Q1: Given that the FACE™️ Technical Standard and Approach support all 5 Principles of MOSA (Modular Open Systems Approach), what other modifications are required to keep the FACE Technical Standard and Approach aligned with MOSA?
A1: The FACE Technical Standard has gained recognition as being a MOSA software solution. However, there is much work to be done by the DoD in terms of defining MOSA requirements in its implementation strategies for future systems. This includes defining conformance requirements for how a software component meets the Government’s MOSA strategy. It is my hope that the DoD will keep the FACE Consortium in the loop as these requirements evolve so that we can further align our technical efforts to meet the government’s needs. For now, we continue to keep the MOSA principles in mind as we look into future improvements for the standard.
Q2: What enhancements to FACE Technical Standard and Approach are expected in 2022?
A2: For the past year, we have been focusing most of our attention on enhancing language in the standard to get better guidance out to the aviation community. We’ve spent a lot of time going through areas of the standard that are either hard to understand or have ambiguities when it comes to intended behavior. There has been a lot of interaction and collaboration among TWG subcommittees in order to enhance the 3.x edition and solve things working together. 2022 is going to be spent rolling out FACE Technical Standard, Edition 3.2, as part of our continued effort to deliver the best possible product in terms of a software standard. We have also made plans for a Reference Implementation Guide (RIG) update and have formed a tiger team to recommend areas of improvements and possible scope enhancements.
Q2.1: What can the FACE Consortium expect in revision Edition 3.2 and any plans for the next major Edition 4.0?
A2.1: FACE Technical Standard, Edition 3.2 is in the works. So far, we have not been in a rush to get it into a review state. The past year has given the TWG a lot of leeway to be able to focus time on CRs and foster more communication between the subcommittees in order to come up with a collective decision on ‘bigger’ issues. Therefore, we are taking advantage of this time that we have available and plan to start establishing a timeline once all subcommittees finish their backlog list. FACE Technical Standard, Edition 3.2, clarifies some requirements language and interface implementation behavior for FACE APIs given certain inputs. It will provide better guidance to UoC suppliers when it comes to implementing FACE Interfaces.
Right now, there are no plans for a 4.0, but there have always been a few suggestions that we keep in our back pocket for when that day comes. In the same manner as moving to 3.0 gave us a chance to align to more current software development practices and digital technology, we will move forward with the FACE Technical Standard to adjust to the evolution of embedded software . We just haven’t hit that date yet.
Q3: What roles can be expected of the FACE Technical Standard and Approach for Future Vertical Lift (FVL)?
A3: Right now, the Army has spent a lot of effort in standing up the MOSA Transformation Office in order to define MOSA requirements and implementation guidance across the individual platforms. As a part of this, the FACE Technical Standard is the primary referenced standard for software implementations, both at the Enterprise and System Design level.
Q4: What exists today and what’s needed for the FACE Technical Standard and Approach to effectively support Systems-of-Systems requirements of FVL aircraft?
A4: My answer to this question tends to change from day to day, depending on what challenges are waiting for me when I log in to my laptop in the morning. Although, the two areas that have come up recently both involve guidance as an area that is needed to support the FVL mission.
A few months ago, I had the pleasure of touring an Army lab where the FACE Technical Standard has played a pivotal role in architecting new experimental capabilities. I must say that it was very impressive. However, one subject that came up was airworthiness; specifically, how airworthiness is achieved for FACE UoCs that maximize reusability using code that has dependencies on runtime configuration. As an example of this, say you have a FACE UoC that uses an abstract class to carry out a task that may be system or mission-specific. The UoC is delivered with various concrete classes that implement this abstract interface in a variety of ways given the integrator needs. However, this creates the situation where there is code that is never called at runtime except under certain conditions. This begs the question for how the software supplier can be expected to structure their artifacts to cover all the conditional cases in a manner that is accepted. It is areas like this where I believe that more guidance and lessons learned from those that have achieved DO-178 certification using these patterns need to get back to the Consortium. The other area of guidance that I feel may need a second look is in contract language. Without diving too far into this one, I’ll simply leave a question that arose just the other day, “When writing requirements for a FACE UoC, what considerations should a platform take into consideration when specifying a FACE Profile?”
Q5: What are the technical hurdles to enabling international adoption of the FACE Technical Standard and Approach?
A5: The FACE Consortium has been working with the Defense Technology Security Administration, as well as the Bureau of Industry and Security to open up the FACE Technical Standard to a broader audience. It is a slow process, but we believe we are on the path to accomplishing this. The challenge has been in demonstrating that while the FACE Technical Standard is a software standard with military avionics as its primary target, nothing in the standard is specific to military software which would serve as a security risk by opening it up to the world.