 Participating today, you'll hear the information live. For folks who are going to be in need of the information at a later date, we will have all of it available for you for future reference. I'd like to welcome you to today's Face Conformance Program Overview Webinar. My name is Judy Surenzia. I'm from the open group and I am the program director for the Future Airborne Capability Environment, Face Consortium. We have two additional presenters today. We have Marcel Padilla, who represents NAVAIR, who will be giving us technical overview, executive overview, about the face technical standard and some details about what sections and segments of the standard that you would need to conform to. And we have Steve Getz, who represents U.S. Army Ammerdeck, who will be giving you information about the policies, documents, process that you go through for face conformance and how to get more information, not only about the process and the steps, but how to contact our various verification, certification, and library administrator authorities who comprise the Face Conformance Program as well. So with that, we will get started. Simon, if you could go to the next slide, please. For those of you who are not familiar with the Future Airborne Capability Environment, we are a government industry collaborative organization. We operate under the umbrella of the open group, which is a global consortium who focuses on achieving business objectives through the use of open standards. The Face Consortium, the face approach, is a government industry software standard and business strategy that we are using to enable folks to acquire affordable software systems, rapidly integrate portable capabilities across global defense programs, and attract innovation and deploy it quickly and affordably. We want to change the current business model from develop once, charge 10 times, pay multiple times for similar capability with proprietary wrappers on multiple aircraft to the point where we have reusable, portable, interoperable software that government and customers can use to procure differently and software suppliers can expand into a horizontal market and be more innovative in how to strategize their software across multiple product lines to support the warfighter and give more capability of the warfighter faster. I did mention that we're developed through an industry and government collaboration through the open group, Face Consortium. We have 90-plus member organizations participating and over 1,100 individual participants on our roster. We've grown exponentially over the past six years and very proud of the fact that we are now in a position to put the business strategy in place in order to enable the standard and the adoption and uptake of the standard to propagate to the customer, which is right now government military aircraft and software industry. Next slide. So the benefits to government by developing an open standard using a collaborative environment between government and industry is to meet the better buying power needs that are called out as a lot of the directives from the U.S. government. Better buying power enables us to increase competition, achieve affordability and control the overall life cycle costs of the multiple programs for the various aircraft that are out there for Army, Navy, Air Force, some international communities as well. We want to incentivize productivity and innovation in industry and government and ultimately reduce software development times, saving time and money through modularity and portability. It also allows for cross-program or cross-platform decision-making. Reuse is one of the primary tenets of the FACE approach. Reuse applications across multiple platforms without any cross-platform dependencies. Don't invest multiple times for the same capability and enable integration of cross-program requirements. Next slide. Industry benefits as well. The FACE approach enables industry to create software-centric product line market opportunities so they can develop capability once and use it for multiple customers across multiple platforms. And it also provides the opportunity for software capability across multiple aircraft types, which may not have been available to them before when they were just supplying product for one customer. This enables them to get into a market where multiple customers can benefit from the capability that they have. It also lowers their cost of doing business. Common standards allow for lower cost and schedule risk. If it's developed once, the QA quality assurance is done once. And if it's proven to work once, it's proven to work in multiple environments. Standardization also allows for rapid development of capabilities and reuse of software enables integrators to optimize platform performance. So if they've tested it once, they've integrated it once, the learning curve goes down and folks can do things more rapidly. Again, with the ultimate goal of getting high-quality capability to the warfighter faster and in a more cost-effective way. Next slide. So I'd like to tell you a little bit about where you can find more information about the FACE approach. We do have a landing page, www.opengroups.org-slash-face, which is our public-facing site. We also have a website that we use for collaboration among our members. If you're interested in joining the FACE consortium, finding out more how to participate, we can give you a little bit more information about that at the end of the webinar. But the landing page will give you information about consortium activities, membership, information about the public documents and tools that we use to support developing FACE software. And some of the things that are out there available, the FACE technical standard, we've got addition 1.0, 1.1, 2.0, 2.1, and various related documents that are associated with that. We have a reference guide, reference implementation guide for each addition to the technical standard. We also have a conformance verification matrix that's associated with each addition to the standard and a data model that's available to correspond to additions 2.0 and 2.1 of the FACE technical standard. In addition to that, we have some of the conformance policy documents, conformance guidance documents, information about library requirements, and information about business guidance, as well as the FACE contract guide, which will enable customers to find information about how to procure FACE conformance software and suppliers to find information about how to put contract language together to offer FACE conformance software in response to an RFI or an RFP. All of this has been put into place, not only to document the technical standard and guidance for how to develop software so that it meets the requirements that are defined in the technical standard, but also the business strategy and tools techniques so that government can procure and industry can provide FACE conformance software in a mechanism and in the language that meets contract requirements. Our big announcement is that we are live and ready for business. The FACE conformance program has all of the pieces and parts in place. We have the documentation in place. We have our conformance authorities in place. The verification authorities who will run through for the record testing of the conformance test suite and some of the other tools that we have for developing and testing that software does meet FACE conformance requirements. We have the FACE certification authority in place who can confirm that all of the testing was done correctly and can ensure that all of the legal agreements are signed and ensure that a certificate is issued to prove that software is conformant to the standard. And then we have the library administrator in place who can confirm that software that has gone through verification that has been certified as conformant is listed in the registry. And the only way that we 100% guarantee that software is certified FACE conformance is if it completes all three steps. So listing it in the registry is the last step of the game. And we're very, very happy that we have all three of the authorities in place. And our panelists that are coming up later will give you more detail about the technical aspect and about the authorities and some of the processes that are in place and procedures that are in place in order to enable making that happen. Next slide. So some of you may be wondering why does it matter? And I will go into a little bit of detail here about why it matters. You can have a technical standard. You can have organizations that work very hard on developing a technical standard. And you can have zero customers that are interested in using any of the capability that's built based on the technical standard. What we would like to see happening here, we want to make sure that we have vendors who have invested in doing it right. There are customers who are very interested in seeing face conformance software. There are customers who are very interested in seeing that commonality, reusability, interoperability on most of their aircraft. And we want to make sure that the software that is produced to conform to the face technical standard does indeed conform and it is interoperable and it is portable and it is reusable. So by certifying that vendors have gone through the process and have completed all of the steps, it identifies who has invested in doing it right. It's a delineator between who is making claims that they're face conformant, who is making claims that they're certified and who has actually done the job. And by having the product listed in the face registry, it gives you a way to check. You're either conformant or you're not. It also lets customers buy with confidence that conformance has been proven by a third party and they do not have to go out and spend or invest additional money or do any additional investigation because it has been verified and the vendor is going to warrant that it's going to stay conformant until, you know, for the lifecycle of the product. And if it's found to be not conformant, they are warranting that they're going to fix it so that they make it right so that it can be reusable and interoperable. And when we realize the value when customers make their choices based on certified conformance, so we want to see products populated in the face library. We want to see choices available for customers to pick and choose among face conformance software so that they have a place to go to get reusable software. They have a place to go where they have confidence that what they buy is going to meet their needs because the requirements have been vetted. The requirements have been included in procurement and the customers have supplied products that do meet those needs. It gives vendors a place to provide a marketplace of conformant products so that they get the word out that my product is out there. I am face conformant. I match the APIs. I've done all my testing. You can choose my product and have confidence that the integration cost will be reduced, the time to field will be reduced and ultimately, again, it's back to getting capability to our war fighters faster. So with that, I'm going to introduce our next speaker. We have Marcel Padilla from Navair who is going to give a little bit of background on why we started not only with a technical standard for avionics on military aircraft but also some background about the business strategy that is going to enable us to adopt that standard and get capability to the war fighter by generating face conformant products. So with that, I will turn things over to Marcel. Thank you, Judy. I'll go ahead and move to the next slide, Simon, or I will try. All right. So when we started this project, we realized that back in the early 60s and 70s that we were building avionics systems in the aircraft and they were very purpose-built and that allowed us to give the industry developers freedom to develop whatever needed to happen in a very expeditious way and at the time there was no constraints on finances or money. That resulted in proprietary solutions that multiple layers within an architecture as described in the left display on this slide. Along in the 80s comes the iPhone, which is an innovative approach and then while some people will say the iPhone is a closed system, it actually has opened up quite an open architecture on the application side by them rigorously defining an application interface and then providing tools for people to develop applications independently that can be downloaded and integrated onto that device. However, the way to manage that, the company has custom middleware and operating system and hardware to make sure that the supporting infrastructure was consistent. And then because of that, that was creating such a competition market that some of the phone providers were losing ability to compete so coupled with Google, they formed a consortium to develop the Android operating system which is a custom middleware and operating system combined and they also allowed to open up the application space by defining an application interface and tools to develop to that but they also opened up what we call the bottom side to the hardware to allow the phone and small device providers to create hardware and compete in that market. So while iPhone still has a large portion of the market share as far as revenue, Android has taken over a lot of the market share for the actual devices. When we started the face consortium because of the government's rules for open competition in all cases, we wanted to make sure we had every portion of the system which included applications, middleware, operating system and hardware. Now face itself, the standard does not address hardware. The intent here is that we address the ability to abstract software from hardware to allow any hardware to compete in that market but we are not defining hardware interface. So traditional approach, I mentioned a little bit on the previous slide, each platform, each software and the mission sets and boxes and integrate them independently. So what I ended up with, as you see on the left side of the screen, four aircraft might need the same equipment but it has to be integrated three different times and each one of those would have a different software load because only portions of those systems were required for each of the aircraft based on their mission set. This caused a lot of integration cost and as you see, there was a lot of integration efforts. With the face approach, we would like to be able to develop those capabilities such as survivability and sensors and terrain awareness one time and utilize the face software architecture to minimize the integration that would have to happen one time for each platform by taking that capability and reusing it and only changing the software that was needed to integrate it. This will allow cross-platform decision making because we can have common capabilities across platforms and thus lower acquisition costs for not having to purchase the same capability multiple times. When we started the face consortium, we established these objectives and they've been persistent throughout the six years of our life. We wanted to establish a portability portable capability-based applications across the Department of Defense avionics system. Since then, we've realized that our software architecture approach is not constrained to DOD avionics system. It's just good software business practices. The rule that we set upon ourselves was we needed to determine a strict set of open standards to establish this environment based on the principles of open architecture, integrated modular avionics and MOSA, modular open systems approach. Some of the attributes of our architectural approach should include portability, modularities, partitioned, scalable, extendable, and secure. Why did we need to do this? There was a demand from the customer to reduce life of costs and time to field. How are we going to do this? We had to obtain industry and DOD program management endorsement which is why we entered into a government industry consortium and lastly we were going to finally come with the hammer that many standards do not bring which is we need the conformance to ensure that the requirements have been met to maximize the interoperability and portability that the standard was defining. So I'll go into the technical overview now. The technical strategy was quite similar, quite simple, I'm sorry. On the left side of the screen we have portable applications so that we wanted to get from one environment on hardware to new hardware and we did not want to address avionics networking. There are many other standard bodies that are working those aspects. We wanted to focus on the actual software that does the actual capabilities or functions that we needed it to do. I'll get more detail as we go through. So what is the faith architecture? As I mentioned, it's a computing environment that will enable product lines for military aviation or any other software product line development. We've established a set of places or segments where we have points of variance. Inside those segments there is design flexibility as long as you meet the boundaries, the requirements of those segments and the boundaries of those segments are bounded by robustly defined interfaces. We have vertical interfaces that are defined in the standard such as operating system interface, the input-output interface and the transport services interface. The operating system interface is based off of two readily available standards, the POSIX standard as well as the entering 653 standard. The IO interface is a very simple, normalized interface. Then I'll talk about the following slide as is the transport services interface. The horizontal interface is standardized in the way data moves throughout the system. Originally we bounded this system within the skin of an aircraft but it could be within the partitions of one operating system or inside one box or between multiple boxes. But again, as I said, we're not trying to standardize the communication pathway between aircraft, networking or those types of things. We wanted to focus on the software architecture itself. So what were the barriers that we were trying to solve? Portability is what we wanted to do. Reusability is the goal. The first step is making sure the software is portable. So on the left side of the screen, we would expect software developers to get a list of their givens that included what display am I outputting my data to? What hardware am I running on? What operating system am I running on? What bus am I transmitting data on? Are there any other software components that I'm tightly coupled to? And all of these things would govern the way I wrote my software and typically I would embed all of those specific functions of my software. The challenge with that is anytime one of those things would change, then I would have to rewrite a portion or all of my software and have to potentially retest all of it. So we categorize those concerns as presentation concerns, input-out concerns, input-output concerns, and operating system and driver concerns. The dependency on other software we can manage as well. What we did in the FACE architecture is basically identify those concerns and we would mitigate them with creating adaptation layers to deal with those so that we could isolate the green square on the screen which if you can see is the business logic or the algorithm that we really want to reuse and leverage the investment on that critical capability. We'll talk more in detail about what those adaptations are, but what these allow is when the display changes, I just change the adaptation software to the display, not the business logic. If my bus that I'm running data on changes, then I change the adaptation layer to that bus. If the operating system changes, it doesn't matter because I am standardizing on a strict set of operating system interfaces that all of the operating systems that are participating in the consortium provide. And then any dependency on the other software would be standardized by the use of our horizontal interface to make sure that the information is being exchanged in a standard way. This is a picture of the FACE architectural segments plus a couple of extras. I'll try to use the annotation function on this display to help me. I'll start from the bottom. So at the bottom, this is outside of the FACE architecture. The FACE architecture is bounded by the dashed lines, the heavy dashed lines in the screen. At the bottom is the hardware. Hardware has multiple meetings in the case that we're talking about, we're talking about platform devices, sensors, effectors, radars, radios, input output devices, those types of things. The next step up is interface hardware. When we talk about interface hardware, the examples are listed in there, mill standard 1553 bus, Ethernet, airing 429, discrete ways that we're going to transmit data across hardware boundaries. Both of these things have are implemented in non-standard ways and typically output data in non-standard ways, whether the data from the sensors or effectors are proprietary in nature or the implementation of the standard interface hardware is implemented not exactly the same. Because we've recognized this from the experience of the multiple companies in the consortium, we realize we had to figure out a way to deal with this change and isolate the change from our algorithms or business logic that I talked about on the previous slide. The first step is obviously the operating system which is indicated by the L shape, the gray L shape on this. The operating system provides many features that any software system would require which is, you know, the standard things such as file systems, network stack, as well as access to the device drivers that are on the actual hardware on the processor. So what we see is that we define an operating system interface in the green line that's up the left side of the diagram and this is going to provide those execution services for all software in every segment. In some cases the operating system can be used for communication and I'll talk about that in a moment. The next step, though, is the input output service segment. The intent of the input output service segment is to normalize the implementation of the interface hardware that I discussed down here. So the point here is that if I have one manufacturer of a Milstander 1553 card and another manufacturer, they might slightly implement that. They might slightly implement the standard slightly differently and because of that, the outputs will not be quite the same. So the purpose of the I.O. service is to take that proprietary implementation and normalize that so that all the data is passed through the input output interface in a normalized fashion. The calls are very standard and very simple here, input open, close, read, write, send, receive. And then there's a standard message format that the data is put into that is defined in the standard. The key part of the I.O. service is that it does not understand the data. It's only purpose is to take the data from the interface hardware, put it into a standard envelope and pass it through a normalized interface. So the key part of the I.O. service is that if I change from one vendor 1553 card to another, I only have to replace this component and I don't have to replace any of the other software in the system. So moving up the stacks, the next segment that the face architecture defines is the platform specific services segment. As in its title, this still has some specificity and is available. We'll talk about a few sub segments. The first one is platform device services sub-segment. And the primary role of this device or this service is to take the data from a sensor, analyze that ICD and transform that data into a standard format that's defined by the face standard. This allows this service to take this information it receives from the I.O. service that it received from the bus that received it from the sensor and convert that into data that the rest of the software in the system can understand in a standardized fashion. This also allows for ability to control some basic controls of that sensor or effector. But what this also allows is if I have a sensor that's a GPS device and I go from one vendor to another, I can replace that GPS device. I only have to change this piece of software, not the input output service or the other software that would consume the data from that. Again, the intent of the face architecture is to isolate change away from our valuable algorithm. Again, the intent of the face architecture is to isolate our valuable algorithms or business logic at the top of the stack. The other sub-segment in the platform specific services is platform common services which includes things such as health monitoring, fault management configuration services. FACE does not define the requirements for these. It defines the requirements on where to put these in the architecture so that you don't tie your business logic to health monitoring, fault management or system level configuration. You can isolate that by creating a separate component that if you change your requirements of your monitoring or your configuration, it does not affect your portable application. The third sub-segment in the platform specific services is graphic services. We realize that many graphic services are closely tied to their drivers such as OpenGL. We did not want to add additional layers of interfaces or processing as well as sometimes there's some latency challenges with graphics. We identified a way to deal with that and identify the graphic interfaces that they're allowed to use and in some cases go direct to the graphics driver. Moving up, once the data has come through any of the components here that needs to go to be consumed by my business logic, it will go through the transport services interface. Transport services interface is again another normalized interface. Very simple, open, close, read, write, send, receive and call back. Seven basic functions that are the syntactic interface but now we introduce the face data model or type specific interface that actually spends model data that understands the semantics. We have a semantic interface of the data. From this point forward, all the software not only has a standardized interface fantastically but also a semantic understanding of the data. Transport services has some features that need to provide routing and configuration at a minimum but it also has some conditional requirements that are available and we provide requirements on how to implement them in a standard way but you are not required to implement them in all cases. Things like data conversion, data marshalling, quality of service and those are all system level requirements depending on your integration of that information in your architecture so that you do not inadvertently put that information in your valuable business logic so that you have to change your business logic if you port it to another system. On the other side of transport services is the transport services interface. Just the way we have drawn this diagram as a layer is going to depict this way. I have a different slide on the board. Our portable component will take this information. It only has an interface that it only has to speak to the transport interface and it only has to speak to use the OS interface and other than that this is where it provides industry that the valuable innovation that they can create all of their excellent innovation and capabilities in these capabilities. They can compete in the transport services layer and there are sensor and effector developers that can provide their platform specific services that accompany their devices that they sell and there are interface bus hardware developers that can provide input output service with their components to further allow their capabilities to be integrated using the face architecture. This is another picture of the face architecture. It is exactly the same architecture just drawn differently. This one has a few examples and I'll very quickly summarize my previous conversation with a little bit of a data flow. Using a GPS is an example. I want to get GPS data displayed onto my display. I start with a GPS device. It outputs proprietary data onto the mill standard 1553 bus which has been integrated on a 1553 car that has been produced by company A. That has a driver that the operating system interfaces with. We will write an IO service that takes the proprietary implementation of 1553, normalize that data into a standardized envelope and pass it through a normalized IO interface to a platform device service up in the platform specific services. This is where that data is interpreted using the GPS ITD and transformed into standard face data architecture and pass through the transport services interface to the transport service. Transport service through configuration knows that data needs to go to application 1. Application 1 will consume it. It will conduct its calculations and output data through the transport services back to transport services interface back to transport services. They will route it to platform specific services graphics to be output up displayed on a GPU driver and then out to the actual display itself. In each case, every time any one of those things changes in the loop, we have the ability to connect each of the segments, thus keeping our portable applications portable. As we go down the stack, there's a little bit less portability, but if you are tied to the same hardware in all cases, then your software should be portable with that same hardware. This is a slide that just summarizes kind of the bounding of each of the what we're calling unit supportability. If it's relevant to unit performance, it's just a little bit easier for folks to say of how I'm going to make it portable. For instance, in the PCS and portable components segment, it has to conform to the transport service interface and the operating system segment interfaces, which include operating system interface or programming language runtime or a framework interface. Segment components, they have to conform to the operating system segment interfaces, and the interesting part about transport services, it provides the transport service interface. So that's the other interface it still has to conform to by ensuring that it provides the transport services interface to its consumers. For the platform specific services segment components, they need to conform to not the operating system interface, but also the input output service interface. That's the reason that we put system level health monitoring and system level configuration services in that segment so that they would have access to all interfaces within the software system, as well as they need to comply with the operating system segment interface. I mentioned a little bit about the endeavor that we've added, so there's a strong metamodel in the face standard, and it's robustly documented, but essentially what we are doing is we are creating a platform independent model standardized with rigorous mathematical models to make sure it's verifiable. And what we're trying to do is capture the semantic understanding of the data. ICDs have done a great job. They are only as good as the people who are available to interpret them. By capturing the information robustly into a semantic data model, utilizing these OMG model driven architecture principles, we can utilize all of this to create auto transformations if we have independent development of messaging. I'll very quickly go through this, but the conceptual data and conceptual views of information that are not platform-specific at all, air, sky, vehicle, those types of things. We'll utilize data refinement and step down to the logical data model view where we start talking about observables and measurements that we can apply and give more context to those conceptual views. This can project a message, and then when we move to the platform specific model, we can add in specific information related to our aircraft itself or our system itself, and this can actually create the message. We document the entire tree and the message in a unit portability supplied model that is delivered with their software. That model can generate the actual code for the interfaces in using IDL and we have IDL to language binding mappings that can then be used in our integration with our software. Every unit of portability, unit of performance from the piece portable component segment in the platform specific services segment, we'll have one of these delivered with it to provide that semantic understanding of the data that that component requires. Because we're talking about conformance, that's the data that we need to send. Transport services API provides the structure in which to send it. Everything in green and blue are required, sorry, this purple is also kind of hard to see, but those are required and then red and orange are optional. Optional requirements don't sound like they're standard but the reason these are system level decisions and face conformance is done at the component level. Based on my system, I'm going to develop a component and if my system requires quality of service requirements, then I'm going to put those quality of service requirements in the transport services component that I'm developing and I will add the associations that are required. So we are providing not only the data model but the structure in which it's sent over the transport services API. All of this is testable. I will talk about a little bit about performance testing. The data model, we have a performance test suite that tests for the data model by verifying that it is constructed to the face shared XMI format. It also verifies that it is compared against the face shared data model which is a configuration managed list of basis elements at the conceptual and logical level. This performance test suite will also generate the data types from that UOP supplied model and verify that the data types that are provided in there are the only data types that are used by the unit of conformance that's under test. So four very rigorous tests that the performance test suite does on the data as well as the performance test suite will also test that unit of performance for the interfaces that I mentioned. Either the transport interface, input output interface or operating interface is getting capabilities to the warfighter faster at a lower cost by increasing portability and thus reusability. The documentation is being designed through an industry government collaboration which ensures that both are reaping the benefits that Judy talked about at the onset of this brief and technical standards being considered for all defense avionics software procurements where reuse is available and commercial industry is also looking at it and has already started to address it. The FACE initiative is addressing business concerns that have hampered other OA initiatives such as conformance program. Without a strict conformance program you can't ensure implementation across the board and we are very excited about having our program being stood up. Steve gets to get into the details about the conformance program and the process that software suppliers would go through. I do have a question from the Q&A chat. So are conformance tools open source and are there plugins for standard tools such as Eclipse IDE? So the conformance tools are open source that can be downloaded from the open group website and there is one for each version of the standard not intended to cause confusion but the consortium identified that there would be contractual limitations and then we didn't want a vendor to be unfairly constrained by they went on contract and version one of the tool was available and by the end of their contract version 5 is available we didn't want to force them to go to version 5. So all versions of the tool are available to them. It is expected to use the most current version if possible but those are all available. They are not tied to a specific IDE they are done in a generic modeling environment and they are the ability to be run on Linux and Windows. Any other questions? No that was the only one that came through so I appreciate that very much. With that we will now switch gears and introduce Mr. Steve Getz from US Army MR DAC to give us more information about the actual conformance processes, where to get information about the conformance process, conformance documentation and how to go about going through the various steps of verification certification and registration to get based off where they are completely certified and listed in the registry. With that I will turn things over to Steve Getz. Thanks Judy. I hope everyone can hear me okay. Am I running slides? I am. So that is me Steve Getz and I am looking at 75 attendees so I wasn't nervous until just now. But anyway my intent here is first of all to provide an overview of this in detail. Not a huge deep dive because we just don't have the time but I will describe the policies and procedures and some recommendations that are made in getting through the face conformance program and getting ultimately certified and listed on the registry. The key take away I would like to stress right here at the beginning is that I am going to talk about some of the available sources. Some of them have already been mentioned and I am going to mention them again because I think they are that important and because they are already in my slides. So without further ado we will jump right in. So here is a very high level of view of the conformance program and it is associated three processes being applied but this diagram has been referred to as the perfect diagram. Since I was involved in its construction I had no argument but the next slide is what we call the more perfect diagram. In that you will notice on the top left we added a step of conduct preparation and while that is not an official part of the face conformance program it is in fact so critical and that is what we are going to spend a little bit of time talking about as we get through the rest of this presentation. If we don't get down to your question and at the end we will have some time where I will certainly do our best to get you an answer and if we don't have it I am sure we can follow up with it later. While we are on this diagram the flow from the top left of the software supplier and let me just describe a software supplier is someone who supplies software and that sounds a little silly but what that means is it might be the system integrator it might be the subsystem integrator it is not necessarily the person who was the software developer but who actually supplies the software that is assessed for face conformance so there is the role of software supplier and they remain in control of stepping through this process and I will talk a little bit about that as we move along. Once you get through preparation you would initiate verification and that is done through an authority called a face verification authority we have VA's as they are addressed. Two are from government one army one navy and two are from industry from SIRTAN and Tucson embedded systems currently and we are expecting more. They are assessed by a VA approval committee to make sure that they meet muster and they assert that they will remain current and qualified and they are in fact an expert on the face technical standards and the associated verification methods by which there are two and Opus touched on this slightly we use test and we use inspection or a combination of those two. But they will do the testing and inspection of the submitted software known as a unit of conformance and it is provided verification evidence from there if the software once they pass if the software supplier chooses to do so they can proceed to certification. We have one and only one certification authority and the certification authority reviews some documentation received from the VA and from the software supplier make sure that it meets the requirements for that paperwork and then will issue the conformance certificate associated with that unit of conformance. From there the software supplier again has a choice to register on the face registry and it is done by addressing the library administrator of which there is one. The library administrator will look at the descriptions that are offered for the UOC check back with the certification authority to make sure that a certificate has been issued for the UOC that wants to be listed and then it can be pushed up on the registry and the registry is a very important part of this process and program. It is the listing of only face certified UOC's so if they haven't completely met conformance and it is binary you either pass completely or you do not you will be unable to be listed on the registry and to do that you also must go through certification. So the next slide and Judy showed I think the same slide but again I wanted to mention it because it is so important is the face landing page. I am going to focus primarily on what is available related to conformance but if you are not familiar with the face consortium and its architecture and its approach there is a lot of other information available through this landing page so this website here if you haven't put it in your bookmark shed I would recommend that if you want to proceed with the face approach. So the next shot here is drilling down to the conformance tab of the face landing page and this is where again you get the pleasure of viewing the more perfect diagram but also there are four tabs there starting on the left where you can get conformance publications ranging from the conformance policy we have a conformance certification guide you can download the related conformance verification excuse me matrices you can download the test tools and all of these things are freely available there is no secret to this stuff we tell you the standard we let you test yourself before you get there because we want to populate that registry with conformance units of conformance and really make this approach a success. The next tab is conformance guidance and what that tab does is step you through the preparation phase the verification process the certification process and finally the registration process our conformance certification guide that I mentioned previously has recently been published and our goal is to get that linked directly through the steps in this conformance guidance we're not there yet or the conformance subcommittee that I'm a member of is working hard to continually improve this landing page and this tab to help the software supplier and integrator or whomever understand and get through the phase conformance program and processes. The third tab there with the green check mark on it is a link to conformance authorities I mentioned them before we have verification authorities and we have one certification authority the links there as you drill down will provide contact information to our current four verification authorities and also directly to our certification authority excuse me and then lastly we have a tab for frequently asked questions just ones that have continually bubbled up either at face-to-face meetings such as this webinar and then also there is a conformance term definition listing there so if you have a question regarding face terminology hopefully it will be answered there okay so now we're going to step through the preparation and then the other three official steps of conformance in a little more detail and it may spur some questions which will do our best to answer once I get through these slides so the role of software supplier there on the left of course it's very important to obtain your references and your tools the reference repository also known as the open group bookstore can be accessed via the face landing page via the conformance tab you can google it there's a bunch of ways to get to this stuff and we are absolutely not trying to hide it we are trying to get it available if we had a mailing list I would think people would send it out but by all means get these documents read through them I am not a software developer but I'm told that this is not building rockets while it may fly on aircraft it is straightforward and can be the standards and the technical requirements in the technical standard are not new they are certainly being driven as Opus said through specific interfaces and then some control of the development inside the segments but we're not inventing things here to make this difficult we are trying to ensure portability and reuse so you have your references the next thing that is recommended to do in preparation is to reach out to one of those verification authorities and establish a relationship and there's really two relationships that are there one is the legal relationship there's a verification agreement between the software supplier and that VA that sets out what will be performed by the VA how many times would it be performed before it would be renegotiated if there's difficulties also what type of evidence needs to be provided and what methods would be used to exchange that information and provide feedback that's done on an individual basis by each VA the consortium doesn't get in that business if there are issues we certainly need to address them but those VAs are independent authorities however without the approval of the consortium they can't perform the verification role the other relationship between the software supplier and the VA is really the technical relationship the working back and forth to ensure that they get a successful verification of the submitted software the unit of conformance that was addressed earlier and the unit of conformance is the element that face conformance is based upon and it can range from an operating system to a portable segment component some may be very small an example I'd offer is just something that keeps time to an OS is a much larger block of software so one of the questions that comes up frequently is well how much is verification going to cost and the answer that I give and it may not be popular well it depends and it depends on how big the unit of conformance is, how many there are how well prepared the evidence is that the software supplier provides it to the VA so this is where that relationship and that communication is critical so as that goes on then the software supplier on the third oval in that square on the left or that shape on the left would develop their unit of conformance there's lots of references on how to do that certainly the technical standard there's a reference implementation guide and there's more help on the way so certainly a doable process so the next step then is to establish a library portal profile and we'll talk a little bit more about the library portal here in just a second quick second so here's the second website address URL that I would recommend you note and my understanding is of course this webinar will be available but I think these slides will also be available and so this library portal has two major parts to it one is it houses the FACE registry again the registry is the public open to the public listing of conformance units of conformance that are available through the representatives that are listed there it does not house software you don't download your app from this registry what you do is you obtain the description of the application or the UOC and then a point of contact and how to get to them to negotiate obtaining one of these units of conformance again it won't be on the registry if they haven't passed muster all the way through verification and certification and then the other piece which is the UOC management and this can be used by software suppliers starting from verification all the way through registration and we'll talk about which steps are required and which ones are optional okay so I'm going to show a series of DODF diagrams and these particular ones are called OV5Bs and it all sounds at least to me it's a little intimidating to talk about DODF diagrams and their particulars and these diagrams can in fact look a little busy but please don't let them scare you again this stuff is not rocket science we just wanted to be able to provide depth through if you think back to the perfect or more perfect diagram that encompasses really the major pieces of the face conformance program but as we look at this we can see that the software supplier who hopefully during preparation established that relationship with the verification authority submits their software verification package which contains some paperwork contains some compiled object code for the test environment and some instructions on how that was made and how it would run with the test suites the verification authority can do that there's certainly room for back and forth the verification authority performs the assessment through inspection of the design documents and information provided and then conducts the for the record test using the face approved test suite again the software supplier has full access to that exact same test suite so that there should be no surprises they perform the evaluation if there are some issues then there's some back and forth feedback is provided all this is done first of all in accordance with the face consortiums policies and processes but also in accordance with that verification agreement that the software supplier and the VA have entered into once assuming the USC passes then the VA would create the verification results package provide that back to the software supplier and then the VA also archives that data in a element of the face library called the verification retention repository and that's there just in case of audit or other need to check either on that particular software or and what was assessed or in case the VA should come up under audit okay so there's verification so the next step then again is certification and again the software supplier controls the timing and initiation of all these steps if you know contractually you have a timeline to meet you'll have to back plan that but especially if it's perhaps an IRAD development or if a software supplier wanted to hold announcement of a particular unit of conformance for marketing reasons or make it at an unveiling of a product or something that could be done and it's again under the software suppliers control so the software supplier reaches out to the certification authority and in this case let me back up just a second on a thought on verification while it's not mandatory that library portal account that we mentioned a few slides ago can be used to help step through verification to exchange information to obtain references and that sort of thing however it is not mandatory but once we move into the certification then the library portal tool must be used that's the method of submitting information to the certification authority by the software supplier the certification authority again there's only one it goes into that library portal looks at the documents provided reaches back to the verification authority to ensure that that unit of conformance did in fact pass verification assuming that all things are in order they create a conformance certificate and that's issued to the software supplier and a bit of information that was submitted along with that certificate is put into the certification retention repository for safekeeping one of the things that I didn't mention here is that there is an agreement between the software supplier and the certification authority that as Judy mentioned part of being certified is that the software supplier warns that their unit of conformance not only meets conformance to the face technical standard but will continue to meet it so if an issue is found the software supplier either needs to repair and correct that issue or their certificate will be pulled and so that's in that certification agreement and that's exposed early on so there's no gotcha to that as you proceed through this it's explained very clearly in our guide and several other documents okay our last step is conformance registration again this is done through that library portal through the library administrator who runs the registry the software supplier through that tool once applies for registration can list a product description of their UOC so it's a free text field along with some established metadata that help describe that product that UOC for anyone who's looking at the registry the library administrator once they receive the request will reach back to the certification authority just to ensure that the UOC that wants to that they're desiring to have listed did in fact receive a conformance certificate they verify that library administrator receives that verification and reviews the posting and then pushes it up onto the face registry the face registry again this is another one I certainly stress is very important this is the public access viewing of your product your conformant UOC and this is where project managers and system developers are going to go look for these existing UOC's and understand that they have the pedigree of having been through this fair conformance program and received certification so really important to follow it through all the way to the end okay so did we get everything perfect absolutely but what if there's an issue okay the face consortium has a problem reporting and change request ticketing system another website there listening hopefully you won't need it but if you do it's there it's a step through tool where you can submit an issue either a question or if you think you found an error or something missing from let's say the conformance policy or one of the technical standards it can be put in there it will be triaged and addressed feedback will be provided the answer may just be an explanation it may be hey we've already dealt with this one or if it's a valid issue it will certainly be addressed in a efficient manner in a thorough manner the problem reporting is actually specific to conformance and that is if there's an issue that's valid that is preventing a software supplier getting their UOC through the conformance program that goes through an expedited process and an item called an approved correction can be developed allowing verification to be completed and then as documents and tools or what have you are updated those approved corrections would be rolled into those tools and documents to make sure that any issue that was found is corrected okay if that doesn't work if at all gets messed up or there's questions or there's disagreements that can't be solved in conformance there is an appeals process and the submitter possibly and most likely the software supplier but it may be a verification authority might appeal something and it goes to the face consortium steering committee and they will review the appeal and make a decision either yes the appeal is approved and changes will be made or it's denied no change is made and that is the final decision should there be a problem we are not advocating them and are not anticipating them but we do have a plan if they should occur so that's the high level walk through and I certainly wanted to leave some time for questions but again I wanted to walk through the process provide the links describe the roles policies and some procedures and at this point certainly call you all to action as software suppliers especially to get your product certified get the face registry populated and let's continue to make the face initiative a success and so I think I know that's the end of my slides and I think Judy is now when we move to the Q&A section so yes I have at least two questions can you all hear me okay okay thank you Judy okay very good okay so the first question as the face standard matures or changes will there be updated conformance standards that will require suppliers to develop new UOC and re-verify through a VA or is the goal to maintain backwards compatibility and either Steve or Marcel I'll defer to you guys to answer that question as you feel the need hey Marcel let me take the first part because I like taking the easy part so so conformance of a UOC is to a specific addition of the technical standard so if so that conformance certificate will list which technical standard which version of the test suite was used to test it and so it's tied to that if a software supplier wants to be certified conformant to a follow on standard or perhaps a proceeding standard they would have to go through a separate verification and certification for that particular addition of the tech standard and utilize the test tool that's a link to that and then so that I think that answers that question and let me I don't put you on the spot Marcel but I think you'd do a better job on the backwards compatible part yeah so there's two pieces to this so the face architecture that I described is an abstraction and interface standard so there's two ways to look at this if I am taking a software conformance design to addition 2.1 of the standard and I want to integrate it into a system that's using addition 3.0 of the standard there is an adaptation opportunity to deal with that change utilizing the requirements of the new standard so we can mitigate that so rather than taking that 2.1 component I may not have to actually change it I may be able to interface with it however if there are some other things or there's a business desire to migrate it then you would do some rework to do that to mitigate how much rework the technical working group maintains backwards compatibility matrices between going forward from 2.1 and going forward so that if someone wants to go from 2.1 with their component to 3.0 they are aware of any potential impacts that may have happened in many cases though the guidance and goals and objectives of the technical working group is not to make the ensuing standards more restrictive but rather extend them so while a 3.0 component may not go to 2.1 the intent is that older versions would more easily be integrated into newer versions of the standard or systems that incorporate components from newer editions of the standard so it's kind of we're trying to hit it all sides like Steve mentioned on the conformance side but on the technical side we're trying to minimize impact as much as possible thank you both and I have one more question what are the kinds of cases where a supplier with a verified UOC would fail to be certifiable can that happen so this is Steve Getz and I'll take that one because I take the easy ones so it's possible the certification step is very non-technical the certification authority is reviewing basically four documents the software supplier's statement of conformance and that's provided to the VA early on and that is where the software supplier describes their unit of conformance and how they meet the requirements of the technical standard so that one has been through a technical review and then it is provided to the CA there's also the statement of verification and upon successful verification fills out this PDF fillable document and states basically the environment in which the UOC was assessed against which technical standard using which test tool which conditional requirements were involved and there's not with me but there's certainly a short list of items that are annotated on that form then there's the certification agreement and that one's going to be there because that's those two things when I mentioned it it provides the warrant by the software supplier that they have conformance software and will maintain it as such and it also ensures that the certification authority gets paid for doing their job so that that will be there and I know I said four and I'm coming up with three and I can't come up with a fourth but if you go to the guide and it may only be three I apologize I'm drawing a blank so the certification authority is going to make sure that those forms are completely filled out correctly filled out an example I think that might be a little possibility is perhaps a part number that's listed on the statement of verification versus what's listed on the software suppliers statement conformance maybe a number gets transposed or something like that that would be the type of thing I think that's possible could happen but as far as technical issues being there those are assessed during verification so I hope that answers your question okay and I have one more question you need to find it give me a minute so would it be more typical to certify a single UOC at a time or to certify a set of related UOC's that together provide a fully functional solution to some mission requirements so we have a item concept I'm not quite sure what to call it called a UOC package okay and there's not particularly a technical reason for making a package of units of conformance but there is likely a business decision in making that yeah absolutely if a group of UOC's complement each other and provide a like you said a mission capability then it makes sense to do that unit of conformance package each UOC that comprises that package has to be individually verified and certified and then a certificate can be issued for that package the thought there is is that that would be listed could be listed individually certainly but also could be listed as a package on the registry so that if you as a provider wanted to you know say hey I've got this greatest capability that you know whatever makes time travel possible the photon torpedo that's something you want to get out there there are a couple of additional requirements to a UOC package and basically you can't run from the top to the bottom on the architecture because what we end up doing there is breaking portability so during the assessment of that package it would be checked to make sure that it didn't violate the rules and there's a diagram and depiction in the tech standard that clearly lays out which segments in combination can't be crossed so I hope that answered that question and let me add one last thing if you have a stack of UOCs that are not related that you want to push through all at once there's no restriction on that either okay thanks Steve I'm looking at one more question okay so when a UOC is registered does that include source code or has it just been executable? So when a UOC is registered it includes no code it includes a description of that UOC there's some free text fields and again there's a long list of metadata stuff and I I wouldn't even pretend to be able to quote it to you but what segment it resides in what technical standard addition it was certified against or certified to things like that that the buyer is going to want to know and then it's going to contain email address perhaps name phone number how do I get a hold of the software supplier who produced this great certified conformant UOC so I can purchase it or acquire it so yeah no code is stored in any of our in that particular part of the library the product repositories which are maintained by the software suppliers is where that code would be housed. Okay great thank you so much I almost said brilliant because I'm on the other side of the pond but I'll revert back to my brilliant. Okay I have one more question that came in from the participants and is face 2.1 still the latest and greatest and what is the status of face 3.0 face 2.1 is the latest and greatest 3.0 is on schedule to be published in summertime of 2017 very good and in response to the call to action I do want to announce that as of earlier this morning probably earlier this week but I've been on holiday most of the week so I found out earlier this morning that we do have our first certified face conformant UOC listed in the face registry it is Rockwell Collins missionized flight management software application it is one of the portable components in the face software stack of the reference architecture and I'm very proud to announce that we have officially completed the launch of the face conformance program through investigation verification certification registration and we have our first face conformant software product listed in the face registry so on that happy note if you have any more questions either indicate them in the chat or indicate them in the Q&A I do see something coming in in the Q&A one more question let me just check is there a policy on who or how many accounts a software supplier can have for the face library and Steve that might be a better question for you in the couple minutes that we have left I am not aware of one and I apologize yeah I don't know of a limitation and I'm trying to understand why there might be one but no not to my knowledge okay so I do know the person who asked the question personally if you would send me an email with that same question in the either the subject line the text I can do some investigation and if you're having difficulty on that type of information I can do some investigation and find out for you my understanding is that the accounts should be on a role based so it could be either individual or it could be company based and I'll get more information and I will get back to you so if you would send me an email with that question I can do some investigation and let you know so in the 30 seconds that we have before we switch from 4 o'clock to 401 are there any final questions parting words closing thoughts for many attendees anyone on the panel that you would like to like to embellish going once going twice so with that I would like to thank all of our attendees for participating today very pleased with the turnout I'd like to thank Marcel Padilla from there and Steve guest from us army everdeck I'd like to say thank Simon from the open group staff my kiki from the open group staff for participating and keeping us in check and with that if you have any additional information feel free to send me an email Jay dot syrensia at opengroup.org you can acquire for more information on opengroup.org slash face and we'll look forward to hearing from you and look forward to seeing more of our members and nonmembers submit for the certification conformance process and see more certified conformance software populating our face registry thank you so much for joining today and you have a good afternoon and a good evening thanks everyone