 My name is Bill Kenahan and as the slide here says, I'm with a company called Scale. Let's see, James Bubba Davis is on the call as well. Between the two of us, we run the Data Interoperability Working Group as part of the phase consortium. Anyway, today I'm going to go through a bit of an overview on what data architecture is all about. Let's see, let's just dive right in. Now, the first number of slides here, let's see here, sorry, just figuring out how to use the computer. The first group of slides here, we're probably covered in a lot more depth in the business working group and technical working group overview. So I'm going to go through these really quickly. I think most of the folks on the call attended those and if you didn't, as Reggie mentioned there, recorded it online and available to go back and look at for better reference. But anyway, real quick, why is there a phase initiative? Basically, the systems as they've been built today, don't really allow for reuse across the different platforms, each one's a unique solution. That structure really doesn't support currently doing something better than that. So we've got to find a better way to make it so that we can develop pieces once and reuse them over and over again. So this is sort of borne out by the trends you've seen. I'm sure folks have seen this chart over the years. As the complexity of the platform goes up, the cost and the time are starting to really go up exponentially and we need to. We can't survive that kind of trajectory anymore, and we've got to make a step function change. So the idea is by coming up with a new way of doing this where we can reuse, and it's not a reinvents every time we need to create something. Hopefully, we can have this positive effect on future aircraft where we bring the cost down substantially. Why a consortium? Well, the idea here is to, sorry, is there a question? Just a reminder, if you're not asking a question, please go on mute so that we don't have background noise. Anyway. Excuse me, Bill. Excuse me for interrupting. Yes. I see that there's a couple of callers there that I need you to identify yourselves, I see a 6172 and a 9082 numbers. Because otherwise, if you can't identify yourself, unfortunately, I would have to kick you off. The 908 number eight and the eight one, right? Two. Yes. 617 is Draper. Is Draper? Draper, yes. Can you put those in the chat room for me, please? Okay, thank you for identifying. Sorry, Bill. That's not a problem. Anyway, why a consortium? I think the idea here is to get industry and government and academia all involved in coming in a common solution. The consensus-based approach is more likely to be more widely accepted than a government mandated or vendor-specific approach that's put forward. By having the consortium, there's an open discussion process, open decision process. What happens? Everybody's interests are balanced to the extent that they can be. There's a process to follow. There's an appeals process. It's all based on consensus. Again, the idea is it's not a solution that's dominated by one particular organization or interest. Anyway, that's the idea behind forming a consensus or a consortium to do this. A quick overview of the organization. There's a steering committee at the head, which ties into an advisory board for making sure that we're on board with industry trends, and we keep our eyes open on things that we need to focus on. Underneath the steering committee, we're divided up into three main working groups. There's a business working group. There's a technical working group and the group that was talking right now, the domain interoperability working group. There's also an enterprise architecture standing committee that does some things like making sure we have alignment with other standards bodies, looks at the larger integration problem, and so forth. We'll look a little more about the domain interoperability working group in later charts. I think we've covered the business working group, the technical working groups, and other sessions. Reggie, I'm not looking at the chat. If questions come in, maybe you can bump me and let me know that there's a question. Sure. Okay. Thanks. Or if folks just want to speak up and ask as well. The consortium, there's a pretty broad participation across industry, government, it's a sponsor level organizations. We've got sponsors from all the different service branches. We've also got some key players in industry, Boeing, Collins, Lockheed, Raytheon. Again, a number of principal level organizations all listed here. I'm not sure what the total organization count up, what count is currently, but as you can see, the list is pretty much a who's who, the folks that are doing things in the Airborne Avionics Domains. The elected officers today, committee chair and vice chair, you have Joe Carter from Army and Fred Miramair Descharme from IBM, business working group James Doty from L3 Harris, and Brenda Nodonal from PEO Aviation. The technical working group, chair and vice chair are Chris Crook from Army PEO Aviation, and Ben Brozgl from ATACOR, and for the Domain Interoperability Working Group or the DIOG, you've got Bobbitt Davis and myself Bill Kenahan. Again, I think a lot of presentations of yesterday covered this, so again, I'm not going to get into it much detail other than that. The idea on the right-hand side is, we're trained to open up the whole platform. The applications, the middleware, the operating system, and the hardware side as well. Although FACE, I will say does not address hardware, but where FACE is hardware agnostic, you can be on top of practically any different platform that supports one of the operating systems that's demonstrated to be FACE conformant. Again, I think you've seen this chart before, but what makes this all work pretty well is all these different technologies for how to do light bulbs have a common interface. We look at how that applies to what we're doing in software. If we have a specific functionality and we find a way to normalize the interfaces, then we've got some portability and adaptability on top of them and below that interface. This goes back to that first chart, is why are we doing this? When you look at legacy platforms, each one of them is one off. If I want to integrate this kind of equipment onto these platforms, I've got four separate integration efforts, the same thing for these, the same thing for these, and it's not just the integration efforts, but by and large with these having a different approach to bringing these kinds of capabilities on, the functionality that controls this equipment or this equipment or this equipment, typically is unique to the solution that's been integrated into here already. I'm talking to some nav device, ABC vendors, EGI, and I want to put that on the Chinook. The company has developed their own way of building that piece of software. Likewise, this company has built it their own way. Face is trying to promote a way that we can actually develop these components one time, these software components one time, and integrate them into the different platforms individually. By having the layered approach here, segmenting your device IO, your platform pieces that talk to those devices and the communication between the platform pieces and the portable components and within these segments. By normalizing that, we've got the ability to actually move the components from platform to platform, so we don't have to remake these. Every time I want to put it on a new platform it's just an integration effort. Okay. There's a number of certified components that are becoming available. As you know, there's a face product registry. Hopefully, you heard about that yesterday. This slide gives you a bit of a snapshot into who has components in there, the set of components in that library. I believe there's portable components in there, there's operating system components in there, there's transport service implementations, and even some data model implementations. So the list of things is growing, and it's projected to continue to grow as more capability is developed. All right. This is a bit of a recap on some of the slides. We've recap on the recap. Again, why are we doing this? It's to open everything up so that we have more competition and more flexibility. All right. Define, create well-defined interfaces so that we can define a marketplace for the business software. Benefits-wise, from the government's perspective, there's more flexibility and aligns through what the government is trying to accomplish and from industry's perspective. Well, number one, they're meeting their customers' requirements, but then there's new opportunities for business. The barrier entry for defining certain components has come down some, so you can have components from a broader group of folks. And then at the same time, it should improve productivity through the open architectures and the reuse and modeling and so forth. Maturity is option. We just released version 3.1 of the phase technical standard. It's a small delta on top of 3.0, which had major improvements over the phase 2.1 version. But again, we're at 3.1. It's published now. And there is a conformance process in place. As mentioned earlier, there's a number of things in the registry. I think we said 23 on the prior chart and 22 here, so we'll have to check that. But again, the fact that we've got that many things in the registry, let's speak to number one, the maturity of the standard and number two, the maturity of the conformance process. OK, so that's my blazing fast pass through the overview that, again, hopefully most folks saw that yesterday. If you aren't as familiar, there's presentations from the business working group and the technical working group that probably go into a lot more detail than I did. So anyway, now we're on to the domain interoperability working group, which is the one that Bubba and I show chairing roles on. So there's the domain interoperability working group. We've got that divided into three subcommittees. The first one is what we call our language subcommittee. That's run by Stu Furking from CCD Avmik and Ryan Brooks from Boeing. The language subcommittee is in charge of coming up with the metamodeling concepts that form the basis of data modeling for face. There's the metamodel. There's all the different rules on model construction and those kinds of things. That's all under the auspices of our language subcommittee. We've got another subcommittee called the shared data model subcommittee. That's right now led by Chris Alport. And we're still searching for the right co-lead to work with Chris. Not that Chris is difficult to work with, but we just can't find the right lead. Anyway, we'll talk a little bit more about the shared data model, but real brief description is it's a set of shared definitions that are standardized by face or expected to be used by every data model that folks produce. The shared data model subcommittee is responsible for evaluating change proposals and coming up with recommendations for the shared data model change control board. And then finally, we've got our guidance subcommittee, led by Leanne May from Collins Aerospace and Sean Mulholland from Tucson Invented Systems. This subcommittee is responsible for coming up with, as name implies, guidance on how to do data modeling. They actually publish the R volume, the data modeling volume of the reference implementation guide. And in addition to that, they attack various questions that come up about how to model certain things and produce white papers that are available on Play-Doh that folks can use to look at special topics that aren't covered by the rig. OK. So now we start actually talking a little bit about data model. I know there's a lot of excitement out there. But anyway, I'd start with this picture, because I think there's a lot of folks on the call that have probably a lot of background in software engineering and are used to developing, I'll say, our data types. They are focused on data structure that is intended to be an efficient, both in terms of space and access, way of structuring the storage of information for retrieval and use. Make sure that we've captured all the information. We can get at it quickly or quickly enough. We have ways to communicate it and share it and so forth. That's what also data types are. And I'd say a lot of folks, not everybody, but most, are starting over here. This is what we're used to if you've done software for years, data structures. Well, where we're going is over here. And it's different. It's a way of looking at the data in terms of relationships. How does this thing relate to these other things? And what are the properties of those things and properties of those relationships? It's actually quite a different way of looking at it. And what we found over the years of doing this is that there's actually a pretty big paradigm shift to go from over here where you're thinking about how is data organized for software versus what is the meaning of the data? So I'd say most of us are over here. I may have a few that are over here. And then this is where we're going to try to go. And after I go through the presentation, you'll hopefully understand a little bit better about what this destination is. Now, as we go forward, if you have any questions, put them in the chat and regular alert made. I'll make sure I address them in time. So anyway, I'm going to move to the next chart. So what are we trying to accomplish with data modeling? So I've got a bit of a rigorous definition here. All right? I'm going to say describe the data going into or coming out of the software component and the context of the entities of concern to the software component to enable an integrator to combine software components to provide a bigger capability. So what does that mean in a little more easy to understand language? We're really just trying to describe what it is we want to communicate to and from our software. And we need to do that well enough so that everybody understands what we mean, so it's easier to put the parts together. So that's what we're trying to accomplish. Now, to do so, that means we need to capture the semantics of the data exchange in a rigorous machine processable format. In other words, we want to have a model that we can do something with. And we need it to be fairly formal in the way we describe things. And again, I'm going to get into maybe my next chart and the chart after. We're going to show you what a little bit of this looks like. It's probably kind of fuzzy right now. And the last thing on this chart here that's important to understand is the data model mechanisms that we've built into the data modeling language within FACE are domain-independent. There's nothing FACE-specific about them. You can describe avionics type things, things from navigation, communication. But beyond that, you could theoretically describe anything. In our next example, we get into describing aspects of a university. That has nothing to do with avionics and so forth. But the data modeling language is quite adept at being able to describe those. This is not for weapon system or for aircraft or tactical or navigation or any of those specific things. It's pretty wide open. We just happen to use it for those kinds of things for a lot of the components. Alrighty. Where does data modeling fit? Let's see. Hopefully you've seen this chart over the last day. We've got the different FACE segments here. So these green lines here, okay? Represent the usage of the platform-specific services segment components down in here and the portable component segments. Well, anytime we want to communicate between any of these components, either within a segment or between segments, we have to use the FACE transport services segment to do that. We can't communicate directly between these guys here or from this guy to this guy without going through transport services. And where the data model fits in is for all these interfaces here that use the transport services, any usage of that has to be data modeled. Okay, we need to describe the data that we're gonna communicate either into or out of our components, okay? And then transport services, you know, when configured by the integrator, it will match up the interfaces between the source and the destination and provide any kind of translation and other kinds of functionality, you know, that allow the interfaces to be connected to one another. So let's start looking at an example of, you know, what a data model might look like. So I'm gonna assume that most folks on the call have an understanding of what your basic university idea is. So what we've done here is we've got a really small, you know, set of concepts that we're going to use to show how this relates to some of the data model terminology. Now for this particular picture, I've got two different kinds of blue boxes on there. I guess they're not technically boxes, but I've got this kind here with is a rectangle with the rounded corners and I've got hexagons. Now, important to mention at this point that face doesn't really have a diorama notation, okay? Our metamodeling language, you know, is, you know, strictly, you know, textual, okay? But often it's convenient to be able to draw some pictures to describe things. So we've sort of invented our own notation just informally, but this is not mandated by the standard. You can use other forms. I know there's UML profiles that have been used to draw, you know, to help model things in face. But again, I want to point out that face does not have a diagramming notation as part of the standard. But, you know, this is what we're going to use for this lesson here. So anyway, I've got two kinds of things. I've got entities and I've got associations. Now, entities are, as you would kind of guess, they're things, all right, that we might talk about. When I mentioned entities concern earlier, you know, these are the kinds of ideas that I'm talking about. Now, associations establish relationships between entities. Okay, so they sort of tie them together and provide some kind of meeting and the relationship between the two. Now, let's use those definitions to look at this picture a little more. So I've got my two entities. I've got the universe. Whoops, I click, it changes the chart on me. So I've got a university here. Now, let's think about, you know, what are some attributes of a university? It's a good time to bring up, you know, these things here, they're called attributes and properties, they are the, you know, the characteristics of entities. And you notice here that associations also can have their own characteristics. So that's sort of a universal thing. But if I look at a university, some of the characteristics that it has, that I might be interested in are the idea of the university, the name of the university, the location of it, okay. You know, so those are some common things that we would attribute to a university. I'm sure there's a long list of other things, but we only model what we need to model, right? And for this point and purpose, you know, I don't, we don't need to model much beyond what we have here. Now, if I look at a person, you know, I've modeled one characteristic of person, right? And that's ID. Now, it turns out there's a phase rule that says, you know, that says every entity or association needs to have an ID characteristic. That's the one they need to have. And everything else beyond that is optional, okay. Persons do have many more characteristics and eventually building something more real and practical and have a bunch more stuff in there. But for this example, you know, ID is fine, okay. Now, where it gets a little more interesting, okay, is when I started looking at associations. So, you know, let's look at this one here. Enrollment, okay, well, that's, that's a relationship we've defined between a university and a person. And hopefully this makes sense to everybody. People are enrolled in universities, right? So each enrollment relationship, I did some characteristics of its own, all right. Got a, you know, a date of the enrollment, you know, an ID of the enrollment. Remember I said, each one of these have to have IDs. But, you know, this enrollment has, you know, these characteristics, all right. And then when we follow these lines over here, okay, you see I've got some labels on them that describe the, what I'll call the cardinalities, you know, of that part of the relationship. So we follow this line over here, okay. We see that the university, and this will feel kind of familiar to all you folks that know UML, has a, it's participation in this relationship here as the role name of university, right. And each enrollment, you know, has one university that's participating. That's that one dot dot one, okay. And if we follow it over this way, all right. The person is playing the role of student in this participation, okay. And each enrollment relationship has one student. So essentially an enrollment is a relationship between one university and one student, okay. Bill, I have a question for you. Sure. Okay, just from Tony. And would like to know why didn't we do an aircraft related example? Well, I've got one a little later on that shows something more, not necessarily aircraft, but, you know, something tactical. So we do touch on that a little bit. But the main reason is, this is something that didn't really require much in the way of domain knowledge, you know, figuring most of the folks that are gonna hear this are familiar with this. And, you know, for the business folks that might be listening in that don't know anything about, you know, common operating pictures and those kinds of things they could, you know, they could relate to this a little bit better. So, and then, you know, one other thing is that, I think it speaks to the, I'll say the universality, you know, of what you can do with data modeling. So we try to touch on the aircraft stuff, but, you know, this I felt was just a little more, you know, widely understood in some things from an aircraft domain. We've also received some comments in the past with one of our learning examples we used as we developed the phase 3.0 data architecture language, and that some of the decisions we made just for documenting and exploring what were, what features were available and how they were implemented in language didn't line up 100% with Army doctrine. And so there ended up being confusion and discussion over what amounts to a sample example model and Army doctrine, and we didn't want to get into those kinds of discussions. Yeah, there's less difference of opinion here on this. So hopefully that answers your question, Tony. We'll try to touch on that. And again, you know, if you have more specific questions or you want to, you know, something more aircraft specific, we can see if we can wrap back around it at the end. So, let's see. So I addressed, you know, these labels here, but, you know, I didn't really speak to these, okay? And these are the source end of the participation. And, you know, what they're trying to do is establish some rules on, you know, numbers of enrollments, for instance, okay? So when I put a zero to star on this end here, basically it says that, hey, a university can participate in zero to many enrollment relationships, okay? And a person, okay? Well, I mean, the way we've said it up here, a person can participate in zero to many enrollment relationships too. So what does this all mean? Well, a university can have many people enrolled in it or many students enrolled in it. And a person can be part of enrollment relationships with multiple universities. In other words, you know, you could be going to, you know, Cornell and RPI, right? And your local community college if you want, right? There's no way we haven't put a balance on that what we've described here, okay? Including zero, maybe he's not going to school anywhere. Okay, you know, like many of us, we've graduated and we're just working now. So anyway, if we look here, we've just described another relationship that is an employment relationship. Now, if I look at this one here, it says, well, an employment relationship is between one university and one person. That employment relationship has a date and maybe an ID. So you can think of this as like your employee ID. Up here, this is your student ID, right? But again, like an employment relationship between a university and a person. In this case, a person is a professor, okay? We've, you know, so we've developed this generic idea of a person, okay? And, you know, in some cases, they're filling the role of student. In some cases, they're filling a role of a professor. And then, you know, one tip I'd give you, you know, in doing data modeling, think about, you know, an entity, you know, when you're contemplating and creating an entity, think about, you know, its usage. And, you know, when you're coming up with that idea, you know, for that entity, can it be used in more than one, you know, kind of relationship? So I'll be honest, when I first started this example, well, I had a person entity. I'm sorry, a student entity and a professor entity. Right? And, you know, in hindsight, that doesn't, you know, it's not necessarily the best thing, but that's what fell out at first. But when I started exploring, you know, some of the relationships, I said, well, what if it's, you know, the way I've done this, a student can't also be a teacher, a professor, right? But I know that, you know, from experience and some of Dr. Bubba's, you know, personal experience, you know, he's been both, even for the same class. That's students and a teacher in the same class. But anyway, so, you know, when you're thinking about this, you know, think about what you've defined and how broadly it can be used. So here I took my student entity and my teacher entity and I generalize them to be person and just put them in the different relationships and let the relationships define, you know, what role they are playing there, okay? I'm looking at this employment relationship just a little bit further, you know. So again, it's between one university and one professor, right, but a university can participate in zero to many employment relationships, okay? It can have, you know, any number of employees, theoretically, zero isn't very much of a university, but you know, we saw no reason to limit it here and likewise, a person, you know, can participate in zero to many employment relationships with a university. So maybe it doesn't work for a school at all, okay? And then many of the students aren't going to, you know, participate in that kind of relationship. The person might teach at multiple schools, you know, you might teach it, you know, a couple of different local universities or whatever. So, you know, hopefully you guys are getting the idea on that. Let's see, one thing, one question that's often asked when I'm presenting this is that an employment relationship has to be between a person and a school, but what if that person wants to work somewhere else? Right, that's not a school. So we didn't tackle that in our example. So we've, you know, we can sort of shape our whole world here and that's what we've done. We've limited to that, but yeah, in real life, you'd probably need to look at, you know, employment relationship, you know, being a little more open-ended on the other end. I do want to come back to, you know, these characteristics here, you know, you know, these IDs, again, might be different depending on the different relationships. Your student ID might not be your employee, your faculty ID, right? So they're unique to the different, they are unique to the different relationships here. So I'm going to go into the next chart. Is there any more questions that can come up, Reggie? Because this is about the time we usually start getting some. Nothing yet. No, don't get bashful, folks. Yeah, just put it in the chat window and I'll relay that to Bill. We hardly ever make fun of anybody for a question. Anyway, so, you know, trying to think about this a little more broadly, you know, I didn't put the numbers in here and the different labels, but, you know, if we were to take what we looked at here and expand a little bit further and look at some of the other ideas and concepts, okay, in our university example. So we've got, you know, our university here again, but, you know, if we were to, you know, play a little bit of buzzword bingo with a university, what are some of the things we think of? Well, we think of the university and the courses and the classes and the classrooms and, you know, all those kinds of things. So they all show up on this picture. All right, so I've got my university and, you know, there's an idea of a course, but what is the course, you know, relationship to the university? Well, the university offers the course, okay? And courses, you know, have IDs, all right? Maybe, you know, going back to, you know, to one out of the school, you know, CSE 221, right? Introduction to Pascal. But that was the idea of the class, right? And, you know, it had a duration or a number of credit hours or whatever, you know, associated with it, okay? And that's the course. So I looked up the course catalog, there it was. Well, every semester when you had to sign up for things, you know, there wasn't just one of these. There was, you know, several different versions of the classes that could be offered. And those are, you know, a class is really an instance of a course. So I might have, you know, section one, section two, three and so on, okay? So, you know, the university offers a course. And each semester there's certain, you know, classes, which are instances of those courses. Is there a question? Hey, Bill. Yeah, we have one from Travis in asking, and I think he talked about slide 18. What if he wanted to add a person who was an assistant or janitor or whatever? Reggie, your audio wasn't coming through too good for me. Can you repeat that? Oh, wait a minute. It said, what if you wanted to add a person who was an assistant or janitor or whatever? That sounds terrible. What's going on? Yeah, so let's see here. So, you know, I could come back here. If I wanted to deal with all persons employed by the university, you know, I could probably change this relationship here to be employee, the name here to be employee, okay? Right now it's sort of specific that, you know, this relationship deals with professors, okay? And if I wanted to generalize it, you know, I could change the name of this to be employee and that would deal with all employees of the university. Now, if I wanted to, you know, single out teaching, you know, I might have another relationship here called teaching, right? That went between a university and a person and, you know, the person on the other end, you know, was labeled teacher, professor or whatever, and I could sort of single out that specialized kind of relationship, different from a generic employee relationship. Hopefully I answered your question, Travis. You know, thanks, appreciate it. Okay, you know, it's probably a good time to point out that, I mean, you're going to model based on, you know, what you need to describe the concepts for what you're building, okay? So, you know, you've heard the statement, all models are wrong, but some of them are useful. I mean, that's sort of the same idea here, right? We're describing things and relationships between those things, and we're only describing the stuff that's important to us, right? We haven't captured, you know, other characteristics of university. We haven't captured other relationships between universities and persons and so forth because, you know, as we've narrowly defined the problem here, you know, that's not important, okay? So, you know, when you go through this, you'll learn as you go what, you know, what just enough, you know, just the right amount of modeling is, and it's a bit of a, you know, an iterative process. I will say that, you know, as you go through this, you'll, you know, don't do it in ink. We're doing it on a whiteboard so you can easily erase it because, you know, you're going to write some things down and you're going to change your mind and new realizations are going to pop into your head and you're going to fix some things so that it captures what you need to. Yeah, you know, Bubba and I did this example, oh, I don't know, more than a year ago now and I think, you know, every time we do this overview, somebody points out, you know, something that we didn't think of or some, you know, some limitation of the model. And we just say, well, we meant it that way. But, you know, they're good points, really. And, you know, you'll go through that process when you do data modeling yourself. There's, I'd like to say it's exact and you know when you're done and you know you've got it right. And, you know, unfortunately, part of that, part of that path from going from data structures to, you know, data modeling, you know, part of that shift in paradigm, you know, is this activity where, you know, you're not sure and you're trying to find your way. Anyway, coming back here, you know, we talked about course. Bill, can I ask you a follow-up question? Sure. So you can stay on the slide, it's fine. Just wanted to follow up on your comment about this level of uncertainty in your experience or other modelers that you're aware of. There's going to be a point, right, where you're identifying gaps in your model. And I'm kind of wondering how detrimental said gaps could be to the software development process and lifecycle, because sometimes I'm guessing that, well, you know, we've done enough modeling and we're going to call it good and we'll take care of the rest of it and requirements or rationale or derived requirements or what have you and get going with the rest of it. And so I guess I'm just saying, is there ever a point in which the gaps that you may or may not know about in your model are detrimental to the software development process? Yeah, I mean, you know, it's hard to answer because, you know, all the different scenarios are different and it depends on how, to what extent you're exploiting the model. If there are gaps where you've missed something where there's data you need to address, either in your requirements or in communication between components, you know, you're going to have to do the refactoring of the model and, you know, the artifacts downstream because, you know, you've decided that's data you need to communicate about, right? But, you know, ultimately, as we'll talk about a little in a little bit, this model here, okay, it helps you define the concepts, but it forms a basis for the data that you use to compose your messages, your data structures that the software uses. Okay, so ultimately there's data structures at some point, but the modeling language actually has a natural way of sort of decoupling this conceptual view from, you know, the data structures that end up popping out and you're using in your code. So by using, you know, that mechanism, the view mechanism, which we'll talk about in a little bit, you might be able to change this model that we're seeing on the screen here now but not change any of those views because the data you've put into them, you know, is already in the model, it may have moved around and you're gonna relink those pieces together but the data structure didn't change and therefore your software doesn't necessarily have to change either. Okay, thanks. No problem. And we're gonna touch on views in a little bit. So let's see here, you know, continuing through here, you know, you've got, you know, persons, right? People, okay? And well, they're gonna enroll in a certain class, not just the university but they're gonna enroll in a certain class, right? And you've got another person that's teaching the class, right? Looking here, you know, where are you gonna hold the class? Well, you know, the university has rooms, okay? Some of them, you know, are class rooms, okay? Not all of them, like, you know, the gymnasium might not be, you know, maybe a room at the university but, you know, isn't necessarily a classroom. I guess for phys ed, it could be but anyway, you get the point. And then, you know, there's a room allocation between a class and a classroom, okay? And if we chase that away through here, we can get to, you know, what the room is. Now, one interesting thing on this chart, I see this association relates an entity to another association, okay? And that's, you know, perfectly allowable in the face modeling language. And as a matter of fact, if you were to look at the underlying meta model, you know, an association is just a form of entity that allows you to connect other entities together but it itself is an entity. So you can do some stuff like this to really capture the relationships. Let's see, I saw a quick thing pop up. I think Ben might have a question or a comment. And there was one. Yeah, since you'll probably come with it, what about the types of the attributes, for example, duration could be in minutes or in hours or in an hour, et cetera. So I know you're gonna get to it but we don't mention it here. No, that's fine. That's, you're playing a good straight man. You'll notice, you know, what we've done here describing these concepts, we haven't addressed any of that. We haven't said what the ideas look like or, you know, what the location of a room or university is or the duration of a class, how we're doing that in minutes or, you know, four nights or whatever, right? Conceptually, we don't have to. We all sort of understand, you know, the position or the position, the concept of a position, regardless of how we're gonna measure it, right? So conceptually speaking, you know, we describe it this way. And then you're right, Ben, we do have another layer of this that goes through and says, okay, that position, you know, I'm gonna describe it this way, okay? And then I'm also, when I actually represent it in real physical data types in my programming language, it's gonna take on this shape, okay? And we do get to that in other layers in the model and I believe my next chart is gonna start to hint at some of that. So let's see, I think I'm done with this chart unless there was more questions on it. So what we've been looking at to this point is what we're gonna, you know, we'll call our conceptual data model. It defines the concepts and some of the properties of all the entities and relationships, but again, as Ben pointed out, I haven't talked at all about specifics on what some of these next things mean. So that's where, you know, faith actually has, you know, multiple levels to it, okay? We've looked at, you know, the conceptual data model. All right, that's what we've spent our time right now. And that's, you know, to me, you know, that's the most head scratching part of the whole thing. All right, that's, you know, where you're really trying to tease the ideas apart and figure out what are the right entities and what's an association between them and where does, you know, X, Y, Z property live as a part of an entity, as a part of an association? You know, those kinds of things. All right, after that, in my opinion, it gets easier because in areas, you're just making some, some refining choices. So, you know, we've talked about a conceptual data model and a logical data model. Actually, let me come back here and use one specific term that might help. Their conceptual data model, we've talked about our entities and their observable characteristics. Okay, that word observable is important. They're the things that, you know, we can see, we can measure, okay? At the logical level now, all right, for those entities and associations we've defined, we make some choices about how we're going to measure those observable characteristics. So that, you know, that position, you know, for the university, you know, might be, you know, a lat long that I've described in, you know, degrees for the latitude and longitude, okay? Or I could do something crazy like use EarthCenterFixed coordinates where it's an XYZ kind of system based on the center of the Earth. Or, you know, I can use a street address. All of those are good ways to describe the position, right? That at the logical level, we make a choice on which ones we're gonna use, okay? And matter of fact, I can even make multiple choices. I'm gonna be able to get at its lat long position and its street address position, okay? So at the logical level, it's pretty much the same things we've done here, but we make some choices on how we're gonna measure those observable characteristics, okay? And I'll emphasize that we can, you know, we can perhaps do that more than one way. If it's useful to you in your domain to do that. Now, the platform level, well, again, we're just making some choices, all right? If I decided I wanna use lat long to measure the position of my university, well, at the platform level, I might say that, well, I'm gonna use double precision for latitude and longitude to be able to, you know, represent that position with the accuracy I need. Or, you know, university, you know, a float is fine, you know, it gets me close enough, okay? Or for my, you know, my street address version of the position of the university, maybe I'm gonna use a text string, okay? But those kinds of choices are made here at the platform level. So just going through it again, you know, here, we define basic concepts and observable properties of things. Here, how are we gonna measure those properties using what kind of measurement system and what kind of units and frames of reference and all kinds of things, right? And then here, what is the actual, you know, type, data type that I'm gonna use look like? Okay, so for my lat long, I might use, you know, it's gonna be a struct of doubles, you know, something like that. Okay, for my ID, it might be, you know, a 64-bit, you know, integer, 128-bit integer to hold a UUID, you know, something like that. All right, hopefully everybody's with me so far. Ben, did that help clarify things at all? Yeah, if there's one question, when you get to the platform view, you're talking about doubles and floats, but that's language independent, like an IDL, or you're looking at, you know, CDC++ AIDA. It's language independent. So it's all tied into data types that sort of map to IDL. Actually, if you look at the metamodeling language, you know, it would be, you know, an IDL double, an IDL float, that kind of stuff. And then later on, it's a translation process, you know, into the underlying programming languages. Again, you know, we try to maintain as much independence as we can, and who knows? Maybe in the future, there'll be some other version. Maybe we'll do it in Rust or Go or something like that in the future, right? And so we wanna maintain independence and just change the mapping. So this part here, okay, you know, it defines our model of the entities and relationships. Now, something I haven't really talked about, there's this thing, this little box here called platform views. Now, you know, a platform, a view in general, is a certain way of looking at parts of the model. Okay, so if you're familiar with, you know, with databases, you know, I might have a bunch of tables in my database and I might create views, you know, of those tables, which are really just, you know, select statements that I can view, you know, as sort of another table, but that's all joined from different data in the model. Well, views, you know, in face are pretty much the same thing. It's a reach back to the entity model to the data you wanna include, you know, in the view. Okay, and matter of fact, it's such a, you know, there's strong analogy back to databases, the textual language we've chosen to actually do that is derived from the SQL language that's used in many database systems. But these views here, you know, again, they describe back, they reach back into the entity model to say, what data is in that view? And views actually, you know, are the key thing to define, you know, payloads of, you know, messages that are gonna be communicated, you know, between your units of portability. Views, I'm probably getting a little bit ahead of myself, but views at the platform level actually, you know, map down into real, you know, ideal language structure that can be translated into any of the programming languages. Back here at these other levels, you know, we can't define that structure because we really haven't defined, you know, data types at that point, but we can still, you know, call out certain data that we want to be in part of our view, but this is, you know, the most common usages of view is in this level here, it's to define payloads that go back and forth between your UOPs, units of portability. Let's see. So these are the three levels of the model and these next two, you know, this next one isn't a level, so to speak, but it's a usage of the model. Okay, so here you're going to define, you know, your component and the interfaces to that component. So components can be in the different, you know, segments, right? The portable component segment, the platform specific services component, you can even have, you know, transport service components, you know, that are defined here. The idea is, you know, what you define here, it talks about, you know, the interfaces to that component in terms of the data model. So if I, you know, if I have some data I want to communicate in my component, I'll define views for it here that describe what parts of the entity model are in that particular view. And then I'll create a component here and I'll have what's called a connection on that component that refers back to that view saying, hey, this connection that I called ABC is going to, you know, point back to this ABC view type, right? And that way we know all the ports, you know, the intus and out of, if you will, for my unit of portability and the data types that have communicated over them. And by knowing that, I've got reached back into, you know, all the different levels of the models have got all the information I need. I saw there's another question that popped up. Let's see. Yeah, just to clarify some terminology, the use of platform here is in terms of embedded software platform versus an aircraft form slash design or platform, correct? That is correct, Travis. That was going to Travis. Yep, yeah, actually, I finally figured out that I opened the chat window myself so I could see the pop-up. So I just brought it over to another screen so it's not an interference presentation. But yeah, you're right. I mean, platform is sort of an overused term. I remember when I first joined the consortium, I was like, well, what do they mean platform here? And I was scratching my head on it for a while. Yes, platform here means, you know, the computing platform, not the air vehicle platform, okay? Let's see. So we talked a little bit about units of portability. I can, you know, define one or more of them and, you know, describe the connections that go into or out of the unit of portability and I can map it back to views. So I've got data types and so forth. Now, having all of this, I can then, I've got all, you know, assuming it's all, you know, passes the conformance test and it's all, you know, it compiles, if you will. I can then use that to translate, you know, what I have in my model into real life code, okay? So I can take everything here and, you know, I can generate, if I have the right tools, I can generate IDL, I can, you know, go directly to ADA or C plus plus or C or Java, right? Those, you know, all of those, you know, are the mappings, the language mappings that are defined right in the face technical standard. Okay, including, you know, how this, how the face model maps to IDL and how IDL maps to these other things. So it's all on the standard. If you wanna do something in XML, I mean, I'll say that the face data model itself is stored in a form of XML, but if you wanna have your own special form of XML that you use to, you know, as a part of your message definitions, you know, you can, you know, with your own tools, you know, process the face data model, the XML that it is, and translate it into whatever form of XML you need, okay? So this is really just a subset. The nice idea here is that by having this in a model, and, you know, what I earlier referred to as a machine processable form, you know, you can feed it into different tools and translate it into whatever you need. Yeah, whatever makes sense for you to get the most, to leverage it the most that you can, okay? So I think I've about exhausted everything on this chart. I don't see any new questions popping up, so I'm gonna move ahead. I'm gonna try to move ahead anyway. Okay. So, you know, we've talked a little bit about the model, the different levels of the model. I'm gonna get into just a little bit more detail. The, I've got an interesting dividing line here, okay? Things to the left are something that's called, in something called the shared data model and everything to the right, is stuff that's added in, what we call a UOP supplied model or USM, right? So I talked a little bit about the shared data model earlier. I said that it's part, it's produced by the face consortium, it's managed by the face consortium. It contains some common definitions that we wanna make sure that everybody has access to and everybody uses consistently, okay? So again, things to the left are in that shared data model and the only ones that you're allowed to use of those kinds of things, everything to the right, you can come up with whatever you like. So at the conceptual level, there's these idea of observables, okay? What are the kinds of observable properties that I can describe on things? So we saw a couple, position, ID, duration, some other common ones, temperatures and pressures, velocity, acceleration, all those kinds of things, they're all observable properties. Many of them are observable properties are physical things, but some of them are a little more abstract like health status. All right, that's a little more abstract or mode or those kinds of things. Now there's again, a fixed set of things in this observable list that's managed by the consortium, but that's been pretty stable for a couple of years now. It's not really much added to that. So we think, believe it's pretty comprehensive in the case that there's something missing from the shared data model that you need. Yeah, the process is to fill out a change request to the FACE consortium to request it to be added, all right, providing data or details on what should be there and why you think it needs to be there and how it works and so forth. And then the shared data models of the committee that I brought up earlier, we'll take a look at it and sort of judge it against the things that are in there now. Is this consistent with where we want to go? Is this a duplicate of something else just with a different name and so forth? But anyway, they'll do some analysis and maybe even add some back and forth with the submitter and then come up with a recommendation that the shared data model CCB uses to vote on. That CCB, in case you're interested, includes members from, Bubba and myself from the DIOG are on it, Chris Crook and Ben are on it from the TWG as well as Stephanie Burns and Stephen Price from the Transport Services Group. Because remember, we need transport services to communicate anything using the data model. So anyway, at CCB, we'll then look at that recommendation and we'll go in or out, okay? But you can't just invent your own because if you try, you'll fail conformance if it's not in the shared data model. So anyway, we've got observable properties here and those are things in the shared data model. The other things at the conceptual level are entities and associations. So we showed you those, okay? Now, not everything in our meta model is on this list but I'm trying to keep it meaningful for everybody. So there's some other little things behind the scenes but these are the main things, right? Now, at the logical level, okay? Well, we wanna talk about how we measure observables, okay? So we've got, let's see here, we've got measurement systems and to have a measurement system, actually you need some basic coordinate system kinds of concepts first and then you can create measurement systems and measurement systems are based on certain landmarks with reference points that fill in. So for instance, if I wanna do Earth-centered, Earth-fixed, I might have a landmark of the center of the Earth and its reference point is 0, 0, 0. And then I've got a couple other reference points that use to center the system in a 3D space and that's all defined at this level. We also have units, okay? We've got a really comprehensive set of units in there. Again, derived from about every source of units that we could find. This has been fairly stable as well, it's rare that something new gets added but there's a long list of units out there. Value types, again, this list is pretty small, it's been stable pretty much since day one. We're talking about like real numbers, integer numbers, enumeration, kinds of things, right? Value types, a new one in phase three is this standards-based measurement system. So sometimes a standard exists that we wanna use, that we wanna point to instead of having to do it all in detail, like I think the first one that went in there, correct me if I'm wrong, but it was MGRS military grid reference system. All right, so that's a fairly complicated way to describe a location. And there's an existing standard out there for it. So rather than trying to work it into a set of axes and all those kinds of things, this just points at that standard by name and allows you then to say, hey, I'm measuring this position using MGRS, okay? Now, these are the things that are in the shared data model. You've got measurement systems and coordinate systems. Now the actual measurements themselves, you're free to define. So you may point back to saying, hey, I'm using a WGS84 measurement system, which by default has units of meters, but I'm gonna create my own measurement based on WGS84 that uses inches, right? Some ridiculous thing, okay? Or I've got a temperature-based measurement system over here that by default uses Celsius, but I need to do something in Kelvin. Or Fahrenheit or whatever, okay? So you're gonna define your own measurements that are based on things, that are gonna use these over here, okay? And the other thing that's still at this level here are your entities and associations because they're needed here to be able to provide a trace back to what you're refining. So my university here at the logical level would realize back to the one at the conceptual level, same thing for associations. At the platform level, okay, you've got your entities and associations again because now you're filling in the types for them, okay? But you're gonna define your own IDL types. So for my Earth-Senator Fixed Measurement System in inches here, I'm gonna define a struct that says, hey, I've got fields X, Y, and Z and they're gonna be in long ints, okay? Okay, or I've got my position in WGA City 4 and I've got a field called latitude, which is a double, longitude, which is a double, and altitude, which might be an integer, you know? Again, these are structures that you come up with right here, these IDL types, right? There are some primitive types that are back here but these are like your really basic things like the idea of being a double, all right? Double and int and string and those kinds of things are all just defined back here in the shared data model. We're not looking for you to come up with your own double, right? But you'll use the ones that are here in creating your structures. And then finally over here, these things called queries and templates. Now these are the things that go back to views. So when I said you're going to create a view and the language looks an awful lot like SQL, if you're familiar, okay? Well, that's the query side of this. Okay, you're going to use that to describe, hey, what data from the model is it that I'm including in this payload? Okay, so that's how you tie it back to that model. Now the template side of things is, well, now that I have this data, how do I want to organize it? Okay, so the query theoretically goes back and gets this flat view of the data. And you may want to have some other structure around it so that it's organized and you can maybe get a little bit of reuse in there too. So for instance, if I'm trying to pull together data for my engines and my aircraft, I might have a query that says, give me the data for the left engine and give me data for the right engine. But my template says, okay, for each engine, I'm going to organize that into a structure and I'm going to start out with all the temperatures and I'm going to have all the pressures, right? You know, that kind of stuff. But you can, you know, again, you're creating your data structures here for your messages. So, you know, back to that brain picture, you know, back in that upper left-hand corner where we're comfortable, that's, you know, that's this stuff here, okay? But the, you know, the right-hand side destination, you know, the picture, that's all the stuff up here, okay? And then this last piece, okay? Oh, by the way, you know, queries and things like that do exist at these other levels, but like I said, I didn't show everything. I showed the, like the important bits from each and the common ones. But anyway, if you do want to see what's really in there, you can take a look at the face standard or, you know, look at the meta model that's underneath everything and you'll see, you know, exactly what's there behind the scenes. So finally we've got this UOP model piece. And what do we have in there? Well, we've got, you know, platform-specific components. We've got portable components and for each of those we can describe the connections. You know, you can think of a connection in this case as a port to, you know, into or out of one of these. Okay, we use the term connection because that's what the transport services folks use. You know, when you're using transport services, your code will call an API called create connection. Okay, and that's really what we're trying to map to exactly here. So again, your component, you'll define some number of connections. Do they go in or out? What's the rate they go at? What's more importantly, you know, what's the data type that we communicate over it? That's the kind of stuff you do at this level. Okay. Everybody with me? So the thing about doing this virtually is I can't see any kind of puzzled faces so I can drill a little further. I'm relying on you guys. If you have questions, ask them. All right, I'm gonna go to the next chart. All right, now. No, no, excuse me, Fred. I just wanted to give you a time check. Am I running out of time? No, not yet. But I just wanted to let you know, 12, 12, 14 right now. So- Let me wrap up, 12, 30? Yes. Okay, I'm getting there. Okay. Sorry if I'm going a little slow. No, that's okay, I just wanted to let you know. So let's see, somebody earlier was asking about, what's a Tony was asking about why not a more relevant example? So here's one that's a little more relevant. The word relevant, there's no pun intended, but when we're looking at a mission, there's this concept of a relevant operating picture, right? So we've tried to embody that here. We've got a relevant operating picture. That relevant operating picture is centered about a position that has a size, right? It has some dimensions. It's this many kilometers, by this many kilometers and so forth, okay? That relevant operating picture may be composed of, and that's the shorthand I'm using on this chart, composed of zero to many tracks. Okay, a track is the thing that I'm tracking. All right, those tracks might have an ID, they may have a kind, maybe it's a ground track or an air track or whatever, all right? Conceptually, it doesn't matter. There's a kind that's interesting to me and they have a position, okay? So here's, again, a really simple, conceptual view on things. The logical level. For my relevant operating picture, I've got an ID and I'm gonna use a UUID for it. Position I'm gonna do in WGS84, measured with units, degrees, degrees and meters. And I'm gonna do the size of it in kilometers. And for those tracks, again, for my ID, I'm gonna use a UUID. Kind is an enumerated, air, ground, sea. You know, I guess I gotta have subsurface and different kinds of things here. Again, it's up to you what you need. And for position, I'm gonna use Earth-Centered Earth Fixed and it's kilometers and all three axes. All right, that's the logical level. Now at the platform level, okay, for my relevant operating picture, that ID, I'm gonna use a string. I'm gonna use doubles for the lat and long and int for the altitude. And for the size of the thing, I'm gonna do that in floats. Now for my track, I'm also gonna use a string for the ID. It's gonna be an enum for the kind. All right, with these enumerations and position, it's gonna be three doubles. And you've seen, I've drawn these realises line from one to the other just to show that, hey, this logical representation is the same as that. And this platform representation is the same as this logical one. It's just a realization of it. Now, I'm trying to go quick because I'm realizing time's running out. So, you know, I've got two messages I wanna communicate. One that's got all of the tracks in it. Okay, and one that has information about the operating picture itself. So my tracks view says, hey, select all the tracks from relevant operating picture. Okay, so that's this list of things here. Okay, that's the data that I want in that view. Now, I haven't shown a template here, but I would then describe a structure that allows me to say, hey, what does this look like? And for every track that's in there, how am I organizing that data? That would be in a template. Again, not in this example right now. My relevant operator in picture view, I might say, hey, select a position and select the extents. But for extents, use the word size instead of extents because most people realize what size means and the extents isn't necessarily clear. So again, I can alias that here and select that from the relevant operating picture. Why is it a new class? Well, I mean, ultimately, I think the way we've got things mapped from IDL and noons into the different languages, I think a lot of them are wrapped in classes just to provide a namespace around them so there's not collisions. But for kind here, we just, again, we just made a choice that these are the iterations you could take on. We didn't need any other kind of information to accompany that. I mean, struck that would normally think of this two or more pieces of data to represent it. And here, you really only needed the one, that's the enumeration. Let's see here. I said that was a question from Sean, by the way. So I'm gonna move on to make sure I save a little time for questions. Something I haven't talked about yet is the integration model. That was a phase 3.0 add-on. It's not required by everybody. And this is something an integrator can choose to use, but it allows you to describe how I'm going to connect units of portability together. So I may have unit of portability x instance one and another instance two. Okay, maybe I've got two devices and EGI, two EGI's on my aircraft for redundancy purposes. So I have two copies of this and I'm gonna map a message M out of each of them through a transport node. And I'm gonna transform it because UOPW doesn't speak the same language, right? Positions over here, maybe are in radians and this guy needs degrees. So as an integrator, I'm gonna wire this up, gonna move the data through the transport. I'm gonna transform the message type from what this guy gave me to what this guy needs. And it's gonna show up over here. And same thing, you know, this path, right? Cause this guy says, well, I typically have multiple EGI's that I need input from because I'm gonna synthesize some kind of solution, you know, from redundant, you know, and pick the best based on redundancy. So he's got multiple inputs set up over here. Again, you know, similar example here, you know, I've got two different UOPs out there and this guy provides a subset of the data I need. This guy provides a different subset, maybe some things I don't need, all right? Integrator's gonna, you know, arrange to have that transported through whatever, you know, way he wants, whether he wants DDS or UDP sockets or shared memory or whatever, that's up to the integrator. And he uses an aggregator block to say, all right, take the pieces I need out of A, take the pieces I need out of BC, which just looks like only C, create a message that this guy needs and pass it on. So this is, you know, again, this is a whirlwind, but this is the kind of stuff that would appear in an integration model. Again, it's optional, not everybody has to use it. I mean, if you're just making UOPs, you wouldn't use this, you know, you wouldn't deliver this anyway, maybe you would use it for your testing. But integrators, you know, can choose to use it if it helps them. And even an integrator isn't required to use this. All right, I'm gonna move on. So, all right, so now we're sort of through the language and the concepts and now we're back to some of the big artifacts. Okay, so there's the phase three of technical standard. Okay, inside it is this thing called the metamodel. That's, you know, the metamodel defines all the rules for the data model construction. It defines the fact that there are things called entities and there are things associations and there are things called characteristics and so forth. And, you know, an entity can have, you know, all the rules it says an entity can, you know, have composed into it some number of characteristics and so on. There's also a set of rules that are added for different checks. Just like any programming languages, there's a syntax and then there's some semantic checks, like, hey, the types have to be the same on both ends of this equal statement, you know, or assignment statement. That's what, you know, these kinds of things are here for. The metamodel and the phase standard is done using we use the Eclipse modeling framework and a tool in there called eCore or a modeling feature called eCore, which is based on OMG's meta object facility. So what we have here, you know, again, is a MOF model, you know, or a MOF model that forms the metamodel for the phase standard, you know, if you're curious, you know, the MOF meta object facilities actually underpins UML as well. UML is defined, you know, using the MOF. But anyway, so, you know, so it is a standard that we're based on top of, all right. By using that, we automatically, through the use of that standard, get an underlying format for our data, which is called phase XMI. So the term XMI stands for XML for model interchange. Now, I know there's a number of modeling tools out there like EA and Cameo that produce, you know, you don't see my air quotes, but air quotes XMI, which isn't, you're really the same. It's not, it's not this. It's their implementation of XMI is tool specific where this is, you know, normative to the XMI standard established by OMG and it's established completely by the metamodel using the meta object facility. So anyway, we've got our standard of the metamodel inside it. We've got the shared data model with a governance plan behind it that describes how it's maintained over time and how it's changed. Let's see, and there's some details over here on that. I went through it a little bit earlier. We've got this thing called a domain specific data model, which is an optional thing, but an organization or a community of interest can define, you know, a bunch of modeling concepts that they use that they then want used by everybody else. So again, they can factor out some commonality and save, you know, save work across an organization by defining this thing. So this is just a set of things that might be used a little more broadly. When you're delivering your UOP, you need to give a UOP supplied model, okay, which, you know, when it uses certain things that are in the shared data model it has to actually use the ones from the shared data model. It must align with the SDM. And then, again, there's the integration model, which we just talked about, which, you know, is built by integrators or maybe by UOP developers when they want to do a little testing, you know, to check, you know, to tie their new UOP into some test code and so forth. But again, it defines interconnectivity between UOPs. Let's see here, some, you know, some of the ways that this, you know, might work. Okay, again, there is no specific tooling, you know, mandated for FACE. I mean, you could use, you know, your favorite UML editor with a profile or you could use, you know, Emax and edit the FACE.xmi text file directly. Don't recommend that. But, you know, if you're that hardcore go for it. But anyway, there's a, you know, a set of model editing tools over here. So this is, you know, Inderville's GME and this is Cameo, EA or App City has some stuff and a number of companies that developed their own proprietary tools that I'm aware of. These can, you know, take in the shared data model, take in DSDMs and edit them. Same thing for UOP supplied models. And then there's a set of tools over here that, you know, folks can use. There's the FACE conformance test suite, which, you know, as they implies, is used to get conformance, but also as part of that conformance process generates code from these models that you can, you know, you can use in your UOP. So all the data types for C, C++, AIDA, Java, you know, all those kinds of things can be generated out of here from these models. The FACE transport services APIs, you know, the API pieces of it, not the implementations can be generated out of here. Okay. And then you can have your own tools that might do some things that are useful for you. How robust to be available? Michael Winning, how robust are the available tools? Seems like not having a robust set of tools beyond compilers is the gap. Yeah, possibly. I mean, the set of the conformance tools are, you know, they're gaining maturity. You know, they're a little challenging to use, but pretty much everybody seems to be using those and generating the code for the data model and the APIs. You know, there's been some profiles for some of these tools that are over here that are available to practically everybody. There's an EA plugin, there's Cameo plugins that are practically available to everybody. You know, you could look at it as a gap, you could look at it as an opportunity. I mean, you know, I worked, well, I worked at a prior company that did this and I work at a current company that does this. Okay, and we feel like we've got something, you know, that's an advantage over these. You know, in terms of, you know, what the capabilities are and features for efficiency and so forth. So let's see, Travis, I think the model editing tools need more work in general. Yeah, I can't say I disagree with that, Travis. They're still running for improvement and it'd be nice to get some third party vendors on board, you know, doing some things that provide, you know, better, more sure, state-of-the-art capabilities. And that's, you know, one of the reasons that the face consortium doesn't get into that business. We don't, you know, we don't want to be producing those tools. Time's getting critical here, so let's see here. I mean, I'm available past 12.30 if we want to let it stay, but I'll try to get through everything by then. So the face conformance test suite, which is, you know, freely downloadable, is used to validate USMs and DSDMs. Okay, and both must adhere to the published meta model and the standard, right, meet all of the OCL, object constraint language constraints that are in there. Okay. And let's see here. They must adhere to the stuff in the shared data model. So if you can't create your own measurement systems or observable types or ideal primitives, you have to use the ones from the shared data model. And if you need something that's not there, you need to file change paper to get it added so that you can achieve conformance. Okay. And let's see, there's a set of query and template constraints, which at one point in time, we're in the governance plan, but in version three, one of the standard that's just been published, all this is in the three one version of the standard now. Let's see, the CTS, like I said, the automation process is validated and it generates code in each of the four target languages. Let's see, there's a question about describing the data modeling from the two, one addition. That's a long topic. So I don't think I'll have time for that here. If you wanna reach out to me separate, you know, I can, I think I've got a set of charts, but, you know, I recommend everybody's start moving with three, three out with three one. Let's see here. This is a plug for our reference implementation guide. Let's see, so, you know, there's this, the volume data architecture guide and the volume and the three oh rig or the reference application after the three oh standard. Definitely recommend you take a look at it and it is available on the open group bookstore. Let's see here. So why are we here? Again, you know, data modeling is about describing the semantics, the concepts, the ideas, right? Underline everything you're gonna communicate. I mean, we've all picked up that ICD that we don't, we're not sure what they mean by the name of this piece of data. So that's what the data model is there to try to help with, right? To describe those semantics so that we got a better chance of understanding each other, all right? And better chance of understanding, you know, the data that goes into and out of our UOPs, you know, relative to things that we want to communicate about. What's next? Let's see, well, phase three oh, so this may be an interesting thing. So phase three oh was published and since then, all right, actually it's not what is next, it's what's now. We've taken parts of the standard and created a new standard called UDDL, Universal Domain Description Language, okay? And remember I said it can be used for anything, it's not domain, it's domain independent, all right? Well, all those domain independent things that are not there specifically for phase are in this standard. The ideas of entities and associations, observables, measurements, you know, types and queries, all those kinds of things are in this standard, all right? The remainder has been put into the phase three one standard, so phase three one actually references UDDL and adds a few things. And it adds things that are specific to phase like UOP models and templates for how you're organizing your data and the integration model and traceability, which we really haven't talked about. But all of these standards are now publicly available and published in the open group bookstore. So, you know, really this is where folks, you know, probably should start spending their time is in the three one UDDL one oh area. The data model really didn't change other than it got split apart. So the data model, you know, cumulatively here is exactly the same as it was here. But anyway, let's see. All right. Sorry, I didn't realize time was going by so fast. Sure is fun when you're talking about data modeling. Anybody still out there? Any questions? No one questions, Bill. I did check the person's name that I'll send you that about the data modeling from the 2.1 edition. Okay. And send that to you. Okay, sounds good. I'll see if I can scare up that chart there. There were significant changes. We had a lot of issues. The biggest change in two one, you know, from three out of two one or two one to three oh isn't the idea of the views. You know, that was changed substantially because what we had there, you know, just wasn't gonna work very well. So that was the biggest area of change, standards-based measurements and things like that. A few other small things, but those are the big items. And thanks for the feedback there. Michael, appreciate that and Sean. And I guess I hope it was useful for everybody. And you know, you'll see me in some of these virtual meetings. So, you know, if you've got any other questions or follow-ups, let me know. The charts are posted on Playto. Let's see, Reggie, do you know exactly where that is? I mean, I have a copy along my local machine. I don't know where Maureen is posted them yet. So, but people will get an email from her. All right, well, thanks everybody for attending and Bill, thank you, great job. No problem.