Today we're at Pride Portland. We are here with the beautiful cherry. Hi, how you doing today? I'm well How are you? I'm fine. Great. How is pride today? Oh girl pride. Okay, so pride is uh, pride's awesome But uh, this is definitely like my fourth gig this week and I didn't I got like an hour sleep I'm with it though. I'm ready. I'm ready to party because It's been an emotional I would say kind of Community right now. I would think it's very very emotional. So how do you think that pride today can help? Kind of lift us out of that. Well, I think that um, it's it's good because it's reminding people that you know Even after this this horrible tragedy like it's reminding people that we need like this is what we need the most We need to stand strong and we need to be together and we need to Make sure that we are not letting people like not letting situations like that stop us in our tracks And make sure that we remember like remember why we're celebrating pride like the Stonewall riots and you know All the people who came before us to make sure that we have our rights Like the way that we do today, and we're still fighting but still like the just making sure that we're Lifted spirits. Yeah, like lifted spirits is definitely like that's this is this is gonna bring us out of that slump It everybody had a really hard week And I think it's time that we all let it go and just enjoy our our celebration Bring optimism is what you're saying. Correct. Bring it up Yeah, up with optimism. So what are you doing today? I'll be judging these lovely floats that are gonna be coming by I Got my judging face on I'm ready. I'm gonna. Uh, I'm gonna read these floats up and down and may that may the best float win We're here with Shauna Ray today at Pride Portland Shauna. How are you? I'm fabulous. How are you? I'm doing well Thank you so much. So how are you feeling today? Amazing amazing. We did a show last night. It sticks. It was called pride unfiltered So this is the result of last night as well. So you must have not gotten that much sleep No, because I live in the Lewiston Auburn area.  So what are you looking for today in terms of the judging floats? I want to see originality and fun Fun fun fun. I want it to be what it's what we're all about. Are you excited to judge? Yeah What are you looking for? All the colors So you want to see a lot of color? Yeah Big round of applause everybody Starting over here, and it's cherry lemonade Celebrate another year Oh In southern Maine with pride for them having had the honor to perform drag antics all over the country cherry's home I'm happy to be home with the lgbt community which she grew up cherry Travel both space and time and hey give it up for the good humor man, by the way Having ice cream tell them when they play the music they're out SpongeBob pop You know, he's one of our great judges today judging all of the floats and all the marchers today Some of Jack's hobbies are dancing lip-syncing and flirting while being fancy Me too Jack Here we have Sean Aray Sean Aray Has been playing the art and female illusion for more than two decades And has seen done and large many things that are derby throughout the years For alter ego as a stylist in Lewiston Sean Aray's won a few titles over the years including Miss Andrew Spoggan, Miss Central Maine, Miss Southern Maine Bride Miss Aids Awareness Increasing age awareness for passion and she works in the brandy team on his center Here for Sean Aray Ladies and gentlemen, the Development Director, Development Director in Quality Name The only Executive Director of Emerge Name All right, by Portland Marshall Betsy Park, Portland Public High Schools of Portland And was the founding member of the Southern Maine Gay, Lesbian and Straight Education Network You know, it's very much for all the hard work you've done over the years. Thank you. All right, right behind them is the GLBTQ legal advocates and defenders Through their strategic litigation public policy advocacy and education The legal advocates and defenders works in New England and nationally to create a just society free of discrimination Based on gender identity and expression HIV status and sexual orientation. So a big round of applause for these folks We have the first first congressional church They're open and affirming preservation of the United Church of Christ inviting into their common life for all persons regardless of race Culture or sexual orientation Thank you guys Our supporters are all waiting to fly flags and banners We have the first congressional church of South Portland House folks walking with us today enjoying the sunshine. Thanks for coming out today To me, they're not done Just a little more We want to go over and open that door Oh my God, wind up on the floor Well, I had no idea you didn't I hope I can do that I know, cheers All right, I can't do that No, I can't do that No, I can't do that Certainly can't do that My hips don't move like that You're right, God Hey, loud and proud It was the first ever ban to march in Portland Pride in 2014 You want information on these guys, just go to loudandproudany.com We're going to get a loud and proudest You should hang out back here on the stage with us, huh? For the Constitution, especially, it's guaranteed a free seat Separation of church and state and freedom for all without dissemination Portland Public Library Raiders, everyone included, everyone That's right And they have all of the old videos from video for it now I know it Imagine City Center, the largest HIV aid services organization Providing direct support for people living with HIV As well as HIV and hepatitis C testing And prevention services I got this one, Greg Uh-huh Next It's case number 31 It's a selfie time Allurean Blight Selfie I want you to ever listen to them again That's right, yes I still love those guys Thanks for being a sponsor of Pride Portland They're okay They're okay By the way, Blight, I think your question will be down in the park a little later That's right, there I'm seeing them down at the park Blight is proud to be a productive sponsor of Pride Oh, they grabbed other cars I know, look at that Hey, and we have beads I guess cell phones have to be refrigerated That is a big ol' track for some cell phones Right Well, it's kind of hot out here in the sun, you know Derby Association and one of the hundreds of leagues across the nation That have embraced the quick-rowing sport of roller derby It's starting June 26th And our next game is September 17th Which is, by the way, five days after my birthday In case you want to shop There you go That's on Friday, right? It's a Saturday We have some nice folks joining us today from the Animal Refuge League of Pride Portland They provide temporary care and shelter for stray, abandoned, confiscated and relinquished animals And they're really taking almost 4,000 stray animals every single year They're committed to giving the best possible care And of course, hey, you can maybe adopt one of these animals in the car right now Life-size key There's not enough kitty litter in the world Fred joining us today Coming up for a big round of applause You know, these folks have been in the parade Each and every year supporting all the efforts of Portland Pride They provide behavioral health and education services For about 7,500 children, adults and families throughout May They're programs that include outpatient and community services Education and residential treatment For people with autism, developmental disabilities and mental health challenges We have the City of Portland Public Health You guys over on India Street Our cue cards have kind of gotten shuffled a little bit So it's kind of like, you know, 52 pickup Well, we know this is goodwill Well, yes India Street The store is goodwill, operates 25 group role Hovering centers in May Goodwill has 100 job openings listed online right now At goodwillnne.org The social club that encourages open-mindedness, diversity And the right to an old criminal life Without discrimination, judgment or prosecution You can get more info at maingreens.org Gays A big round of applause for the maingreens Welcome This year, Bank of America is a company That recognizes the potential of every employee By actively encouraging a diverse and inclusive workplace In thought, style, sexual orientation, gender identity Ethnicity, culture and experience Big round of applause for Bank of America Just a minute Next, it's Man! Thank you, our grand panel of judges Welcome to the Boston Human Rights Center of Maine For the Pride Film Festival, Fridays in October We have the Unitarian Church from Waterville joining us as well Just down the street Girls seriously put the power in Southern Maine, the University of everyone Classes, I'm almost graduating Today, USM does have pride That's right, University of Southern Maine And a very gay colored car That's not just for the parade, guys That's every day That's commitment to the community You know, Lori, we have the Cathedral Church of St. Luke Joining us today Episcopal Cathedral of Maine Finds the complexities of pain assistance Across the continents of history The point is Hands out the window Take your pocket if you lost a check Hey, Piper George, by the way Is a retirement community that welcomes diversity Among its residents And among its community outreach Next, it's great important for them To transfer real property To embrace the diverse culture And remember, it's required to get back to the community In many ways To make great important an area A great place to work and live You know, and Lori, if you were wondering Why you don't see me on TV anymore It's because I am part of this group now And it's also a big round of applause For our luxurious and strong organization Big round of applause Max is hot, 104.7 Business partners, partners are here with dignity And respect like Oh, my God, they stole a shopping cart How'd you get the wheels to move? Some special teeth? I'm the LGBTQ intersex Intersex Oh, all right To move equality forward Big round of applause For these folks, they come out every year You have nothing to do with it That's right We could Well, it doesn't hurt Right? I'm gonna have to get somebody over here Come over here So that I don't make my own conclusions As to what a rainbow baller is Why don't you just tell us An alternate call we put on for LGBT youth To end up at the University of Miami For a future socialist society Services, Maine's deaf community They too fight for equality and acceptance And employment, education And all that life has to offer We stand with you in our shared strengths Thank you for providing communication Access to deaf people at Pride events DJ Marin is a family crisis services So a summer in Cumberland, Maine They really helped a lot of folks out there Provide safe and exceptional services To all people affected by domestic violence Data diversity, disability, sexual orientation Gender, age, and you know They help a lot of people out there So big round of applause Thanks for joining us today It's the Portland Vet Center Providing read just the counseling For combat veterans Returning, we also provide counseling For military sexual trauma survivors Couple counseling and bereavement services For banner members of service men Who are passed in the line of duty And we have the Freedom from Religion Foundation Joining us today They're not their banner They are the National Freedom from Religion Foundation Organization They support the separation Of religion and government By imposing Evanguizing young vulnerable children Public conduct is still rare in public schools And government payment To fund freedom of services Evergreen home performance Proud to provide energy efficiency Audits, levels, and insulation To help the LGBTQIA homeowners Achieve year-round comfort More bubbles It could have changed It supports the education about LGBTQ Plus rights and experiences They're doing a cute, distinctive Postal man campuses Nice car I don't know if they've been Guardable to ice up at the sun You know, they also have new campuses In here in Morocco And a robust offering of degrees And certificate programs online Classes in Morocco, right? It's property by design It's going to be their rights For here in Maine abroad Since 1994 They are not throwing hot puppies They're not going to throw me A nice coffee or something A nice coffee? In the United Church of Christ It's a gay party race I know, this is great All the churches are drawing this I like the umbrellas That's a nice touch That's great That's great And street hugs Some selfies come on The Great Street Mission Is finally in 2006 It's an outreach street minister For pastors working with homeless And marginalized in downtown Portland The VA Main Healthcare Committed to a diverse workforce Out of this sensible, high-performing organization That delivers the best service to our veterans The lesbian, gay, bisexual, and transgender community Is an integral aspect of human diversity VA Main Healthcare System They serve all who have served Thank you Big round of applause for these guys That will sit in your mind That's ours, everyone The parade is coming To an end here, but not before We have to talk about this You know, this is the Pride Portland River A pride, wonderful vision That will travel slowly That measures over 900 feet long Mark Chadborne, Mark Tell me a little bit about yourself And what you do with Pride Portland I am a current one of two co-chairs Of Pride Portland in 2016 I live here in Portland And I wanted to be More involved in the community So I volunteered Nice So what does Pride Week mean to you? Pride Week in a nutshell Is supposed to be a celebration of our diversity As a community That's a good way of putting it So what kind of activities Did you have this past We think you can share with us To celebrate with you Pride Portland is very proud Of having ten days of pride Not just a parade and festival But ten days of pride Which starts out with a flag raising A launch party at Grace A big dance party And then we had kayaking in Casco Bay We had trivia night We had history night At the Portland Public Library So tons of things going on So compared to last year What did you say this year ranks? The events are similar We changed some I think by the turnout today We've definitely got a much larger turnout this year And of course the tragedy in Orlando You think if influence maybe The community more wanting to come in And share in the joy I think it's definitely unified us And brought people out It's also added a little somberness To the event where you want to be respectful Of what happened But we also want to celebrate Who we are and why we're here So I think we've met that tone We've acknowledged and we've tried To give people whatever they need Closing notes, what message Would you give to Portland today? I want to just thank the community For coming out and supporting The community that we have here And I hope they have one hell of a good time Thank you so much Mark And enjoy the show I can hear them in the background starting So thank you so much Appreciate it


Since the accident in August of 2014, we've taken many steps to respond to the health and safety concerns and initiated three separate investigations. Two of those investigations, the independent panel of experts and the Chief Inspector of Mines were completed in 2015. Both concluded the same thing that the dam at Montpauly failed because of the strength and location of a layer of clay underneath the dam that was not taken into account in its original design. Both of those investigations have provided government with recommendations to prevent that sort of thing from happening again. There were seven recommendations. They were broken down into some sub-recommendations, but seven recommendations from the independent expert panel and 19 recommendations from the Chief Inspector of Mines investigation. We've committed, as you all know, to implementing all 26 of the combined recommendations. We've already made a lot of necessary changes that will help prevent an accident like what happened at Montpauly. In March 2016, we changed the Mines Act to strengthen compliance and enforcement. You remember the legislation we passed that created the authority for administrative penalties, which probably the Ministry ought to have had before that, but now at least we have it. We also, I think, importantly implemented a web-based record system that provides a lot better and easier access to the public so that they can review inspectors' reports and all of the other documentation that flows between the regulator and the mining industry. It was interesting for me after the accident happened to deal with the accusations that we were hiding things because documents weren't available. In my little ministry, there were people going through filing cabinets at three o'clock in the morning trying to find documentation that people were asking for, and it really and truly was not an issue of anybody trying to not allow the public to know what was happening in the industry between the mines and the regulator. It was a question of us having a very old and archaic filing system. In June of 2015, I appointed a Code Review Committee to determine how best to implement those seven expert panel recommendations and also the 19, later that year, the 19 recommendations from the Chief Inspector of Mines, that's the group that Naline worked on. This review was carried out by three separate committees. There's an overarching Code Review Committee chaired by the Chief Inspector of Mines, Mr. Hoffman, which included an equal number of representatives nominated by First Nations, mine labor unions, and industry. The Code actually prescribes this process for changing it. It is one of the few pieces of provincial legislation where there is a prescription written right into the legislation on how you go about changing it. So in other words, government doesn't just go and change it arbitrarily. I don't actually know if there are other pieces of legislation like that, and it requires government to work with the unions and with the mining companies to make sure that the changes that are being proposed make sense and will work well. And of course, what we did this time around was to add an opportunity for First Nations people, First Nations governments to be involved in this process. We actually sent out a request to every First Nation that has a mine operating in their traditional territory, and we sent that same request to Dave Porter from the First Nations Energy and Mining Council and said, you know, who would you recommend to be on this, to be doing this work on this panel? And names came back and I don't want to embarrass Nalene, but Nalene Moran had the highest number of recommendations. There were more people who wanted to see her put on this group than anybody else. So that was the overarching Code Review Committee. The two subcommittees that provide technical reviews for the tailing storage facilities and the health and safety sections of the Code. So we split the job of reviewing a Code and making recommendations for changes. One piece being the tailing storage facility. That piece is what we're talking about today. We're done with that. And then there's the health and safety section of the Code that they're beginning to work on now. So we're here to announce the TSF tailing storage facility portion of the Code Review. It is finished. It means that we have implemented all seven recommendations for tailing storage facilities that the independent expert panel gave us. The Code Review Committee worked for more than a year to develop these necessary changes. These changes ensure that the mining code now includes design standards for TSFs that are tailored to the particular conditions encountered in BC. The changes for TSFs and dam safety emphasize the protection of the public and the environment. Updates to the TSF portion of the mining code include, El Hoffman will go into a bit more detail here, but they include new design and operations criteria for TSFs. And El will tell you about that. There's a little more prescription in the Code today about things like factor safety than there were before. Minimum static factor safety is something that's prescribed. Requiring water balance and water management plans for TSFs, you remember at Mont Pauly, they get a lot of, it's not just the water that's produced through the mining process. It's the water that comes from the sky and the snow that comes that creates issues for mines in terms of what do you do with all that water in addition to the water that's produced by the mining process. So, requiring water balance and water management plans for TSFs is something else that we now have in the Code and requiring mines with tailing storage facilities to establish independent tailings review boards. That now is prescribed in the Code and I believe there is only one other jurisdiction in the world that prescribes those boards and that is the state of Montana. And I won't say more about that. Slide six, with these updates along with the upcoming new site characterization guidelines from the Association of Professional Engineers and Geoscientists of BC, we can now have confidence that our standards for tailing storage facilities are as good as exists anywhere in the world. I asked Mr. Hoffman before we came down here if through all of the cross jurisdictional analysis that's been done since 2014 and before that and given his understanding of how regulators do business elsewhere in Canada and the United States and in other countries whether he really believes that we do have the best process now given these changes and I'll let him answer that question but he said yes. So on that natural segue I think I'll turn it over to the Chief Inspector of Mines, Al Hoffman. Thank you Minister Bennett. Good afternoon. My name is Al Hoffman. I'm the Chief Inspector of Mines and I also chaired the Code Review Committee over the past year. As Minister Bennett mentioned our ministry has been working very hard to complete this portion of the Code Review so I'd like to take a moment to go through each of the Independent Engineers Panel seven recommendations and explain what actions our ministry has taken in response. So recommendation one implementing best available technology or BAT using a phased approach including using filtered tailings or dry stack technology which is one of the examples they used where it is appropriate. We've created new requirements to ensure Mines Act applications include alternative assessment which considers best available technology for tailings management and storage. In March of 2015 the Environmental Assessment Office as well has also required new mine projects to provide an alternative assessment which considers BAT for tailings management. Recommendation two improving corporate governance. Corporations proposing to operate a TSF should be obliged to commit to a program for tailings management which includes an audit function. And in our Code Review we've updated the requirements to ensure that all mines in BC maintain a tailings management system that includes regular system audits and the one that we're looking at and it is being currently reviewed is the one by the Mining Association of Canada towards sustainable mining programs but there's others available as well. Recommendation three expanding corporate design commitments. Future permit applications for a new TSF will have considered all technical environmental social and economic aspects of the project to support an investment decision. In our response in order to demonstrate the selection of best available technology inclusion of an alternative assessment will now be required in all Mines Act permit applications that include one or more tailings storage facility. This assessment shall provide a comparative analysis of options considering the following sustainability factors environment, society, and economics. Changes to Part 10 of the Code also require updates to the Mines Act permit application to provide a declaration of quantifiable performance objectives and include a proposed program for prediction identification and management of physical, chemical, and other risks associated with tailings storage facilities and dams. As I mentioned before the BC Environmental Assessment Office has also established additional information requirements in order to evaluate tailings management options for proposed major mines in BC. Recommendation four enhanced validation of safety and regulations of all phases of the tailings storage facility. Increasing the utilization of independent tailings review boards. We will now require all existing mines in BC with TSF to establish an independent tailings review review board by December 31, 2016. In addition the terms of reference and the proposed membership of the independent review board must be approved myself as the Chief Inspector of Mines and each mine will be required to submit an annual report that includes an overview of its independent tailings review boards activities and these will be all posted online. The report will include a summary of the reviews completed by the RTRB that year, whether the work received or reviewed rather meant that the ITRB's expectations of good practice and any conditions that compromise TSF integrity or occurrences of non-compliance with recommendations from the engineer of record. Recommendation five strengthening current regulatory operations that is determining if other tailings storage facilities have similar risks to those found at Mount Pauley. So we immediately addressed that. I as the Chief Inspector ordered mines to undertake an assessment to see if any of the dams associated with their TSFs may be at risk too. First of all an undrained sheer failure of a silt and clay foundation and whether a glacial accustry in materials or GLU as you're all familiar with similar flows of Mount Pauley exist below any of their dams. Secondly they were required to assess their water balance adequacy and outline their current and long-term water management plans and third look at filter adequacy. So that was to identify internal erosion prevention methods and other means to prevent piping and cracking through the dam. The order applied to the 38 BC mines with an operating TSF or a non-operating TSF with a dam safety classification of significant or higher. We completed our review of these assessments of October 2015 and they are all available online. Recommendation 6, improving professional practice. And the recommendation is to encourage the association of professional engineers and geosciences of BC develop guidelines that would lead to improved site characterization for tailings dams. We're very happy to announce that APIG BC has completed the review of site characterization guidelines and they will be available hopefully by mid-August. These take into account the geomorphological, hydrogeological and seismotechnonic characteristics of a site. And recommendation 7, improving dam safety guidelines. The recommendation was to develop guidelines that are tailored to the conditions encountered within TSF and BC and emphasize protection of the public. In response, the mining code now includes design standards for TSFs that are tailored to the conditions encountered here in BC and then emphasize protecting public safety including TSF requirements for the steepness of downstream slopes, a minimum static factor of safety, new seismic and flood design criteria, and define rules and responsibilities for the engineer of record including a duty to report to the regulator concerning any concerns related to safety. Existing mines in BC must immediately make any and all necessary changes to comply with the code with the following exceptions. Mine managers have until September 30th of 2016 to designate and notify the chief inspector of record with respect to the engineer of record retained by the mine and designated a TSF qualified person for safe management of all TSFs. So that's an individual who works at the mine site who will have that responsibility. Additionally, we're giving mine managers until December 31st, 2016 to have a water balance and water management plan prepared by qualified person. We'll have in place quantifiable performance objectives developed by the mines engineer of record and the TSF qualified person. There must be an ITR be established and to ensure adequate training of employees on the mine site all staff involved in the operations of the TSF or dam are trained and qualified based on the operations maintenance and surveillance manual for the TSF. In closing, through these revisions to the mining code, government has addressed 20 of the combined 26 recommendations from the independent expert panel and the chief inspector of mines report. The remaining CIM recommendations will be complete by the summer of 2017. Government is accepted is working on this also working on the 17 recommendations from the auditor general's report. I want to take this opportunity to thank all the ministry staff and the members of the code review committees, both the main code and the tailing subcommittee who have worked so hard and so diligently over the past year. I'll now turn things back over to Minister Bennett. Thank you very much, L. So we're not done overall. We still have those six recommendations from the chief inspector of mines report to implement and we have some of the recommendations from the auditor general that we'll need to do some more work on as well. I think, yeah, I should remind you that the health and safety portion of the code review is going to be ongoing and it'll continue through this year and we have a target for all the revisions to the code dealing with health and safety to be done and enforced by early 2017. The public will have an opportunity to be involved in that. Actually, there's a comment period that will go till the end of September. Like Mr. Hoffman, I just want to thank everyone who served on this code review committee and continues to serve on the code review committee and in particular the tailings technical review subcommittee. It was a lot of work but we're in, I think, a very good position now so I'm going to stop there and thank you for bearing with the presentation from Al and I and we'll take questions from the media.


Hello and welcome to yet another episode of Nicolau tries to do something helpful with his life. In this episode I talk about how I implemented a new feature in KD Plasma or almost implemented, as it's a merge request, but I'm pretty sure it will get in very soon, that is a straight up copied from Windows 11, like the visual part of it, of course the code is different, but in this case it's a minor thing that I think could improve the experience of some Plasma users, so I thought, I mean, why not? It's not like the suus or anything. So what is it? You might know that Windows 11 now has this centered start menu and since that has happened, a lot of people have started trying to customize KD Plasma to look just like that, so actually centering their kickoff icons and the task manager, which is fine, it looks good and I mean, Chrome OS did it too, so what can I bring new to the table? Now the fact is that if you try to center kickoff and the task manager, which you can do, I've done a tutorial on how to do that, when you actually open the application manager, that is kickoff, the window, which I'm going to edit in KD in live, it's at the center of kickoff and of course due to the task manager existing, kickoff won't be at the very center of the screen, which means that the application launcher dialog won't be at the center of the screen either and that's the very simple idea, what if whenever there's an application, sorry, a widget inside a panel that is very close to the horizontal or vertical center of the screen and it's so close that it could be centered and would still cover the original applet, that is, if we just move it a bit to the right, it will still cover the kickoff icon, why don't we just set a hard rule to always center it in these scenarios? So I did that. How do you even try to approach implementing something like this? Because this is actually meant to be educational content, like you learning how to contribute to projects, so how do you approach this task? Okay, firstly, it's important to know what we're dealing with here. So all the things I've talked about this a lot, all the things that you usually see in KD Plasma, that is, the kickoff, all of the widgets that when you click on them and they open up a dialog, KRunner, the sidebar on the left, when you click on Admore widgets, all of these things are a single thing, 100 hood, which is called a dialogue. This dialogue is a very general thing that uses the KD Plasma theme to draw its background and it chooses to position itself in its own code, which is of course called dialogue.C++. Now the only thing in KD Plasma that really isn't a dialogue, even tooltips are dialogue, everything except for the panel. The panel is its own thing, it's not a dialogue. But we only care about dialogues, which is already a pretty good indication. And the side of that dialogue.C++, we only care about dialogues that come out from widgets. Because if you have a tooltip, then you still want to tooltip to be close to, you know, the icon you're hovering and not in the middle of the screen, just because it's almost in the middle, what does that mean? Luckily, the dialogue has a series of classes. You just, I didn't know about them, so I just looked at the dialogue code and so that you can choose what class to give this dialogue. And one of these is indeed a applet. And you know, that means it's a dialogue that was opened by clicking a widget in the panel, which is what we want. At this point, we need to pick up the code where, which decides where to position the panel, the dialogue. And from this point on, it's not that hard. We firstly check if you're dealing with indeed an applet. And then that we check what's the distance between the middle of the dialogue, which is of course, left of the dialogue, plus half of the position, the distance from that to the center of the screen. And if that is less or equal than half of the dialogue, it means that it's close enough to still be able to be centered and cover what was meant to be, what actually opened up the applet. And that's just like that. We just say, okay, if this is the case, you set the x coordinate to be exactly half of the screen minus half of the width, because, you know, when you set the x coordinate, you set the leftmost point, which is always half a dialogue to the left of the center. So that is the merger quest. Just to finish up this video, I quickly want to mention, thanks to all of the patrons, this that you're currently seeing is how much I get paid. And my personal answer to that is not enough as always. So if you'd like to help me grow the channel, do more podcasts, do more KD development, fix more bugs, I'm really trying to fix a lot of bugs, as you can see on my channel. I have a lot of videos coming up about bug fixing. So if you like that, then feel free to pull up donations. And thank you so much. See you tomorrow with another video.


So Chip, if you're ready, can I ask you to stop today's presentation? Thank you, Simon, and welcome everybody to this morning's presentation on system architectures, MOSA and the FACE technical standard. We'll discuss how this, the FACE approach differs from other standards. I'm joined this morning with Chris Cook, he's the Senior Software Analyst for US Army, PEO Aviation, and also he serves as the Chair of the FACE Technical Working Group. I'm a Senior Market Development Director of Aerospace and Defense at Real-Time Innovations, also known as RTI. I'm also the Chair of the Business Working Group Outreach Committee. So system architecture is a description and representation of a system based on components and subsystems that will work together to achieve mission and operational functionality. A typical breakdown of system architecture for a DOD platform usually consists of the following subsystems. Go ahead and click ahead, Chip. So when we consider a DOD platform, a particular aviation platform, the system architecture is going to be defined in terms of certain subsystems. Now these can either be defined separately or as part of a collective design. Either way, a system is going to consist of hardware, software, network, and in the case of airborne vehicles, a subsystem to define the entities and behavior for radio frequency and signal processing. So this graphic is sort of a continuation of the one shown on the previous slide. And while there are many different architectural modeling languages, tools, designs, and approaches, this is meant to be notional in order to represent an abstract view of the different conceptual subsystems we previously touched on. Here we have shown some examples. Go ahead and click ahead. Some examples of most of the standards that can be used to define the components and behavior for particular subsystems. For defining a network architecture, an example is the victory standard, which defines a networked data bus for use on military vehicles. For hardware, architecture is over on the right. We have OpenVPX as an open standard example, which defines an architecture framework that manages and constrains module and backplane designs. This includes defining pinouts and it also sets interoperability points. Down at the bottom at the RF signal level, Mora extends the victory standard into the radio frequency arena by decomposing radio systems into high-level components that enable sharing of hardware such as amplifiers and antennas. And then finally, at the software subsystem level, and sort of the central viewpoint of this briefing, the face technical standard can be used to realize abstracted software components that are portable between systems. Next. So modular open system approach, also known as most formerly known as open systems architecture, OSA or open systems approach, can be defined as a technical and business strategy for designing an affordable and adaptable system. There's five principles of MOSA. So MOSA is actually defined by 10 U.S. code 2446 alpha, which took effect in January 2017. So the U.S. code defines a set of rules for adherence to the modular open systems approach, which are consolidated into what is known throughout the community as the five principles of MOSA. The first of these is to establish an enabling environment. What that basically means is that the approach should include all of the necessary resources in order to specify, identify, develop, and sustain the approach. This should include things such as the business approaches, contract guidance, technical guidance, training, et cetera. The second is to employ a modular design. Now, for the U.S. code, this is to allow several major system components at the appropriate level to be incrementally added, removed, or replaced throughout the lifecycle of a major system platform. The third is designate key interfaces. The MOSA requirements require that major system components be separated by a defined interface, and that brings us to item four, which is that a MOSA implementation should use open standards, not just in the component design, but in the interface design as well. The last principle is to certify conformance, which is sort of an inherited requirement in order to ensure that correct adherence to the MOSA design and interfaces is guaranteed. Next. So how does the FACE approach apply to this? So if you take a look at the first item established in an enabling environment, the FACE business approach features a business guide, contract guide, software suppliers getting started guide, integrators guide, and many more documents I'll show you later in the presentation. There's also tools currently available to create FACE products. So as far as employing a modular design, the FACE technical standard defines a reference architecture, and it is component-based. These components are abstracted and grouped into logical segments based on the capabilities and services they provide, thus achieving the modular design. Whereas the notion of the FACE segments can sometimes be a little bit confusing, an implementation of the FACE reference architecture is nothing more than a series of components that provide certain capabilities. Some of them have the sole purpose of enabling the capabilities of other components. An example of this would be the components within the transport services segment, which those of you familiar with FACE already will have familiarity with, and the transport services segment and particularly the components within it provide other components the ability to move data. The FACE technical standard also defines a data architecture in order to provide semantic descriptions of data that moves in and out of certain FACE software components, which are known as units of conformance. The third bullet is to designate key interfaces. So each segment that Chris just described is to find the FACE reference architecture and provide these open defining interfaces that can be easily accessed by anybody deploying the FACE standard. These interfaces are just for common services and also provided via the operating system segments. In order to satisfy using open standards, the FACE technical standard uses open, commonly used, consensus-based standards in its requirement for software components, as well as the interfaces. Some examples of these are its use of POSIX, Erring 653, Erring 661, OpenGL, and there's quite a few more. And finally, you need to certify these components to adhere, make sure everybody hears to the standard. So the FACE business approach defines a FACE conformance program that uses third-party entities called verification authorities to certify software components as being fully conformant to the FACE technical standard. There's no compliance or partial conformance. It's all, only 100% conformant is allowed for this FACE approach.  Most likely the most popular ones is TriService's memo from January 2019 that's like FACE, SOSA, OMS, UCI, and Victory. And it's just the use of MOSA is considered a vital to the success of the U.S. DOD. And it should be included in all requirements programming and development activities. Army, Navy, Air Force have also issued separate guidance around the MOSA requirement. Just because you have a MOSA approach doesn't necessarily mean that that approach is open. So there have been certain ventures to establish a MOSA design using an open standard. Now the FACE approach follows this pattern by defining the FACE technical standard, which is an open standard published by the open group. Go ahead and go to the next, Chip. Now as a result, the FACE technical standard as well as all its supporting documents are distribution A and they are publicly available within the supporting ecosystem. That means that all guidance documents, all business documents, contract guides, everything is open to the public. It is an open standard that implements MOSA. Once again, the MOSA is defined by the 10 U.S. Code 2446 alpha. And this slide just kind of shows that FACE does satisfy the requirements in MOSA as defined by DOD. So the first is that it employs a modular design. And yes, FACE does employ a modular design. It focuses at the software component level. It has defined interfaces and as Santa Bonas uses all commonly used open standards. It is subjected to verification to ensure major system interfaces comply with if available and suitable, widely supported and consensus based standards. Once again, yes, FACE does satisfy that. For its OSS level, it is interfaced to the operating system. It uses only open, commonly used APIs, POSIX, AERING 653, to where FACE does not require anything proprietary in order to implement units of conformance, a.k.a. software components using the FACE technical standard. Number three is that it uses a system architecture that allows several major system components at the appropriate level to be incrementally added, removed, replaced throughout the lifecycle of a major system platform to afford opportunities for enhanced competition innovation. And again, yes, FACE does allow for that. It is a component-based system with defined interfaces to allow greater power to the integrator to manage the lifecycle of the entire system. The most approach also integrates technical requirements and contracting mechanisms and legal considerations to support a more rapid evolution of capabilities and technologies throughout the product lifecycle. This is through the use of architecture, modularity, open system standards, and appropriate business practices. These standards are well known. We use a lot of different types of both public standards from other parties and also we've created our own business standards to assist in this approach. So once again, the DOD seeks to yield the following benefits with the most approach. The significant cost savings or avoidance, absolutely. There's essentially a product line mentality that surrounds FACE architecture and FACE procurement because you can now have multiple companies target a class of components that can be distributed to the U.S. government or any other entity for a next generation airborne platform. So yes, FACE does do this. And also the DOD hopes that you can get a rapid schedule reduction and allow for the rapid deployment of new technology as required. And once again, FACE tells us this. The third one is really opportunities for technical upgrades and refresh outside of the older model where we had a very long three to five year possibility and longer refresh cycle with FACE because it's very modular. You can update these components as required in a very rapid fashion without upsetting the entire platform or causing a retest the entire platform. So once again, FACE enables these opportunities for technical upgrades. And then finally, interoperability including system assistance interoperability and mission realization. Once again, FACE does this quite well because it's all based upon standards that are predefined as interoperable and it has been tested to be interoperable across platforms. So as far as how FACE fits within the architecture picture, here we're bringing back a graphic from earlier in the presentation. In this blown-out view, we have a notional environment boundary that would feature safety critical as well as non-safety critical software components as part of a software subsystem solution. Now in this example, we have a common bus separating the two environments where a FACE computing environment is used to house the safety critical software components. As part of a larger notional example, this is meant to convey that FACE is not intended to be the only solution within a software system architecture but is a solution for implementing safety critical software components. Some unique features of the FACE technical standard. For one, it is distro A. It is publicly available. It has no competing abstraction layers. All the software layers are prescriptive. The flexibility allowed below the transport layer, it allows for greater interoperability as far as transport services. It abstracts the protocol and the transport mechanism from the individual component and it allows for different sorts of capabilities to be implemented as far as the transport layer to do things such as message association, transfer between certain protocols and things of that nature. The underlying point is the abstraction of the transport from the individual software component allows for greater scalability and flexibility for the integrator. Governance at the data architecture level. This optimizes opportunities for reuse and interoperability by enforcing a common lexicon for component-to-component interfaces. Also, here recently in FACE technical standard 3.0, added an integration model to facilitate systems integration and kind of make things a little bit more organized in terms of the system integrator. This provides a great way of summarizing all the connections involved in the FACE computing environment that is maintained by the system integrator. Also, we have government industry collaboration on the standard itself and it's supporting ecosystem. The FACE technical standard and all supporting documents are maintained by a standard-based body. Oh, it looks like we've lost Chris off the audio chip. Okay, no problem. I'll take it from here and Chris gets back on. We'll get him on board here. So it's really a key that there's over a hundred government industry collaborators on this standard. It's not a handful of companies or defense contractors or even one service or agency that created this. It's 10 years of collaboration between government industry and academia. So it's something that's well debated and well understood by these companies and I put these published statements, published documents from the faking story and prove that fact. It's really interesting that it's applicable for hard real-time, near real-time, and non-real-time systems. There's different profiles in the operating system that can allow for this and also allows for safety and security capabilities. And then finally, the FACE approach has a domain-specific data modeling mechanism that exercise integration of multiple open standards on the same system so you can actually bring in other standards as required. Okay, I'll do the next few slides here. So how's it different from other most of standards? Well, it's suitable for, as I just mentioned, development of safety-critical software applications. It utilizes third-party component suggestions called verification authorities for the verification of artifacts. So you have an independent agency reviewing submissions for conformance to the FACE technical standard. The FACE technical standard defines requirements for conformance based on three levels of criticality, general purpose, safety, and security. And the FACE units of the conformance have been demonstrated to pass airworthiness certification. There's no blockage impact. In many cases, the FACE standard, the technical standard, tends to enhance and create an ecosystem of people with ready-to-go airworthiness certification evidence, like RTCA, DO170C. And then, as Chris mentioned before, the FACE technical standards are all of distribution A, so they have a supporting ecosystem. Anybody that will come download these at no charge. Now, there's a lot of really interesting use cases for the application of the FACE technical standard. They can be as wide-ranging as flight critical systems with strict airworthiness requirements and hard real-time response. They can be mission systems that need to rapidly integrate the applications from a diverse supply chain, multi-domain operations coming in from different security domains or national domains, and also multi-level security platforms. We actually have today two different companies in the FACE registry with certified conformance capabilities there. So you can actually bring in different agencies, different services, coalition partners, and bring in data from these different capabilities. Also, systems that challenge with lowering the total cost of operations by design phase is very modular and should and has reduced the total cost of operations of many platforms. Also, systems that need to separate and decouple critical software from new software innovations. It's the partition capability of the FACE technical standard allows you to bring in old software, new software, high-criticality, low-criticality software, and run that on the same compete platform. It's also standards-based. It's a standard of standards. So you can bring in multiple industry and industry standards like AIDA, ARIX 553, ARIX 64, C, Java, and others. So it's quite open in that. And E-standards now built into the FACE technical standard, and we try to take advantage of this whenever possible. And then the program is going to be software interoperability pre-qualified through a formal conformance program with proven artifacts. We have that through the FACE certified conformance program. And then, once again, the systems that need to support multiple levels of safety, criticality, or other types of criticality as defined by the entity. So there's use cases for the application of this business approach. One, and probably the best one, platform is a very high cost of change or updates, upgrades. You can actually now use the FACE approach to break apart some of the, I'll say, driveliness of those platforms to insert new technologies as required. There's also programs that say, I like to procure software from an app store with credential entries. It's not quite an app store. We have a FACE registry that actually talks about the capabilities and the credentials behind those capabilities. And then you would go to the software supplier to go procure that application. Platforms that need to include software from many business domains in a diverse, competitive supply chain. If you're trying to create a competitive environment when you go off or bid, FACE is a great way to do that. There's many companies now that have FACE certified conforming products. I think we have now 20 in the FACE registry, and there's a lot more coming. It's a great way to say, here's the set of capabilities I need to please bid on this. Programs that need to reuse software over multiple or similar platforms, and I think this is, especially too, as we get into unmanned platforms where some of the capabilities almost exactly the same, it's perfect for those types of environments. Systems challenge with lowering total cost of operations unless you're poor. And the real goal here is, you know, get the best avionics software to the warfighter faster. FACE is an open standard developed by government industry and academia that enables the most approach for these military avionics systems. It defines an architectural and business approach to developing and procuring avionics software. The development of the FACE Consortium technical standard and business approach is managed independently by the open group. There's no government entity or no set up companies or one company that can control the standard. And all the FACE technical business documents are published as you mentioned before. So, let's go back here. So how do you get started? Well, we have a FACE website. And on this website, there's lots of different options for you to go see. You can see the consortium activities and membership. I encourage everyone to join the FACE Consortium if you have an interest in the standard. There's links to public FACE documents and tools. There's a page on recent procurements and roadmaster FACE acquisitions and there's quite a few of these now. And also information for just navigating the FACE verification and components process. And also a link to the FACE registry that lists out the software platforms that have gone through FACE components. You know, such a ton of support. This is all on the open group.org slash FACE site. We have been very busy over the last 10 years. We've released quite a few FACE documents for both the business and technical side. You can see the different divisions of the FACE technical standard, shared data models, data governance, conformance, getting started guides, verification, business guides, 3.0 is coming out soon. So there's lots of publications. And if you want to learn about FACE, you can download all these publications and begin to read them. I'm sure you'll figure it out in about two years. Or you can just get started. If you're a software supplier, we have listed out, and this is up on the website, documents that you should read to get started to understand what's going on from a software supplier, an integrator, an acquisition, data modeler, or a business perspective. The best thing you can do is get involved. Join the FACE consortium. This is the place where when you go to these face-to-face meetings, if you really gain an understanding, you get to see the presentations and discussions of the different groups inside the FACE consortium, talk about some of the common problems on the both technical and business side, and also just meet some really great people. And I think people have been involved with FACE consortium for some time, but I have developed lasting friendships that will go well beyond our working environment. And once again, you get the network of other FACE members at these meetings, and that's really key. So if you have questions, or essentially ask me anything, send those to ogface-admin at opengroup.us, and they will vector that off to the right party to try to answer your question. Obviously, Chris Crook is part of this team today. He's chair of the FACE technical working group. I'm chair of the business outreach committee on the business side. FACE consortium members, everyone who attends FACE meetings will be happy to or answer any questions that they can. So do we have any questions, Simon? We certainly do, Chip. So first of all, thank you, Chip. Thank you, Chris, for that presentation. Before I go to the questions, we've had a number of inquiries about the slides, and my understanding is the slides will be posted at the opengroup FACE website along with the recording. So you'll be able to download those slides on the opengroup FACE website. So I'm going to work my way through the questions on the Q&A guide. So I'm going to start with Tim, and Tim asks, how do you achieve strong semantic typing in the FACE data architecture? And how does this relate to the open standards used for FACE? So I'll take this one. And my apologies to everyone for my audio dropping. I just continued to talk away before I saw in the chat that my audio had dropped. So I'm sorry for that. And thank you, Chip, for grabbing the ball and running with it. So I appreciate that. So the FACE data architecture in FACE, so whenever you use the transport interface, the transport interface is typed to a specific message. And the FACE data architecture defines all of the semantic representations in a shared data model that data types in FACE can be realized from. So what that means is when you build your data model to describe your data, whether it be, you know, a position message that defines LAT-LONG and altitude, you have to use the observables and measurements defined in the shared data model to realize those types. And the shared data model is managed by the FACE Consortium by a specific subcommittee. You can use the PRCR process to add things to it, but all data models that represent data traversing over a FACE interface must extend from a shared data model, which provides that strong semantic typing in order to describe the data that you are representing at the IDL level, which will be represented at the programming language level once generated off the model. As far as how this relates to open standards used for FACE, it kind of does and it doesn't. This is just one of those things that is used for conformance and to ensure that strong semantic typing in ensuring that whenever an integrator uses a unit of conformance, or a component designed to FACE, there is no question as to the representation of the data that is going to be traversing the interfaces that it is going to be attached to. So that way, if an integrator needs to provide a message transformation or do anything with that message that is traversing that interface, he has the knowledge in order to do that. Great, thank you very much. A question from John asking what are your thoughts of combining all these standards and he says that is Mosa, Mora, Victory Face Sosa into an all-encompassing standard. What do you think of that? That's an interesting request. I don't think that's going to be feasible because the level of technical knowledge required for each of those standards is very high. And I think it's far better to keep them as separate. But do as we did with the Face Sosa, reference these other industry standards in the technical reference guide. And so I think that's key is that you want to leverage these other standards when possible. But I think trying to integrate and then coordinate the development of and the revision of all these standards under one tenement. What would you, Chris, give another idea? Well, for one, it would be a very large standard. Just as Chip said, you would have to have expertise on every single one of these in order to create such a large standard. Now, there have been ventures within the DOD to create what is considered a standard of standards. And what I mean by that is that it applies to the overall system architecture design in that it has requirements like for all hardware you have to use for pin counts, you have to use the open VX standard like that. But it is not like an overall standard. It just provides guidance and requirements for implementing a system architecture based on existing standards. So things like that have been done, but as far as merging all of the standards into one to govern every single aspect of a system architecture that is very hard to achieve, I would imagine, and there haven't been any discussions about doing that unless someone had a good idea on how that would be accomplished. I'm not sure that that is a good idea at this time. But like I said, there have been standard of standards ventures within the DOD to use all of the available standards within an architecture design. And I think to double down on that from this perspective, it would be very hard to fund that unless the DOD has a massive war chest to actually fund all these different organizations. Many of these standards are funded by commercial military or DOD platforms like openGL like POSIX. So I think it would be very difficult to fund and coordinate all these different standards under one umbrella. Okay. Thank you, Chaps. We've got a question here from Todd and we'll take offline, but I'll ask it anyway. So Todd asks what is the cost of third party face conformance verification? So the verification authorities, that the independent agreement between a software supplier and a verification authority, so it is a competitive environment with multiple verification authorities and those will be individually negotiated in most cases with the data and the conformance verification matrix in the test suite all are in good shape. It should be very affordable. If you need help and of course many folks need help especially on their first face conformance activity the VA is there to help and therefore they will charge you more money because they're helping you out to get through the process. But as you get that into the client activity you can actually reduce this cost considerably. Okay, thank you. Boris asks, can you explain the difference between face and IMA? I'll just pronounce EMA or just IMA. So I'll get that correct even though it's a technical problem. So IMA is integrated modular avionics and there's a standard behind that called ERIK 653, managed by ERIK which is a commercial organization that manages avionics standards and aircraft standards. So IMA is a time and space partitioning it breaks platforms into executable partitions executing on a strict time basis. IMA and ERIK 653 is part of the face standard it's actually a fundamental part of our operating system segment in the face technical standard where we look forward to partitioning from both safety and security standpoint, but also legacy and new trusted and untrusted. So partitioning in the face technical standard is a very important activity and IMA and ERIK 653 is a fundamental contributor to that. Okay, thank you. Question from Aaron, it's another difference between asking what is the difference between a key interface and an interface, or he says or what is a key interface and what makes it a key interface? So I would define a key interface as an interface where variance is expected to occur and you want that to be abstracted as much as possible. As far as just an interface, any API can be considered an interface. However, there are only three APIs, the politics APIs, things that are version-specific referenced by a standard. However, things like transport, logging, interfaces where the software developer has a greater array of choices on what can be implemented and where all those choices may be different from another developer. I think that's what separates a key interface from, say, using something provided by POSIX as far as getting your hostname. So places where you see barriers to integration, those are where you're going to see key interfaces and what these defines as key interfaces are one, the transport, the operating system, but it solves the operating system by deferring to commonly used open standards. IO operations as far as device drivers, configuration and I believe that's about it. As far as now, there are other interfaces forthcoming. I know there's a pipeline in the works for a logging API, but that's still in the works. But yeah, basically to encompass the overall point, a key interface is where variance is going to occur from software supplier to software supplier. Okay, thank you. Question from Tony. Is this modular approach extended to the platform for remote and operation activities, for example, mission planning and mission data creation? Who fancies that one? Chris? Chip? I think we're both pondering an answer to that. I think the answer is no. We don't control that aspect of it. We're the architecture of an airborne avionics platform but the system, not the entire avionics platform or airborne platform. We really focus on the compute systems inside in your graph. Yes, I agree. That goes beyond the scope for MOSA and that gets into more platform-specific operations. That could be realized using the MOSA approach but not necessarily governed by MOSA itself. Okay, that's great. Thank you. Question from AV, asking, are face and MOSA new standards that are listed or included under the overall DoD architectural framework documentation versions 1, 2, 3 etc. or are they linked separately to the DoD AF? So the idea of MOSA is relatively new and MOSA itself is not a standard. It's more or less a template for creating a standard. Face has been around since what, chip 2010 and when did 1.0 come out? I think about 2 years later. Okay. So yeah, and since then we've had 2.0, 2.1 and in 2017 3.0. So not so much new but as far as products that are aligned to face, those are still up and coming and you know deployment of face components is still forthcoming. So new in one sense not so much new in another. As far as DoD AF, Chip do you have an answer for that one? I'm sorry I don't. That's great. Todd asks, have the claims related to face presented on slide 13 being substantiated with real world program results? That's interesting. Let's go back to slide 13 real quick. So as far as number one we don't yet have metrics on we don't really yet have metrics on that. That is kind of a long term solution. And that's really only realized when you have a family of software components in a system that you know kind of give you a kind of a base to measure the true cost savings that can be realized using face. So we don't yet have a metrics for number one. Same thing for number two. Don't yet have a metric for that. Three don't really either however the the overall design of components using the face technical standard does allow for this by you know separating capabilities and abstracting certain behavior from the software component level in order to allow for new technologies to be integrated and also forthcoming conditions for the face technical standard also add to new technology in terms of new versions of programming languages and things like that. I know in 3.0 we added support for new versions of C++ as well as data. So and as far as interoperability yes we have shown interoperability as far as interfacing with excuse me legacy components and as far as interoperability with software components that leverage other standards. So three and four yes one and two we don't really yet have metrics on. And I'll step into Chris I think we need to be a little bit more aggressive I appreciate your conservative view on this but as far as number one goes we are bidding separate entities on a platform now where before that is not possible I had to go through a large systems integrator so we are immediately taking costs and avoiding additional costs by based on parts of a platform not the entire platform and modification of the entire aircraft platform certainly schedule reduction we've proven that I don't think we track these metrics well when we do military programs but we certainly have proven that integrating a very complex solution stat with avionics cockpit software transport services systems operating systems graphic subsystems you can now do that quite quickly because we actually have these interfaces with the base technical guide so I think that the two things that we absolutely can say I think the top opportunities also for technical upgrade and refresh are now there's not more aircraft but there's more opportunities for more vendors that you can actually bid on a program where before you might have been walked out and obviously interoperability using this face approach is absolutely proven where you can actually bring in different types of systems and integrate them quite quickly and unpacking weeks versus months or years over also one of our colleagues kind of put in the chat that you know through balsa evidence and showing different demonstrations and integration efforts there have been shown anywhere from 25 to 75% reduction in integration efforts that we've learned through those ventures so thank you Corin for putting that in the chat that's great and I think everyone appreciates your further clarification that's fantastic thank you John asks when you say safety critical is it just software or is it down to the process level as well in terms of face just software excellent that's a quick answer to a short question let me just expand up on that absolutely with regard to face it's just software but if you're going to get airworthiness or get the safety certification with the DL178C for software and DL254 for hardware typically you're going to combine both those standards to achieve the safety certification that's great that was a short question this is a slightly longer question from Vincent he asks does face support data mediation is it our message details change over time and he says for example new fields added etc and we are looking for a capability that will help our publishers and subscribers mediate between different versions of the same message set I would like to pick that one up so that capability can be supplied via a component in the transport services segment the way the transport services segment in face is set up allows for a range of capabilities that are pretty much up to the software supplier as far as how detailed they want to get but say you have a software component that sends data according to an old version of a message and you have a new component that expects it in a newer version which has new fields or a change fields you can implement in the transport supplied by face or not supplied by face you can have a capability in a transport aligned to the face technical standard that allows for message transformations from one version of a message to another so that is certainly possible face is set up to allow for that kind of behavior although it is not defined directly there is nothing prohibiting a transport vendor from implementing that behavior okay thank you question from Tim asks what role have regulators played in developing the face approach how does face change safety audit requirements so this is chip down himself safety is part of face only in respect of that we want to either enable airworthiness faster or make platforms and systems that don't add to a safety burden but we do not have a safety standard within face so that would all be controlled by regulators deploying DO-178C or some other type of safety certification standard that is not something that the face consortium controls it is all we do have DO-178 well personnel with DO-178 knowledge and expertise that assist in publishing airworthiness guidance as far as implementing the face so whereas an implementation of the face requirements does not guarantee a safety certification or safety audit there is guidance available in the face technical standard and in supporting documents to ensure that safety considerations are taken into account when you are designing your face component okay thank you another recently lengthy question read it out as clearly as possible this is from Peter Peter asks may we assume there are face and moza definitions on the data labels etc which come in from 429 for air data and or inertial if so what are those parameters or where is the document that defines it good luck guys that's all that you have Chris thanks Chip I'm just trying to make sure I understand the question let's see do you want me to read it again Chris? no I can see it on the Q&A I'm just I'm parsing the language here if I'm understanding the if I'm understanding the question correctly which I may not be and if I don't if I don't answer this in the way that you put forth the question please feel free to contact me when we can actually have a discussion about this to make sure I'm addressing your question appropriately I don't want to leave you with a lack of information once again my contact info is in these slides as far as the interpretation and data labels for parsing 429 messages this is all going to be modeled in your ULP supplied model as far as providing definitions and the semantic meanings behind the elements of your data message so all that is going to be covered by data architecture which is defined in the face technical standard and once again if I didn't answer your question adequately or you met something else please contact me and we'll discuss this and I can pull the people in the room that have more knowledge than I do on this specific subject area that's great Chris and Peter thank you you've got the guy's thinking there so that's excellent so question here from D'Ralf and I'll pronounce your name correctly what's the latest status of face related tools so there are tool vendors out there that provide products that have the ability to develop and parse and generate code using face data models so those are out there the face consortium website has a third party tools listing that has a few of those out there the face consortium also has plugins available for certain tools and usually those are on the third party tools page as well another good tool to use is the conformance test suite the conformance test suite can be used to generate code and generate dependencies for testing your software that is aligned to the face technical standard but I would advise you to try the third party tools website and see what all is listed there I think there's quite a few vendors out there that don't list their products on that page but if you reach out to some of the open group representatives I'm sure they can point you in the right direction another specific question this is from Mike he says United States Air Force is OMS choose to define interfaces to various devices say for example radar, EL etc but it seems face is not how do you get interoperability if different vendors choose different interfaces so all this is abstracted via an interface in face there's a wide range of different external inputs device drivers and things of that nature there is a certain point that face doesn't dive into as far as certain hardware we abstract that in the IO services segment where you can define particular software components to interface with certain buses drivers or certain pieces of hardware to where the interface that is used by the unique software component to consume or to write to those pieces of hardware device drivers etc the interface is relatively constant and is abstracted in such a way to where if the devices change or new capabilities come about to where that software component that interfaces with that particular bus or device needs to change the software component that consumes the data doesn't need to change so that is how we achieve interoperability as far as devices and hardware OMS just chose a different route it's another solution is wrong it's just a different way of doing it there are certain things that OMS does that face and vice versa so it's just a different approach face chose to standardize an interface that abstracts external interfaces away from the environment so that's how we achieve interoperability in fakes well that's great guys we've come to we're virtually at the end of our hour so I'd like to call it a day here we haven't been able to get we've got loads of questions so first of all to the attendees we share or sorry we leave all your questions and they will be they will be shared with today's speakers also if you have a question that you'd like to ask the team then the email address is ogface dash admin at opengroup.org so that's ogface dash admin at opengroup.org so Chip, Chris before our enders are there any final comments you'd like to make to our attendees today go ahead Chris oh I'm sorry Chip we both kind of jumped in there yeah I would just like to thank everyone for dialing in thank you for your time thank you to you know for listening to what we you know have to say about mosa and the face technical standard I for one hope this has been beneficial to everyone and that we were able to kind of give you a little bit better perspective on how face implements mosa and mosa you know in general so I hope this was beneficial I hope we answered your questions adequately if not please get in touch with us because we would like the opportunity to to answer your questions and make sure that we provide the best knowledge that we can but overall thank you for joining us sorry back to you Chip thanks Chris I think you said everything quite well I just echo Chris's comments thank you once again for attending this webinar I think it was very informative for everyone involved so thanks again take care