FACE Special Edition 2022 by OpenSystems Media

SPECIAL EDITION 2022 | Volume 1 | Number 1 www.opengroup.org/face

FACE Special Edition

2022

To subscribe to the Avionics Design e-newsletter and Military Embedded Systems magazine and receive future copies of the FACE Special Edition, CLICK HERE. To subscribe to The Open Group’s FACE E-newsletter, CLICK HERE.

Q and A with Joe Carter, chair of the FACE Steering Committee

@theopengroup

2022 VOLUME 1 NUMBER 1

EDITOR’S PERSPECTIVE

FACE Special Edition

By John McHale, Editorial Director

FACE FEATURES

p.20

Making software con ormant an y orta e o in i ance or a By Benjamin M. Brosgol, AdaCore

Three quick questions …

Q and A with Joe Carter, chair of the FACE Steering Committee

8 10 16 20

… with Chip Downing, chair of the Outreach Subcommittee of The Open Group’s FACE Business Working Group

FACE Membership List

FACE Consortium Information Virtualization: A FACE lift for vehicle control By Will Keegan, Lynx Software Technologies

Making software FACE-conformant and fully portable: Coding guidance for Ada By Benjamin M. Brosgol, AdaCore

FACE combats existential threats to advance global competitiveness in airborne systems By Chip Downing, Real-Time Innovations (RTI)

FACE combats existential threats to advance global competitiveness in airborne systems By Chip Downing, Real-Time Innovations (RTI) p.24

Digital avionics displays from the cockpit to the helmet to the holograph By Sally Cole, Senior Editor

FACE SPEAKOUTS AND PROFILES

12 32

FACE Speakouts FACE Proﬁles

ON THE COVER

Digital avionics displays from the cockpit to t e e met to t e o o ra By Sally Cole, Senior Editor p.28

The UH-60V Black Hawk helicopter leverages FACE Technical Standard certiﬁed conferment solutions. Pictured is the interior of a UH-60V Black Hawk helicopter on display at a ribbon-cutting ceremony at the Eastern Army National Guard Aviation Training Site (EAATS) at Fort Indiantown Gap, Pennsylvania. EAATS was the ﬁrst unit in the Army – active duty, National Guard, or Army Reserve – to receive the new variant, which includes an upgraded digital glass cockpit. U.S. Army photo by Brad Rhen.

2 | FACE Special Edition 2022

www.opengroup.org/face

Editor’s Perspective By John McHale, Editorial Director

FACE Special Edition By John McHale, Editorial Director Welcome to the FACE Special Edition, which covers the technology behind The Open Group’s Future Airborne Capability Environment (FACE) Technical Standard . . This maga ine is the first of what will be an annual issue, highlighting editorial content on FACE from the pages and website of Military Embedded Systems magazine, together with the products aligned and certified conformant to the standard. This FACE Special Edition is similar to our S SA Special Edition, published last fall concurrent with the release of the Sensor Open Systems Architecture (SOSA) Technical Standard Rev 1.0. While FACE is a more mature standard than S SA, they share the goal of enabling commonality across multiple platforms through an open architecture approach that reduces life cycle costs. During a presentation at the FACE/SOSA Technical Interchange Meeting event in September , eff Howington of Collins Aerospace and at the time vice chairman of the FACE Consortium Steering Committee noted that software costs in new platforms can be unwieldy, especially considering that to of avionics capability lies in software. ater, as I recorded the McHale Report podcast with Howington, I asked him how FACE would reduce those costs. ne of the biggest cost drivers the FACE Consortium set out to conquer was the common practice of developing different software for different platforms that implement the same capability,” he asserted. y conforming to the FACE Technical Standard, you can produce software for portability and reusability, and therefore reduce duplicative development efforts. Standardi ation allows reusability while reducing integration efforts because it puts everyone on the same page with respect to the overall architecture, interfaces, and data definitions. www.opengroup.org/face

If the software also meets criteria, then it becomes possible to reuse both the software and its certification artifacts in another system, saving additional time and cost.”

FACE and MOSA

The FACE Consortium, founded in , was an early example of a modular open systems approach M SA). Fast-forward to The success of FACE helped fuel Army, Air Force, and Navy leadership’s decision to mandate a M SA approach for all new program designs and refreshes, calling M SA a warfighting imperative. Signed by the secretary of each service, the memo stated that “development of a modular open systems approach M SA) in areas where we lack them is vital to our success.” The missive also mentioned FACE, SOSA, and other standards by name as examples of M SA. The founders of the FACE Consortium deserve credit for establishing a strong foundation and incorporating the M SA principles,” says Joe Carter, Systems Engineering Lead at the U.S. Army PEO rogram Executive ffice Aviation and the chair of the FACE Steering Committee in a Q and A on page 6. In addition to being a warfighting imperative, FACE and M SA are also economic imperatives, as Howington explained. Government can no longer fund technology development from the ground up or continue to invest in closed architectures. It’s economically unsound. FACE’s proven results have broadened the standard’s reach Today the consortium boasts more than 90 member organi ations from industry, academia, and government. FACE certified conformant solutions are already ying in platforms like the Army UH-60V Black Hawk helicopter pictured on our cover. “The FACE Technical Standard is now required in nearly all new U.S. military

John.McHale@opensysmedia.com

avionics programs,” says Chip Downing, Senior Market evelopment irector, Aerospace efense at TI and Chair, FACE Business Working Group Outreach Subcommittee in a Q and A on page 5. The .S. Army Future ertical ift program is a good example of this effort. Having been around for more than a decade and now in version 3.1, the FACE Technical Standard benefits pilots, prime contractors, and software suppliers. Howington explains why: Aircraft operators and pilots can benefit from reuse by having interoperable capabilities with similar look and feel, he says. rime contractors benefit from standardization, allowing them to pick best-in-class products from a wider variety of suppliers while lowering integration costs. The benefit for hardware and software suppliers is the ability to compete in a larger addressable market that can better integrate their products. For FACE procurement examples, visit: www.opengroup.org face procurements. M SA approaches like FACE and S SA continue to gather momentum and we’ll continue to cover them like we’ve covered open standards for years at penSystems Media, dating back to our first publication ME us Maga ine still published today as VITA Technologies. Helping bring this issue together were Reggie Hammond and her colleagues at The Open Group. A big thank you as well to Chip Downing, who helped in his role with the FACE Outreach Subcommittee. To be part of future FACE and S SA Special Editions or to contribute content to Military Embedded Systems maga ine and our Avionics Design e-newsletter, reach out to me (john.mchale@opensysmedia.com) and assistant managing editor Lisa Daigle (lisa.daigle@opensysmedia.com). Thanks for joining us. FACE Special Edition 2022 |

Gold Sponsors PG

SPONSOR

Ansys – Develop ARINC 661 compliant avionics software aligned to the FACE technical standard

Ansys – Executive Speakout

Skayl – Scale anything. Integrate everything.

Skayl – Executive Speakout

RTI – RTI Connext TSS

RTI – Executive Speakout

GROUP EDITORIAL DIRECTOR

ohn McHale john.mchale@opensysmedia.com

ASSISTANT MANAGING EDITOR Lisa Daigle lisa.daigle@opensysmedia.com TECHNOLOGY EDITOR Emma Helfrich emma.helfrich@opensysmedia.com CREATIVE DIRECTOR Stephanie Sweet stephanie.sweet@opensysmedia.com WEB DEVELOPER Paul Nelson paul.nelson@opensysmedia.com EMAIL MARKETING SPECIALIST WEBCAST MANAGER

rew aufman drew.kaufman@opensysmedia.com yan raff ryan.graff@opensysmedia.com

VITA EDITORIAL DIRECTOR Jerry Gipper jerry.gipper@opensysmedia.com

SALES/MARKETING

Advertiser Index PG 39 14 14 19 27 31 26

DIRECTOR OF SALES AND MARKETING Tom Varcie tom.varcie@opensysmedia.com (734) 748-9660

ADVERTISER Abaco Systems – The hardware your software deserves Abaco Systems – Executive Speakout AdaCore Technologies – Executive Speakout Parasoft – Ensure FACE conformance & DO-178C compliance with one unified solution The Open Group – The FACE Approach United Electronic Industries – Ready. Reliable. Rugged test & control systems Wolf SSL – Let’s talk security!

DIRECTOR OF MARKETING Eric Henry eric.henry@opensysmedia.com OPERATIONS & AUDIENCE DEVELOPMENT (541) 760-5361 STRATEGIC ACCOUNT MANAGER Rebecca Barker rebecca.barker@opensysmedia.com (281) 724-8021 STRATEGIC ACCOUNT MANAGER Bill Barron bill.barron@opensysmedia.com (516) 376-9838 STRATEGIC ACCOUNT MANAGER Kathleen Wackowski kathleen.wackowski@opensysmedia.com (978) 888-7367 SOUTHERN CAL REGIONAL SALES MANAGER Len Pettek len.pettek@opensysmedia.com (805) 231-9582 DIRECTOR OF SALES ENABLEMENT Barbara Quinlan barbara.quinlan@opensysmedia.com AND PRODUCT MARKETING (480) 236-8818 INSIDE SALES Amy Russell amy.russell@opensysmedia.com TAIWAN SALES ACCOUNT MANAGER Patty Wu patty.wu@opensysmedia.com CHINA SALES ACCOUNT MANAGER Judy Wang judywang2000@vip.126.com EUROPEAN MARKETING SPECIALIST Steven Jameson steven.jameson@opensysmedia.com +44 (0)7708976338 SENIOR EUROPEAN MARKETING SPECIALIST Alastair Swift alastair.swift@opensysmedia.com +44 7910 073565

Profile Index ADVERTISER

Transport Services Segment (TSS) Real-Time Innovations (RTI) . . . . . . . . . 32 Skayl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Jovian Software Consulting . . . . . . . . . 34 Platform-Specific Services Segment (PSSS) Ansys, Inc. . . . . . . . . . . . . . . . . . . . . . . . . 35 Operating System Segment (OSS) Lynx Software Technologies . . . . . . . . 36 Abaco Systems . . . . . . . . . . . . . . . . . . . . 37 Portable Components Segment (PCS) ENSCO, Inc. . . . . . . . . . . . . . . . . . . . . . . . 38 LDRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4 | FACE Special Edition 2022

www.opensysmedia.com PRESIDENT Patrick Hopper patrick.hopper@opensysmedia.com EXECUTIVE VICE PRESIDENT

ohn McHale john.mchale@opensysmedia.com

EXECUTIVE VICE PRESIDENT AND ECD BRAND DIRECTOR Rich Nass rich.nass@opensysmedia.com ECD EDITOR-IN-CHIEF Brandon Lewis brandon.lewis@opensysmedia.com TECHNOLOGY EDITOR Curt Schwaderer curt.schwaderer@opensysmedia.com ASSOCIATE EDITOR Tiera Oliver tiera.oliver@opensysmedia.com ASSISTANT EDITOR Taryn Engmark taryn.engmark@opensysmedia.com ASSISTANT EDITOR Chad Cox chad.cox@opensysmedia.com CREATIVE PROJECTS Chris Rassiccia chris.rassiccia@opensysmedia.com MARKETING COORDINATOR Katelyn Albani katelyn.albani@opensysmedia.com FINANCIAL ASSISTANT Emily Verhoeks emily.verhoeks@opensysmedia.com SUBSCRIPTION MANAGER subscriptions@opensysmedia.com CORPORATE OFFICE 1505 N. Hayden Rd. #105 • Scottsdale, A

Tel

)

REPRINTS WRIGHT’S MEDIA REPRINT COORDINATOR Wyndell Hamilton whamilton@wrightsmedia.com (281) 419-5725

www.opengroup.org/face

The FACE Approach

Three quick questions … ith Chip o ning chair of the utreach ubcommittee of he pen roup s FACE usiness orking roup at oes t e t re o t e Approach look like? DOWNING: The FACE Technical Standard and Business Approach are now in production mode. e have refined both the technical and business aspects of this open standard, and the FACE Technical Standard is now required in nearly all new U.S. military avionics programs. The .S. Army Future ertical ift program is a good example of this effort. The next step is to expand the use of the FACE Technical Standard and Business Approach to our foreign military partners. The FACE Business Working Group (BWG) has already collaborated with European partners for years and has even delivered FACE presentations at AT Headquarters. ast fall, we had our first FACE avilion at Aerospace TechWeek in Toulouse, France, along with white papers delivered by FACE Consortium members. Efforts like the Joint All-Domain Command and Control A C ) include our foreign partners by design, and the FACE Business Approach is ideal for creating a pandomain, forward-leaning posture that can rapidly insert new competitive datacentric technologies to maintain this assertive stance. Expanding the use of the FACE Approach is a two-way street, as foreign avionics suppliers can now supply systems based upon an open platform to .S. programs. ikewise, these suppliers can transform their existing aircraft platforms into open FACE platforms that are readily adaptable with higher levels of affordability. And all Armed Services can share highly competitive avionics solutions across platforms. As further proof that the FACE approach is in production mode, it is now being designed into other standards, such as www.opengroup.org/face

The Open Group’s Sensor Open System Architecture (SOSA) Technical Standard. SOSA has adopted FACE capabilities into its operating systems and transport/ interaction binding requirements. As it has matured, have you discovered any new compelling benefits to using the FACE Approach DOWNING: The FACE Technical Standard is a standard of standards, and many of these standards are wellentrenched in the commercial avionics space. In nearly all cases, commercial avionics software needs to be safetycertified at some esign Assurance evel A ) of the TCA C standard. rior to the emergence of the FACE Approach, highly proprietary, single-platform airworthiness solutions were being developed. These solutions have been discarded as the FACE Approach has been adopted we now have a rich set of certified FACE conformant solutions that also have C certification evidence. This is a surprising byproduct of the FACE Consortium efforts, which have reduced the cost, risk, and time to airworthiness. These efforts have expanded the market for C certification evidence across both military and commercial avionics systems. I would call that a joint win for both defense suppliers and our military services. o does the FACE Approach support the U.S. DoD’s latest initiatives like data-centric directives and A C DOWNING: In September 2020, the .S. epartment of efense o ) issued the DoD Data Strategy, which directs U.S. DoD leaders to evolve all DoD assets into data-centric assets that treat data as a weapon system. Datacentricity refers to a system architecture

where data is the primary and permanent asset, and platforms, systems, missions, and applications come and go. A data-centric system is typically based upon a shared data model and provides real-time operational data to command and control (C2) decisions systems across different operational commands, from the tactical edge to the cloud. This data spans land, sea, air, cyber and space-based sensors; C2; and weapons systems from all operations services, agencies, and partners. Members of the FACE Consortium were smart and forward-thinking they built data-centricity into the FACE Technical Standard architecture. They even created both the Open Universal Domain Description Language (Open UDDL) and the Shared ata Model overnance lan to support the consistent application of data-centric strategies across military avionics programs. A key characteristic of the FACE Technical Standard is that its layered architecture decouples the data transport from the applications, enabling more rapid reuse and interoperability. The A C program is a joint warfighting concept that helps the U.S. military maintain a dynamic, always-on, data-centric position of superiority over all adversaries. All three branches of the Armed Services have programs building and testing JADC2 systems: U.S. Air Force with Advanced attlefield Management System A MS); the .S. Army with Project Convergence; and the U.S. Navy with Project Overmatch. These JADC2 efforts and require exible systems to insert new competitive technologies on demand. The FACE open architecture approach is ideal for airborne systems in JADC2 deployments across all U.S. and coalition partner platforms. Read The Open Group FACE™ Consortium Newsletter: https://bit.ly/3EgNyov. FACE Special Edition 2022 |

FACE SPECIAL EDITION

Q and A with Joe Carter, chair of the FACE Steering Committee Joe Carter is the chair of the The Open Group’s FACE Steering Committee and works as the Systems Engineering Lead at the U.S. Army PEO [Program Executive Office] Aviation. In this Q and A he discusses the challenges he sees confronting the FACE Consortium and what needs to be done to prepare for them.

FACE: ow on yo a e een in o e in t e onsorti m an w at are yo r c rrent res onsi i ities with the Army? CARTER: I have been involved in the FACE Consortium for seven years, and I just began my fourth year as the Steering Committee chair. At PEO Aviation, I am the Systems Engineer Lead and lead the tactical branch in G10. Some of my responsibilities include leading the digital engineering environment, integrating M SE model-based systems engineering throughout the E , assisting the tactical systems to achieve Army Interoperability Certification and supporting the E M SA modular open systems approach Transformation ffice in architecture and standards. I also chair the Army’s Real Time, Safety Critical, Embedded Computing Environment Working Group that is part of the Army s C E. FACE: lease tell us about one of the several positive impacts you have had on the FACE Consortium.

6 | FACE Special Edition 2022

CARTER: efore I was elected chair three years ago, I noticed that several key leaders were wearing too many leadership hats, so they were being spread too thin and struggled to dedicate the time to all of their responsibilities. This caused unnecessary delays in releasing certain documents and decisions. Therefore, one of the changes I started making was spreading out leadership responsibilities by encouraging only one leadership role per individual. I believe this has helped develop more leaders, keeps people more engaged, and lessens the impact when we experience turnover. FACE: It has been years since the FACE initiative as first launched. hat ere the original goals of the FACE Consortium and hat are they today CARTER: The key goals of improving the affordability of capabilities and delivering capabilities to the warfighter faster have not changed. These goals drove the establishment of the FACE Consortium back in une and they still drive us today. I believe having these stable goals really helps ground the FACE Consortium and keeps us on track. FACE: Is the FACE Approach ready for more

idespread use

CARTER: Yes. The FACE Approach includes business processes, technical practices, and an open component-based software standard. Even though we are focused on the aviation software domain, good software engineering is good software engineering regardless of the domain. The recent M SA guidance and policies from Congress, the o , and the services have in uenced our business processes, recommendations, and outreach, but we already had a solid foundation to build upon. e have already seen other industries like the oil-refinery industry leverage the good work we have done. There continues to be international interest, and we have made significant progress towards allowing international participation in the FACE Consortium. www.opengroup.org/face

FACE SPECIAL EDITION

FACE: o

has the recent

A guidance impacted the FACE Consortium

CARTER: I am glad you asked that question. The founders of the FACE Consortium deserve credit for establishing a strong foundation and incorporating the M SA principles. So, to answer your question about how M SA guidance has impacted the FACE Consortium, our most significant efforts are in outreach to let everyone know that

THE RECENT MOSA GUIDANCE AND POLICIES FROM CONGRESS, THE DOD, AND THE SERVICES HAVE INFLUENCED OUR BUSINESS PROCESSES, RECOMMENDATIONS, AND OUTREACH, BUT WE ALREADY HAD A SOLID FOUNDATION TO BUILD UPON. the FACE Approach addresses all rinciples of M SA. This really separates us from other open standards, because they do not have an independent and operational conformance program and most do not have an established enabling environment as extensive as ours that covers business resources, tools, training, examples, and certified conformant capabilities. utting on my Army E Aviation hat, our organi ation is embracing M SA and, to be honest, being disruptive to current contracting and engineering activities that

do not support a modular open systems approach. Moving forward, we plan to make M SA a source selection discriminator in future solicitations. ■ oe Carter is currently the Deputy G6 of the Program Executive Office (PEO) Chief Information Officer (CIO)/ G6 office. He is the chair for the Army’s Real Time, Safety Critical, Embedded (RTSCE) Computing Environment (CE) Working Group (WG), which consists of over 40 programs across 8 PEOs, which is part of the U.S. Army’s Common Operating Environment (COE). He is responsible for assisting the tactical systems to achieve Army Interoperability Certification (AIC) via COE and other interoperability testing. His PEO Aviation team has the responsibility for Information Assurance (IA) of tactical systems. Read The Open Group FACE™ Consortium Newsletter: https://bit.ly/3EgNyov.

MOSA Virtual Summit Sponsored by RTI, Annapolis Micro Systems, Curtiss-Wright, Elma, Flex Logix Technologies, Mercury, Milpower Source, and Systel In early 2019, Air Force, Army, and Navy leadership issued a joint memo mandating that the U.S. military use a Modular Open Systems Approach (MOSA) for new program designs and refreshes, calling MOSA a “warfighting imperative.” Now, as of 2021, MOSA is the law, as Congress passed legislation requiring MOSA to be part of the Department of Defense (DoD) acquisition process. MOSA strategies are now being leveraged across multiple domains – air, land, sea, space, and spectrum. The MOSA Virtual Summit is designed to drive awareness and thought leadership around MOSA initiatives like the Future Airborne Capability Environment (FACE) and Sensor Open Systems Architecture (SOSA) and aims to study how they impact signal-processing, software, hardware, AI, and RF designs. Watch the webcast: https://bit.ly/3KCFf8H (This is an archived event.)

WATCH MORE WEBCASTS:

https://militaryembedded.com/webcasts/ www.opengroup.org/face

FACE Special Edition 2022 |

About the FACE Consortium TM

www.opengroup.org/face The Open Group’s FACE™ Approach integrates technical and business practices that establish a standard common operating environment to support portable capabilities across avionics systems. The modularity defined in the FACE Approach enables an agile environment for firms to respond to market and customer demands for capability changes and upgrades. Industry has proven its commitment to the success of the FACE Approach by completing FACE conformance certification for its products. This enables military programs to rapidly select precertified software modules to reduce design, integration, and conformance costs for all programs requiring FACE conformance.

FACE SPONSOR

Elbit Systems of America https://www.elbitamerica.com/

Air Force Life Cycle Management Center https://www.afrl.af.mil/

FLIR Systems, Inc. https://www.flir.com/

Boeing https://www.boeing.com/

GE Aviation Systems https://www.geaviation.com/

Collins Aerospace https://www.rockwellcollins.com/

General Dynamics https://www.gd.com/

Joint Tactical Networking Center https://www.jtnc.mil/

Green Hills Software https://www.ghs.com/

Lockheed Martin https://www.lockheedmartin.com/

Honeywell Aerospace https://aerospace.honeywell.com/

NAVAIR https://www.navair.navy.mil/

IBM https://www.ibm.com/us-en?ar=1

U.S. Army PEO Aviation https://www.army.mil/PEOAviation

L3Harris https://www.l3harris.com/

FACE PRINCIPAL

Leonardo DRS https://www.leonardodrs.com/

AdaCore https://www.adacore.com/

Mercury Systems https://www.mrcy.com/

AeroVironment, Inc. https://www.avinc.com/

Northrop Grumman https://www.northropgrumman.com/

BAE Systems Inc https://www.baesystems.com/

Parry Labs, LLC https://parrylabs.com/

Bell https://www.bellflight.com/

Raytheon https://www.rtx.com/

Cubic Corporation https://www.cubic.com/

Sierra Nevada Corporation https://www.sncorp.com/

Sikorsky Aircraft https://www.lockheedmartin.com/en-us/ capabilities/sikorsky.html U.S. Army Combat Capabilities Development Command Aviation and Missile Center https://www.army.mil/article/157845/ ccdc_aviation_missile_center Wind River https://www.windriver.com/

FACE ASSOCIATE

8 | FACE Special Edition 2022

Abaco Systems https://www.windriver.com/ Adventium Labs https://www.adventiumlabs.com/ Aitech https://aitechsystems.com/ Alta Data Technologies, LLC https://www.altadt.com/ Ampro ADLINK Technology, Inc. https://www.adlinktech.com/en/Index Ansys https://www.ansys.com/ Avalex Technologies https://avalex.com/ Avilution, LLC https://www.avilution.com/

www.opengroup.org/face

Carnegie Mellon University, Software Engineering Institute https://www.sei.cmu.edu/ CoreAVI https://coreavi.com/ Craft Designs, Inc. ttps://craftdesigns.net/ CS Communication & Systems, Inc. https://www.cscanada.ca/ CTSi https://www.goctsi.com/ Cyient, Inc. https://www.cyient.com/ Danbury Mission Technologies, LLC https://www.dmtllc.org/ DDC-I https://www.ddci.com/ ENSCO Avionics https://www.ensco.com/ EXB Solutions https://exbsolutions.com/ GaN Corporation https://www.geeksandnerds.com/ General Atomics https:// www.ga.com/ General Micro Systems, Inc. https://www.gms4sbc.com/ Integrated Solutions for Systems, Inc. https://is4s.com/ Inter-Coastal Electronics, LLC https://www.faac.com/inter-coastal/ ITZ, LLC https://itz.org/ Jovian Software Consulting LLC https://www.joviansc.com/ Kearfott Corp. https://www.kearfott.com/

KIHOMAC, Inc. https://www.kihomac.com/

Skayl LLC https://www.skayl.com/

LDRA Technology https://ldra.com/

Southwest Research Institute https://www.swri.org/

Leidos https://www.leidos.com/

TABAS CO, LLC https://tabasconsultingllc.com/

Lynx Software Technologies https://www.lynx.com/

Terma North America Inc. https://www.terma.com/

Makel Engineering, Inc. https://www.makelengineering.com/

TES-SAVi https://tes-savi.com/

Micro Focus (US) Inc. https://www.microfocus.com/en-us/home

Textron Systems https://www.textronsystems.com/

Moog, Inc. https://www.moog.com/

Thales Avionics, Inc https://www.thalesgroup.com/en

North Atlantic Industries, Inc. https://www.naii.com/

Trideum Corporation https://www.trideum.com/

OAR Corporation http://www.oarcorp.com/

TTTech North America, Inc. https://www.tttech.com/

Parasoft https://www.parasoft.com/

Twin Oaks Computing, Inc. http://www.twinoakscomputing.com/

Performance Software https://www.psware.com/

United Electronic Industries, Inc. https://www.ueidaq.com/

Presagis USA, Inc. https://www.presagis.com/en/

University of Dayton Research Institute https://udayton.edu/udri/

Rapita Systems, Inc. https://www.rapitasystems.com/about/ partners/face-consortium

Vector North America https://www.vector.com/us/en/

RDRTec, Inc. https://www.rdrtec.com/

Verocel https://www.verocel.com/

Real-Time Innovations https://www.rti.com/en/

ViaSat, Inc. https://www.viasat.com/

Riverside Research https://www.riversideresearch.org/

wolfSSL https://www.wolfssl.com/

Rogerson Kratos https://www.rogerson.com/

Zodiac Data Systems https://services.zodiacaerospace.com/s/ login/?ec=302&startURL=%2Fs%2F https://www.baesystems.com/en/home

SAIC https://www.saic.com/

Note: List as of 4/1/2022

www.opengroup.org/face

FACE Special Edition 2022 |

FACE Consortium Information TM

THE FACE™ APPROACH The Open Group’s Future Airborne Capability Environment (FACE) Approach is a government-/industry-developed software standard and business strategy with the goals of: • Increasing the affordability of capabilities • Improving time-to-field, delivering new capabilities to the warfighter faster The FACE Approach integrates technical and business practices that establish a standard common operating environment to support portable capabilities across avionics systems. The FACE Technical Standard defines the requirements for architectural segments and key interfaces that link the segments together. This enables the reuse of capability-based software components across different hardware computing environments. The idea is to avoid “reinventing the wheel” for every new platform system. It also enables rapid replacement of older software and insertion with new and improved capabilities throughout the system lifecycle. The FACE Approach is relevant to both enduring systems and future systems, including new system designs, system-level upgrades, and component upgrades.

IS THE FACE™ APPROACH ONLY FOR AIRBORNE PLATFORMS? No, the FACE Approach and FACE Technical Standard are applicable to many environments. The FACE Technical Standard focuses on embedded military avionics applications. Other domain experts have evaluated the standard and determined it can be applied beyond the military avionics domain in areas such as real time embedded, ground-based defense systems, industrial control, and enterprise environments.

FACE™ TECHNICAL STANDARD The FACE Technical Standard is an open, non-proprietary specification that is publicly available without restrictive contracts, licensing terms, or royalties. The open standards specified within the FACE Technical Standard allow use without payment or other obligation to the standards owners. Additionally, neither the FACE Technical Standard nor the FACE Conformance Certification Process require or prohibit a software supplier to relinquish rights to Technical Data or Computer Software within the software, the business logic, the presentation logic, or any other logic whether in the application or the software computing environment. Adherence to the FACE Technical Standard is enforced through the FACE Conformance process. FACE Conformance ensures proper use of the defined FACE Interfaces and adherence to the FACE Reference Architecture. In addition to conformance, the FACE Approach addresses other practical business concerns such as contracting (FACE Contract Guide), value proposition and business drivers (FACE Business Guide), and product registry (FACE Library documents).

Email The Open Group ogsosa-admin@opengroup.us For more information, visit www.opengroup.org/face

10 | FACE Special Edition 2022

LinkedIn: https://www.linkedin.com/groups/4127663/ Twitter: https://twitter.com/theopengroup You Tube Channel: https://www.youtube.com/playlist?list=PL4uhUsJo0STm3ypYiR6bBHlMH55eHf0SV www.opengroup.org/face

www.skayl.com

Transforming System & Software Architecture

EXECUTIVE SPEAKOUT

ADVERTORIAL

QUESTION: HOW DOES THE FACE™ TECHNICAL STANDARD BENEFIT THE WARFIGHTER?

The Blueprint for Innovation: FACE™ Technical Standard By Chip Downing, Senior Market Development Director, Aerospace & Defense Three ways the FACE™ Technical Standard benefits the

arfighter

1. The FACE Technical Standard is a blueprint for innovation it defines a framework where a wide range of suppliers can rapidly deploy highly competitive technologies into arfighters hands for a superior mission operations stance against all adversaries. 2. The FACE Technical Standard is a standard-of-standards, which enables proven standards-based solutions from both commercial and military sources to be deployed in FACE platforms. ow defense suppliers can leverage commercial avionics standards that have existing TCA C safety certification evidence proven in commercial platforms to be quickly re-used in FACE platforms. This accelerates platform airworthiness and time to deployment. . The FACE Technical Standard encourages data-centricity. This exactly aligns with the o ata Strategy, which directs military leaders to evolve all o assets into data-centric assets that treat data as a weapon system.

To support data-centricity, the FACE Technical orking roup T ) created and published both the pen niversal omain escription anguage pen ) and the Shared ata Model overnance lan to support the consistent application of datacentric strategies across military avionics programs. These capabilities coupled with the FACE layered architecture decouples the data transport from the applications, enabling more rapid reuse and interoperability. This data-centric architecture is based on a shared FACE ata Model, enabling the delivery of real-time operational data to command and control C ) decision systems across different operational commands, from the tactical edge to the cloud. arfighters can now enjoy unparalleled situational awareness using data that spans land, sea, air, cyber and space-based sensor systems and can utili e weapons systems from all operations services, agencies, and partners, enabling the oint All- omain Command and Control A C ) integrated approach to sense and utili e data for superior mission operations.

www.rti.com

EXECUTIVE SPEAKOUT

ADVERTORIAL

QUESTION: HOW WILL THE FACE™ TECHNICAL STANDARD BENEFIT THE WARFIGHTER?

Changing the Focus from Application-Centric to InfrastructureCentric Integration and Leveraging the FACE™ Technical Standard By Gordon Hunt, Co-Founder The fundamental integration problem is managing the complexity of change and differences. We must solve it to effectively deliver warfighting capabilities faster and cheaper. e can try to minimi e complexity but changes always will escape the scope of a single component and affect other parts of the system. The FACE™ Technical Standard encourages an approach we call Infrastructure-Centric Integration, which accommodates change via the infrastructure instead of via the application. It does this by allocating mediation responsibility to the Transport Service (TS) in the form of capabilities such as data transforms, message association, and message routing. It also requires that portable application components use standardi ed TS A Is to send and receive data and to model communicated data in a structured format. The data model goes beyond mere syntax and includes semantics like units, measurements, and domain-specific context that are necessary for mediation. Only the integrator has the necessary context to resolve the competing needs of the constituent parts in a system. The above require-

12 | FACE Special Edition 2022

ments ensure they have the knowledge to determine the necessary data transforms and behavioral mediation. A capable infrastructure provides the mechanism. In contrast, modifying applications in response to system needs forces them to know more about their surrounding environment and creates knowledge dependencies in the wrong direction, making each application less reusable. Additionally, that approach duplicates functionality. If each application implements its own mediation capabilities it increases the overall development cost and decreases the proportion of resources spent on core business logic. The integration infrastructure (aka a FACE Transport Service) is a first-class system component that can be separately procured and managed. It both simplifies applications and enables integrators to use the full power of purpose-built, exible infrastructure. For more information: https://www.skayl.com/post/infrastrucutrecentric-integration.

www.skayl.com www.opengroup.org/face

EXECUTIVE SPEAKOUT

ADVERTORIAL

QUESTION: HOW DOES THE FACE™ TECHNICAL STANDARD INTERFACE WITH OTHER OPEN STANDARDS?

Combining the FACE™ Technical Standard and ARINC 661 for Certifiable Cockpit Display Systems By Bernard Dion, Ansys Fellow As manned and unmanned airborne platforms move forward to modernized software architectures, development based on an open architecture specification has significant advantages for glass cockpit, mission system and operator controls applications. A MOSA Tri-services Memo from anuary , recommends the use of the FACE™ Technical Standard for new acquisition programs, which also includes an option to use A I C as a graphics rendering service. enefits of an A I C architecture include modularity, reduced costs risks for capability insertion and incremental qualification certification when new capabilities are added), and exibility to integrate non-A I C applications all in direct support of MOSA objectives. The A I C specification includes the Cockpit isplay System C S) which renders graphics, and ser Applications As) which provide platform capabilities that interface to the C S. Ansys SCA E enables efficient development customi ation of the C S graphics server and associated primitives called widgets, and also the As that provide capabilities within the C S. And while development of the C S or As within SCA E support certification

objectives up to DO-178C DAL A or similar airworthiness criticality levels), the architecture can also include previously developed or new lower-criticality applications integrated within the architecture. Additionally, Ansys SCA E provides a graphical approach to support FACE ata Modeling and o Integration. In close collaboration with the S o , Ansys was able to work directly with the S Army FACE erification Authority to validate the Ansys A I C C S Server s conformance to the FACE . Technical Standard as a platform-specific service SS) achieving FACE Conformance as a result. And as an active participant of the FACE Consortium as well as the A I C subcommittee, Ansys was able to capture lessons learned to pave the way for future acquisition programs. evelopment of a certifiable turnkey A I C architecture aligned to the FACE Technical Standard is possible today with Ansys SCA E.

www.ansys.com

Protecting Sensitive Data and Algorithms At-Rest, In-Motion, and (Now) In Use Sponsored by Wind River Cryptographically protecting data both at rest and in motion has become commonplace for military embedded systems that could fall into enemy hands, but one vulnerability persists: the security of data or code as it’s moved into and used within working memory. In this webcast, join experts from Idaho Scientific and the Cybersecurity and Technology Protection Group at Wind River, Star Lab, as they present an integrated solution for securing information and algorithms throughout the system. The program covers protection of sensitive data and algorithms at rest, in motion, and in working memory; holistic protection of Linux on an embedded system (Xilinx MPSoC) that meets stringent levels of security for mission-critical systems; and cybersecurity using Wind River and Idaho Scientific products. Watch the webcast: https://bit.ly/3rch6ON (This is an archived event.)

WATCH MORE WEBCASTS:

https://militaryembedded.com/webcasts/ www.opengroup.org/face

FACE Special Edition 2022 |

EXECUTIVE SPEAKOUT

ADVERTORIAL

QUESTION: HOW WILL THE FACE™ TECHNICAL STANDARD BENEFIT THE WARFIGHTER?

FACE™ Technical Standard Gives Edge to Warfighters By Mark Hutnan, Vice President, Business Development, Abaco Systems The Future Airborne Capability Environment™ (FACE) Technical Standard is the open avionics standard for portable software components used in general purpose, safety and security applications. Developed by the Open Group FACE Consortium, the standard is especially beneficial in airborne military computing operations. While the FACE Technical Standard focuses on software, it also helps open architecture computing and electronic systems suppliers like Abaco Systems improve aircraft lethality and survivability. It ensures that all types of military aircraft are equipped with up-to-date, uniform and conformant embedded computing systems. From my perspective as a former U.S. Marine Corps aviator and Mission Commander who has been on multiple overseas deployments, this open standard is an asset for the military aviation community. Our capabilities must stay ahead of emerging threats. Not that long ago, it could take months to implement software updates on airborne platforms. Today, it is possible to make relevant updates within hours after returning from a mission. We want to extend this capability and make updates while airborne in real time.

This fast response requires a powerful hardware suite to interface with and enable FACE-compliant software applications and updates. The benefits of combining open software and rugged embedded computing products are available to all prime military system integrators. This symbiotic integration of software and hardware encourages cross-platform development, eliminates obsolescence, reduces cost and timelines and simplifies production schedules. Abaco Systems, for example, offers integrators commercial offthe-shelf (COTS), open architecture, rugged electronics for the most demanding defense applications, including our FORCE2C ight safety certifiable mission computer. These integrators have confidence in the reusability and portability of the software and embedded hardware, even when the system is updated. In turn, the technology gets to the field faster, giving the warfighter unmatched capabilities to win the day.

www.abaco.com

EXECUTIVE SPEAKOUT

ADVERTORIAL

QUESTION: WHAT ADDITIONS WOULD YOU LIKE TO SEE TO THE FACE™ TECHNICAL STANDARD AND WHY?

Improving the FACE™ Conformance Verification Process through Qualified Tools By Dr. Benjamin Brosgol, Senior Technical Staff, AdaCore Qualified tools have a long and successful history in the commercial aviation industry. Incorporating tool qualification into the FACE™ conformance verification process can make conformance verification both more efficient and more reliable. The FACE approach is based on a Technical Standard that defines software requirements for portability/reuse (restrictions on APIs and language features), and a verification process that assesses conformance with these requirements. Conformance verification uses link-time tests to detect if the software is using prohibited APIs, and source code inspection to check requirements that cannot be verified by link-time tests. However, manual code inspection is inefficient and subject to human error. More fundamentally, linktime testing does not work well for a language like Ada, where source code portability comes from standard language syntax rather than APIs for run-time services. Static analysis tools can address these problems if there is confidence that the tools work correctly. Experience in the commercial airborne software domain offers a solution.

14 | FACE Special Edition 2022

For the commercial aviation industry, the DO-178C standard defines extensive requirements for software verification. If an automated tool replaces a manual activity, then the tool needs to be qualified; i.e., shown to be fit-for-purpose. Specific tool qualification requirements appear in the DO-330 standard, independent of DO-178C and applicable in other contexts/domains. The FACE conformance process will benefit by incorporating the tool qualification concept and allowing qualified tools to automate applicable verification activities. For example, a number of FACE requirements are syntactic restrictions that a static analysis tool can check, and qualifying the tool means that its output can be trusted. This can simplify the conformance verification effort while increasing the confidence in its result. For further information on AdaCore and the FACE effort, please visit https://www.adacore.com/industries/defense/face.

www.adacore.com www.opengroup.org/face

FACE SPECIAL EDITION

Virtualization: A FACE lift for vehicle control By Will Keegan

As a testament to the celebrated success of The Open Group’s FACE [Future Airborne Capability Environment] approach, mandatory conformance requirements for mission-system software have flowed down for nearly every applicable military program since the publication of FACE 2.0. But even as FACE informs and guides all aspects of software design for tactical mission systems (communications, flight control, flight map and planning, cockpit displays, etc.), the world of vehicle control harbors reservations about FACE adoption. The imperative to deliver safety critical, hard real-time control systems has raised concerns about technical feasibility impeded by the complexities inherent to the FACE multicore Operating System Segment (OSS). Recent experience in working with vehicle-control projects particularly those based on multicore processors has proven the use of C virtuali ation as a powerful tool that compliments operating systems in resolving integration con icts between software components with platform requirements that differ greatly in terms of A I application programming interface compatibility and architectural assumptions. The Future Airborne Capability Environment (FACE) standard views virtualization as primarily a hardwareconsolidation tool. But as the world presses forward in the development of

16 | FACE Special Edition 2022

unmanned vehicles, the need to integrate vehicle-control and mission-system computing will become mandatory and the concerns more pertinent. Given its capacity to deliver on core FACE principles where hard real-time control is essential, virtualization deserves further consideration.

The vision of FACE

For many years, military systems have largely been based upon proprietary applications, middleware, operating systems, and/or hardware. This situation resulted in problems that included long lead times, high costs, and few opportunities to reuse existing technologies. utting system modifications out to competitive tender has been impossible because the only suppliers equipped to make changes have been the suppliers of the original system. The FACE Consortium a partnership between industry suppliers, government experts, academia, and customers was formed to address those issues. Standardi ing approaches for using open standards within military avionics systems promised to lower implementation costs, accelerate development, ensure robust architecture and www.opengroup.org/face

FACE SPECIAL EDITION

FIGURE 1 | Example FACE configuration with CPU virtualization-assisted hardware partitioning segment.

Dedicated partitioning segment

consistently high-quality software implementation, and maximize opportunities for reuse.

Virtualization in avionics systems

Many of the benefits of multicore virtualization in embedded avionics systems are well documented. The ability to consolidate multiple legacy single-board computers (SBCs) with various operating systems and applications into a single, multicore, virtualized SBC is widely acknowledged to be the most tangible benefit to next-generation avionics. However, the capacity of C virtuali ation and hypervisors to provide benefits relating to real-time performance, software composability, and architectural robustness are less well-known to the veteran embedded software community. The following sections discuss these benefits as applied within the context of the FACE reference architecture edicated partitioning segment, simplifying space for real time, and increasing portability and reuse. www.opengroup.org/face

Over the last ten years, there have been considerable advances in the ability to run multiple operating systems on a single processor through CPU virtualization. While popularized and universally adopted in the IT world, the underlying hardware has features that are just as appealing to embedded engineers concerned with robustness and predictability. In traditional platform software design, each processor hosts a single operating system S) kernel that is responsible for managing memory allocation, execution scheduling, interrupt routing, exception handling, peripheral control, and bus multiplexing. Now, virtuali ation-enabled multicore hardware is now capable of accommodating many kernels, with each kernel allocated subsets of resources of varying types and si es. Multiple independent software runtimes can therefore be implemented on a single device without the interference of a common kernel and consequentially common mode failure ha ards. Such capabilities enhance fundamental architectural properties relating to safety and security concerns. From a security perspective, the use of built-in C virtuali ation features to isolate hardware-security functions, and separate application-runtime services from hardware control interfaces, goes a long way to assure system robustness. Such design techniques eliminate commonly exploited threat vectors that result in security-policy bypass, privilege escalation, and loss of C control altogether. From a safety perspective, upholding threshold design principles predictability, integrity, and high availability is greatly aided using virtuali ation partitioning features such as: › MA channel isolation › Shared last-level cache partitioning › Memory bus bandwidth allocation › Independent interrupt, event, and exception handling FACE Special Edition 2022 |

FACE SPECIAL EDITION

The ability for software partitions to be fortified and controlled with greater fidelity at hardware levels aligns with FACE ideals. The diagram shown in Figure introduces the notion of a Hardware artitioning Segment fulfilled by a hypervisor to the FACE reference architecture. The depiction shows a hypervisor isolating two sets of software on two different C cores. Each set is configured with FACE-conformant components. Each set of software is granted greater partitioning properties over a single OS-hosted design where the device drivers and internal service are separated.

Simplifying space for real time

Adding yet another segment into FACE would be a significant undertaking. Introducing another class of technology and layer of software beneath an S may seem counterproductive to realtime and safety-conscious developers wary of complexity. ut the hardware partitioning and multiplexing capabilities presented by CPU virtualization presents the opportunity to encapsulate and map subsets of runtime features for critical tasks on a processor that is simultaneously hosting applications with inherently richer runtime and service dependencies. For example, suppose a vehicle-control health-monitor application, such as a high-frequency majority-voting C IT continuous built-in test needed for TM triple-modular redundancy error detection must run alongside a ightplanning application on a multicore processor. Using a hypervisor-based solution rather than implementing both applications concurrently on the same OS sharing the same network stack and kernel, the health-monitor application (shown in Figure 2) can be: › Mapped to a separate C core › Mapped to a separate Ethernet MAC › Run according to an independent thread-scheduling algorithm › Isolated from orthogonal interrupts and blocking semaphores › Isolated from MA and S kernel memory-access errors › Run on an optimized, minimalistic POSIX-compliant runtime environment

18 | FACE Special Edition 2022

FIGURE 2 | Example FACE configuration with independent real-time partition.

FIGURE 3 | Example of standalone Units of Conformance (UoCs. The result is an ideal scenario for a real-time programmer looking to simplify analysis of worst-case execution time CET). et at the line-replaceable unit ) level, the platform retains the ability to host applications with richer Transport Services Segment (TSS) and Operating System Segment (OSS) capability requirements that are less concerned about timing and integrity hazards.

Portability and reuse

Military programs are often stuck with board-support package S ) non-recurring engineering E) costs that could be avoided if internal platform software were more portable. Low-level code modules (particularly drivers) are notoriously problematic in providing valued properties of reuse and interoperability. www.opengroup.org/face

Standardizing OS internal kernel interfaces is impractical due to their unique design and (in many cases) proprietary nature. However, several classes of device drivers that are naturally independent from core services and require minimal S feature support such as the file system) can be isolated by a hypervisor and integrated with applications over standard inter-process communication I C) interfaces. It is demonstrable that devices can be controlled independently from operating systems and integrated with other components without embedding proprietary OS dependencies. Consider an OpenGL UA application that simply needs drivers with access to the GPU device interface. Another example A self-contained MI -ST service with TSS-compatible I interfaces made available to PCS [portable component segment applications see Figure ).

control subsystems has proven virtuali ation as a means to reduce platform software complexity carving out low-level hardware-control access while providing the wellappreciated architectural benefits of partitioning and interoperability interfaces. ressing into the standardi ation of these low-level capabilities can bridge the gap of FACE-compliance feasibility for vehicle-control development without tarnishing the undoubted benefits of existing FACE provisions for mission-system development. ■ In his role as chief technical officer for Lynx Software Technologies, ill eegan leads the technology direction across all the Lynx product lines. He has been instrumental in the development of key security technologies within Lynx to broaden the reach of the existing products, with a focus on cybersecurity, cryptography, and virtualization. Keegan holds a Bachelor of Science degree in computer science from University of Texas. yn

o tware ec no o ies

tt s www. yn .com

Instead of relying on S implementations of resource mapping and I C transports, the TSS layer and local application runtime software can locate dependent modules and integrate with the use of standard hypervisor-provided interfaces and services. Such an approach can even follow the FACE nit of Conformance oC) packaging requirements. This vision is not farfetched, given that virtuali ation standards such as OASIS “VIRTIO” area already well-established. Just as FACE relies on POSIX to uphold standard specifications for the SS, I TI can similarly support the proposed Hardware Partitioning Segment.

Virtualization works for FACE

FACE is a resounding success. But to date, the portability and interoperability benefits of FACE have been generally limited to the mission-system software hosted by operating systems above the TSS layer. Exacerbating that situation, the targeting of military avionics towards the development of unmanned systems is likely to see the underlying boundaries of mission system versus vehicle-control computing domains diminish, with the limitations of FACE becoming more of an irritation. To fulfill its charter, FACE must accommodate the needs of vehicle-control software. ecent experience on vehiclewww.opengroup.org/face

FACE Special Edition 2022 |

FACE SPECIAL EDITION

Making software FACE-conformant and fully portable: Coding guidance for Ada By Benjamin M. Brosgol

The Open Group’s FACE [Future Airborne Capability Environment] approach to reducing life cycle costs for the military is based on reusing software components across different platforms and airborne systems. The FACE Technical Standard addresses this issue through a reference architecture and data model, well-defined interfaces, and widely used underlying industry standards (IDL, Posix, ARINC-653). Conformance with the FACE Future Airborne Capability Environment requirements is a necessary condition for reuse and software portability, but full sourcecode portability means more than using a common set of interfaces. In order for a FACE-conformant software component known as a nit of Conformance or oC to be fully portable, it should have equivalent behavior across different platforms and or compiler implementations. However, each of the programming languages called out in the FACE Technical Standard C, C , Ada, and ava has features whose effect may depend on the compiler implementation or target platform. riting a fully portable oC in any of these languages involves avoiding the potential implementation dependencies. here full portability is not possible, for example if there are intrinsic target dependencies, the software structure should encapsulate such dependencies. Ada has strong advantages to FACE oC developers in terms of software

20 | FACE Special Edition 2022

engineering support and program reliability, and it was designed to facilitate the development of fully portable code, but even Ada has features with implementation dependencies. This article shows how application developers can use Ada or its formally analy able S A subset to achieve full portability of FACE oCs, in particular for the Safety or Security capability sets profiles defined in the FACE Technical Standard.

Functional portability

ortability, or what will be called functional portability here to distinguish it from portability in the sense of FACE conformance, has been a goal of programming-language design since the earliest days. Ideally, functional portability means that a source program can be compiled and run on one platform and then, possibly with a different vendor s compiler, the same program can be successfully compiled and run on either the same platform or a different one and have an equivalent effect. Equivalent informally means that the program has the same external effects except for those resulting from permissible timing differences. A real-time program has a limited concept of which timing differences are permissible i.e., some of its timing constraints are essential since missing a deadline may mean that the program fails to meet its requirements.) In practice, however, several impediments may interfere with functional portability. These can include sing language features that are either nonstandard i.e., unique to a specific compiler vendor), or else are standard but optional and not implemented by all compilers; using standard language features with imprecisely defined semantics; and dependence on characteristics of the target platform. The following will offer guidance for Ada functional portability, covering both Ada and Ada , with a focus on features allowed by the Security and Safety capability sets of the FACE Technical Standard Edition 3.0 or later. Where applicable, the guidance shows www.opengroup.org/face

FACE SPECIAL EDITION

of implementation-defined extensions, through arguments to pragma Restrictions; for example, No_Implementation_Pragmas and No_Implementation_Units.

Optional features

Another impediment to functional portability is to use a standard feature that is not supported by all compilers. The certification policy for Ada addresses this issue by prohibiting subsets every Ada compiler must implement the full language. evertheless, the revision process that led to Ada 95 recognized that particular domains have speciali ed and sometimes con icting) requirements, and a number of annexes the Speciali ed eeds Annexes) are therefore optional with respect to compiler certification. A compiler has to implement the full core language, including the predefined environment standard library) and the interlanguage interfacing facilities, but the Systems Programming, Real-Time Systems, Distributed Systems, Numerics, Information Systems, and Safety and Security Annexes are optional. In practice this optionality has not been an issue, since the most commonly used annexes Systems rogramming and eal-Time Systems are supported by the vendors in the Ada ecosystem. Moreover, the FACE Safety and Security capability sets for Ada prohibit the istributed Systems, umerics, and Information Systems Annexes, so their optionality is not relevant to functional portability. evertheless, the Systems rogramming and ealTime Annexes raise a few issues that might affect FACE oC developers

how the SPARK Ada subset can be used to mitigate potential non-portabilities. Here, the language name Ada refers to both Ada 95 and Ada 2012 unless indicated otherwise.) This guidance is not an exhaustive list; the Ada reference manual is the definitive source of information on which features can have implementationdependent effects.

Language extensions

To prevent vendor lock-in from nonstandard extensions, the certification policy for Ada compilers has included a no supersets directive from the outset. That policy, however, has always recogni ed the utility of vendor-specific functionality provided that no new syntax is introduced, and thus allows certain kinds of language extensions; in particular, implementation-defined libraries, pragmas, attributes, arguments to pragma Restrictions, and for Ada ) aspects. The FACE Safety-Extended and SafetyBase & Security capability sets impose a few restrictions in this area but do not otherwise restrict such language extensions. To facilitate portability, the use of implementation-defined language extensions should be minimized. Ada 2012 has explicit support for enforcing the absence www.opengroup.org/face

› Some of the services defined in these annexes and permitted by the FACE Safety and Security capability sets are intrinsically system-dependent for example, interrupt handling) and thus will require revision on porting to a different execution environment. esigning the application to encapsulate such dependencies will ease the porting effort. › The FACE Safety and Security capability sets significantly restrict the functionality supplied by these annexes. The oC developer will need to demonstrate, through static analysis or code review/inspection, that prohibited features in these annexes are not used.

Guidance for features with implementation-dependent semantics

Functional portability requires well-defined semantics, so that a source program has an equivalent effect on each platform where it is compiled. In practice, however, there is sometimes a tradeoff between precisely defined semantics and efficient run-time performance. Since efficiency is typically a critical requirement for programmers, language standards including Ada) contain features whose effect may vary across different implementations.

Order of evaluation in expressions

To facilitate optimi ation, Ada does not specify the order of evaluation of the terms comprising an arithmetic expression, but in some cases the effect depends on the order that the compiler chooses. ne way to mitigate this issue is to identify potentially problematic instances (by inspection or static analysis) and make the order deterministic by rewriting the expression as a sequence of assignment statements that compute the intermediate results. Alternatively, the potential nonportability can be eliminated completely by using the SPARK Ada subset: restrictions such as the prohibition of side effects in functions ensure that the value of an expression is the same, regardless of the compiler s choice of evaluation order.

Parameter passing

Formal parameters to a subprogram in Ada are specified in terms of the direction of data ow › “in, from the caller to the called subprogram › “o t, from the called subprogram back to the caller when the subprogram returns FACE Special Edition 2022 |

FACE SPECIAL EDITION

› “in o t, from the caller to the called subprogram, and then from the called subprogram back to the caller when the subprogram returns

require initiali ation to be supplied by an external input at system startup. More subtly, default initiali ation can lead to a hard-to-detect programming error where a variable that needs to be explicitly initiali ed is referenced prematurely, yielding the default initiali ation that is valid for the variable s type but incorrect.

The compiler chooses whether a parameter is passed by copy or by reference. For certain classes of types in particular, scalar types and access types pointers ) the semantics of parameter passing is by copy. For some other classes of types the semantics is by reference. ut for types that do not fall into these categories, the compiler can choose either strategy, generally using the type s object si e as the criterion. If the si e of each object is smaller than some threshold value, then by copy is used, otherwise it will be by reference.

eferencing a variable before it has been initiali ed is a programming error. In the absence of a guaranteed value, the Ada semantics leave the effect of such a reference undefined. Ensuring that variables are initiali ed before being referenced is outside the scope of the restrictions in the FACE Safety and Security capability sets, and thus needs to be enforced through other means.

The potential functional portability issue is that the effect of the subprogram may depend on the compiler’s choice. This can occur through “aliasing” (e.g., a global variable is passed as a parameter to, and is also assigned from, the subprogram) or exception handling a formal o t” or “in o t parameter is assigned from the subprogram, but an exception is propagated before the subprogram returns). These implementation-dependent effects can be mitigated in several ways. The aliasing issue can be avoided by ensuring that a global variable is not passed as a parameter to a subprogram that can assign to the variable. Violations can be detected by code review/inspection or static analysis tools and are prevented in SPARK (which prohibits such aliasing). The exception propagation issue can be avoided by appropriate programming style deferring any assignment to the formal parameter until after it can be assured that exception propagation will not occur. This issue is completely avoided with S A , since the proof tools can demonstrate the absence of run-time exceptions.

References to uninitialized variables

The Ada language enables variables to be declared without initialization. Requiring initialization universally would be problematic: A sensible initial value might not exist, or the program logic might

22 | FACE Special Edition 2022

Several Ada language features can help › Some types require a default initiali ation. In particular when an access value (pointer) is declared without an explicit initialization, it will be set to the special value n . An attempt to dereference the n value raises an exception › The programmer can define default initial values for record fields › In Ada any scalar type can define a default initial value In practice, references to uninitiali ed variables for other types are detected in many instances by the Ada compiler, especially at higher optimization levels where sophisticated ow analysis is used. Static-analysis tools can also address this issue while minimi ing false alarms. And as with all the other potential nonportabilities discussed in this section, references to uninitiali ed variables are completely prevented in S A since they will be detected by the S A proof tools.

Concurrency

Ada has a powerful and high-level concurrency model, but in the interest of supporting a wide range of target environments the language enables a number of scheduling policy decisions to be determined by the implementation. This nondeterminism is mitigated by the avenscar profile, a simple, deterministic and efficient subset of the Ada tasking features. oth the FACE Safety-Extended and Safety- ase Security capability sets restrict the Ada tasking facility to the avenscar subset and thus avoid the functional portability issues of the full tasking model. The avenscar features are allowed in the Safety capability sets for Ada in Edition . of the FACE Technical Standard, and for both Ada and Ada in Edition . .) The Ravenscar subset is supported by SPARK, and thus a SPARK program will avoid the nondeterminism of the full Ada tasking model.

Elaboration order

An Ada program typically consists of a main subprogram together with the modules (“packages”) that the main subprogram depends on, directly or indirectly. Program execution first executes run-time code in the various dependent packages for example to initiali e global data) known as package elaboration then invokes the main subprogram. The order in which the packages are elaborated is partially constrained by language semantics but is generally implementation-dependent, with different orders possibly yielding different results. Implementation dependence is intrinsic to the language semantics, since any attempt to completely specify the elaboration order would also prohibit useful cases such as interdependent packages. Several techniques can help ensure portability: › Add appropriate pragmas to constrain the elaboration order see Figure for an example) or › Avoid elaboration-time code in the dependent packages by moving all such code into procedures that are explicitly invoked at the start of the main subprogram www.opengroup.org/face

FIGURE 2 | Portable numeric type. packages will localize and help minimize the adaptation needed when porting the code to a new target platform. umeric type representation The predefined numeric types in Ada Integer, Float, etc.) have implementation-defined ranges precisions. This situation can cause functional portability issues if the programmer implicitly assumes that a type such as Integer always has some minimum range; an arithmetic expression may over ow and raise an exception when the code is ported to a platform where Integer has a narrower range. The potential nonportability can be avoided by declaring custom numeric types instead of using the predefined types. Figure shows an example.

Follow usage patterns

FIGURE 1 | Elaboration order. Elaboration order nondeterminism can also be avoided by using SPARK, since the SPARK restrictions ensure that all elaboration orders have the same effect.

Guidance for target dependencies

System.* package hierarchy and representation clauses: Although low-level programming involves accessing targetspecific characteristics, Ada helps to mitigate the nonportability through standard language features. The package System declares a type Address and associated operations, and the child packages System.Storage_Elements and System. Address_To_Access_Conversions offer standard facilities for dealing with raw storage and for treating a pointer as a physical address or vice versa. Representation clauses allow the program to define low-level properties of program entities, such as the layout of a record or the address of a variable. These features are permitted by the FACE Safety and Security capability sets. Although their usage is platform-specific, encapsulating such code in the bodies of www.opengroup.org/face

riting fully portable code requires not only FACE conformance but also functional portability. That means following appropriate usage patterns, especially for features whose semantics are not completely defined by the language standard. Ada is, in general, a language with strong support for functional portability, and over the years system moderni ations have successfully ported large Ada programs to new hardware and new compiler implementations. onetheless, functional portability does not come automatically, it must be planned for; developers should either avoid language features that are implementation-dependent or else take appropriate mitigation measures. This is especially important for applications that need to adhere to one of the FACE Safety and Security capability sets profiles. Such applications have strong assurance requirements, which are difficult to demonstrate if the code uses language features that are not precisely defined. The S A subset of Ada is particularly relevant, since the SPARK language restrictions ensure deterministic semantics. In brief, adopting appropriate stylistic conventions for Ada most of which can be enforced by static analysis tools such as AdaCore s Code eer or ATcheck) or using S A can help developers achieve full portability for their FACE-conformant software while also reali ing the assurance benefits that Ada and S A bring. ■ r. en amin rosgol is a senior member of the technical staff at AdaCore. He has been involved with programming language design and implementation throughout his career, concentrating on languages and technologies for high-assurance systems with a focus on Ada and safety certification (DO-178B/C). Dr. Brosgol is Vice Chair of The Open Group FACE Consortium’s Technical Working Group. Readers may reach him at brosgol@adacore.com. AdaCore • www.adacore.com FACE Special Edition 2022 |

FACE SPECIAL EDITION

FACE combats existential threats to advance global competitiveness in airborne systems By Chip Downing

As the costs of creating advanced avionics software continue to increase and program funding continues to be constrained, a new business and acquisition approach along with a new technology foundation needs to be adopted to maintain competitiveness with near-peer adversaries; in short, everything must change. To meet this challenge, the government and defense/aerospace industry have joined forces to create The Open Group’s FACE Future Airborne Capability Environment (FACE), which redefines the landscape for developing, procuring, integrating, and maintaining next-generation military avionics platforms. Gone are the days where the United States could tower over all adversaries with unmatched technology projecting global power. Today, our near-peer adversaries can procure and build competitive, if not dominant, systems and capabilities that challenge our best weapons and defense systems. Historically, the U.S. has built manned aircraft platforms with both a single mission purpose and prime contractor and a fixed set of suppliers. Modifications to these systems had long lead times coupled with high change costs. Regardless, this approach worked well in a world where the number of aircraft types was constrained and the cost of aircraft was modest when compared to the cost of aircraft today. ut in our new era of unmanned systems and relatively high airframe costs, this way forward is no longer feasible, especially with multiple near-peer adversaries emerging and evolving faster than we can innovate. This challenge is exacerbated

24 | FACE Special Edition 2022

by tightening military budgets and our equipment moving to unmanned, robotic, and autonomous platforms that drive both software and system complexity higher.

MOSA to the rescue

How to compete in this new environment? There are many vectors we can traverse to change this situation, but one vector that has proven to be successful is to build a new procurement and technology approach that creates system capability agility, coupled with a procurement process that does not need to ow through a platform prime contractor. The .S. military has now fully embraced a Modular pen Systems Approach M SA) that opens up systems and platforms to enable the rapid insertion of the best-of-breed technology from a supply chain that supports both legacy defense and new innovative companies. M SA is based upon standards, with one of the most successful to date being the

work of the Future Airborne Capability Environment (FACE) Consortium, a group actively managed by The Open Group standards organization. This consortium consisting of more than government, industry, and academia members has created both a technology standard and business approach. The FACE Technical Standard is based upon a layered architecture. The FACE eference Architecture defines a set of standardi ed interfaces providing connections between the five FACE architectural segments (Figure 1). These interfaces are 1. Operating System Segment (OSS): The SS is where foundational system services and vendor-supplied software reside. An SS oC unit of conformance provides and controls access to the computing platform. 2. Input/Output Services Segment (IOSS): The IOSS is where normalization of vendor-supplied interface www.opengroup.org/face

FACE SPECIAL EDITION

FIGURE 1 | The five segments of the FACE Reference Architecture.

hardware device drivers occurs. I SS oCs provide the abstraction of the interface hardware and drivers from the SSS oCs. This allows the SSS oCs to focus on the interface data and not the hardware and driver specifics. 3. latform-Specific Services Segment SSS) The SSS is comprised of subsegments available in a given airborne platform, including latform-Specific evice Services, latform-Specific Common Services, and latform-Specific raphics Services. 4. Transport Services Segment (TSS): The TSS is comprised of communication services. The TSS abstracts transport mechanisms and data access from software components facilitating integration into disparate architectures and platforms using different transports. 5. Portable Components Segment (PCS): The PCS is the application layer and is comprised of software components providing capabilities and/or business logic. PCS components are intended to remain agnostic from hardware and sensors and are not tied to any data transport or operating system implementations, meeting the objectives of portability and interoperability. www.opengroup.org/face

FIGURE 2 | FACE-certified conformant suppliers with DO-178C certification evidence. Government/industry adoption The FACE Consortium has existed for more than ten years, has refined its suite of standards to production quality, and is now using the third generation of the FACE Technical Standard, Version 3.1, in multiple programs. Due to the many airborne programs the .S. Army is fielding for existing aircraft Future Attack econnaissance Aircraft FA A) and Future ong- ange Assault Aircraft F AA) the Army is leading this open standards transition by specifying FACE standards and other M SA standards in new and modified avionics designs. This strategy enables the .S. Army to leverage the work that is being performed today in moderni ing existing platforms This work can be easily migrated over to Future Attack and econnaissance Aircraft FA A) and Future ong ange Assault Aircraft F AA) platforms as they become part of the eet. In a parallel track, the armed services have also moved military-airworthiness certifications to adopt the TCA C avionics software safety standard proven in hundreds of commercial aircraft. This move produced an unexpected efficiency by creating commercial-off-the-shelf C TS) certification evidence that can be used in multiple programs and platforms, minimi ing the cost for each program. This stands in contrast to the legacy approach of creating safety artifacts for a single platform FACE Special Edition 2022 |

FACE SPECIAL EDITION

with one program absorbing all of the costs. The FACE approach, therefore, creates technology-leading software that can be more readily deployed and can also use C TS safety certification evidence proven on other platforms that accelerates time to airworthiness and deployment. The FACE layered architecture can be directly mapped to industry partners delivering not only FACE Certified Conformant software but also C TS certification evidence, as depicted in Figure 2. Complete descriptions of each FACE Certified Conformant product can be found in the FACE Registry at https www.facesoftware.org . ecause this list of FACE Certified Conformant products changes often, it s best to check it before making software decisions. ow military avionics designers can procure FACE software products from an open market and may also procure relevant safety evidence. The availability of having both companion products is driving a new marketplace that lowers the cost of acquisition and accelerates the time to airworthiness and deployment.

FACE acceleration

In today s world which has a growing number of near-peer adversaries maintaining strategic dominance requires a focused effort by both the government and industry that requires all parties to adapt and evolve to meet new challenges head-on. Adopting M SA and deploying the FACE Technical Standard and business approach has proven to accelerate the inclusion of the latest airborne innovations. In addition, these moves are creating a parallel market for C TS certification

26 | FACE Special Edition 2022

evidence that removes program risk and accelerates time-to-airworthiness and deployment. ■ Chip o ning is the senior market development director of Aerospace and Defense at Real-Time Innovations (RTI). In this position he manages RTI’s global aerospace and defense business. Downing currently serves as chair of the FACE Consortium Business Working Group Outreach Subcommittee and serves as the VP/ Ecosystem of the DDS Foundation. He previously served as senior director of Aerospace & Defense at Wind River Systems, and has led organizations at Esterel Technologies (now Ansys), Validated Software, OnCore Systems, and Mentor Graphics (now Siemens). Real-Time Innovations (RTI) tt s www.rti.com en

www.opengroup.org/face

FACE SPECIAL EDITION

Digital avionics displays from the cockpit to the helmet to the holograph By Sally Cole, Senior Editor The side head-up display for AC-130J gunship cockpits was upgraded with the MAGIC1A high-performance embedded computing system from Abaco Systems. Photo by Airman Cameron Lewis.

The digital cockpits of military aircraft today have increased in complexity and capability by leveraging commercial processing, graphics, and navigation in open architecture designs, bringing unprecedented awareness and advantages to military pilots. When glass cockpits replaced the traditional dashboard of gauges and dials in older ight decks, pilots couldn t stop gushing about the improved situational awareness the digiti ation of their instruments provided. Today’s advances, while more subtle, are delivering similar jumps in capability for ight and helmet displays via improved ight computer processing, high-resolution display graphics, and holographic near-eye displays. These solutions are also happening at a faster technology-insertion rate, thanks to open architecture designs and initiatives.

Enhancing cockpit displays

Cockpit displays like many other defense electronics solutions and products must meet reduced size, weight, power, and cost (SWaP-C) requirements in addition to providing improved capability, all while maintaining compatibility with legacy systems.

28 | FACE Special Edition 2022

e receive varying customer requirements, says uis Espar a, product manager for Abaco Systems (Huntsville, Alabama). “In general, display computers and processors rely on ensuring large central processing unit (CPU) processing in conjunction with strong graphics processing unit ) processing. e ensure the power and interoperability are available out of the box with multicore, multi- igaher , multi-tera ops oating-point processing, and enough memory to make it all work. There s also an expected level of bus connectivity, whether multi- ig, Ethernet, or legacy, such as A I C and Mil Standard avionics, he adds. Some of these requirements also drove an upgrade to an existing side head-up display platform in ACgunships. The biggest challenge involved was that the customer required pin compatibility with the legacy system, says Rob Cox, regional sales manager for Abaco Systems, which supplied its MA IC A high-performance embedded computing system for the upgrade, which aims to enable operational visibility of the battlespace for the platform. MA IC A provides features including increased storage space for mission and ight data, higher processing capacity, and cybersecurity capabilities. MA IC A delivers the latest in graphics and computer processing to a S a -C improvement on a legacy design to ensure seamless integration,” Cox says. “It will allow the customer to reduce the technology footprint on the platform via a serial digital interface S I I upgrade on the system. www.opengroup.org/face

FACE SPECIAL EDITION

toolkit, which enable our customers to easily create high-performance applications to leverage AI inference at the edge, says ave Tetley, principal software engineer for Abaco Systems. AI-based sensor processing applications such as target recognition and tracking can be more effective than traditional techniques and are becoming widely adopted as more compute power is provided within a low size, weight, and power profile. Technology refreshes that involve features like AI capabilities, processors, rugged displays, and cyberdefense are now faster and more efficient thanks to open architecture designs and initiatives like The Open Group’s Future Airborne Capability Environment (FACE). pen systems architecture SA) is enabled via the use of standard interfaces in hardware and common application programming interfaces A Is) in software. [The latter – the API – is how the FACE Technical Standard enables commonality and reuse in avionics software.] The idea of having reuse and being able to leverage a hardware abstraction layer is critical, says Steve Motter, vice president of business development for IEE an uys, California). e have been using the FACE Technical Standard as a design guide in our MF implementation. e support SA in our avionics displays via a communication interface and video processing capabilities, he continues. This includes everything from traditional avionics buses, to A I C , to Ethernet-based video distribution architectures such as ARINC 661.” An example is IEE s . -inch aircraft control display unit C ) designed for helicopter avionics. Applied beyond typical radio and communications applications, this CDU provides a central data entry and status display for the search-and-rescue rotorcraft platform s ersonal ocator System S).

Helmet-mounted digital night-vision display

FIGURE 1 | The EVA system from

Collins Aerospace is a helmet-mounted digital night-vision display. Image courtesy of Collins Aerospace.

Adding a removable terabyte solidstate device (SSD) is “expected to enhance the operational security posture for tactical field operations, Cox adds. Cybersecurity is enabled via Intel’s trusted platform monitor. ike cybersecurity, artificial intelligence (AI) capability is being enabled across multiple defense platforms and electronics solutions. For rugged display applications, Abaco leverages the NVIDIA Deep Learning SDK and Intel’s OpenVINO www.opengroup.org/face

hile modern digital ight displays have made pilots working days much easier, the technology in helmet-mounted displays enables pilots to see in all types of conditions. An enhanced visual acuity E A) system from Collins Aerospace Charlotte, orth Carolina) is helping the .S. avy and Marine Corps transition from analog to digital night-vision systems. This system will be used by rotary-wing and tilt-rotor aircrews to provide advanced digital night-vision and display technology to enhance situational awareness for warfighters. E A integrates a helmet-mounted binocular display for wider, higher-resolution imagery and improved night-vision performance at very low light levels, which is when rotary-wing pilots need it most. (Figure 1.) All of the digital night-vision processing for our E A system is hosted on the helmet within the E A electronics assembly, which makes use of the latest multiprocessor system-on-chip M SoC) technology to enable high-performance, low-power processing, says Michael A. opers, principal systems engineer, Helmet ision Systems, Avionics for Collins Aerospace. EVA represents the next technology leap in aviator night-vision systems, according to Collins Aerospace, taking that next step by providing the visual acuity of analog night-vision goggles with a larger field of view and full color binocular heads-up display symbology,” Ropers explains. “And it replaces dated monochrome monocular displays on the A AI rotary-wing HM S helmet-mounted display system with the latest binocular color displays.” FACE Special Edition 2022 |

FACE SPECIAL EDITION

The system uses the ISIE- night-vision sensor for low-light performance, combined with the displays. EVA is noticeably lightweight and has both high contrast and a large field of view. It s paired with a full-color high-brightness microdisplay, and also offers a substantial improvement in visual acuity, higher brightness, and lower life cycle costs over previous rotary-wing helmet display systems,” Ropers notes. ne of the most surprising aspects of E A is that, beyond its displays, its lightweight, exible night-vision solution is operational whether in-line-of-sight or stowed above the eye, he continues. A seamless transition from day to night operations for our pilots was key in the integrated design of the night-vision sensor and display, allowing for day night operations without the need to install or remove components from the helmet. But the night-vision sensor assembly can be quickly removed with minimal effort if the pilot desires. ork under a developmental contract with the .S. avy and Marine Corps is underway at Collins Aerospace facilities in Iowa, California, and Massachusetts, and with contract completion scheduled for March .

Holographic near-eye displays

The next leap in military display technology may come from research in holographic near-eye displays via new software and hardware advances. A new technique to improve image quality and contrast for holographic displays was developed by researchers from I IA Santa Clara, California) and Stanford niversity; the technique may help improve near-eye displays for augmented- and virtual-reality applications. Augmented- and virtual-reality systems are poised to have a transformative impact on our society by providing a seamless interface between a user and a digital world, according to onghyum im, a researcher at I IA and Stanford niversity. Holographic displays could overcome some of the biggest remaining challenges for these systems by improving the user experience and enabling more compact devices,” Kim says.

M-CODE AND ALTERNATIVE NAVIGATION TECHNOLOGIES Honeywell Aerospace (Phoenix, Arizona) has flight-tested new technologies to enable alternative navigation offerings, including its embedded GPS inertial (EGI) navigation system. EGI supports M-code, the standard GPS signal used by militaries around the world. The flight tests demonstrated a milestone in providing continued navigation solutions within GPS-denied environments. It was also the first time an airborne M-code receiver was flown aboard an aircraft within an EGI, demonstrating M-code in a live environment. While GPS is used for navigation for military applications, a seamless connection to these signals isn’t guaranteed. Even modern systems can have problems within GPS-denied environments like dense urban areas near tall buildings. Jamming can also prevent signals from conveying critical information about positioning, navigation, and timing. Aircraft and vehicles should thus have alternatives such as celestial or vision navigation. “The issues of GPS-denied environments or GPS jamming are felt by every facet of the aerospace industry, but they’re particularly concerning for military operations,” says Matt Picchetti, vice president and general manager of Navigation & Sensors for Honeywell Aerospace. Honeywell is developing multiple alternative navigation technologies to add resilience to GPS and enable continuous, safer, and more reliable navigation if GPS signals are unavailable. It will provide its third-generation M-code EGI to various U.S. Department of Defense (DoD) and international customers in 2021.

30 | FACE Special Edition 2022

FIGURE 2 | Michelson holography shows

significant improvements in image quality, contrast, and speckle reduction compared with all other conventional methods, such as naïve SGD [stochastic gradient descent]. Photo credit: Jonghyun Kim, NVIDIA, Stanford University.

The new holographic display technology is called Michelson holography, which the researchers reported in Optica, an open-access journal from the ptical Society of America. The technology combines an optical setup inspired by Michelson interferometry used in spectroscopy and wave detection) with a recent software development to generate interface patterns to make digital holograms. (Figure 2.) “Although we’ve recently seen tremendous progress in machine-learningdriven computer-generated holography, these algorithms are fundamentally limited by the underlying hardware,” Kim says. “We codesigned a new hardware configuration and a new algorithm to overcome some of these limitations and demonstrate state-of-the-art results. Holographic displays show potential for outperforming other display technologies used for augmented and virtual reality by enabling more compact displays. It improves a user’s ability to focus their eyes at different distances and offers the ability for contact-lens wearers to make adjustments. But so far, the technology hasn t achieved the image quality of more conventional technologies. Image quality of holographic displays is limited by an optical component called a phase-only spatial light modulator www.opengroup.org/face

S M). hase-only S Ms that tend to be used for holography have a low diffraction efficiency that degrades observed image quality, particularly image contrast. It s difficult to dramatically increase the diffraction efficiency of S Ms, so the researchers designed a completely new optical architecture to create holographic images. Michelson holography uses two phase-only S Ms rather than using a single phase-only S M like other setups. The core idea of Michelson holography is to destructively interfere with the diffracted light of one S M using the undiffracted light of the other, im says. This allows the undiffracted light to contribute to forming the image rather than creating speckles and other artifacts. The researchers combined this new hardware arrangement with a camera-inthe-loop (CITL) optimization procedure modified for an optical setup, a computational approach to optimize a hologram directly or to train a computer model based on a neural network.

READY

CIT allowed the researchers to use a camera to capture a series of displayed images. It also allowed for correction of small misalignments of the optical system without using any precise measuring devices. nce the computer model is trained, it can be used to precisely figure out what a captured image would look like without physically capturing it,” Kim points out. “This means the entire optical setup can be simulated in the cloud to perform real-time interference of computationally heavy problems with parallel computing. This could be useful, for example, to calculate a computer-generated hologram for a complicated 3D scene.” The researchers put their new Michelson holography architecture to the test using a benchtop optical setup within their lab to display several 2D and 3D images, which were recorded via a conventional camera. This demonstration showed that the dualSM holographic display with CIT calibration provides significantly better image quality than existing computer-generated hologram approaches. To make their new system practical, the researchers say they need to first translate the benchtop setup into a system small enough to incorporate into a wearable augmented- or virtual-reality system. And they note that their approach of codesigning the software and hardware may be useful for improving other applications of computational displays and computational imaging in general. The researchers received funding from the Army esearch ffice, kawa Foundation for Information and Telecommunications, Alfred . Sloan Foundation, ational Science Foundation, and Ford Foundation. [Link to article: https://www.osapublishing.org/ optica fulltext.cfm uri optica- - id . ■

RELIABLE

TEST & CONTROL SYSTEMS

RUGGED

• Sensor Interface Units (SIU) • Data Concentrator Units (DCU) • Data Acquisition Units (DAU)

SA SA SA

IN N D E IU NU A A D ED E IU A

M M M

UEI UEI UEI

ueidaq.com

www.opengroup.org/face

FACE Special Edition 2022 |

FACE Special Edition Profiles

Transport Services Segment (TSS)

RTI Connext TSS The Future Airborne Capability Environment™ (FACE) technical and business standards promote software reuse across disparate airborne platforms, both manned and unmanned. Within the widely-adopted FACE architecture, the Transport Services Segment (TSS) provides the APIs and capabilities that FACE portable components use to exchange data. 1. Certified FACE™ Conformant Transport Services Segment (TSS)

FEATURES Ą Ą Ą

2. Direct support for Sensor Open System Architecture (SOSA) Interaction Bindings ™

3. Unparalleled Modular Open Systems Approach (MOSA) Expertise

4. TRL-9 Data-Centric Open Standards Architecture 5. Robust Avionics Partner Ecosystem 6. RTCA DO-178C DAL A Certification Evidence

STILL CURIOUS?

Check out our 10 Questions to Ask Your FACE TSS Supplier datasheet.

Connext TSS supports both the FACE Technical Standard Edition 2.1 and Edition 3.1. Connext FACE TSS stack has acquired RTCA DO-178C DAL A safety certification evidence. Connext TSS supports eight+ safety RTOSs with commercial DO-178C DAL A certification evidence. Connext TSS supports over six processor families including ARMV7/ARMV8, Infineon AURIX TriCore, Intel, NXP Power/Arm platform, and Xilinx UltraScale platforms. Connext TSS is the first FACE Certified Conformant TSS, proving RTI's commitment to FACE. Connext TSS is data-centric and aligned with the US DoD Data Strategy.

www.rti.com/products

Real-Time Innovations (RTI) www.rti.com

32 | FACE Special Edition 2022



info@rti.com

www.linkedin.com/company/rti

 (408) 214-3980

@ rti_software www.opengroup.org/face

FACE Special Edition Profiles

Transport Services Segment (TSS)

CinC™ and PHENOM™ – Next Generation Integration Our Configurable Infrastructure Capability (CinC™) and PHENOM™ provide an open framework that enables scalable development and integration of system capabilities. Together, they enable developers and integrators to work collaboratively to address integration scalability challenges head on. CinC and PHENOM manage system complexity with an architecture that embraces constant system variations and enables rapid generation of intelligent runtimeready configurable integration code. Going beyond brittle commonality-based specifications and manual application modifications, CinC and PHENOM leverage dynamically-updated models to generate what was once manually created and maintained. Together, they enhance affordability and speed to fleet by reducing integration and testing complexity, adding deployment flexibility, decreasing errors, and eliminating duplication of effort. Independent and continuous integration is enabled by our configurable design of the infrastructure and our advanced model-derived and optimized configurations. The architecture, software, and design of the tools fully support the FACE™ technical specifications as well as other interface and protocol-based standards. PHENOM is the ecosystem for development, review, validation, and tracing of data, integration, and deployments models. Leveraging Skayl’s FACE Conformant Domain Specific Data Model (DSDM) in model construction increases interoperability across other systems and domain via previously modeled interfaces.

Ą Ą

Ą Ą Ą Ą Ą Ą Ą

Streamlines Model Collaboration enabled by dynamic model analytics reports and model health indicators Achieves System Interoperability Over Time leveraging multi-model versioning and advanced configuration management Provides Integration Flexibility with optimizable and configurable data and behavior mediation configurations Post-Deployment Configurability enables updates to system performance and message and interface variations Automates System Impact Analysis with temporal backward and forward versioning and impact tracing Multi-Standard Support across the FACE Technical Standard and other protocol and interface specifications Streamlines Conformance Processes with generated test and configuration artifacts Tool-Neutral Integration provides user-definable workflow and processes to utilize data model content Generates Integration Models and Software eliminating manual and error-prone repetitive tasks

CinC, a next generation FACE Transport Service, enables integration of systems through generation of infrastructure software derived from the data model, integration models, and deployment models developed in PHENOM. CinC provides compilable integration code generation through a variety of included and customizable templates and integrator-optimized data manipulation functions.

FEATURES Ą Ą Ą

Eliminates Integration Ambiguities though automated semantic-based interface matching and discovery Automates Validation & Testing of system interfaces and integration logic with generated stimulus functions Produces Always Conformant Data Model Exports with advanced guided modeling and tool-assist features www.skayl.com/whitepapers

Skayl

www.skayl.com www.opengroup.org/face



solutions@skayl.com

www.linkedin.com/company/skayl

 410-848-4946

@ Skayl_It FACE Special Edition 2022 |

FACE Special Edition Profiles

Transport Services Segment (TSS)

Transport Services Development Kit (TSDK) The Transport Services Development Kit (TSDK) is an Innovative, Open and Robust FACE™ Transport Services Segment (TSS) solution provided with Government Purpose Rights. Designed around a modular open framework; TSDK is built for MOSA. Key characteristics of the TSDK approach include: > Affordability – TSDK is available to any Government program at no license fee, reducing program risks around data rights, licensing and vendor lock. > Openness –TSDK is extensible through an open, inclusive, predictable process allowing contributions from different vendors. Contributors to TSDK maintain their IP and can develop business models around that IP. > Quality – TSDK includes the verification/data packages needed to support functional verification and airworthiness in production deployments. > Standards-based – TSDK supports all required/optional TSS component deployments aligned to 3.x versions of the FACE Technical Standard.

www.joviansc.com

Ą Qualifiable code generation framework using model-based

templates for TS-API code generation. Ą Embedded software libraries with open, modular interfaces provide all TSS capabilities. Ą Cross-platform UI supports editing FACE Data Models; manages code generation & TSDK configuration based on model data. Ą Model-based foundation for TSS development built on the Eclipse Modeling Framework (EMF) provides flexible integration options. www.joviansc.com/tsdk

TSDK General Availability planned 4Q22, conformance in 2023.

Jovian Software Consulting

FEATURES



info@joviansc.com

 616-920-0458

www.linkedin.com/company/jovian-software-consulting-llc

Unmanned Systems Virtual Conference: Enabling artificial intelligence, safety certification, and MOSA in military unmanned platforms Platinum sponsor: Wind River Unmanned aerial systems (UASs), unmanned ground vehicles (UGVs), unmanned surface vessels (USVs), and unmanned undersea vehicles (UUVs) continue to be force multipliers for the U.S. military operations. These platforms not only deliver lethality in wartime but also feed the Department of Defense (DoD) thirst for sensor data, collecting critical intelligence, surveillance, and reconnaissance (ISR) during peacetime. Performance and capability requirements flowing out of the DoD are driving innovation at the payload, sensor, avionics, and communications level. The Unmanned Systems Virtual Conference is designed to drive awareness and thought leadership around embedded electronics technology for unmanned systems from artificial intelligence to signal processing to avionics safety certification; it will also examine strategies for applying a modular open aystems approach (MOSA) in such designs. Watch the webcast: https://bit.ly/3vjS0P5 (This is an archived event.)

WATCH MORE WEBCASTS:

https://militaryembedded.com/webcasts/ 34 | FACE Special Edition 2022

www.opengroup.org/face

FACE Special Edition Profiles

Platform-Specific Services Segment (PSSS)

ARINC 661 Compliant Avionics Displays with Ansys SCADE SCADE Solutions for ARINC 661 Compliant Systems is a simulation toolset that empowers engineers to prototype and design ARINC 661 compliant systems, embedded Cockpit Display Systems (CDS) and User Applications (UA). For CDS developers, the toolset features a customizable ARINC 661 compliant widgets library, delivered as SCADE models; ARINC 661 configuration files to define the widgets list and their interfaces; and the automated generation of an ARINC 661 Server. For UA developers, the toolset features the design of UA pages as models, the automatic generation of standard binary and XML Definition Files (DF), and the automatic generation of communication code between SCADE Suite UA models and any ARINC 661 Server. With SCADE Solutions for ARINC 661 Compliant Systems, aircraft manufacturers, CDS developers and avionics UA developers or integrators can ensure compliance with ARINC 661 Supplement up to 6. They can increase productivity while achieving the highest level of quality and compliance with DO-178B/C safety objectives, as required for the certification of CDS and UA avionics applications. Modular, model-based, certifiable and configurable, SCADE Solutions for ARINC 661 Compliant Systems significantly decrease overall avionics software development and modifications costs. They also decrease the time-to-certification and are an important step in allowing for more modular certification of ARINC 661 compliant aircraft components.

"SCADE Solutions for ARINC 661 is instrumental for driving interoperability and reusability – enabling our team to easily update new functionality for military aircraft as it becomes available." – Omar Facory, Vice President of Mission Systems at POC

SCADE Solutions for ARINC 661 Compliant Systems Product Line ARINC 661 CDS Design Environment: SCADE Widgets Library for ARINC 661 Compliant Systems, SCADE Display ARINC 661 Advanced Modeler, SCADE Server Creator for ARINC 661 Compliant Systems. ARINC 661 UA Design Environment: SCADE Display ARINC 661 Advanced Modeler, SCADE UA DF Generator for ARINC 661 Compliant Systems, SCADE Suite UA Adaptor for ARINC 661, SCADE LifeCycle Reporter for SCADE Display ARINC 661, SCADE UA DF Generator DO-178C Certification Kit FEATURES

• • • • • • •

Customizable Widget Library ARINC 661 Widget Prototyping and Design Automatic ARINC 661 Server Generation ARINC 661 UA Definition File (DF) Prototyping and Design DO-178C Qualifiable ARINC 661 UA DF Generation ARINC 661 UA Communication Code Generation Test automation framework

https://www.ansys.com/products/embedded-software/solutions-for-arinc-661

Ansys

www.ansys.com www.opengroup.org/face



sales@anys.com

www.linkedin.com/company/ansys-inc

 844.Go.Ansys

@ANSYS

FACE Special Edition 2022 |

FACE Special Edition Profiles

Operating System Segment (OSS)

Lynx Software Technologies As the complexity of systems increases, costs and time associated with the creation, certification and deployment of mission critical electronics expand. The best path is to harness mixed criticality systems, partitioning the system in a way where the amount of code that needs to be certified is minimized, isolated from other applications, and proven to operate in the intended deterministic, real-time way. LYNX MOSA.ic for Avionics is a development and integration platform founded on our lightweight hypervisor, LynxSecure. LynxSecure is a separation kernel developed according to DO-178C DAL A standards and supports ARINC 653 architecture requirements.

FEATURES Ą

Fine-grained system control of hardware resources

System immutability

POSIX and FACE™ v2.0 and V3.0 support

Reusable Software Component certificate from the FAA for re-usability in DO-178B/C cert projects

LynxSecure has 20k lines of certifiable source code

Key system functions decentralized and distributed

Embodying the DoD strategy of the Modular Open Systems Approach (MOSA) LYNX MOSA.ic is specifically designed for open flexibility, enabling real-time developers to efficiently realize their design goals on inherently complex hardware/software platforms. In contrast to traditional RTOS platforms, where hardware control, real-time scheduling, security, multimedia, and application runtime services are integrated into a common stack servicing all applications on all CPU cores, LYNX MOSA.ic allows system architects to subdivide systems into smaller, independent stacks which include only the dependencies required. Lynx has used this framework to create specific products for specific applications. LYNX MOSA.ic for Avionics includes a native POSIX DO-178 certified RTOS, certification artifacts, Linux (Buildroot), bare metal applications such as Lynx Simple Applications (LSAs), and a rich set of tools.

www.lynx.com/products/lynx-mosaic-for-avionics-systems

Lynx Software Technologies www.lynx.com

36 | FACE Special Edition 2022



inside@lynx.com

 408-979-3900

www.linkedin.com/company/lynxsoftwaretechnologies/

@ lynxsoftware www.opengroup.org/face

FACE Special Edition Profiles

Operating System Segment (OSS)

FORCE2C The rugged small form factor FORCE2C flight safety certifiable mission computer is powered by a QorIQ-based single board computer with extensive I/O capability targeted at rugged avionics applications specifically requiring DO-254 and DO-178C flight safety certification. DO-254 and DO178C artifact packages are offered for the FORCE2C for this purpose. The FORCE2C comprises COTS boards packaged in a proven chassis design with a high technology readiness level (TRL), allowing customers to focus on application design by reducing integration effort, thus lowering risk and time to market. Additionally, the FORCE2C is designed to be suitable for applications developed according to the principles of the Future Airborne Capability Environment™ (FACE) Consortium. The intention of this standard is to provide interoperability and portability, as well as ensure a robust architecture and high-quality software development. Abaco works with software partners to provide functional support for various DO-178C compliant safety-partitioned operating systems on the FORCE2C. At the heart of the FORCE2C is the SBC314C single board computer. The SBC314C is based on the Power Architecture T2081 CPU, which is supported by NXP’s MultiCore For Avionics (MCFA). This, combined with extensive I/O, including eight ARINC 429 TX ports, up to ten ARINC 429 RX ports, up to four MIL-STD-1553 (dualredundant), up to six logic level discrete I/O ports, twelve RS422 ports (eight without flow control and four with flow control), and three 1GbE ports, makes the FORCE2C ideal for a wide range of high-performance avionics applications where flight safety certification is required.

To minimize program risk Abaco worked with a Designated Engineering Representative to audit processes and artifacts throughout development, so you can integrate our products into your DAL D to DAL A flight safety-certifiable system with confidence. Services to assist with artifacts integration and particular program safety case compliance, with respect to Abaco artifacts, are also available.

FEATURES Ą Ą Ą Ą Ą Ą Ą Ą Ą Ą Ą Ą

QorIQ™ T2081 processor MIL-STD-1553 / ARINC 429 I/O Avionics discrete I/O Comprehensive RS-422 serial I/O D-178C and DO-254 artifacts, DER audited MIL-STD-704F 28VDC PSU Qualified to MIL-STD-461G, DO-160G, MIL-STD-704F, MIL STD-810G Comprehensive software support, including safetypartitioned real-time operating systems Conduction cooled -40º C to +71º C operating temperature Dimensions: 24.3 cm x 8.41 cm x 16.66 cm Weight: 3.7 kgs

www.abaco.com/force2c

Abaco Systems

www.abaco.com www.opengroup.org/face



support@abaco.com

 (866) 652-2226

@ AbacoSys

www.linkedin.com/company/abaco-systems-embedded-solutions

FACE Special Edition 2022 |

FACE Special Edition Profiles

Portable Components Segment (PCS)

FEATURES Ą Integrated Software

IData® Tool Suite

Development Environment for HMI Displays

IData delivers a Human Machine Interface display development environment that saves time, money, and effort across the entire product lifecycle. Developed by avionics engineers, IData combines the power of a platform-independent, integrated tool suite with a data-driven open architecture and flexible development framework aligned to the MOSA principles. This full featured environment enables the development of multiple displays (e.g., primary flight displays, digital moving maps, training and simulation, and command and control) without the need to generate code. IData is fully certifiable to DO-178C and streamlines re-certification after implementing design changes.

Ą Aligned with industry Standards

(FACE™, ARINC 661, Khronos, AS9100)

Ą Reduces Life Cycle Costs and

DO-178C Certification costs

Ą Multi touch (10 touch points) and

multiple gestures

IData directly addresses rapidly evolving challenges when creating safety-critical systems. Its robust design and flexible workflow help developers quickly accommodate changing technology, increased complexity, evolving human/machine relationships, and the need for a cost-effective balance between software reliability and time to deployment. IData also includes a module for creating 2D and 3D digital moving maps (IDataMap) that expand IData’s value for HMI avionics. This integrated toolset drives down time, cost, and risk across the entire development lifecycle.

Ą IDataMap 2D/3D Digital Moving

Map Toolkit

Ą True Rapid Prototyping with

Behavior based animations

Ą Design Once, Deploy to Many

https://www.ensco.com/aerospace/human-machine-interface-hmi

ENSCO Avionics Inc. www.ensco.com



idata@ensco.com

 607-741-6472

www.linkedin.com/company/ensco-inc/

@ ENSCO_Inc Portable Components Segment (PCS)

Automate FACE™ Conformance with the LDRA tool suite® LDRA has more than 45 years of experience providing software quality tools that help ensure functional safety, security, and standards compliance. The LDRA tool suite helps software suppliers achieve FACE™ conformance through automation, coding standards compliance, traceability, and artifact generation. Furthermore, the LDRA tool suite supports DO-178B/C certification up to and include Software Level A. LDRA is a member of the FACE Consortium helping advance and promote the use of the FACE Technical Standard. LDRA’s FACE Conformance Packages and FACE Verification Authority (VA) services reduce the risk, cost, and schedule of developing and deploying FACE Conformant UoCs.

FEATURES FACE Conformance Packages (FCPs) Ą Execution and production of FACE conformance reports, including Conformance Verification Matrix (CVM) traceability Ą Includes automated coding standard checking as prescribed in the

FACE Technical Standard

FACE Verification Authority (VA) Services Ą UoC Independent Validation and Verification – IV&V activities based on submittal of one or more UoCs and the associated Conformance Statement to the FACE Conformance Workflow Tool. Ą UoC Lifecycle Support – effective performance of SQA oversight that

prepares the UoC for formal validation and Conformance Test Suite Testing www.ldra.com/face

LDRA Technology, Inc. www.ldra.com/face

38 | FACE Special Edition 2022



info@ldra.com www.linkedin.com/company/ldra-limited

 855-855-5372

@ ldra_technology www.opengroup.org/face

The hardware your software deserves. COTS flight safety-certifiable mission computers for your FACE-compliant applications. Flight-certifiable systems and aircraft are complex undertakings with lots of commercial risk. COTS hardware solutions help by reducing cost of development, time-to-deployment, and program risk, letting you focus on your core competency—application development. In addition to being certifiable to DO-254, the FORCE2C mission computer from Abaco Systems is also certifiable to DO-178C for operation with certifiable and FACE-compliant operating systems, so you can integrate our products into your certifiable system with confidence. Flight safety-certifiable hardware with DER-reviewed artifacts—like the FORCE2C—get aircraft out of the lab and into the sky faster. Let us show you how our certifiable hardware boards, board sets and systems can help you stay on task, on budget, and on time.

abaco.com/force2c

SBC314C The brain of the FORCE2C is also available as a certifiable 3U VPX single board computer.