 One of the things is the data models that we process, the CTS processes, they are stored in a format called XMI and there is a face, a technical standard schema or specialization of the generic XMI. And these files are intended to be processed by computer. You can read them as a human, but that's not really their primary goal. It's that these are our forms of documentation that a computer can process and leverage. So how do we go about building those? So face itself talks about something called a shared data model. Now the shared data model is effectively a curated model. It has all of the foundational concepts that we need to start building out our data models as users. So there's really two sets of kind of core concepts in there, but the primary one is called an observable. And if you look in the green box on the right, I have a list of observables presented there. And these really are the core concepts that we use to build out our data model. These are the things that we talk about. Okay. Now there are three properties primarily that define an observable. It's the name. Okay. Now, why do we have, the name is the thing, well, we have this curated managed model. It is CCP control so that when anyone builds a data model using a shared data model, well, they're able to always look at the word position for the concept of position. We don't sometimes have it called location, sometimes called position, sometimes called pause or lock. It's always position. Second, part of the definition of the observable is its description. We actually manage that name as well, that description. And the goal there is to help disambiguate what we mean by position or radiant intensity. And it helps a little bit understand and provides some better understanding for what that observable is intended to mean. And finally, there is a globally unique identifier, sometimes called a GWID. And this is a unique number that is tied to each one of our observables. And one of the reasons we use a GWID is that it allows the computer a much better way to reference these observables. And also sometimes the names change. Now, names don't change very often, but sometimes it happens in order for us to reduce ambiguity or as what happened between the shared data model, addition 2.1 and 3.0, we actually changed the observable called unique identifier to simply identifier. However, in that case, since the GWID didn't change, we actually had some sort of continuity from one shared data model to the next. So what you can do, since you need all of these observables to start building up your data model, you can grab the shared data model by downloading it from that URL provided. It's provided by the open group that's on their website. I just condensed it just for the sake of the presentation. All right. What are we even going to build here? So before we even start talking about the content we're going to stick in our data model, we have to talk about what's the structure of a data model. So generally there are three main levels that we worry about. Yeah, there are a couple more. But just for the sake of today, we're going to focus on these three. First we have the conceptual data model. And this is the most abstract level of our data. And really, this is kind of how humans communicate. It facilitates how we, as humans, talk about the different ideas. Now, going all the way to the bottom, we have the platform data model. This is the most detailed level of our data. And this really gets down to how the level of where computers start to communicate. So what we have, clothes and integers and strings and those kinds of things that computers share. And then finally, in the middle, we have this, you know, it's the yummy center of the Oreo cookie that kind of keeps the other two ends glued together. And we call this the logical data model. And I just tend to think about it as the mathematical middle that helps translate between the way humans think about things and then the way computers think about things. All right, let's start talking about building a little bit of documentation. So typically, when I have to document an interface or I have to start building my data model, I'm given an ICD or an interface control document. And it has all of these tables in here that look a lot like we see here in message one. And in this case, we have this thing called vehicle pose data. Now, the point of, you know, what we're doing in our data model is we're trying to document the interfaces. And this is an interface express right here. So just for the sake of this paper and this presentation, we're going to use the semi-fictitious open-stove pipe standard version 42. Okay, let's start identifying some of the information that we see in the ICD. So the blue circles here are just some of the names that we'll use when we're actually building out our data model content. So maybe we would define our interface name as the same name as the message here. So we would use vehicle pose data. And over on the left, we have the attributes of the individual interfaces. So, you know, we may send an XYZ and a roll pitch yaw. Now, in the area here under description to this orange box, this starts giving us that human readable description that we're going to need to start documenting the content in our conceptual data model. Over here, we have the primitives. And this is where we're going to start capturing information that we would use in the platform data model. And then finally, over here on the right, we have meters and radians. You know, these are our units. And this is part of that mathematical middle, that GUI middle that defines that description of how the computer sees it now, people see it. Okay? We need to start building this into data model content. Now, let's just take and build out a naive translation of the interface. So as I discussed in the previous slide, we'll just take vehicle pose data and make a new entity here called vehicle pose. Then we'll move all of our attributes down into the interface. And then we have to do something here with this description. Now, notice I put these things over here on the right in dash boxes. This is still important information. But we're going to use it in the logical and platform levels. Right now, I'm just worried about building out some conceptual content. So how do we decide which observables to choose for our attributes? Well, this is why we have to rely on that description in our ICD. And if we look at X, it says this is the X position of the vehicle and Y, the Y position of the vehicle. So we can look through that list of observables. Again, when you download the shared data model, all of the observables are present. And you can try to pick the best match. Read the definitions of the observables and make sure that you are picking the right concept. What you might find in some cases is where you have roll, pitch, and yaw, this might say the roll angle of the vehicle or the pitch angle of a vehicle, which is completely acceptable for a description. One of the things you have to be aware of is that altogether roll, pitch, and yaw are representing the concept of an orientation of this vehicle. So you might want to be careful to not just pick the naive angle there, which radians might lead you to pick. Now, I have this notation down here at the bottom that says IDML4. So looking back to, I think, our 2018 paper on interface documentation maturity levels, this was a concept that we worked on inspired by TRLs to kind of talk about different levels of maturity in data models. And here, this is what we tend to call a message entity model, where we're just kind of doing a naive translation of the message into an entity. All right. So we've done a little bit of data modeling. Granted, I haven't shown you how to build out the XML. I haven't talked about how we're driving specific tools. But what we can do once we have some of that XML written, we can start doing a very simple validation using the DMVT. So uninstall, basically unzip and install the CTS and then start a command prompt. And what we'll do is we'll go into this phase 30 CTS conformance test suite DMVT document, and then we'll actually run this command prompt here. And what we find from the example is we get an error that our entity does not can satisfy the has unique ID constraint. So then we'll go back and fix the entity. And I have that slide hidden. But essentially what we'll do here, there we go, I scroll down, we can add identifier. And now we run this back through the DMVT and it's going to pass for us. As I mentioned, there's a lot of stuff I just didn't have time to cover. So I really talked about building out just the entities. And really when we do our documentation, we do our documentation using use. Or in phase 30, we talk about queries and templates. When we do this naive type of message entity implementation, it's really very easy to derive our views from the entities. It's kind of almost a direct translation. That becomes very easy. I didn't talk about tools. There are tons of tools that you can use to build this. It's not quite like an IDE. But I know Vanderbilt has provided some tools. We've used Enterprise Architect and we've used Cameo Magic Drawl. Scale also is a tool vendor. We have some products available. And there are other vendors within the consortium. And finally, I really didn't talk about model quality. So really the goal here is just to get you some ideas to just get you started. Really not building high quality models. This is just enough data model to get you going and to start getting some feedback from the data model validation tool. There's a lot more detail in the paper about how to clean up your entities and how you can do a couple of iterations to get to better model quality. OK. So I guess we have time for some questions. I'll just put a note here at the bottom. We've got some references from our previous papers. We have put out a podcast. The audio quality is a little rough. But we talk about some of these in just a live form with some of our team. And then we also have training. We can leave any further assistance. Great. Thank you, Chris. If anybody has any questions for Chris, if you could please put them in the Q&A and chat. I don't see any yet. But we'll give it a minute or so and see if they come through. Oh, looks like one just came through. OK. Chris, are you ready? Sure. OK. How do you handle versioning issues? If two systems implement different versions, or one system wants to update its version, with change field names between the versions, they may lose their interoperability to each other. This implies that one system may. And then the question stopped. OK, well, let me just take that first part. Sure. Oh, there you go. Oh, this implies that one system may valid to the data model, but not interoperable to one system. OK. So I'll take a stab at this one. You are generally, so when you're getting conformance to a shared data model, so if we just stay at that level, you are generally getting your conformance against a specific shared data model. So you will always be valid against that data model. If it changes in the future, you would have to rerun your conformance against that additional version of the data model. Now, if we're talking about managing larger data models, that's a much more complex issue. And that would be something we have to talk about in a larger forum, somewhere we have more time. Great, thank you.