Module 12 - A321a

A321a: Understanding User Needs for Traffic Management Systems Based on TMDD v3 Standard

HTML of the Course Transcript

(Note: This document has been converted from the transcript to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included.)

Shelley Row
ITS Standards can make your life easier. Your procurements will go more smoothly and you'll encourage competition, but only if you know how to write them into your specifications and test for them. This module is one in a series that covers practical applications for acquiring and testing standards-based ITS systems. I'm Shelley Row, the director of the ITS Joint Program Office for USDOT, and I want to welcome you to our newly redesigned ITS Standards training program of which this module is a part. We are pleased to be working with our partner, the Institute of Transportation Engineers, to deliver this new approach to training that combines Web-based modules with instructor interaction to bring the latest in ITS learning to busy professionals like yourself. This combined approach allows interested professionals to schedule training at your convenience, without the need to travel.

After you complete this training, we hope that you will tell colleagues and customers about the latest ITS standards and encourage them to take advantage of the archived version of the webinars. ITS Standards Training is one of the first offerings of our updated Professional Capacity Training Program. Through the PCB program, we prepare professionals to adopt proven and emerging ITS technologies that will make surface transportation safer, smarter, and greener, which improves livability for us all. You can find information on additional modules and training programs on our web site ITS PCB Home. Please help us make even more improvements to our training modules through the evaluation process. We look forward to hearing your comments. Thank you again for participating and we hope you find this module to be helpful.

Nicola Tavares
Module A321a is about Understanding User Needs for Traffic Management Systems Based on TMDD Version 3 Standard. The target audience for this module is engineering and planning staff, emergency management, public safety, traffic management center operations staff, system developers, and public and private sectors.

Your instructor is Dr. Raman Patel, who has 40 years of experience in the transportation field and has been actively involved in the ITS Standards development and standards training program and has served as chair of ITE's standards committee for the past 15 years. He is a member of the NTCIP and TMDD committees. Dr. Patel is president of RK Patel Associates.

Dr. Raman Patel
Hi, everyone. I'm Raman Patel. Thanks for participating in this training module for A321a: Understanding User Needs for Traffic Management Systems Based on TMDD Version 3 Standard.

There are two possible training curriculum paths we have in front of us today. The first four modules are common to both paths. This one here shows SEP, Systems Engineering Process, was used in developing certain standards so we have certain training modules prepared based on SEP content. And what that means for us is that those standards developed with SEP have already user needs and requirements and design concepts available in them.

On the other hand, there are standards which were not developed using SEP process, escaped the user needs documentation and requirements as well. So, we have to, for those standards, we have to actually identify and write user needs as well as develop requirements. So, you are seeing those modules here. For example, module following after 203 we are asked to identify for our devices so there are certain NTCIP device standards, such as CCTV, don't have user needs. So, this module, for example, deals with that kind of training process.

On the other hand, also similarly, requirements are not there so we have to develop them. So, these are the two paths that we have to follow. These four prerequisites are necessary for today's module and they prepare us in terms of backgrounds and everything else that we need to understand TMDD subject. In addition to that, we also have knowledge of this couple of areas here, particularly the one with the SEP discussion that we have in every module preceding this one. And also, the traffic management centers. Today's subject is very closely identified with traffic management centers. So, we have to be aware of what that means to us.

There are five learning objectives for today's module discussion. We have these two in front of us and these two learning objectives will allow us to explore what problem TMDD is addressing and how TMDD is actually meeting our needs. So, these two learning objectives will guide our discussion in that direction. Number three, for example, will tell us where the information is. We need to understand, in the structure, the standard structure, where this information that we're looking for is located. So, it will go through that process. Number four, NRTM, NRTM stands for Needs to Requirements Traceability Matrix. It is a table that we need to know how to use it, what is available. And also we need to learn how to prepare for our local project. Every project must have its own NRTM and today we're going to discuss how to prepare one for us. The last one here, number five, is to identify what kind of requirements we will have, institutionally, as well as technically, so that when finally the system interface is shaping up, we know how to use it or how we can share the information that we are passing through the system interface. So, there are certain conditional requirements that we have to go through and we'll deal with that.

So, let's start with Learning Objective One. So, what is traffic management data dictionary about? What is it? It's a standard. It's a high level standard. It provides us detailed descriptions, definitions of what the user needs are, and then requirements that fulfill those user needs. And then we also have the design that go with the requirements. So, it provides definitions that across the TMDD structure we will discuss in both volumes, one and two. The material provided by traffic management data dictionary is used to acquire, procure system interface. So, we have to write the specification. So, when we write the specification all of the three components user needs; requirements and data concept will be included. So, we are learning that process as well how to do that. And then finally, when we do have system interface design in front of us and then eventually gets built or implemented, at that point we will know how this supports our operational needs, center-to-center operational needs. And that starts with user needs.

So, traffic management data dictionary is a standardized way of looking at high level definitions. There are two definitions that we will go through. One of them is here: centers. The structure of the standard is based on the definition of external center, who's the external center and who is owning the center. An external center is the one that makes the request to the owning center. The owning center has the information storing their TMC all in their system and, in fact, they have direct control of the field devices. So, they have everything that someone else wants. So, external standard can be defined as someone who is making a request. An owning center can be defined as someone who holds the information, has the information, and is willing to communicate with each other.

So, those are the definition of centers we use. Interoperability is widely taught. In fact, TMDD exists for interoperability. We want to make sure that we understand the meaning of interoperability in the context of center-to-center. So, this is a standard definition of IEEE standard-based. And what it means is that the ability of two or more systems or components to exchange information. And then use that information to exchange. In practical terms, what this means is that my system can talk to your system and we can both exchange information. And then we end up using that information to our mutual advantage. That is the whole theme or aim or goal or objective of achieving interoperability among centers.

So let's have a little activity here and see what you think, why centers desire to communicate with each other. Can you just tell me something in the chat pod? Why do you think it's a—anything? Okay. I will say, well, we want to share information. Of course, yes, that's a very good answer. To share information, to share data. We want to inquire what is happening. We want to know current conditions, maybe. We also want to know what is a planned event coming up. A lot of different things come up. Situational awareness, yes. What's going on? It's very much part of the day-to-day management. These answers that are coming in are very good because they are real. And also real-time information. When I said right on it, it says real-time information. So, a lot of these things require center-to-center communication and in terms of real-time application or what is happening in current condition-wise.

So, let's look at the process of how communication can occur. For example, without the standardization process there are five centers shown here. They may be talking to each other with the proprietary solutions, all right. And these proprietary solutions are very complex. They are very expensive, costly. They're difficult to maintain and they need expertise for all of these things. And you end up with one interface for everybody else. So, on top of that, it is a clumsy way of handling day-to-day operations. And we are trying to get out of the situation using a standard-based approach. If we use a TMDD standard and develop a system interface, we escape all of the other things that we just said in the sense that we now have a common interface and it's less complex because standard has already defined all of this definition provided to us. And we based our system interface on standardized process. So, that is an advantage of using a standard-based interface.

So, what is a system interface? A system interface is a boundary with the local system. So, we have a local system. It could be any system here, 511, 911, a traffic management system, or a freeway management system. And this system interface makes a boundary with the local system to exchange messages in and out, messages that are coming in from another center and messages go out to that center. So, this activity, to exchange information, you just mentioned earlier in the answer, the real-time information. Coordination of emergency management, that was another answer. And control the devices of other centers, that was also another answer given to us. If you put those two situations here for each one of these activities that you mentioned, we will require messaging between these different centers, and that's what system interface does.

Here, in a regional sense, we understand where the system interface is located. So, these are two TMCs, for example. These are fully blown, probably a large size operation. But the system interface is seeing each other and they are like in the front. So, what happens is that this messaging taking place between the centers has specific purposes. And they request to each other, in this case, both arrows are okay. So, we get the messages in and messages out through the system interface and we make connection to the local operations in both cases. And we end up doing this thing to help us manage. How do we use the system interface? Well, we manage the assets, like you said, control each other's devices, for example, here, all right. We want to know current condition, what's going on, a situation awareness. We also want specific information. And all day long, we keep asking questions and looking for the information, and we can get it. So, in general, we would like to say that asset management, there are a lot of things out there in the field, and then we want to make sure that we have the ability to communicate with each other so that we can manage them better.

So, to do that in our procurement process, we have to include user needs, requirements, and design concepts. So, what is a user needs in general? User needs answer what, what are our needs, specifically what we need so we can alleviate our problem or situation on hand. All right, so, that's what, the “what” part, is handled by user needs. Requirement is a little more detailed, quite a bit more detailed and they are written in “shall” language. They must be because they address the functionality across the interface. So, the requirements must be detailed enough so that we can actually begin to allocate them to these user needs. So, they are tightly connected to each other. Okay.

So, requirements now are fulfilled by the design concepts. That's the third element we have in the standard. For every requirement that we have, we also have a design that goes with it. So, on that part is what the design concept is handling. So, these three together, all of them together make up our specification. So, we have to include them in the specification. I would also like to say that when you are exchanging information with each other, with all of us, those who are involved in the exchange process, will require same user needs, same requirements, and same design concept. We'll discuss that as we go along.

So, let's summarize Learning Objective One. TMDD is here to help us get the system interface. So, TMDD is recognizing that there is a need for common standard-based system interface, and it provides all of the material that we need for specification. So, there is nothing much we have to do beyond what TMDD is offering us. So, we are pretty much self-sufficient in terms of what we need, what kind of building materials we need for system interface design, all right. And then we have to recognize this also Learning Objective One that if we do want to communicate with each other we have to have a common set of user needs requirements and data concepts in our specification. That is the only way we can get the interoperability which is the ability to talk to each other.

Let's have another activity here. What operational needs you think the TMC may have? Go ahead, please, respond in the chat pod. What comes to mind that might present it as an operational need? Okay. What is under DMS? That's a very practical inquiry. What's going on? What is out there? What's going on? What message you are showing? So, that also gives you the ability to make management decisions. The answer here is exchange of incident information, incident information, location, direction, which direction is affecting traffic management. All of those things might be also of mutual interest to each other. The search nature of inquiries also helps us. So, what the TMDD has done, I've categorized these user needs based on what are the real practical needs out there, just like you mentioned several of them here.

There are eight categories of user needs classified by TMDD standard. The first three here you are saying they are about the managing network. These three help us manage network. We've got to make a connection with each other. We've got to make sure that we are talking to the right people, you know authorized people. There may be some restriction also along the way. And then who are we talking to, what is the name of the organization, and so on. So, these three user needs categories deal with basic starting a process. Okay. This next set of user needs categories deal with the real thing, just the way you mentioned before, that there is a need to have situation awareness. What is going on? There's an event out there and what is happening? What is the roadway description? What roadway? What direction? What exit? All of those different things. Also providing control of devices, TMDD has provided access to about ten field devices such as DMS, CCTV, ramp metering, and so on. So, such capabilities are located within this structure here. Also sharing data from each other. I like to have what you have and I can give to you, what I have, that kind of things, you know, that happens between the centers, agencies. And we use that data for planning purposes and so on. The last one here is the null values. When you ask something and there is no answer to give it to you, there is no information available or it's not applicable, then we have provisions in these user needs also to send you a zero value, meaning that I don't have much of anything to send to you. All right. So, there are provisions in there. So, eight of these categories make up the user needs presented by TMDD.

Let's take a closer look at some of them. As an example, this is a connection. We need to make connections. This we have to log in and all of that process takes—the system-to-system communication, so we verify the communication connection, and then we begin to have our conversation. So, the conversation will take place with subscription maybe, you know, when something happens, give me the information, that kind of need you might have like you said about the DMS message. What is the current message? Please let me know. Some of those inquiries can be done once you set up the connection and all of that. So, that's one user need.

This is the real thing in the sense that there is an event in progress. And this external center is asking the owning center at TMC, maybe, and say please give me the current update of the information, or current information on an event that has occurred. Its location may be an accident, how severe it is, and what is the status? Has it been clear or is it in progress? All of those things. Also, occasionally, we also have a need for planned events like stadium events or parade or any of these other musical events and anything happening in the town or region we need to know ahead, and that helps people plan so that they can allocate resources accordingly.

Another need that could be looked at in this overall context is that of sharing data about the route, the roadway description, the link, node, accident direction, a lot of things happen on roadways. So, we have to have a way to describe all of those things and that's what this need is about. So, this is one of the very basic needs that we all have in terms of describing our roadway network. If you notice here, for example, in this diagram, we are saying 15 minutes time to go to the stadium. So, this is also computation. Based on the information we get about the roadway network centers can also calculate the real time travel time in real time. It could be 15 minutes now. Moments later it could change to 20. So, that kind of ability is also available between the centers. And then this information goes to other people as well. It could go outside to 511 or some of the people who have a need for current information. It could be on the web as well, on the internet, the webpage.

This example here about a DMS, like you mentioned before, needs to play new message in a remote DMS. Something happened in the jurisdiction and all of a sudden you are in a situation where you want to deal with a larger event and ask other people to help you. So, you might say, well, can you put this message for me? You know, that kind of need is out there and this is what this need addresses.

Data archiving: we all collect data. And we all know that ITS is very data hungry, the more the data the better also in real time, current data. So, and if I have collected data, then you can have it. So, this exchange also is possible within the TMDD structure. So, you collect one and you can use it multiple times. Or one agency collects and all of the other agencies uses. So, these abilities are presented by TMDD user need in this fashion.

Let's illustrate some of these things. Here in this illustration, we have a need to exchange information and in a real time basis, right now. So, for example, this transit center is asking, requesting a traffic management center about this event that has occurred so that they can make a management decision informing their resources in this case, this is a bus driver. So, they're saying what is the current information about an incident that has occurred in your area so we can inform these people. So, this center will make a determination and they will verify the event because they want to make sure that what they're saying is current, right. So, they will verify with the camera that they have, and then they will tell the center, requesting center and say “Hey, this is the current information. This is what's happening.” Based on that, this center, in return, will provide that information to the bus driver, for example, or somebody else, maybe a maintenance crew out there, on any of these possibilities are out there. So, this whole loop in terms of information processing, is out there, and this is done in real time.

In this illustration here, we now have the ability through TMDD-based definitions that we use in the structure system, in the system structure, is that not only we can make a request to display a message on another jurisdiction remotely, right. So, for example, the TMC is sending a message to this TMC and say, we have a problem in our area, but can you help us putting an advanced warning message on your side of the boundary, in your jurisdiction, to let people know that beyond exit nine there is a problem? So, a lot of people can probably take exit nine and go out some other direction. So, it could be a bypass of any nature. So, this center said, okay, that's good, because we want no congestion here as well. So, it's a mutual benefit for everyone. So, this process of sharing field devices is at the heart of TMDD. And there are 10 different devices CCTV, for example, dynamic message sign, environmental sensor stations. In recent times we have been situated with the flooding, right, and it's very common, now, to have floods. So, somebody may want to know flooding conditions and therefore, we have environmental sensor stations all over the region. So, those ESS or environmental sensor stations kind of information will also help each other to avoid, or to make a better decision in terms of managing traffic in the field. So, this illustration tells us that information exchange is possible and controlling devices is also possible. And we can also describe the network because we have the user needs. So, a lot of these user needs that you saw under those eight categories are present behind this illustration.

So, let's review operational needs in terms of what we said we will do. We have eight categories of operational needs, and all of them are addressed by TMDD for interagency communication, and here they are in terms of listing. We went through some of the examples. The last one, as I also mentioned, sometimes there is nothing much to send, or nothing much available to send or maybe simply cannot be sent. In that case, we also have a provision in the user needs to handle that part of the information exchange process.

Coming to Learning Objective Three, what is the standard offering us? Where is the information? So, for that, we need to understand what the structure is providing us. So, there are two volumes TMDD has.

Volume one is titled as Concept of Operations and Requirements. They provide the definition and in the sense that what is to be done? Everything we need to understand as users, what is to be done, is here in this volume one. Right. The first section deals with the beginning introduction and all of that. But the second section takes over in terms of user needs. Some of the operational needs that we discussed before are present here in the sense that every operational needs is now reflecting in a specific definition of user needs. So, this is a good section for our discussion today, because they are organized in the sense that those categories that we have seen before, you know, that are device-related user needs, there's information-related user needs, network connection-related user needs, so all of that thing is present in section two. Similarly, for the requirements part, section three deals with them also in a very organized way. So, for every user need, there's a requirement, and they meet in section three. Number four is Traceability to Architecture. Very often we want to know how well TMDD supports architecture. And we want to know that the market packages in national ITS architecture, the way we are very keen to implement. And we need to know whether TMDD helps us or not, and the answer is very good, yes. The answer is that yes, that it does offer enough data flow so we can talk from TMC to TMC, or TMC to 911 center. It doesn't go all the way in terms of architecture flows, but it does provide enough data flow support so we can get two important things done in the center for center context. The last section is NRTM. NRTM is a matrix, as I said. It goes over a couple of pages, not a couple of pages actually. It's a huge table that outlines all of the user needs and the requirements together in one place.

Volume two answers how it is to be done. It's a design concept. There's no discussion about concept of operations or anything. It simply gives you all of the design material that you need. So, this is a very large volume and has a very specific structure to it. Dialogs are necessary to initiate the conversation. Messages are the conversation between the two systems. Section two deals with that. In section three, we are actually getting the data concepts, definitions, based on there are two formats. One is the ASN.1 format and the other is the XML format. And both of these formats are listed in volume two. We can only use or the other. We cannot use both together. Okay. So, we cannot mix them. So, that part gives us a detailed definition of what design concept we have to use. The last one, section four, is RTM. RTM is the connecting points to design concepts. It connects requirements and design concepts so it makes a focus of the whole design process. And we need to know both RTM here and also NRTM in the volume one.

So, as a volume one and two together what definitions are available? What does the inventory look like in terms of size and shape, for that matter? So, you can see there are 126 user needs, a large number of requirements to meet them. And then also very large number, 600 here, that make up the design concepts. So, these are actually data concepts. Data concept means that they are broken up in pieces. The first are dialogs, then followed by messages and data frames and data elements. This is the smallest unit of data or information that we have in this arsenal. So, this is the inventory of what TMDD offers. And we can meet practically any needs that we have based on what the standard is offering. So, when we design the interface, we are actually taking what we need for our local project. Okay. So, we are not using everything that's in here but we are taking whatever that meets needs in our local project design.

There are two relationships we need to understand: the relationship between the user needs and requirements is through NRTM. In other words, we are not doing our own thinking and saying, well, how are they connected? The NRTM tells us how it's done. So, we have to use an RTM that's in this volume one. That is the way it is. That is how we use the standard going through the NRTM. And then RTM will connect us through user needs to requirements. Similarly, volume two has RTM in it and RTM will connect us from requirements to the design concepts. Again, we are not doing anything on our own. We are following, simply, what the RTM is guiding us, all right. So, we have to make sure that we understand this relationship.

Summarizing Learning Objective Three. We have understood that an RTM provides mapping capability. You have operational need in your hand and you are going to volume one, and you are looking at that section two in volume one and you are mapping. You are looking at it and say, “Okay, this one meets my operational needs.” and you are picking that user need. Okay. That's how it works in that sense. Then, we also realize that requirements do exist for good reason. They exist because user need exists. If there is no user need, there is no requirement. That's what traceability means: that every requirement is traced to at least one user need.

Then we have the NRTM concept which gives us the relationship between analyzed definitions of user needs and requirements. So, everything is standardized for us through NRTM. Similarly, the use of RTM is very important. We need to understand and we have concluded that every requirement is now traced to data concepts, to RTM. Again, we are not going to do our own. We are going to simply follow RTM in the standard and connect to these data concepts. All right. So, this relationship is also standardized by RTM between the requirements and data concept. So, we can say the design is standardized to RTM.

TMDD promotes off-the-shelf interoperability. What does that mean? If the two or three or four users all use standardized definitions, standardized data concepts, we are now reaching out to gain off-the-shelf interoperability. We are as close as we can if we start using standardized definitions from the TMDD structure. So, Learning Objective Three has given us enough information where it is and how to use it using NRTM and also using RTM. So, that's the conclusion that we can make on the Learning Objective Three.

Now, moving on to Learning Objective Four will ask us this question up front, say, well before we go on to the details, let's ask this question: where is the user located on the lifecycle process? And if you remember that we are following a system engineering process to develop an ITS project. And this thing begins with concept of operations. And there's an earlier step also, step one, for example, is the general architecture. So, we have the architecture done. Then we come to concept of operations and we begin to address the user needs. That's where user needs are located. So, the answer is that NRTM on page 174 to 295, that's where the user needs are listed in terms of what we need to do to go ahead and understand NRTM-related user needs. So, this step is very clear, saying that if you are thinking about NRTM, please go to page 174 and begin to read NRTM in the standard. That's what this diagram is telling us.

How does NRTM look like? Well, NRTM has two parts. The first part here says “What is to be done?” What needs to be done is what is answered here in the first three columns. These first three columns are about bringing major desired capability to the table. What is that user need going to do for us? Okay. So, we have now addressed why we want it, why that user need exists, for example, and what is that we want. So, this “what” portion is handled up front by NRTM. There's a user need ID number, a specific number. There's a title of the user need. And you as the user, the project manager, you will have to select yes or no, whether you need this user need or not. That is also the decision. So, this is the role for the user, all right. We are actually making on our own. Sorry, we are making on our own what we have to do. Then the standard takes over in this part.

The second part is the requirements. This is the detail. The detail about requirements is in the last five columns. Here, again, requirement ID will show up and the name of the requirement by the conformance, whether it's required or not, support, yes or no, and then other comments that you might have. So, NRTM has eight columns and multiple rows. There will be more rows.

Let's look at in a real example way. The content of NRTM has now said, “I go to my volume one and I read the user needs, and I connect by mapping my operational needs to it, and I come back with this number.” All right, when you do that, you are coming up with this number and saying that there is a user number 2.3.6.4.5 which meets my particular need, and therefore, I'm selecting it. Okay. So, you are doing actual selection here. So, now, you've done your part. By the way, there is a title here. I didn't put it here because there's not enough room but there is a title for every user need. So, you are now completing your work here. And then you look at the standard, as soon as you have this, NRTM also takes you to this, it's connected. You're not doing anything on your own, or we are simply following this and saying, “This user need is connected to this requirement.” And also this column, conformance column, says it's M. M means mandatory, all right. It's required. The standard has determined that. And then you are selecting yes because the standard has said M, you have no choice. You have to select yes. Everything M gets selected as yes. So, this is what you've done. This is what standard is doing for us. Standard is helping us very clearly, all right.

Let's look at it in a little more complete way, saying that the requirements are traced to user needs, right. We saw those numbers; work is monitored at every stage. In the SEP process, the NRTM will help us where the requirement is addressed or the user needs are addressed, in the sense that we are asking this question. Are we addressing user needs or somebody forgot about it? Or is it put on the side or something? That ability, again, through NRTM, to monitor your user needs, we are getting through the NRTM. So, at the end of the process we will also ask another question: did we build the system right, or the right system? In this case, the right system is the correct way of asking. These user needs are included so when we related our system at the end of the process we can get it through this. So, there are three things that NRTM plays a very good role in.

Let's have a little activity here. Who do you think benefits from the user or NRTM? And you put it in the chat room. Okay. Owner, programmer, user, stakeholders. It makes it easier to select needs from a list. They are very good answers because that's what it is. That it is a list—NRTM is a list. It is coming in front of us and it says you cannot miss me. Everything that you need to know is here in NRTM in terms of user needs. So, these are very good answers because users and stakeholders are making sure that their needs are matched. And that is the one way to look at it and come back to that.

So, let's summarize here the beneficiaries of NRTM and say that if you are a specification writer, requirements is your main concern. You want to make sure that everything that your project needs is included in it, all right, so you're not missing it. So, you will be looking at from that view and come back with answers and say yes, I took care of everything. I'm sure I have everything now. I asked everybody and we got it. NRTM will guide you in that process. If you are an integrator, implementer, consultant, system engineer, whatever, the title you come back with and you have the responsibility to implement, you know that there are risks in the projects. All right. You know that you don't want to miss something. You also know that if you miss something and you're trying to fix it, your relationship with your client will also go somewhere at a different level. You wouldn't want that. A lot of times the risk management is looked in that sense of how can I be sure so my client is happy and I'm not missing anything in the system development. And we all get the system that is needed to be done is done. So, the assurance of managing risk will come in a big way through NRTM. If you are a supplier and you interested in selling more products to clients, you will be always looking for what capabilities are out there, what capabilities and what functionality the client wants. And when you look at the NRTM, it's omnipresent. It tells you that what these needs are about. So, you understand the structure a little better in terms of marketing standpoint. Finally, the ultimate user is the one who is going to be suffering whether anything is missed? If you are a user, you want to ask that question. I want to make sure that I have talked to everybody around me. I looked at all of the different centers around me, my jurisdiction as well as the neighboring ones. I'm not missing anything. In fact, interoperability is the reason why this project is created. I want to be able to exchange information with other people, right? So, you ask that question and say is there anything missing here? And you examine these things in a very careful way and you also go back to your other projects. This is a chance for us to look at other ongoing ideas project and say well, while I'm doing this project, am I affecting that other project? Or are there benefits of coordination between the two projects, three projects, whatever the numbers are, right? So, that question can also be asked in terms of users' needs and making sure that interoperability doesn't suffer. So, the benefits are in all of these four areas and they are for everybody that you mentioned. And you had a pretty complete list of people, users, stakeholders, consultants and everything. So, that's good.

Now, let's look at how interoperability gets used. Desiring interoperability is one thing and achieving is a little more. Carefully, we have to understand that concept. So, what are we doing here in terms of achieving interoperability? How do you achieve interoperability? Well, let's say there are two centers here, the way we have shown them here and they want to exchange information in real time, right. So, you ask this question and say, well, what is interoperability? And I said in simple terms, in practical terms, we can say, well, I want to be able to talk to you and you should be able to talk to me. All right, so go back to the original definition from IEEE and said what does it say? It says that two systems should be able to do exchange information or two components exchange information and use that information so exchanged, right? So, in two parts, this definition is coming alive. And so we ask this question and say well, which requirement will make sure that this happens? So, the answer is user needs. User needs are a first step towards achieving center-to-center interoperability. And I keep repeating this thing, again and again, because this is the only way we can be sure that we have interoperability to user needs and therefore, NRTM. So, what happens here that in the NRTM process there will be user needs that we will have from one to end, for example, and in between. So, these user needs identified are present in both specification here and here. If you do have this subset of information, user needs, present in this specification at both locations, both centers, then you have taken the first step correctly. Again, for getting, making sure, ensuring interoperability is obtained, we have to have the same subset of user needs. Same subset of user needs will arrive through the NRTM. That means that you as a user will have to select yes. We have to select yes for one user need here, number one. We also have to select anything in between. So, when you do your NRTM, this will make sure that everything you're looking for to exchange information is present in these user needs. All right, that's why this sentence is very important. That user needs are the first step towards achieving interoperability.

Let's see how we can do it. So, there are two types of user needs out there in the standard. Those are mandatory user needs by standards. They have been determined by standards that absolutely minimum they are required. There are six of them and they are listed here. So, you as a user preparing a specification, we always have to select them yes. There's no choice here. And if you look at them basically as we had discussed earlier you need to know who you are connecting too, right? So, there's a connection management issue here. So, that's got to be mandatory. Then you are actually making request. So, that's the whole reason why you are designing system interface so that has to be mandatory. Then you are supporting errors. Occasionally, there are errors on either side and so therefore this is necessary. And then you need to describe a roadway where things are happening, where is the node, where is the link, all of those things will come to such a user need. So, that's present in this one and two here, one and two sub needs. And then finally, as I said, there's nothing much to send. I don't have anything to give to you. And then you cannot keep sending me message that says please send me. So, to take care of that, we said there's nothing much to send, nothing is available. So, such nature of user needs have made them mandatory. So, now not everything is mandatory. Most everything is left to the user to select. So, here in this example, you are selecting. You are selecting to say, give me information when it's available, subscription, right. You want to have information from another center on occasional basis or when it's updated. So, a lot of the subscription is “yes.” If there is a correlation between one event to another, then it's also selected “yes.” Multilingual: this is probably not an issue for everywhere, location-to-location things differ. But if this is required, then you have to select “yes.” All right. And then the current information, this is one of the common user needs that's present in most designs and we select “yes.” So, detector data, for example, is also selected here. So, what this tells us is that optional needs are based on projects' operational needs. It's a project that decides not the standard, okay.

So, let's illustrate that. For example, here centers are looking for interoperability, right? And this example is telling us that there is a need to display a message in a remote DMS. This DMS is owned by this center. This is a similar example to the previous one we discussed. But here we are putting user need in front of it and say, well, what really take this to happen? What particular user need will make this thing happen? And that's what this thing is. 2.3.6.4.4 actually deals with displaying message on a remote DMS. So, now if you want that capability between those two centers, and both of you have agreed, both centers agree, then this user need must be present in those specifications here and there. All right, so we want to make sure, one more time, that everything you want reflects in the specification because the interoperability demands it. So, that's the example that we have.

So, now, we are coming to a point where we have to figure out how do you actually prepare a project NRTM. Okay, so we look at the volume one and volume two, and we discussed earlier what they offer is three things. They offer user needs. They offer requirements. And they offer data concepts. This is what standard is offering us, alright? And we know that we, at the local level, our projects are different, every project level, every local-level project has a different need. So, standards has a lot of things in it but we don't need all of it, so, now you have to prepare a project NRTM. Similarly, you have to prepare a project RTM. We are talking about this thing today, and the next module will address RTM in the same way. So, we already discussed earlier that user needs and requirements are connected through NRTM.

So, what do we do? Well, let's take a first step and say I have this step that's telling me to take my operational—because that's the only thing you know as a user, just like you give some answers in a chat, that's the only thing you have—and say look, I know what my need is. I want to make sure that I'm able to put a message on other people's device, or request to put a message on other people's device, a dynamic message sign, for example. So, that's my operational need. So, now, how do I go to the standard volume one and relate that operational need? And that's what step one is about. This is a very basic requirement that we all have to go through, need. So, step one says you go to section two. In the section two of volume one, you'll find page 22. On page 22 you're going to match your operational need and you're going to read that it reflects, it is reflected in 2.3.6.4.5. That is the number you are picking. This is the first time you will see a numerical assignment to a user need, all right. So, you are walking over with a great deal of information from volume one when you pick up this 2.3.6.4.5, all right? And each of these things are unique. They are not repeated. So, this number is unique throughout the process, all right? So, you feel very good about that. And say, okay, I got what I do it for, I need. And now I'm ready to go to the next step. Now, while we are at this discussion level we should also ask what does need do? What this user need actually does for us. And the answer is rationale. To answer that question you have to understand that it supports the congestion management or traffic management, all right? So, every user need also has this rationale in it. This is the capability, major capability, that it brings to us and this is the rationale. This is what we are looking for and why we are looking for, reflected here. So, when you analyze all of these things about user needs, this is going to come to you. For every user need, you're going to go through this process and say, I know why I want this thing, all right. So, section two has the similar approach for everything else. All of the user needs are lined up that way because every user need also has some rationale in it. It has the description right above the user need, right? This one shows up. This is exactly how you will find it in the book, in the standard book, right? So, this rationale also appears there on the top. So you will read it and understand, and then you will confirm and say “Yes, this is the user need that I am looking for,” all right? So, that's Step 1. And if you take Step 1 correctly and properly, chances are very good the rest of the process will be easier, okay?

All right, so this is the Step 2 now. Let's go into Step 2. We picked up these 2, 3, 6, 4, 5. It had a title. It had an ID number. It had a title and you selected “yes” because that's what you want. So your part is pretty much done here, right? As soon as you say yes, you are now ready to let the standard do the work. So, what do you do in Step 3? You go to Section 5 and you'll find this. You will find this requirement listed in this table, right, and it also says “M”: means mandatory. That means that you have to now enter “yes” alright? So, you will enter “yes” because it's mandatory that you have to require that now. So, Step 3 is allowing us to fill in the requirement part. Step 1 allowed us to fill out this first part, right? So, three columns are done under Step 2. The last five columns are done under Step 3.

Now we go to Step 4 and say “Well, this whole bigger picture is emerging.” The particular user need where I selected has 10 requirements. I'm reading 10 requirements on this page, and that's what you are entering in Project NRTM. You are literally taking what the standard is telling you. You're not making any judgment calls. You are not deciding anything. You are not questioning anything to comply to the standard, or to go what the standard is guiding you with. You have to go through this process in Step 4. So, you are now entering in your Project NRTM; so you're populating gradually, okay? So, and this is for only one user need. If you have more than one user need, you know, we're going to extend in other rows, okay? So, now, let's continue. Only two of them in this 1 and 2, here, are marked “mandatory” so you already selected them. Similarly, the bottom four are marked by standards as mandatory so you have to select them. Now, what about these four? What about these four, here, in the middle, right here, right? The standard says to you “If you want all these four you've got to select “yes.” If you don't want them, that's fine.” So, now you have to read this description. There is a pretty good description, right, for all four of them. For example, this one says “Name of the operator.” Who was the operator who got your request? If you want to know, then you've got to select “yes.” Standards doesn't say you require it, you know, you are required to have it, but you will say “I need to know who I'm talking to,” right? That's reasonable. So, you will most probably, and I'm making a judgment call on your behalf here, but as a user, a common user will say “I want to know who that operator was that got my request,” alright? The next one, for example, is a little less important because it says, “Who was the last operator who locked that information?” In other words, you cannot put any message on that particular dynamic message sign. Who made that determination on the TMC? If you want to know that person's name then you will select “yes,” right? Otherwise, if you don't care for that much detail, this will not be necessary, okay? Then there are additional information. For example, this one here is the last person who logged in the information, and then there is the name of the organization and contact. So, some of this determination is coming from who the people are, who the organization is, who made that judgment and logged the devices and so on. So, when you understand this by reading the description, and this is a nice description, they are long enough to understand what they mean, and that will allow you to make judgment here and make them. Is it M,M,M,M? Or O,O,O? Whatever it is, right? So, since I'm reading page 24, this is the reason why they are showing up M or O. When you do your Project NRTM, only mandatory will show up because this is mandatory, this is mandatory, this is mandatory. Once you select “yes,” they become mandatory. So, for Project NRTM, in this example, everything is M, alright, because you select it, and you can only have mandatory or optional. You cannot have both, but when you write the NRTM, it disappears. This thing is not necessary or it will show up mandatory. So that's the distinction we make. This is a very important step, because if we understand this process now, we are ready to fill up our NRTM in a full way. So, that's what happens in terms of preparing Step 4. Again, each user need is linked to these things by the standard. We as a user, specification preparer, have no responsibility in trying to come up with your own requirement; that does not happen so we just simply follow a standard and come back and fill up these things, all right? You have a judgment call to make here to decide which one you want or you don't want. That will happen after you read the description here and then you decide, a very simple process.

So, summary of Learning Objective 4 is now telling us that there are at least five key concepts that we walk away in terms of Learning Objective 4. First, Learning Objectives are about where the user needs. Learning Objective 4 told us that user needs are located in SEP at a concept operation stage. This is a very basic step. We need to make sure that we understand what the concept is. We need to understand what the operational requirements are, or needs are, I mean, and also understand the context, also understand the rationale: why this user needs are required or needed, you know, and that you will understand only going through the concept operation stage on a V diagram. This is an opportunity for us to review why this project is created, what the operational needs are, and the whole context. And also, I mentioned earlier, that one project is mostly likely, is connected with other projects so those things are also present in terms of operation, you know, we don't develop one project at a time, independent. They are all connected in some ways to each other, okay? So, that kind of knowledge base exists in concept of operations, and that's what we find in the V diagram at the user needs stage. Second one, user needs are mapped. User needs are sort of—operational needs are mapped to the user needs using Section 2 in Volume 1. So, that's what we learn in this discussion, that NRTM is located in Section 2, and we should straightaway go to NRTM and extract our user needs the way they have been described. Now the descriptions are pretty authentic because they have been done by the experts based on the input from the users across the country. When the standard was developed, there was a lot of input distilled from practitioners and TMCs and operators, and therefore, these users' needs descriptions are pretty much mapping why they match. So, you will find interesting that it's not as hard as it might seem like matching operational needs to the user needs in Section 2. Also, I find it's very interesting, because it has a range of user needs out there so when you're looking at something you might be interested in understanding why the other needs are there in the Section 2. So, that's the second advantage of NRTM in that sense. Also, NRTM is addressing too—it addresses every requirement to at least one user need. Now we saw this in the example that we just discussed: one user need produced 10 requirements, right? So, we know which user need did that. So, if we didn't have NRTM, we will have a hard time figuring out, you know, but NRTM actually places every requirement to at least one user need; so that part is good. Mandatory user needs, they must be selected. The standard has minimized the number because you cannot make everything mandatory or most of it mandatory, right? So, then this whole concept is based on what is the bare minimum for conformance? So, this word I'm using here, very strongly, because I want to make sure that to conform to TMDD version 3 standard, you must include all mandatory user needs, and you're going to do that through NRTM, alright, by selecting “yes” in your Project NRTM. So, that's very important. Last one, an optional user need. If the optional user need is selected, then whatever the standard says associated with it are also mandatory. Okay, standard is not saying that you need this, this, and that, in terms of user needs, but if you select the user needs, standard has already outlined particular requirements that go with that. That means that they become mandatory for you. So, collectively, these five concepts make up what the NRTM is doing for us in terms of user needs, and that's the way Learning Objective 4 guides us to prepare our NRTM.

We are now coming to our Learning Objective 5, and in Learning Objective 5, what we are saying is that, “Okay, we've done our homework. We've prepared the Project NRTM. We went through the design process.” By the time we come to realizing that we need to make some preparations, because System interface implementation is not going to occur without some kind of understanding. So, this Learning Objective 5 has allowed us to discuss what kind of pre-arrangements we will need. What will it make? So, eventually, system interface implementation will be successful. So, to understand let's take a look at this diagram here. There are three centers shown, for example, here, and in terms of their context of operation, this is a 24/7 operation. It could be a 911; obviously they're open 24/7, right? This one here is 9 to 5, maybe a small city traffic system, maybe a couple of cameras perhaps operation-wise; so it's the nature and the extent of the operation may determine their hours of operation. Then you have statewide operation perhaps, district-wide operations, regional centers, they're open 24/7 and their responsibilities are over a larger area, right? So, if you put all of these things together and then say “Well, if we have to talk to each other, for example, and every one of us has different mission objectives, in fact, we have somewhat a different customer base maybe, obviously, in the 911 center has a different focus than Traffic Management Centers, right, in responding.” So, all of us are now asking this question, and say “Well, how do we get this thing off the ground?” right? So, we have to come to some conclusions and understand what needs to be done. So, what would that be?

Let's have a little activity here. What do you think should that be in the pre-arrangement? And you name some in the chat pod. Go ahead please. Is that okay? Okay? This is an administrative issue like network URL, network firewall, security, maintenance; administrative issues we had to iron out how we're going to actually make this thing happen. So, a very important point that you raised. Also we have to agree on a common protocol. How are we going to communicate to each other using which protocol? You cannot have two different protocols, you know, we'll talk about that in a minute, so that's another one, that's a good one. So, there are pre-arrangements that we will have to develop and understand these issues both network management issues, limitation on information exchange. Some of the information perhaps you want not to go beyond your TMC, you know, a lot of people feel that way.

So, at the end of the day, we have to agree what is available, what could be made available, and things like that, we'll have to put down on the paper, right? So, the first one I would present to you saying, MOU, Memorandum of Understanding. This is a very common instrument out there in the public sector right now, that people say “Okay, meeting of the minds.” You know, that we have centers, we know, who has what, and after talking it over, we say “Okay, this is how we're going to do it,” all right? So, we have some kind of understanding how we're going to make the requests to each other, what we will provide to each other, what we will limit, you know, and, in fact, we can promote and collaborate with each other. So, eventually, MOU will help each agency's center, not only in terms of planning and design, but also improved communications will result in improved coordination, and once we know these benefits, then we can also say “Well, we're going to collaborate. The next project maybe we have shared devices.” So, a lot of these good things are at the beginning when we look at the MOU; you know, it allows us to put our views together, it allows us to discuss our conditions, you know, and it opens up minds. MOU opens up public agencies' minds and says what the possibilities are; it fosters, it promotes and, eventually, it will go somewhere. In the beginning, it may not be that easy. So, for example, in this Florida DOT District Four MOU, you can see that it provides a framework. So, what is a framework? Framework is a very important word in ITS, because it accommodates everyone's collective needs, all right, mutual benefits, and common purpose. It reflects in the MOU. So, the framework is flexible. So, it's designed to make it work. It's not hard so that it breaks, you know, sort of, but it is soft enough so that everyone's aspirations and everyone's wishes are reflected in MOU but it takes time to develop. I would also say that, by the way, someone who knows how this works in a big city environment, when you have more than one agency doing it. So, we all have gone through these situations one time or the other, but we can summarize these things, saying that MOU fosters maximum communications, because it begins in a gradual way, and eventually it lands somewhere. So, that is the message I will give through this MOU example.

There are agreements out there that they're a little more elaborate than MOU perhaps, in a realistic way and they are written somewhat differently; they are written in their various language, you know, like shell language, that kind of thing, and just like you said, it has a network administration. You know, there was a very good answer about firewalls and URLs and who will maintain what; who has the maintenance responsibility. Can we share the cost, which is another issue now popping up; cost, everyone's trying to reduce the cost, operating cost, maintenance cost, and that then needs to be handled. So, collectively, network management and administration, authentication procedures, all these things reflect in that category. The Standard Operating Procedures has its own place, SOP. as we see. SOPs are the instrument with which the TMC operates. This is one of our declarations that if there is nothing written in the SOP, somebody has to make a judgment call, but most TMC operations are conducted with the SOPs in a very organized way. So, it brings to us right away saying, “Under the circumstances, or under the conditions, who is going to do what?” Okay, as soon as you say who and what, there are other things will pop up. So, SOP is generally focuses on the current condition and the role of the networks. It will say “This is what's happening, and these are the current conditions, and this is updated information,” and so on. Also, SOP will outline what sharing devices are available out there. CCTV, DMS, these are two common ones out there, but lately you can also think of ESS, the environmental sensor station. I mentioned to you about flooding, and so some of these devices are increasingly becoming important and they could find a way in SOP and in terms of sharing and making them available for other people's use. Sharing event information is a very common one; the traffic incidents information that you mentioned several times in our chat pod discussion as well. All of these things collectively tell us that if we share the information, we are doing better coordination, because sharing information reflects communication, right? And communication lends itself into a better coordination. The more closer you communicate in real time, the better coordination will be. This is one of the reasons why we had this slide about two TMCs talking in an interoperable way, because you get the information in real time and you make the management decisions on that information also near real time or real time. So, in that sense, you maximize your benefits. Okay, this is something not usually talked about, but the real reason why we want to exchange information with each other about events, is that we want to make the next decision correctly, properly. And, in fact, we want to make the decision as soon as possible. So, there is a remedy here in SOP in terms of how quickly we get that information and what happens to that information. And I will mention to you one more example here, that certain information cannot go out beyond TMC. For example, if there is an incident and there is a traffic accident, for example, and there are victims in it, that kind of information may not be broadcasted. It may be restricted only for the local TMC purpose. So, such constraints are also part of the agreement. And then comes the data sharing. The data sharing is what we held on from previous episodes, previous incidents. What worked? What did not work? What was done right, correctly, properly? What was not done correctly, properly, all right? So, a lot of this information is out there, and we also collect real time data during the incidents. So, all of these things are available; they are archived, they are logged. So, if you want to have that particular information about certain incident or accidents or whatever happened, you have a way to handle those things under the SOP. And that's what happens in the agreement. So, one way to look at this agreement is to cover what your needs are based on standard-to-standard communication. Here's an example, this is a very good example.

This is a formal agreement between the general agencies who are charged for a larger area; it also fosters a larger participation. People see that there are benefits of having agreement, formal agreements, all right? Public agencies tend to go at length in terms of getting rid of the people who sit next to them, okay? In the beginning it's hard but eventually when people see the benefits, they would see that this framework works so they can work cooperatively. So, this is a very cooperative model. In your supplement we have references provided, so I would encourage you to, when you have a chance, to look at it and see what's in those agreements.

Here's another example that also speaks the same way in terms of practical mutual benefits and cooperative discussion. This one has particularly more detail. So, this agreement has detail in the sense that there is archiving, there is incident management, there is a whole configuration about the ITS Project and how the whole region will benefit from each other. And then it lists the elements of the agreement. What is the numerically one, two, three kind of things, you know, so you put your hands on it and say “Well, this thing is valid for my area, my local project.” So, it can relate and say “Well, why this particular element is there in the agreement?” So, we begin to question and learn something, all right? This is all about learning how to make it practical enough so people can actually use it; and that's what the system interface will demand. So, once we designed the system interface we want people to use it, you see? So, how do we make sure that that happens actually? Well, one way to make sure that these MOUs and the agreements reflect that, and say “Well, this is the reason why the system interface design is accommodative of everyone's needs.”

Then we are coming to a question that was earlier touched on in terms of TMDD's relationship to architecture.

Here I'm showing that the TMC is able to communicate with all of those different things we just finished talking, can be done through this process; one TMC talking to another TMC or external center. It could be TMC, right? So, this sort of elements TMDD has adopted from architecture. They have reflected in it and provided enough user needs and requirements and data concepts to make sure that this is a reality. So, yes, we can talk to 911 center; yes, we can talk to an information service provider, ISP. This could be a shadow traffic or some outside services that provide traffic information. So, they got their information from Traffic Management Center in real time, all right. This could be a 511 center that can also get information in real time. Also archiving the data management; that's also architecture's issue. Emergency management, 911, this is architecture relates in the sense that data flows are accommodated. So, TMDD is about traffic management data dictionary, right? TMDD stands for Traffic Management Data Dictionary. So, in a literal sense, actually, TMDD is about traffic management, right? So, you have to keep that in mind and say “Well, there are limitations to what TMDD can do for us,” right? But it accommodates so many different field devices, 10 of them actually, ESS for example, weather services, right? So, that's included. Also the Toll Administration, Transit Management; our illustration in our module we went through this, right, why and how Transit Management Center can use current information from Traffic Management Center so that they can advise their drivers of the fleet and make the proper decision. So, the dependencies present in this chart, you know, in some cases fully support it, in some cases they partially support it, but nevertheless, the concept is now implemented in TMDD. So, this relationship is real; it's a good one, alright?

Let's take an example here. This example of cultures that the market packages the way they are shown in the TMDD, relate to a discussion in the architecture, expects you to have this center-to-center and center-to-field connectivity in the information process; not the physical one, but the information exchange process. So, a TMC, we know that 24/7 what it does, it deals with the field equipment. It controls and commands, or it commands and controls and then it makes the devices provide information back to it, and it creates all kinds of real time information, right? This information is now available at TMC so this is NTCIP, another level of standards. This is TMDD. So, if you have TMDD-based interface, standard-to-standard interface, you are now also able to get benefits of this information out there, all right? This is the real time information made available through the center, is now passing on to you, another center here. This could be a private center, it could be a 511 center, it could be another TMC for that matter, okay? So, it's not restricted, but the point is made that the real time information, because it is available upon request and that's what TMDD does. So, this is a very good way of looking at how center-to-center and center-to-field coming together. Everyone's needs are met in terms of exchange process, tangible information, real information, something you can use, and also information that directs to the device what to do, and what information to provide. So, through TMC, you can actually tell this device what to do. So, this capability is available through TMDD. TMDD knows how to make the requests which will translate in control and command over devices in a different way; that's what remote operation meant.

So, what will be required? You answer in your chat pod very good that there is a common protocol required, right? So, there are two things present in this chart here that to implement a system interface we require two things. First, we require that we use TMDD; and this is a very good summary slide as well for that matter. So, we must make sure that when we use TMDD version 3 standard, we have to make sure that user needs, requirements, and data elements, whatever data elements we select, are all the same for our common specification. If you don't do that, then we will not have the interface that delivers interoperability, all right? So, this is one thing that you must always make sure that the user needs requirements and data concepts subsets are the same at both locations. And if there are three centers then all three centers must adhere to that, all right? That's how number one is looked at it; the standard must be used in terms of the subset. Second requirement is the application protocol; this creates messages and conversations. This allows us to develop what needs to be put in, in a conversation. This one is actually the vehicle that takes your information to the other location, whether it's TMC or its external center, you need an application protocol. Now, application protocol is developed without any consideration to what operating system you have, what computer system you have, what kind of machinery you have at TMC, what the device—nothing to do with it. Application protocols are independent of what you are trying to do; so they are very common. The two common protocols available right now in NTCIP, familiar standards, is NTCIP 2306 which is Standard to Standard XML; this is one protocol that you can use at both locations and able to communicate information in real time. Or if you choose you can use the DATEX which is also a common standardized protocol, right? So, a question comes up “Which one do I need? Which one do I use?” Well, you can only use only one of them, right? So, you have to make your own determination at the point when you are deciding these things you will also have to make this judgment. And the reason is these things. The reason is that data concepts, these data concepts, are different here than this. Both XML and DATEX data concepts are different; they're two different formats for encoding. So, you have to make that judgment and say “I'm going to go for XML,” then you will pick XML data concepts, okay? So, that's the reason. If you decide to go DATEX then you're going to pick ASN.1-based data concepts. So, those are the type of decisions you will be making and you must select the same protocol as you answered in the chat pod correctly. So, that protocol is going to determine your expectations from system interface; what works, what doesn't work, and if you don't have common protocol, you're not going to get the interoperability, right?

So, that is the discussion that we had in terms of what NRTM and what user needs and how we should consider. So, to exemplify or to go into a little more closer to our summary, this case study is designed to help us. So, let's go through this case study.

This case study, I'll give you a minute or so to read it, you know, and comprehend what we are trying to say here. So, while you read I will also say the key points that there are TMCs, A and B. TMC already has a good deal of assets out there, particularly DMS and CCTV; so they are mixed standards and other center is willing to exchange information and they have an agreement of some sort that could have probably MOU or whatever, all right? So, go ahead please read that. Also, this is a federally-funded project so you have administrative constraints; it has to be done certain ways. You know, ITS projects are required to be developed using certain processes. Alright?

So, I hope you had a chance to read now and let me just go now to the next slide and begin to deal with this. So, the first question here or first point that we need to discuss in the chat room is that the project will be guided by the blank to develop the system interface desired by the TMCs. What process do you think we are talking about here? What would you name the process that we need? Go ahead in your chat pod. Please answer if you can. See the process that we are talking about that will help develop this project. And remember this is an extension. They already have, they are adding a capacity or capability, sorry. Anyone? Take a look. Okay, I would say that we have this curriculum path in the beginning and you know the first line says critical impact with SEPs; so SEP stands for Systems Engineering Process, right? So, a lot of the standards, some of the standards are developed using SEP, some not, but nevertheless, when you do your project, you follow system engineering lifecycle; that's the V diagram that we talked about. So, System Engineering Process actually guides us at each stage of the development, beginning with the user needs all the way down to the implementation and testing and verifying and verification and all that. So, the answer is “SEP.” SEP is the process that we will use. Also remember now this is a federally funded project so federally-funded project, Rule 940 as it's called, requires us to use SEP to develop ITS projects. alright? So, that was the process that you have to follow. Even if you use your own money, I would recommend, or we all recommend that you use SEP as your guiding process to develop ITS projects.

Alright, that brings us to the second one. Second one, what standard are we talking about? What standard is to be used for system interface design? What we have discussed today, in this module, what is the discussion on? Can you tell me on the chat pod what standard we have been talking about? Anyone wants to take a crack? Okay. So how about this? The TMDD version 3 standard will be used to develop system interface for both TMCs, right? So, version 3 has the offering of both XML-based data elements that you need, or if you choose TMDD version 3, also offers ASN.1-based data elements, alright, and they cannot be mixed. So that's the second point that we want to walk away from this case study.

Also in this case study, interestingly, in the beginning I had a definition of what Owning Center is and what External Center is because the entire standard is based on a reference-based Owning Center asking for information and External Center asking for information and Owning Center is providing the information. So, can you tell me in the chat pod which one is the Owning Center in this case study? Anyone want to take a crack? Which center is TMC? Is the Owning Center? Alright. TMC A is the Owning Center because it has the DMS, static controllers, and CCTVs. Anyone who owns the assets is considered as the TMC A. In this case, that says so; so they are the Owning Center. And the Owning Center will provide information requested by the External Center which in this case is TMC B, right? So, TMC A and B are now going to be able to share information with each other using this new capability they're trying to bring to the project.

So, which tool you will use to map your operational need? Which tool you will use? Can you tell me in the chat pod please? What metrics you will use? We talked about it at great length today in this module; anyone? Okay. Alright, so how about NRTM, because that's what we have been talking in Learning Objectives early on. So, our focus has remained today in terms of operational needs and mapping them to user needs is done through NRTM located in Section 2 of Volume 1, right? That's what we've been talking about all along.

Okay, let's go onto five. “How do we go about preparing project user needs?” What do we do? What do we got to have? Okay. All right, how about preparing Project NRTM? So, what you are walking away from this case study is that these centers, TMC A and B, will have to have Project NRTM; they will have to create the Project NRTM, which is common to both of them in this case, alright? If they choose to have separate procurement, then they will have to reflect common specification; well that's what it meant.

The last, number six here, sorry, it says “Both TMCs must prepare a what with some same set of user needs, requirements, and data concepts to achieve interoperability?” So, how about specification? We want to walk away with the notion that you need a common specification that reflects user needs, requirements, and data concepts. That's the only way you're going to get interoperability using TMDD. Off-the-shelf means the standard already has done a good part of the work and our job is to extract in a common way so that we end up with the interoperability that we need.

Alright, now let me recap this. The additional detail related to this case study, the overall operational concept that's driving this development is the congestion management. I mentioned several times that operational needs have rationale. They have a reason for them being—driving the development and that rationale, in this case, is congestion management. You know, obviously, both centers TMC A and B are concerned with congestion and they want a tool so that they can effectively coordinate and manage congestion better, right? So, it's a collaborative effort on the part of both centers to improve congestion management.

The standardized user needs definitions can be found in TMDD standard, Volume 1, Section 2. Now, we have to gather this knowledge very specifically so this recapping is very important in the sense that we need to know where we would go for the information. So, user needs are located in Volume 1, Section 2.

Then we come to this important listing “Information exchange related to user needs are what?” There are four key areas: roadway network, event sharing, device sharing, and you have data archiving. These are the key areas besides the network management and authentication and all that we discussed. So, there are eight operational categories out there, operational needs categories, and four of them deliver the information process itself. The other four are generally dealing with the network management and administration requirement.

Then we are coming to this number 10 and say well “What pre-arrangement should TMC have in place for implementation?” What these two centers should have done? They should have developed an MOU or SOP or agreement. Either one of these three things will work. The reason is that the MOU—is that MOU already has an agreement. Obviously, the case study says that they agree, right? So, therefore they have agreement already. SOP because it's an ongoing operation and they just help you accommodate what additional things will happen, you know, after they have the system interface. And the agreement is a more formal way of doing these things. So, any one of these things, three types of arrangement, will work for that project.

The last one here is what you said before is like application protocol has to be same. In this case, I took this, 2306, because it suggests to me that they already have DMS. They already have traffic controllers. They already have made good progress in the region. Chances are very good that they probably have XML, you know, but not necessarily so. You can select the other one as well. So, I don't want to imply that you only have to have XML, alright? Either one of the protocols will work with this case study.

So, now we are coming to summary conclusion of this module to assess what we have learned. Let's look at closely saying “What have we learned in terms of Learning Objective 1?” Well, in Learning Objective 1, we realized that the system interface capability wasn't there; TMDD has made it possible. And now it has brought the standardization to the table. So, if you want to develop that capability using TMDD, you can create center-to-center information exchange; we walk away with that understanding that TMDD has addressed that basic need for center-to-center information exchange.

Learning Objective 2. We realized that there are eight categories of operational needs. We know them by name and we know their extent, what they do, and what they stand for. And we also know where to find them in terms of where they are making difference in center-to-center exchange. In other words, each one of these categories tells us that if you do this in a system environment, system interface environment, then you will get this benefit. For example, you learned that event sharing in real time is helping you because you're going to make additional management decisions to improve your coordination, right? And that is coming through this operational need called event sharing. So, that's what we learned from Learning Objective 2.

Learning Objective 3 is a source of the information that we need; it deals with the source, Volume 1 and Volume 2. Volume 1 has NRTM; we know where to find it, we know how to use it, and we also know how to, now, make our own project level for NRTM. So, that kind of sequence is present in Learning Objective 3 and it's followed up further as well. Volume 2 has the design concept. We know where these designs are located. And, again, we also made a point that we are not doing anything; we are not designing any concept. We are simply taking what is in the RTM, and the same thing with the NRTM requirements. We are not defining requirements. We are simply taking requirements from the Volume 1, NRTM, alright? So, that is the understanding we had in Learning Objective 3.

In Learning Objective 4, we knew the step by step, how to prepare NRTM. There are four steps that we learned. We went through the Section 2 and extracted the user need, we mapped it. Then we went to the requirement and we mapped the user ID with the requirement ID. We made a list of those 10 requirements as an example to remind you, right? And we came back with a very nice filled, partially filled, but nevertheless completed NRTM for that particular user need. So, we know how to prepare a Project level NRTM. This is the crux of this module in the sense that we need to walk away with a methodology – how we get our Project NRTM done. And that's what we learned in Learning Objective 4.

Learning Objective 5. We just finished discussing earlier with the case studies, there has to be an agreement. There has to be some kind of mechanism that will guide us through this system interface development and this implementation because eventually when it's done, when it's available, you want to use it and that's not going to happen if you don't have pre-arrangement. And the experience in the field suggests that a lot of designs are done, a lot of systems are existing, but they are poorly used, not used at all, or they are in the corner in the room, alright? And that's something we don't want to have to look at it later on after one or two years later development process. So, this pre-arrangement also have implications towards the end of the deployment of system interface so we have to be aware of that and Learning Objective 5 made it very clear. The case study brought to us, at least in a very simple way, it says okay, you're going to make an extension to your current hardware infrastructure equipment and then you're going to bring the information exchange process into this context then you've got to be aware of certain issues, right? You need to make sure that everybody has the common user needs. You've got to make sure that requirements are the same in both specifications. And certainly the use of data concept is mandated throughout. If you want interoperability, you've got to use the same data concept. And, again, we said you've got to use remember, one format, you cannot use both XML and ASN dot. You have to choose one and therefore, you will also choose the correct protocol to go with it. So, that's what we learned in case study.

And then now I think we are also better prepared for the next module which is going to be on requirements. So, the next module will deal with the requirements part of how to go about preparing yourself with the RTM, the Requirements to Requirements Traceability Matrix. How do we handle data concepts through RTM? That's what we're going to focus on in the next module. So, I think we are better prepared for the next module as well.

Where can I find more information? There are at least these four sources that I would suggest you look at closely. Definitely the first one, the TMDD standard, and my request and my advice is to download from this site only. There's a lot of old drafts maybe here and there so you're better off going to the original standard source and pick up your copies of your standard there. Also, there is a TMDD Guide right there at the same site and located next to each other so you can download the guide and the guide is actually helping you in terms of how to prepare specification and implementation.

The second guide we have here is also NTCIP. It deals with all kinds of protocols, both the field devices, as well as the 2306 and DATEX that we had mentioned application level protocols. So, it's some very good information in there.

If you are also either new or want more knowledge on SEP, this Caltrans guidebook on ITS system engineering is a very good one; it has a lot of case studies and it's a very practical, useable book that you can lay your hands on.

The last one is also how to develop an ITS project using SEP process, which is a very good one developed by Federal Highway. So these four make up a very good source for us to help in our work.

So, at this point I'd like to open up for questions. Please go ahead and ask any question you have on your mind in the chat room. Again, I encourage you to ask questions. Please, go ahead. Anyone has any questions in the chat room? Anyone? Okay, while you are thinking about questions you can ask me, well, let me just raise these are three questions that I came up with more or less, you know, in terms of subjects that we have discussed.

I would say my first question, I would say, well “Is TMDD version 3 standard backward compatible?” If someone wants to know whether this version that we discussed today, is it going to work with something already existing out there? And the answer is no. And I would say no because this standard has the new data elements in it which are based on standards which are different than the previous version 2 and 1. So this standard, version 3, is not backward compatible. So, that's the additional information that you might be aware of, you should be aware of.

Anyone else have any questions in the meantime? Alright, I will ask the second question. Do we need both NRTM and RTM in the specification? Just to clarify this, do we need both metrics? Do we need both tables in our specifications? And the answer is yes. And the reason is: NRTM connects the user needs to requirements and RTM connects requirements to data concept or design. So, and we need all in our specification. So, therefore, we must make sure that we have project level NRTM and we must also make sure that we have project level RTM developed for that project, alright?

So, those two questions I raised now and you have any other questions? Anybody has questions? I'll give you a moment to do so. No questions? All right, if there are no further questions, I'd like to thank you all for participating in today's discussions on our A321a and I recommend that you take the next module. Stay tuned for the next module which will be on requirements and, again, thank you for your participation.