 Let's see. Looks like the reporting is in progress. So welcome everyone. Today I'm going to go through a quick overview of Balsa and then we're going to talk about the conformance test suite. So first and foremost, I'm going to talk about what a unit of conformance is and sort of its boundaries and why it's important to understand what a unit of conformance is when we're talking about things like Balsa and the conformance test suite. So it's a little bit of information I like to go over because after all that is the cornerstone of the software development efforts regarding the phase technical standard. So once we talk about what a unit of conformance is, I'm going to talk about Balsa. I'm going to talk about what it is, what it can be used for, how it's organized and then just some additional information regarding it. I'm going to show a couple of diagrams just to kind of show why it is the way it is and then after we take a short break I'm going to talk about the conformance test suite. I'm going to go over the testing methodology and the approach to testing with the conformance test suite. We're going to talk about project configurations, tool chains and then preparing a UOC for test, running a test and then I will actually demo it in real time show you using a Balsa UOC the test being executed. So unit of conformance or UOC it's mentioned a lot in the phase technical standard. A lot of people hear it thrown around but basically it's a software component built according to the requirements in the phase technical standard. That's pretty much it. If you've defined a defined and developed a software product aligned to the standard it at its lowest level is a unit of conformance. The unit of conformance requirements can be found in section 4.11 of phase technical standard edition 3.1. I believe it's 3.11 and 3.0 because we iterated the chapters to introduce a definitions chapter in edition 3.1 and then segment specific UOC requirements can be found in the following sections for all of the segments. But at the lowest level there is the unit of conformance requirements and then depending on what segment your UOC targets you have segment specific requirements that a UOC must adhere to. So that's these. I just wanted to kind of show this for familiarization and to so that everyone understands exactly what is meant by a UOC and how you're meant to navigate the standard when building one. So a UOC is essentially depending on the programming language you use in its state is essentially an object a service or a package. In terms of object oriented languages it's going to be an object and more procedural languages like C it's typically going to be a service it can be a package consisting of several services and it can actually be deployed as a UOC package in which multiple capabilities are deployed with it. A UOC may only use the interfaces defined by the face reference architecture so for data movement you know the TS interface for input output the IO service and for using OS specific methods and functions the OSS APIs and it's important to note that the UOC itself is not a standalone executable parts of the face technical standard do go over you know the concept of the external client which is expected to produce a main and that kind of fits more into the more object oriented approach that was introduced in 3.x. Now with unit of units of conformance with p triple s and pcs UOCs because they interact with the TS interface and actually move data you know in and out of itself those particular UOCs must provide a data model to model its message syntax and semantics and this is going to be in the form of a UOP supplied model defined according to the face data architecture. TSS, iOSS and OSS UOCs also have to provide implementations of the face interfaces that they that service entry points to the services they provide and what this means is that when it comes to the face technical standard a UOC is both a provider and a user of a face interface and if you look at this diagram at the bottom you have just a very basic mock-up of a UOC using a TSS interface and then a UOC that provides the TSS interface you know kind of within that UOC boundary and so on the left the TSS implementation would provide the TSS interface whereas a p triple s or pcs UOC would use that interface so it's very important to understand that concept and of course because the UOC on the right is going to use the TS interface all its data exchanges have to be modeled in accordance with the face data architecture and supply a UOP supplied model when it comes to conformance. So now let's get into balsa now that we know what a UOC is and kind of its boundaries and you know kind of the reason for the madness so balsa or basic avionics lightweight source archetype just because everyone loves an acronym it's a set of UOCs that provides the following first and foremost a face computing environment which is basically an instantiation of the face reference architecture a face computing environment provides the minimal UOCs in certain segments in order to integrate new p triple s and pcs capabilities so the face computing environment provided by balsa has TSS UOCs it has iOSS UOCs an implementation of the OSS configuration services it has an HMFM service implementation it has a centralized logging p triple s UOC it supplies the face interfaces defined by the face technical standard and it also provides implementations of the face support classes and these are defined in appendices of the face technical standard include things like fixed string and sequence and then also in addition to the face computing environment it provides a set of p triple s UOCs that use the face computing environment in order to demonstrate a very basic avionics process I believe there's I think four p triple s and pcs UOCs other than the centralized logging of course that basically combined position and tail number data to you know kind of you know show an ad sp out process and it's got a mock p triple s when I say mock it's that it because it doesn't fulfill all of the requirements of a UOC in the p triple s but we call it the ad sp in and basically it's just to read back in the data going out over the wire and show that full loop so I do I do have to acknowledge that when it comes to balsa there is one mock p triple s UOC that's just there for demonstration purposes it does not fulfill the requirements of a true p triple s UOC here's the face boundary diagram for balsa at the very top of the portable component segment we have a pcs called the atc manager and it communicates with the balsa tss the balsa tss consists of a tst a adapter UOC which provides the ts capability it also features a type extraction uoc that provides the abstraction capability distribution and configuration the platform specific services segment has four platform device services the egi controller the aircraft config the ad sp out and then even though it doesn't satisfy all of the p triple s requirements we do include the ad sp in on the diagram just to kind of show it and then for platform device services within the p triple s we have a centralized logging UOC at the IO services segment we have a implementation of the generic IO service and it provides a udp read and write capabilities that communicate with the ethernet device driver and also there is an implementation of the generic IO service that just does file input output and that is used by the centralized logging UOC to actually write out its data at the OSS the operating system that is assumed is linux or some form of the linux kernel the config there is a configuration services UOC provided by balsa which I mentioned on the previous slide and there is a health monitoring implementation it's one for those of you that are not so familiar with the health monitoring there is two ways it can be implemented either one in a posix pure environment using the health monitoring C style declaration that's in the face technical standard however if you're using a-ring 653 you are required to use the health monitoring apis that are provided by a-ring and if you are providing a mix of posix and a-ring for your posix processes you are expected to implement the health monitoring api as sort of a wrapper to the a-ring 653 methods so that's the boundary diagram now as far as kind of more specifically what balsa is and why it is the way it is it's it's written in c++ with some c services it uses the posix safety base api set it was developed using sentos 7 however we've tested it on other operating systems sentos 8 i think linksos and a couple of rtosses i can't remember which ones other than deos rtems it uses a multiple inheritance pattern to inherit and implement the face interfaces at different levels of inheritance it uses base classes and it also implements the factory pattern in its design especially when creating new connections in the tss and in the ios s as well so the factory pattern has has proven very useful in abstracting different services at different levels and for providing better extensibility and reuse we originally used the joint strike fighter coding standard i i say originally used because it's had so many iterations along the way that i'm not 100 confident that we are 100 compliant with that coding standard however we originally did write our code according to that style so yeah that that was just something we chose and it we also implement a very strict set of compiler settings we use pedantic and we use all warnings as errors to ensure that it compiles as clean as possible we also provide shell scripts for launch operations you can launch it as one uoc per executable or you can launch them as a group with the adsb in being outside of the one executable that instantiates and manage the life cycle of the rest of the uocs and just for information all uocs do pass the face conformance test suite however they only there is a certain test suite that we last tested with there are two new versions of the cts per 3.0 and 3.1 and we haven't fully tested it with those because we delivered balsa to the face consortium before those cts came out so what is it used for as far as the consortium the consortium gets a lot of use when it comes to balsa in the form of vetting cr content and testing changes it proves to be a very valuable test bed now for government and industry partners it can be used for developing new products learning about the face reference architecture and kind of understanding you know patterns and you know an approach to developing face uocs because you know a lot of people tend to learn by doing i know i'm i'm one of them i like to see a pattern implemented before i you know can you know can safely say that i understand it and then also it's useful as a test infrastructure it's it's out there for use by companies and government as sort of you know a way to have a test infrastructure that we don't have to go out and procure your own procure or build your own tss or ios s for for for example it's it's there for that use because after all in face you're designing to interfaces not to implementations so there's benefit in that now how we organized it so being that it's in c++ we have the ability of separating things by namespace the only thing that's in the face namespace is the is the are the interfaces and things defined by the face technical standard so we implement nothing in the face namespace we just use it for the headers and the implementations of the support classes simply because um most of the support classes are in class form and so um hands are just kind of tied there but uh as far as the face support classes and their implementation these are considered integrator provided aspects um some os s's do provide them um and certain products that you can procure have them as well so in order to not overload the face namespace we created yet another acronym fia or face implementation architecture and that's where we've implemented all of our face interfaces as far as the um tss ios s and os s you will see uh we also create component base classes in the fia namespace and then in the balsa namespace we have our application specific adapter services for things like the tss and ios s we have our tst a infrastructure we also have the balsa component classes and pcs and p triple s base classes now once again each of these um base component classes inherit interfaces at different levels for instance that the component base class all components are assumed to use the configuration services so they inherit the configuration injectable interface and then you know more specifically at the pcs and p triple s levels um they inherit the tss base and then pcs and p triple s you will see classes in themselves where you get into actual instantiations of specific services then you inherit your type ts injectables and also we have external clients which provide main they instantiate the uocs to resolve the uoc dependencies via the lifecycle um no i'm sorry the injectable interfaces and then they also manage the uoc lifecycle now one extra little tidbit about balsa balsa does implement as much of the face technical standard as relatively possible and in doing so we have also implemented all of the lifecycle management interfaces except for the uh framework uh connectable interface so we implement the initializable configurable and the stateful interface some bonus features when it comes to balsa there is a user's guide and it's complete with cts instructions on how to compile and test use uh test the balsa uocs with the conformance test suite an early version of a balsa 3.0 uoc did successfully pass face the face verification authority and i've i know you can't see it but you know down on the right hand side that is the statement of verification that we received back from the face va um asserting that their review was success successful and they have not sure what the correct term is for how it passes their level it's not conformant yet because it hasn't been through all the levels but it did pass face verification so i believe that's all i can say about that um and then also it was part of the source distribution of balsa there is a tss benchmarking tool called ping pong where it is used to basically measure the data flow rate and latency uh of of tss messages on a particular os that you're testing it on so that was very useful for us in kind of showing um the tss latency on different os's i know we tested it on on both sentos and raspberry pi not sure if it's been tested on any other os's and then another bonus balsa has been successfully deployed on a face conformant art os so it is portable to a uh art os with slight modification now going back to talking about inheritance this is kind of a bit of an eye chart i i'm aware but this is a um l class diagram showing the inheritance at different levels in balsa components now this does not include an example of a um of a pcs or p3s that provides a service this is strictly the base class architecture at the lowest level kind of in the middle the biggest one the fia component inherits the configuration injectable it also inherits the lcm initializable and configurable going down one more step to the balsa component it inherits the lifecycle management components uh stateful stateful instance sorry um simply because the stateful interface is tied to a data model so it's a little bit less abstract which is why we grouped it in the balsa namespace because it's specific to the balsa data model and then at the pcs and p triple less level is when you inherit your base injectable so this is sort of the inheritance structure that we used and once again at the actual service level of the pcs and p triple less classes is when you inherit your type ts injectables how it looks when it's running this is kind of a a mock example of what balsa looks like when you run it with one uoc per executable it basically just creates a bunch of terminals and prints out the data that's you know that it's processing and if everything works the adsbn which you can see on on top on the left on the right is the centralized logging component which you know just prints out like a like a message or two and then it just kind of just awaits in the background the adsbn is showing everything that it's got and if you have correctly implemented everything then it will be getting adsb data which you can see displayed on that console window okay that's it for the balsa portion