 and its family assistance, a list of those is provided at the end of our presentation. We have a lot of slides, and I'm going to figure out exactly. We have a lot of slides to present, and we don't have enough time to go into the detail we want to. So during the next few slides, I'm going to talk about some of the background information from our earlier presentations. This slide shows the mission statement of CCDC. The mission statement for the CMS program was to provide a modular systems architecture for rapid deployment of new capabilities to the UH-60 fleet in the shortest timeframe possible. I'm going to manipulate this differently than I thought it would, so it's taken me a little bit more time. To perform that mission, CMS selected the face technical standard and face approach as its foundation for its architecture and management plan. In 2018, the CMS project served as the basis for a large-scale integration event at the PO Aviation Face Tim. 19 vendor products were shown in alternative versions of CMS. The alternatives included replacement key components of CMS as well as extending CMS capabilities. This demonstration started what we call the rapid integration framework, a set of architectural approaches, including the face technical standard that a family of systems can follow to better share software and hardware capabilities. Since that 2018 event, the number of systems in our CMS team has supported, has grown. CMS has flown with an active duty unit as part of a limited user evaluation, and CMS was permanently installed in the UA-60 Air Force HH-60U with additional capabilities to support its gimbal-mounted sensor. Today, the CMS family systems continues to grow across more laboratory systems for demonstration of technologies and is progressing toward deployment on more new aircraft systems. So today, our presentation is on how the common set of architectural approaches can facilitate the rapid integration of new technologies. The time it takes to get a new technology out to our airborne weapons systems is unacceptable when compared to our adversaries. The direction we're getting from DoD leadership is to find new ways to reduce this lag. The face approach was developed to enable the deployment of new capabilities across a variety of weapons systems by having the architectures of each weapon system open to accepting complex software from other platforms. Thus, the deployment of software to the first platform would burn down the schedule and cost of the alignment to other platforms. This technique can be attended to the technology demonstrations we use as technology evolves. This chart shows the TRL levels. As technology moves, it moves from refresh level one through nine. The CMS systems or the systems within the CMS family systems currently include a number of laboratory systems for early technology demonstration through the field of aircraft, and that list is growing as we can see. In the early stages, technology is primarily in the hands of the vendor. As technology demonstrators within the Army, our technology is demonstrated on technology demonstrators within the Army to show how the technology can be used to support the Army's mission. User interface working groups can help evolve the technology in preparation for use by flight crews, and the technology is also demonstrated in flight tests from bolt-on pallets to eventual integration into permanently mounted aircraft equipment. I'm starting to catch up on where I should be on my schedule. Sorry for talking so fast. If we apply a set of common architecture approaches across these systems, we can see the benefits shared software components can provide. We can also see the technology evolution rapidly moving toward a set of components that are ready to deploy. Simulations, for example, can be factored into the architectural approach and reused across early demonstrations. The adoption of architectural approaches common with the field of systems can allow field of software systems for use in early demonstrations. A wider application of these common approaches can lead to a reduction in costs and schedule for the deployment of these laboratory systems as well as provide a path for technology evolution that moves the technology closer to the final architecture, integrates the technology with production systems, and reduces the rework of software after the demonstration period. So, through our experience on CMS, there are several architectural approaches that we recommend. The first of those is the face technical standard. It's an obvious choice. It provides a foundation for a software MOSA that has been directed for use by PU Aviation on development for new and existing platforms. And it stands to reason that new technologies should embrace the face technical standard for deployment to Army aircraft. Some of the other architectural approaches to consider, including in the family systems, include configurable core capabilities that adopts to deployment of new capabilities without the need to recompile or requalify them. This is particularly of interest when a system supports mixed design assurance level capabilities. Core system components can be built to support higher criticality capabilities and simply to configure to support new lower criticality capabilities as they're added. This leads directly to the airworthiness considerations. The patterns for separation of the software capability throughout the family systems application of some of those approaches limits the impacts of airworthiness and future integration of capability software based upon those technologies. Normalizing a set of common services is also critical to a more unified approach throughout the family systems. What language should be the software be developed for? How will the configuration of the capabilities be used in the final aircraft systems? How should the software log events? What user interface capabilities will the software be used for display and control? All of these things could be applied to early technology demonstrators that match what we would find in the production aircraft. We should also be working toward a domain specific data model that's used across the family systems. This can allow the development of new technologies around the data modeled elements that are already existing on the aircraft that can greatly reduce the need for transforms and marshalling within the transport layer. Through this, we can identify a shared data model of changes that will need to be made in support of new technology. We're not asking for conformance early in the process. So those identified elements can be submitted to the shared data model PCB and given a time to get approved prior to the eventual fielding. As mentioned earlier, the factoring of simulations and simulation interfaces into the architecture for reuse across family systems constructed along architecture patterns are better able to adopt to a changing set of real and simulated equipment. This can extend their value to a wider set of systems within the family systems. The use of simulations also plays into training and software development kits. If the family systems has a simulation environment that was portable and available to technology suppliers, the suppliers can get a better understanding of the architecture and develop their software in the architecture prior to the arrival of the first demonstration. This SDK would be developed based upon a reference avionics system that meets the architecture in an aircraft agnostic manner. The architectural approach to user interfaces is a principal concern. Most new capabilities brought to the aircraft will have a new user interface. The user interfaces will likely be provided by a set of configurable core capabilities that deal with the rendering to a display or the inputs from switches such as touchscreens and keyboards. The model view controller pattern expresses the user interface in terms of a model, which is the new capability, a view that the user has of the model, and a controller through which the user can manipulate the model. Software developed for new aircraft systems should separate the user interface from the model in terms of the controller and view components. Having a set of well-defined standards for doing so seems an obvious key interface to include an architectural approach that's selected for the family of systems. Another thing to consider is the rendering of geospatial entities. Many new capabilities we bring to aircraft systems include the situational awareness of the air crew to be informing them of objects and entities around the aircraft. Having a common interface for sending geospatial entities can allow for configurable core components to render this situational awareness data. This can allow new capabilities to be added to the SA system without recompilation or requalification of the SA system itself. So if we look at the selection of the architectural approach using a trade study methodology, we've done a development of the trade study for a graphical standard. We can look at the criteria for evaluation of a graphical standard that fits within what we desire for an avionic system. The portability, the standardized interface, standardized control, limited recompilation, you can read these on your own. Mill Standard 1472G, which is the standard for display, is one of the critical things and, of course, separation of criticality. If we evaluate various alternatives against the list, we see that Eric661 provides the standard that we need for separation of safety concerns. This should come as no surprise as Eric661 was developed to specifically answer these concerns where the other alternatives were developed for other purposes. Some of the alternatives shown here have been proposed as alternatives to 661 and could be utilized as a face technical standard. The rating scale we've used here treats a one as an objective that's built into the relevant standard while a four represents an objective that is not obtainable using that standard alone. And as I said, from this, we can see Eric661 is the only thing that can really meet the safety, separation of criticality, and the integration of a single unified display across multiple capabilities. Some performance concerns around Eric661 when it comes to the generation of complex imagery. Eric661 was developed primarily for the display of gauges and simple, clean user interfaces. When it comes to displaying video, fabricated external views, or rendering PDF pages, the standard provides an external source widget. This widget allows applications to bypass the restrictions of the traditional widgets and render to the graphics card directly. Note that this does bypass some of the user interface advantages of traditional Eric661 widgets and should be used sparingly. The face technical standard 3.0 has formalized the manner that a widget can be used to provide the same level of criticality protections that this external source widget can be used and still allow multiple software units to render to OpenGL. Overlaying the model view controller on the face technical standard with Eric661 and OpenGL might look like this image here. So trying to get to my conclusion so I can get the questions. So the family of systems, reference avionics system utilized in the technology demonstrators can provide the greatest level of reuse within these systems. Using face technical standard Eric661 and a common domain specific data model can get those technologies to the field faster. And using informed engineering decisions should be able to make each program or should allow each program to assess if that program fits within this kind of a family of systems following those strategies. And of course, programs seeking to take advantage of CMS lessons learned may be better served to adopt the decisions presented here. My last slide is the list of presentations that Steve Price and I have done in the past. And Steve can say now, high now, since we have a little bit of time left, if he unmuted himself. We don't see him on there, Chris. Oh, okay. He knew I was gonna be presenting because we didn't have time to really trade off like we had planned. Okay. But this is our Q&A section, so... I do not see any questions in the Q&A. Does any... Joanne, do you? I do not. Okay. Okay, Chris, I don't think we have any questions at all. Thank you very much. Our next paper will... Oh, wait a minute, one just came in. How do geo-entities... This is what it says. How do geo-entities handled by CVS? So in ERIK661, there is a... In the earlier supplements, there is a map horizontal component, which has a way of sending geospatial entities, basically a symbol and a location or a label and a location. You can draw triangles. You can draw a grid of information like you could draw weather on top of a map by sending what's called a map item list to the map horizontal, which individual user applications within ERIK661 can then just render to geospatial without necessarily knowing where the view is on the map. Supplement 8, which came out this year, has brought in three-dimensional mapping, which we can use for out-the-cockpit views. You can overlay that on top of a sensor, a geosensor, or you can use it to render synthetic vision and pan around using 3D. Does that answer your question? I believe it does. Since it came into Q&A, we can't really see. If there are any follow-on questions, please put them in the Q&A and we will get them to Chris. Thank you, Chris. Very much. Appreciate your... Oh, here comes another one. Does FACE account for infrastructure management of the physical network hardware? No, the physical network hardware is something that can be handled by the transport layer. So FACE is basically abstracted that away. Within a family of systems, if we're focusing on a software-centric aspect of the family systems, we should be able to write to a generic transport and we've used multiple transports using the CMS code. So the transport and the physical layer can be agnostic. And the person wrote perfect. Thank you.