 Welcome to the CTS Learning Series, Chapter 5, Testing a Non-OSS-UOC Example. Video 6, Demonstration of an iOSS Conformance Test. In this video, we will demonstrate how to construct a project configuration file for an iOSS-UOC, perform a successful conformance test on an iOSS-UOC, and suggest ways to troubleshoot common errors while testing an iOSS-UOC. As mentioned in Chapter 5, Video 1, we'll be testing Balsa's UOCs. This video in particular will test Balsa's iOSS-UOC. 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 iOSS 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 PCS-UOC. But for more information about each of the options provided in the PCS-UOC, 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 iOS. 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, the Balsa iOSS 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 RINX 653 APIs, only POSIX. For our iOSS, we also 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 iOSS example. Let's click on the Data Model tab. Data models are not required for iOSs, except if an iOSS is using the Lifecycle Management interfaces. Our UOC does not use the Lifecycle Management interfaces, so we can entirely ignore the Data Model tab. 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 Object Libraries tab, we must define the interfaces the iOSS uses. It should be noted that the beginning of the iOSS Object Libraries tab is different from the PCS and PEE-TRIPLE-S and the TSS Object Libraries tab. An iOSS may define one-to-many IO interfaces. For our purposes, our UOC uses the generic IO interface only. For more information about the types of IO interfaces the iOSS supports, please consult the Face Technical Standard. As mentioned before, analyzing Balsa is out of scope for this video. However, each of the header files that the 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 Functions CPP file, we must generate the GSLs. For now, we'll leave this blank. Now, we must select the interfaces that the iOSS UOC implements and use. Our iOSS doesn't implement any interfaces, but it does use the Configuration Services Interface and the Health and Fault Monitoring, or HMFM, interfaces. 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 Functions sections blank. To fill these 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 file 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 Factory Functions header file and a face subdirectory. Let's open the CTSFactoryFunctions.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 that 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 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. 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 iosasfactoryfunctions.cpp. Let's include the ctsfactoryfunctions.hpp header file and the header files for the iosas UOC, which is where the FIA IO service 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 class that implements that specific function. Now, the cts may understand that the iosas UOC implements each of the required functions. Let's put the path to this factory functions file in the factory functions location in the project configuration builder. 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 iosas 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 iosas. 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 4. 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 5, video 7, we will open the performance test report and talk about the test 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 Review of Testing Result, we will explore where a non-OSS conformance testing report is generated, analyze how to read a conformance test report, and analyze the major sections in a conformance test report.