 Welcome to the FACE CTS Learning Series, Chapter 3, The CTS User Interface, Video 4, Project Configuration. In this video, we will explain the options contained in the Project Configuration Builder. You may open the Project Configuration Builder by launching the CTS and selecting File, Projects, then select New to create a new Project Configuration File. For this video's purposes, we will keep the default options in the Project Name and Project Location. As mentioned in previous videos, the Project Configuration Builder allows the user to define UOC-specific options, so the CTS can test the UOC as intended. The General tab allows the user to first select a base directory. The base directory is a file path to where all other file paths defined in the Project Configuration File are relative to. For example, if our toolchain configuration file location was in a folder outside of the base directory's location, like the shown figure, the toolchain's file location would be . . . slash mytoolchainfile.tcfg. The user may choose the face segment type the UOC is by selecting from the dropdown list, either PCS, TSS, PSS, iOS, or OSS. Similarly, the user may choose the language that the UOC is written in, either C, C++, ADA, or Java, and the profile, either General, Safety Base, Safety Extended, or Security. Then, the user may choose what partition the UOC will execute from. There are options for POSIX, RANK 653, and POSIX, RANK 653. If the UOC type is an OSS, and it is selected to provide POSIX APIs, choosing a POSIX partition indicates the UOC provides all of the required POSIX APIs for the selected profile in the face technical standard. For any other UOC type, choosing a POSIX partition indicates the UOC may use any of the POSIX APIs allowed by the face technical standard. If the UOC type is an OSS, and it is selected to provide RANK 653 APIs, choosing an RANK 653 partition indicates that the RANK 653 APIs are supplied as per the face technical standard. For any other UOC type, selecting an RANK 653 partition indicates that the UOC may use any of the RANK 653 API allowed by the face technical standard. Choosing a POSIX RANK 653 partition indicates the UOC provides all required POSIX APIs for the profile, and the allowed subset of RANK 653 APIs as defined by the face technical standard. For any other UOC type, selecting the POSIX RANK 653 partition indicates the UOC may use any of the POSIX APIs and subset of the RANK 653 APIs allowed by the face technical standard. The APIs for each of the face profiles are defined in the face technical standard. If a POSIX or POSIX RANK 653 partition is selected, the POSIX multi-process option is available for selection, if the UOC uses POSIX multi-processing. If RANK 653 partition is selected, the POSIX multi-processing option is not available for selection. Allowed POSIX APIs that support multi-processing is also defined in the face technical standard. If RANK 653 partition is selected, however, the RANK 653 Part 1 version dropdown will be available for selection, either 2010 or 2015. This allows the user to define what version of RANK 653 the UOC is targeted towards. The user also has the option to define the openGL APIs that the UOC uses, if at all. The user must provide the associated toolchain configuration file the project will be associated with. To correctly configure a project configuration file, the toolchain configuration file must be valid. The toolchain configuration file interface is defined in the previous video, and a demonstration of the creation and validation of a toolchain configuration file will be provided in upcoming chapters. The toolchain contains configuration options to define the compiler, linker, and archiver to successfully test the UOC. Finally, the user must provide the UOC's name that is meaningful to the user. This name must also match the name given to it in the data model used for PCS and P3S UOCs. The Data Model tab allows the user to provide the location of the SDM and USM, which stands for Shared Data Model and UOP Supplied Model respectively. The Ellipse button at the right of each input field allows the user to provide an absolute path via the File dialog. More information about the Shared Data Model and UOP Supplied Model will be detailed in Chapter 4. Additional information is provided in the Face Technical Standard and the Reference Implementation Guide, or RIG. In case the user decided to define every entity as unique in their USM, they must check Entity Uniqueness. If the user decided to define every observable as unique in the USM, they must check Observable Uniqueness under the USM field. Finally, the user may select what UOP model corresponds to the UOC in question, as a USM may provide multiple UOP models. After a valid USM supplied to the CTS, the UOP dropdown list and Associated Views box will automatically populate. As explained in previous videos, the Gold Standard Libraries tab allows the user to define the directory in where the Gold Standard Libraries are generated. To generate the Gold Standard Libraries, you may click on the Generate Gold Standard Libraries button, denoted by the Bookshelf icon. Clicking on this button will generate the Gold Standard Libraries, generate Interface Header Files, and generate the Factory Function Header in the location that was defined in this section. The Object Libraries tab allows the user to define a UOC's dependencies, object file or source location, and the face interfaces that the candidate UOC uses or provides. In the conformance testing process, the CTS purposefully has no knowledge of how the object files include header files, so the user must define all locations a header file is used from. The user must define the paths of the directories in the Include Paths section and Absolute Paths of the file in the Include Files section. The CTS has two ways of testing a UOC, using object files and libraries, called the target linker method, and using the source code directly, called the host linker method. If the user chooses the target linker method of testing UOC's, the user must provide information about the build tools to build the UOC in the toolchain configuration file. A list of compiler flags are listed in the CTS user manual that are necessary to use the target linker method. If the user chooses the host linker method of testing UOC's, the user must alter the project's build system that uses the host build tools and recompile. The user must be mindful of any conditionally compiled code based on architecture or compiler, as any results, for example, link tests, must be reproduced by a verification authority to be deemed conformant. In the case of performing link tests, the same testing environment must be reproduced because the linking is different for each compiler used. For more information, please refer to the Conformance Certification Guide and Software Suppliers Guide. Face interfaces are empty declarations. When the gold standard libraries are generated, the gold standard libraries themselves, the header files to build the UOC to, and the header file directory for the factory functions are created. This factory function header file is a list of all face interfaces and function calls the UOC candidate provides. In order to properly test the user's code within the CTS, the user must provide a file that contains a concrete implementation for each interface needed for the UOC provided. This is called a factory function. Once the user creates their factory function declaration and the user runs the conformance test, the test file declares a pointer to the face interface. Then the CTS instantiates it by calling the factory function implementation that the user provided. Once the instantiation is complete, it calls each method defined in the interface to ensure complete adherence to that interface. Language specific information on how to generate, read, and write factory functions is contained in the CTS user manual. The user must then select any interfaces used in the candidate UOC. It is important to note that there is a difference between a provided and used interface. The user must supply an injectable to that interface. The injectable interface provides a way for the integrator to pass an instance of the implementation. The injectable interface provides a way for an integrator to pass an instance of an implementation of a certain API to a user of that API. For more information, it is recommended to consult the face technical standard. The user has the option to select the life cycle management interfaces if used. More information about life cycle management interfaces are provided in the face technical standard. Because, as we will discuss in the next chapter, face data models describe PCSs and P3Ss, project configuration files that target iOSs and TSSs that use the life cycle management stateful interface must provide information on reported type name, reported type data model name, request type name, and request type data model name. In other words, the reported state is the states that the UOC can be in and the requested state includes the states that an external agent can request the state to change to. Then, the user may select any face interfaces used. The IO interfaces will become interactable only if the target UOC type is a P3S. The user may define any LCM stateful interfaces that are used by the UOC. The user must provide the interfaces that the UOC is going to transition to another UOC. Just like the toolchain configuration builder, the project configuration builder provides a note section to write any notes necessary for the description of development and description of the usage of the project. The notes will be shown in the project files list when saved. Last, the project info tab provides information about the project configuration file that has been defined in previous tabs. These fields are not editable, but changes in other sections are reflected here as necessary. A project configuration may be validated by pressing the check configuration button on the top left, denoted by the checklist icon. Doing so, we'll check the required fields for valid entries. If after selecting the button, the project configuration is not valid, the CTS will show an error message with the description of the error. If more details are required, the user may select the bottom right button for more detailed results. Since we don't have a valid project configuration file at the moment, clicking on the run conformance test button will result in an error. At the top of the run segment conformance test interface, we are shown the title of the project configuration file of the UOC under test. In our case, it is untitledproject.pcfg. Directly under the title, we may select a recent project from the recent project configuration files and run another conformance test without having to leave the run segment conformance test interface. Similarly, we may choose to only test the data model from a selected project configuration file in the recent project list. The summary section under the recent project section shows the user details about the project configuration currently under test. We may expand the general data model, objects libraries and note subsections, but they are unable to be edited. On the right, we are shown a progress bar with the current progress of the conformance test. Since we did not have a valid project configuration file, the CTS did not start the conformance test. Instead, it shows an error saying that we have not provided a toolchain configuration file. More detailed results of the error can be found at the error.log file shown below the progress bar. A demonstration of using a toolchain configuration file and project configuration file to test the UOC will be shown in future chapters. You may return to the project configuration builder by using the back button or selecting the project in the recent project list and pressing the edit button. You may also return to the home page by selecting the home icon. Thank you for watching. This concludes the project configuration builder tour. In this video, we explain the configuration options available for project configuration files and introduce the run segment conformance test interface. This also concludes chapter 3, the CTS user interface. In the next chapter, we will introduce why and how the CTS uses data models to test for UOC conformance, further explain the data model tab in the project configuration builder, and how to validate data models using the DMBT within the CTS GUI and on the command line.