Guest Editorial MT 2/2022 · 5 In a typical scenario, a FACE-conformant avionics application resides in the Portable Components Segment (PCS). It invokes RTOS services portably, either via a POSIX or ARINC 653 API provided by the Operating System Segment (OSS), or through standard programming language syntax (in C, C++, Ada 95, Ada 2012, or Java). If the application needs to communicate with other PCS software, it uses functions from the Transport Services Segment (TSS). The TSS interfaces are defined in IDL, enabling type-safe communication between components written in different programming languages. The FACE Technical Standard accounts for safety and security considerations by defining POSIX and ARINC-653 subsets known as ‘profiles’ (Security, Safety Base, Safety Extended, and General Purpose) for accessing OSS services, with space and/or time partitioning based on the profile. Since programming languages like C++, Ada, and Java realise run-time functionality through standard language syntax, rather than API calls, the Technical Standard likewise defines language subsets (‘capability sets’) with restrictions on permitted features. FACE conformance with a safety or security profile/capability set does not guarantee specific assurance properties, but it avoids features that could complicate safety or security certification. Using a language like Ada can help. Ada was designed to directly support developing high- assurance software, and its contract-based programming features facilitate demonstrating specific safety or security properties. The FACE approach is gaining momentum, with more and more procurements requiring FACE conformance. Although the FACE Consortium has been US-centric thus far, the aerospace and defence industry for allied counties is multinational, and plans are underway to allow international participation (initially Australia, Canada, New Zealand, and the United Kingdom). As companies and projects come on board, the reuse benefits can finally be realised. Further general information is available at https://www.opengroup.org/face, or https://www.adacore.com/industries/defense/face for details of AdaCore’s support for the FACE effort. Reuse has been a goal for software developers since the earliest days. In principle, it should be possible to take a component designed for one system and redeploy it in a new application and/or different platform. In practice, life is not so simple. A number of issues have inhibited effective software reuse, but an initiative being shepherded by the US Department of Defense – the Future Airborne Capability Environment (FACE) effort – offers an innovative solution for military airborne systems. The exponential increase in computing performance and capacity over the years has enabled new and complex functionality in modern aircraft, and software has become the dominant factor influencing cost. However, military system procurers and contractors have rarely focused on ensuring that software components can be reused in other systems, or ported to different platforms. One result has been vendor lock-in, incurring high costs for component porting. Differences in processor, Real-Time Operating System (RTOS), peripherals, etc., can require significant effort to adapt the software. One factor inhibiting reuse is contractual: designing a reusable component requires additional effort up front, but the savings only show up on future systems. There is little financial incentive to design for reuse. Licensing is a related impediment, if reusing the original software is restricted or prohibited. Other issues are technical. Effective reuse of a component requires the developer to carefully specify its interface, including prerequisites (conditions for using the component) and obligations (conditions that the component brings about). Portability, a type of reuse, entails avoiding platform dependencies (eg, word size, address range, operating system functions). These issues are not new. Reuse and portability have been topics of focus amongst programming language and software methodology researchers and practitioners for decades, with notable results. Modern programming languages provide features directly supporting reuse (eg, object orientation, data encapsulation, generic templates, contract-based programming), and reuse at the level of programme libraries is common practice. Similarly, through standard language semantics and pragmatic style conventions, programmers can write portable source code (ie, having equivalent effects when compiled for different target machine architectures). The challenge is to achieve reuse on a wider scale, at the level of software components encapsulating specific airborne software functionality. The FACE Consortium was founded in 2010 to meet this challenge. Chartered under The Open Group and comprising representatives from government, industry, and academia, the FACE Consortium has formulated a two-pronged approach: • A Technical Standard defining requirements for software portability and reuse, with supporting procedures to check conformance; and • Business processes addressing procurement practice and incentivizing industry to produce FACE conformant products. At the heart of the FACE Technical Standard is a reference architecture with well-defined interfaces based on open industry standards (POSIX, ARINC-653, IDL). The architecture comprises several layers (known as segments) and separates platform-specific and platform-independent behavior. The FACE technology also specifies a data modeling architecture enforcing a consistent view of data exchanged between software components. Dr Benjamin Brosgol, Senior Technical Staff, Adacore Software Reuse for Airborne Systems: the FACE Approach Dr Brosgol is a member of the senior technical staff at AdaCore. He has been actively involved with the FACE effort since 2017 and is currently Vice Chair of the FACE Consortium’s Technical Working Group. Dr Benjamin Brosgol, a senior member of Adacore’s technical staff, is currently Vice Chair of the FACE Consortium’s Technical Working Group. (Photo: Adacore)
RkJQdWJsaXNoZXIy MTM5Mjg=