 Welcome to the CTS Learning Series Chapter 5, testing a non-OSS UOC example. Video 5, demonstration of a TSS conformance test. In this video, we will demonstrate how to construct a project configuration file for a TSS UOC, perform a successful conformance test on a TSS UOC, perform an unsuccessful conformance test on a TSS UOC, and suggest ways to troubleshoot common errors while testing a TSS UOC. As mentioned in chapter 5 video 1, we'll be testing Balsa's UOCs. This video in particular will test one of Balsa's TSS UOCs called TSS Type Abstraction. 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 TSS 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 TSS. 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 TSS 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 TSS, we also aren't going to use any of the 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 TSS 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 entity uniqueness or observable uniqueness, so we can leave these options unchecked. For TSS UOCs, when the data model populates the UOP section, instead of a drop-down, we have a checklist that we may select UOPs to see the associated views. This is different from P++ and PCS UOCs that we have seen in Chapter 5, Video 3 and 4. 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 then supply the Include Paths and the Include Files for the TSS UOC. It should be noted that the beginning of the TSS Objects Libraries tab is different from the PCS and P++ Object Libraries tab. There are multiple different TSS types, which may be selected in the drop-down, either TSS Interface TSS UOP, TSS Type Abstraction Interface TSS UOP, TSS Component State Persistence UOP, TSS Transport Protocol Module UOP, or TSTA Interface Adapter UOP. We will be selecting the TS Type Abstraction Interface TSS UOP. It is out of scope for this video series to explain the different types of TSS UOPs, but more information may be found in the FACE Technical Standard and the Reference Implementation Guide. Next, we have an option to define whether our UOC uses the Type Abstraction Intersegment API or the Transport Protocol Module Intersegment API. For the TSS Type we selected, we are unable to use the Type Abstraction API, but our UOC does use the Transport Protocol Module API. We also have options to select if our UOC uses or implements the extended or TPM serialized interfaces. Our UOC does not implement or use either, so we may leave these blank. 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 UOC's for conformance, the Target Linker and the Host Linker Method. We will be using the Target Linker Method. This means that 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 may select the interfaces that the TSS UOC implements, but our TSS doesn't use any. However, the TSS UOC does use the Configuration Services Interface and the Health and Fault Monitoring, or HMFM, interface. The notes and project info tabs do not contribute to the project configuration validation or conformance testing, so we can ignore those tabs. We won't use them. We have intentionally left the Target Linker section and the Factory Functions section 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 CTS Factory Functions header file and a face sub-directory. 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 sub-directory. Here, we have the generated header files we must include while developing UOCs. How to use these 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. With Balsa from the open group website, it already comes with the factory function implementation that is required to be written. Instead, 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 tssfactoryfunctions.cpp. Let's include the ctsfactoryfunctions.hpp header file and the header files for the tss UOC, which are fia underscore tss underscore base dot hpp and fia underscore tss underscore type abstraction dot hpp, which is where the tss base and the tss type abstraction classes are 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 tss 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 tss UOC for face conformance. When we build, balsa detects the gold standard libraries to build against. Balsa contains configuration options to provide the path for 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 tss. 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 conformance 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 Demonstration of an IOSS conformance test, we will demonstrate how to construct a project configuration file for an IOSS UOC, perform a successful conformance test on an IOSS UOC, perform an unsuccessful conformance test on an IOSS UOC, and suggest ways to troubleshoot common errors while testing an IOSS UOC.