 Welcome to the CTS Learning Series, Chapter 5, Testing a Non-OSS UOC Example, Video 4, Demonstration of a P-TRIPLE-S Conformance Test. In this video, we will demonstrate how to construct a project configuration file for a P-TRIPLE-S UOC, perform a successful conformance test on a P-TRIPLE-S UOC, and perform an unsuccessful test on a P-TRIPLE-S UOC, and suggest ways to troubleshoot common errors while testing a P-TRIPLE-S UOC. As mentioned in Chapter 5, Video 1, we will be testing BALSA's UOCs. This video in particular will test one of BALSA's P-TRIPLE-S UOCs, called ADSB UNDERSCORE OUT. For more information about BALSA and how BALSA is organized, please consult the FACE Technical Standard, the Reference Implementation Guide, and the Software Suppliers Getting Started Guide. Let's open the project configuration list and make a new project configuration. Let's name it, CTS Learning Series, P-TRIPLE-S Demonstration, and we'll save it in the CTS Learning Series directory. After clicking OK, we are presented with the Project Configuration Builder. For this video, we will be demonstrating the construction of the PCFG, but for more information about each of the options provided in the PCFG, please refer to Chapter 3, Video 4. Let's first select the base directory. I'm going to set the base directory as Home, CTS User. Next, our segment is going to be P-TRIPLE-S. BALSA's UOCs are all written in C++, so we will select C++ as our language. Our profile is going to be Safety Base, as that is the FACE profile our BALSA P-TRIPLE-S UOC is written to, and what we configured the toolchain to test as well. Our partition is going to be POSIX, as our OS does not provide any of the RNK 653 APIs, only POSIX. For our P-TRIPLE-S, we aren't going to use any OpenGL functions. Next, the option to provide the toolchain configuration file is provided. Finally, the UOP name is used to identify the UOP. Let's enter CTS Learning Series P-TRIPLE-S example. In the Data Model tab, let's provide the shared data model location and the UOP supplied model location. BALSA's USM does not have any entity uniqueness or observable uniqueness, so we can leave these options unchecked. We must choose our UOP from the dropdown. In our case, let's choose ADSB underscore out. In the Gold Standard Libraries tab, let's provide the location of an empty folder. We will set this as Home, CTS User, GSLs. In the Objects Libraries tab, we must then supply the Include paths and Include files for the ADSB out UOC. As mentioned before, analyzing BALSA is out of scope for this video. However, each of the header files that the ADSB out UOC uses must be provided in order to check for conformance. The list of included header files and paths are listed on the screen. As mentioned in Chapter 1 Video 1 and Chapter 3 Video 4, there are two methods of testing UOCs for conformance, the Target Linker and the Host Linker methods. We will be using the Target Linker method. This means we must provide object files that were compiled against the Gold Standard Libraries. We don't have the object files yet as we haven't generated the Gold Standard Libraries or built BALSA against them. For now, we'll leave it blank. Continuing down, we are provided an option for providing the factory functions. As mentioned in Chapter 1 Video 1 and Chapter 3 Video 4, factory functions are concrete implementations of methods that allow the CTS to test for implementations of the provided interfaces. The factory function header file is generated alongside the Gold Standard Libraries. So before we can provide the factory function's CPP file, we must generate the GSLs. For now, we'll leave this blank. Now, we select the interfaces that the ADSB Out UOC uses. The ADSB Out UOC implements the LCM initializable and the LCM configurable interfaces. The ADSB Out UOC uses configuration services, generic IO interface and the Health and Fault Monitoring or HMFM interface. Note that in Chapter 5 Video 3, the IO interface options were not able to be selected. This is because, according to the face technical standard, a PCS cannot communicate using an IO interface. All IO interface usage is by the PEECH or BALS. More information is contained in the face technical standard and the reference implementation guide. The notes and project info tabs do not contribute to the project configuration validation or conformance testing, so we can ignore these tabs. We won't use them. We have intentionally left the target linker section and the factory function sections blank. To fill those sections in, let's generate the Gold Standard Libraries by pressing the bookmark icon. After the generation finishes, let's take a closer look at what was generated. In the directory, we can see a list of libraries and a readme file. Let's look at the readme that was generated. The readme lists the valid GSLs that were generated, as well as the associated include directories that should be used to build objects to test with the CTS, including the files that were just generated. Let's take a closer look at those files. If we point to the GSL include directory, we can see the CTS factory functions header file and a face subdirectory. Let's open the CTS factory functions.hpp. Here, we can see the function signatures we must implement in order to be face conformant. These were generated based on the supplied options from the project configuration file. Let's exit this file and look at the face subdirectory. Here, we have the generated header files we must include while developing UOCs. How to use these files are out of scope for this video series, but it is important to understand that the GSL generation process generates these files as well. For now, what we're focused on is the libraries and the factory function headers. Balsa was written to the face technical standard and correctly implements the interfaces required to be conformant to the face technical standard. If you download Balsa from the open group website, it already comes with the factory function implementation that is required to be written. For the purposes of this demonstration, we are going to write the factory function implementation ourselves. Let's do that now by opening a text editor and creating a file called adsboutfactoryfunctions.cpp. Let's include the ctsfactoryfunctions.hpp header file and the header file for the adsbout UOC, which is where the adsbout class is defined that implements each of these functions. Then we'll copy and paste all of the required functions from the header file to the source file and return a new instance of the adsbout class. Now the cts may understand that the adsbout UOC implements each of the required functions. Let's put the path to this factory function source file in the factory function's location. Finally, we need to create our object files. Balsa has a build process that uses make. Although we are not going to analyze the build process, it is important to note that there are two ways of building balsa. One to build for face conformance and one to build without face conformance. In our case, we are going to build the adsbout UOC for conformance. When we build, balsa detects the gold standard libraries to build against. Balsa contains configuration options to provide the path to the gold standard libraries. Before we build, we must make sure the path is correct or else balsa won't be able to find the gsls. Finally, we may enter our build command. Enter make-f makefile.conformance adsbout. Balsa will build and create an object file. The file extension for the object file will be .rel. Let's provide the newly created .rel file in the target linker section. We can now press the test UOC conformance button. The progress bar will fill up as the conformance tests are being performed. Just like the data model conformance testing we performed in chapter four, we are shown the conformance test result with the output file location at the bottom of the interface. It looks like we were successful in our test. In chapter five, video seven, we will open the conformance test report and talk about the results for non-OSS UOCs. Let's intentionally create an error by creating a new project configuration with no options configured. Let's select the test UOC conformance button and see what happens. It looks like the test returned an error because there was no toolchain among other things. Let's press the back button and then the project validation button. This button tests to see if our project configuration is valid and all options are configured correctly for a conformance test. It looks like we're missing our toolchain file as stated before. Clicking on the bottom right icon allows us to view details of the failed test. Thank you for watching. In the next video, entitled Demonstration of a TSS Conformance Test, we will demonstrate how to construct a project configuration file for a TSS UOC, perform a successful conformance test on a TSS UOC, and perform an unsuccessful conformance test on a TSS UOC, and suggest ways to troubleshoot common errors while testing a TSS UOC.