MILITARY & DEFENCE
Figure 2: Operating system segment with FACE
interfaces between the segments. Each segment consists of one or more software components. Each of those components must be shown to be fully conformant to the FACE Technical Standard requirements applicable to the segment to which it contributes. The FACE Conformance Test Suite automates the verifi cation of some of the conformance requirements. A certifi cate of conformance is awarded following successful reviews by a FACE Verifi cation Authority and a FACE Certifi cation Authority. A component that has been certifi ed in this way is known as a FACE Unit of Conformance (UoC). Optionally, a software developer can register their UoC to appear in the FACE Registry.
FACE operating system segment Foundational system services reside in the FACE Operating System Segment (OSS). These services are provided by OSS UoCs and include the control of access to the computing platform, support for the execution of all FACE UoCs, and the hosting of operating systems interfaces.
The platform software that resides directly on hardware runs here. The benefi t of writing this code using FACE APIs is that it becomes far easier to migrate this code between different systems and different hardware. There are different profi les associated with the OSS, namely: 1. Security Profi le: Most restricted Application Programming Interfaces (APIs), and therefore, the smallest attack service 2. Safety Profi le: A superset of the security profi le, intended for applications that require safety certifi cation. The Safety Base Sub-profi le supports single POSIX process applications with a broader OS API set than the Security Profi le. The Safety Extended Sub-profi le includes all of the Safety Base Sub-profi le OS APIs along with additional OS APIs and optional support for multiple POSIX processes. 3. General-Purpose Profi le: Widest set of APIs
12 NOVEMBER 2022 | ELECTRONICS TODAY
Figure 3: Interactions between a FACE UoC software supplier, and FACE authorities and administrators
to support rich applications that do not need a real-time or deterministic response Developers pick the profi le that best addresses the need for their application. It is important to note that both the Safety and Security profi les include time and space partitioning. This originates from the ARINC 653 standard and delivers hard isolation between applications running on a platform. This means that a problem in one area of a system remains sandboxed in that area and does not cascade into other areas.
FACE Conformance Program The FACE Conformance Program provides the conformance criteria and processes necessary to assure that UoCs are developed according to the FACE Technical Standard. These criteria and processes require the verifi cation, certifi cation, and optionally registration of the UoC. FACE Verifi cation: Determining the conformance of the UoC to FACE Technical Standard requirements. Verifi cation is handled through a FACE Verifi cation Authority (VA), such as LDRA Certifi cation Services (LCS). FACE Certifi cation: Applying for FACE Conformance Certifi cation once verifi cation has been completed. Certifi cation is processed through the FACE Certifi cation Authority (CA). FACE Registration: Publicly listing the FACE Certifi ed UoC in the FACE Registry. The FACE Technical Standard represents the source of requirements for the verifi cation and certifi cation of a UoC. In support of the standard, the FACE Consortium has also created a Conformance Verifi cation Matrix (CVM). It lists and categorises the requirements that a product must meet in order to be certifi ed as FACE Conformant, along with the specifi c techniques to be used to verify each of those requirements.
Conformance: An example from Collins Aerospace
Collins Aerospace is committed to FACE Conformance and earned the fi rst FACE Conformance Certifi cation in 2016 for the Mission FMS.
The Tactical Combat Training System (TCTS) Increment II program is one important example of using open standards to provide multi domain Live, Virtual and Constructive (LVC) training capabilities to modern warfi ghters. The underlying system (called the Joint Secure ACMI System (JSAS)) utilises an open systems architecture incorporating the FACE Technical Standard and other industry interface standards to allow interfacing with a variety of monitoring and debriefi ng systems. It’s scalability, enables training scenarios from individual to large force, home stationed to deployed, and across service, allied and coalition security boundaries.
Developing software in accordance with any standard is hard. The concurrent application of project requirements, coding standards, the FACE Technical Standard and functional safety standards provide a logistical challenge for any project manager. Automating that traceability is a boon, especially in the face of changing functional requirements, or failed tests. Working with a FACE Verifi cation Authority from the beginning of the project is likely to minimise any surprises later.
Ultimately, the proof of the principles lies in the ability to fi eld software more quickly and at lower cost. That ability is ably demonstrated by the success of Collins’ Tactical Combat Training System (TCTS) Increment II program, whose underlying system utilises an open systems architecture incorporating FACE and other industry interface standards.
LDRA
Idra.com/face/
Lynx Software Technologies
www.lynx.com
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44
