 Well, good afternoon and thanks for allowing me to present this paper, Impact in Action. We do have limited time, so a link to the paper in two different locations is provided below. I'm Stephen Seemey, my colleagues, are Ed Lopetier and Ken Erickson, the Tucson Invented Systems titled the Paper, Impact in Action, glad you stayed on, Nathan. We are conducting multiple phase development efforts aligned to a series of other design qualification efforts, DO 178, the supplement DO 331, reuse guidance AC 2148 and the airworthiness guidance for the Army 7062. The outline for the paper, for the presentation, we want to introduce impact improvements and modernizations of programing's affecting capabilities and technologies. We got a nice acronym out of that one. Highlight and describe two current phase development efforts. These are multiple phase applications to the guidance described on the cover page and in the title of the paper. I want to identify and introduce a new term, model-based open systems approach. Now we're bringing in the face and open systems approach and applications into model-based system engineering and identify some additional benefits that you actually get using the awesome model-based system engineering tool if you apply it to phase development efforts and then summarize with next steps. So impact, identified improvements and modernizations of programs affecting capabilities and technologies. It was a funded research and development effort by then the Army's named ADD, the director that does the research for advanced aircraft. It was conducted in 2014-2015 with a report printed out. It was one of a series of S&T research efforts and studies. The objective and intent of impact were to prepare the aviation community for using improved tools and processes in order to modernize design and development capabilities that exist back in 2014 so that it can be prepared for the next generation of aircraft designs defined by the vision and referenced in the paper. The development process for the next generation aircraft will be prepared for advanced capabilities. I'll be required to address tomorrow's complex battle space environments. That battle space is both manned and unmanned teams and aircraft and ships as in terms of NAVSEE operating in complex operational environments that is day, night, all-weather, hostile environments with terrain over land, sea, etc. This will ensure that the military will own the environment and the quotes through a collection of highly integrated advanced aircraft and capabilities operating collectively as a set of interoperably advanced capabilities that is a system of airborne systems of systems and there's essentially a lot of references in the paper. So in bottom line, impact was a report for the gaps and tools and processes needed for the next generation aircraft designs. So we want to jump into the description of two-phase development efforts pictorially with the face architectures. We have the Arkham project on the left and the AGX EIS. Arkham is the Army's aviation radio control manager and the AGX is an aircraft gateway with the extra represent next generation and EIS is the external interface systems. Side-by-side we have a comms domain on the left, aircraft survivability equipment onto platforms. We have the face diagrams you can see in very small images down below, the devices that we're going to control. We have several radios on the left and aircraft survivability on the right. Arkham is the Army's comms domain and its shared comms across the aircraft and AGX is the domain for aircraft survivability initially focused on the Apache aircraft. Side-by-side we have face, five face UOCs for Arkham, seven face UOCs for the AGX EIS. Jumping to the bottom, both of these programs will be verified to be face conformant and run through airworthiness. Difference a little bit there. We've got the Army face VA on the left and we've got the TES savvy face VA on the right. On the left we have the more generic airworthiness with a very long new name and acronym to combat capability development command aviation missile command system readiness director dash airworthiness. On the right it'll be the Apache subdivision of airworthiness. So Arkham has five modules as the radio control component, communications manager, the mission and network planning, and the bulk data manager. On the right hand side for the AGX is all the aircraft survivability equipment that's currently hosted on the Apache. We have two versions of the radar warning receivers. We have an MRFI, modern radar frequency interferometer. We have a common missile warning system with the counter dispenser Kirkham. We have two versions of laser detecting sets. We have an infrared jammer and a radio frequency jammer on the Apache as the aircraft survivability equipment suite. Again, they'll be both run through face conformance and airworthiness. Different flavors of VAs and different flavors of airworthiness kind of speaks to the robustness that we're using these tools in this environment. So I wanted to point out, if those are familiar and not with the DO178, that there's life cycle and side by side, these are identical. If looking at what I referred to as a DO178 dashboard, essentially there's 71 objectives and the back of DO178, they have tables and you need to comply with each of these objectives. It's essentially a life cycle in order to go through airworthiness. They have 22 life cycle design artifacts, 11-1 through 11-22. And for DAL-C, design assurance level C, you have 62 objectives. I want to highlight, and it pulls out a little bit later in another couple slides, the green versus yellow. Yellow is an objective that needs to be performed and demonstrated on a target architecture, leaving the greens, the other ones, to be performed off of a target architecture. And this kind of leans into a reuse potential that will be illustrated on the next couple of figures. So again, on the bottom, we have airworthy face and then airworthy qualifications on two different flavors of airworthiness over at the U.S. Army. Then we get into the benefits of a model-based open system architecture and the proven process here. Side by side, my dashboard enhances. And I'll read the title for this. When we used DO331, which is the model-based supplement of DO178C, we have this idea of theory of sufficient. If you have a sufficiently described model, you can have the auto generation of artifacts that are used for both face and DO178. That's the embedded control code, the models, the test cases and procedures, the results with tracing, and all of the lifecycle design artifacts. The qualify this is that our capability model and awesome, a different tool, is sufficient. It generates more than the face data models, but it allows for that efficiency to generate the embedded code. Nathan just asked for the TSS to be generated. It generates that, the cases and procedures, et cetera. So when you're looking at the dashboard below, you're getting a lot of these objective compliances generated through the use of the tool. Additionally, since we have the green versus yellow, we have now the opportunity for reuse for the reuse guidance AC2148. So the model-based open system architecture used in the SAVI tool allows for the development test and integration of six additional compliance objectives with little additional level of effort. So essentially, you're getting more from the same. So what we're getting is we're getting B-like design and testing for C-like levels of effort. The efforts that we're bringing in, the compliance objectives are the six are listed on the bottom left of the table. We end up bringing high-level requirements being compatible with the target architecture, low-level requirements being compatible with the target architecture, which is extreme amount of work. Low-level requirements are verifiable that software architecture is conformed on the target architecture and then software architecture is verifiable as well as source code. This chart is animated, but it's not animating on this one. So I'll go ahead. The model-based system, open systems approach used in the tool has reuse benefits as well. When we look at the ratio of the green versus yellow, the green as they are, the design artifacts as they are can be reused on different platforms, whereas the yellow identified and separated as it needs to be compatible with the target architecture. This reusable software component face needs to be ported to the target time operating system and the processors, and then we auto-generate and run the testing artifacts to be executed on these targets in order to support the demonstration of the yellow compliance objectives there. Therefore, we're able to achieve the goal of the face approach, rapid acquisition of reusable aviation capabilities of cyber physical systems on complex systems of systems aircraft, regraining ownership of aircraft interfaces and promote aviation plug and play and the procurement of reusable portable capabilities and we get to field them a much faster. So essentially you'll build on the left the original aircraft for error worthiness. Put all your artifacts in a repository and then you can port these artifacts to the different architectures as shown on the bottom there. Reuse 90% of the compliance objectives illustrated in the chart above and then run the 10 remaining percent of the specific platform resources in getting conformance on different aircraft platforms there. So essentially it results in a fleet of different type of vehicles having compatible capabilities also distributed in a much expedient way. So if we got some time and questions, this has been briefed in several different formats at the Pentagon. This is a huge chart to discuss back to. Summary with next steps, our tool is commercially available. My division here we actively participate in the face consortium since its inception in 2010. We lead in several working groups. We also provide development engineering services. We are a sanctioned VA, the savvy VA. Lessons learned from using the ecosystem. When a cross-organizational team, both of these are being developed with different companies, provides insight to how complex systems of systems, example is the future vertical lift family of systems will be developed in our near future. So we're on schedule to develop and field in 2021 two different sets of multiple face development efforts that align both face conformance and airworthiness efforts corresponding to the armies and following guidance of the 2148 reuse guidance. The next steps will be indirect and direct development for the future vertical lift family of systems that awaits the community. Essentially that aircraft includes flora, which is the future attack for Sonica's reconnaissance, elacraft and flora, the future long range assault aircraft. And we're currently supporting JMR efforts, the air vehicle mission system architecture IDD and the FAP, which is the architectural design for the FVL. So with that, I go to a question slide and we should have some time for questions. If you need to find additional information, you've got links on the bottom and on the cover page or contact information as well. So thank you very much and you guys have a great day. Oh, Stephen. Yes. We just had a question come through, if you don't mind. OK. Sure. I can read it to you. I'm getting bombed. Savvy does, I'm getting bombed and I can't read the question. I can read it to you. Yes, thank you. Does each of the USCs have its own DSDM or are they aligned to one? If one, which one? Great question. It'll be a generic DSDM for the comms domain and we're going to make one for the aircraft survivability domain. That's an excellent question. So essentially it leads into the reuse plug and play. So right now the left one where we're spinning two radios, we could then add the additional capabilities for another radio and that'll be a comms domain DSDM for aircraft survivability. We have seven devices and we could spin that, take in or take out other devices to make that aircraft survivability domain. Excellent question. One domain for each domain. One model for each domain. Is there anything else? Nope, that is a question. So with any view through after we left this presentation, we'll get those questions to Steven and get you an answer. But those are all the questions as of right now. So thank you very much, Steven.