Applicable Technical Standard:
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
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
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
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);
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
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
Access the FACE PR/CR Ticketing System

FACE CONSORTIUM SPONSOR MEMBERS