FACE Software Architecture Will Play An Important Role In The Future of Process Automation

Author photo: Harry Forbes

Overview

It may seem odd to dedicate a report on process automation software to a software technology that today has no presence in process automation. However, the FACE software architecture and FACE Consortium that supports it will FACE software architectureplay an important role in the future of process automation as end users and automation suppliers work to define an “Open Process Automation” architecture.

Below ARC answers several key questions about FACE from the standpoint of the process automation business.

What Is FACE?

FACE (Future Airborne Capability Environment) is a standardized system-level software interoperability architecture that was developed to serve military avionics applications. The objectives in developing the FACE standard were to promote the rigorous reuse of software in military avionics systems.  Software reuse enables suppliers to more rapidly assemble and integrate avionics systems and enables different military aircraft platforms to much more rapidly take up new innovations in avionics.

Who Manages FACE?

The Open Group facilitates the FACE standard and technology development. The FACE Consortium, a legal entity, owns the relevant intellectual property and manages the standard development, documentation, testing, and conformance certification processes. The FACE Consortium contracts with other organizations to execute various tasks that require independence (such as conformance-related processes). It also maintains a directory listing FACE-conformant software products. However, it does not maintain or operate any online store or e-commerce operation for selling these software products.  Only the respective developers sell the actual products.

Participants in this organization include The Open Group, which acts as facilitator, plus various consortium members that include hardware and software developers and military avionics end users. In addition, testing agencies and other firms serve in contract roles for the FACE Consortium.

Why Was FACE Developed?

The business objectives of the FACE Consortium are to promote accurate and stable costs and schedules for developing military avionics systems. A second objective was to reduce costs through reuse of certified existing software systems and components to make avionics systems and components more affordable. Another objective is to enable innovation by developing a business ecosystem consisting of multiple suppliers doing business in a market in which software product reuse is a reality. Finally, the FACE Consortium promotes rapid integration and deployment of its certified software products and systems across multiple military aircraft platforms via reduced need for testing, a simplified integration process, and a streamlined airworthiness certification process.

How Is FACE Relevant to Industrial Automation?

The FACE technology and FACE Consortium are important to the future of industrial automation (especially process FACE software architectureautomation) for two reasons. First, the FACE standard itself will be used as the software architecture for the open automation prototype that Lockheed Martin is now developing under contract with ExxonMobil.

The second and more important reason why the FACE technology is relevant to process automation is because The Open Process Automation Forum is using the FACE Consortium as a model. This includes using the FACE documents and organization for the structure of the organization and the model of its eventual deliverables. FACE documents will serve as the templates when creating the standard documents. The work products of The Open Process Automation Forum will be similar in structure to the FACE architectural standards, although the deliverable content and the reference architecture will be different.

What Is the FACE Software Architecture ?  

Rather than a new standard, FACE is a detailed reference architecture.  The FACE architecture consists of five logical layers, called segments.  Between any two segments in this stack are FACE “vertical” interfaces. These consist of FACE-defined application programming interfaces (APIs).  At the bottom of the stack is an interface to an operating system (OS).  FACE specifies interfaces to POSIX operating systems based on three “profiles.”  Each profile is a larger subset of the complete POSIX APIs.

FACE software architectureAt the top of the stack are portable FACE applications.  FACE applications can also support “horizontal” interfaces for direct interprocess communication with other FACE applications. Suppliers (not FACE) define and document the horizontal APIs.

How Does FACE Conformance Certification Work?

FACE verification determines the conformance of an implementation to specifications. Verification is performed by any one of the firms designated as a “Verification Authority” (VA). These are technical experts approved by the FACE Consortium Steering Committee. When verification has been completed successfully, suppliers apply for formal FACE Certification.  The FACE Registration process provides updated lists of all FACE Certified “Units of Conformance” and these lists are available to all members.

What FACE Consortium Documents Are Publicly Available?

These are the most relevant documents, along with links.

FACE software architecture

 

ARC Comments and Recommendations

The FACE standard and FACE Consortium are useful for and relevant to the process automation market for a number of reasons.  But there are also several drawbacks.  Let’s begin by discussing the positive features.

The business goals articulated by the FACE Consortium for software reusability to support vendor innovation and a multi-vendor product ecosystem match the requirements of process automation. These are exactly the goals that ExxonMobil has articulated for several years now at ARC forums.

The second favorable point is FACE conformance certification.  It is critical for any interoperability standard to have a conformance testing and certification counterpart. Independent organizations must test products for conformance. There must be both a well-defined testing and certification process and a thorough set of test procedures. Buyers should know (before they choose suppliers) the conformance status of vendor software products.

FACE software architectureSadly, many important standards relevant to industrial automation and industrial manufacturing (notably many existing standards of the IEC and the ISA) lack any type of compliance testing process or independent compliance organization. This greatly limits the end user value of such standards. The FACE standard, by contrast, includes a well-specified and developed conformance testing and certification process. While this process may not be optimal for the automation industry, it is far better to begin standardization using a model that includes a well-developed conformance process, rather than beginning with no process at all.

The FACE conformance certification process is thorough, but also relatively slow for the internet era and quite similar to industrial safety certifications. ARC believes that the process needs further automation and streamlining to lower its costs, while maintaining or improving the present level of rigor.

On the negative side, several valid criticisms can also be made when viewing the FACE technology and Consortium in a process automation context. These are not necessarily criticisms of the technology itself or its supporting organizations, but rather of the fact or way in which they mismatch the requirements of process automation. Here are three examples:

The normal operating life use cases of avionics systems are different from process automation systems. Avionics’ normal use includes many system startups and shutdowns. For every flight, the avionics systems are usually completely started up and then shut down again. Modifications to any part of the avionics systems are qualified both on the ground and in the air before being accepted for normal use. 

By contrast, process automation systems are required to run for months or years at a time without shutting down. Modifications (especially minor ones) are made on the target automation system while the system is operational. It will be up to The Open Process Automation Forum to evolve a standards-based technology that can be adapted to the long operating cycles of process plants and (hopefully) also be useful in the vertical industries of discrete manufacturing plants, which have shorter operating cycles more closely matching those of avionics.

The Open Process Automation Forum should plan to improve testing and certification processes. The FACE Consortium technology development and certification process represents no speed improvement over most existing conformance processes. The challenge is how to bring today's more rapid IT and open source development and integration processes into the process automation field.  Adoption of FACE or a similar model without improving this process would limit the value of the new technology.

Finally, the FACE standard defines technology for interoperability, but not performance.  The system integrators are responsible for adequate system performance. This is not necessarily bad, but end users need to realize that the FACE standard is designed solely to promote interoperability, not guarantee any particular level of performance. In present-day DCS systems, the system performance levels are assured by enforcing various design constraints, rules, and guidelines.  These constraints are enforced by each of the many proprietary software tools used to configure the automation systems. In the case of future open process automation systems, this responsibility will shift from a DCS supplier to whichever firm assumes the role of system integrator.

 

If you would like to buy this report or obtain information about how to become a client, please  Contact Us

Keywords: FACE Consortium, FACE (Future Airborne Capability Environment), Interoperability, Open Process Automation Forum, Software, ARC Advisory Group.

Engage with ARC Advisory Group

Representative End User Clients
Representative Automation Clients
Representative Software Clients