We are fairly close to our agenda time at this point and also really happy to be bringing you an interesting group of individuals. These gentlemen that I'm hoping you can see the slide on screen now are extremely involved in certainly open architecture, open standards. As you see to my left, Mr. Joe Carter, US Army Program Executive Office Aviation, Acting Systems Engineering Lead, but Joe is the face steering committee chair and I'm not going to let the cat out of the bag, but Mr. Carter, when it's your moment to do an introduction, I believe you may have added another hat to your job titles and workloads. So I won't say anymore, even though I probably told a little more than I should be at this point. Next we have Jason Derner, as you can see, Architecture Team Lead, Intel Technology and Architecture Branch, US Army Combat Capabilities Development Command, C5ISR Center. Jason, I love it. It goes on and on. You are extremely involved of course in the technical working group on the SOSA side. These gentlemen, for the most part, folks, these gentlemen are not just SOSA. There is a lot of overlap in their involvement on both consortiums. So I'll let them get a little bit farther into that as you hear from them. Then we have Dr. Elia Lipkin, just thrilled with his efforts. As many of you know, he's our superstar. We look to Elia to get out there in the public. He does a tremendous amount of webinars and connecting the public and going back and connecting the government and DOD for all the upcoming new technical standard from SOSA. So as you can see, a technical expert for the Air Force Lifecycle Management Center, Centers and Engineering Directorate. He is ahead of the SOSA Steering Committee as Chair. We then have my colleague that has been just an enormous help, Tyler Robinson, Lead Engineer on our Avionics Architecture Team, PMA 209. Tyler has been a very involved engineer. We recently, we meaning Navair PMA 209, launched our host, which is the Hardware Open Systems Technology website to support that particular platform. So again, four heavy hitters for you all. And to put the cherry on top, if I may, Jerry Gipper is back with us as Executive Director, Vita Trade Association. Jerry, I'm going to turn it over to you, sir. This panel is yours. We'll let you of course work through the introductions and then move on to our panel discussion and open interaction. So it's over to you, Mr. Gipper. Okay, thank you, Sally. Good job on the introductions there for everybody. Welcome to this panel session and how do we keep moving forward when it's next? I'm going to go ahead and bring up the slides. So I'm going to need the ball for a second here. I'll bring up the slides. Do you have the host to give me a screen share, please, Sally? Up, there we go. Jerry, the slides are already up. There we go. Oh, you're going to project them from there. They're already there. They're already there. You can just move on. Okay. Okay, we'll use those. Thank you. So with that, Joe, I'll bring you up and I'll let you finish your introduction there, if you would, please. Well, Sally said, you know, I've added titles and that's probably true, but it's really the system engineering one is the one that I've added on right now. I'm still doing the face stuff for the Army, still doing most of the, you know, involved with the most of stuff involved with a lot of the open system architecture for aviation as a whole. Plus, you know, I've been doing the real time safety stuff for the common operating environment that ASALT runs. So I'm not going to read all the chart to you, but I've been at this job now. I always tease one of our guys because he said, no one had ever lasted in my job more than three years. Well, I'm approaching seven, so I feel like that's been a huge success. You can go to the next slide. So one of the things that when I first came in, I told our guys that we need a better way of messaging what we're attempting to do with an open system architecture.  So what we did was we tried to come up with a chart that showed them by software reuse what we could do and how their funding could actually go further. So Platform A, and I just pulled some pictures. You'll even notice the last word we don't even use anymore, but if the funding for Platform A goes through B and then we can reuse some of that software over in Platform or to Task B, and we can reuse that software over into Platform B, now their money gets down to Task C. If we extend that even further into Platform C, it gets down to Task D. So it gives them a lot of opportunities to expand or stretch our money and make it go further. And you'll see at the top the different reasons we would be upgrading maybe new warfighter functionality that we're going to use. It could be headquarter mandates by congressional or higher from out of the building, obsolescence issues or just technology insertions.  So the other thing we're wanting to do is we want to make sure that whatever we're doing from a face perspective helps reduce those costs through to strategic software reuse. So these five principles, I built a lot of this around Mosa as a whole because the five principles of Mosa to the side and then how the face approach and ecosystem meets those to the to your right side of the screen. It's a, you know, establishing that environment that's huge because if you're trying to do an open system architecture, you got to have that, right? We're in the process right now of standing up a Mosa transformation office. One of the things I've been tasked to do is stand up the digital engineering environment that we're going to integrate within our PEO network. That's going to allow us to maintain models on on our systems and we're going to have to try to provide access to those models by external access.  The data architecture, a lot of tools, you know, the CTS, you know, rigs and Bossa examples. Bossa as a whole has been a great training tool that we've utilized within an aviation portfolio, as well as it's been expanded throughout the the face consortium as itself. The employees, the modular design, that reference architecture and data architecture is going to help with that. Key interfaces, those interfaces being the OSS, the iOSS and the TSS all coming from face, you know, will help meet those interfaces and then select interfaces, open interface standards that we can leverage as part of the face thing is A-Ring 653, A-Ring 661, OpenGL and POSIX. And then the thing that I always point out to everybody when they start talking about an open system architecture is certification conformance. And face to my knowledge is the only one that has that capability through a conformance program that is completely operational. And we actually have a library that's got a lot of products in it. And we're adding some, I think just this week, we're adding some more. So, next slide. I mentioned that we're undergoing a MOSA transformation. We're standing up that office currently. We are looking across our portfolio and trying to see where areas are, you know, where we could apply MOSA implementation. We're following that guidance from DoD, the tri-services, the AE and ASOL, not to mention OSD as a whole, has been very interested in some of the things that we're doing and have actually asked us to brief them on the things that we're implementing currently. MOSA as a whole will be a source selection discriminator for future contracts. It's coming. And, you know, we're trying to look at the language for contracts and everything now. And I push them toward the face contracts language out of our business working group. So, that's one of the areas that we're pushing. As I mentioned, we're creating an environment across our aviation system to allow this digital engineering. And it's expanding rapidly. And I have a traditional approach to a digital engineering environment. I don't believe it just from the system engineering side, but it's going to be from the financial side, as well as the contracts and all the logistics parts with facilities and things of that nature. So, our intent is to completely change the way we do network business right now. We're looking at utilizing, you know, a complete digital engineering approach. That environment as a whole is, you know, we're in the process of training. I've actually been in a meeting today where I was talking about trying to get people, you know, I need a schedule. I need a class schedule out. We're putting that together. Hope to have that published. Just finished our level two model based system engineering class two weeks ago. We started another one here in two more weeks where we're trying to train personnel within PEO aviation on model based system engineering as well as just the design or the the concepts of open system architecture. So I think that's it will lead us to that reuse of software components. There's other parts to this. I could talk for hours on it, but I won't. I will not bore you. So I'll turn it back to you, Jerry. Okay. Thank you, Joe. Jason, I want you to spend a couple minutes here giving us a bit of what you're up to. Okay. Thanks, Jerry. So as mentioned before, my name is Jason Derner. As the architecture team lead at I2WD, I've been involved with both CMOS and SOSA since their inception. And as I'm currently serving as the technical working group chair within SOSA, I'm really pushing hard to maintain alignment across those those standards, those initiatives whenever possible. So the slides I'm going to go through general columns already touched upon many of the points. So I'm going to use this opportunity to just reinforce some of the key points from the discussions. So next slide, please. So I always like to start by just re-baselining folks with what CMOS is. Because CMOS is a suite of standards. A lot of folks gravitate to open VPX and the card aspect first. Rightfully so, it's it's easy to understand and it does provide a lot of value. But the fielding capabilities as cards is just one of the aspects of CMOS. CMOS also leverages the modular open RF architecture to provide a decomposition for radios. It establishes the radiohead construct, promoting the amplifier with the antenna. It really lays the foundation to be able to share the antenna's amplifiers, the RF resources on the platform. In addition to that, CMOS leverages the vehicular integration for C4-ISR-EW interoperability victory, which establishes the network data bus on the platform and also allows for the discovering and sharing of services such as position navigation time. And then finally, and this dovetails into what Joe was just saying, from a software layer, CMOS has adopted a number of frameworks to really abstract the software from the hardware to get at software portability and reuse. So in terms of the frameworks, we've adopted, we've adopted Redhawk, software communications architecture from an RF perspective, the future airborne capability environment, from avionics and just general purpose computing perspective. One thing to point out is we have adopted multiple frameworks, not because we want proliferate multiple options, but because each of those frameworks typically comes with an existing library of capabilities. So we want to make sure we can reuse those capabilities and make sure that they can interoperate with the other layers within the CMOS suite of standards. Next slide, please. So this shows how it all comes together. As General Collins mentioned, this is sometimes referred to as the universal a-kit. So moving forward, ideally, if capability is software only, it would be deployed as a software firmware update on existing hardware. So for example, if there's a mission command or a C2 application, that could be deployed to an existing single work computer in the chassis. If you do need to bring hardware, for example, there's a new communications wave form, you can feel that quickly as a card and then plug it into an existing or open payload slot in an existing chassis. Ideally, that capability would then take advantage of the existing antennas, amplifiers on the platform that are discovered and controlled via the more interface. Although if you do need to bring a new radiohead, perhaps because you're operating in different frequency band or you require higher power, you can simply do so. Bolt it on to an existing mount, but still take advantage of all the existing plumbing on the platform. So all that really gets at not only cost savings in terms of integrating these capabilities on the platform, but also is what enables you to rapidly integrate new technology when required. So next slide please. So since the focus of this panel was what's next, I just wanted to reiterate all of the ongoing activities within C5ISR Center, within the Army, POC3T, POI, AWS in terms of applying and using CMOS. Because from my perspective, that's what's next. We have the standard, now we have to start incorporating it into acquisitions, into programs. So General Collins already touched upon the strategy fairly well in terms of managing the standard, including participating in standards bodies such as the Soci Consortium in order to continue to evolve the standard, address emerging gaps, emerging requirements, but also continue to maintain that alignment that allows the reuse and economies of scale across the community. From the establishing labs, oil is in the forefront and you'll hear more about that I think in the upcoming months. And then field experimentation working hard to demonstrate CMOS capabilities at upcoming events such as NetMod X and then PIN tax. In terms of synchronization, we're synchronizing across a number of programs, a record, which I'll get into a little more on the next slide. Synchronizing across emerging requirements, which as General Collins mentioned, CMOS mounted form factor is one of the big ones. And as well, coordinating across prototyping efforts either within C5ISR Center or coming out of organizations such as the Network Cross Functional Team. So next slide please. So in terms of ongoing efforts, so PM Electronic Warfare and Cyber released a memo previously requiring all of their programs to leverage CMOS wherever appropriate. So as a result, there are a number of program of records out of EW&C that are already built against and aligned with CMOS. So the first out of the gate was the Multifunction Electronic Warfare Air Large Program, which provides an electronic attack, electronic warfare support capability for a gray eagle. Kind of at the opposite end of the spectrum, you have the Tactical Cyber Equipment CMOS chassis, which is using CMOS to provide a man-pack capability to deliver CMOS effects. And then in terms of large ground vehicles, you have the Treser layer system, which is providing a more capable integrated multifunction capability, providing SIG and EW and cyber enabling solutions. On the heels of that, in the comms, P&T and mission command areas, as well as EW, you have the CMFF capabilities, which will be prototyped, I believe with the intent to have a minimum viable product ready for fielding sometime in the 25-time frame. And then feeding into that a number of prototype efforts. So TSM is the comms capability that came out of the network CFT-TEM4 effort. As General Collins mentioned, TEM5 is focusing on radio heads that would be complementary to that card. From an S&T perspective, we're excited to see the universal software radio peripheral getting ported to a CMOS card, because that provides a very clear transition path as we prototype capabilities on usurps in the lab, porting them to a open VPX card and more ruggedized form factor facilitating getting that capability into the field. Crypto is a big one. We have always within CMOS wanted to be able to share crypto capabilities on the platform. So one of the prototype capabilities to get at that, we took what had previously been done within C5 ISR center with the rescue program, a government-owned software-defined crypto, and we ported that to a mezzanine card that can then be integrated on a switch in the chassis and thereby shared across all capabilities. In terms of software, looking at porting all of the existing software that exists onto single board computers. So joint battle command platform and the follow-on mounted mission command has already been ported. It'll be one of the capabilities that we're looking to integrate as part of CMFF. What's not listed here, we've also worked with industry to port the electronic warfare planning and management tool to a single board computer and ideally in the future we'll have both of those running on the same card in order to show the swap reduction that's possible. Number of prototype systems ranging from last year we demonstrated a mounted assured P&T system where in under six months we took a chassis that had already been developed, a COTS P&T card integrated it on a striker with a anti-jam antenna and took it out to Wismer to demonstrate a rudimentary assured P&T capability. Similarly, from a SIGINT perspective we took a CMOS chassis. In this case the chassis was actually developed by the Air Force as a SOSA prototype but since we have aligned CMOS and SOSA we were able to reuse that hardware, integrate it on a striker and then rapidly show the ability to implement a number of SIGINT capabilities within the architecture. And then on top of that there are a number of ongoing prototyping efforts and small business innovation research efforts to further get at the next generation comms card software defined radios and then radio heads looking at both analog and digital RF distribution. So with that I think I've eaten up more than my allotted time just wanted to give folks again a refresher on what CMOS is and then a feel for some of the ongoing activities within the C5 ISR community. Jerry with that back to you. Thanks Jason that was a good update. Tyler you're up next with a your update thank you. All right can you hear me? We can hear you. Okay yeah thanks thanks for having me it's Tyler Robinson and thanks for the introduction. So I'm supporting GMA 209 so you had the opportunity to hear from Captain Wilson earlier so I just want to probably highlight a few of the lower level details that we are working in support of her efforts and hopefully be able to answer any questions that you have in those regards. So Jerry can you go ahead and advance the slides I don't think I have control thank you. So within our team in PMA 209 we have three I guess sub teams three major focus areas the software team hardware team and a platform integration modeling team highlighted here. So pretty much since the start of the face standard our team has been in existence supporting the open architecture efforts as the standards have matured face and now going into host and supporting other standards such as SOSA and OMS our team has had the opportunity to I would say broaden some of our focus beyond just standards development into platform support and so that's when a few years ago we stood up this platform integration and modeling team and so with that team we're really focused on working with those NAVAIR programs as they go to adopt the open architecture standards. Additionally we've blended this with a modeling focus recognizing the relationship and partnership we can have with the MBSC community at NAVAIR and so we've developed that expertise within our team as well so as we go to support these programs we can kind of have that cohesive approach to open architecture and modeling within NAVAIR. All right next slide. So here's just a brief highlight of some of the programs that our team supports and we do have a small team so I don't mean to imply that we are intimately involved in the details of all these programs but as SMEs within the OA community we do have the opportunity to touch these platforms work with them at various phases for some of them it's early on as they're kind of forming the programs and writing requirements and other programs it's maybe when they're going through some block upgrade and maybe looking for an open architecture opportunity or solution with an upgrade and so our team we do have a focus on outreach to reach out to these other program offices. We partner with the other groups within our office as Captain Wilson had the opportunity to explain briefly we do have a wide variety of products within PMA 209 that has the opportunity to touch most if not all I probably can't speak to the details of the air platforms within NAVAIR and so being situated within that program office our team then has the opportunity to work with these products and to work with these platforms as they're going through their upgrades. Next slide. And this is I think this is about the last slide I have it supported the intro again just reiterating a couple points we do have a focus on MBSC we are not leading the MBSC transformation within NAVAIR but we do work closely with that group. We are focusing again beyond just the development of standards we still heavily support the new versions of face and the new iterations but as that standard has matured we've had the opportunity to branch out into some other areas and so our support as I highlighted it's not just be working with programs but it's also what products can we provide we still are in the business of providing producing products to support these standards and so we've moved been able to move some resources and focus into things like tech starter kits acquisition guides and things like that so we hope to we hope to kind of build up a more robust MOSA ecosystem is kind of one of the words we're applying to it where we have this supporting infrastructure through public websites through starter kits through guides so whether you are a program office who's looking to put something on contracts whether you are a prime contractor who has this requirement or whether you're a vendor who's producing some hardware or software component we want to be able to support the adoption and so that's really where our team is looking is are there any gaps in this MOSA ecosystem and if there are what should we be doing to fill those gaps and I think that's the last slide I have so so Jerry back to you for now and I'll be open to questions after the entrance okay Tyler thank you next up is Dr. Lipkin Dr. Lipkin if you could jump on and do your introduction we can get the headed into that hi can you guys hear me yep you're good great so I am the Air Force life cycle management center open architecture support lead for OAMO our office actually has an open mission systems technical standard run by Stephanie at quid and our chief engineer for that is Steve Brooks our goal primary is to support a deployment of open architectures for the Air Force and Air Force systems next slide so I like Dilbert and I think this particular slide is interesting because everybody has an open standard and we're always going to have another open standard come out the every year so the question is is how do we manage all these new open standards together so one of the things we've done in Sosa is we decided to leverage other open standards first and adopt adapt and innovate only as required which made us very unique and also set us in path of convergence with Army Navy Air Force and other agencies for example Jason earlier mentioned Red Hawk that's really an NSA product we're using face which is you know Army Air Force Navy product we're using Victory which is an Army Stan Inc which is NATO it's so on and so forth SCA is another one which we're planning to use which is whereas innovation forum and the important next slide so there are a lot of benefits to doing open architecture and consortium environment few of them are a helps us to simplify our management position help us a lot with sustainment and interoperability the last two are quite important because once we standardize in the similar interconnects or key open interfaces as Joe Carter mentioned earlier you can have reuse of savings it also makes a sustainment a lot easier because I can buy one part number for multiple programs so instead of buying lifetime buy of let's say 50 parts for just one program I can do lifetime buy of 500 parts for 20 programs so everybody benefits and then allows us a flexibility and agility at a later date which also speaks to interoperability because it allows us to pivot quicker if a new technology comes out for example next year Intel is going to be generating another processor well how quickly can I feel that if program A pays for all the NRE for how we plug it in against Sosa CMOS and host technical standard then we can probably roll it out within 12 months or less to all the compatible systems out there and for the industry it gives you a bigger marketplace you can improve on your development costs because one solution will fit multiple departments of the multiple duty department it helps you create product families because you can service multiple variations for unique customers your tailoring is simplified and strategic sourcing one of our challenges is a lot of times in open vpx before CMOS host and Sosa whatever you buy you start with that one vendor for life with Sosa whenever you buy you have a choice of multiple vendors for life so your ability to pivot quickly some happens to vendor A is greatly improved so one of the things we've done is we followed the face model to make sure that everybody has skin in a game if we pay 100% everything what's the risk to you the company for successful failure of the technical standard it's very minimal it's all in the government the skin in a game the risk is shared so it makes us more interesting and challenging as well it helps us to open up the aperture for Sosa participation we have over 100 companies join the social consortium if it would be in the other way we would have been more selective on who we invite the way we mature the technical standard is through a series of prototypes to validate and verify that the social technical standard is properly designed so as we iterate through a development test demonstration we feed all the lessons learned and things we discover right back into social technical standard so other folks get an opportunity not to make the same mistake it also makes for more robust open standard because we're constantly validating it next slide I borrowed this from Jason's Turner team they did a good job this is copy with tri-service memo which outlined Sosa, OMS, face and victory as the four major standards to look at and of course PMEWC memo as well next slide so this is the newest addition to social endorsements I actually pasted the whole thing over if you want to read the whole thing it's in the congressional report 116442 the link is pasted on the lower right corner and I will read you one paragraph finally the committee the military services should begin to combine missions to enable seamless and social for multi-mission tactical communications, electronic warfare, second and battlefield computing in one system such an effort will reduce swap on various platforms for the military electronics and unify the industry around common military hardware as well as software standards so this is one awesome endorsement from congress this is again part of NDIA, the Thornberry Act and it's very powerful basically what congress is saying is what we're doing is the right thing and we're in the right path it's the best endorsement I can ask for it also reinforces the need for standardization across services next slide there's more than a hundred members again I borrowed this slide from the army brief a lot of times people ask what's the relationship of SOSA to CMOS and it's captured here as well as the list of participants one of the major additions to our group right now is Intel as you can see the corporation so we're working with them to see how we can streamline adoption of Intel products processors of PGA's internet of things we're also in discussions with NVIDIA as well currently Mellanox which recently got bought up by NVIDIA is a member of SOSA consortium so we've been discussing with them as well next slide this is a commercial roadmap that we put together to help government and industry to plan procurement and tech refresh one of our challenges is a lot of times I get a sell or a document proposal from the industry and they have to evaluate for its technical qualities in one of them is are you selling me an obsolete component or is that component going to go obsolete when I field it so what we did is we worked with the social consortium hardware working group to come up with the roadmap of technology where do we think it's starting where do we think it's sunsetting and where are the upgrades are and it's very powerful because using this small diagram if I get your proposal I can say aha you selected PCIe Gen 3 well guess what in CY22 is being sunset in favor of PCIe Gen 4 so why should I buy technology from you that I know is going obsolete or it can also encourage me to invest in PCIe Gen 4 over PCIe Gen 3 because that's what the mainline cuts components will be going forward it basically allows me to figure out where the need in technological curve is very easily for the programs next slide so we're having a virtual plaque fest in Dayton Ohio Air Force is going to try something new we are inviting vendors to deliver their components a lot of them already arrived today actually and we're going to do it in about two and a half weeks where we're going to test out and see how many cards components and capabilities we can swell pins pop out and the lessons learn and additional information will be shared if you have any questions contact information is right there next slide finally we have several outreach activities we have quarterly newsletters we have a website we have multiple events today is one of them and if you have any questions there's emails and contact information there as well next slide and I think I'm done that's it for you guys yeah thank you there's been a lot of questions come in so I'd like to kind of open it up to the panel discussion with we can well bring up questions and maybe I'll call in one of you to start the question and then if others have some things you want to add into it that would be great I'm going to start with one of the questions that I had and that is I heard several of you talk about the need for model based systems engineering um how does do organizations like somebody like Vita what do we should should we be doing different to make it easier for you guys um joe you maybe I can start with you to be honest I don't think there's anything that you really could do I think you are pretty much right in line with things that we're already doing and already utilizing so there's no no tools or anything like that or standards written in a different format or oh I'm always looking for other tools that we could utilize so have you got an hour yeah Jason you talked about do you have any comments did I lose Jason sorry I forgot I had to unmute the challenges of being virtual the comment of the year right it still amazes me that we have systems that have two or three layers of muting but that's well another story so the question was regarding model based system engineering yeah is there anything the standards groups should be doing to make it easier for you guys with the work you're doing not from a model based system engineering perspective right I mean the from and I mean I'm going to go off topic for a second but I mean from from my perspective right we we've we've got a lot of the standards written right now we need to start using them right and and using them I think we're going to learn a lot and I think the understanding and this is where I guess model based system that system engineering could help in terms of understanding as we as we've broken down our stove pipes right and we moved to multifunction how do all these missions that that typically operated independently how do they start to to work together to provide a cohesive capability and what are the implications in terms of shared resources user interfaces so not not exactly answering your question directly but I could see nbsc kind of factoring into some of that right okay jerry yes tyler I can also dance around that question I think I don't I don't have a direct request of something the standards bodies could do differently but I would highlight that I would say in years past within nav air there has been more thrust on maybe a higher level of modeling that that mission level in that system black box but now over the past maybe year or more there's been more focus on what I would say is a lower level modeling getting down inside the subsystems of the components and looking at how we could use modeling to to better support you know those desires at that might get down to a host level so we are looking at modeling the host standard we are looking at how we would model cards and pens and these types of things and into what level would be appropriate to provide benefit to the government and so I think as of today there's not a specific request but it is something that we are continuing to push forward more with even at the lower levels okay dr. looking you have anything to add to that or no not really I think all these answers were good okay we have a lot of questions I'm going to try to get through as many of them as I can how do they open systems architectures that we've been you've been talking about today scale across the different platforms operating in different domains like air land and maritime does anybody want to take a stab at that okay uh jason yeah so they they scale very well right so our our motto from day one has been architecture is independent of altitude right there's there's nothing about any of the technologies that we've selected that bind them to a ground vehicle and air a manned airframe a pod a ship a sub right that they are all equally applicable and I think you you're seeing that based on the fact that you've you're you're starting to share hardware across both air and ground programs right and I think that will continue to to grow as more and more programs start to embrace and include these standards so I guess I just want to foot stop I mean the we have a lot of diagrams and I know I've taken heat from it in terms of I show a slide with a ground vehicle on it and then my first question is well why isn't there an airframe or why isn't there a pod and the answer is I was too lazy to create end versions of the same slide right it's they are all equally applicable over we need we need a cloud image for the uh the different uh different environments right yeah right Roger that so um anybody else to actually piggyback on what jason said uh we build the standard not to be just altitude agnostic but also uh the main agnostic for example jason forgot about submarines so you know under sea what do you call that so the point is and this is something that mr tremper from OSD uh stated during the last social um face to face event is we're working toward converger app physics are the same the use cases between army name air force how we deployed are different so when you boil down to the pure technology levels it doesn't really make a difference so once we realized that it's really the same it was a lot easier to develop develop commonalities however my interest our aircraft uses ground vehicles but that's okay because uh the vendors still gonna sell me one str they don't really care where I look it in mine may have conformal coding that jason's won't but it's still going to be the same card Joe i'm not just questions for you um has there been any concern from the program managers regarding software areas that they feel are not covered by the face technical standard and if so what are they looking to bridge the gap for the most part I think they've pretty much been happy with everything they've done I think the standards are pretty broad uh the you know whichever face standard you want to use I think they're pretty broad always push them toward using 3x as I didn't say 3031 I just say 3x I don't care which one they use for I have heard of no issues from many of our platforms and I'm pretty good about asking asking those questions well how did new uh requirements maybe get passed into what you're doing normally they you know if one of the platforms or one of the pms is having an issue they'll come back to me knowing I'm the centerpiece for the face stuff right so what I do is I send it back up through the technical working group I'm sort of blessed in that the chair of the technical working group Chris Crook works for me so uh we we can have a conversation in my office assuming we ever get back in our office but uh you know I have them push it back and have them look at the uh standard as a whole and see if there's anything we need to do or they can submit a prcr process back to the consortium for for check does anybody else have anything in that area we'll see um another area question I have is um this kind of goes back to Dr. Lipkin's uh Dilbert cartoon is um it seems like the number of standards is growing and so how do you guys how do you handle that I mean Dr. Lipkin kind of talked about it but um new stuff keeps getting added are you concerned about that or what's what's what's what are the philosophies do you have all right simple we have a design to work with the standards as emerging for alignment and communication purposes we have a way to stand it up as required most recent example is sca and wireless innovation forum um that is how we're planning to do this outreach and collaboration and seeing opportunities to leverage each other so I think you got to look at it from you know you got to address the different domains uh software hardware signal processing network you know so if if we pulled that thread a little bit and you just use an example system architecture for software we would use space and I know for a fact that sosa and cmos both leverage space for some of its software for hardware and we use host for signal processing we're using mosa for our networking stuff well I push victory the main topics that I always push our face host sosa and victory uh I tell them you know that's not inclusive there may be others that we need I mentioned more more and I think that's uh you know you just got to look at the domains for what you're doing how do you guys go ahead sorry I just wanted to add one other thing so even though it might seem like there's more and more standards I think we maybe haven't done ourselves a service because all of the or at least all the standards that that we've discussed today are aligned right they might have a different name in the air force the the navy the army but they have all been aligned they're all leveraging the same commercial standards right I mean so I truly am seeing more of a convergence as opposed to a divergence in terms of the number of standards and how they all lay together over it's the same time how do you um how do you work with other groups that may be working on open standards architectures I know you guys have done a really good job within the the US DoD is there other organizations I think um Tyler you meant you touched on some of them a little bit in your your slides set but how do they get involved certainly certainly there's um there's a few other organizations that come to mind um that aren't uh just DoD specific I mean one that comes to mind we work in certain areas with the OMG for example the open management object management group um as we start to touch some standards uh that would impact uh the like the UAF profile and things like that so where there is a need we will have members of our teams um absolutely interface with those to create the right touch points um I know there was a question asked about COSA um COSA collaborative open systems is a working group we've established with the UK Ministry of Defense and so we have the UK the Army and Nav Air participating in that uh to look for areas of alignment and preventive divergence within standards so um really we we I wouldn't say I have an answer as far as an overarching approach to address every single other body that's out there but certainly we have SMEs in the field that start to recognize where there is um potential alignment or divergence between standards and we get the right experts plugged in and become active in those groups um I want to grab a question that came in off the um of the WebEx here is is there any work that's being done on a common standard for elent signals and data same by where honestly that's a loaded question I can't even answer in this forum long story short we're exploring that's all I can really say okay the other set of questions that I have been monitoring and trying to quickly answer by text there's model based system engineering and cyber we do have a lot of activities and so so to support model based engineering we're leveraging phase data model for one as part of social activities and other is but the entire team out of Huntsville uh j-cell supporting social nbsc activities where we're actually literally modeling the social technical standard in the system l uml the goal about putting all of the shells right out of the model rather than the document so if things go well the social document will be a auto-generated product right out of the system lml models right now they're leveraging enterprise architect as their goal primarily due to the cost of enterprise architect it's very affordable for small businesses and academia so hopefully that will answer a whole bunch of questions on nbsc if you guys interested in seeing what it is uh right now the nbsc model is distribution d it hosted on air force vdl site if you have the credentials you're more than welcome to download and explore it if questions about the data modeling uh phase technical team can help or social technical team on data modeling can help as well yeah there seems to be a lot of questions on the nbsc stuff so we'll have to respond to some of those offline here um the space domain seems unneglected seems neglected here can anyone care to speak about uh what might be happening in that area yes uh the space command joined sosa back in december and uh they had an initial kickoff the last virtual face-to-face and right now we're ramping up to support space community i can't say any more than that till the space community is ready to save themselves but uh what we've done is leveraging um some of the lessons learned from sumo if you guys know about that space technical standard and space vpx are all being rolled into sosa to support leveraging the common interoperability environment for the satellites as well as the air ground and submarines so the best thing i can say is they have to join the working groups and participate to learn more so the question i have too is um what what about the modular open systems keeps you guys awake at night or all the infrastructure or are you all sleeping well in place what was that i don't sleep at all i said i don't sleep at all but uh having the infrastructure in place so uh we can provide access to everybody and uh it ranges all the way down to making sure we got the proper number of licenses for modeling tools and then uh access uh that we're going to give to our models as a as a whole do you feel like you're getting the support you need or is it a constant battle for you to get the support no we're we're definitely getting our support i mean it's it's going all the way up to general berry uh he's given us um complete rights my boss says he told me just last friday he said run it the way you need if you need to hire more people go hire them and uh i knew with my operating budget where i could pull certain people and matter of fact i pulled that trigger yesterday and started putting out hiring notices uh jason you kind of having comments on that area what keeps you up so i guess what what keeps me up the most is trying to decide what what the right level of specificity is within the the the technical standard within the architecture right what the right decomposition is because it's it really is a balancing act between specifying enough so that we get the the reuse and portability and what what people mean by reuse and portability is is relative right is it is it within a p.m is it within a p.e.o is it across services ideally it would be all the above right that we would be able to leverage capabilities across the board but but in order to do that i mean we need to have uh specificity to guarantee interoperability and at that point you're you're also the more specific you get the more you potentially constrain right so making sure you don't constrain too much so that uh you're impacting performance or you're stifling innovation so that's i think that's a it's a fine line we we constantly walk and then we're gonna constantly probably go back over the the line and make the trades to to figure out what's right for the community over Tyler what's keeping you up i can well i'll i'll uh answer it this way i can i can definitely say there's one thing that used to keep me up but i think it's changing now and i think especially maybe five years ago or so i i i think as we were growing some standards and trying to get adoption there was always the question from a program is to well how much is this going to cost and how much isn't going to slow me down up front um and i don't think at least from my perspective i i think i have to understand where i am as an engineer within a team i'm not senior leadership myself but um we had to weigh those and kind of establish the value ourselves um within the past few years i've seen even greater push from leadership from above and um and i think that's doing nothing but ease the adoption um so the momentum now is stronger than ever and um i think less and less now we're having to um fight those fights within the programs and i think people are starting to see the value and and considering open architecture approaches from the start so i think that was the issue five years ago was can we justify an open architecture approach dr. Lipkin other than tornadoes no um is excess so there's a lot of open standards uh that are behind the silos of excellence that we have to compete with and what's keeping me up at night is uh what's going on behind the silo of excellence z that hasn't opened up the door and says we spend a billion dollars or ten billion dollars uses well i don't know if i can if i don't know what your requirements are if you're supporting all the programs and all the missions so what's keeping me up at night is not knowing what's behind the silos of excellence door x and how will it impact what we're doing today i would say that's the biggest challenge have you guys seen any um um it's been mentioned that part of this whole strategy is the cost savings and being able to reuse stuff or other programs and stuff and i know it's it takes a long time to see some of that stuff but are you starting to see signs of that what i am starting to see is i'll give you an actual example one of the vendors failed to deliver us an lru and that required we had a and a test event we needed to do and we had no box to put our capabilities in so i picked up the phone and within i would say seven hours i have two alternative boxes available from multiple vendors so then we just picked the alternative and it was shipped and within five days we were operating on somebody else's box um and what this happened is it demonstrated our ability to pivot quickly to deal with the contractor non-performance issues okay i'm going to start wrapping up here i got one more one more is anybody else want to add to that by the way but on the cost i just wanted to to echo what uh dr. Lipkin said in terms of we had a similar experience of program a card was delivered late and due to having multiple suppliers for that same card we were able to to pick up a competitors card and then still meet schedule so that's uh that probably cost translate into a cost savings right it's not having to delay the program but i think that's just one example of the the benefits we'll realize moving forward over so one thing i do want to point out and i just feel that a question cost is important but it's not number one requirement number one requirement is fast fielding fast upgrades and fast capabilities to the warfighter if two cards that are identical um you know given to us obviously the cost will be the last decision factor to use but the number one priority for us it's not the cost it's fast yielding just want to make sure we're clear using open standards to support fast fielding fast upgrades fast deliveries it's a good point um so i'm gonna wrap up with the one last question we've had quite a few uh a handful of questions come in on um international access to the work you guys are doing um any update on what's going on there that we can share with the audience i mean a lot this is a us do d focused so i'll take it from the face perspective it's uh uh when i took over in the chair a couple years ago i opened it up and i told him to start acting like we had internationals at the same time my predecessor went to the state department to try to get approval to remove uh some of the itar stuff off of our documentation so we're still in the process we're still working uh trying to get it open uh i never thought it would be difficult to take it off but it's just a statement there's no itar in ours um particular standard and it makes it it's been a unique challenge to remove that itar from from our documentation but our intent is to go international and open it up where we can get international participation any bails the host standard is uh distrae it is publicly released so so it says as well distrae publicly released but we do have appendixes that are distra d and above if needed so the goal is to allow international bodies to reduce standard however participation in the working group is restricted because of the nature of the business however with that said we do welcome if somebody wants to pick up from our industry partners overseas so it's a technical standard snapshot three or upcoming version one and provide us feedback in the written form we're always glad and happy to receive inputs that way the results you will see in the next revision our technical standard because it has to be PO approved to be released as a distrae but we're always welcome input and writing for anything that we publish on the open group side for everybody's consumption it's not an easy way to work but it's the safest way to work any other comments yeah so i would echo everything that was said i mean from from a seamless perspective we we've pushed to make everything publicly releasable or publicly released when possible for or explicit reason of allowing our foreign partners to to to use it not only the the partners but their industry right in order to to be able to to to compete it within their industry the the standards truly have to be open uh the we have been coordinating uh government to government in terms of standards development but it would be nice at some point to have a a a better forum where they could more interactively participate in the sausage making if you will right i mean as as dr. Lipkin said it's it's one thing to provide written feedback it's another to actually have them in the room and participate in the discussion and it's it's not easy but that's something i think we should still work towards over so jeremy let her jerry let me clarify because faith is distro aid but what i'm discussing is i want to be able to have international participation setting in the room with the creation and the modification of the standard as a whole right i think that's kind of where i was going with a lot of it too was is um when's that going to happen i think i need to wrap up sally's wearing out my phone with the text messages telling me to wrap um i really appreciate uh you guys that participating in the panel here today so gary one more item sorry to interrupt so i've been scanning the q and a's last year um navy tim we did in atlanta demonstrated face oms c post mora we're all toa all working together in a social c must uh environment and if somebody's interested they can look up last year's tso ad to see how we got everybody to work together to give us a cool capability sorry to interrupt i think you're going to try to get answers to all these posted here um when we wrap up here so if we didn't get to your questions online we will uh we will definitely get an answer out to you um and i i appreciate the work you guys do i know how hard it is to do these things you're doing i've been involved in this industry for over 40 years myself and i've seen great great work coming out the last few years and you guys are definitely key contributors to that so with that sally i'm going to turn it back over to you for the next uh next session thank you very good gentlemen all of you thank you so very much uh obviously your contributions not just in uh your own uh working groups your own consortium so forth uh a tremendous asset uh to the government to the industry to academia pulling all of this together um mosa nbsc and and so forth so thank you these ladies and gentlemen these are experts uh and you will continue to see them uh influence and uh write it almost the the front of the the the group uh making these things happen with face sosa seamas host uh all just incredibly uh uh important uh efforts uh so again thank you for participating we will let you go at this point uh ladies and gentlemen right now we'd like to go ahead and bring you our next session and next up as you can see from our slide uh we're about to welcome brendan o'Donnell and jason york they are going to uh of course not just showcase the new face business guide overview key updates to know as you can see here but i believe that i caught a glimpse of brendan and jason slides uh last week and i think they're going to go a little bit uh more broad in their discussion and the good news with that of course is that you will be able to get even more information about face again our whole premise for this tim is what's going on now what's new and where are things going what's next so with that uh brendan i see your face uh on there uh how's your mic check real quick can you hear me salad i can hear you fine and and jason are you uh mr york are you with us as well yes ma'am oh perfect all right i will uh go on mute and turn it over to you thank you again for joining us today for your session it's all yours um great thanks ellie just wanted to say uh say thank you for having uh jason and i present this overview of the latest version of the face business guide i think this is the probably the the best resource produced from the face consortium uh for folks both inside and outside of the consortium to to understand the value proposition of the of the face approach uh both to government and industry so um you'll be hearing from uh two of us today myself um i'm brendan odonnel i'm the vice chair of the face business working group uh my background is in management consulting and flying helicopters um i support uh joe carter and peo aviation and then you also be hearing from uh jason york jason's background is in software engineering and program management he's been really the principal driver behind the the upgrades to the latest version of this face business guide and he also supports uh both peo aviation and abmec the aviation and missile center in huntsville all right so the agenda for today will cover uh cover these topics well the title of this presentation is the face business guide overview so we'll talk a bit about upfront about the actual document itself where you can find it um and then we'll get into some of the uh the contents of that that document that really do talk about um the sort of the why behind the face approach and and the the key kind of goals and drivers and what we're trying to achieve from a from a business perspective we'll talk um about a bunch of misconceptions about face so so a lot of times we hear face either is this or does that or or isn't this or doesn't do that so uh we'll walk through some of the common misconceptions and all this you can find in the actual uh document the face business guide we'll talk a bit about how the face approach uh supports um implementing uh principles for mosa and then we'll get into some specifics on uh the value proposition for the face approach to both government industry and then hopefully at the end we'll leave a few minutes for some discussion okay this is actually the third version of the business guide that we have released so as brendan was mentioning it is a very effective marketing tool with the primary audit audience being executives uh on the government side and industry to better understand the value that face brings and uh you know in this uh you know brendan's gonna talk about this in a little bit more detail uh the face approach uh what i know you've heard that a lot uh we tried to visually show and describe uh what that actually means uh we're going to talk about the value uh specifically for the government uh and industry and then we're going to talk about applicability uh you know a lot of people say well this is great it's a it's a you know standard so we can design it in and that that is perfect for future platforms but there's also applicable applicability to enduring platforms and some techniques to use uh to make that happen uh we're going to briefly talk about rights and technical data and computer software and uh you know that's it's uh really no secret here uh we do not need unlimited uh you know data rights we need to be very selective in uh in what we asked for primarily uh in the interfaces where we won't be locked in and we can promote competition uh this guide is available at the open group library and there's the link uh all you all you need to access it is a open group login which is uh you know freely available uh together okay uh some major uh enhancements from the previous version we did a little bit better job describing succinctly what encompasses the face approach we'd mentioned the previous version the common misconceptions uh but but we provided a lot more detail on those and we're going to talk about those at length today and then with the uh recent guidance that we've seen come down from you know DOD try services down through um you know the the organizations the specific services a lot of service specific guidance on MOSA and then uh you know we are happy to report and and Joe's actually already mentioned this in uh his introductory slides in the previous session that the face approach addresses all five principles of MOSA so we won't spend a whole lot of time on that but we have you know a couple things to add uh business related uh on that particular slide okay so so as as I mentioned a bit earlier the the business guide is it's really a great place if you're unfamiliar with with what face is and what the face approach is trying to accomplish it's it's a great resource for you to go uh to go read through but um to under to really understand the the why why why we're pursuing this face approach so so what is what is face and the face approach the face approach defines an open avionics standard for software that has been collaboratively developed by government industry and academia partners it defines both technical and and business approaches for developing and procuring software for for aviation systems um it the work of the consortium is managed by and falls within the the sort of the the rules and processes for developing open standards managed by the open group um and as the speakers during the last presentation were were mentioning um all of the completed documents that have been developed by the consortium are publicly available they're published uh by the open group and and anybody can go into that open group library and and download any of the completed uh face technical or business documents but the bottom line for the face approach is that we're trying to get the best avionics aviation software uh to the warfighter as fast as possible again a lot of the similar concerns that you've heard already from from some of the the previous speakers and so how do we how do we get here um historically the the the od aviation systems have been developed uh to a unique set of requirements and they've been developed by by a single vendor um the face approach is really a response to some of these historical issues in being able to develop software that can be reused across platforms historically it's been been difficult to to these um these unique requirements and these single vendors have made it very difficult to reuse software across platforms as result in increasing costs to field the latest software there's high barriers to entry for new technologies and there's high barriers to competition both within and across platforms and the result of this is that there's long lead times uh to field the latest technology to the warfighter even even for very urgent needs and it's due to the the complexity and and to integrate those technologies onto the platforms up to this point do these acquisition structure really hasn't supported the use of uh software that hasn't supported software reuse across platforms so there there's been a lack of commonly accepted uh open standards uh for those standards that that have been developed there was a lack of enforcement uh to those standards and the structure for many of the acquisition uh program management activities has not uh incentivized them or funded them to field uh software that can be reused across multiple platforms and if you look at the chart there in the lower right hand corner what you see is that this problem is not unique to the DOD community and commercial aviation saw similar increases in software complexity over time so and as more capabilities for aviation platforms have been implemented in software there was a exponential increase in the cost of integrating those capabilities onto platforms commercial industry developed some approaches to reduce that software integration around open standards and found some success and the the face approach is really an attempt to be to bring some of those approaches to to the DOD aviation community so as as Ili briefed in the in the the the last session you know like so said the the key goal for face is to improve the affordability of capabilities and and and that really means um reducing the cost for integration and and enabling the Department of Defense to spend its investment dollars on capabilities and then reducing the time it takes to field those sort of latest and greatest technologies to the warfire um you see on the right there for for an aviation platform uh it's going to have a systems architecture that looks at things like sensors, hardware, networks, RF, and signal processing and and the scope of the face approach is is really looks at software and software reuse across platforms for aviation systems. A couple of the key kind of concepts behind face is to be able to develop both technical and business processes to support procurement and incentivize industry to develop software to the face to an open standard and and provide some support from both a technical development and and business from the business side to enable a successful ecosystem to flourish for those reusable software components and then face is a is a component based software standard meaning the the things that get certified to the face technical standard are software components rather than let's say whole systems or or platforms so it it promotes some measure of flexibility and and as you're looking at what you're going to make open on a particular system or platform uh that that face is is really looking at those software components for compliance to the face technical standard so some key um so some key attributes of the the face approach include the ability to support innovation uh enable more efficient technology insertion as i mentioned previously previously enable uh software modularity in order to port and reuse software across platforms um early on we looked at enabling a marketplace where users and software developers software integrators government program managers could find products applications that have been developed to the face standard and then faces taken the approach to to to align itself again has been mentioned in the couple previous speakers with other open architecture initiatives and to the extent possible use existing industry standards within the face approach so from a business perspective there's uh several products and tools that are out there to support uh discovery and development of face applications those include the functioning up and running conformance program so folks can take their software through series of testing and and verification to ensure that the software has been built and meets the technical requirements of the face standard the face registry exists to enable discovery of existing applications and then we've produced a sort of a host of other things that are available for folks tools templates to support things like how do i write an rfp for face application or how do i respond to to one if i'm an industry for a long time for those of us that have been around face for a while the work of the consortium was very future looking so we spent a lot of time sort of internally focused trying to figure out what does it mean to to be conformant to the face technical standard what is the best way to verify that conformance what's the best way to communicate sort of to the outside world about the availability of face components but face is and has been for for a few years now up and running so we have a a completely functional conformance process where a software developer can take their product build it get it verified that it that it meets the face technical standard and then make that product available for folks who are interested in discovering reusable software products there's as i mentioned there's a face registry which lists all of the current or list products that have been developed to the face technical standard and i was pretty sure this would happen but i think either yesterday or this morning since we developed these slides there's there's now another unit of conformance and an additional supplier that that have been in the registry so i apologize for not including everybody but but another one stuck in there after we put our slides together but the bottom line is the face approach is is is up it's running it's available in its in use now so here are the common misconceptions that we we mentioned earlier so the face consortium has been up and running a little bit over you know 10 years and this is a very successful osa you know initiative and in the past there was very unsuccessful you know ones for various reasons not having uh you know business processes covered not having a conformance program i won't i won't go into great detail there but with the open systems architecture you know initiatives there there's a lot of skepticism and there was a lot of misconceptions proliferated so some of our communication was to dispel these so a few years ago we decided we're going to start writing these down and kind of hit them off you know at the past so we talk about this at the 101s where people you know what can kind of understand it helps kind of scope it shows what you know the face approach is what it is not so brin and i are actually going to step through each of these and provide a little bit more information so i'll let brin and take the first one okay so the first one that that we had listed there was that all all all software on a platform must be conformant to the face standard common misconception and and uh this is certainly not true so for any um p.m. out there or a systems integrator that's looking to integrate face onto a system or a platform there's a business case that needs to be done to to um look at whether it makes sense for you to develop a piece of software that that can be reused as i mentioned a bit earlier what in face that we use the term units of conformance for for those software components that that that are both verified and then certified to be built to the face technical standard um and a system can be made up of units of conformance of software applications that all have been certified to the face technical standard or or some that have and some that haven't or or perhaps in a larger system you may have some subsystems that have no face components on them but so so there's no there's no requirement for face uh to you know for your system or your platform to have all face conformance software it really is up to the p.m.s to do that to develop that business case for um whether to to integrate a piece of software that's built to the face standard um so so the bottom line here is uh face does not certify systems or subsystems or or platforms um it face certifies units of conformance and it's up to uh integrators and system developers to to identify which of those components will be and which won't be built to the to to the face standard right here's one that we heard uh especially early on uh you know a lot of um you know existing you know program manager says hey this doesn't apply to me this is just for future systems uh the the face approach uh applies to both if you are a fresh start which we have a couple on the army side in the uh that we've been recently working on you can design in uh the face infrastructure in the computing environment from the very beginning where you can take advantage of uh use and reuse of face units of conformance with the enduring fleet you can attack this incrementally uh you don't have to have uh you know an upgrade focus strictly on incorporating face into your uh platform you can do this by setting up either full or partial face infrastructures this can be you know if you've got a new aircraft survivability equipment and you've got a little bit of um excess resources you can you can set up a face infrastructure there with the ability to host uocs um maybe maybe you're you know upgrading a mission processor that that would be uh you know good um another thing if you could have a adjunct mission processor where you have a face infrastructure uh anytime that you have resourcing uh extra resource capabilities where you can incorporate a partial infrastructure and when I say a partial infrastructure a lot of these uocs don't have dependencies on all five of the uh of the segments so you may have a pcs component that really only needs uh you know the the transport and then the operating system so you can kind of look at this in a case by case basis and you can incrementally you know grow to it a few years ago there was uh you know a few of us um at Joe Carter's direction uh we looked at different integration patterns and how you could go about setting up these partial that would be able to grow to full you know face infrastructures and the benefit if obviously if you if you bake it in to the fresh starts it's going to be there from the beginning and if the enduring fleet has those infrastructures established you can share uh resources you can share develop capabilities and it really helps the enduring fleet address obsolescence issues and a lot of things that was previously solved with a hardware with a box can now be addressed uh as a software implemented capability and that could be only one of those extra resources that you have that saves you know weight that saves maintenance in the future and what we're really trying to do is provide more capabilities with cost avoidance where we can extend our money further and and having the legacy platforms enduring fleet play with the future fleet really helps extend that limited funding that we live experience over the last several years. Okay another another common face misconception is that face either somehow guarantees or inhibits the functionality of the software that I'm developing so you know this is not a technical discussion but its core face looks to verify that the software interfaces that have been developed to the face technical standard and so your your software application that you're developing can complete the face verification process that does the technical look at your software and verifies that it was built in accordance with the face technical standard but when you actually you know run your your your your software that adds two plus two face is not going to not going to do anything in in its what as it as it looks to there's nothing in the face conformance process that's going to guarantee that your software when it adds two plus two equals four so it can be it doesn't relieve the PM or the systems integrator of doing those software systems engineering processes to ensure functionality and performance and so so face is not going to ensure your your your software performs its capabilities but at the same time there's nothing in face that that inherently is going to inhibit it from from from doing its mission the so you know the bottom line is things like their worthiness while there's a lot of overlap and benefit from developing your software to the face technical standard and there's folks within the consortium that are specifically looking at something like that to to look at how we can use artifacts developed for the face standard to support something like airworthiness face itself is not going to either guarantee or inhibit a technical aspect like airworthiness certification oh right we've heard this a lot you know face just the nature of it requires unlimited data rights this is absolutely not true there's really no difference with acquiring face acquiring software that addresses face requirements software being you know face conformant in any other software acquisition so what we what we want to focus on is going after the data rights that we need and typically those are around the interfaces we want to use open interfaces so the face approach itself does not require any specific data right strategy and the fact is the government can afford all the data rights from industry and if we could afford them we probably wouldn't know how to to use it and to modify that that's why we rely on industry because they're the experts so what we're trying to do with the the the data right strategy is really focus on open interfaces where we're not locked in to a particular vendor where we can open up you know competition and um there there's benefits you know across the board you know for that we want to promote innovation by increasing competition and when we do that you know if you're a software supplier you have to be encouraged by that because we just open up the market for you and instead of having to go directly you know with one of these you know legacy enduring fleet you know prime contractors and going that way individually to get on you can actually develop you know a software capability and if it's the best to breed we want to take it and we want to put it across the platforms you can keep all your intellectual property on that all we're really asking for and we're pushing for is we're not stuck you know with that we can replace it if another one comes up and we do that you know with requiring open interfaces built off open consensus based standards. Quickly on another misconception is that FACE is somehow cost or schedule prohibitive I think Tyler in the brief rate before ours mentioned the fact that that several years ago I think there was a lot more concern about FACE and building a piece of software or a system with FACE components but over time I think folks have demonstrated that there's nothing specifically about FACE that would would would be cost or schedule prohibitive in the development of a piece of aviation software and in fact there's there's a number of benefits to support things like platform software platform lines and common reuse even within organizations that that the that the FACE approach actually has benefits to to if not improve your your ability to deliver within cost and on schedule it doesn't appreciably negatively impact it. Okay the the last misconception we're going to talk about today is you know the concept if the FACE approach guarantees or prevents airworthiness qualification that that is not true FACE does not get you airworthiness qualification nor does it prevent what we what we found and we've looked at this a lot of times if a capability enabled by software has been part of a system certification they have you know established airworthiness you know documentation what we found is they're able to reuse a lot of that documentation and take you know their CVM submittal and map to that so it's it's not they're definitely not mutually exclusive but but they don't negatively impact you know each other and there was a a paper written several years ago it was actually a 2014 you know that came out of MRDEC at the time DevCon Avmic called a developer's requirements guide for airworthy reusable FACE UOC's that's actually publicly available if anybody would like a copy of that if you would just drop me an email or let Sally know she can pass it on to me be happy to provide you a copy of that I will let you know there has been another paper written focused on integrators and you know their guide for integrating airworthy reusable FACE you know UOC's unfortunately that has not been distro a publicly released yet but if you have the right credentials I can definitely put you in contact with the author if you're interested and if he can you release it you know to you he'd be happy to do that with a contingency that you review it and give comments back to to improve that paper so we're going to talk a little bit about value to the government and these are kind of the things that's important you know to the government we kind of think of them as big blocks you know they overlap you know some obviously you got policies and mandates for ability time to field you know capabilities and then we're used to extend the money I don't have a slide on the NDAA's but what we've seen you know with the NDAA specifically in the FY17 there was a big push for MOSA in major weapon systems and they actually called out major system interfaces so it was almost like they were focused on you know making sure that they were open where we would have interoperability between systems this year in 21 when the NDAA came out they took that down the level and they added modular system interfaces and were very interested in going after the software rights you know for those the DOD has plans that hadn't been formalized yet but it was mentioned in the NDAA to have interface repositories where they can be you know tested out and demonstrated you know to prove you know that they're open and can be you know reusable and then the next slide is going to talk a little bit more about MOSA when we talk not not quite ready yet so affordability you know we've heard it a lot we have to do more with less and the way we do that we promote competition we have to reuse across platforms we can't we can't purchase these capabilities from scratch for every platform we have to as Joe mentioned in his charts we have to extend our money so program A has to get maybe the first two capabilities and program B supplements that to get the third and program C supplements that to get the fourth and and Dr. Whitken you know really pointed out a high priority for the government is to get these capabilities to the field faster and we're trying to reduce integration time and if anybody's been in a technical briefing you understand that the restrictions are really on the software developer to benefit the integrators and that's really what we're you know focused on focused on as far as capabilities go we only get new and enhanced capabilities to our war fighters to maintain our battlefield superiority I understand that's kind of a you know military view you can also you know expand that we we want to provide it to the commercial aircraft you know also these capabilities would be used across you know DoD and commercial and then we'd already mentioned it you know the reuse and how important you know that is with limited funding to be able to provide these capabilities across the air for aircraft. Next slide. So I want to talk a little bit more about MOSA a little bit more detail so we were very encouraged two years ago tri-services memo came out and it was actually a question around lunchtime and I was I was excited about that it's good to get that information out so the secretaries of all the service all three services put out MOSA for our weapon system is a war fighting imperative and they actually cited several open standards face SOSA victory and they talked about how important it is that this that we continue developing these standards and vital for our success and follow on to that each of the services has really taken that and ran with it so the Navy came out with guidance very shortly after that couple months after that the Army acquisition executive and I'm more familiar you know with that and then what followed after that came and issued you know guidance on implementing you know MOSA and then the Air Force also last summer had more guidance on implementing MOSA. Pull that thread a little bit I've got a lot of visibility and what's happened on the Army side so the AAU memo they actually empowered ASALT office of the chief system engineer to direct MOSA into PEOs and into PMs and that guidance actually came out last summer June 10th and then Joe mentioned the MOSA transformation effort that we're undergoing at PEO aviation we are aligned with that guidance and PEO aviation to address that it is aligned with the five MOSA principles and which is you know really good you know for the face approach because we bake that in from the beginning so that is a open standard that really supports all these MOSA initiatives and the guidance that we see coming out. Next slide. So Joe's already briefed a version of this slide the big takeaway face approach addresses all five MOSA principles and I wanted to highlight just a couple of things in the establishing you know environment there is training available there's more training you know on the way and then we also have titleable contract language you know Brandon and I support the business working group another piece that we have is the face contract guide and that actually has recommended language that we you know have to put to include face requirements in solicitations so I think Joe did a good job covering that so I won't spend any more time on this Joe. Okay just real quick you know Jason talked a bit about the the value of proposition for for the government participants in the face consortium certainly you can you can just look at the the member list of the consortium and see that industry sees value also in the face approach so not only will they be able to support the government's requirements for things like MOSA requirements and face specific requirements on on contract but there's also an opportunity in industry to increase competitive opportunities if you have the latest and greatest technology with face you in the future may have a better chance of getting that fielded on a platform than you would under the legacy approach for for developing aviation software and bottom line is companies are seeing an ability to improve shareholder stakeholder value from from following the face approach. Face has been mentioned the intent there is not to limit it to the future fleet but their approach supports fielding face applications on both the enduring fleet and the future fleet so for the future fleet obviously all of these things we've talked about are being designed in things like enabling a more rapid technology insertion to be able to increase the pace at which we field capabilities and reducing the the cost and complexity in the bottom line is as we look forward over the next decades to be able to keep pace with our adversaries by fielding in a cost efficient way the most current capabilities for the warfighter. So applicability to enduring fleet we've we've pretty much covered this in the misconceptions but there's a distinct benefit of the enduring fleet of establishing a full or partial face infrastructure where we can utilize you know the space you see that's already been developed or develop their own where they can you know be pushed forward to the other platforms. We've also kind of covered this too you know data rights the government and industry are trying to you know establish a great relationship for the government we don't really need your IP we will open interfaces we're not locked in a specific vendor and the government's really opening up the market for these software suppliers to play in areas that they haven't been able to play with before so it's it's really a win-win for the government and industry. All right so Sally I think we're coming in right on schedule here but we just wanted to say thank you very much for your time and attention today the the face business guide is is it's publicly available is for folks that are interested in doing a deeper dive into the why behind face the the value of face to both government and industry participants of the consortium that's a great place to start to to get a better understanding of of the face approach so if anybody's got any questions certainly feel free to reach out to to me or to Jason or you know any of the other leadership of the face consortium so again thank you for your time and we'll stand by for for any questions. Great well and as you said Brendan and Jason both thank you so much clearly you have a tremendous amount of material that you shared here today the really good news is this is all going to get posted on again the open group websites both face and sosa as well as the expo tim 2021 that way it can be easily accessed and shared with everybody we are low on time we do want to move over to our also another cool session that we have coming from our sosa team so any incoming questions we'll funnel those over to you if not today tomorrow and let you reply back to folks accordingly so thank you both for your time thank you for the presentation and thank you for a whole lot of material that I know is going to be just well received and has been here already but I appreciate that so I will bid you adieu and welcome our next group thank you Brendan again and Jason appreciate it so as you can tell we are also very excited to be bringing you this session sosa business executive overview benefits and adoption of this new standard today we not only have our three co-presenters Mike Orlowski Valerie Andrew and Roy Keeler I also happen to rope in on the phone Patrick Collier and for those of you that may or may not be familiar with Patrick actually I'm going to sneak a peek over here at my notes Patrick is a senior open systems engineer at Aspen consulting he's also a sosa member who has been heavily involved with the conformance piece so if in fact when Mike and Valerie and Roy move through their presentation if in fact we do have time at the very end for some questions and they refer to conformance I may tap Patrick to speak up again hoping that we all have a good audio going forward also when they do wrap up this session I would like to ask you to stick around for another 60 seconds we do have further contact information for you and some information about the September 14th open group face uh I was going to say sosa forgive me the open group face expo and Tim which is now slated for September 14th in Huntsville so just a quick save the date on that one but in the meantime Mike I see you're online I want to double check uh how is your mic are you good to go sir I believe I'm good to go okay you hear me perfect Valerie and you're on with good audio ma'am I am very good and Mr. Keeler Roy are you on as well sir yes Sally I am hot dog all right thanks that's always good news and Mike I'm going to turn it over to you and go on mute and to the three of you please let us know what's up okay thank you Sally and uh good good afternoon thank you for attending our presentation today I'm Mike Carlos game the sosa business working group chair and my co-president presenters are Roy Keeler who's our business architecture subcommittee chair and Valerie Andrew who's our outreach chair you'll hear from both Valerie and Roy a little bit later this past year has been a challenge and both Roy and Valerie adapted their subcommittees to operate in this virtual mode and continue to deliver the results that you'll be seeing in the presentation I also we want to extend our thank you to our Tim host Navair PMA 209 along with the coordination by the open group and they do have to call out a special thank you to Sally who work closely with us to essentially make this presentation a reality bit of orientation so sosa is the sensor open system architecture work consortium within the open group and sosa is focused on the sensor domains of radar electronic or electro optical infrared electronic warfare and communication so if we go to the next slide see and Sally I seem to be having trouble moving the slide you know my forward oh there we go I think we just there we go just checking thank you so much sir okay sosa in a nutshell so okay so our collaborative approach we address both the technical and business aspects of the the four domains or five domains that that we just mentioned the technical aspects are focused on the set of rules for the the reference architecture for sosa and so those are those rules are organized in the sosa technical standard our current publicly available document is essentially the snapshot three document that can be found on the open group website under the sosa consortium so you go there and it'll show you how to to essentially register and download the document as you've heard previously today the version one technical standard will be released very soon our presentation today we're focused on the the business aspects and so the the business aspects essentially describe the what I'd say is the collaborative ecosystem around the sosa standard so we have the technical aspects but more are equally important we have the business aspects that essentially describe how we balance the needs and constraints of the acquirer the supplier and the technologist and how they operate with the standard the the standard also addresses the fact that we're operating now and certainly in accelerating evolution of today's environment so things are changing rapidly so the standard has to end the business ecosystem has to be flexible enough to to react to to this so if we go to let me get the next slide let's see I seem to have lost my slide control there we go there we go so advantages disadvantages so the transition to digital engineering is underway as was mentioned earlier the sosa reference architecture supports this transition so you can look through and we call it a number of benefits and advantages but we employ essentially a standardized composition and set of interfaces to essentially facilitate the commonality reuse and technology insertion into the the sensor systems we recognize that full lifecycle so the design development integration and support and you can see from both the government perspective and the the industry perspective that this approach has a variety of of benefits to both the the acquirer the supplier and the the technologist so from the acquire perspective a tech insertion that that will occur as new capabilities come out as other capabilities become obsolete from a vendor or industry perspective the modular decomposition helps us structure what we're providing the interfaces are known and tested and then we have the standard space tooling to to support this so sosa really addresses that that whole business ecosystem regard surrounding the the standard to to make it successful so if we go to let me to the next slide so we built on a set of existing standards and so ilia mentioned earlier that we're leveraging this very large body of open standards that that are out there and these standards are both government-based and industry-based standards so we've talked about face and the previous presentation you've heard about seamos and host earlier but we also leverage many other standards so the vita standards say SAE standards and this diagram attempts to sort of organize that large body of standards that that were applying and so again i'd refer you to snapshot three to see that significant body of work that's been accomplished to date there's contact information on the the website and then at the end of this presentation as you look at this and you have questions you can also reach out to us and the team right now is certainly working in overdrive to publish technical standard 1.0 this year and let me go to so consortium membership so i think we mentioned the around 100 members so we have nine sponsor level members of of sosa we have 13 principal members and 89 associate members and as the word of sosa continues to to to get out there we are continuing to to grow we encourage folks to join and be or participate in the standard the technical standard and the business products you'll hear a little bit later these are all developed from essentially the consortium on membership so the the membership essentially provides both technical and business subject matter experts to participate within the working groups and subcommittees to develop the the products that that you'll be seeing the whole consortium meets nominally five to six times per year normally in normal times it was in person in various spots throughout the continental us but this year we've adapted and we've been meeting in a virtual format and i will do a shout out thank you to Sharon and the open group because they invest a significant coordination amount of coordination time to enable a successful and organized meeting but we do have a large body of members to draw from and encourage folks to join and help us continue to evolve the products our social organization is set up around essentially an advisory board steering committee we have two working groups and two standing committees the technical working group is responsible for the the technical standard business group is essentially the business processes and value proposition as i was reviewing these slides earlier today realized we did have one typo slip through roi keeler is actually our business architecture subcommittee lead and as you heard earlier patrick is our conformance lead so the conformance standing committee is focused on essentially the conformance program to essentially govern the use of conformance to the social technical standard our architecture standing committee addresses the conceptual and logical integrity of the direct reference architecture and essentially the the advisory board is sort of those senior experts that advise the steering committee on that sort of the the bigger picture is to the how the standard fits within the larger domain now roi and valery will address the essentially business architecture conformance and significant body of resources and outreach that's occurring and so roi is with adling technologies he's our business architecture subcommittee lead and i'll now turn it over to roi to to continue on okay well thank you mike i appreciate that so as michael was saying we are responsible for developing navigation guides for the soza consortium to do a business acquisition and suppliers and there are several pieces of that one is the business guide and that is in draft form now we're very close to getting that completed the conformance program i'll talk a little bit more about that as we move through the presentation conformance program is well under its way as you can imagine with all the different stakeholders within the organization conformance is a is a big a big lift for everybody takes a lot of coordination among all the various uh standing committees then we have the soza registry we'll talk a little bit about the registry how it fits into the whole scheme of the acquisition guide and then of course the acquisition guide in itself and how products can be procured and how they can be specified that meet the soza technical standard and then valery will will talk about the marketing guidelines and how that pertains to the overall business guide so what is the business guide well it shows you what our soza value proposition is you've heard throughout all today's presentations and and even with admiral peters opening comments of the value that face brings to the community well we are doing the same thing with soza we're bringing value not only to the government but also hopefully to the industries that support the soza standard and are implementing soza soza compliant products so within all of these guides and models that we are providing as i mentioned we have the business guide the acquisition guide this hooks into the technical standard and then we have also the conformance policy that ties all of that together okay there we go okay so the conformance program so um the conformance program provides all of these things that you see here and as you can imagine it's a pretty complex process for conformance one of the things about conformance is it's not going to be implemented all in one shot formance is a conformance is going to be phased in and that's going to depend on the maturity of the technical standard as more things become implemented in the technical standard the conformance program will expand with that now we don't know how long that's going to take we don't know in what what the sequence will be and as i said it will be guided by the technical standard so we're also taking into account what types of products that our suppliers will be building to go into through conformance so we're now soliciting information from the supplier community and from the user community to know where they want to go with with their products so we can then tailor the conformance policy to meet those product demands we're also working on developing the test tools because we do need an extensive set of test tools for the conformance program and we're actively engaged with industry to let us know what they will be developing for conformance another part of that is the verification authorities so we've put together the verification matrix guide and now we're we're vetting and we're talking to organizations to be verification authorities for soza compliant or soza aligned hardware this process can be many different entities it could be a lab it can be a command or it can be a private supplier of systems so we're working out all of the different formats for conformance so at a very high level we have soza verification authorities they comply to or submit their products to the verification authority they either get a pass or fail whether their soza compliant or not if they're if they pass they're certified and then they're put into the soza registered for a soza certified product so these certified products will be are actually called procurable units and we'll talk a little bit about that later on in the in the presentation but this is kind of an overview of how the certification process is designed to work so um what does the let's move on to the acquisition guide here a little bit what does the acquisition guide provide for you well it addresses thing as we mentioned conformance it addresses things like technical data rights on both sides on the procurement side and on the supplier side we also give examples on how to write a statement of work where that's going to impact the supplier and how it is response how you respond to those questions or those requirements coming out of the procurement agencies and it also provides some evaluations for awards so the procurement managers can now look at these responses that come in and then evaluate those responses as how they fit into the soza standard and again you're going to hear this throughout the presentation and throughout soza the benefits that soza brings we're really trying to knock down the time to market so we can get new and exciting products out into the out into the warfighter and out into the field we want to bring down the costs for both the suppliers and the procurers and we want compatibility we want to we want to eliminate as much as we can vendor lock on certain systems or on systems and open up the competition so these are all key points and all key benefits that we look at when we're writing and when we're developing the soza acquisition guide so what does the acquisition flow look like well this is the operational resource or resource pardon me flow diagram out of the DOE DAF and when you look at this you notice that right off where it's rather open as far as definitions of who these various entities are when you look at an acquirer that's just an organization that's going to want to purchase a procurable unit that's conformant to the soza technical standard and you might ask what is a procurable unit well procurable unit is a product that's define is defined as a product that's been comprised of a one or more certified soza compliant sensor components so the acquirer is the one going out and getting the procurable units now this could be a government entity this could be another systems integrator we left that the definition of what an acquirer is wide open same thing with a supplier this is an organization that's supplying sensors that are aligned with the soza technical standard it can be many different types of suppliers it could be a board supplier it could be a system level supplier we don't define that as well then as we mentioned the conformance program there's there's the verification authority and the certification for authority within the conformance program products are submitted to the conformance program they are either passed as conformant or not and then once they are and they have certification and verification results those are put into the soza registry now the soza registry is a catalog that's going that is maintained by the open group that contains all of the information all of the metadata that you would need to make a selection for a soza compliant or aligned product we're trying to make this as transparent and as easy as we can for the user one thing I will I will mention is there are resources that are going to have to be supplied by both the acquirer and the supplier in this process a product is going to have to go through the conformance program there is going to be a resource required to be able to do that and the same thing on the supplier program you're going to have to look at providing budget for or on the acquirer pardon me on the acquirer side for these additional standards that have to be implemented so there there is some cost associated with this and as far as maintenance is concerned as well and that is the overall view of the soza acquisition guide we should be putting this out we're in draft form now we're making very good progress as Michael indicated and if you have any questions please feel free to let me know and I believe that's my last slide with that I'll turn it over to Valerie Andrews Valerie thank you Roy so my role as Roy and Mike mentioned is it's the chair of the outreach I have a co-chair Gina Peter who is with Pentak and I wouldn't be able to accomplish as much as we do without her so we also have a very active team of people who help out so Roy's side handles the business and acquisition collateral resource assets and our team handles the outreach and marketing promotional anything to do with getting the word out basically next slide please so as you've probably already seen we do have a website we have lots of good plans for it this coming year we plan to update it and improve it face has set the stage for us and they're getting ready to improve their website and and release it into the wild and we're going to leverage the work that they did to make our similar kind of improvements we have we started a newsletter this year actually we're getting we're collecting materials to do the second one if you want to sign up for it you can go to the website and put your name in we include member news releases articles links to webinars trade shows when they come back on board and and a variety of different resources both technical and and business related the to that end there are there's there's quite a quite a lot of activity going on we also do collateral and show kits as we refer to them again once face-to-face kicks back in you'll see some of those we provide member placards for all of the members that are attending designated events we do news conferences where it makes sense we bring in experts either tied directly to the show audience or to our membership to help get the word out the as Ilya mentioned before there are plug fests that's more driven by the technical team but we do try to help get the word out the trade shows we have the TSOA ID which occurred in January we attempted to have one two or three different occasions last year and that didn't happen so hopefully that'll pick up this year as well we also contribute speakers to webinars and symposium events we've done some recently and there are quite a few member driven webinars we as a matter of fact just did one on conformance with the help of Patrick Collier that Sally mentioned and the manager of conformance at the open group Sue Harper the we are also going to be having a webinar in April that will talk to the the differences and similarities and how the variety of different standards that have been talked about today work together and how they how they fit together so other assets we have is YouTube tutorials that we're just getting started on that we do have a LinkedIn page you're free to follow us we try to keep up with news plugs on there we're also launching a Wikipedia page the thing I skipped over on the previous slide was the marketing guidelines and Mike touched on that what we include in there are things like how the proper usage of the SOSA logo and the trademark how to incorporate it into your marketing materials and we also provide guidelines to to different kinds of opportunities we have had the media reach out to us and offer special discounts to the members so all of that is included with the marketing guidelines next slide please these are just a couple examples of assets one of them was actually the infographic that Mike showed earlier it's uh hasn't passed its final call for consensus within the committee which happens at the at the BWG level but that came out of the outreach committee the we have a trifold that's a membership piece that can be handed out you can see a sample of it on the left and there's an executive overview of the what the what SOSA is it's a very top level I don't know I think it's about 15 slides that talks to SOSA for uh for executives who are interested in finding out more about SOSA and why they need to pay more attention to it next slide please so again it has been mentioned earlier we are forging forward with version 1.0 there's still quite a bit of work being done within committees but the goal is to release it sometime this summer the other goal that we have as as we've also mentioned we do have meetings that are roughly every every other month they've gone virtual over the past year and we hope to bring it back to face to face and with any luck we might be able to do it in August which is when my company is actually slated to to host so we're very hopeful that that can happen in person next slide please so I invite any and all of you to join us if you would like to contribute to the business working group at the top level we meet once a week on Mondays and then we have the two subcommittees outreach and conformance and we meet every other week on Tuesday afternoons sharing that time slot so it's it's once twice a month roughly that they meet and on the next slide you'll find our contact information we encourage you to reach out to us ask any questions that you have if you want to join if you have a great idea that you want to contribute by all means reach out to us so thank you for your time I am I've completed the the roster thank you Valerie thank you Mike and thank you Roy I'm not seeing a great deal of questions come in the window but I will tell you that as you all three know and Patrick who is joining us by phone kind of standing by we have been inviting our attendees to send me questions especially those that don't want to necessarily reveal who they might be on the open Q&A window so just be aware that I may be shooting some questions over in your direction in the next day or so in the meantime as all of our guests can see here are the contact information for the the SOSA team here that just presented that session don't be shy please feel free these are very involved folks with SOSA and and just have a plethora of information to share so again don't hesitate to reach out to Mike or Valerie or Roy the open group SOSA consortium of course always an open door ladies and gentlemen I'll say goodbye and before to all of our guests before we say goodbye to you just wanted to show this slide very quickly as mentioned earlier all three websites the opengroup.org face and SOSA and ExpoTim2021.com will have these presentations up as well as the videos and then again there is my contact information below feel free reach out to me at any time and then our final slide before I bid you all goodbye I wanted to again share with you to save the date for September 14th this will be the open group face consortia technical interchange meeting and Expo crossing our fingers it will be live and in person it should be we certainly hope that's going to be the case at the Vaughan Brown Center in Huntsville Alabama and to that I am excited to say PEO Aviation will be hosting that Mr. Joe Carter Ms. Alicia Taylor and a whole vast team that will be on board for that other than that ladies and gentlemen thank you for taking your time for staying with us for enjoying it again a great deal of information about the open group face and consortia and open standards open architecture and open innovation I will bid you all a wonderful evening take care thank you Sally my pleasure thank you all