Applicable Technical Standard: All 1.0 1.1 2.0 2.0.1 2.1 2.1.1 3.0 3.1 3.2 3.3

Title	Approved Correction	Applicable Technical Standard(s)	Correction Date
Function references should use TS interface (not TypeSpecific or TypeAbstraction)	For TSS Implementations of the FACE Technical Standard 2.1 use the following text replacements: (1) Section E.3.4 2nd sentence, replace “The TypeAbstraction Receive_Message(TS)” with “The Receive_Message(TS)” (2) Section E.3.4 IDL Declaration, replace “interface TypeAbstractionTS” with “interface TS” (3) Section E.3.5 1st sentence, replace “The TypeAbstraction Send_Message(TS)” with “The Send_Message(TS)” (4) Section E.3.5 IDL Declaration replace “interface TypeAbstractionTS” with “interface TS” (5) Section E.3.6 IDL Declaration replace “interface TypeSpecificTS” with “interface TS” (6) Section E.3.7 IDL Declaration, replace “interface TypeSpecificTS” with “interface TS” To conform to the Type Specific API a TSS should follow the IDL declaration in Section E.2.3. Impact Statement: No impact to existing conformant products. Resolution resolves typos in Appendix E.2.3 to provide clarity.	2.1	02 Oct 2017
Platform View GUID is not the name used in figure 35	For TSS implementations of the FACE Technical Standard 2.1, the Message Header described in 3.7.5.4 defines the second element of the Message Header to be a Platform View GUID versus the Message Definition GUID described by the Platform Data Model View (Header) in Figure 35. To conform to these requirements, the Platform View GUID (3.7.5.4 second element of the Message Header) is considered to be the same element as the Message Definition GUID (Figure 35 Platform Data Model View (Header)).	2.1	02 Oct 2017
Update Conformance Policy to address Domain Specific Data Models	The FACE Consortium has expanded the Conformance Program to include Certification of a Domain Specific Data Model (DSDM). The FACE Technical Standard Editions 2.0/2.0.1/2.1/2.1.1 requirements that apply to a DSDM are in Section 3.6.2, Item 2, requirements a, b, c, and f. As these requirements are tested by the Conformance Test Suite, the Conformance Verification Matrix is not required as part of the Verification Package. A Domain Specific Data Model (DSDM) can obtain a Conformance Certificate by performing the following: 1 - The Software Supplier completes a Software Suppliers Statement of Conformance. Prior to the publishing of a Software Suppliers Statement of Conformance with the appropriate field, the supplier will state "DSDM" after the Technical Standard Edition in section 3. The segments and profiles in section 3 should remain blank. 2 - The VA will test the conformance of the DSDM against the requirements for a USM. NOTE: A DSDM is not required to contain any UoP models or Platform Data Model elements. 3 - The Test Suite can test conformance to these requirements by running a Data Model test. The DSDM will be entered as the USM and will be tested for conformance against a shared data model. Only the Data Model portion of the test should be executed from the CTS main menu. 4 - If the Verification process passes, the VA will complete a Statement of Verification. Prior to the publishing of a Statement of Verification with the appropriate field, the VA will state "This was a test of a DSDM" in the Verification Authority Notes in section 3. 5 - The Software Supplier will submit the DSDM to the CA/LA for certification and registration using the Conformance Workflow tool at https://www.facesoftware.org/.	2.0 2.0.1 2.1 2.1.1	17 Feb 2017
C-language OSS conformance tests for ARINC 653 APIs	Allow the software supplier and VA to execute the following script on the CTS v2.0.15 as an approved correction. find conformanceInterfaceTests/C/OSS/ARINC-653 -name "*.c" -exec \ sed -i 's/#include "ARINC653.h"/#include "ARINC653_CONFORMANCE_TEST.h"/ /#include "ARINC653P2.h"/d' '{}' \; rm conformanceInterfaceTests/C/OSS/ARINC-653/ARINC653.h This will appropriately update the CTS tests to correct for this situation. This corrects an issue where the ARINC-653 tests include the CTS header files instead of the OS header files. A future release of the CTS will eliminate the need for the script to be executed. The timeline for an updated CTS is not known at this time.	2.0 2.0.1	26 May 2016
Conditional Requirement Not Labeled	For conformance to Technical Standard 2.1: In the 2.1 CVM, row 1695 should be treated as if "ARINC 739" is entered in the conditional column. Suppliers are allowed to make claims toward the inapplicability of this requirement to a UoC going through conformance.	2.1	31 Dec 2016
Fixed Length Strings Not Supported	The Data Architecture meta-model has been extended with meta-types for representing both fixed length and bounded strings. The language bindings for mapping these new meta-types to code were added. The attached file includes the updates. An update to the OCL Constraints is also needed due to the addition of the FixedLengthString metatype. The updated FSL document (2017-05-12) attached details this update. Conformance Testing to this Approved Correction will require the use of the latest Conformance Test Suite.	2.1	02 Oct 2017
Removal of Conformance Certification Trademark and TMLA Requirements from FACE Conformance Program	FACE Certification Trademark and Associated Trademark License Agreement (TMLA) have been removed from the FACE Conformance Program. Disregard any and all reference to a FACE Certification Trademark and associated TMLA. All documents having these references will be corrected during the next review cycle.	1.0 1.1 2.0 2.1 3.0	06 Sep 2016
OpenGL Gold Standard library fails to build when using CTS 2.1.0r4	When using the Test Suite for conformance to OpenGL, the Supplier and VA are allowed to make the following change to the CTS version 2.1.0r5. In the file, goldStandardLibraries/C++/Makefile, replace the string OPEN_GL_EGL_12_GoldLib.a with the string openGL_EGL12_GoldLib.a.	2.1	06 Dec 2016
Note for posix_devctl() applies to all profiles	For Technical Standard Editions 2.1 and 2.1.1, The text in the note 4 of Appendix A applies to all profiles indicated in the method table also in Appendix A. The row for posix_devctl() indicate this note in all four columns per the references in the method table also in Appendix A.	2.1 2.1.1	06 Nov 2017
TSS Message Header context not defined	For TSS Implementations of the FACE Technical Standard 2.1, the Message Header described in 3.7.5.4 is a logical entity and is not intended to exist in a structure within the TSS implementation. Section 3.7.5.4 states that the Message header consists of elements in order, this is meant to be descriptive of the logical data.   All elements described in Section 3.7.5 are logical in nature and allow the information identified by these elements to be managed and/or transmitted in a manner that best fits the protocol implemented for the wire protocol. These are logical concepts where the diagram is showing the relationship between the logical elements and with their supporting description in the paragraphs following the figure.   To comply with these requirements, a TSS must simply prove that the TSS is derived from individual logical elements as needed and those elements are reflected on both sides of the communication .	2.1	02 Nov 2017
Remove the need to model well documented graphics standards	The FACE Technical Standard 2.1 section 3.14 states that ARINC 661 Clients and Servers communicate via FACE Transport Services using the ARINC-661 Command Stream. This command stream is completely defined by the ARINC 661 standard and does not have to be represented in the Data Model. For FACE Graphical UoC conformance to FACE Technical Standard editions 2.1 and 2.1.1, an ARINC_661_Command_Stream message type can be communicated over the TSS interface as follows. For C: typedef unsigned char ARINC_661_Command_Stream[]; void Send_Message_ARINC_661_Command_Stream( CONNECTION_ID_TYPE connection id, TIMEOUT_TYPE timeout, TRANSACTION_ID_TYPE *transaction_id, ARINC_661_Command_Stream *message, MESSAGE_SIZE_TYPE *message_size, RETURN_CODE_TYPE *return_code); void Receive_Message_ARINC_661_Command_Stream( CONNECTION_ID_TYPE connection id, TIMEOUT_TYPE timeout, TRANSACTION_ID_TYPE *transaction_id, ARINC_661_Command_Stream *message, MESSAGE_SIZE_TYPE *message_size, RETURN_CODE_TYPE *return_code); For C++: typedef unsigned char ARINC_661_Command_Stream[]; void Send_Message( CONNECTION_ID_TYPE connection id, TIMEOUT_TYPE timeout, TRANSACTION_ID_TYPE &transaction_id, ARINC_661_Command_Stream &message, MESSAGE_SIZE_TYPE &message_size, RETURN_CODE_TYPE &return_code); void Receive_Message( CONNECTION_ID_TYPE connection id, TIMEOUT_TYPE timeout, TRANSACTION_ID_TYPE &transaction_id, ARINC_661_Command_Stream &message, MESSAGE_SIZE_TYPE &message_size, RETURN_CODE_TYPE &return_code); For conformance testing of this interface, the above code snippets may be added to the compiler specific files in the test suite. The normal VA inspection of this file will take into account supplier sighting of this Approved Correction and the design of the UoC as a graphical UoC using ARINC 661. This PR can be expanded if a need for an Ada or Java approved correction is required at a later date.	2.1 2.1.1	28 Jun 2018
Ordering Projection with View, for consistency in generated code	For conformance to the FACE Technical Standard, Editions 2.1 and 2.1.1, Section 3.6.2 should be read as if the following note is present: The FACE XMI representation specifies the order for projected characteristics in a View for representation in data modeling tools and generated code. Tool representations and generated source code should maintain the order of the characteristics from the normative XMI representation.	2.1 2.1.1	01 Oct 2021
Code Mapping not specified for Projection of Associations with blank Path	For conformance to Editions 2.1 and 2.1.1, section 3.6.4.1.1.3 should be read as if the following note were present: If an Association is being projected and the "path" attribute is empty, then only the Characteristic Compositions are included in the View and not the Associated Entities.	2.1 2.1.1	01 Oct 2021
Individual Certification of OSS Components	The FACE Consortium has recognized the desire for Software Suppliers in the Operating System Segment to hold FACE Conformance Certificates for these products. The FACE Consortium also acknowledges that within this segment, the individual products are often tailored to interface with the specific operating system that resides within this segment. The FACE Technical Standard should be interpreted such that multiple UoCs may provide the services described in the Operating System Segment. UoCs within the Operating System Segment can include one or more of the following Capabilities: Operating System* C++ Language Runtime Ada Language Runtime Java Language Runtime OSGi Framework OpenGL Driver Configuration Services** * An OSS UoC providing the operating system must include the C99 language runtime and address the POSIX, ARINC 653, and HMFM requirements per the selected FACE OSS Profile(s). **Items are only available for conformance to Technical Standard 3.0. A UoC (other than the Operating System Capability) can be implemented as a portable OSS UoC if the interface to other Operating System Capabilities is only through the FACE OSS Interface. A UoC that is dependent on specific operating system interfaces can perform verification/certification on multiple operating systems using the variant rules on conformance. Such a UoC can only claim FACE conformance when used with the operating systems it was verified with. Only FACE Conformant Operating Systems will be considered. NOTE: Under these guidelines, an OSS UoC does not have to include any artifacts from the operating system in order to meet conformance. The operating system must be certified conformant; its conformance will not be further evaluated. Attached to this PR is documentation on how the supplier of a UoC can fill out their Software Supplier Statement of Conformance, CVM, and complete the certification process.	2.1.1 3.0	03 Sep 2019
Conforming a TSS to the type abstraction interface for edition 2.1	For Edition 2.1 of the FACE Technical Standard and all 2.1.x derivatives; conformant TSS UoCs/UoPs must supply the Type Specific interface for at least one modeled view. A TSS Providing the Type Abstraction Interface must include a TSS Type Abstraction (that provides a Type Specific Interface and the translation logic to the Type Abstraction Interface) as part of the Conformance Package. Additional TSS Type Abstractions supporting other types beyond the initial conformance certification of the TSS do not break the original conformance certificate unless the originally conformant code is modified. It is not possible to conformance test and certify Type Specific to Type Abstraction UoCs without the underlying implementation of the TSS capabilities provided by the Type Abstraction UoC. Note: Conformance Certification of these components for a previously certified conformant TSS might not be a contractual obligation.	2.1	02 Oct 2017
Align Create Fault Handler error codes to ARINC 653 Part 1 Standard	For technical standard editions 2.1 and 2.1.1; Appendix C.4 Create Fault Handler Service, in the second list of bullets the 4th bullet, the error constant should be changed from INVALID_PARAM to INVALID_CONFIG to indicate the stack_size parameter is invalid.	2.1 2.1.1	06 Nov 2017
Remove erroneous error return value from Obtain Fault Status Service defintion	For technical standard editions 2.0, 2.0.1, 2.1 and 2.1.1, HMFM Obtain Fault Status Service, in the second set of bullets, the 2nd bullet "INVALID_PARAM to indicate the length parameter is invalid" should be removed. In 2.1 and 2.1.1 the change should be made in Appendix C.6 In 2.0 and 2.0.1 the change should be made to C.2, C.3, C.7	2.0 2.0.1 2.1 2.1.1	06 Nov 2017
Add missing error check to Raise Application Fault Service	For technical standard editions 2.0, 2.0.1, 2.1 and 2.1.1, Raise Application Fault Service, in the return codes, add "INVALID_PARAM when error code parameter is not APPLICATION ERROR" as an additional bullet. This is in Appendix C.7, in 2.1 and 2.1.1 as well as Appendix C.2, C.3, and C.8 in 2.0 and 2.0.1	2.0 2.0.1 2.1 2.1.1	06 Nov 2017
Update Return_Code_Type enumeration to match order defined in the ARINC 653 Standard	For technical standard editions 2.1 and 2.1.1, Appendix B.2, RETURN_CODE_TYPE, ADDR_IN_USE and PERMISSION_DENIED enumerations should be moved the TIMED_OUT enumeration, preserving the order defined in the ARINC 653 standard, as follows. enum RETURN_CODE_TYPE { NO_ERROR, //! request valid and operation performed NO_ACTION, //! status of system unaffected by request NOT_AVAILABLE, //! no message was available INVALID_PARAM, //! invalid parameter specified in request INVALID_CONFIG, //! parameter incompatible with configuration INVALID_MODE, //! request incompatible with current mode TIMED_OUT, //! the time expired before the request could be filled ADDR_IN_USE, //! address currently in use PERMISSION_DENIED,//! no permission to send or connecting to wrong partition MESSAGE_STALE, //! current time - timestamp exceeds configured limits CONNECTION_IN_PROGRESS, //! asynchronous connection in progress CONNECTION_CLOSED, //! connection was closed DATA_BUFFER_TOO_SMALL //! Data Buffer was too small for message };	2.1 2.1.1	06 Nov 2017
Obtaining message size and socket status cannot be performed through any defined sockets API	For technical standard editions 2.1 and 2.1.1. The requirement for an Operating System to get the socket size or socket error status is removed. For conformance to the technical standard editions 2.1 and 2.1.1 requirements in Section 3.11 items 10.b and 10.c are removed.	2.1 2.1.1	06 Nov 2017
Setting of Time zone should be visible to local partition/POSIX process only	For conformance to the technical standard editions 2.1 and 2.1.1 UoCs may use the following changes to the technical standard text: 3.1.1 Requirement 12 part e, remove the parenthetical "(including time zone)" 3.11.4 In the third paragraph, remove the last sentence "Partitions authorized to set the calendar time are also authorized to set the time zone value that is visible to all other partitions."	2.1 2.1.1	06 Nov 2017
const_reverse_iterator not supported	For non-OSS UoC tests in Conformance Test Suite versions utilizing C++ CTS 2.1.1r1, 2.1.0r5 and prior, the Test Suite in correctly defines the operator*() operation for reverse_iterator class. The operation should have a return type of "reference" and not "Iterator" (line 204 of <iterator>). For a non-OSS UoC utilizing C++, replace the <iterator> file found in the "\goldStandardLibraries\C++\src\OSS\libstdc++\general" directory with the attached <iterator> file.	2.1 2.1.1	01 Mar 2018
Align fields within FAULT_STATUS_TYPE to align with ARINC 653 Standard	For technical standard editions 2.1 and 2.1.1, Appendix C.2, the FAULT_STATUS_TYPE structure FAULT_MESSAGE_TYPE element is moved to the end as follows: struct FAULT_STATUS_TYPE { FAULT_CODE_TYPE CODE; FAULT_MESSAGE_SIZE_TYPE LENGTH; THREAD_ID_TYPE FAILED_THREAD_ID; SYSTEM_ADDRESS_TYPE FAILED_ADDRESS; FAULT_MESSAGE_TYPE MESSAGE; };	2.1 2.1.1	06 Nov 2017
Add CAN Bus to the FACE Technical Standard	Suppliers wishing to use/provide a CAN Bus IO messages portable to other implementations of CAN Bus IO Services should follow the modifications to the 2.1 Technical Standard presented in the Approved Correction Attachment "PR190-CAN BUS Messages for FACE_v2.docx"	2.1.1	15 Aug 2018
Referenced version of ISO/IEC 8652:1995 is not the intended Ada 95 reference	For FACE Technical Standard Editions 2.0, 2.0.1, 2.1 and 2.1.1, the Ada 95 reference in the Normative References section incorrectly references the Amendment 1:2007. All references to Ada 95 should be “ANSI/ISO/IEC 8652:1995: Ada Reference Manual”	2.0 2.0.1 2.1 2.1.1	06 Nov 2017
std::div is incorrectly tested as part of cmath	For OSS UoC tests in Conformance Test Suite Versions CTS 2.1.1r1, 2.1.0r5 and prior, the Test Suite is incorrectly testing for std::div in cmath when C++ programming language is selected for all FACE OS Profiles. For an OSS UoC configured with C++ in the referred Conformance Test Suite versions, the "Testing definition of div" Conformance Test Suite result under the "cmath Tests" heading in the Conformance Test Results should be considered an acceptable failure.	1.0 1.1 2.0 2.1 2.1.1	01 Mar 2018
POSIX Partitions Include Subset of ARINC 653 not Entire API	For OSS UoC tests in Conformance Test Suite versions CTS 2.1.1r1, 2.1.0r5 and prior, the Test Suite is testing all POSIX and ARINC 653 APIs specified in the FACE Technical Standard when an OS Partition of “POSIX+ARINC 653” was selected. This case tested by the Conformance Test Suite does not match the specification of an OSS UoC by the Technical Standard. The Technical Standard specifies three configurations for an OS Partition: POSIX only, ARINC 653 only and POSIX with a minimum set of ARINC 653 APIs to support inter-partition communication and health monitoring. For an OSS UoC configured with a “POSIX + ARINC 653” OS Partition option in the referred Conformance Test Suite versions, the following Conformance Test Suite results under the “ARINC 653 Conformance Tests” heading in the Conformance Test Results should be considered acceptable failures: - BLACKBOARD Tests - BUFFER Tests - EVENT Tests - FILE_SYSTEM Tests - MEMORY_BLOCK Tests - PARTITION Tests - PROCESS Tests - SEMAPHORE Tests - TIME Tests For any OSS UoC supporting ARINC 653 operating environments (in addition to the POSIX operating environment) the Test Suite should be executed twice, once for each operating environment. The POSIX operating environment should be tested using the “POSIX + ARINC 653” OS Partition option.	1.0 1.1 2.0 2.1 2.1.1	06 Nov 2017
Misspelled functions in the OpenGLSC101 gl.h and gl.c files.	For PCS and PSSS UoC OpenGL tests in the Safety Base and Safety Extended Sub-Profiles in Conformance Test Suite versions CTS 2.1.1r1, 2.1.0r5, and prior, the Test Suite contains a misspelled function in the header and source files for OpenGLSC101 ("glTexEnvi" is incorrectly declared as "glTextEnvi"). For a PCS or PSSS UoC testing OpenGL in the Safety Base or Safety Extended Sub-Profiles, replace the attached gl.h and gl.c files into the following directories: FACEConformanceTestSuite-2.1.1r1/goldStandardLibraries/C/src/OSS/OpenGLSC101/safetyBase/GL FACEConformanceTestSuite-2.1.1r1/goldStandardLibraries/C/src/OSS/OpenGLSC101/safetyExt/GL FACEConformanceTestSuite-2.1.1r1/goldStandardLibraries/C++/src/OSS/OpenGLSC101/safetyBase/GL FACEConformanceTestSuite-2.1.1r1/goldStandardLibraries/C++/src/OSS/OpenGLSC101/safetyExt/GL	1.0 1.1 2.0 2.1 2.1.1	01 Mar 2018
EGL is broken when testing in Safety Profiles	For PCS and PSSS UoC tests using OpenGL SC and EGL1.2 in the Safety Base and Safety Extended sub-profiles in Conformance Test Suite version CTS 2.1.1r1, 2.1.0r5 and prior, the Test Suite does not include the EGL1.2 interfaces in the Gold Standard Library. The Technical Standard specifies that EGL 1.2 is allowed for usage in Safety Base and Safety Extended by PCS and PSSS UoC implementing graphics. For a PCS or PSSS UoC implementing OpenGL in the Safety Base and Safety Extended Profiles, the following steps outline an acceptable modification to the Conformance Test Suite for proving adherence to the FACE Technical Standard regarding usage of EGL 1.2: [1] Generate EGL Library using the General Profile on the CTS GUI for C/C++. - Select “General Profile” - Select “OpenGL ES with EGL” - “Generate Gold Standard Libraries” and pick a directory to save the EGL library file [2] Copy the EGL headers from the general folder into safetyBase and safetyExt folders under "/goldStandardLibraries". - Copy /goldStandardLibraries/C++/src/OSS/EGL12/general /goldStandardLibraries/C++/src/OSS/EGL12/safetyExt - Copy /goldStandardLibraries/C++/src/OSS/EGL12/general /goldStandardLibraries/C++/src/OSS/EGL12/safetyBase - Copy /goldStandardLibraries/C/src/OSS/EGL12/general /goldStandardLibraries/C/src/OSS/EGL12/safetyExt - Copy /goldStandardLibraries/C/src/OSS/EGL12/general /goldStandardLibraries/C/src/OSS/EGL12/safetyBase [3] Compile the PCS/PSSS UoC by using the EGL path for safetyBase and safetyExt from [2]: gcc -std=c99 -fno-builtin -nostdinc -Iinclude -Iinclude/face/dm -I../../goldStandardLibraries/C/include -I../../compilerSpecific/C/systemLibraryDefinitions/ -I../../goldStandardLibraries/C/src/OSS/POSIX/safetyBase/ -I../../goldStandardLibraries/C/src/OSS/EGL12/safetyBase/ -o pcsEGLSampleObj.o -c src/PCS/pcsEGLSampleObj.c [4] Linking the PCS/PSSS UoC: Add the EGLLib.a to the “Object/Library Files” text boxes in PCS or PSSS tab. Make sure the EGLLib.a is after the PCS or PSSS UoC object file.	1.0 1.1 2.0 2.1 2.1.1	01 Mar 2018
std::abs is incorrectly tested as part of cmath	For OSS UoC tests in Conformance Test Suite Versions CTS 2.1.1r1, 2.1.0r5 and prior, the Test Suite is incorrectly testing for std::abs in cmath when C++ programming language is selected for the Safety and Security FACE OS Profiles. For an Safety or Security OSS UoC configured with C++ in the referred Conformance Test Suite versions, the "Testing definition of abs" Conformance Test Suite result under the "cmath Tests" heading in the Conformance Test Results should be considered an acceptable failure.	1.0 1.1 2.0 2.1 2.1.1	01 Mar 2018
CVM 2.1 row 232 contains Note that is not in the FTS 2.1	For conformance to the FACE 2.1 Technical Standard, the note in row 232 of the 2.1 CVM should be ignored. For conformance to the FACE 2.1.1 Technical Standard, the note in row 234 of the 2.1.1 CVM should be ignored.	2.1 2.1.1	01 Jan 2018
OSS HMFM Ada Interface Tests Includes Test for Implementation Dependent Interfaces and Uses Constructs from Ada 2005	For OSS UoC tests in Conformance Test Suite Versions CTS 2.1.1r1, 2.1.0r5 and prior, the Test Suite includes an Ada interface test for the size of Face_Basic_Types.Long_Double which it expects to be equivalent to the size of Interfaces.IEEE_Extended_Float. This association is made in the Technical Standard for FACE, Edition 2.1 via Section 3.18.4 ("IDL to Ada Mapping") and the section's reference to "OMG IDL Ada Language Mapping Version 1.3" maps types from FACE IDL to CORBA to Ada. While the Face_Basic_Types.Long_Double is needed, the tests in this file rely on "Pragma Assert()" which is not included in "ANSI/ISO/IEC 8652:1995: Ada 95 Reference Manual, Language and Standard Libraries". As such, the tests in the file should be changed to account for allowable, compile-time tests. For an OSS UoC configured to be tested with Ada, the attached file should replace the corresponding file found in folder FACEConformanceTestSuite-2.1.XrX\conformanceInterfaceTests\Ada\OSS\HMFM.	1.0 1.1 2.0 2.1 2.1.1	01 Mar 2018
Use of Ada Access type in Conformance Test Suite is not compatible with "pragma Import C"	For OSS UoC tests using Ada in Conformance Test Suite Versions CTS 2.1.1r1, 2.1.0r5 and prior, the Test Suite uses the Access type in a manner that interferes with the ability for the interface in test to use an "Import C" construct. Additionally, the tests as defined could potentially bypass the normal type checking in the language. The tests should have been written in a manner that called the interfaces in test directly and not use the Access type. For an OSS UoC configured to be tested with Ada, the attached file's contents should replace the corresponding directory contents in FACEConformanceTestSuite-2.1.XrX\conformanceInterfaceTests\Ada\OSS.	1.0 1.1 2.0 2.1 2.1.1	01 Mar 2018
Some OSS CVM 2.1 Requirements were Modified From UoC Design to Fully Tested Requirement in CVM 2.1.1	For submitters seeking conformance to FACE Technical Standard Edition 2.1.1, CVM rows, 236, 237, 1468, 1755, and 1756 should be treated as "UoC Designs" when determining the artifacts used for Verification Evidence. For row 239 the submitter should ignore the misleading note. For rows 1591 and 1601, the submitter of an OSS UoC need only provide evidence in support of the Referenced Standard in addition to passing the Test Suite. For 1611, 1612, and 1613, The verification notes should refer to support of the Referenced Standard instead of the obsolete DID references (SAD/SDD). .	2.1 2.1.1	02 Jan 2018
String_var does not get generated in v2.1.0r5 and newer versions	For PCS and PSSS UoC tests in Conformance Test Suite versions CTS 2.1.1r1 and 2.1.0r5, the Test Suite does not generate headers referenced in the Gold Standard TSS when a UoP Supplied Model uses certain data types specified in the corresponding platform IDL. These headers may include one or more of the following: bigint.hpp, fixed.hpp, String_var.hpp and WString_var.hpp. For a PCS and PSSS UoC with an accompanying USM that relies on a data type found in the affected header files, modify Line 5 of the Conformance Test Suite Makefile.TSS file in the "\goldStandardLibraries\C++" directory to add a path to a directory containing the needed header files. The following is an example of what the modification would look like: Original: CFLAGS = $(FACE_CFLAGS) $(FACE_COMPILER_SPECIFIC_CFLAGS) $(FACE_TSS_CFLAGS) $(FACE_POSIX_CFLAGS) Post Modification: CFLAGS = $(FACE_CFLAGS) $(FACE_COMPILER_SPECIFIC_CFLAGS) -IPATH_TO_STRING_VAR_FOLDER $(FACE_TSS_CFLAGS) $(FACE_POSIX_CFLAGS)	2.1 2.1.1	01 Mar 2018
Self Configuring Components	The FACE Technical Standard Editions 2.0, 2.0.1, 2.1, and 2.1.1 make no mention of local configuration and only provides specific requirements on UoC use of a Centralized Configuration Service. It was not the intent of the FACE Technical Standard to limit configuration to Centralized Configuration. Section 3.15 should be interpreted to include the following statement: UoC use of file services from the OSS API for accessing configuration files is permitted by any UoC.	2.0 2.0.1 2.1 2.1.1	28 Jun 2018
FACE_sequence_return incorrectly defines FACE_STRING_NULL_THIS	For Technical Standard edition 3.0; Appendix K.1.3 FACE_sequence Specification, the "FACE_STRING_NULL_THIS" enumeration value should be changed to "FACE_SEQUENCE_NULL_THIS" in the "FACE_sequence_return" enumeration type.	3.0	01 Mar 2018
Additional OSS Conformance Artifact Requirements In CVM 2.1.1 not present in CVM 2.1	For conformance to the FACE Technical Standard 2.1, CVM Row 1648 should have the same Verification Note and Conformance Artifacts as CVM Row 1635. A Code Inspection Test is sufficient to verify proper use of pragma. Use of pragma is not applicable to OSS UoCs. For conformance to FACE Technical Standard 2.1.1, CVM Rows 1520, 1562, 1591 and 1626: * the Conformance Artifacts should be "Referenced Standards" and "Test Suite" * the Verification Note should "Test Suite verifies the provision of the Standard Run-Time Libraries. For conformance to FACE Technical Standard 2.1.1, CVM Row 1613: * The FACE Segment column should be OSS only. * Conformance Artifacts should be "Referenced Standards" and "UoC Designs" * the Verification Note should be removed. For conformance to FACE Technical Standard 2.1.1, CVM Row 1636: * Conformance Artifacts should be "Referenced Standards" and "UoC Designs" * The Verification Note should be removed.	2.1 2.1.1	01 Mar 2018
Extend setsockopt API support to allow TCP protocol option for Safety Extended and General Purpose POSIX OSS Profiles	FACE Technical Standard Section 3.2.1.2 includes the lead topic of: "For General Purpose and Safety Extended POSIX implementations: 1. An OSS UoC implementing POSIX shall support via setsockopt() the configuration of: a. A TCP socket such that small packets are not delayed (TCP_NODELAY) 2. An OSS UoC shall provide the following configuration information via getsockopt() for the specified socket: a. The TCP small packet delay characteristics for a socket (TCP_NODELAY). " The CTS must be updated to include the TCP_NODELAY constant in the General Purpose and Safety Extended Profiles to support TCP. RIG 3.0 addresses the complete set of POSIX constants including these and related constants needed to use TCP_NODELAY in a function call.	3.0	18 Jul 2018
Template Instantiation Naming Patterns	In FACE Technical Standard 3.0 four FACE interfaces have a requirement describing the result of IDL template module instantiation. These four requirements do not apply consistent rules and lack specificity needed to ensure multiple IDL template module instantiations are deconflicted. This correction addresses these problems. Section 3.8.4.1, requirement 4 should read as follows: The fully-qualified IDL scope of the TS Typed module bound to DATATYPE_TYPE via IDL template module instantiation shall be FACE::TSS::<DATATYPE_MODEL_NAME>::<DATATYPE_TYPE>::TypedTS. Note: DATATYPE_MODEL_NAME is the name of the DataModel element containing DATATYPE_TYPE as a View. DATATYPE_TYPE is the short name, not fully qualified. Note: The resulting declarations follow programming language mapping rules as if the interface was declared in a directory tree and IDL file as FACE/TSS/<DATATYPE_MODEL_NAME>/<DATATYPE_TYPE>/TypedTS.idl. Section 3.8.4.1, requirement 10 should read as follows: The fully-qualified IDL scope of the TS Type-Specific Extended Type module bound to DATATYPE_TYPE and RETURN_DATATYPE via IDL template module instantiation shall be FACE::TSS::<DATATYPE_MODEL_NAME>::<DATATYPE_TYPE>_<RETURN_DATATYPE>::TypedTS Note: DATATYPE_MODEL_NAME is the name of the DataModel element containing DATATYPE_TYPE as a View. DATATYPE_TYPE and RETURN_DATATYPE are the short names, not fully qualified. Note: The resulting declarations follow programming language mapping rules as if the interface was declared in a directory tree and IDL file as FACE/TSS/<DATATYPE_MODEL_NAME>/<DATATYPE_TYPE>_<RETURN_DATATYPE>/Extended.idl. Section 3.11.4.1, requirement 4 should read as follows: The fully qualified IDL scope of the Injectable module bound to INTERFACE_TYPE via IDL template module instantiation shall be <fully qualified INTERFACE_TYPE> concatenated with “_Injectable”. Note: The resulting declarations follow programming language mapping rules as if the interface was declared in a directory tree and IDL file where the IDL file is the interface IDL file name with the “.idl” extension replaced with “_Injectable.idl”, e.g., FACE/Configuration_Injectable.idl FACE/TSS/Base_Injectable.idl FACE/IOSS/Generic_Injectable.idl FACE/TSS/<DATATYPE_MODEL_NAME>/<DATATYPE_TYPE>/TypedTS_Injectable.idl Section 3.13.5, requirement 5 should read as follows: The fully-qualified IDL scope of the Stateful module bound to REQUESTED_DATA_TYPE and REPORTED_DATA_TYPE via IDL template module instantiation shall be FACE::LCM::<DATATYPE_MODEL_NAME>::<REQUESTED_DATA_TYPE>_<REPORTED_DATA_TYPE>::Stateful Note: DATATYPE_MODEL_NAME is the name of the DataModel element containing REQUESTED_DATA_TYPE as a View. REQUESTED_DATA_TYPE and REPORTED_DATA_TYPE are the short names, not fully qualified. Note: The resulting declarations follow programming language mapping rules as if the interface was declared in a directory tree and IDL file as FACE/LCM/<DATATYPE_MODEL_NAME>/<REQUESTED_DATA_TYPE>_<REPORTED_DATA_TYPE>/Stateful_Injectable.idl.	3.0	06 Sep 2018
Define rules for IDL-generated file names	see attachment D8 in submitter input - describes rules for the generated output of IDL for filenames, and renames many IDL files to achieve desired result	3.0	25 Sep 2019
Ensure Data Model name is restricted or can be mapped into all programming languages	Restrict the model names to be valid in all programming languages. Current OCL constraints ensure the DataModel name is a valid identifier via the isValidIdentifier() constraint. Ensure DataModel names are not IDL reserved words by applying not isReservedWord() constraint to Elements. This was an oversight in the FACE Technical Standard and simply requires an OCL update. Update the relevant OCL in the Technical Standard to read: package face::datamodel context DataModel /* * Every Element in an DataModel has a unique name. */ inv hasUniqueName: let children : Bag(String)= self.cdm->collect(name.toLowerCase())->union( self.pdm->collect(name.toLowerCase())->union( self.ldm->collect(name.toLowerCase()))) in children->size() = children->asSet()->size() /* * A DataModel's name is not an IDL reserved word. */ inv nameIsNotReservedWord: not Element::isReservedWord(self.name) endpackage	3.0	25 Sep 2019
Improve Consistency of General Purpose POSIX Profile in Appendix A.1	Add a new row to Table 20 in Section A.1 and add the getlogin_r() API to this row with markings that it is "INCL" (included) for the General Purpose Profile. For the getlogin() API row, remove the "INCL" indication to document it is no longer applicable to the General Purpose Profile (the new getlogin_r() will be supported instead). For the setbuf() API row, remove the "INCL" indication to document it is no longer applicable to the General Purpose Profile (the existing setvbuf() function can be used instead and is a safer selection in that it includes a parameter that defines the buffer length).	3.0	18 Jul 2018
Add Additional POSIX APIs as applicable to all FACE Profiles to Improve Alignment with SCA	For conformance to FACE Technical Standard Edition 3,0, the Security, Safety Base, and Safety Extended columns in Table 20 of Section A.1 should be updated to indicate that the following APIs are "INCL" (included) as part of these POSIX profiles (Inter-UoC column is not impacted): exp2() log2() round() trunc() isblank()	3.0	15 Aug 2018
FACE::String Missing Constructor for Constant Strings	FACE Technical Standard Edition 3.0 does not support creating a string instance from a C-style string literal in either C or C++. This approved correction adds support for this use case. For C, Section K.1.4 should be read to include the following declaration: /** * @brief Unmanaged initialization from a C-string literal * @details After initialization, @p this_obj does not manage its own data, * but instead serves as a wrapper to the data pointed to by @p src. * * This function has exactly the same behavior, preconditions, and possible * return codes as calling FACE_string_init_unmanaged where the values for * @p length and &p bound are both strlen(&p src). * * The motivation for this function is to initialize a FACE_string from a * C-string literal. C-string literals are often stored in read-only memory. * Calling a FACE_string interface function that modifies the string value on a * string instance that was initialized from read-only memory results in * implementation-defined behavior such as as access violation. * * @param this_obj a pointer to the FACE_string to be initialized * @param src pointer to externally managed memory */ FACE_string_return FACE_string_init_unmanaged_cstring( FACE_string* this_obj, char* src ); For C++, Section K.2.3 should be read to include the following declaration: /** * @brief Unmanaged C-string literal constructor * @details After successful construction, this String does not manage its own * data, but instead serves as a wrapper to the data pointed to by @p str. * * This constructor has no &p return_code parameter to facilitate construction * of temporary FACE::String objects to encapsulate C-string literals as * arguments to FACE interface operations. * * The motivation for this function is to initialize a FACE::String from a * C-string literal. C-string literals are often stored in read-only memory. * Calling a FACE::String interface function that modifies the string value on a * string instance that was initialized from read-only memory results in * implementation-defined behavior such as as access violation. * * Preconditions: * - str != NULL * When calling this function, if any of these preconditions are false, * - this String is put into the invalid state * * Upon successful construction: * - length() returns the value of strlen(&p str) at time of construction * - capacity() returns the value of strlen(&p str) at time of construction * - bound() returns the value of strlen(&p str) at time of construction * - buffer() returns the value of &p str at time of construction * * @param str A NUL-terminated string. */ String(const char *str);	3.0	15 Aug 2018
Initialize(LCM::Initializable) cannot use Configuration Interface	FACE Technical Standard Edition 3.0 erroneously suggests the FACE Configuration Interface can be used in an implementation of Initialize(LCM::Initializable). This approved correction corrects this error and clarifies the distinction between Initialize(LCM::Initializable) and Configure(LCM::Configurable). In Section D.2.1, the declaration of FACE::LCM::Initializable::InitializableInstance::Initialize should be read as: void Initialize( out RETURN_CODE_TYPE return_code); thereby removing the parameter of type CONFIGURATION_RESOURCE. Replace the first two paragraphs of Section D.2.1 as follows: The Initialize(LCM:: Initializable) function supports the distinct execution point of initialization. This function is an entry point into a Managed UoC instance, providing the instance with a thread of control to perform any appropriate behaviors at this execution point. It is intended to be called once transactionally, meaning called until a return code other than IN_PROGRESS is returned. It is common in embedded systems and safety-critical systems to have a phase of execution for resource acquisition behavior, such as memory allocation, that is prohibited in later phases. LCM Services supports a two-stage resource acquisition process. The first stage, associated with the initialization execution point and hence the Initialize(LCM:: Initializable) function, supports resource acquisition that does not require the Configuration Interface. The second stage, associated with the configuration execution point and hence the Configure(LCM::Configurable) function, supports leveraging the Configuration Interface when acquiring resources. Between the two execution points is when dependencies are resolved between interface users and interface providers via the Injectable Interface. Section D.3.1 should be read with the following as the second paragraph: It is common in embedded systems and safety-critical systems to have a phase of execution for resource acquisition behavior, such as memory allocation, that is prohibited in later phases. LCM Services supports a two-stage resource acquisition process. The first stage, associated with the initialization execution point and hence the Initialize(LCM:: Initializable) function, supports resource acquisition that does not require the Configuration Interface. The second stage, associated with the configuration execution point and hence the Configure(LCM::Configurable) function, supports leveraging the Configuration Interface when acquiring resources. Between the two execution points is when dependencies are resolved between interface users and interface providers via the Injectable Interface.	3.0	15 Aug 2018
C++ Sequence default constructor describes wrong bound	FACE Technical Standard Edition 3.0 erroneously describes the wrong contract for the default constructor of a C++ Sequence. This approved correction corrects this error. In Section K.2.2, the @brief comment for the default Sequence constructor should be read as follows: * @brief Default constructor - creates empty managed unbounded Sequence	3.0	15 Aug 2018
C/C++ Mapping for IDL array should not mention slice	FACE Technical Standard Edition 3.0 erroneously describes a slice as part of the IDL array mapping to C and to C++. This approved correction corrects this error with no change to the mapping rules. In Section 3.14.7.8, the paragraph should be read as: An array in IDL maps to a C-style array of the same dimension. The name of the array is the scoped name of the IDL array as described in Section 3.14.7.1; the C array type’s mapping is specified in the IDL type’s relevant section. In Section 3.14.8.9, the paragraph should be read as: An array in IDL maps to a typedef C-style array of the same name and dimension. The array type’s mapping is specified in the IDL type’s relevant section. CVM 3.0 should be read as follows: Row ID 1481 should be read to match the new paragraph in Section 3.14.7.8 above. Row ID 1601 should be read to match the new paragraph in Section 3.14.8.9 above.	3.0	15 Aug 2018
Licensing category for Open Source	A new option "Open Source" has been added to the metadata table as a licensing category. Note to Submitter: In order to see the new option, please refresh the metadata table, since these changes will not be reflected for UoCs until the UoC Categories are updated to this latest version of the metadata template.		28 May 2018
Default definitions of C++ new need to be included	For FACE Technical Standard Edition 3.0 - The user should read Section 3.2.3.3.3 as if the following note were included. Note: The intention is to provide the single object and array allocation functions. However, no allocators are allowed to throw an exception. A failing new operation that returns to the caller should return NULL. The first version of the 3.0 CTS will provide these allocation methods in addition to the ones which do not throw exceptions per the C++ standard. void* operator new ( std::size_t count ); void* operator new[]( std::size_t count );	3.0	18 Jul 2018
Directionality of transaction_id argument to Send_Message_Callback()	For conformance to the FACE Technical Standard, Edition 3.0, the name of the TSS Send_Message_Callback (section E.3.4, E3.4.3) should be replaced with Send_Message_Async and the name of Blocking_Send_Message (section E.3.4, E.3.4.2) should be replaced with Send_Message_Blocking. The same would be true for section E.4.1 - type abstraction. The description of transaction ID in E.3.2.1, E.3.2.2, E.3.2.3, E.3.4.1, and E.3.4.3 will be updated.	3.0	20 Dec 2018
IDL to C++ Mapping of Enumerations	FACE Technical Standard Edition 3.0 does not precisely state the rationale for the IDL enumeration mappings to C++. This approved correction restates the rationale without changing the C++ mapping rules. The narrative text in Section 3.14.8.8.2 should be read as: An IDL enumeration maps to a C++ enum whose literals are specified with the same name and in the same order as in IDL. The C++ enum is named Value and is wrapped in a struct with the same name as the IDL enum. The struct provides an encapsulating scope in order to reduce the chance for enumerator collisions in scopes with many enumeration declarations, as may occur with TSS message types contained in a USM. The struct has a private constructor declaration with no definition to prohibit construction.	3.0	27 Sep 2018
Directionality of buffer argument to Configuration::Read()	To achieve FACE Conformance, the Read(CONFIG) Function in Section G.2.4 should read: /* IDL declaration */ module FACE { interface Configuration { void Read ( in HANDLE_TYPE handle, in SET_NAME_TYPE set_name, in SYSTEM_ADDRESS_TYPE buffer, in BUFFER_SIZE_TYPE buffer_size, out BUFFER_SIZE_TYPE bytes_read, out RETURN_CODE_TYPE return_code); }; };	3.0	27 Sep 2018
Component State Persistence arguments are incorrect	For conformance to the FACE Technical Standard, edition 3.0 the "out DATA_ID_TYPE data_id" parameter in the CSP Create method (Section E.3.5, E.3.5.4) should be replaced by "in DATA_ID_TYPE data_id". Additionally, the INVALID_PARAM should be returned from Read, Update, or Delete to indicate when the data type has not been previously created. void Create ( in GUID_TYPE uop_id, in DATA_STORE_TOKEN_TYPE token, in DATA_ID_TYPE data_id, in DATA_BUFFER_TYPE data, out RETURN_CODE_TYPE return_code);	3.0	27 Sep 2018
Directionality of buffer argument to TSS::CSP::Read()	For conformance to the FACE Technical Standard, Edition 3.0 the "in DATA_BUFFER_TYPE data" parameter in the CSP Read method (Section E3.5, E3.5.5) should be replaced by "inout DATA_BUFFER_TYPE data". void Read ( in GUID_TYPE uop_id, in DATA_STORE_TOKEN_TYPE token, in DATA_ID_TYPE data_id, inout DATA_BUFFER_TYPE data, out RETURN_CODE_TYPE return_code);	3.0	27 Sep 2018
Make POSIX Processes Optional in Safety Extended and General Purpose Profiles	To achieve FACE Conformance, the VA and CTS users should ignore failures indicating the optional methods are not provided for the methods described in the attached document. There is precedence for the VA to ignore false negatives from the CTS.	3.0	14 Nov 2018
Output Filename Unspecified in IDL to Ada Mapping	FACE Technical Standard Edition 3.0 ambiguously provides no criteria for producing Ada source files from IDL source files via the Ada programming language mappings. This approved correction clarifies this ambiguity that could impact portability across toolchains. The approved correction language is provided in the document attachment. (https://ticketing.facesoftware.org/face_search_bug_view.php?id=332)	3.0	27 Sep 2018
Output Filename Unspecified in IDL to Java Mapping	FACE Technical Standard Edition 3.0 ambiguously provides no criteria for producing Java source files from IDL source files via the Java programming language mappings. This approved correction clarifies this ambiguity that could impact portability across toolchains. The approved correction language is provided in the document attachment. (https://ticketing.facesoftware.org/face_search_bug_view.php?id=335)	3.0	27 Sep 2018
Directionality of message argument to Receive_Message(TS Type Abstraction)	For conformance to the FACE Technical Standard, Edition 3.0, the message parameter of the Type Abstraction’s Receive_Message is defined as an “inout” in place of “out” (E4.1).	3.0	14 Nov 2018
FACE Conformance of Code Generated Variants	For certification to Edition 2.1.1, Edition 3.0, or Edition 3.1 of the FACE Technical Standard, Transport Service UoCs providing the Type Specific Interface that use a process for adding new message types can obtain FACE Certification and keep that certification as message types are added. A TSS UoC can maintain certification as message types are added using a process defined as part of the certification. That process must: 1) be proven to generate FACE Conformant additions when used within its limitations, and 2) be used for the addition of the new message types. The attached document provides the information that the Software Supplier must produce for submittal to their Verification Authority and other parts of the FACE Conformance Program. For the purposes of this Approved Correction, the definition of a "Unit of Conformance Variant" as expressed in the Conformance Policy shall include the process for generation of new data types for TSS APIs and Processing. Future updates to the Conformance Policy, Conformance Guide, or Technical Standard may formalize this for a greater set of code generation practices. Unit of Conformance Variants are versions of a Unit of Conformance generated to a specific set of functionality and target environment from the same Unit of Conformance source code.	2.1.1 3.0 3.1	08 Jul 2020
Java conformance for Tech Std, CVM & Conformance Test Suite	For conformance to FACE Technical Standard, Edition 2.1 and 2.1.1, read with the following changes: • Referenced Documents, Normative References, Paragraph 1: Delete the last sentence in the first paragraph. The sentence to be removed is: “All standards are subject to revision, and parties to agreements based on FACE requirements are encouraged to investigate the possibility of applying the most recent editions of the standards listed below.” • Referenced Documents Page XXIV: Change Java SE 6 Reference : Java Platform Standard Edition (Java SE 8) Specification, Version 8, March 2014 • Section 3.12.2.4, #2: bullet updated to read: “Programming language features described in Java Platform, Standard Edition 8 (Java SE 8)” • Section 3.12.3.4, #1: bullet updated to read: “Programming language features described in Java Platform, Standard Edition 8 (Java SE 8)”	2.1 2.1.1	20 Dec 2018
OSGi conformance for Tech Std, CVM & Conformance Test Suite	For conformance to FACE Technical Standard, Edition 2.1 and 2.1.1, read with the following changes: • Referenced Documents, Normative References: o change OSGi, version 4.3 to OSGi, Release 7, April 2018 (www.osgi.org/release7) • Section 3.13.2, paragraph 2: change to: The framework shall be comprised of the OSGi API described in OSGi Service Platform Release 7 Core. • Section 3.13.3, paragraph 2: change to: The framework shall be comprised of the OSGi API described in OSGi Service Platform Release 7 Core.	2.1 2.1.1	20 Dec 2018
CVM 3.0 Correction on PCS/PSSS IPC Restrictions	CRs 347, 349, 350, 351, 352, and 353 are related and the approved correction for CR 350 applies to all. Please reference the latest version of the attached Word document. (https://ticketing.facesoftware.org/face_approved_correction_published_view.php?id=350&tab=approved_correction&face_table=approved_correction)	3.0	27 Sep 2018
IOS Has No Requirement to Adhere to OSS Profile	CRs 347, 349, 350, 351, 352, and 353 are related and the approved correction for CR 350 applies to all. Please reference the latest version of the attached Word document. (https://ticketing.facesoftware.org/face_approved_correction_published_view.php?id=350&tab=approved_correction&face_table=approved_correction)	3.0	27 Sep 2018
Restrict mmap() Use to Shared Memory in Security and Safety Profiles	CRs 347, 349, 350, 351, 352, and 353 are related and the approved correction for CR 350 applies to all. Please reference the latest version of the attached Word document. (https://ticketing.facesoftware.org/face_approved_correction_published_view.php?id=350&tab=approved_correction&face_table=approved_correction)	3.0	27 Sep 2018
fork/exec Usage Restriction Lost	CRs 347, 349, 350, 351, 352, and 353 are related and the approved correction for CR 350 applies to all. Please reference the latest version of the attached Word document. (https://ticketing.facesoftware.org/face_approved_correction_published_view.php?id=350&tab=approved_correction&face_table=approved_correction)	3.0	27 Sep 2018
Appendix A.6 not Referenced in Requirements	CRs 347, 349, 350, 351, 352, and 353 are related and the approved correction for CR 350 applies to all. Please reference the latest version of the attached Word document. (https://ticketing.facesoftware.org/face_approved_correction_published_view.php?id=350&tab=approved_correction&face_table=approved_correction)	3.0	27 Sep 2018
Restrict posix_devctl() and select() related APIs to Sockets	CRs 347, 349, 350, 351, 352, and 353 are related and the approved correction for CR 350 applies to all. Please reference the latest version of the attached Word document. (https://ticketing.facesoftware.org/face_approved_correction_published_view.php?id=350&tab=approved_correction&face_table=approved_correction)	3.0	27 Sep 2018
Update the hasUniqueID constraint	In the FACE Technical Standard, Edition 3.0, the hasUniqueID constraint should be read as: /* * A Conceptual Entity contains a Composition whose type * is an Observable named 'Identifier'. */ inv hasUniqueID: self.getAllCharacteristics() ->selectByType(Composition) ->collect(type) ->exists(a | a.oclIsTypeOf(Observable) and a.name = 'Identifier')	3.0	14 Nov 2018
Add fdopen() POSIX APIs to Safety Extended Profile to Improve Alignment with SCA	For conformance to the FACE Technical Standard, The Safety Extended column in Table 20 of Section A.1 should indicate the following APIs are "INCL" (included) as part of the FACE Safety Extended POSIX Profile: fdopen()	3.0	14 Nov 2018
LCM Does Not Apply to OSS	For Conformance to the FACE Technical Standard, Table 8 (FACE Interfaces Requiring UoC to Provide Injectable Interface) does not include the OSS yet. Section 3.1.2 imposes LCM requirements on the OSS. These requirements should be ignored. Item 10 in Section 3.1.1 should also be ignored. “10. When the Injectable Interface is provided by an OSS UoC, the Interface shall be in accordance with Section 3.11.4.1.”	3.0	14 Nov 2018
Some CVM 3.0 Rows Contain Incorrect Table References	For conformance to the FACE 3.0 Technical Standard, table references in the 3.0 CVM that do not align with the corresponding text in the FACE 3.0 Technical Standard should be read as containing the reference in the technical standard.	3.0	13 Dec 2018
POSIX OS support for ARINC 653 defined configuration data types.	For conformance to the FACE 2.0 Technical Standard, the “Conditional Reqs” column in row 251 of the 2.0 CVM should be read as containing “ARINC 653”. For conformance to the FACE 2.0.1 Technical Standard, the “Conditional Requirements” column in row 253 of the 2.0.1 CVM should be read as containing “ARINC 653”. For conformance to the FACE 2.1 Technical Standard, the “Conditional Reqs” column in row 218 of the 2.1 CVM should be read as containing “ARINC 653”. For conformance to the FACE 2.1.1 Technical Standard, the “Conditional Requirements” column in row 220 of the 2.1.1 CVM should be read as containing “ARINC 653”.	2.0 2.0.1 2.1 2.1.1	13 Dec 2018
Java TSS Conformance for DDS (Data Distribution Standard)	For conformance to FACE Technical Standard 2.1.1, CTS errors with respect to the Holder classifier not implementing the Streamable or Helper interfaces can be ignored.	2.1.1	19 Jan 2019
isEquivalentEntityTemplate return false positives	For Conformance to the FACE Technical Standard, Edition 3.0 read the OCL constraints as if the ‘isEquivalentEntityTemplate’ OCL constraint is deleted from platform.ocl and the ‘equivalentEntityTemplateHasNoQuery’ OCL constraint is deleted from platform.ocl. Also read the the template_specification Rule of the Template Rules as if the following two rules are added under the existing "If main_template_method_decl is a main_equivalent_entity_type_template_method_decl, then:" A. The boundQuery of the Template whose specification is this template_specification must not be set. B. The effectiveQuery of the Template whose specification is this template_specification must not be set. Under condition "If main_template_method_decl is a main_entity_type_template_method_decl, then": Add rule: C. The boundQuery of the Template whose specification is this template_specification must be set.	3.0	20 Dec 2018
getservbyport() and getservent() should be marked Yes for IPC	For conformance to the FACE Technical Standard, Edition 2.1 and 2.1.1, read the list of API calls in E.4 as including getservbyport() and getservent(). For conformance to the FACE Technical Standard, Edition 3.0, read Table 20 in A.1 as having the "Inter-UoC" column marked "YES" for getservbyport() and getservent(). By marking this as "YES", additional review during conformance is required.	2.1 2.1.1 3.0	20 Dec 2018
pselect() is an IPC method but not in IPC restricted (limited) GSL libraries	For the purposes of conformance to FACE Technical Standard 2.1, the list of restricted IPC methods in Appendix E.4 should be read as including pselect().	2.1 2.1.1	20 Dec 2018
socketpair() is an IPC method but not in IPC restricted (limited) GSL libraries	For the purposes of conformance to FACE Technical Standard 2.1, section E.4 should be read as including socketpair() in the list of restricted IPC methods.	2.1 2.1.1	20 Dec 2018
mq_timedreceive and mq_timedsend not included as IPC methods	For conformance to the FACE Technical Standard, Edition 2.1 and 2.1.1, read the list of API calls in E.4 as including mq_timedreceive and mq_timedsend.	2.1 2.1.1	20 Dec 2018
CTS Incorrectly Flags Java UoC usage of Inherited Methods	For non-OSS UoC testing with Java in Conformance Test Suite versions CTS 2.1.1r3, 2.1.0r7 and prior, the Test Suite does not attribute inherited methods for use by a derived class, whether the derived class is in the Java API or the UoC's Java source. A subsequent occurrence of this anomaly while testing a UoC's supplied class files will maintain the following pattern: "Access to method METHOD_NAME_AND_SIGNATURE in class CHILDMOST_CLASS was requested. Checking for method existence. Error: Method not found". For a non-OSS UoC using Java in the referred Conformance Test Suite versions, if the supplier can show evidence of the method in question being accessible as part of the Java API inheritance hierarchy, then the associated Conformance Test Result should be considered an acceptable failure.	2.1 2.1.1	19 Jan 2019
FACE 2.1.1 specification use of an address pointer for relaying of the I/OS Message not supported in Java	For conformance to the applicable versions of the FACE Technical Standard, the Read(I/O) signature shall map to Java as if the "data_buffer_address" parameter was declared as an inout parameter, resulting in "data_buffer_address" being of type "us.opengroup.FACE.StringHolder".	2.1 2.1.1	25 Sep 2019
Ada 2012 Runtime update/addition	For conformance to the FACE Technical Standard, Edition 3.0, sections 3.2.3.4 and 3.2.3.5 should read as in the attached PDF.	3.0	03 Sep 2019
Update Java Enterprise Edition to 8	Technical Standard 2.1, 2.1.1 For conformance to FACE Technical Standard, Edition 2.1 or 2.1.1, read with the following changes: • Referenced Documents: Change Java EE 5 Reference to: "Java Platform, Enterprise Edition (Java EE) Specification, v8 (Java EE 8), July 2017" • Section 3.12.2.4, #1: change bullet to read: “Programming language features described in Java Platform, Enterprise Edition 8 (Java EE 8)” Technical Standard 3.0 For conformance to FACE Technical Standard, Edition 3.0, read with the following changes: • Referenced Documents: Change Java EE 7 Reference to: "Java Platform, Enterprise Edition (Java EE) Specification, v8 (Java EE 8), July 2017" • Section 3.2.3.6.1, #1: bullet should read: “Programming language features described in Java Platform, Enterprise Edition 8 (Java EE 8)”	2.1 2.1.1 3.0	20 Dec 2018
Update C and C++ Library Definitions to Include POSIX_C_LANG_SUPPORT_R functions	For the purpose of conformance to FACE Technical Standard Edition 3.0, utilize the following: Section 3.2.3.2.1 C Programming Language Definition, change 2nd paragraph from “The C library functions include those defined in ANSI/ISO/IEC 9899:1999, §7 supporting the selected FACE OSS Profile. “ to “The C library functions include those defined in ANSI/ISO/IEC 9899:1999, §7 supporting the selected FACE OSS Profile and the Section A.1 FACE OSS Profile APIs whose POSIX Functionality Categories are defined as POSIX_C_LANG_SUPPORT_R. ” Section 3.2.3.3.1 C++ Programming Language Definition for General Purpose Capability Set, 2nd paragraph, change "C Library functions" to "C Library functions (including functions categorized in Section A.1 as POSIX_C_LANG_SUPPORT_R)". Section 3.2.3.3.2 C++ Programming Language Definition for Safety Extended Capability Set, 3rd paragraph, change "C Library functions" to "C Library functions (including functions categorized in Section A.1 as POSIX_C_LANG_SUPPORT_R)". 3.2.3.3.3 C++ Programming Language Definition for Safety Base and Security Capability Sets, 3rd paragraph, change "C Library functions" to "C Library functions (including functions categorized in Section A.1 as POSIX_C_LANG_SUPPORT_R)".	3.0	04 Mar 2019
Clarify IDL module mappings to Ada packages	A UoC implemented in Ada should interpret the rules for mapping IDL modules to Ada packages in Section 3.14.9.3 per the Approved Correction attachment to Ticket 397.	3.0	14 May 2019
Clarify HMFM APIs available in a POSIX operational environment	For the purpose of conformance to the FACE Technical Standard Edition 3.0: In Section 3.2.1.3 (item 7), change to "7. A Security Profile OSS UoC for a POSIX operational environment shall include support for the Health Monitoring APIs defined in Section 3.2.2 to communicate with an ARINC 653 Health Monitor." In Section 3.2.1.4 (item 6), change to "6. A Safety Profile OSS UoC for a POSIX operational environment shall include support for the Health Monitoring APIs defined in Section 3.2.2 to communicate with an ARINC 653 Health Monitor." In Section 3.2.1.5 (item 5), change to "5. When an ARINC 653 Health Monitor is used, a General Purpose Profile OSS UoC for a POSIX operational environment shall include support for the Health Monitoring APIs defined in Section 3.2.2 to communicate with an ARINC 653 Health Monitor."	3.0	04 Mar 2019
Issue with Partition test set for POSIX and ARINC653	For conformance to the FACE Technical Standard, Edition 3.0, when testing OSS POSIX partitions, failures related to the OS Segment Conformance Tests; ARINC 653 Conformance Test; ERROR APIs shall be ignored. See the attached image for the highlighted section in a CTS report.	3.0	13 Aug 2019
Cygwin Hosted Tools are Untestable on Windows Using CTS 3.0	To test an Operating System Segment UoC that provides a Cygwin GCC C/C++ toolchain hosted on Windows for conformance to FACE Technical Standard, Edition 3.0 and corrigenda, the Conformance Test Suite 3.0 shall use the installation variance described in the attachment. Other toolchains hosted on Windows and all toolchains hosted on Linux are not affected.	3.0	13 Aug 2019
CTS 3.0 ARINC 653 C/C++ Toolchain Validation Program Levies Requirements Beyond FACE TS	For conformance to the FACE Technical Standard, Edition 3.0, edit the CTS file conformancetestsuite/toolchain/verification/C/C99IncludeTest.c by deleting these lines: #include <assert.h> #include <complex.h> #include <inttypes.h> #include <setjmp.h> #include <signal.h> #include <tgmath.h>	3.0	13 Aug 2019
CTS StandardLibrariesTest.c Incorrect Implementation	For conformance to the FACE Technical Standard, Edition 3.0, the Conformance Test Suite file StandardLibrariesTest.c shall be replaced with the following implementation. ============================= #include <math.h> // double pow(double x, double y); int main(int argc, char *argv[]) { double x = 0, y = 0, z; /* * This should compile because of function prototype, * (no header required) and should link if the linker is configured * to include system libraries */ z = pow(x, y); return 0; } ============================= For conformance to the FACE Technical Standard, Edition 3.0, the Conformance Test Suite file StandardLibrariesTest.cpp shall be replaced with the following implementation. ============================= /* Using pow since sometimes math lib isn't automatically included */ #include <cmath> int main(int argc, char *argv[]) { double x = 0, y = 0, z; /* * This should compile because of function prototype, * (no header required) and should link if the linker is configured * to include system libraries */ z = pow(x, y); return 0; } =============================	3.0	13 Aug 2019
Incorrect Conditional notes	For supplier completion of the Conformance Statement the following rows of the CVM should be treated as conditional. Lines 635, 637, and 638 should be conditional on "Common Services". Line 1297 should be conditional on "Non OpenGL Driver Access".	3.0	03 Sep 2019
Configuration should be required for TS-TA Adapter in Table 7	The FACE Technical Standard, ed 3.1 section 4.8.4.1 describes TS Interface requirements for the Base and Type-Specific Interfaces. Items #1, #5, #6, #7 are associated with the Base Interface. Items #2, #3, #4, #8, #9, #10 are associated with the Type Specific Interface (including the optional Type-Specific Extended Type interface). In section 4.7.3, the TS Capability requirement #1 refers to section 4.8.4.1 without limiting the reference to the Type-specific interface requirements only. When satisfying section 4.7.3 #1, the TS Capability is only required to meet section 4.8.4.1 requirements #2, #3, #4, #8, #9, and/or #10. Note #9 and #10 are only required if the TSS UoC provides the Type-Specific Extended Typed interface. FACE Technical Standard, ed 3.1 section 4.7.3 #4 should also be read as follows: When configuration data is used, the Transport Service Capability shall be configured using the TSS Configuration Capability This applies to FACE Technical Standard ed 3.0 but references section 3.7.3 and 3.8.4.1 in place of FACE Technical Standard ed 3.1 sections 4.7.3 and 4.8.4.1 respectively	3.0	04 Nov 2019
Java Application Conformance success blocked by resolution of all Java Jar Dependencies both necessary and optional	When conformance testing Java UoCs for all current Editions of the FACE Technical Standard, the CTS may report unresolved reference errors for unused code paths in 3rd party libraries or frameworks. To eliminate these reported errors, a Software Supplier may apply software tools to eliminate the unused code from 3rd party libraries/frameworks, e.g., ProGuard. The resulting libraries/frameworks will be provided to the Verification Authority as part of the UoC for conformance testing with the CTS. A report generated from applying the software tools to remove the unused code will also be provided to the Verification Authority.	2.0 2.0.1 2.1 2.1.1 3.0 3.1	12 May 2020
Competing Statements for Mapping IDL Enumerations to Java	For conformance to FACE Technical Standard, Edition 2.1.1, the IDL to Java programming language mappings in Section 3.18.5 should be interpreted as if Section 4.7 of the OMG I2J 1.3 standard was not cited.	2.1.1	25 Sep 2019
IDL -> CTS C++ Generation of Unions	For conformance to the FACE Technical Standard, Edition 3.0 please read the following in section J.8 (pg. 459) : Rule: CompositeTemplate // This rule was manufactured to facilitate the binding specification. // It is not a production rule in the Template grammar specification. // Its Expression is not in the Template grammar, but is instead a // meta-type in the Data Architecture meta-model. Expression: face.datamodel.platform.CompositeTemplate Let: COMPOSITE_TEMPLATE = THIS // Generate IDL types for its composed member’s types For each face.datamodel.platform.TemplateComposition in %%COMPOSITE_TEMPLATE%.composition%: Let: MEMBER = face.datamodel.platform.TemplateComposition Emit: { %%MEMBER%.type% => <PlatformView> } // Now generate an IDL Struct for the CompositeTemplate Condition: If %%COMPOSITE_TEMPLATE%.isUnion% is false: Emit: "struct" %%TEMPLATE%.name% "{" Condition: If %%COMPOSITE_TEMPLATE%.isUnion% is true: Emit: "union" %%TEMPLATE%.name% "{" "switch" "(" "unsigned" "short" ")" "{" // Generate the CompositeTemplate’s members Let: CASE_NUMBER = 0 For each face.datamodel.platform.TemplateComposition in %%COMPOSITE_TEMPLATE%.composition%: Let: MEMBER = face.datamodel.platform.TemplateComposition Condition: If %%COMPOSITE_TEMPLATE%.isUnion% is true: // Increment the switch case number. Let: CASE_NUMBER = %CASE_NUMBER% + 1 Emit: "case" %CASE_NUMBER% ":" Emit: %%MEMBER%.type.name% %%MEMBER%.rolename% ";" Condition: If %%COMPOSITE_TEMPLATE%.isUnion% is true: Emit: "}" Emit: "}" ";" as Rule: CompositeTemplate // This rule was manufactured to facilitate the binding specification. // It is not a production rule in the Template grammar specification. // Its Expression is not in the Template grammar, but is instead a // meta-type in the Data Architecture meta-model. Expression: face.datamodel.platform.CompositeTemplate Let: COMPOSITE_TEMPLATE = THIS // Generate IDL types for its composed member’s types For each face.datamodel.platform.TemplateComposition in %%COMPOSITE_TEMPLATE%.composition%: Let: MEMBER = face.datamodel.platform.TemplateComposition Emit: { %%MEMBER%.type% => <PlatformView> } // Now generate an IDL Struct for the CompositeTemplate Condition: If %%COMPOSITE_TEMPLATE%.isUnion% is false: Emit: "struct" %%TEMPLATE%.name% "{" Condition: If %%COMPOSITE_TEMPLATE%.isUnion% is true: Emit: "union" %%TEMPLATE%.name% "switch" "(" "unsigned" "short" ")" "{" // Generate the CompositeTemplate’s members Let: CASE_NUMBER = 0 For each face.datamodel.platform.TemplateComposition in %%COMPOSITE_TEMPLATE%.composition%: Let: MEMBER = face.datamodel.platform.TemplateComposition Condition: If %%COMPOSITE_TEMPLATE%.isUnion% is true: // Increment the switch case number. Let: CASE_NUMBER = %CASE_NUMBER% + 1 Emit: "case" %CASE_NUMBER% ":" Emit: %%MEMBER%.type.name% %%MEMBER%.rolename% ";" Emit: "}" ";" Also read the section (pg. 465): Rule: UnionBody Expression: LEFT_BRACE UnionSwitchStatement RIGHT_BRACE Emit2: "{" Emit: <UnionSwitchStatement> Emit2: "}" as: Rule: UnionBody Expression: LEFT_BRACE UnionSwitchStatement RIGHT_BRACE Emit: <UnionSwitchStatement>	3.0	15 Apr 2020
FACE 3.0 CVM contains rows marked for verification without populating FACE Segment	For conformance to the FACE Technical Standard, Edition 3.0, the Conformance Verification Matrix should be read as though rows 232 and 235 populate the "FACE Segment" column with "OSS" value.	3.0	21 Nov 2019
C Library support for ARINC 653 Operational Environments is Ambiguous	For conformance to the FACE Technical Standard, Editions 3.0 and 3.1 the changes contained in the attachment should be incorporated. For Edition 3.0, please read the 4.x.x section numbers in the attached document as 3.x.x.	3.0 3.1	11 Jun 2020
CTS complex.h tests contain closing brace without an opening brace	For conformance to the FACE Technical Standard, Edition 3.0, replace the files in the CTS v3.0.x conformancetestsuite\conformanceInterfaceTests\C++\OSS\POSIX\general\complex.h directory with the contents of the attached zip file.	3.0	10 Feb 2020
strstreambuf::pcount test has wrong signature	: For conformance to the FACE Technical Standard, Edition 3.0, replace the file conformanceInterfaceTests/C++/OSS/libstdc++/general/strstream/Test000004.cpp in the CTS v3.0.x release with the Test000004.cpp file contained in the attached zip file. Also replace the goldStandardLibraries/C++/src/OSS/libstdc++/general/strstream file with the strstream file contained in the attached zip file.	3.0	10 Feb 2020
C++ operator new still not fully working in Safety Profiles for CTS 2.1.1r3	The following operator new signatures will be supported by the CTS. The CTS gold standard libraries will be updated to provide correct new operators and the CTS conformance interface tests will ensure the operators are provided by the OS. void* operator new ( std::size_t count ); void* operator new[]( std::size_t count ); void* operator new ( std::size_t count, const std::nothrow_t& tag ); void* operator new[]( std::size_t count, const std::nothrow_t& tag ); void* operator new ( std::size_t count, void* ptr ); void* operator new [] ( std::size_t count, void* ptr ); In the Security and Safety Base profiles, no exceptions will be thrown and the signatures modified to remove the "throw" options. bad_alloc will not be defined. Users are permitted to define: void* operator new ( std::size_t count, user-defined-args... ); void* operator new[]( std::size_t count, user-defined-args... ); void* T::operator new ( std::size_t count ); void* T::operator new[]( std::size_t count ); void* T::operator new ( std::size_t count, user-defined-args... ); void* T::operator new[]( std::size_t count, user-defined-args... );	2.1.1 3.0 3.1	08 Jul 2020
Sequence and String Interface Specifications Too Limited	For conformance to FACE Technical Standard, Edition 3.0 an operation to append a single element is added to strings and sequences in both C and C++ as follows: K.1.3 FACE_sequence Specification FACE_sequence_return FACE_sequence_append_elem(FACE_sequence *seq, const char elem); K.1.4 FACE_string Specification FACE_string_return FACE_string_append_elem(FACE_string *str, const char elem); K.2.2 FACE::Sequence Specification FACE::Sequence::RETURN_CODE FACE::Sequence::append(const T& elem); K.2.3 FACE::String Specification FACE::String::RETURN_CODE FACE::String::append (const char& elem); All preconditions and postconditions from the current append() hold. This behavior is available for Ada and Java as published.	3.0 3.1	23 Jan 2020
Serialize Incorrect Direction on Param	For TSS conformance to the FACE Technical Standard ed 3.0 and 3.1, the Message_Serialization::Serialize buffer is 'inout' and the Message_Serialization::DeSerialize message is 'inout' in section E.3.3.	3.0 3.1	18 Jan 2021
OCL constraints realizedCompositionsHaveDifferentTypes for Logical and Platform Entity contexts too restrictive	For conformance to the FACE Technical Standard, Edition 3.0, replace the realizedCompositionsHaveDifferentTypes constraint in the logical.ocl file with: /* * An Entity does not contain two Compositions that realize the same * conceptual Composition unless their types are different Measurements * and their multiplicities are equal. */ inv realizedCompositionsHaveDifferentTypes: self.composition->forAll(c1, c2 | c1 <> c2 and c1.realizes = c2.realizes and c1.type.oclIsTypeOf(Measurement) and c2.type.oclIsTypeOf(Measurement) implies c1.type <> c2.type and c1.lowerBound = c2.lowerBound and c1.upperBound = c2.upperBound) Also replace the realizedCompositionsHaveDifferentTypes constraint in the platform.ocl file with: /* * An Entity does not contain two Compositions that realize the same * logical Composition unless their types are different IDLTypes * and their multiplicities are equal. */ inv realizedCompositionsHaveDifferentTypes: self.composition->forAll(c1, c2 | c1 <> c2 and c1.realizes = c2.realizes and c1.type.oclIsKindOf(IDLType) and c2.type.oclIsKindOf(IDLType) implies c1.type <> c2.type and c1.lowerBound = c2.lowerBound and c1.upperBound = c2.upperBound)	3.0	05 Mar 2020
Parameter mode problem in Get_Serialization	For conformance to FACE Technical Standard, Edition 3 when a FACE Interface of type I is passed as an inout or out parameter it maps to I** in C++. No other programming languages are impacted.	3.0	23 Apr 2020
Sequence payload boundary initialization	Errors in the FACE Technical Standard, Edition 3 result in bounded string and sequence members of IDL structures being mapped as unbounded string and sequence members in the C and C++ programming languages. This Approved Correction describes changes to the C and C++ programming language mappings to realize the correct declarations. In Section 3.14.7.7.1 of the FACE Technical Standard, Edition 3, a conditional mapping rule is added for mapping an IDL structure to a C structure. When the IDL structure contains a bounded string or sequence member, the mapping rule specifies an initialization function to properly assign the bound values. The initialization function is inline with an extern storage-class specifier, returns FACE_interface_return, and has one parameter whose type is a pointer to the structure. The behavior is implementation-defined if the initialization function does not return FACE_INTERFACE_NO_ERROR. String and sequence members are initialized in the body of the initialization function using the corresponding bound_value macro constant. All other members remain uninitialized. In Section 3.14.8.8.1 of the FACE Technical Standard, Edition 3, a conditional mapping rule is added for mapping an IDL structure to a C++ structure. When the IDL structure contains a bounded string or sequence member, the mapping rule specifies a default constructor to properly assign the bound values. String and sequence members are default-constructed then assigned a block-scoped instance in the constructor body. This block-scoped instance is created using the corresponding bound_value macro constant. The assignment operator copies the bound to the string or sequence member. All other members remain default-constructed when a constructor is declared. These errors remain in the FACE Technical Standard, Edition 3 Corrigendum 1. The references to Section 3.14 in the corrections above apply to Section 4.14 of Corrigendum 1.	3.0 3.1	08 Jul 2020
Insufficient requirements for TS Header	The TSS Appendices section E.3 and E.4 wherever the header parameter is included, the following note applies: When TSS UoCs do not support the header parameter, the header's source, instance, and timestamp is set to 0. The header parameter should be considered deprecated for future use by PCS/PSSS UoCs.	3.0 3.1	24 Feb 2021
TSS Capability Requirements Issues	For conformance to the FACE Technical Standard Edition 3.0 and 3.1, the following should be applied to Section 3.7.5 and 4.7.5 respectively, • Requirements 5, 6, 7, 8, 9, 10, 11, and 12 are only applicable when serialization is provided and/or subsequently used by a TPM. The intent of future versions of the FACE Technical Standard is that serialization becomes its own section in the standard because it does not pertain to the TSS Configuration Capability. • Requirement 4 only applies to the TSS Distribution Capability. Its requirement would read as follows, When a TSS UoC provides the Distribution Capability, its TSS Configuration Capability shall provide a TPM injectable interface in accordance with 4.11.4.1. • By inference then requirements 13 and 14 only apply when a TSS Distribution Capability has been provided a TPM reference through the Injectable interface.	3.0 3.1	11 Aug 2021
TSS Interfaces Not Assigned to UoC	For purposes of conformance to the FACE Technical Standard, Editions 3.0 and 3.1, the following additions to Table 8 are added for TSS UoCs to use: Type_Specific Base (Section E.3.1) Primitive_Marshalling (Section E.4.2) Note users of Primitive_Marshalling will require an Injectable Interface For purposes of conformance to the FACE Technical Standard, Edition 3.0 and 3.1, the following TSS requirements are used to identify the TSS UoCs which may provide the interfaces as follows. The text below identifies other approved corrections and existing FACE Technical Standard requirements in addition to CR 564 generated corrections to provide a more complete view across all TSS interfaces for the readers of this approved correction. Approved Correction 491 identifies the requirements in the FACE Technical Standard Edition 3.0 Sections 3.7.3/3.8.4.1 and Edition 3.1 Sections 4.7.3/4.8.4.1 which apply to Base versus TypedTS interfaces Approved Correction 585 allows TS-TA to provide the TSS Base Interface in addition to the Distribution Capability. The consequence is the TS-TA UoC or TS UoC may provide Base. Existing requirements: In accordance with the FACE Technical Standard Edition 3.0 Section 3.7.6.1 and Edition 3.1 Section 4.7.6.1, the TA UoC provides the TypeAbstractionTS and Base interfaces per requirements 5 and 6. Approved Correction 628 clarifies the section references and requirements to apply to TypeAbstractionTS and Base. Existing requirements: In accordance with the FACE Technical Standard Edition 3.0 Section 3.7.13 and Edition 3.1 Section 4.7.13, the CSP UoC provides the CSP interface per requirement 3. CR 564 update: For purposes of conformance to the FACE Technical Standard Editions 3.0 and 3.1, a TPM UoC shall meet the following requirement, A Transport Protocol Module Capability shall provide the Transport Protocol Module Interface as specified in Section 4.7.11.2. Approved Correction 582 clarifies the requirements for the TypedTS to include the TypedTS Extended interface. The consequence is the TS-TA UoC or TS UoC may provide TypedTS Extended. Approved Correction 563 clarifies the requirements in the FACE Technical Standard Edition 3.0 Section 3.7.5 and Edition 3.1 Section 4.7.5 as which ones apply to serialization. CR 564 update: For purposes of conformance to the FACE Technical Standard Edition 3.0 Section 3.7.11 and Edition 3.1 Section 4.7.11, requirements 5 and 6 are not required by a TPM UoC. CR 564 update: For purposes of conformance to the FACE Technical Standard Editions 3.0 and 3.1, the FACE::TSS::TPM::TPMTS::Primitive_Marshalling is removed from the TPM::TPMTS namespace to a separate module with the following namespace FACE::TSS::Primitive_Marshalling. CR 564 update: For purposes of conformance to the FACE Technical Standard Editions 3.0 and 3.1, Serialization and Primitive Marshalling may be part of a certified conformant TS, TS-TA, TA, TPM, or FS UoC or considered integration software that is not certified conformant by the UoC supplier. Note Approved Correction 343 allows a TSS supplier to submit a process for the generation of code which is dependent on USM data types.	3.0 3.1	11 Aug 2021
Inconsistent Language for References to Mapping Rules	For conformance to FACE Technical Standard, Edition 3.0, a requirement in Section 3.8.4.2 should be included to use IDL to Programming Language Mapping in 3.14 for the CSP Interface. The requirement is as follows: "A CSP Capability shall use the IDL to Programming Language Mappings defined in Section 3.14 for its CSP Interface" For conformance to FACE Technical Standard, Edition 3.1, a requirement in Section 4.8.4.2 should be included to use IDL to Programming Language Mapping in 4.14 for the CSP Interface. The requirement is as follows: "A CSP Capability shall use the IDL to Programming Language Mappings defined in Section 4.14 for its CSP Interface".	3.0 3.1	12 May 2020
Describing Model association path of a participant’s characteristic for more stringent rigor will cause a fail of the OCL	For Conformance to the FACE Technical Standard, Edition 3.0, the Conceptual OCL constraint: PathNode:noProjectionAcrossCollection can be ignored. The user and VA may remove, or comment out, this constraint from the conceptual.ocl CTS file.	3.0 3.1	08 Jul 2020
Delete produce by CTS when using Safety Base	For conformance to the FACE Technical Standard, Edition 2.1 and Edition 2.1.1, the software supplier may comment out any lines containing the ‘delete’ key word in any USM generated data type definitions.	2.1 2.1.1	06 Mar 2020
Two FACE::TSS Common Types Should Be Unsigned	For conformance to the FACE Technical Standard ed 3 or 3.1, the following IDL updates in E.2.1 should be used, //! Length of the TS Message. typedef unsigned long MESSAGE_SIZE_TYPE; //! This type is used to represent a size in bytes. typedef unsigned long BYTE_SIZE_TYPE;	3.0 3.1	14 May 2021
CTS Incorrectly flags Java UoC usage of signature polymorphism methods	For Conformance to the FACE Technical Standard, Edition 2.1 and 2.1.1, CTS report entries that match the pattern “Access to method invoke ****; in class java.lang.invoke.MethodHandle was requested. Checking for method existence.” may be ignored. This only pertains to java.lang.invoke.MethodHandle and no other classes.	2.1 2.1.1	05 Mar 2020
Type Abstraction Interface Functions Need Documentation	For FACE Technical Standard, edition 3.0 In E.4.1, the Type Abstraction interface parameters should be read as follows, size_limit in the Receive_Message (TA) and Send_Message_Blocking (TA) is redundant to the buffer_capacity element of the DATA_BUFFER_TYPE and the size_limit parameter can be ignored by Type Abstraction UoCs. Type Abstraction UoC implementations are not expected to return a meaningful value in the size_sent within the Send_Message(TA), Send_Message_Blocking (TA), and Send_Message_Callback (TA) functions. For FACE Technical Standard, edition 3.1 In E.4.1, the Type Abstraction interface parameters should be read as follows, size_limit in the Receive_Message (TA) and Send_Message_Blocking (TA) is redundant to the buffer_capacity element of the DATA_BUFFER_TYPE and the size_limit parameter can be ignored by Type Abstraction UoCs. Type Abstraction UoC implementations are not expected to return a meaningful value in the size_sent within the Send_Message(TA), Send_Message_Blocking (TA), and Send_Message_Callback (TA) functions.	3.0 3.1	08 Jul 2020
TA Send_Message_Blocking return_data Parameter Should be inout	For TSS conformance to the FACE Technical Standard ed 3.0 and 3.1, the TypedTS::Send_Message_Blocking return_data is 'inout' and the TypeAbstractionTS::Send_Message_Blocking return_data is 'inout'	3.0 3.1	18 Jan 2021
TA Read_Callback Signature and Buffer Issues	For conformance to Editions 3.0 and 3.1 of the FACE Technical Standard, register callback in section E.3.2 shall be as follows: void Register_Callback ( in CONNECTION_ID_TYPE connection_id, inout Read_Callback data_callback, in MESSAGE_SIZE_TYPE max_message_size, in MESSAGE_GUID_TYPE message_guid out RETURN_CODE_TYPE return_code); With the following note for the parameter added: message_guid = CALLEE_PROVIDES_GUID indicates the TS-TA does not provide GUIDs but expects the TA to source GUIDs. This note needs to be applied to Register_Callback, Send_Message, Receive_Message, Send_Message_Blocking and Send_Message_Async in the TA description. Section E.2.1 is updated to include the constant: const GUID_TYPE CALLEE_PROVIDES_GUID = 0;	3.0 3.1	18 Jan 2021
Create_Connection’s max_message_size parameter is not useful	When conforming to the FACE Technical Standard, the following note should be included in the Base::Create_Connection max_message_size description, "TSS UoCs that do not support the max_message_size parameter, the max_message_size parameter is set to 0. The max_message_size parameter should be considered deprecated for future use by PCS/PSSS UoCs.	3.0 3.1	24 Feb 2021
No Requirement for Type-Specific Extended Typed Interface	For FACE Technical Standard, Edition 3.0 Section 3.8.4.1 should include requirements for the Type_Specific Extended interface as follows, When a TS TypedTS Extended interface is provided, the TS Interface shall meet the TypedTS interface specification of Section E.3.4. When a TS TypedTS Extended interface is provided, a TS Interface shall supply the return code value returned from the TypedTS Interface functions as specified in Section E.3.4. For FACE Technical Standard, Edition 3.1 Section 4.8.4.1 should include requirements for the Type-Specific Extended interface as follows, When a TS TypedTS Extended interface is provided, the TS Interface shall meet the TypedTS interface specification of Section E.3.4. When a TS TypedTS Extended interface is provided, a TS Interface shall supply the return code value returned from the TypedTS Interface functions as specified in Section E.3.4.	3.0 3.1	26 Oct 2020
Transport Service Capability needs to use the TA Capability’s Base Interface	For conformance to FACE Technical Standard, Editions 3.0 and 3.1, a TS-TA UoC is allowed to provide TS Base Interface.	3.0 3.1	26 Oct 2020
TSS Non-Blocking Requirements should be UoC Design	For conformance to the FACE Technical Standard, Edition 3.0, CVM rows 805, 807, 984 and 986 the Conformance Artifacts should be "UoC Designs". Additionally, for conformance to the FACE Technical Standard, Edition 3.0, CVM row 991 the Verification Method should be "Test" and the Conformance Artifacts should be "Test Suite".	3.0	12 May 2020
Header Guard Mapping Rules Violate C/C++ Language Standards	For conformance to FACE Technical Standard, Edition 3 and Edition 3 Corrigendum 1, please note the following: 1. The mapping rules for C preprocessor directives should not include a leading underscores, as it violates C programming language rules for macro identifiers. 2. The mapping rules for C++ preprocessor directives should not include a leading underscores, as it violates C++ programming language rules for macro identifiers. 3. IDL files included in their entirely in the FACE Technical Standard should not include #ifndef statements where the macro identifier has a leading underscore, as they violate IDL rules for macro identifiers. 4. C headers in Appendix K.1 and C++ headers in Appendix K.2 should not include #ifndef statements where the macro identifier has a leading underscore.	3.0 3.1	23 Apr 2020
C++ Message Serialization Implementation Unable to Call Marshalling Methods	For conformance to the FACE Technical Standard, the signature of Serialize(TS) and DeSerialize(TS) in E.3.3 and subsections should read that TPM::Primitive_Marshalling is an inout parameter.	3.0	23 Apr 2020
TPM Callbacks can't create typed view	For TSS conformance to the FACE Technical Standard, ed 3.0 or ed 3.1, TPMTS::Read_From_Transport should use an 'inout' for its message parameter.	3.0 3.1	24 Feb 2021
Remove confstr() from FACE Profiles	For Conformance to the FACE Technical Standard, Appendix A for the POSIX profile should be read to not include confstr() in any FACE OS Profile.	1.0 1.1 2.0 2.0.1 2.1 2.1.1 3.0 3.1	23 Apr 2020
Process scheduling methods available when multiple processes are not supported	For Conformance to the FACE Technical Standard, Appendix A.1 should be read as follows: The methods sched_getparam(), sched_setparam(), sched_getscheduler(), and sched_setscheduler() are not required to be supported by the OSS UoC unless multiple processes are supported. This impacts Safety Extended and General Purpose Profiles.	3.0 3.1	23 Apr 2020
CTS Test Code does not have const in the pcount method causing a failure	For conformance to the FACE Technical Standard, Edition 2.1 and 2.1.1 replace the file conformanceInterfaceTests/C++/OSS/libstdc++/general/strstream/Pass/Test000004.cpp in the CTS v3.0.x release with the Test000004.cpp file contained in the attached zip file. Also replace the goldStandardLibraries/C++/src/OSS/libstdc++/general/strstream file with the strstream file contained in the attached zip file.	2.1 2.1.1	12 May 2020
Requirement 8 in Section 3.7.4 conflicts with Table 7	For FACE Technical Standard 3, section 3.7.4 requirement #8 should be read as follows, "When data messaging associations and/or tagging are performed, a Distribution Capability shall use the Message Association Capability." The CVM would include requirement 8 as a conditional requirement for Message Association Capability in addition to Distribution Capability. For FACE Technical Standard 3 corrigendum 1, section 4.7.4 requirement #8 should be read as follows, "When data messaging associations and/or tagging are performed, a Distribution Capability shall use the Message Association Capability." The CVM would include requirement 8 as a conditional requirement for Message Association Capability in addition to Distribution Capability.	3.0 3.1	27 Jul 2020
3.7.6 requirement 4 conflicts with Table 7	For conformance to FACE Technical Standard, Edition 3.0, Requirement 4 of Section 3.7.6 should be read as: When implementing the Type Abstraction Capability, a TSS UoC shall also provide zero or more of the following capabilities: a. QoS Management Capability b. Message Association Capability c. Data Transformation Capability d. Message Pattern Translation Capability e. Data Store Support Capability For conformance to FACE Technical Standard, Edition 3.1, Requirement 4 of Section 4.7.6 should be read as: When implementing the Type Abstraction Capability, a TSS UoC shall also provide zero or more of the following capabilities: a. QoS Management Capability b. Message Association Capability c. Data Transformation Capability d. Message Pattern Translation Capability e. Data Store Support Capability	3.0 3.1	11 Jun 2020
3.7.4 Requirement 3 Ambiguous Due to Multiple Terms	For FACE Technical Standard, Edition 3.0 Requirement 3, section 3.7.4 shall be read as follows, A Distribution Capability shall populate the header parameter within Receive_Message, Callback_Handler, or Send_Message_Blocking interfaces based on data from the endpoint sourcing the message data. Requirement 4, section 3.7.4 shall be read as follows, A Distribution Capability shall provide data to endpoints receiving TSS messages to support populating the header parameter within Receive_Message, Callback_Handler, or Send_Message_Blocking. Note, Distribution can be realized through a TS, FS, or TA UoC such that the header is a reference to a parameter within any of the Typed or TypeAbstraction Receive_Message, Callback_Handler, or Send_Message_Blocking interfaces. Note, the data may be received from the TSS source endpoint or derived data. Requirement 1, section 3.8.6 shall be read as follows, The TS header structure shall use the IDL to Programming Language Mappings defined in Section 3.14 per the TSS Header IDL in Section E.2.1. For FACE Technical Standard, Edition 3.1 Requirement 3, section 4.7.4 shall be read as follows, A Distribution Capability shall populated the header parameter within Receive_Message, Callback_Handler, or Send_Message_Blocking interfaces based on data from the endpoint sourcing the message data. Requirement 4, section 4.7.4 shall be read as follows, A Distribution Capability shall provide data to endpoints receiving TSS messages that supports populating the header parameter within Receive_Message, Callback_Handler, or Send_Message_Blocking. Note, Distribution can be realized through a TS, FS, or TA UoC such that the header is a reference to a parameter within any of the Typed or TypeAbstraction Receive_Message, Callback_Handler, or Send_Message_Blocking interfaces. Note the data may be received from the TSS source endpoint or derived data. Requirement 1, section 4.8.6 shall be read as follows, The TS header structure shall use the IDL to Programming Language Mappings defined in Section 4.14 per the TSS Header IDL in Section E.2.1.	3.0 3.1	18 Aug 2020
Message Routing is Not Conditional	For FACE Technical Standard, Edition 3.0 Section 3.7.5.1.1, item #1 should read: """ 1. When a TSS UoC provides a Distribution Capability, the TSS UoC shall contain the following Configuration Data Elements: a. Message Routing Association (Section 3.7.5.1.2) b. Route Definition (Section 3.7.5.1.3) """ Additionally, for FACE Technical Standard, Edition 3.0 Section 3.7.5.1.1, item #2 should be understood as provision of QoS Definition Configuration Data Elements (Section 3.7.5.1.4) being contingent on whether the TSS UoC provides a QoS Management Capability, and Transformation Map Configuration Data Elements (Section 3.7.5.1.5) being contingent on whether the TSS UoC provides a Data Transformation Capability. For FACE Technical Standard, Edition 3.1 Section 4.7.5.1.1, item #1 should read: """ 1. When a TSS UoC provides a Distribution Capability, the TSS UoC shall contain the following Configuration Data Elements: a. Message Routing Association (Section 4.7.5.1.2) b. Route Definition (Section 4.7.5.1.3) """ Additionally, for FACE Technical Standard, Edition 3.1 Section 4.7.5.1.1, item #2 should be understood as provision of QoS Definition Configuration Data Elements (Section 4.7.5.1.4) being contingent on whether the TSS UoC provides a QoS Management Capability, and Transformation Map Configuration Data Elements (Section 4.7.5.1.5) being contingent on whether the TSS UoC provides a Data Transformation Capability.	3.0 3.1	11 Jun 2020
term “header” is overused throughout the TSS sections	For conformance to the FACE Technical Standard edition 3.0 Section 3.8.5.1, requirement 1 should be read as follows, "The TS Interface shall provide content for the following parameters: a. header parameter as specified in 3.8.5.3 b. Message parameter as specified in 3.8.5.2. For conformance to the FACE Technical Standard edition 3.0 Section 3.8.5.1, requirement 2 should be read as follows, "When QoS Management is performed, the TS Interface shall provide content for the QoS parameter as specified in 3.8.5.4." For conformance to the FACE Technical Standard edition 3.1 Section 4.8.5.1, requirement 1 should be read as follows, "The TS Interface shall provide content for the following parameters: a. header parameter as specified in 4.8.5.3 b. Message parameter as specified in 4.8.5.2. For conformance to the FACE Technical Standard edition 3.1 Section 4.8.5.1, requirement 2 should be read as follows, "When QoS Management is performed, the TS Interface shall provide content for the QoS parameter as specified in 4.8.5.4." For conformance to the FACE Technical Standard edition 3.0 Section 3.8.5.3 and edition 3.1 Section 4.8.5.3, requirement 1 should be read as follows, "The context and frame of reference shall be defined for the header parameter data elements: a. Message Instance UID b. Message Source UID c. Message Timestamp For conformance to the FACE Technical Standard edition 3.0 Section 3.8.5.3 and edition 3.1 Section 4.8.5.3, a TSS UoC should be required to meet the following requirement, "Instances of the header parameter shall be a language-specific data structure consistent with the definition provided" For conformance to the FACE Technical Standard edition 3.0 Section 3.8.5.4 and edition 3.1 Section 4.8.5.4, requirement 2 should be read as follows, "The context and frame of reference shall be defined for the qos_parameter data elements: a. QoS Key b. QoS Attribute Values" For conformance to the FACE Technical Standard edition 3.0 Section 3.8.5.4 and edition 3.1 Section 4.8.5.4, requirement 1 should be read as follows "Instances of the qos_parameter shall be a language-specific data structure consistent with the definition provided"	3.0 3.1	18 Aug 2021
LCM Initialize function should not be allowed to return INVALID_CONFIG	For conformance to the FACE Technical Standard, Edition 3, the specification of Initialize(LCM::Initializable) in D.2.1 should not include INVALID_CONFIG as a return code. PR/CR Ticket 263 removed a parameter from the signature but overlooked the consequence to the return codes. This problem remains in Edition 3, Corrigendum 1.	3.0 3.1	18 Aug 2020
TSS Base interface’s Initialize function should return an error when expecting initialization via LCM, Location: E.3.1.1	FACE Technical Standard, Edition 3.0 and FACE Technical Standard, Edition 3.1 section E.3.1.1 return code type NO_ACTION, should be read as follows, "NO_ACTION - to indicate TS has been initialized successfully previously or should be initialized through the LCM interface"	3.0 3.1	18 Aug 2020
LCM interfaces should not return NO_ACTION	For conformance to the FACE Technical Standard, Edition 3.0 and 3.1, the specification of all LCM Services interface operations in Appendix D should not include NO_ACTION as a return code.	3.0 3.1	27 Jul 2020
Section referenced by a CVM requirement with the “Per referenced section” Conformance artifact has no requirements	For FACE Technical Standard, Edition 3.0 Section 3.7.6, item #6 should read: "A Type Abstraction Capability shall provide the Base Interface in accordance with requirements in Section 3.8.4.1." When satisfying this requirement, the Type Abstraction Capability is only required to meet the Base Interface requirements (#1, #5, #6 and #7) in the referenced section. Per the note following requirement #1 in Section 3.8.4.1, if a TSS UoC provides a Type Abstraction Capability and a Transport Service Capability, only one of the capabilities is obligated to provide the Base Interface. For FACE Technical Standard, Edition 3.1 Section 4.7.6, item #6 should read: "A Type Abstraction Capability shall provide the Base Interface in accordance with requirements in Section 4.8.4.1." When satisfying this requirement, the Type Abstraction Capability is only required to meet the Base Interface requirements (#1, #5, #6 and #7) in the referenced section. Per the note following requirement #1 in Section 4.8.4.1, if a TSS UoC provides a Type Abstraction Capability and a Transport Service Capability, only one of the capabilities is obligated to provide the Base Interface.	3.0 3.1	11 Jun 2020
TSS Does Not Provide Read_Callback Implementations as Part of Public Interface	For FACE Technical Standard, Edition 3.0 Section 3.7.6.1 requirement 1 is read as follows, "The Type Abstraction Interface shall meet the TypeAbstractionTS interface specification of Section E.4.1." Section 3.8.4.1 requirement 2 is read as follows, "The TS Interface shall meet the TypedTS interface specification of Section E.3.2." For FACE Technical Standard, Edition 3.1 Section 4.7.6.1 requirement 1 is read as follows, "The Type Abstraction Interface shall meet the TypeAbstractionTS interface specification of Section E.4.1." Section 4.8.4.1 requirement 2 is read as follows, "The TS Interface shall meet the TypedTS interface specification of Section E.3.2."	3.0 3.1	27 Jul 2020
qos_parameters argument isn't adequately defined	For conformance to the FACE Technical Standard, Editions 3.0 and 3.1 the QoS_EVENT_TYPE in Section E.2.1 should be bound to 2 as follows, typedef sequence <QoS_Element,2>QoS_EVENT_TYPE; For conformance to the FACE Technical Standard, Edition 3.0 Section 3.7.11 and Edition 3.1 Section 4.7.11, requirements 11 and 12 do not need to be met. For conformance to the FACE Technical Standards, Edition 3.0 and 3.1, Sections E.3.2.1, E.3.2.2, E.3.4.1, E.3.4.2, E.4.2.7, E.4.2.9 for the qos_parameters the TSS should pass back the length of the QoS_EVENT_TYPE sequence set to 0, if not supported.	3.0 3.1	18 Aug 2021
No epoch for time is given in the Technical Standard	For conformance to the FACE Technical Standard, Edition 3 and Edition 3.1, the following declarations are added or modified to FACE/common.idl in Section B.2: • New type declaration DURATION_TIME_TYPE of type long long with comment noting correspondence to ARINC 653 Part 1, Section 3.4.1 as a duration. • New type declaration ABSOLUTE_TIME_TYPE of type long long with comment noting the frame of reference as the UNIX epoch consistent with the C run-time library. • Modified type declaration SYSTEM_TIME_TYPE to reference ABSOLUTE_TIME_TYPE. • Modified type declaration TIMEOUT_TYPE to reference DURATION_TIME_TYPE. • Modified type declaration INF_TIME_VALUE to reference TIMEOUT_TYPE, moving its declaration after that for TIMEOUT_TYPE.	3.0 3.1	18 Aug 2020
Missing extern C in header files	This Approved Correction describes changes to the C programming language mappings to allow C interface declarations to be compiled using a C++ compiler and referenced by a C client. This concept is called language linking and it encompasses name mangling of library symbols. The C++ compiler is instructed to perform name mangling consistent with C language calling conventions using the extern “C” keywords. An example of the mapping language is given in the attachment, along with the specific changes proposed to the FACE Technical Standard. This new mapping is also applicable to the FACE Technical Standard, Edition 3 Corrigendum 1. The references to Section 3.14 above apply to Section 4.14 of Corrigendum 1.	3.0 3.1	27 Jul 2020
GSL Serialziation_Injectable.hpp missing Serialization_Injectable	For conformance to the FACE Technical Standard, Edition 3.0 and 3.1, the CTS Gold Standard Library may be modified so the Serialization_Injectable.hpp contains an interface for Serialization::Injectable instead of Message_Serialization::Injectable.	3.0 3.1	08 Jul 2020
CTS cannot link against factory methods provided as source	For conformance to the FACE Technical Standard, Edition 3.0 and Edition 3.1, the CTS may be modified to update the tool chain template such that objects appear before libraries in the link command.	3.0 3.1	08 Jul 2020
Unregister_Callback doesn't specify what happens if it is called when no callback is registered	When conforming to the FACE Technical Standard, ed 3 and 3.1, the return code value in the BASE::Unregister_Callback and TPMTS::Unregister_TPM_Callback uses INVALID_PARAM to indicate invoking unregister callback for connections that do not have a callback registered.	3.0 3.1	24 Feb 2021
TPMs should be allowed for intradomain transport	For purposes of conformance to the FACE Technical Standard edition 3.0 requirement 1 of Section 3.7.11 should be read as follows, "A TPM Capability shall provide one or more TPM(s) to form distribution path(s) to transport type(s)." and requirement 2 Section 3.7.11 is not applicable. For purposes of conformance to the FACE Technical Standard edition 3.1 requirement 1 of Section 4.7.11 should be read as follows, "A TPM Capability shall provide one or more TPM(s) to form distribution path(s) to transport type(s)." and requirement 2 Section 4.7.11 is not applicable.	3.0 3.1	01 Oct 2021
Not all TPMs should be required to provide Primitive_Marshalling	For the FACE Technical Standard, Edition 3 section 3.7.11.2 Requirement 1 should be read as follows, "A TPM Interface shall meet the TPMTS Interface as specified in Section E.4.2" Additionally, one requirement is added to make the primitive marshalling interface conditional as follows, When a TPM primitive marshalling interface is provided, the TPM Interface shall meet the FACE::TSS::TPM::Primitive_Marshalling interface specification of Section E.4.2. For the FACE Technical Standard, Edition 3.1 section 4.7.11.2 Requirement 1 should be read as follows, "A TPM Interface shall meet the TPMTS Interface as specified in Section E.4.2" Additionally, one requirement is added to make the primitive marshalling interface conditional as follows, When a TPM primitive marshalling interface is provided, the TPM Interface shall meet the FACE::TSS::TPM::Primitive_Marshalling interface specification of Section E.4.2.	3.0 3.1	18 Aug 2020
C/C++ FACE::Fixed Support Class More Than Container	For conformance to the FACE Technical Standard, Editions 3.0 and 3.1, new declarations of FACE::Fixed for C++ and FACE_fixed for C are adopted. UoCs that provide support for either type for data exchange across the TS Interface should use the new declarations. The normative headers, along with unit test cases, are attached to Ticket 664 in the PR/CR system. The IDL fixed mappings for Ada and Java are unaffected by this Approved Correction.	3.0 3.1	25 Feb 2022
Initialization of Fixed Data Types	For conformance to FACE Technical Standard, Edition 3.0, a C struct that contains a FACE_fixed data type mapped per Section 3.14.7.7.1 must define an inline initialization function that calls the FACE_fixed_init() initializer and passes the prescribed digits and bound that are defined as macros. The initialization function shall return FACE_interface_return value. For C++, a struct containing a FACE::Fixed type mapped per Section 3.14.8.8.1 must provide a constructor that calls the Fixed(digits, scale) constructor using the values defined as macros. For conformance to FACE Technical Standard, Edition 3.0, the FACE_interface_return specification in Section K.1.2 should be read to include an enumerated value for FACE_INTERFACE_LOGIC_ERROR. For conformance to FACE Technical Standard, Edition 3.1, a C struct that contains a FACE_fixed data type mapped per Section 4.14.7.7.1 must define an inline initialization function that calls the FACE_fixed_init() initializer and passes the prescribed digits and bound that are defined as macros. The initialization function shall return FACE_interface_return value. For C++, a struct containing a FACE::Fixed type mapped per Section 4.14.8.8.1 must provide a constructor that calls the Fixed(digits, scale) constructor using the values defined as macros. For conformance to FACE Technical Standard, Edition 3.1, the FACE_interface_return specification in Section K.1.2 should be read to include an enumerated value for FACE_INTERFACE_LOGIC_ERROR.	3.0 3.1	18 Jan 2021
Sentinel Values for transaction_id when Publisher or Subscriber	For purposes of conformance to the Technical Standard ed 3 and ed 3.1, the following should be used to elicit the intended behavior for the transaction_id parameter. Use two additional constants in TSS common const TRANSACTION_ID_TYPE TID_NOT_APPLICABLE = -1; const TRANSACTION_ID_TYPE CALLEE_PROVIDES_TID = 0; On pub/sub connections, the transaction_id is set to TID_NOT_APPLICABLE when sending and receiving To interface to servers that use one connection for all clients, the client/server connections use transaction id as follows: For client request messages, the upper 32 bits of the transaction id is set to the instance of the source and the bottom 32 bits are encoded to a unique transaction value Clients set the transaction_id to CALLEE_PROVIDES_TID when invoking sends Servers provide the received transaction_id when invoking the send_message Clients receive the transaction_id and use it to associate the response to their request. A new return code type, RESOURCE_LIMIT_REACHED is returned when clients have too many outstanding requests To allow clients to have multiple outstanding requests, an additional return code type is added as follows: enum RETURN_CODE_TYPE { NO_ERROR, //! request valid and operation performed NO_ACTION, //! status of system unaffected by request NOT_AVAILABLE, //! no message was available INVALID_PARAM, //! invalid parameter specified in request INVALID_CONFIG, //! parameter incompatible with configuration INVALID_MODE, //! request incompatible with current mode TIMED_OUT, //! the time expired before the request could be filled ADDR_IN_USE, //! address currently in use PERMISSION_DENIED, //! no permission to send or connecting to wrong //! partition MESSAGE_STALE, //! current time - timestamp exceeds configured limits IN_PROGRESS, //! asynchronous connection in progress CONNECTION_CLOSED, //! connection was closed DATA_BUFFER_TOO_SMALL, //! Data Buffer was too small for message DATA_OVERFLOW, //! A loss of messages due to data buffer overflow RESOURCE_LIMIT_REACHED //! The maximum number of resources has been used }; The following IDL direction updates shall be placed in sections E.3 and E.4: Update TypedTS::Receive_Message transaction_id parameter to 'out' Update TypeAbstractionTS::Receive_Message transaction_id parameter to 'out' Update TypedTS::Send_Message_Async transaction_id parameter to 'inout' Update TypeAbstractionTS:: Send_Message_Async transaction_id parameter to 'inout' Update TPMTS::Write_To_Transport transaction_id parameter to 'in' Note that a unique transaction_id value is required for clients with the upper 32 bits encoded to the instance of the source. To generate a unique value for the instance of the source, a TSS UoC could use the TSS instance or a configuration value input by a system integrator. The bottom 32 bits are encoded uniquely for each transaction across the set of transactions managed by the TSS instance. The bottom encoding enables responses to be properly matched to requesting clients. This allows one TSS instance to have more than one PCS/PSSS UoC that makes requests to the same server using a single transport connection.	3.0 3.1	18 Jan 2021
What Happens to Pending Messages When a Callback is Registered	When conforming to the FACE Technical Standard ed 3.0 and ed 3.1, the following note should accompany Base::Create_Connection, "The behavior is unspecified for whether or not messages received on the transport prior to connections being created are available to PCS/PSSS UoCs." When conforming to the FACE Technical Standard ed 3.0 and ed 3.1, the following note should accompany TypedTS::Register_Callback, TypeAbstractionTS::Register_Callback, and TPMTS::Register_TPM_Callback, "The behavior is unspecified for whether or not messages received on the transport prior to callbacks being registered are available to PCS/PSSS UoCs."	3.0 3.1	24 Feb 2021
Base and Typed Interfaces Disagree on Invalid Connection Id Return Status	For the purposes of conforming to the FACE Technical Standard editions 3.0 and 3.1, the NO_ACTION, INVALID_PARAM, and CONNECTION_CLOSED return code should read as follows NO_ACTION to indicate a failure to complete the requested action due to unknown reasons INVALID_PARAM to indicate one or more parameters supplied is null or not in range or the connection_id is unknown to the TSS implementation CONNECTION_CLOSED to indicate the TSS UoC connection is not open/available This affects the following interfaces, FACE::TSS::<UOP_MODEL_NAME>::<DATATYPE_TYPE>::TypedTS::Receive_Message FACE::TSS::<UOP_MODEL_NAME>::<DATATYPE_TYPE>::TypedTS::Send_Message FACE::TSS::<UOP_MODEL_NAME>::<DATATYPE_TYPE>_<RESPNSE_DATATYPE>::TypedTS::Send_Message_Blocking FACE::TSS::<UOP_MODEL_NAME>::<DATATYPE_TYPE>_<RESPONSE_DATATYPE>::TypedTS::Send_Message_Async FACE::TSS::TypeAbstraction::TypeAbstractionTS::Receive_Message FACE::TSS::TypeAbstraction::TypeAbstractionTS::Send_Message FACE::TSS::TypeAbstraction::TypeAbstractionTS::Send_Message_Blocking FACE::TSS::TypeAbstraction::TypeAbstractionTS::Send_Message_Async FACE::TSS::TPM::TPMTS::Read_From_Transport FACE::TSS::TPM::TPMTS::Write_To_Transport For conformance to the FACE Technical Standard, Editions 3.0 and 3.1, the FACE::TSS::Base::Unregister_Callback and FACE::TSS::TPM::TPMTS::Unregister_TPM_Callback can return CONNECTION_CLOSED per the definition above.	3.0 3.1	11 Aug 2021
Route name shouldn't be required	For conformance to the FACE Technical Standard, ed 3, requirement #2 section 3.7.5.1.2 is considered deleted. For conformance to the FACE Technical Standard, ed 3.1, requirement #2 section 4.7.5.1.2 is considered deleted.	3.0 3.1	14 May 2021
Modeling of Time parameters in TS Interface	For purposes of conformance to the FACE Technical Standard Edition 3.0, requirement 2 in section 3.8.6, to model the time parameter, is not required. For purposes of conformance to the FACE Technical Standard Edition 3.1, requirement 2 in section 4.8.6, to model the time parameter, is not required.	3.0 3.1	11 Aug 2021
Register_TPM_Callback should not return DATA_BUFFER_TOO_SMALL	For conformance to the FACE Technical Standard ed 3, section E.4.2.11 Register_TPM_Callback should not return DATA_BUFFER_TOO_SMALL.	3.0 3.1	14 May 2021
Send_Message_Blocking Should Be Able to Return DATA_BUFFER_TOO_SMALL	For the purposes of conformance to the FACE Technical Standard, editions 3.0 and 3.1, the TypedTS (E.3.3.2) and TypeAbstractionTS (E.4.1) Send_Message_Blocking method is able to provide the return code DATA_BUFFER_TOO_SMALL with the following definition. • DATA_BUFFER_TOO_SMALL to indicate the message received exceeds the message size given on a single transaction	3.0 3.1	22 Jun 2021
DMVT Incorrectly Reports Error when using SDM Approved Basis Entities	The CTS may report spurious error messages. For Conformance to the FACE Technical Standard, Edition 3.0 and Edition 3.1, CTS error messages following the template: "Addition of 'XYZ' (BasisEntity) is not allowed. Additions of 'BasisEntity' type must be submitted and approved by the CCB for inclusion in the Shared Data Model" may be ignored as long as BasisEntity XYZ does exist in the FACE SDM.	3.0 3.1	26 Oct 2020
FACE fixed.h has function defined twice	For conformance to the FACE Technical Standard, Editions 3.0 and 3.1, the declarations for FACE_fixed in Section K.1.5 should list FACE_fixed_init_short() once.	3.0 3.1	26 Oct 2020
Unnecessary comma after last value in enum	For conformance to the FACE Technical Standard, Editions 3.0 and 3.1, the declaration of FACE_interface_return in Section K.1.2 should not have a comma after the final enumerated value.	3.0 3.1	26 Oct 2020
FACE_FIXED_DIGITS_MAX in C++ conflicts with C macro	For Conformance to FACE Technical Standard, Edition 3.0, the declaration for maximum number of digits in a fixed-point number for the FACE Fixed Specification in Section K.2.4 should be read as follows: static const FACE::Short DIGITS_MAX = (FACE::Short)31; For Conformance to FACE Technical Standard, Edition 3.1, the declaration for maximum number of digits in a fixed-point number for the FACE Fixed Specification in Section K.2.4 should be read as follows: static const FACE::Short DIGITS_MAX = (FACE::Short)31;	3.0 3.1	26 Oct 2020
Discriminator Mutator Mentioned with No Corresponding Method	For conformance to the FACE Technical Standard, Edition 3.0, a discriminator mutator in the C++ mapping of IDL unions, as described in Section 3.14.8.8.3, is not required. For conformance to the FACE Technical Standard, Edition 3.1, a discriminator mutator in the C++ mapping of IDL unions, as described in Section 4.14.8.8.3, is not required.	3.0 3.1	26 Oct 2020
All HMFM requirements should be conditional	For conformance to the FACE Technical Standard, Edition 2.1.1, the Conformance Verification Matrix should be read as though row 1967 populates the "Conditional Requirements" column with "HMFM" value. Additionally, the CVM should be read as though row 1752 populates the "Conditional Requirements" column with "Safety Profile" and "Security Profile".	2.1.1	26 Oct 2020
Include IPV6_JOIN_GROUP and IPV6_LEAVE_GROUP Option Values for General Purpose Profile	For conformance to FACE Technical Standard, Editions 3.0, Table 32 should be read as requiring IPV6_JOIN_GROUP and IPV6_LEAVE_GROUP as required for the General Purpose Profile. For conformance to FACE Technical Standard, Editions 3.1, Table 32 should be read as requiring IPV6_JOIN_GROUP and IPV6_LEAVE_GROUP as required for the General Purpose Profile.	3.0 3.1	14 May 2021
The CTS version 2.1.1r5 incorrectly looks for some assertions in wchar.h when they have been moved to wctype.h	For conformance to the FACE Technical Standard, Edition 2.1 and Edition 2.1.1, CTS errors related to wchar.h related to the following methods or macros may be ignored. iswalnum iswalpha iswcntrl iswctype iswdigit iswgraph iswlower iswprint iswpunct iswspace iswupper iswxdigit towlower towupper wctype	2.1 2.1.1	26 Oct 2020
Approved correction for PR 223 should apply to row 1528 as well	For conformance to FACE Technical Standard, Edition 2.1.1, Rows 1528 and 1550 of the Conformance Verification Matrix (CVM) for 2.1.1 should be interpreted as though "Fully Tested Requirements" was removed from the Conformance Artifacts column. Additionally, the corresponding note about "Fully Tested Requirements" in the Verification Notes column should be ignored.	2.1.1	26 Oct 2020
Approved correction for PR 214 should apply to row 238 as well	For conformance to FACE Technical Standard, Edition 2.1.1, if an OSS UoC meets the ARINC 653 requirements for a General Purpose OSS UoC, then column of row 238 in the Conformance Verification Matrix can be read as the Conformance Artifacts column containing "UoC Designs". Note: If a General Purpose OSS UoC does not meet the ARINC 653 requirements in the Technical Standard, row 238 does not change.	2.1.1	18 Jan 2021
Include IPV6_MULTICAST_HOPS Option Value for General Purpose Profile	For conformance to FACE Technical Standard, Editions 3.0, Table 32 should be read as requiring IPV6_MULTICAST_HOPS as required for the General Purpose Profile. For conformance to FACE Technical Standard, Editions 3.1, Table 32 should be read as requiring IPV6_MULTICAST_HOPS as required for the General Purpose Profile.	3.0 3.1	14 May 2021
Constant FACE Strings Behavior Is Not Fully Defined	The Approved Correction for PR/CR 260 should define the function FACE_string_init_unmanaged_cstring() in Section K.1.4 of the FACE Technical Standard, Editions 3.0 and 3.1, with the src parameter being of type “const char *”. For conformance to the FACE Technical Standard, Edition 3.1, the FACE_string_init_unmanaged_bounded() function should be avoided in favor of the FACE_string_init_unmanaged_cstring() function.	3.0 3.1	18 Jan 2021
Inconsistent Definition of FACE_HMFM_RETURN_CODE_TYPE	For the purpose of conformance to Editions 3.0 and 3.1, the following values should be deleted from the definition of FACE_HMFM_RETURN_CODE_TYPE in F.2: FACE_HMFM_ADDR_IN_USE, FACE_HMFM_PERMISSION_DENIED, FACE_HMFM_MESSAGE_STALE, FACE_HMFM_CONNECTION_IN_PROGRESS, FACE_HMFM_CONNECTION_CLOSED, FACE_HMFM_DATA_BUFFER_TOO_SMALL	3.0 3.1	18 Jan 2021
TSS Header Uses Programming Language Mappings Requirement Should Be Deleted	For conformance to the FACE Technical Standard, Edition 3.0 Section 3.8.6 or Edition 3.1 Section 4.8.6, requirement 1 is not required.	3.0 3.1	18 Aug 2021
Add Logging API to the technical standard	For the purposes of conformance with FACE Technical Standard, Editions 3.0, 3.1, or 3.2, assume the changes described are made to that edition. Also assume Approved Correction for PR/CR 1054 which removes the requirements for Centralized Logging and Centralized Configuration has been applied. In addition, assume that non-normative text for Platform-Specific Common Services (PSCS) will be removed as a result of the Impacted Product Proposal for PR/CR 1054. Implement the changes in the document attached to PR/CR 748.	3.0 3.1 3.2	29 Apr 2024
Union Accessors	For conformance to the FACE Technical Standard, Edition 3.0 Section 3.14.8.8.3 and Edition 3.1, Section 4.14.8.8.3, the C++ union mapping rule is changed. The second mutator is removed. While it supports mutation on the left-hand side of assignment, it also accesses the union value without regard for the current discriminator. This violates the concept of a discriminated union. The signature of the accessor is changed so the compiler may distinguish it from the mutator. The accessor is const, returns void, and has two parameters of type T& and of type RETURN_CODE. An example generated declaration for a C++ union is: class FooUnion { public: enum RETURN_CODE { NO_ERROR, INVALID_STATE }; FooUnion(); FooUnion(const FooUnion&); FooUnion& operator=(const FooUnion&); ~FooUnion(); CASES::Value discriminator() const; void a(FACE::Short); void a(FACE::Short&, RETURN_CODE&) const; void b(FACE::Long); void b(FACE::Long&, RETURN_CODE&) const; };	3.0 3.1	24 Jan 2022
loss of const on FACE_sequence_at	For conformance to the FACE Technical Standard, Edition 3.0, the Sequence example in Section 3.14.7.6.2, as an example of the normative mapping rule for an IDL sequence, is revised as follows: * Each macro definition is enclosed in parentheses * The macros for _at() and _buffer() are defined with a const-cast of the return value For conformance to the FACE Technical Standard, Edition 3.1, the Sequence example in Section 4.14.7.6.2, as an example of the normative mapping rule for an IDL sequence, is revised as follows: * Each macro definition is enclosed in parentheses * The macros for _at() and _buffer() are defined with a const-cast of the return value	3.0 3.1	01 Oct 2021
MIL-STD-1553 MAX_WORD_COUNT incorrect	For conformance to the FACE Technical Standard, Edition 3.0 and 3.1, the value of the MAX_WORD_COUNT constant in Section C.3.8 should be 32, not 31, to reflect MIL-STD-1553B.	3.0 3.1	24 Feb 2021
Errors produced from template parsing: TemplateVisitorOrientedParser.PerObject	For Conformance to the FACE Technical Standard, Edition 3.0, using a zip utility place the attached log4j2.xml in the root of DAConformanceTest_v30-2020.5.1.jar and it will suppress the spurious messages.	3.0	24 Feb 2021
PR #580 Approved Correction incorrectly references tech standard section E.3.2 instead of E.4.1	For conformance to Editions 3.0 and 3.1 of the FACE Technical Standard, CR 580 Approved Correction should reference section E.4.1 instead of section E.3.2 for the purposes of conformance to the FACE::TSS:TypeAbstractionTS::Register_Callback.	3.0 3.1	22 Jun 2021
PR/CR 528 approved correction (when corrected properly) also applies to CTS 3.1 and 3.0.1	For conformance to the FACE Technical Standard, Edition 3.1, replace the files in the CTS v3.1.x conformancetestsuite\conformanceInterfaceTests\C++\OSS\POSIX\general\complex.h directory with the contents of the attached zip file.	3.1	25 Feb 2021
PR/CR 529 also applies to CTS 3.1	For conformance to the FACE Technical Standard, Edition 3.1, replace the file conformanceInterfaceTests/C++/OSS/libstdc++/general/strstream/Test000004.cpp in the CTS v3.1.x release with the Test000004.cpp file contained in the attached zip file. Also replace the goldStandardLibraries/C++/src/OSS/libstdc++/general/strstream file with the strstream file contained in the attached zip file.	3.1	25 Feb 2021
Incorrect method specification for C sequence in Approved Correction for CR 531	For conformance to the FACE Technical Standard, Editions 3.0 and 3.1, the operation to append a single element to a sequence in C per Approved Correction 531 should instead be as follows: K.1.3 FACE_sequence Specification FACE_sequence_return FACE_sequence_append_elem(FACE_sequence *seq, void * elem, size_t elem_size);	3.0 3.1	14 May 2021
Type Abstraction UoC not possible in 2.1	This Approved Correction provides guidance for how to apply the TSS requirements to different TSS UoPs in a way that allows them to be conformed as individual components. For details about this guidance, see the attached document.	2.1.1	11 Nov 2021
The FACE Consortium will not currently accept any results from this release for certifying software components as FACE	Results from the FACE Conformance Test Suite v3.1.0 are acceptable for conformance verification purposes.	3.1	22 Jun 2021
The CTS tool requires to find header files not part of the safety or security profile	For testing UoCs with the CTS v3.0 and v3.1, you may edit the C99IncludeTests.c file to comment out the lines referring to complex.h and inttypes.h.	3.0 3.1	01 Oct 2021
EGL and OpenGL Gold Standard Libraries not generated for C++ projects	For verifying a C++ UoC's usage of EGL and OpenGL using CTS 3.0 and 3.1, the following method may be applied for purpose of conformance: (1) Using the sample C project that most closely aligns with C++ UoC under test, modify the project configuration to select the desired OpenGL option. (2) Generate and build the GSLs using the modified sample C project. (3) In the toolchain configuration for the C++ UoC under test, add the OpenGL and EGL GSL directories to the "Include Paths" on the "Tools" tab. (4) In the project configuration for the C++ UoC under test, add the OpenGL and EGL GSL libraries to the "Provided Segment Objects/Libraries" on the "Objects/Libraries" tab. (5) Compile against the GSL and run CTS as normal.	3.0 3.1	01 Oct 2021
Remove pthread_setconcurrency() and pthread_getconcurrency()	For the purposes of conformance to Editions 3.0 and 3.1, the FACE OSS Profile APIs table in Appendix A.1 should be read as not having pthread_setconcurrency() and pthread_getconcurrency() included in any profile.	3.0 3.1	25 Mar 2022
channel_id description says send when it should say receive	For purposes of conforming to the FACE Technical Standard, editions 3 and 3.1, the description of the channel_id parameter in E.4.2.7 Read_From_Transport should be read as follows, "identifier for the connection on which to receive data"	3.0 3.1	19 Apr 2022
Consider calling init() method for C Struct members of struct type	This Approved Correction depends upon Approved Corrections for PR/CR 552 and PR/CR 665. For conformance to the FACE Technical Standard, Edition 3.0, an initialization function is always emitted by the C struct mapping rule in Section 3.14.7.7.1. The declaration is inline with an extern storage-class specifier, returns FACE_interface_return, and has one parameter whose type is a pointer to the structure. FACE_interface_return is defined in Section K.1.2. The definition calls the initialization function for each structure, string, sequence, and fixed member and returns FACE_INTERFACE_NO_ERROR if and only if all initialization functions called return FACE_INTERFACE_NO_ERROR. The behavior is implementation-defined if the initialization function does not return FACE_INTERFACE_NO_ERROR. For conformance to the FACE Technical Standard, Edition 3.1, an initialization function is always emitted by the C struct mapping rule in Section 4.14.7.7.1. The declaration is inline with an extern storage-class specifier, returns FACE_interface_return, and has one parameter whose type is a pointer to the structure. FACE_interface_return is defined in Section K.1.2. The definition calls the initialization function for each structure, string, sequence, and fixed member and returns FACE_INTERFACE_NO_ERROR if and only if all initialization functions called return FACE_INTERFACE_NO_ERROR. The behavior is implementation-defined if the initialization function does not return FACE_INTERFACE_NO_ERROR.	3.0 3.1	01 Oct 2021
TRANSMISSION_TYPE discrepency with MIL-STD-1553	For conformance to the FACE Technical Standard, Editions 3.0 and 3.1, the declaration of FACE::IOSS::M1553::TRANSMISSION_TYPE should reverse the order of enumerators TRANSMIT and RECEIVE, giving RECEIVE the ordinal value 0 and TRANSMIT the ordinal value 1 consistent with MIL-STD-1553 Section 4.3.3.5.1.3.	3.0 3.1	25 Mar 2022
init() function for C structs should be "static inline" and not "extern inline"	This modifies prior Approved Corrections titled "Sequence payload boundary initialization" (Ticket 552) dated 08 June 2020 and "Initialization of Fixed Data Types" (Ticket 665) dated 18 Jan 2020. For conformance to the FACE Technical Standard, Edition 3.0, the C structure initialization function described in Section 3.14.7.7.1 is declared inline with a static storage-class specifier (i.e., "static inline"). For conformance to the FACE Technical Standard, Edition 3.1, the C structure initialization function described in Section 4.14.7.7.1 is declared inline with a static storage-class specifier (i.e., "static inline").	3.0 3.1	01 Oct 2021
improve M1553.ReadWriteBuffer	For conformance to the FACE Technical Standard, Editions 3.0 and 3.1, an IOSS UoC Software Supplier may choose the FACE::IOSS::M1553_Mk2 declaration as the basis for a MIL-STD-1553 IO_Service. The existing FACE::IOSS::M1553 IO_Service remains. M1553_Mk2 offers more complete support for terminal functions and mode codes, and more robust representation of redundant simultaneous bus status conditions. The declarations are available as an IDL source file attached to Ticket 833 in the FACE PR/CR Ticketing Tool.	3.0 3.1	25 Mar 2022
DATA_OVERFLOW doesn't seem to make sense and is not clear	For purposes of conformance to the FACE Technical Standard, the DATA_OVERFLOW return code type does not need to be returned if the underlying protocols and transport types prevent overflow issues from arising. If however, DATA_OVERFLOW is indicated it should be returned for as long as the buffer overflow condition exists. Users are not assured to receive every incoming message although each message instance read should be valid. Nor are users assured its messages were distributed due to the underlying cause being associated with buffer overflows. Callbacks which return DATA_OVERFLOW may not be portable to interface to many different TSS implementations.	3.0 3.1	19 Apr 2022
CTS Tests for C++ headers/functions not part of all or specific Profiles	For conformance to the FACE Technical Standard, Edition 3.0 and 3.1, comment out #include <stdarg.h> in the following CTS files: conformanceInterfaceTests\C\OSS\POSIX\safetyBase\stdio.h conformanceInterfaceTests\C++\OSS\POSIX\safetyBase\stdio.h conformanceInterfaceTests\C\OSS\POSIX\security\stdio.h conformanceInterfaceTests\C++\OSS\POSIX\security\stdio.h Additionally, comment out the following lines from the FACEConformanceTestSuite_3.0.2\toolchain\verification\C++\StandardLibrariesTest.cpp file: #include <exception> std::terminate();	3.0 3.1	25 Oct 2021
Arrays defined in header files are missing sizes, so sizeof doesn't work	For conformance to the FACE Technical Standard, Editions 2.1, 2.1.1, 3.0, and 3.1 update the following definitions to read: goldStandardLibraries\C\src\OSS\POSIX\selected_FACE_profile\dirent.h: char d_name[NAME_MAX+1]; goldStandardLibraries\C\src\OSS\POSIX\selected_FACE_profile \sys\socket.h: char sa_data[14]; goldStandardLibraries\C\src\OSS\POSIX\selected_FACE_profile \sys\un.h: char sun_path[108]; for your given FACE OSS profile.	2.1 2.1.1 3.0 3.1	26 Oct 2021
Add Support for explicit FACE::Fixed constructor for FACE::Float in FACE 3.0 and 3.1	For conformance to the FACE Technical Standard, Editions 3.0 and 3.1, an explicit constructor for FACE::Float is added to FACE::Fixed in Section K.2.4. The declaration is: explicit Fixed(FACE::Float val);	3.0 3.1	24 Jan 2022
Remove FACE_INTERFACE_NULL_THIS in FACE 3.0 and 3.1	For conformance to the FACE Technical Standard, Editions 3.0 and 3.1, the enumerator FACE_INTERFACE_NULL_THIS for enumeration FACE_interface_return in Section K.1.2 is removed. There is no interface contract that null references are checked. This alternative was chosen to reduce the number of required test cases at each interface call for high assurance implementations.	3.0 3.1	24 Jan 2022
Add Support for FACE String/Sequencreserve() methods in FACE 3.0 and 3.1	For conformance to the FACE Technical Standard, Editions 3.0 and 3.1, the following declarations are included: For FACE_string (C language, Section K.1.4): /** * @brief Attempt to reserve memory to store @p capacity characters * @details This function is useful when @p this_obj is initialized * as a managed-unbounded string with an implementation-defined * capacity in order to perform potential reallocation at a known * point of program execution, such as during program initialization. * * On success, the implementation can store a string value of capacity * @p capacity. The function may succeed without reallocation if the * implementation-defined capacity exceeds @p capacity *and* the * implementation does not reallocate to a smaller capacity. * * If any preconditions are violated, @p this_obj's state remains * unchanged. * * Preconditions: * - @p this_obj is valid * - @p this_obj is managed * - @p this_obj is unbounded * * @retval FACE_STRING_NULL_THIS if @p this_obj is null * @retval FACE_STRING_PRECONDITION_VIOLATED if @p this_obj is not * initialized or any other preconditions are false * @retval FACE_STRING_INSUFFICIENT_MEMORY if memory allocation fails * @retval FACE_STRING_NO_ERROR otherwise. */ FACE_string_return FACE_string_reserve( FACE_string* this_obj, FACE_unsigned_long capacity ); For FACE_sequence (C language, Section K.1.3): /** * @brief Reserve storage for @p capacity elements. * @details (see #FACE_string_reserve) */ FACE_sequence_return FACE_sequence_reserve( FACE_sequence* this_obj, FACE_unsigned_long capacity ); For FACE::String (C++ language, Section K.2.3): /** * @brief Attempt to reserve memory to store @p capacity characters * @details This function is useful when an instance is constructed * as a managed-unbounded string with an implementation-defined * capacity in order to perform potential reallocation at a known * point of program execution, such as during program initialization. * * On success, the implementation can store a string value of capacity * @p capacity. The function may succeed without reallocation if the * implementation-defined capacity exceeds @p capacity *and* the * implementation does not reallocate to a smaller capacity. * * @param capacity number of elements to reserve storage for * * Preconditions: * - is_valid() == true * - is_managed() == true * - is_bounded() == false * When calling this function, if any of these preconditions are false * this String is put into the invalid state. * @retval PRECONDITION_VIOLATED if any preconditions are false * @retval INSUFFICIENT_MEMORY if memory allocation fails * @retval NO_ERROR otherwise */ RETURN_CODE reserve(FACE::UnsignedLong capacity); For FACE::Sequence (C++ language, Section K.2.2): /** * @brief Attempt to reserve memory to store @p capacity elements. * @details (see #FACE::String::reserve) */ RETURN_CODE reserve(FACE::UnsignedLong capacity);	3.0 3.1	24 Jan 2022
Invalid CTS failure - alarm API	For Conformance testing with the FACE Conformance Test Suite, Editions 3.0 and 3.1, any call by the interface tests to alarm() should be updated to use the signature “unsigned int alarm(unsigned int)”. The variable passed should be of type “unsigned int”. The GoldStandardLibrary unistd.h and unistd.c files should be updated to use the signature “unsigned int alarm(unsigned int)”.	3.0 3.1	24 Jan 2022
UDDL Requirements Filter to Apply too Broadly	For conformance to the FACE Technical Standard, Edition 3.1, the Conformance Verification Matrix should be read as though the Conditional Requirements column for rows U-4 to U-7 were marked with "Data Model".	3.1	25 Feb 2022
CTS 3.0.3 OCL: false positive errors from conceptual and logical CompositeQuery::noCyclesInConstruction constraints	For FACE conformance testing with the CTS v3.0.3, replace the files in the DMVT/DAConformanceTest_v30-*/edu.vanderbilt.isis.face.v30.architecturemodel.validation.ocl.jar file's constraints directory with the contents of the attached zip file.	3.0	10 Feb 2022
Ambiguous behavior with multiply parameters for IOSS configuration	For conformance to the FACE Technical Standard, Editions 3.0 and 3.1, Section C.2.8 and C.2.10 should denote INVALID_PARAM as the appropriate return code to indicate that 'parameters' was not assigned as one transaction.	3.0 3.1	25 Mar 2022
Remove msync() from All Profiles	For the purposes of conformance to the FACE Technical Standards Editions 3.0 and 3.1, the FACE OSS Profile APIs table in Appendix A.1 should be read as having msync() not included in any profile.	3.0 3.1	19 Apr 2022
Remove SOCK_SEQPACKET from all profiles	For the purposes of conformance to FACE Technical Standard, Edition 3.0, read Table 31: POSIX Set Socket (Use over Internet Protocols) Option Values as having SOCK_SEQPACKET removed. For the purposes of conformance to FACE Technical Standard, Edition 3.1, read Table 33: POSIX Set Socket (Use over Internet Protocols) Option Values as having SOCK_SEQPACKET removed.	3.0 3.1	25 Mar 2022
Java TSS Datatypes GSL Library Can Contain Incorrect Datatypes	For a Java UoC requiring a USM for CTS testing, manually delete the contents of the ‘goldStandardLibraries/Java/src’ CTS subdirectory before each test run.	2.1 2.1.1	19 Apr 2022
shutdown() function should not be in Security or Safety Base	For the purposes of conformance to the FACE Technical Standards Editions 3.0 and 3.1, the FACE OSS Profile APIs table in Appendix A.1 should be read as having shutdown() only included in the Safety Extended and General Purpose Profiles.	3.0 3.1	19 Apr 2022
pipe() Should be Conditional on Multiple Process Support	For the purposes of conformance to the FACE Technical Standards Editions 3.0 and 3.1, the FACE OSS Profile APIs table in Appendix A.1 should be read as having pipe() included in the Safety Extended and General Purpose Profiles only when multiple processes are supported (e.g. MP not INCL).	3.0 3.1	19 Apr 2022
CLOCK_THREAD_CPUTIME_ID Should Not be in any Profile	For the purposes of conformance to FACE Technical Standard, Edition 3.0, read Table 29: POSIX Clock and Timer Source Values and FACE Profiles as having CLOCK_THREAD_CPUTIME_ID removed from all profiles. For the purposes of conformance to FACE Technical Standard, Edition 3.1, read Table 28: POSIX Clock and Timer Source Values and FACE Profiles as having CLOCK_THREAD_CPUTIME_ID removed from all profiles.	3.0 3.1	19 Apr 2022
ARINC 653 C Library Should Not Include Timezone Support	For the purposes of conformance to Editions 3.0 and 3.1, A.8 C Library Supported Functions (as introduced in CR518) should be read as not including localtime_r(), tzname, and tzset() in any profile.	3.0 3.1	06 Jul 2022
POSIX Spawn Attribute Flags from Profiles that do not Have Methods to Manipulate Them	For the purposes of conformance to FACE Technical Standard, Edition 3.0, read Table 34: POSIX Spawn Attribute Flags as having POSIX_SPAWN_SETSCHEDPARAM and POSIX_SPAWN_SETSCHEDULER removed from the Safety Extended profile. For the purposes of conformance to FACE Technical Standard, Edition 3.1, read Table 36: POSIX Spawn Attribute Flags as having POSIX_SPAWN_SETSCHEDPARAM and POSIX_SPAWN_SETSCHEDULER removed from the Safety Extended profile.	3.0 3.1	19 Apr 2022
Remove SCHED_SPORADIC from FACE profiles	For the purposes of conformance to FACE Technical Standard, Edition 3.0, read Table 23: POSIX Thread Scheduler Policy Values in Appendix A.3 as having SCHED_SPORADIC not included in any profile. For the purposes of conformance to FACE Technical Standard, Edition 3.1, read Table 24: POSIX Thread Scheduler Policy Values in Appendix A.3 as having SCHED_SPORADIC not included in any profile.	3.0 3.1	06 Jul 2022
Remove process groups functions from profiles	For the purposes of conformance to FACE Technical Standard, Edition 3.0, Table 20: FACE OSS Profile APIs in Appendix A.1 should be read as having setsid() and getpgrp() not included in any profile. For the purposes of conformance to FACE Technical Standard, Edition 3.1, Table 21: FACE OSS Profile APIs in Appendix A.1 should be read as having setsid() and getpgrp() not included in any profile.	3.0 3.1	06 Jul 2022
Graceful transition of transaction id	For conformance to FACE Technical Standard, Editions 3.0 and 3.1 when applying CR 674, the following should also be applied: Add a note in section E.3.2.2 as part of the transaction_id parameter as follows, "Note: A TSS implementation sets transaction_id to TID_NOT_APPLICABLE to avoid an uninitialized variable. Subscribers should ignore the value set in transaction_id on receives." Add a note in section E.3.2.3 as part of the transaction_id parameter as follows, "Note: Publishers should set transaction_id to avoid an uninitialized variable. The TSS implementation is not required to return an error if transaction_id is not set to TID_NOT_APPLICABLE by a publisher. For publishers, transaction_id does not change upon return."	3.0 3.1	08 Nov 2022
mlock/mlockall Included but Associated Constants are Not	For the purposes of conformance to Editions 3.0 and 3.1, the FACE OSS Profile APIs table in Appendix A.1 should be read as not having mlock(), munlock(), mlockall(), and munlockall() included in any profile.	3.0 3.1	08 Nov 2022
Update Verification Note on Testing of Java	For the requirement at Row 1517 in CVM 2.1, the Verification Method and Conformance Artifacts values of "Test/Test Suite" should also apply for verification a UoC written in Java. For the requirement at Row 1417 in CVM 2.1.1, the Verification Method and Conformance Artifacts values of "Test/Test Suite" should also apply for verification a UoC written in Java.	2.1 2.1.1	08 Nov 2022
Clarification on PSSS Responsibilities on I/O Service Connection Requirements	For the requirement at Rows 297 and 298 in CVM 2.1, the FACE Segment column should be interpreted as not applying to "PSSS". For the requirement at Rows 299 and 300 in CVM 2.1.1, the FACE Segment column should be interpreted as not applying to "PSSS".	2.1 2.1.1	08 Nov 2022
Evidence for select() requirement (F-244) should be CTS and Inspection	For CVM 3.0, the Verification Method and Conformance Artifacts Columns for rows 227, 232, and 235 should be interpreted as also including "Test/Test Suite". An OSS UoC should still provide evidence showing the select() method supports use with sockets. The Test Suite will evaluate that the methods are correctly provided. For CVM 3.1, the Verification Method and Conformance Artifacts Columns for rows F-234, F-240, and F-244 should be interpreted as also including "Test/Test Suite". An OSS UoC should still provide evidence showing the select() method supports use with sockets. The Test Suite will evaluate that the methods are correctly provided.	3.0 3.1	08 Nov 2022
Section citations incorrect in Ticket 899	For conformance to the FACE Technical Standard, Editions 3.0 and 3.1, the Approved Correction for PR/CR 899, titled "Ambiguous behavior with multiply parameters for IOSS configuration", should refer to Sections C.2.6 and C.2.8 rather than C.2.8 and C.2.10.	3.0 3.1	08 Nov 2022
ARINC-429 LABEL_SEQUENCE should be unsigned long elements	For conformance to the FACE Technical Standard, Editions 3.0 and 3.1, the IDL declaration of LABEL_SEQUENCES for the ARINC 429 IO_Service should be an bounded array of IDL unsigned long.	3.0 3.1	08 Nov 2022
Remove Reentrant Functions From 'std' Namespace	Approved Correction 906 is incorrect and no longer applicable. The reentrant functions are required in C++ but should not be in the std namespace.	3.0 3.1	08 Nov 2022
Add More POSIX setsockopt() Option Values in FACE 3.0 and 3.1	For the purposes of conformance to Editions 3.0 or 3.1, read Table 31 in Appendix A.3 to support these in the General Purpose Profile: • SO_BROADCAST • SO_KEEPALIVE • SO_ERROR • SO_SNDTIMEO • SO_RCVTIMEO • SO_DONTROUTE Also read Table 31 in Appendix A.3 to include IP_TTL in all profiles.	3.0 3.1	08 Nov 2022
Restrict POSIX FILE SYSTEM S_IS*() functions supported to a more limited set	For the purposes of conformance to FACE Technical Standard, Edition 3.0 and 3.1 Section A.1 should be read as having the S_IS*() function-like macros annotated as follows: S_ISBLK(), S_ISCHR(), S_ISLNK() and S_ISSOCK() annotated as not supported (i.e., blank entry) for all Profiles. S_ISFIFO() annotated as supported (i.e., "INCL" entry) for the Safety Extended and General Purpose Profiles only. The annotation for S_ISDIR() and S_ISREG() remain unchanged (i.e., "INCL" entry for all Profiles except for the Security Profile).	3.0 3.1	08 Nov 2022
IO_Service for multiple discrete lines per connection	For conformance to the FACE Technical Standard, Editions 3.0, 3.1, and 3.2 an IOSS UoC Software Supplier may choose the FACE::IOSS::MultiChannelDiscrete and FACE::IOSS::MultiChannelAnalog declarations. The existing FACE::IOSS:Discrete and FACE::IOSS::Analog remain. The declarations are available as an IDL source file attached to Ticket 980 in the FACE PR/CR Ticketing Tool.	3.0 3.1 3.2	24 Jan 2024
The requirements for the operator[] override in the C++ header for String.hpp leads to confusing behavior	For conformance to the FACE Technical Standard, Editions 3.0, 3.1, and 3.2, the description of FACE::String::operator[] should read as follows: /** * @brief Returns a reference to the character at a given index. * @details If @p index is out of range, the behavior is * implementation-defined. Out of range is defined as greater * than the value returned by length(). Strings use a zero-based * index. * * @param index The index of the element to be retrieved * @return a reference to the desired element. */	3.0 3.1 3.2	08 Nov 2022
<sys/ioctl.h> commands defined but arguments to those are unspecified	For the purposes of conformance Edition 3.0, section 3.2.1.2 requirement 10(a) or Edition 3.1, section 4.2.1.2 requirement 10(a), read as if the following sentences were present to clarify FIONBIO: "The argument is an integer which if 0, non-blocking input/output on the socket is cleared. Otherwise, the socket is set for non-blocking input/output." For the purposes of conformance Edition 3.0, section 3.2.1.2 requirement 10(b) or Edition 3.1, section 4.2.1.2 requirement 10(b), read as if the following sentence were present to clarify SOCKCLOSE: "The argument is an integer which is the file descriptor number of the socket to close."	3.0 3.1 3.2	08 Nov 2022
Update Characterization of PCS/PSSS UoC OpenGL Requirements	For CVM 3.0, the Verification Method and Conformance Artifacts columns for Row IDs 1281 through 1288 and 1319 through 1326 marked as "Y" should be read as reading "Test" and "Test Suite". The Conditional Requirements column for 1281, 1290, 1292, 1294, 1319, 1328, 1330, and 1332 should be read as only containing the value "EGL". The Conditional Requirements column for 1283 through 1288, 1321 through 1326, and 1333 should be read as also containing the value "OpenGL SC". For CVM 3.1, the Verification Method and Conformance Artifacts columns for Row IDs F-1430 through F-1437, F-1469 through F-1474, and F-1477 marked as "Y" should be read as reading "Test" and "Test Suite". The Conditional Requirements column for F-1430, F-1439, F-1441, F-1443, F-1469, F-1479, F-1481, and F-1482 should be read as only containing the value "EGL". The Conditional Requirements column for F-1433 through F-1435, F-1472 through F-1474, and F-1484 should be read as also containing the value "OpenGL SC".	3.0 3.1	28 Feb 2023
pthread_cond_destroy() should not be in the Safety Base profile (all FACE Editions)	For the purposes of conformance to Editions 3.0, 3.1, and 3.2, the FACE OSS Profile APIs table in Appendix A.1 should be read as not having pthread_cond_destroy() included in the Safety Base profile. For the purposes of conformance to Edition 2.1.1, the FACE OSS Profile APIs table in Appendix A should be read as not having pthread_cond_destroy() included in the Safety Base profile.	2.1.1 3.0 3.1 3.2	28 Feb 2023
GSL Makefiles ignored	For conformance testing with CTS v3.0.5/v3.1.4 or earlier, copy the source files from the corresponding directory in “goldStandardLibraries/C/src/OSS/libc_ARINC653/<FACE_PROFILE>” to “goldStandardLibraries/C++/src/OSS/libstdc++_ARINC653/<FACE_PROFILE>”. Rename files from *.c to *.cpp.	3.0 3.1	22 Feb 2023
Remove Non-portable Native Handles from C++11/14 Multi-Threading Capability Set	For the purposes of conformance to the FACE Technical Standard, Edition 3.2, Section 4.2.3.3.2.1, the second bullet should be read as follows: "C++ thread support library (ISO/IEC 14882:2011/2014, §30) is included, except for capabilities associated with native handles (ISO/IEC 14882:2011/2014, §30.2.3) Note: Native handle members and their semantics are implementation-defined and are inherently non-portable."	3.2	26 Apr 2023
C++03 Missing Allowance for long long Type	For the purposes of conformance to Edition 3.0, sections 3.2.3.3.1, 3.2.3.3.2, and 3.2.3.3.3, supported capabilities include the long long and unsigned long long types as defined by the C99 standard. For the purposes of conformance to Edition 3.1, sections 4.2.3.3.1, 4.2.3.3.2, and 4.2.3.3.3, supported capabilities include the long long and unsigned long long types as defined by the C99 standard. For the purposes of conformance to Edition 3.2, sections 4.2.3.3.1, 4.2.3.3.3, and 4.2.3.3.5, supported capabilities include the long long and unsigned long long types as defined by the C99 standard.	3.0 3.1 3.2	26 Apr 2023
Lack of Mapping for Forward Declared Structs from IDL to Ada	For conformance to the FACE Technical Standard, Edition 3.0, the IDL to Ada mapping rules in Section 3.14.9 are amended as described in the attachment to PR/CR 1045 with respect to a forward declaration of a sequence element type. For conformance to the FACE Technical Standard, Edition 3.1 and Edition 3.2, the IDL to Ada mapping rules in Section 4.14.9 are amended as described in the attachment to PR/CR 1045 with respect to a forward declaration of a sequence element type.	3.0 3.1 3.2	31 Aug 2023
CSP::Open When Named Store is Already Open Not Handled like Create_Connection	For purposes of conformance to FACE Technical Standard ed 3.2, the return codes in section E.3.4.2 should read as follows: INVALID_PARAM to indicate a resource with this name has already been created successfully without an intervening Close(CSP) or one or more parameters supplied is null or not in range. NOT_AVAILABLE to indicate the CSP is not yet initialized or the underlying storage medium is unavailable and cannot return a valid token. If NOT_AVAILABLE is returned, the caller should retry Open(CSP) until something other than NOT_AVAILABLE is returned. NO_ERROR to indicate the UoC's data store was successfully opened from this or a previous invocation of Open(CSP) which returned NOT_AVAILABLE.	3.2	31 Aug 2023
Make PSCS Logging, Configuration, and System Health Use Cases in RIG	For conformance to the FACE Technical Standard, Edition 3.0, the requirements in the following Sections are considered not applicable: • Section 3.6.3.1: Platform-Specific Common Services Requirements • Section 3.6.3.1.1: Logging Services Requirements • Section 3.6.3.1.4: Centralized Configuration Service Requirements • Section 3.6.3.1.5: System Level Health Monitoring Requirements For conformance to the FACE Technical Standard, Edition 3.1 and Edition 3.2, the requirements in the following Sections are considered not applicable: • Section 4.6.3.1: Platform-Specific Common Services Requirements • Section 4.6.3.1.1: Logging Services Requirements • Section 4.6.3.1.4: Centralized Configuration Service Requirements • Section 4.6.3.1.5: System Level Health Monitoring Requirements	3.0 3.1 3.2	31 Aug 2023
Remove or Update DPM requirements in light of injectable interface.	For conformance to the FACE Technical Standard, Edition 3.0, the requirements in the following Sections are considered not applicable: • Section 3.6.1: Platform-Specific Services Segment Requirements, #4 the DPM exception is removed • Section 3.6.2.1: Platform-Specific Device Services Requirements, #3 • Section 3.6.3.1.2: Device Protocol Mediation Requirements For conformance to the FACE Technical Standard, Edition 3.1 and Edition 3.2, the requirements in the following Sections are considered not applicable: • Section 4.6.1: Platform-Specific Services Segment Requirements, #4 the DPM exception is removed • Section 4.6.2.1: Platform-Specific Device Services Requirements, #3 • Section 4.6.3.1.2: Device Protocol Mediation Requirements This Approved Correction is associated with ticket #1055.	3.0 3.1 3.2	29 Apr 2024
PSGS requirement redundant with Graphics Services section	For conformance to the FACE Technical Standard, Edition 3.0, the requirement in Section 3.6.4.1 is considered not applicable. For conformance to the FACE Technical Standard, Edition 3.1 and Edition 3.2, the requirement in Section 4.6.4.1 is considered not applicable.	3.0 3.1 3.2	31 Aug 2023
CTS 2.x tests for presence of va_copy() which is not part of C++03	For testing of an OSS UoC provision of C++03, a failing test in stdarg.h or cstdarg for va_copy() can be ignored. (Note: This does not apply to the corresponding test in POSIX.)	2.1 2.1.1	05 Jul 2023
Clarify create_connection INVALID_PARAM return code	For purposes of conformance to FACE Technical Standard ed 3.2, the return codes should read as follows: INVALID_PARAM in section E.3.1.2 to read, "to indicate a connection with this name has already been created successfully without an intervening Destroy_Connection(Base) or one or more parameters supplied is null or not in range" NOT_AVAILABLE to indicate the TS is not yet initialized or the underlying technology is unavailable and cannot return a valid connection_id. If NOT_AVAILABLE is returned, the caller should retry Create_Connection(Base) until something other than NOT_AVAILABLE is returned. NO_ERROR in section E.3.1.2 to read, "to indicate the TS-UoP connection was successfully created from this or a previous invocation of Create_Connection (Base) which returned NOT_AVAILABLE"	3.2	03 Aug 2023
Redundant Requirements in Message Pattern Translation	For purposes of conformance to the FACE Technical Standard ed 3.0, consider 3.7.10 requirement #3 as deleted. For purposes of conformance to the FACE Technical Standard ed 3.1 or later, consider 4.7.10 requirement #3 as deleted.	3.0 3.1 3.2	05 Jul 2023
Read(CONFIG) buffer content	For the purposes of conformance to FACE Technical Standard, Editions 3.0, 3.1, and 3.2, the bullet following the description of the element parameter to the Read(CONFIG) method in Section G.2.4 should be read as follows: • “all” to indicate that the intent is to read all data from the configuration container as a stream. The format of the data returned in buffer may be binary or a NULL terminated ASCII string. • Any other value is treated as a key which is used to look up the associated value. The value will be returned in buffer as a NULL terminated ASCII string. Note: The container instance will only support one of these modes of operations. Both data formats may not be supported by all underlying configuration media. Note: A UoC will use a container instance for either binary or key/value pairs and is required to provide an XSD of the configuration data it expects. It may use multiple container instances to obtain both formats of configuration data.	3.0 3.1 3.2	05 Jul 2023
Configuration::Read() has no error condition for "not found"	For conformance to the FACE Technical Standard, Editions 3.0 through 3.2, the second bullet of G.2.4 for Read(CONFIG) should be read as INVALID_CONFIG is to be returned when the configuration set specified by set_name is not found. Similarly, the third bullet should be read to include that if set_name is NULL, then INVALID_PARAM should be returned.	3.0 3.1 3.2	05 Jul 2023
Ada mapping rule for sequence can emit duplicate types	Note this Approved Correction is linked to the Approved Correction for PR/CR 1045. They are confirmed as adjacent and not overlapping. For conformance to the FACE Technical Standard, Edition 3.0, the IDL to Ada mapping rules in Section 3.14.9.6.2 are amended as described in the attachment to PR/CR 1067 with respect to instantiating sequence packages of the same element type. For conformance to the FACE Technical Standard, Edition 3.1 and Edition 3.2, the IDL to Ada mapping rules in Section 4.14.9.6.2 are amended as described in the attachment to PR/CR 1067 with respect to instantiating sequence packages of the same element type.	3.0 3.1 3.2	31 Aug 2023
IPV6 should be included in all profiles	For purposes of conformance to Editions 3.0, 3.1, or 3.2, Table 32 in Appendix A should be read as including IPV6_MULTICAST_IF and IPV6_MULTICAST_LOOP as only required in the General Purpose Profile.	3.0 3.1 3.2	31 Aug 2023
Add Ada Capability Set Testing for Verification of non-OSS UoCs	For conformance to FACE Technical Standard, Editions 3.0, 3.1 and 3.2, Ada UoCs should use the Ada Toolchain Assessment Test Suite (TCATS) attached to FACE PR/CR 1070 to determine what aspects of the Ada Programming Language Capability Sets an Ada toolchain detects or does not detect. For any aspect of the Capability Set shown by TCATS to not be detected by the toolchain, the Supplier is responsible for providing verification artifacts showing a UoC meets the aspects the toolchain cannot detect. No verification evidence is required for aspects of the Capability Set TCATS shows the toolchain does detect beyond a successful execution of the CTS.	3.0 3.1 3.2	15 Aug 2024
Clarify Allowability of POSIX Inter-UoC Functions Use in PCS/PSSS	For the purposes of conformance to FACE Technical Standard, Editions 3.0, 3.1, and 3.2, the following paragraph should be replaced: "The Inter-UoC column includes a “YES” for those APIs whose Inter-UoC usages are restricted to Transport Services and I/O Services." The replacement text is as follows: "The Inter-UoC column includes a “YES” for those APIs whose Inter-UoC usages are restricted to Transport Services and I/O Services. These capabilities can also be utilized for Intra-UoC communications (along with other capabilities restricted to Intra-UoC use only)."	3.0 3.1 3.2	05 Jul 2023
TPM Open_Channel alignment to TS Create_Connection	For purposes of conformance to the FACE Technical Standard, ed 3.2 a TPM's Open_Channels return codes in section E.4.2.3 should read as follows, INVALID_PARAM to indicate a channel with this name has already been created successfully without an intervening Close_Channel(TPM) or one or more parameters supplied is null or not in range. NOT_AVAILABLE to indicate the TPM is not yet initialized or the underlying technology is unavailable and cannot return a valid channel_id. If NOT_AVAILABLE is returned, the caller should retry Open_Channel(TPM) until something other than NOT_AVAILABLE is returned. NO_ERROR to indicate the TS-TPM channel was successfully created from this or a previous invocation of Open_Channel(TPM) which returned NOT_AVAILABLE.	3.2	31 Aug 2023
QoS Should be Optional for TPMs	For purposes of conformance to the FACE Technical Standard ed 3, QoS management is optional for TPMs in Table 7	3.0 3.1 3.2	22 Jan 2024
Ada Capability Set Consistency and Refinement Updates	For the purposes of conformance to the FACE Technical Standard ed 3.2, Section 4.2.3.4 in the Technical Standard should be interpreted as including the additions and deletions attached to the Approved Correction for Ticket 1108.   For the purposes of conformance to the FACE Technical Standard ed 3.1, Section 4.2.3.4 in the Technical Standard should be replaced by Section 4.2.3.4 attached to the Approved Correction for Ticket 1108.  (Note:  The memory management consistency updates identified by Ticket 466 and introduced in ed 3.2 are also applied to ed 3.1 via this Correction, but documentation of Ticket 466 is not required as there is no associated Approved Correction.)  For the purposes of conformance to the FACE Technical Standard ed 3.0, Section 3.2.3.4 in the Technical Standard should be replaced with the content of Section 4.2.3.4 attached to the Approved Correction for Ticket 1108.  Additionally, UoCs using Ada 2012 and targeting the Safety Extended, Safety Base, or Security OS Profiles must document the Approved Correction for Ticket 387.  (Note:  The memory management consistency updates identified by Ticket 466 and introduced in ed 3.2 are also applied to ed 3.0 via this Correction, but documentation of Ticket 466 is not required as there is no associated Approved Correction.)	3.0 3.1 3.2	29 Apr 2024
Data Store Capability should be optional for TPM	For purposes of conformance to the FACE Technical Standard, ed 3.0 requirements 3.7.12 #4 and #5 are not applicable. Additionally, it should be considered optional in table 7 for the TA and TPM UoCs to provide the data store capability with the following clarification. "*Sections 3.10.1 requirement #10 and 3.6.1 requirement #13 require PCS and PSSS UoCs to use the TypedTS interface for reading and writing to data stores. Therefore, more than one TSS UoC is required to support PCS/PSSS UoCs’ use of data stores. However, a TA or TPM UoC can satisfy the requirements in 3.7.12 wholly to access data store devices." For purposes of conformance to the FACE Technical Standard, ed 3.1 and 3.2, requirements 4.7.12 #4 and #5 are not applicable Additionally, it should be considered optional in table 7 for the TA and TPM UoCs to provide the data store capability with the following clarification. "*Sections 4.10.1 requirement #14 and 4.6.1 requirement #15 require PCS and PSSS UoCs to use the TypedTS interface for reading and writing to data stores. Therefore, more than one TSS UoC is required to support PCS/PSSS UoCs’ use of data stores. However, a TA or TPM UoC can satisfy the requirements in 4.7.12 wholly to access data store devices."	3.0 3.1 3.2	15 Aug 2024
C and C++ common headers share macro names	For conformance to FACE Technical Standard Editions 3.0, 3.1, and 3.2, the mapping changes outlined the document attached to PR/CR 1179 should be applied to constants generated as part of FACE Interfaces.	3.0 3.1 3.2	04 Jun 2024
posix_devctl() should be marked as IPC	For the purposes of conformance to Editions 3.0, 3.1, and 3.2, the FACE OSS Profile APIs table in Appendix A.1 should be read as having "YES" in the "Inter-UoC" column in the row for posix_devctl().	3.0 3.1 3.2	14 May 2024
Common.idl does not match source in the repository	For conformance to FACE Technical Standard, Edition 3.2, the Common.idl code in Section B.2 should use the uploaded IDL file attached to FACE PR/CR 1191 in the PR/CR tool.	3.2	04 Jun 2024