 Good afternoon, everybody. We're trying to outnumber you today. Welcome. I'm Maaren Leid. I'm a senior advisor in the international security program here at CSIS. And this is the fourth of what has been a series of events, continuing series of events on the joint multi-role tech demonstration and future vertical lift efforts to get at the future of Rotorcraft. And so we started out with a broad conversation about why future vertical lift. And then in July, we had a session at which Dan Bailey, who's the program director for both efforts, participated. And that was focused on the air vehicle platform side of the future vertical lift effort. And today, we're having the second half of that conversation about the mission system architecture, which is a lot easier to say the digital backbone of future vertical lift. A couple of admin notes before we get started, if people could turn the ringers off on their phones, that would be much appreciated. When we get to Q&A, people will come around with microphones if you could briefly identify yourself before asking your questions. That'd be great. We're going to march down the line here in hopefully relatively succinct fashion. And then we'll try to, and then we'll have time to get into a broader conversation. People, as always, can email me questions if you're watching on the web, mleed, m-l-e-e-d, at csis.org. And otherwise, again, we'll have questions here. And let me also just say thanks to our sponsors. Bell and Textron have allowed us to do this effort around future aircraft. So we're very grateful for their support. So again, we're going to talk about the mission system architecture, the joint common architecture, which Dan Bailey characterized in July as the wrapper around future airborne capability environment or the face the open architecture standard. And so I'm sure we'll talk a lot about face today and about JCA, how JCA is advancing the implementation of that standard, and how the FEL effort is in the process of implementing a series of planned demonstrations to employ it. So we're going to start with our OSD rep. This is Dr. Michael May. He's the acting director of information systems and cybersecurity in the Assistant Secretary of Defense for Research and Engineering. We have a whole range of technical expertise. This is the physicist in the bunch. And prior to his time at OSD, he was an analyst at the Institute for Defense Analysis. So he is going to start by talking about the requirement for this and the problems that the mission systems and the joint common architecture in general are trying to solve for the department. Over to you. Thank you. When we look at complex systems, we realize that our current systems have become so connected and built by many different teams that are in a distributed fashion that it becomes hard to track all of the interfaces. It becomes hard to track all of the different semantics, meaning the meanings. And what did someone intend when they built one module and then they connected it to another, yet alone to the physical interfaces or, say, the data interfaces? So take a step back and think in, and right now I'm thinking from a software perspective, and it also applies to the avionics and things as well, the electronics. But in these kind of missions, what are you trying to do? You're trying to, you have a set of requirements, a very high level set of requirements. And what you want at the end of the day is running code on a particular machine that meets those requirements. It sounds very simple to do. However, in our current system of developing things, there are a tremendous number of steps between the high level requirements and the actual running code. And people have different names for them, specifications, high level specifications, derived requirements. But really what it is, is from the high level requirements, you get more and more detailed refinements and abstract, that you lose your abstractions as you go down the list. And each one of those steps today is done in a very manual fashion. Requirements are often kept in a spreadsheet, for example, where your specifications are. It tends to be a very error prone process. And as you go from one down to the level below, as a different level of abstraction, there are assumptions that are made. And sometimes those mismatches are those, if you make a wrong assumption about what the person at the other level intended, then you have a problem. And that can lead to mistakes. And so I'm sure that a lot of folks have heard of model-driven development. And why is model-driven development important to, or is a possibility to help attack this problem? Well, in a model-driven development environment, what you do is you actually record what the interfaces are, the semantics. And that information is available then to anyone who wants to use it. So you have a shared understanding. More importantly, if you once you get down to the very end of the chain, we are actually going to produce code that runs on a machine. You have, we have methods today where we can formally verify the properties of that code. And so using formal methods would be great because we would give us something that's provably correct, right? Now, there's a couple of cautions there. I mean, the first off is a lot of some of our methods don't scale well to entire systems. So one could imagine a condition where you formally prove various parts and then keep track of the contracts. But the important thing I think about formal methods is that it changes the conversation. Currently, if you're either talking about interfaces, you say, oh, we had these many mismatches and these many fixes. Or if we're talking about software, you say, wow, today my team fixed seven bugs. Well, how many bugs were there? What's the ground truth, right? So if you can actually build something that's provably correct and traceable up to the high-level requirements via these models, then what you've done is you've changed the conversation for being about bug finding to being about what did I mean about being correct, okay? I said it was correct by construction, but how did I determine what was correct? And at least then the conversation is about the requirement, okay? These guys are gonna talk more about it, but one of the things we do is we've got a lot of things I noticed behind me, there's the AADL logo for the SAE standard is on the board there, on the screen. But things like that, those kind of tools, whether it's requirements planning tools, the architecture modeling tools, or even the formal methods based auto code generation tools that are being developed in some places, DARPA has a hand in those, those are good things. And lastly, I would say that it might, if we're effective or successful in doing, developing these new paradigms, then we'll require probably new earned value measures because again, you're going to be correct by construction when you generate your code, right? And also I'd like to say that we have to look at our workforce because currently the folks out there in the world who program in the formal methods world, they use different languages. They don't use C++ and Java, right, to do formal methods. And the academic community that tends to use those are not the folks that we're often hiring with our bachelor's degrees, they get to come out and work on our systems. The formal methods guys tend to be PhDs. And it's a little bit, I won't get into the history of that right now, but there's, it's an interesting story about how that schism happened. So anyway, I think that my last point there on workforce development and getting sure we have the right talent for a new paradigm is something that should be considered. Thank you. Okay. Thanks very much. So one of the people who's responsible for trying to get this, get all these levels to properly talk to each other is Robert Sweeney, whose day job is as the lead avionics architect at Nav-Area Air Combat Electronics Program Office, PMA 209. But in the context of this discussion, he's also the chairman of the future of the face technical working group. He has a background in software engineering. He's done that both for Wakwa Collins and for General Dynamics Information Technology. He is a computer scientist by background. And again, he's deeply involved in executing the complicated architecture that you just described. So Robert. Thank you. I guess I'd like to pile on a little bit more to the problem statement and maybe bring it up just a little bit higher than what Dr. May discussed. So what is it that we're actually trying to do? What are we trying to accomplish? We're trying to acquire systems that allow us to innovate over time and to drive competition in the industrial base. So how do we do that? How do we make sure that we're able to sustain our aircraft, integrate new capabilities and bring more capability to the warfighter itself? So common architectures for future road of craft. We have to first invest in the infrastructure for the mission systems and the common architectures. And that's kind of where we're going with face. Also the emblem for host, which is a hardware infrastructure. And then getting back to Dr. May's point of actually functionally decomposing our software and breaking it down into modules based off the requirements. So looking at the highest level, initial capabilities documents for our platforms, looking at the mission threads and the kill chains, understanding what the capabilities are on those aircraft and then taking a model-based development approach and looking at each of those requirements and breaking them down into functions that can actually be reused to make up the capabilities across platforms or families of systems. So the three pillars of the common architecture that we're currently looking at is the hardware infrastructure. How do we modularize the inside of mission computing? The software infrastructure, which is the future airborne capability environment. So that establishes the interfaces and then the semantic data model that Dr. May discussed. At least the building blocks for it so you can implement multiple data models off of that infrastructure, but they are interoperable because they have a common semantic definition underneath. And then the functionally decomposed components. So that way we're actually defining what the components do, the functions and the capabilities, what the interface is to those components, that goes in as in goes out as, and then what the behavior of those interfaces are. And then based on that, we can then have companies or vendors compete on those components and derive different algorithms with different performance characteristics, but yet still meet those interfaces so that way we can reuse those components across multiple platforms or replace them, compete them, innovate on them. Next we've got Dan Bailey, who's the program director for Joint Multi-Role, for the Joint Multi-Role program, as well as a future vertical lift effort at Army Aviation and Missile Research, Development and Engineering Center. Dan is a West Point grad, a career aviator and then became a test pilot and an acquisition professional. He's spent his entire career immersed in various rudercraft platforms and is now leading the FEL effort writ large. So I think you're gonna give us an update on where we are in the evolution of Joint Common Architecture and before we get to the people who are actually doing the work. So first I'd like to say for those of us who come from the southern part of the US this morning, we thank you for warming it up for us and I always thank you for Dr. Lee for hosting us. So you understand the problem, I think we talked about the problem. If you didn't understand the problem before, you certainly heard some aspects of the problem here. So what's different, what's new and what are we doing under the Joint Multi-Role, which is a science and technology effort, obviously, to feed future vertical lift. Well, the problem is not new. We've learned over time, technical aspects of how to deal with the problem, but there's more to dealing with the problem just the technical aspects of it, right? The tools and the standards are one thing, but as Lieutenant General Williamson, the mill depth to the Army Executive, our acquisition executive said a couple of weeks ago at the Open Architecture Symposium here in DC that you can have standards while implementing those standards through the acquisition process is another story. So what's different, if you will, is we've learned over time for several decades we've been after this, right? We continue to go after it and we struggle because it takes multiple programs over long periods of time to learn the different business practices and the different elements of the process to implement those standards and maintain that backbone so that we can ultimately get the efficiencies that Rob talked about. So how do we move forward from here? Well, just like on the air vehicle platform side of the Joint Multi-Role Tech Demonstrator, we're trying to do the same thing on the mission system architecture side. We're not developing the mission system architecture per se for future vertical lift. It's way too early to do that, but we are looking at the processes, the tools, the standards, and we're going to do demonstrations of that over time. So if you bring up the next chart for me, you'll see right here this is the definition of the mission system architecture demonstration under the Joint Multi-Role Tech Demonstrator. We're looking to provide guidance and infrastructure necessary for FEL, implement that affordable, timely, and effective architecture across the family of future vertical lift systems that's enduring, efficient, and effective for the long term. Well, there's more to it than just the standards and the tools. Those are absolutely the foundations, but now we have to determine across the family of aircraft and across the family of program managers, various entities that provide commodities to us, how do we implement that globally from an acquisition process perspective? So that's what we're focused on. The business practices, as well as the technology, has advanced to the point where we think we now can start to implement this effectively, and that's what we're looking to demonstrate. So we're not developing the mission equipment package, we're not developing the architecture per se, we're trying to implement demonstrations over time to learn, so learn as we go, and that's what we're doing incrementally for the next five years. At the same conference, Vice Admiral Dunaway, who's the NAV air commander said this, he said, system acquires need to think about everything they're buying as a part of a system of systems, as opposed to a stovepipe component that moves through the acquisition process with its own agenda. So how do you broadly change our processes, our practices, our culture in some ways so that everyone from the acquisition community is implementing that globally, if you will, so that we have the ability to integrate those standards and those tools over the long haul. That's really what we're all about. So if you go to the next chart there, this is the MSAD schedule, aligned with the air vehicle piece, we're looking at the configurations for the air vehicle, the flying backbone, this is the architectural backbone. There's many technologies that are advancing, and as we have done in the past, right, we've learned that now we're gonna implement a fiber channel data bus as an example. We have to learn through that program what that means to us from an architecture perspective, what it means to us from a modeling and tools perspective. We don't wanna learn in the first iteration of FEL and then every other subsequent FEL, change it. We wanna learn before we actually implement the first one. So that's what this science and technology program actually gives us the ability to do. In a shorter period of time, with obviously fewer resources required, we can do incremental demonstrations of this and learn as we go so that the first future work lift program of record has what we need in terms of culture, process, standards, tools to implement it at the beginning. So if you look at the schedule here, to do that, we've got to first know what do we think mission equipment in the future is gonna look like? What do we think the technologies are gonna be required in the future? So we did what was called a mission systems effectiveness trades and analysis. We went out to industry, had all the industry partners who are subject matter experts in their fields do the studies. Where are we today? What are the problems of today and where we think the technology's going in the future? We learned some critical things. We learned that fiber is probably the way of the future. We learned that wireless databases are probably the way of the future. We learned that multi-core processing, the distributed processing, the way of the future. Multiple layer security requirements are a part of the future. So how does all of that affect the architecture and the standards and the tools? So now that we understand that, we can begin to think about that now before we actually finalize the standard and implement the standard and ultimately build in an acquisition process that stove pipes us. That's what we don't wanna do. So we did that. We turned that into what we thought was the first iteration of the demonstration. And we, if you look in the bottom left or in the process of execution of what's called the Joint Common Architecture Demonstration, that bottom left, as well as the Architectural Century Virtual Integration Process, which is the model-based tool process that Dr. May talked about. That's an overshadowing part of this. So the demonstration first is a concept. It's a proof of concept. Are we on the right path? Learn as we go, as I said. And then from that, we will turn that into several iterations, as you see there, called Architectural Implementation Process Demonstration. Key, right? The key word in all of that is implementation. Go back to what I said at the very beginning. Lieutenant General Williamson said, you can have standards, but implementing those standards is the difficult part that we run into over time. So how are we gonna implement it, right? Program manager guidance, memos, standards, policies for the program managers. Those will have to be enforced, implemented across our fleet, if you will, if we're gonna get after the synergies we're looking for. And ultimately, we're looking to do on a capstone demonstration at the end in a large instantiation of architectures that won't necessarily be the architectures, but they certainly could be the first of many to come. So I say all that to actually introduce, and I know Dr. Leeds is gonna introduce, to my left are two contractors for the Joint Common Architecture Demonstration, a team of Boeing and Sikorsky and Honeywell, and they're gonna talk to you about what they're doing specifically, but I'll finish with one more quote from Lieutenant General Williamson, and it says, there's still a requirement for leadership and management. You can put out as many standards as you want, but you still have to make sure you understand how those are implemented within your program. So what is Joint Multi-Role Tech Demonstrator Mission System Architecture Demo all about? It's about the implementation of all the work that's going on outside of this so that we understand the process, the implementation tools, the standard, the culture that's required to get after that synergy in the future. Okay, thanks very much. So Dr. Tom DuWa is the Chief Systems Architect at Sikorsky Boeing JMR Helicopter Future Vertical Lift Program. He's also the Co-Principal Investigator of the Sikorsky Boeing Joint Common Architecture Demonstration Program, which Dan was just talking about. He's got 27 years at Boeing and developing advanced mission systems for various aircraft programs. So Tom, if you could talk a little bit about what the Sikorsky Boeing team is doing and what it takes to actually execute what these all our previous panelists have described. Yes, for sure. Yeah, thanks a lot for the opportunity to be here. Thank you. And I also like to recognize my Co-Principal Investigator, Bill Kinahan, works for Sikorsky and unfortunately couldn't make it here today. But on to what we're doing on Joint Common Architecture Demonstration. We have been very much involved, both of our companies, jointly and independently with the FACE Consortium helping write the Joint Common Architecture and even doing some R&D studies in model-based design, at least from a research perspective and maybe some applications in that area. So when we saw JCA demo appear as an opportunity, we thought that was a great chance to really try out these new technologies in earnest following from what Dan said earlier. And so basically for the project, we were given a data model, as mentioned before, a very few number of performance requirements which were actually the behavioral aspects as was discussed earlier as well and told to be conformant to the FACE standard. And then go build an app, if you will, a Fusion app in this case and a piece of software that can be used to test it. And the results would go through a blind test. So we have no idea what this was going to run on and it would run these things at the Army Lab in Huntsville and also subject it to the FACE conformance verification process. Well, throughout this, it was most important, and this is the learning part of it, to use the government provided tools referred to as the JCA ecosystem and collect lessons learned. And there were a few things we learned on the way and they were very quickly changed, much credit to Rob Sweeney for making a couple of those things happen because this is definitely a learning process. And by the way, all of this work had to be done in four months. So you had to write a Fusion app, conform to a new standard and you basically had four months to do the job and hand it off to a test group and it'd be a blind test. You were not given any information but what this was going to run on, what operating system was going to use, what hardware it was going to use. So to me, it was a great experiment. When I saw the description of what was necessary, I thought this is a really cool experiment. This is going to be a big challenge. Let's see what we can do to make this work. So we also had some ideas of our own too. One of them is, and it's mentioned before here, is reuse. So what we did for our part of our demonstration, and there's the picture right there, if you look in the upper left-hand corner, we grabbed a piece of software that already did Fusion. It's been fielded on the AWACS aircraft, P-8 aircraft and a few other aircraft. We basically ripped it out, created a wrapper using some terms. We heard earlier around it to conform to the phase standard. So basically it aligns the IO. So we'd expected IO in one form and using the data model that they gave us used IO in a different form. So the old way was ICDs. The new way is data models and maybe if we can get to the point of behavioral models as well. So truly a different way of building systems. So at the same time, we also had to build a test software to prove that this thing worked. It met its requirements. And so we actually, and a lot of this is where some of Bill Kinahan's innovation came in, we decided to use the same standard, the same phase standard to build the tool that would test the fusion software. So it was using the same data model. The only thing that made it different is we used another tool to auto-generate a lot of the test cases that would automatically run on it. So in addition, so that was basically what the basic work was. We handed, and actually we finished it in three months instead of four, which was pretty cool. The last month was all about tweaking it a little bit and creating the artifacts that were necessary to support the verification process. Everything was handed over and the Army's working with it right now. So in addition to the basic program, if you look in the upper right and lower left, we actually volunteered a couple extra tasks that we thought were perfectly in line with what the government's objectives were. The first one was to, which is a task to host the same app on a bunch of different operating environments. So we had the blind test. So we went to do our own blind test. So we came up with three other systems that we would try to run this fusion application on. That's the one that's shown in the lower left. One of them is an architecture that is the same hardware architecture that's on the Apache aircraft. Another one is on the Sikorsky Raider aircraft. And a third one was on a future-oriented architecture that Dev Boeing calls Phantom Fusion. So we wanted to cover the legacy, the emergent, and the future, all with the same basic application. And to what extent does the software really need to change to get it to run from one to the other? And to the credit of the standard that Rob's been championing here, very few changes need to be made. They're done at what's called the transport layer, very low level. So you can think of this as trying to write an app without changing hardly any of the software and have it automatically run on your iPhone, your Windows phone, and your Droid with the minimalist of changes. So I thought that was a really good task. We basically just began that task but we have transport services for them and we really kind of started it already. We couldn't really start it fully until we had the code to work with. So we couldn't start before month three. The upper right-hand corner is the second task. This is a new app and we wanted to learn how to build data models ourselves too as an integrator. And we also wanted to explore to what extent the standard can be pushed into touching the flight controls. So we created a new application called Formation Flight. We chose it because a lot of our smart people are thinking that there has to be a much tighter integration between the flight controls and traditional mission systems to accomplish some of the really visionary requirements that we expect to see in JMRFEL, particularly in the areas of autonomy, optionally piloted vehicle, cognitive decision aiding. These are really hard requirements to meet to achieve their full vision. And so we think by having a tighter integration between those disciplines that we'll be able to do that. So the question now was for us on this additional task was could you build an app that conforms to those standards and all of the overhead that comes with being open, conforming to that, will it create time delays and latencies that would make it impossible to meet some of those requirements? And so we actually were able to start that one from the very beginning because it was a brand new application using the same standard. And so far our results are showing us that the standard does not get in the way of this at all. Now we're fairly certain we can't push it down to the innermost flight control loops, but we can do outer loop type functionality, some interesting functions like integrated fire and flight control and other types of apps that interact with the vehicle and become a complex cyber system that's flying and not have to worry too much about the architectural details and the separation. So some of the future work in the area of control laws and other types of behavioral modeling pushed up a level like Dr. May was talking about is all related to this kind of a thing. And we think the architecture concepts are going to evolve over time to make that happen. So in summary, I can say that I started this, I was like most engineers were a bit skeptical. We've had histories of other standards like Jaiwig and things like that. And so when you go into these things you wonder where the problems might be and things like that. And I can tell you from my experience as a PI on this one project, I'm a believer now. I think we can make these things happen. The doubts and uncertainty of its possibility are gone. It's starting to look like more like a maturation rather than a exploration, if you will. So the next big challenge, as Dan mentioned, is the integration aspect of it. And that's also what makes app development for aviation systems a lot different from app development for mobile computing is all the interactions that occur between the applications to make an aircraft fly. And if we push into touching the flight controls a bit more that even complicates it in ways we haven't thought of. So the integration part is gonna be a real challenge in that area. But also believe that that's what's necessary to achieve this family of systems type vision and have it work on a lot of different aircraft be independent of the underlying operating environment and hardware and things of that sort. One thing also that I, and the DOD did kick off an impact study on airworthiness that's very much related to this because to make these kinds of new concepts work you have to be able to get it to be safe to fly in the end. And to do that there's probably gonna be some needed changes to the airworthiness process. And I know the DOD has recognized it. I think these are the technologies that are driving it to be able to meet these really ambitious future requirements. And it's gonna take something like that to make FEL as a family, a system, a real program that the warfighter has to have. So there's also the airworthiness aspect of it as well that needs to be addressed. So ultimately it's a good experience. We got a few more months left to finish it up. We're going through the verification right now but it's more one of, we'll get the job done. So, and it's been a pleasure to work on it. Thanks. Thank you. So now, just Ritter's here as the representative of Honeywell, the other team working on the architecture demonstration. He's the senior technology manager at Honeywell's Advanced Technology Organization. Again, the program manager for Honeywell's JMR Joint Common Architecture Demo. He also has had a variety of positions over 35 years both in management and in actual development and integration of technology for avionics and ground vehicle electronics for missiles, fixed and rotary wing, aircraft, artillery, and a variety of other systems. So just over to you. So again, thanks for CeCis hosting the discussion today and for AATD to allow Honeywell to perform on the demo program. I think the demo program, it was a great opportunity as was said earlier to learn by doing and that is, hopefully we'll continue these efforts because really we've learned a lot, I think both on the industry side and on the government side through this activity. We executed really the same technical program that Boeing Sikorsky executed, so I'm not gonna go into those details per se. I think what's interesting here is what we demonstrated and validated was more than conformance to the standard, it really was this concept of the ecosystem and how does everything work through the system. So we were asked to publish in the FACE library. We are distributing through the verification authority and verifying that that process and that organization is being stood up and working as well. And so that's been very beneficial. I think what we really achieved here in this first exercise is, regarding a glimpse, can we do procurement against a model-based methodology? And I think that at least initial report out is, yeah, we can, it's gonna be achievable. There's stumbling blocks. I mean, we have to be prescriptive to the data model and make sure we all understand specifically what the data model is and accuracy to that. Just like any text-based requirement, it's gotta be very accurate and very, the perspective has to be correct, but I think that we've seen, yeah, this is going to work. Again, I think from a positive note, we all learn very rapidly, both on the government side, both on the industry side, the procurement model, data model approach is going to work. We were pleasantly surprised by some of the tool interaction. We had actually budgeted effort to develop some specificity around transport services, and actually the tools provided that for us. That was a very pleasant surprise, made our effort quite a bit easier. There are things that both sides are gonna have to learn. I think there was around the specifics, I think there was learning to be done on both the government and industry side around the 653 model, around specific actions around the actual data model, but again, this has been a good experience, a good learning experience on both sides, and as far as proving, will a data model approach work, I think we've done that. Thanks. We wanted to wrap up the discussion today with the customer perspective, so to do that, we have Commander Will Hargers, he's his day job is as the Air Vehicle Systems and Production Team Lead for the MH-60RNS models, and his other hat is as the FVL Common Systems Team Lead, also an Aviator Test Pilot, multiple deployments in support of operations both in Iraq and Afghanistan, graduate of the Naval Academy with a mechanical engineering background, and masters in technology management from Johns Hopkins, so Commander Hargers, how does this sound to you? I'm buying it, right? So I'm a huge proponent of everything that this composite team and everybody else associated with the JCA, the host, the face efforts, all the consortium members, everything that I see coming out of this just shows goodness down the road, not only for future vertical lift, as the context for the discussion, but for our in-service platforms as well. I'd like to offer my thanks for the opportunity to speak, not only to CISIS and you, Dr. Leed, but also to the audience members who took some time today to come join the discussion. I think that the breadth of folks that we have here, both in and out of uniform, is telling in that there's interest in the problem and also in the solution, and I think that that interest only needs to grow. We gotta solve, we've gotta solve not only this problem, but the future vertical lift problem in general. How do we recapitalize the loss of thousands of aircraft over the next couple of decades as their service life comes to an end? It's a huge challenge. I think we're up to it, but it's gonna take some significant alignment between government industry partners, the S&T efforts, a seamless transition to the actual implementation recapitalized capabilities. As I mentioned, I think future vertical lift, the S&T activities, MSAT efforts, the JMRTD air vehicle efforts, provide the perfect context for this discussion, as do a lot of our other future acquisition efforts. You look at, you know, we got FAXX coming down the road. That's the Navy perspective. We've got ships, submarines. Everybody can benefit from advancement in our mission systems and in development of our interfaces in enabling, as Rob mentioned, enabling competition, enabling rapid integration. It shouldn't take me two years to defeat the threat. If I've got, if somebody else has developed the solution, it shouldn't take me two years to contract for, design for, integrate and field that solution. I would gotta be able to do it faster and more furiously. This is something that we can do now, as evidenced by the fact that the JCA team is stepping off and doing a great job in their functional decomposition. That's the first step. We gotta define those boundary layers. I step into a cockpit and my collective goes up and down and my cyclic goes left and right. Now the PUMAS pedals are going the wrong direction. But it's standard. My developers across industry, my government partners, they should be operating within the same common context. I think that functional decomposition is gonna provide that for us. And it's vital that we get it right, that everybody buys in, everybody's aligned and that we move forward and implement those that we don't diverge. I mentioned that this applies to in-service platforms. I've got production aircraft and I'm gonna field my last year from next month. And that aircraft's backbone, it's computing power is gonna be obsolete and not too long. I've gotta be able to leverage what I've got. It's gotta be cost effective and I've gotta keep that aircraft relevant. I think efforts like the host effort, the hardware side, the JCA, functional decomposition, the path to the mission systems demo, the work that the face guys are doing and through their consortium, the industry partners. I think it's vital to the in-service platforms as well. I'm gonna give you an example. About six years ago, I was the Avionics Systems Project Officer for the H53 and we were trying to field a material solution that met CENTCOM Blue Force Tracker requirements. Had a fantastic need board. Did everything that I needed it to do. My guys could see incoming data. We could provide position location for our aircraft and met all the requirements. However, no standard 704 application wasn't standard across the services. I had a need board that wasn't qualified to navier standards. So I went to go field that I could through my set of process. It didn't work. Waivers weren't generally approved. So it complicated the acquisitions process. The Navy, Marine Corps, Army, Air Force can agree on a standard application of that handbook, of that standard. I can field an open system that provides capability to the warfighter. I can get out there faster. Make those guys a lot more effective as they're facing the enemy. I think the alignment part is critical. I think we're doing a very good job. An example is that the software engineering directorate is the first verification authority for the face standard. Did I get that right, Rob? Yeah, I chose perfect partnership, particularly as it applies to today's discussion. I think it's critical that we continue down that path. We don't stay aligned. We're gonna fail from the get go. We can have common, even identical requirements for their vehicle for the mission systems. If we don't apply it across the services the same way, I think we'll run into the cost growth that has plagued previous joint common programs. We've gotta avoid that kind of problem. I think I'll close with emphasis that the time is now. We've gotta resource these kinds of efforts that services have to buy in. We're not too early. And the architecture is a key part that we can do now to start solving this problem so we can field some relevant, some technically effective aircraft come 2035 when we've gotta get them out there. Again, thanks for the opportunity. I look forward to the discussion today. Okay, thanks very much. Let me kick off the questioning just briefly. Dr. Mayer, I wanted to get back to a point that you raised about workforce and some of the implications of workforce requirements of these developments. I don't want to specifically ask Sikorsky and Honeywell whether what you all see as, and then maybe get the government perspective as well, do you feel like on the government side, the workforce is properly aligned to carry this effort forward, not in its specific instantiation in this program because obviously it is, but in general more broadly. And then on industry side, do you all see a need for a different workforce and is that a concern? Why don't we start with the government side? If one of you wants to jump on that. I think it was more directed to- And then, well, I wanna ask what the government workforce implications are and also then what the industry implications are. So currently today, we're working towards bringing our workforce up to speed on model driven development, development of the software standards, decomposing our software, looking at formal methods. These are all things that we're looking at doing. We're bringing new engineers in through development programs, putting them in the right places on the right program so that way they come up to speed and then deploying them out to other program offices in order to bring the rest of the workforce up to speed. So I think we are positioning ourselves. I wouldn't say we're there today, but we are getting there. I'll add to it. So we're not on the government side, always as lucky to have someone who's been on the industry side that's done this for real. We have probably few of those and we have a lot of acquisition professions. So another piece that came out of two weeks ago, the architecture symposium, there was a statement that says, what we're looking for is what we do in our process so that we ask the right questions early in the process so that we're not surprised at the end, right? So back to that, that's a culture thing, that's an education thing and we're not there today for sure. But the key part of this is we realize it. And so under the effort through the Vertical Lift Consortium, we are actually in partnership, Army, Navy together, in partnership through the Joint Common Architecture and the JMR efforts, we're tasking the Vertical Lift Consortium to provide us SMEs. I think it's two per task, right, function, so we're doing functional decomposition on that. We're asking for two SMEs, can't be the same companies for periods of time to help basically direct us in execution of that. And then on our government side, we're actually coding it and working that in the standard, but in the architecture instantiation, but it's really the industry that's teaching us and guiding us, if you will. So we're heading down that path that Rob's talking about. We're not there today, but we'll certainly be there on our timeline record. Yes, actually, we have some interesting observations in this category from our experience working on the JCA demo project as an example. Talked about the workforce and the skill base. One thing when you're dealing with data models, for those who have more experience in programming, there's a tendency of writing data models as computer structures. You don't wanna do that. That's not the right way. You gotta think of data models as kind of functional, more object-based view of what's going on. Representing more, here are the elements of the system and here's how they interact. Not here's a structure that has this particular scalar data type or something along those lines. What we found is one of the people working on our project who was able to pick up data modeling the quickest was one of our youngest engineers, as a matter of fact. So he wasn't biased by a history of doing a lot of programming in different ways. So I think the schools, and actually, because of the way the technologies are advancing and the kind of tools that they're using there and doing more library, they're building up code more from libraries and existing libraries and existing code, it becomes more of a building block approach to programming versus first principles, structural decomposition way of looking at a problem. So I think that one is a case of, I think the universities are starting to do the right thing and we need to keep an eye out for them. And maybe those who have a little bit more experience need to move into more of the other aspects of the behavioral modeling and trying to do the advanced programming that might be associated with trying to make those kinds of things happen. So I think to make this model work, there has to be that workforce like transition. I'm not seeing any significant gaps because I think, in a sense, people are moving towards that already, which is another reason why I like this basic approach. I think Honeywell perspective is similar. My PI worked on the data model for FACE and so really understood it quite well, but some of our developers struggled actually with the concept of the data model and dealing with the data model and the learning curve was a little steeper there. So that is feedback for us to go back and make sure we're looking at our talent and growing people in this way. I do agree that coming out of the universities, it's more appropriate. People have better experience in that realm or aren't as biased from having years of developing in a different methodology. So I don't think it's not out of bounds for us, but it is something to pay attention to at this point. Okay, thank you. Can I add? Yeah, absolutely. So I think one other aspect just to touch on the cultural changes and the acquisition professionals we do have our current culture in the DOD is quite heavily focused on engineering as acquisition. So changing the mindset and then changing the mindset of folks that have been there that have lived through some of the open architecture experiences, having them be able to accept that there's a change coming is a little bit more difficult. So really bringing in new engineers, new talent I think is helping that out. And then as it shows some success stories, I'm very glad to hear the success story that you guys are experiencing. Those success stories help with the cultural change within the DOD. I'm gonna pal on one more. So I'm gonna actually maybe turn this over to Dr. Magnus. We're just doing one question today. He's a subject of expert on this, but Savvy as you see up there is actually a commercially based enterprise. And so the other aspect to this is DOD is reaching out. If you will, DOD has its own version now of what commercial industry had started years ago. And so certainly the industry partners that are out here have commercial sides and DOD sides and sometimes they cross and sometimes they don't. But if you will, AVCIP or ACVIP is the DOD version, if you will, of what the Savvy group has been working on for years. So we're now getting the cross-pollinization for the commercial side and the DOD a little bit more than we have in the past. Real quick, I'll just add on that. I think, I'm hearing that when it comes to data models, it's kind of a low hanging fruit as a good place to train people. But earlier on we were having a discussion and we were talking about behavioral models. And we get to verifying whether the behavior is correct. We start getting into, again, kind of the formal methods area. And that's really, when I made the comment, I'm kind of looking farther down the line even in the data models. And thinking about, there's two communities and the formal methods community tends to be, again, PhD folks, right? And they program in different languages than the folks who program in C++ and Java to do formal methods. And so low hanging fruit, I think, we're probably in a good spot. I think farther on down the line when we talk about provably correct behavior, that's where we will have to try to find more cross disciplinary folks. Okay, as proof of concept that emailing me questions does actually work, I'm gonna offer one that I got my email. It's from an Australian Lieutenant Colonel, Charlie Barton, who's the aviation liaison officer at the Aviation Center of Excellence. I'm not gonna try the accent, you're in luck. There's really two questions, quick ones. Will the proposed common architecture include data link and data sharing access, or data sharing across all four services? And then the second question is, will DOD develop an agreed common data architecture so FVL can transition from the, from the littoral to the land via high altitude without a loss of information or battle space compatibility? So those are very probably specific requirement kind of questions. And I would say that we haven't defined this full set of requirements at this point. But I think fundamentally or theoretically, maybe that kind of connectivity is certainly what we're after, both from a sea to a land perspective, but more importantly across the services, whether it's sharing data or whether it's a common capability of data collection that we can ultimately leverage in whatever way the service needs to leverage it. There's probably, we maintain aircraft very similarly, but yet we don't necessarily capture the data very similarly today. So there's opportunities there. Those requirements haven't been defined specifically, but anything we can dream up today, we're looking at building architecture to accommodate that. And I can add, too, yes. I did some background in doing this networking kind of thing, too, with some previous experience. So from our perspective, where we're at now, though, once those requirements are defined, it's an application for us. We write the application. Hopefully we only write it once, and it can be used in all the different aircraft. So once, I guess, this kind of standard gets defined, probably at the DOD level, I mean, it's percolated down to the services. It becomes one application. It becomes one data model that implements whatever that protocol happens to be to implement how you're going to be linking your data or whatever, if it's a video as well, there could be other standards for that. You need services on the way to do those kinds of things. These are things that should only be done once, and this approach that we're looking at now is designed to try and make it happen that way. So that we don't have the answer today, we have an approach that once the requirement gets defined, it'll be really easy to get the answer. There'll be an app for that. Right. Yeah, okay. Let me open up to audience questions. Again, if you could raise your hand. People come around with a mic. If you could state who you are quickly and get your question. So Sydney, from Surprise. First question from Sydney. Sydney Friedberg, Breaking Defense and Humanities major. So put this in layman's terms, and I know you guys have to slow your brains down by like a factor of 100 now. How does this approach to software, this model-based approach, these formal standards, I guess it's almost like measure twice, cut once. How does it prevent the kind of disasters you got with future combat systems, SOSCO software, which I don't think ever worked, where again you had probably to do one system across many different pieces of hardware. How does it prevent the problems you've had with the last joint aircraft? I believe even the commander mentioned, alluded to this, JSF, where they've had a lot of trouble getting the software, for example the Marines, where it needs to be on schedule. In terms of getting the product to the military consumer functioning and on schedule, what does this approach do better than the way JSF, FCS and other projects have done the past? Better than FCS is not a high standard. I guess I'll take a first crack at it and then everybody else can pile on. So I think the approach that we've taken is we haven't tied our standards or the methods to a specific platform or specific requirement or technology. So we really looked at, so the FACE standard, the JCA standard, it's not specific to future vertical lift. So the JCA standard, the functional decomposition, those functions can be used to create different capabilities across different platforms. The FACE standard itself, it's not specific to even aviation, even though aviation's in the name. It's more of a software standard. So we've really tried to pull ourselves out of the implementation itself and look at what's the best methods and how, or best practices that commercial industry has used to establish a product line. So I think previously in our endeavors, such as FCS, we've really tied ourselves to a requirement and a specific implementation. And I think that's probably where we're taking a different approach. And also looking at what the business aspects are, so that way we get a broader scope of industry looking at the problem away from the actual acquisition process. So what are the other ones, they're not making it forward specifically for one requirement to say, or it needs to be widely applicable, and whatever the requirements end up being, because you don't know them yet. That's correct. Yeah, and I think I can definitely add to this one too, since I actually worked on FCS and was part of, well, indirectly, but I will say that Tosco did work. I actually took it to Australia with me and showed how I could use it to connect the Chinook to a scan eagle and do some maritime patrol. But so it did work. The problem was one of broad acceptance. Now, getting at the heart with the differences between SOSCO and what FACE is trying to do, it comes down to transport services. SOSCO was its own design, in a sense, on how you handled things at that middleware level. I hope I'm not going too deep for the audience. But so SOSCO was the middleware, so you would write your application, it went through SOSCO, and then it went to the hardware that was underneath it. What FACE has done differently is you write your software, you use a common transport service, and then whatever the underlying operating system and hardware is will have its own, call it plug-in for that transport service. So you don't have to change yet the things at the application level. When you wrote software for FCS, you always had to use the SOSCO middleware to take advantage of all those features. Here you don't really have to do that. The standards are more open and things go down to the transport service level. So all you need to do is comply the standard right to the transport service level, and then everything below that can handle the operating system, handle the underlying hardware. So that effectively was the key technical difference at the heart of what made SOSCO different from this FACE standard. And having worked both and seen one not maybe be as successful as one would have hoped, and one that seems to be going to be successful, I do have that kind of background, so I did work both. Well, it's allowing there to be lots of middleman versus. Lots of providers, as long as they comply with that transport. That's right. You comply with the interface and everybody can play, right? So in theory, you get the best of the product for that capability. Also wanted to clarify my JSF comments, right? Strictly used as an example of cost growth and not necessarily as technical challenges. Every new program has technical challenges. And this one certainly will as well, right? You don't fully realize the depth and breadth of the challenge until you dig in and start to do it. But I think what Rob and his team and the JCA team and those guys are doing is really just enabling that development, enabling that innovation. They talked about some of the technical applications and I really wish Rob had a chart, his FACE chart that shows closed systems as they migrate to open systems for development as it applies to smartphones, right? You look at Android as being a fully open system and anybody that's got a capability that they want to bring to that flight, well, they can play because they know what that standard is. They know what the interface is and they can do their level best to make it work right. And we can go out and ask for competitors to play in that environment. And as long as we do a good job with those requirements, I think we'll end up with a better product. On a pile on that the standardization part of FCS was probably one of the successes. So something like say the SCIA was actually a decent success there. In a true model based acquisition regime where you even have modeled the behavior, right? Then, and you establish the correctness of those models all the way down to the code, then you can ask yourself, do they actually match the requirements? And then you can either adjust your requirements or you can adjust your system. And FCS tried to do a lot of things in a world where, again, there were mismatched assumptions and expectations between people at various levels in the acquisition system from requirements all the way down to the developer. And hopefully we'll make that much more transparent and make sure that the assumptions are better aligned. Model Croatia, C-Power Magazine. The one question I have is you're developing your software model program separate from the platform developers. Somewhere or another, it all has to come together. Mission systems have to tie in with operating systems and to make the aircraft fly. Is there any problem that what you're doing somewhere when you could actually marry this together with the platform itself, there could be glitches or is this flexible model, would you be building compatible enough so that it can merge right in with the platform? You're absolutely right. Obviously there's connectivity there that has to be made. There was a deliberate decision at the beginning of the JMR program not to build the architecture onto the air platforms. The backbone of what we're building, if you will, is simply demonstrators to demonstrate certain new configurations that give us new performance regimes that we can go after and what does that look like. But as Rob said, we're not defining the architecture to a product solution. The architecture work that's going on and what you're hearing here is in fact flexible enough to be leveraged at some level to the current fleet, to other ground and sea-based systems and certainly the family of future vertical lift at large. So we're not defining it to a product solution. The connectivity there is really amongst the people that are working it. And I say that to say that we're not all separated. So the air vehicle piece is still under my program in total as well as the architecture piece. So the demonstrations of everything that's going on is actually one consolidated team working together. Yeah, I really appreciate the question, too, as one of the key reasons why, you know, Sikorsky Boeing, we're building in the air vehicle and you hit it, you hit the nail on the head. That is a key issue. That's why it's a priority for us to work this part because we know some of those things are going to come through. And as a follow-on to what I spoke about earlier and a tighter integration between the flight controls and the mission systems, that particular aspect, I think even sensitizes us to what you're asking even more so. So we're in it for the long run and we want to really understand what that connection is because there could be some surprises there that we're not aware of right now and they need to be addressed. And we need to see how far we can push this technology beyond the conventional sense of what a mission system actually is to make some of those things happen. I think from a technical perspective, I'll assert that the most important thing in doing that is understanding the timing. So writ large, your question is about what, in many circles, is called cyber-physical systems where you've got control loops that are connected to physical actuators in a very tightly coupled fashion. So model-based development doesn't remove the need for sound engineering judgment. And if for whatever reason, cost, programatics, you decided to separate the two, you have to be able to understand when the two are ready to attempt to put back together and test. And again, the claim is that if you understand the timing, in other words, the latency, the sense of time, the timing and the fine-grain timing that you need in order to then operate a very tightly coupled control system for the aircraft platform, if you understand that and you understand the physics behind it and the electronics behind it at the same time, you stand a good chance of putting those together and having a successful demo, or at least being close enough where you can kind of adjust the mark. Dan, if I could ask you, you just mentioned that face in theory could be applied in any number of different capability areas. Robert, is that, are there plans to demonstrate it in other, for other types of platforms or is it we're gonna evolve it in the FVL context and what's the anticipation of the way going forward? So there's multiple actual acquisitions that are using the face standard. C-130T, avionics, obsolescence upgrade, which is a cockpit for the C-130T in the Navy. AV-8B for its R&P, R&A requirements, which is civil lawyer space mandates. And then I believe H-60 Victor also had a requirement for face. So it's not only new platforms that can benefit from it, but also legacy platforms. As long as we come up with good sound engineering judgments on how we cut it into those platforms. So we do analysis up front of how we're actually going to do that. Do we make wholesale cuts or do we just tie it in little bits at a time? Absolutely. So both services have already signed up that face is the future. So as we look for any kind of modifications and upgrades to our current fleet in the Army aviation arena, the intent is to make them face compliant. Now, the challenge there obviously is you're only doing pieces and parts of that current system. And again, based on the business practice and the acquisition process that you've used to get to that point, it constrains how far you can implement. So again, I go back to the point of it's exactly the same thing with the model-based tooling. So certainly, if we're gonna do new software development on an air platform of the future, we are looking to utilize those tools in that process. But those tools are semi-mature today and they will continue to mature over time. And we will mature them through the first, the fast learn process that we're trying to implement right now under JMR. And at some point, obviously at whatever point a current fleet upgrade is done or a future vertical lift is initiated, the maturation of those and the ability to implement those will be a little different, right? You just won't be able to implement it fully on a current aircraft as you would a new platform that you designed from the ground up for that purpose. This may not apply to where we're at in this thing now, but in software, there's been a problem in the past of proprietary interest. You know, if you develop a software government wants to have it so they can use it for whatever they want in the future, you're developing a model that will be used for a lot of different things. Is there gonna be a problem somewhere down the line between this end of the two ends of the table in the middle as to who owns what you've developed? Can I kick it off from the government side and then I'll turn it over to you. So we're trying to be very careful in what we do in all of our standardization practices and all the standards that we develop that we respect the industrial basis need for intellectual property. We're not asking within these standards or even within the functional decomposition for all of the intellectual property. We're looking at what the interfaces are and what the interfaces, how the interfaces behave. The intellectual property can still live in those components that are defined in the different layers of the software and it gives the government the ability to either license that software, those algorithms, replace them down the road, compete them. It provides a way for us to break down vendor lock but also allow vendors to keep their IP. So we're traditionally, when we try to break down vendor lock, we went after at least a minimum of government purpose rights for everything. I think there's a different acquisition strategy and data rights strategy that we're trying to go after and that's if we need GPR, then we'll ask for that. If we think that we need to just license it so we can compete it later, we'll do that. So we're gonna look at a holistic approach for data rights strategy going forward. Yeah, and we have actually, maybe our opinion is not so far off at least from the Sikorsky Boeing perspective. We're OEMs, we build aircraft principally. On some of those aircraft, we integrate the mission systems and write the software, others we don't. So we're very also familiar with the vendor lock issue and so we're also looking for ideas on dealing with our suppliers as well that there's the same way our customer in this case is looking at it. So I think we're in a shared journey on that point. I think we realize from industry and we'll hear from others maybe, I'm just gonna speak from our perspective that we recognize the move towards open systems. We know there's no sense trying to try and take some IP at the infrastructure or the data IO level, the standard level. We expect our customers are gonna define those standards. We expect they're gonna use commercial standards as much as possible as well. I mean, we've seen pure military standards that don't work. So we know they're heading in the right direction and that's a good thing. There might be cases like Rob said where we would have some IP in the heart of the algorithms, the best algorithm that can do certain things that we spent, you know, billions of dollars testing and proving that it works. In those cases, you probably wanna let us have the IP because it gives the warfighter something they can't get anywhere else. That might be a case where you'd have something there at the heart of it, but you're not taking any IP for the infrastructure and the services that go around it. Other things, and we are looking at other ways to find IP associated with this whole process that makes industry more competitive. Maybe it's in the backend tools. Maybe we share, there's a common language for sharing models. For example, yet, we have one set of tools. Our competitors have a different set of tools and we're competing over cost and whose tools work better. Who's got a better set of test cases? Who can generate test cases better and quicker and faster? There's a lot of different ways where you can find IP and I'm not saying I know the answer right now, but we recognize the trend in the open area and I think we're also sensitive to the same issues of interlock and we wanna help solve that as well. So I think from Honeywell's perspective and again, we're more of a component avionics supplier in general. I mean, sometimes we've crept up into the integration, but also I think that there's nothing in the standard or the model base that keeps us from maintaining our IP positions. There are places where we've developed things out of commercial aviation or whatever that absolutely we're gonna maintain and the standards provide that interface that we can deliver to. We may have to get agreement on what level the interface will go down to so that we protect our, if you will, business interests, but the standard itself should not provide any obstacle to that. That being said, I mean, I think there does still need to be and continues to be growth on the industry government side on understanding that commerciality and offering up industry to provide their commercial solution in a licensed form. And that's really what we're trying to demonstrate under the iterations and what the role, right? So standards not gonna define that, but the acquisition process and the implementation of that to get after the vision of in this case, future vertical lift is what we're trying to learn over the next five years. Can I pull the thread on that a little bit? Because, Robert, I think what I heard you describe is at least at first blush consistent with sort of the more nuanced approach that I think Frank Kendall has talked about being necessary and that there might have been some overreaction one way or the other to better pining by our 2.0. And now anyway, I think he's acknowledged that sometimes the two sides talk past each other. And so as I was listening to you talk, I was wondering the degree to which you think your understanding of this is influenced by your time and industry. I think the concepts and the data right strategy in my thinking is very much influenced from my time in industry because I didn't work on just DOD, necessarily US DOD platforms, but I worked on military sales as well. And so when I look at the two DOD or government and industry, how industry makes money, they're reporting to their shareholders, then the folks get bonuses off of that. That's what drives their company. With the data rights piece, we had to be able to retain IP so that way we could then resell it to other countries, other customers. Within the government, we need to do better at looking at what we actually want. Do we want innovation? If we want innovation, then we need to allow industry to invest IRAD and retain the IP for that. If we want competition, then us paying for the data rights upfront and investing in those doesn't really drive competition. It's the ability to replace those in the future. If we spend all our money up front on that, we're not gonna be able to even recompete it. So I think we need to look at that. So the affordability versus profits, I think we need to look at what drives industry and then what drives us and then correlate those together in devising our data rights approach. To further follow this a little bit, Dan, I wanna ask you about one of the other elements of the FEL effort writ large is the piece where you are asking industry to invest a significant amount of their own capital in both lines of effort. Can you offer some commentary now, some partially down the road on this about some of the lessons learned in that regard that agree to which you think the kinds of things that you're doing in FEL are generalizable across more broadly sort of where are we in that finding the right balance? So it is balance, that's correct. I would say that my read of the industrial base would say that industry is very concerned as is DOD that our future of vertical lift is on a ledge. So we've got a lot of modernization programs that have been ongoing for some time and those are in production or assembly and they come to an end here soon and I say soon in the relative terms from an acquisition timeline and the life of those aircraft is getting quite old. So we haven't put new aircraft in the fleet, brand new aircraft in the fleet for some time. So we haven't done a lot of this work in a very long time. We've been doing major upgrades, we've been doing that very well but we haven't done new designed aircraft in a long, long time. So all of us need to spin ourselves back up on that and so I believe industry is on board with that. I think that's the indication of why they're willing to invest so heavily but I do know that industry looks at it from both sides. So of course, future vertical lift is not a given at this point but honestly it's in my mind the most efficient and the most affordable path forward and I believe industry sees that but industry is leveraging in what we're doing across the board whether it's the architecture piece or whether it's the air vehicle piece so that they can use that in our current fleet to maintain relevancy until future vertical lift comes about or future vertical lift is on pause again for some period of time for a next generation fleet then our current fleet will have to be maintained. So I believe that's motivated within industry, I believe that that's what's bringing their investments to the table and it's really relevant regardless, it's really down to a question of efficiencies. What's the most efficient and affordable method to go forward? So I'll branch just quickly into saying that therefore we're doing a business case analysis under future vertical lift. We are trying to bring together all of the elements of the future vertical lift community and we're trying to articulate and the intent to have a product late next year, a business case analysis that looks at how many of these are applicable to the current fleet, what levels, what that looks like from an implementation and affordability perspective and what a future vertical lift in comparison would be. So really establishing the groundwork for what would be an analysis of alternatives when we kick off a future vertical lift program. So we're looking to make the case if you will and I believe the case is gonna be pretty solid when we get to that point, but proofs in the pudding. So we'll get there. Hi, CW2 Andrew Wicklin, Wisconsin Army National Guard H-60 pilot, test pilot. These complex systems that you're talking about, especially fiber optics, things like that waves of the future. My question involves how do you anticipate the services will train and maintain qualified personnel, retain them in their service after they've been trained and then will the services instead maybe rely on a more robust contractor, civilian force, particularly in a deployed or adverse environment? Thank you. So I don't think I can address the use of contractor support in a maintenance role deployed. I think that historically that's come up as an alternative, largely in the face of affordability. I don't think we're looking at enabling that sort of support as much as we are looking at commonality across the board as a concept that enables reduction in cost and all of the column-derived requirements for the purpose of this discussion. If I have a certain level of common components, in theory, I reduce my logistics footprint. I train a smaller cadre of folks that are qualified to work on that system. If I can align that across the services through operational concepts, through policy, through concepts of deployment, I should realize some measure of savings in operations. That's one of the things that we're looking at through the business case that Dan just discussed, specifically in the areas of training and through common and in common software and also in maintainability. I think what we've seen historically is that we do achieve some level of cost savings by implementing a level of commonality across family of systems. There's a reason that the Navy's flying Hornets, Hawks and E-2s off the carriers, right? I've got a common cockpit in both of my series aircraft. They both operate off the same ship and I'm running the same code. My maintainers and those squadrons are trained similarly, but they're deployed in different squadrons. So through a simple memorandum of agreement, Mac on one aircraft can work on the other squadron's aircraft. We're talking about complex systems. No doubt that the guys coming out of boot camp are gonna go to a schoolhouse that are trained on those complex systems. Something that was mentioned earlier was the fact that one of the most junior engineers at the company is the guy that's kind of leading the charge and encoding using the new standards. We've got academia partnerships through the consortiums that I think are building those up. I think the push for science, technology, engineering, mathematics through the high schools is gonna enable the support that you're alluding to to support our forces, but it's gotta happen. I'll add that as ages ago, I was a tracked vehicle mechanic in the National Guard. Today I sit on the senior steering group for engineering and resilient systems. And one of the things that model-based design will allow you to do is be able to model what the maintenance will look like. And so modeling, not just the system, but also the costs that go into the sustainment tail are critically important to the department to keep things under control and also to make to project what skills we're gonna need. And so your point is very well taken. Last question in the back there. So the last question is from a French major, Don Klein, Elba Systems of America. I'd actually like to go back to Dr. May's opening statement about culture and cultural changes. And generally people, although we'd like them to be altruistic, don't do things of their own volition. So from a positive carrot perspective, how do you intend to inculcate cultural change? Recognizing that obviously DOD, even within services, has its own cultures, then we go to industry. And even within the industry, we talk about wanting plug and play capability, but the industry that develops that plug and play has a very different culture than the aerospace industry. I know it's a very nebulous question, but it's ultimately one that if you wanna see the full vision implemented, you're gonna have to get the buy-in across the enterprise. So I just ask that as a last question. Yeah, that's a good question. I sit in the research directorate, and so I don't own acquisition policy or even systems engineering in any way. So what I will do is I will advocate for better buying power 3.0. And I think if you look through better buying power 3.0 and you ask yourself, do the things that are in there, do they make sense, right? And I think they do. It's hard to find somebody who looks at something and argues, this is a bad idea. I mean, it's a list of things that just make sense. And I think your real question is, how do we get that to our program managers, and how do we get to that to the people who are the implementers, right? And I think that that's just a matter of really trying to take value to heart as a government person. I do have things that I am in charge of, the research programs, but I try to look in there and ask, am I really getting the value? And I think if we start to teach the new processes, so in our case, there's open systems architecture, there's intellectual property plans, data rights plans, let's make sure that we seriously emphasize these, say at DAU for example. And it's a leadership function to translate BPP 3.0 and get it transmitted down to the workforce. So I think from my time in industry, I think industry is fairly well, even in the aviation side, fairly well positioned. I think each of the companies already have a culture of product line approaches, reuse across their product lines. They were driven that way to increase profits. And we should also take that same look at it as how are we going to increase the affordability of our systems? So if that's really what we want to look at, that's kind of the same type of cultural change. And I think we're seeing a push from our leadership. They're getting more on board and pushing down instead of it being a bottoms up push. Now we have more of a tops down push. Dan quoted Vice Admiral Dunaway. He's a huge advocate of this. If you haven't seen the article that's out there, there's many different quotes in there. So at Nav-Air, there's a huge push on affordability and open architecture and where we go from there. So that's helping change the culture there, at least at that CISCOM. Anybody else? Talk about the industry side. Okay. On the culture side, I'm trying to think of it in terms of a combination of skill and culture and we have silos. So they all kind of mesh together. So there's definite cultural resistance to more integration between flight controls and traditional mission systems. That's a barrier we gotta get over at some point, I believe, if you're gonna make some of these innovative requirements a reality, that's one. Another one is the whole method of systems engineering and software development, we have to get away from doors and these long text-based requirements documents and ICDs and think more models and formal methods, for example. And there are organizations whose life is dedicated to maintaining the door system, producing artifacts in a certain form and structure. Maybe to the extent that there's a stepwise way of getting into it to auto-generate some of those things might be a small step towards trying to deal with some of those issues, but the cultural boundaries are these traditional legacy organizations that plain old simply don't wanna go away because that's the way they've done it before and that's the way it's worked before and this is a big change. So it is a big change going from structural decomposition to object-based and model-based, you know. So we're seeing it, it's gonna take some time. That's the best thing I can tell you on that point, but I think people are recognizing that that is the right way to go. It's the best I can help on that cultural one. Okay, well thanks so much to all of you for coming and for all of you for coming as well. We are hoping to have our next FVL focused event in December with a panel of Navy staff representatives talking about Navy Future Rotorcraft Requirements, so more to follow on that as soon as we know it. And then of course we'll have a new agenda for FVL events in 2015, so all kinds of FVL excitement to look forward to. Again, thanks very much to all of you very much for taking the time to come and for your insights. Appreciate it.