Module 40 - A309a

A309a: Understanding User Needs for Ramp Meter Control (RMC) Units Based on NTCIP 1207 v02 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.)

Ken Leonard: 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 them. This module is one in a series that covers practical applications for acquiring and testing standards based ITS systems. I’m Ken Leonard, the director of the U.S. Department of Transportation Intelligent Transportation Systems Joint Program Office. Welcome to our ITS standards training program. We’re pleased to be working with our partner the Institute of Transportation Engineers to deliver this 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’ll tell your colleagues and customers about the latest ITS standards and encourage them to take advantage of these training modules as well as archived 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. You can find information on additional modules and training programs on our website at 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 and thank you, again, for participating and we hope you find this module helpful.

Narrator: Throughout the presentation, this activity slide will appear indicating there is a multiple choice pop quiz following this slide. You will use your computer mouse to select your answer. There is only one correct answer. Selecting the submit button will record your answer and the clear button will remove your answer if you wish to select another answer. You will receive instant feedback on your answer choice. Please help us make even more improvements to our training modules by completing the post-course feedback form. This module is A309A, Understanding User Needs for Ramp Meter Control Units Based on NTCIP 1207 Version 2 Standard.

Your instructor is Raman Patel. Dr. Raman Patel is a Fellow of ITE and has over 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 ITS Standards Committee and is a member of an NTCIP and TMDD Communities. Raman has close to 30 years of experience at the New York City Department of Transportation as Chief of Systems Engineering, and seven years at Parsons Brinckerhoff. He is currently teaching ITS Systems Engineering and Transportation Engineering at the NYU Polytechnic School of Engineering in Brooklyn, New York, and is working on road safety projects in developing countries.

Raman Patel: Hi. I'm Raman Patel. I'm your instructor for this module. The target audience for this module includes traffic management and engineering staff, people who work at traffic management centers, operational staff involved in ITS operations in general. Also the people who are specifically working on freeway management signals, as well as the traffic signals on the arterials, people who maintain the signals, retimings, and in general the system developers who put things together for us on an integration manner, integrated system that comes out of different efforts that we make in ITS. And of course, the private and public sector users that also includes manufacturers, vendors who supply traffic controllers.

The recommended prerequisites for this module includes basically the list that you have here. But it also includes specific modules which might be very helpful related to this particular module today. For example, A202 here also teaches us how to write user needs when they don't exist in any given standards. So that's a very important standard as well, module. C101 at the end here shows how the NTCIP communicates and the process works, so some of these important modules are made prerequisites so that you understand this series pretty well.

This is the same thing, in a graphical manner. The last box that's shown here we are actually discussing today. There are four learning objectives for these modules. Together these learning objectives will prepare and provide us additional skills that we need to prepare good specifications for ramp mirroring the control modules.

The first learning objective provides the general discussion on the structure. What's in the standards and where to find information. The second learning objectives will actually help us identify specific user needs to the operational aspects of RMC. The third learning objective represents a criteria that we use to write the user need related to RMC needs. And then we move to the last one, which explains us, what it will really take us to our RMC standards. So basically, these four learning objectives will guide us through these modules today.

The first learning objective provides us the definition of a ramp meter. What is a ramp meter? What is a reference layout? How does it work in the overall architecture? Also it introduces the family of standards, the stack, where to look at how the data is moved. It explains the purpose of 1207 Standard and components in the standards. And then finally, what's new in the version 2.

So let's look at the terminology. The ramp meter is actually a traffic controller. If you equipped with software and firmware and some algorithms specific to freeway ramp control. It's not for arterial traffic control, as we might be looking at the number of intersections, you know. This is specifically on the ramp activity.

The ramp metering is the rate. Is expressed in vehicles per hour per lane, and generally also discussed as a release rate. So for example, a ramp meter may allow 500 vehicles per hour, per lane, and that term is a release rate. Ramp metering control, RMC unit is a term that we use in this standard. And RMC is a system in which the entry of vehicles on to the freeway from an on ramp is controlled by traffic signal. So it allows only fixed number of vehicles to enter the freeway from each meter lane on the ramp during each cycle. RMC unit has several components, the main one being the controller itself, the traffic controller. It has several detectors. One detector station is on the main line. In every lane, there is a detector that measures sphere occupancy and one of the speed traffic flow. So you also have similarly, you also have detectors on the ramp that provide us the demand, the passage, and the queuing. And also the traffic signals themselves. Like three head, green, amber, red, and signs. Signs also suggest whether the meter is on or not, or if it actually displays the message. So RMC unit has these components as shown in this diagram, and we should be looking very closely as we move along.

RMC, when does it function? Well, this is the general architecture diagram that's taken from the standard itself and modified slightly here for this module. It allows us to see that the RMC is part of the overall architecture which also includes traffic management center as shown here on the top portion of the figure. At the bottom you have RMC control unit, which actually is part of the traffic controller, and in between what we are trying to do is to use this NTCIP to allow a 1207 Standard which is the subject matter for this discussion today. So our main interest is in here today, and trying to make this RMC communicate to the TMC and the TMC communicate to the RMC.

The other part is discussed here in this context diagram here. You also include sometimes, we exchange information with other centers out there in the TMC. And that usually is a differing set of standards, including traffic management data dictionary and the NTCIP 2306 Standard or set of standards.

This standard also supports the traffic metering service package from the architecture. So if you are dealing with the general architectures, you will know about this particular metering package that is in fact provides the metering on the ramps. So this standard does support this package.

The NTCIP framework is shown here. It's a stack. It has two parts, the first part being that at the information level, it provides data dictionaries. There are two dictionaries in play here. One is 1201, NTCIP 1201, which are global objects and they are MC objects, 1207. Both of them are located in the stack at the information level. So they provide us the definition of data for RMCs and then the global objects.

At the lower levels, you have how the data is exchanged or moved from place A to place B or point A to point B. So that kind of approach is coming through this stack of communication protocols which we need. So the top level provides us the data dictionaries for data design. And the bottom protocols provide us the matter with which we exchange the data.

Also, there are two important terms that we need to be aware of in terms of RMC particularly, the basics. The standard assumes that the operation is within the RMC, ramp controller. So the intelligence related to RMC functionality is located inside the RMC unit, which resides in the controller—it's not at the center location, but it is inside the controller. And the second point is that the TMC that's done away, remotely actually manipulates or controls through the interface that we create. And so the data, database, actually resides in the RMC unit at the controller at the local level at the RAM.

The manifest of standards. Why are we generally concerned about using ITS standards? And there are several reasons why we should be concerned and understand the manifest provided by protocols like NTCIP. First of all, the compatibility. We have different devices in ITS. We are with a City, for example, traffic controller, we have a dynamic message sign. All these different devices, they do different things. And also they come from different vendors. So protocols are also important in terms of if we have a common NTCIP communication protocol like the one shown here, the devices work in a compatible way. Meaning that they don't interfere with each other. They allow each device to function in its own role and provide the functionality as desired. So that's what the important part is. The compatibility. You have a common protocol for the compatibility.

The second aspect, which is a very global one as well in the ITS arena here, is that we get the interoperability. Interoperability means the devices themselves exchange information with the same traffic management center and then this information is used to improve our operation in general, the traffic management operation in general. So there is important aspects of how and why we use these kind of standards so we can get the interoperability.

The third aspect here is inter-exchangeability. Here we are looking at a very close view of we are coming out of the old hardware that was not compatible with each other maybe. Also, we had a proprietary solution and things like that. The old hardware had very limited capabilities, functionalities. Now we are entering a new era where we have emerging standards that are providing us control, of which are not only powerful physically in terms of processing-wise, but also provide us more capabilities in terms of what and how many different things we can do. So try, for example here, it could be 170 or 2070 controllers are also now being upgraded to ATC, which are newer ones, which also have more memory power, processing power, and functionality, in the cabinet and all those other things. So interchangeability has now played a big part. Particularly in these aspects of ramp metering where we are moving away from old traffic controllers on the ramp towards more localized processing machines like ATC. So there are several benefits that, as we discussed here, come into play and we should be generally also thankful in terms of common protocol, because our marketplace is also improving. Not only just one vendor but many vendors are now engaged in providing services acquired in the marketplace. So there are plenty of benefits that NTCIP and ITS standards have brought to the table.

Components of this particular standard, NTCIP 1207, Version 2 in particular. There are several sections in this standard. Section one is pretty general provides your introduction and scope and reference terminology. Section two is we just discussed advantages. Why are we even doing it, doing this—the NTCIP standards? Way back when we had a problem with the proprietary solutions, now we are coming out of it more or less, right. So those are the benefits described nicely in this section two. Section three is very specific to RMC, this particular device that we are talking about today. And in there you have management information base, which is actually an organization of design data or design objects as we call it. And these objects are organized by function. So they are easy to read by function. And then these objects themselves are designed based on another common language format that came from Abstract Syntax Notation Standard, ASN.1. So these objects have a very definite structures, so that every standard is following that in NTCIP family of standards. And RMC has similar objects also available. There are about 83 or so objects organized under MIB in section three.

Section four is new. There are ramp meters, specific block objects. These objects are specifically developed so that where we have a situation very limited availabilities available on the wire line or communication, and then we want to include transmission efficiency. So these objects come to our help and then instead of sending one object at a time, and then keep sending, repeating the process, instead, we can send a bunch of objects together and be done with it. So that's what the RMC blocks are of objects are about.

There are new annexes, A, B, C, D, E. Those are the five annexes in this standard. A and B are a very important subject matter for us today in this module. Because annex A provides the description of how RMC unit is working. A typical operational aspects. And it's written by experts in the terminology of the standard. So it's really difficult to understand, but it does provide us very good information. And we will talk about that shortly.

Annex B is a list of conformance groups. The conformance groups are coming out of the MIB interorganization for functional base objects. So we will be using A and B. Object C or annex C is providing us object three, which is an organization of how nodes are listing each different object under it. And D is for future dispositions. We don't have it and so it's blank in this standard. And annex E tells us what actually is new in version 2. So it talks about document revision.

What is not offered by the NTCIP 1207 Version 2 Standard? Well, we need certain information to prepare project specification, right? As shown here in this diagram, part of the Vee diagram as we normally use, you have user needs, which is not offered. You also have requirements, not offered. And the third part here, design, is offered. So look at it each one of them separately, saying that each of these are not offered by the standard, so what the user has to do is to identify and write the user needs. Same thing applies to requirements. Again, based on the user needs that we identify, we will have to write the requirements. So the requirements are also not provided by the standard.

The third part, the MIB as we had discussed just a few seconds ago, is the organization of design data which is provided so we can put our hands on those design data and probably get the information we need.

Our first activity here is in order now. And so the question here we are asking which of the following statements is false as applied to the NTCIP 1207 Standard? Answer choices—we have four of them here. A) standard is independent of the type of the ramp traffic controller, b) MIB provides design objects for RMC functions, c) RMC user needs are listed, and d) ramp metering module resides in the traffic controller.

The correct answer is c. Because ramp meter control user needs are listed, it says. While the answer is correct because the statement is false. It's really not available. It's not listed, so that's why it's correct. Answer a is incorrect because standard is independent. So answer b is also incorrect because MIB does provide us design statements, design objects that we need for our specification statements. And answer d is also incorrect because each ramp meter has its own metering module in it.

So let's summarize the learning objective 1. What we learned in learning objective 1, we reviewed and defined RMC unit and components. We reviewed the layout, also the architecture. We reviewed the NTCIP family of standards and the benefits they provide to us. We reviewed the purpose and the structure of the standard, the key components, what is available, what is not available. We also reviewed what is new in Version 2 standards.

So moving on to learning objective 2. Now we have to identify RMC's specific operational needs in learning objective two. And what are our operational needs? We had to answer this question. And why are they operational needs? We also have to look at two important aspects of functionality of RMC, and how RMC covers operational needs, this standard covers operational needs. First, the command source is, what are the mechanisms with which we can communicate to the RMC, and also what action we want RMC to take, such as fixed rate traffic responses. So we have to discuss that. And then finally, the third component here is the description of annex A. RMC operational description and see what's in it. So together, these things will allow us to identify the operational needs.

What are our operational needs, and why are they operational needs? Well, the first thing first. The concept of operation for user needs is embedded in the operational aspects of the big picture. What is the big picture? Collectively, these four questions allow us to dig into what does the big picture look like. So the first question is what is the current situation? What problem we are trying to address. The second question is what are the users? Who is affected? Where the impact will be? Also operational scenarios. What works? What doesn't work? We went through a lot of these operational, historical, experiences at every agency, and we pretty much know sometimes things work, sometimes they don't work out, you know, so we had to look into this and understand what the needs are. Also, the operation, is it localized? Are there any maybe corridor issues or is there a regional aspects? Some of those issues we have to examine so that we can understand our operational needs better.

Sources of operational needs. There are several documents that are here in front of us on this day. The first one being is the development plan. Every agency has a development plan for ramp metering. They just don't go out and do certain things without documenting it. Why are we doing it? What will we gain out of it? What are the criteria? All of these things are there in the development plan, because it generates the efforts and it requires a pretty detailed description of what this thing is about.

When we come down to the design level, ramp meter design manuals, they do exist and most states have it. This one shows a California manual, but there are other states; Texas, for example, also has a similar manual. And this manual has good information in it. Geometric information, ramp design, line up side, curvature, radius, limitations. And along the way we can also get a lot of good information why certain things or certain decisions were made the way they were made. And that does tells us that there are certain user needs that we can expect from also in the design manuals—from the design manual.

The third one here on the right corner is operational guidelines. For example, this one shows from Texas. And again, many agencies have their own operational guidelines, how the ramp meter should be conducted and strategies and policy discussion. So we can get a lot of good information from these three types of documents.

There are two additional sources that we must talk about it. First of all, the USDOT has taken this subject matter very seriously and created these two wonderful documents. A very detailed one of The Ramp Management and Control Handbook. It's very up to date. It tells us about the practice and provides us all the details, very step by step. So The Freeway Management Handbook, which is a general concept of how freeways should be managed and operated, also has chapter seven specifically for ramp metering and control. So together these documents really provides us all the technical and operational information we need. So they are a very good source of where we can find operational details and needs, that analysis we need to do.

So operational needs are also about what we really gain out of this whole situation on a freeway management side of the ramp management. For example, there are three objectives that we have in terms of achieving efficiency. So we want to improve the freeway flow. We want to keep the cars moving, right, vehicles moving, so there is certain flow rate. For example, let's say 2200 vehicles per hour, you know, our expected objective. We also want to maintain the freeway speed. Highways and freeways are designed for higher speed. So for example, we want to maintain, at least maintain 55 miles per hour speed, right, or thereabout. And then we want to improve overall travel time. And remember, travel time is a general subject, we are all interested in it. You know, if we maintain speed and there is no congestion, travel time will be properly estimated early when displayed even in the morning signs. So travel time cuts across all aspects of operation activity. But nevertheless, we want improvement using ramp metering, so that's why these three important aspects are shown here.

The safety aspect is as important as other aspects, and in there we want to reduce the number of accidents, particularly in the area where we have merging with the freeway traffic. So the ramp metering it also pays very close attention to how we can improve the road safety in terms of managing with the merging area.

The third component here in this discussion improvement-wise is the incident management practice. Now we all know that when there is an incident occurred on the freeway, we need to clear it quickly, right. So the clearance time is our main interest in terms of reducing the time. And when bad things do happen, and they do, you know, and we all know about it, incidents are part of our operational practice. You know, we all suffer from it. So when they do occur in one particular location, the incidents have a tendency to cause damage in the other parts, or in other words, they have impact in other areas as well. So and we can see an issue for corridor and corridor coordination. We need to coordinate our aspects in how we manage the corridor. And then we may end up even closing part of the highway, part of the ramp. Some ramps maybe have to be closed. And then in certain situations, we need to detour traffic. So if you look at it collectively, in the traffic incident management as a practice, ramp metering plays a very important part. So we have these components coming together.

So in summary of operational outcomes or benefits, on the efficiency side agencies have reported very significant benefits. As you see in the first column, the flow volume has increased. And if you put this percentage on the side for a moment and just pay attention to how much effort the agencies have made over the decades in improving the flow, it's a significant progress that ramp metering has allowed. In the middle here, we are talking about improvement in the average speed. Average speed has also gone up in most applications, and significantly by the way also. So if you look at the travel time reduction, again as I said earlier, we tend to gain from overall improvement through the management, and then we can benefit that aspect through the reduction in travel time. So agencies have done a lot of good work over the last decades and achieved a good number of—a good percentage of benefits actually, I should say, you know, on these three areas.

On the side of the safety outcome and benefits, very important. Now safety is very important to all of us, right? And we all agree on that. So it's part of our operational culture, our focus. And if you look at these benefits shown here, for example, Detroit is reporting 50 percent reduction of the merge. And these are significant benefits that occurred in the merging areas when as shown in the diagram here on the right, you can see that the—when the ramp metering traffic is merging with the main line traffic, you have this area of say about 1,500 feet or so in this particular area, the merging and orderly merging is very important. So to achieve that objective, so we have to break up the platoon that's entering the main line highway on the ramp.

So we have good number of benefits that we just discussed. So to achieve such benefits, there are generally three operational actions that are listed here. The first one is the fixed rate, which is based on—the rate is based on a predetermined number, based on the historical data and periodic observation, and we'll discuss that in detail. The second one is traffic responsive, which is not a fixed rate but is calculated as the conditions change on the freeway and the ramp metering rate is calculated. And the third one is the corridor one. Not just one ramp, but a string of ramps or multiple ramps in a particular corridor are managed together in this in order to provide a better management of the whole corridor.

Let's look at closely the fixed rate metering action. It regulates traffic on the ramp based on the historical data. You go out there and you take your observations weekly, monthly, whatever, and you come back and you analyze it and say this is how we're going to come up with the range. So it's based on the time of the day, need and/or free time, but it's nevertheless fixed. So the cycle length is fixed. Here's an example. In the photo, we are showing that there's one meter lane operation, which releases vehicles at 240 to 900 vehicles per hour, for example, in a single operation.

If you have multiple lanes on the ramp as operations, then here in this photograph, second, two lanes are shown on the right. So when you have multiple lanes, the rate, reduced rate, goes higher. And then if your merging area permits you, and you can see the geometric condition in this area here for example, this seems like enough room to have two vehicles go through the merging area, and in that case, the rate will go high, but the geometric will have to be cooperating. And there are conditions where geometric is limited and there is no space available, then you may end up accordingly with the single lane operations or one automobile at a time.

Traffic responsive, on the other hand, as the name suggests, it regulates the ramp traffic based on what the condition that is on the main line. So, on the main line you have three types of data that we collect to detector station, as shown here in this layout. The occupancy, flow rate and speed. Together these three parameters bundled together give us a good level of comfort in calculating response rate so that it matches with the current needs. So there are three terminologies that come together, actually. The metering plan. The plan is a numerical value, like say ten plans, you know. And they are like a configuration tables, they are telling us how a particular response will be created in the plan, right. The metering levels are within the plan. You have maybe 10 or 15 levels, but each level you have a different set of occupancy, a flow rate, and speed show up.

So they are like variations in those three parameters. That's why these levels. There's level one, level two, level three. And each time, those combination of those three parameters will change. Based on this, we have a meter rate. The meter rate is a final response that comes out based on the calculation that we do using the level concepts. So the current information is coming in continuously from the data, detector data on the main line. This detector data provides the occupancy. So this could be detectors on the freeway that you may have seen. Or it could be also the model TSS sensor stations coming into deployment lately. They will also provide the continuous data. So regardless of where the data comes, but we are interested in the occupancy, speed and the flow. And those parameters now provide us the primary metering rate. So these terminologies are connected or are looped together.

Let's take an example of how this situation works. This is a simple situation. It may or may not be close to the real world, but it gives us an idea of what really happens in terms of how responsive scenario allows us to understand the basic concept. Eight o'clock in the morning, you have traffic that is being read by the detector station. The occupancy of 20 percent. On the right, we have in this table the store in the RMC unit, which actually tells us the rate is about 8. And these rates are computed based on the—on our previous research and practice in the field. So for example, for this 20 percent occupancy, you are really in the range on the table, 17 to 22. And that allows us to compute the rate at 8. Eight times the metering rate will be for 60 seconds, for 60 so 60 minutes, you will have now 480 vehicles will be allowed. An hour later, say nine o'clock, traffic conditions change, and now the occupancy has risen. From 20 percent, it has gone up to now 31 percent. So now the rate will have to go down to accommodate this response. So in this case, it happens to be 4. So our metering rate is now cut in half, so it's now 240 vehicles. So within the variation between 8:00 a.m. and 9:00 a.m., you can see that the responsive patterns, the traffic responsive methodology will allow us to adjust for metering rate. And that's what's behind the traffic responsive action.

The example shows the two metering levels. So my advice to all of us is to think of these metering levels as like a presets, okay. The levels are presets. So if you have maybe ten presets, you already know how you're going to use them in a given condition. So it gives us an idea. So presets are pretty reflective of what the levels are about.

So now let's look at how does the RMC standard cover operational needs. We just reviewed what our operational needs are, basically. Now let's see how this standard actually covers it. So we look at the RMC unit that's out in the field, right. So on side of the input, you get the data from loop detectors as shown here or TSS, transportation sensor stations, provided in the other standards. You can actually feed that data into the RMC. And then you also have TMC. TMC generally makes a request and receives the answer from the RMC. So those two components are shown here on the side of—an input side of the RMC. As an output side, you can look at it and really see what the features and functions are about. What does it really do? So you have the one car at a time shown in photograph one here at the top, right. So it tells us, the green, amber, red display, and how many vehicles at the bottom are supposed to be. So the sign shows that. On the other hand, we also have to let motorists know whether the meter is on or not, the operation is in effect or not. So there is a dynamic sign that actually says that message. So these are the functions and features supported by the standards.

So let's look at how we can actually make these changes or control the RMC behavior. So there are several mechanisms provided by the standards. The first mechanism is the manual, which has the highest priority. Here is a device that you can use, a laptop, to control your RMC functionality. You either go to in front of a panel, open the door, and you play with the keyboards and then you do your things. Or you can use the laptop and get the same thing done. So modern machines are capable of doing a lot of different things, okay. So manual setting is what the RMC has the priority on. The second one is NTCIP, which is our main subject today. So it provides us remote capabilities to request the action from the RMC. And then RMC will do what the communication command actually wants it to do. So that's the second priority. The third priority is the interconnect. So sometimes peer-to-peer environment exists in communication, so you have a nearby probably a master controller, so in that case, that master controller can actually tell RMC what to do or how to manipulate or control the functionality. So that's a third priority. It's not probably widely used, but it's still there as a capability.

The fourth one is the global schedule. There is also time-based control as we call it, and it's a schedule based around holidays, special events, or pre-holidays, floating holidays, whatever the needs are. According to the schedule, the time base control will take over and put that in effect.

The fifth command, which it shows here shown, is the default. Default is just like it says default, in the sense that it comes with the machine and it's a very basic, elemental thing that's inside the package. It generally provides as a starting point and then allows us to move from there. We don't normally use it, but sometimes when we want to learn or benchmark certain things or sequencing the signal system, we probably start with the default. But it's not widely used. So there are five mechanisms that we have here that standards support.

Let's take a close look at it. What do we actually end up doing, using a third party software? So the third party software allows us to do a lot of different things in traffic management center, right. So the communication command, for example, remotely exchanges data with the RMC. We can use the third party software from the TMC and actually tell RMC what to do and what data it needs to be managing.

So now three things happen. There is a configuration. So what does the device look like in the field? What is the model number? Serial number? When was it installed? So some way of knowing about a particular device. So there is a need to know what the configuration of the device in the field is. Also there is a need to change the configuration. So both components are created under the configuration management of RMC device or unit, as they say here.

The second aspect is the control. The control means the functions and features that we want to alter or we want to derive from the RMC working. So, so control parameters are provided by the standards so that we can actually remotely control the functionality of the RMC unit.

The third thing is the monitoring. We need to monitor every device in NTCIP context, right. If we don't monitor our devices, then obviously something is not right. So to monitor, we have these capabilities available. So we request data from a device and the device will provide the data in a timely manner so you can actually create a scenario what happened five minutes ago, or what will happen, or what is likely to happen and you can expect. So all these three functions are supported by these standards.

We also should look at it in terms of what additional information is provided, because we already have the detected data from the main line, and we don't normally use all the data, right. Sometimes we have a lot of data available, which could be used for different purposes or other purposes at TMC. For example, planning. You could use this data for planning, congestion management, improving efficiency, corridor strategies, a number of things that TMC might be able to look at it. This data could come from in between the corridor. We're talking about ramp metering, right. So ramp meter, six in the middle of a corridor, then you have detect the data also collected within the corridor, which can be used. So all aspects of the data collection is also very useful in terms of both operations, management, and planning, as well.

So what does the standard annex A provide? Well, there are four areas where we have key features outlined. First, the previous segment. How many lanes are there? What is the lane number? Main line detectors, volume, sphere occupancy, right. And then you also have upstream, down from the station identification. In the second part we have on ramp. Similar details also exist for the ramp, so the standard actually organizes the two annex A organizes the experiences of what activities will occur on on-ramp. The third part is the command sources. We just reviewed these five different commands that's available to tell the RMC what to do or alter the functionality, right. So those five command sources are covered in annex A. Also, what will the command source, each one of the command sources do? So each one of these command sources listed in three also provides us the ability or action that we can make a request with. So that we can make a request for a fixed rate or a traffic responsive or a rest-in-dark or a rest-in-green. So there are like four key elements that's covered in the actions.

Our second activity, let's ask this question now. Which of the following is a false statement related to traffic responsive operation? Answer a) a TMC operator can remotely retrieve traffic flow data, answer b) communications command source has the highest priority, answer c) metering labels are part of metering plan table, or answer d) is RMC module is located within the RMC unit.

And the correct answer is b, communications command sources has the highest priority. It's the correct answer because the statement is false. Communication command is not the highest priority. The highest priority is manual command source. So it's followed by the communications source, right. So that's why the answer b is correct. A is incorrect because the statement is true. Similarly, answer c is also incorrect because the statement is true. And answer d is also incorrect because the statement is actually incorrect.

So in summarizing learning objective 2, we have reviewed the RMC specific operational needs and why. We reviewed the concept operation big picture. We also reviewed how standards cover priority-based mechanisms. There are several of them. Manual communications. We also discussed the communication actions. What will they do when the request is made, what the RMC will do? Fixed rate, traffic responsive, corridorwide. We also reviewed the RMC user needs from annex A. So there are four components that we just reviewed.

Turning to learning objective 3, now we need to learn how to prepare well written user needs for RMC units. So we need to understand that these user needs don't exist and realize that they don't exist, but we need to develop them and follow a requisition process. We also need to understand how to extract these user needs and write them. And then we will also answer this question, what happens if we don't have certain user needs that can be satisfied by this standard? What we are going to do?

So let's look at now a little closely, what is a user need? A user need is a description. It's a statement that we put in our specification of what the RMC system should do to support our operational needs. So user needs are features and functions. So example, the short one here is a TMC operator needs to make a request to the RMC unit to change the current ramp metering rate. What is impulse statement? What interferes as a user needs? So as a first step, we must identify what the user need is. And we have to then write it, and actually develop it, and then put it into our RMC specifications.

So let's look at the criteria. This is the criteria we have been teaching in all of our PCB modules all along, and we are very consistent with it, so we also use the same. This criteria was discussed in A202 modules, so those of you who have not taken that module, I would request you to consult that module, and then apply this criteria that we have described here. So every time you start writing a user need, these are the four criteria we have to apply. We actually should be on our minds to apply them, so specifically and not miss one of them.

So take a look at the first one. The first one tells you that we must provide a structure. A structure also provides a title and has a unique way of writing short sentences or something like that as a—that implies the title captures. So the structure will be very short in terms of the user need, and it says identifying number, like user need number one, for example, and then it has a short title. And the reason why we name it is that there may be more than one user need, right. Certainly we know that it's not just going to be one user need. It could be 10, 15, 20, even 100 when you put all these different devices together.

So what happens is that a lot of these things go into the software, databases, right, and then we need to identify them. Also later on we will know that if we have a user need title, then we can also relate it to the requirements, right, and then so on. So this one point is very important. Second here is the major desired capability. In short, we call it MDC. Now MDC represents functions and features. It is the indication what you really want the device to do for you, right. So it has that capability implications, therefore we must write it properly in our user needs. The third is the rationale. We must capture rationale when we write a user need. What is the user need about? Why is it a user need? And we need to answer that so that people who read the user need can make sense out of it and say, "Yeah. Oh, really, that is why they want this user need." Right? So that is the third component, the rationale. And then finally, every user need should be solution free. We should only state what our user needs are. We should not design it. We should not tell somebody who needs it how to do it, how to design it. So it has to be solution free. And to keep out of this discussion in a solution free is that we want to give the people who develop the system more flexibility. If we end up saying this is how it should be done, then we are not providing the flexibility that it should be. So user needs is very, very mindful of what the need will do to others. So these four components. Make it identifiable, MDC, rationale, and solution free.

Let's apply the same thing we just discussed to this example. Same user need that we mentioned in the previous slide here now has a title. A title says user need number one, change a metering rate, and uniquely identified. That's what it is, right? So by not discussing what the user need is about yet, I am looking at the title and I say, it says change a metering rate. Wow. That means it's got to be something about what the current rate is and now, you know, I'm going to change the next level of rate, right. So let's look at it very closely. A TMC operator or a management station has a need to make a request to the RMC unit to change the current ramp metering rate to a new metering rate in order to meet current traffic flow condition on a freeway segment. So look at what happened. We started out with a good title and a number. And now we introduce MDC, the MDC being “change the current ramp metering rate,” right. So we are asking the capability. Then we are also saying because we have a need so that we can actually change the current traffic flow condition. Metering rate change to meet the current rate traffic condition, that is what I actually wanted to say, right? So there is a reason, there is a rationale why this MDC is needed, right. And nowhere here in this description, we tried anything like this. We did not say this should be done this way or that way or whatever. So we kept the user need solution free. So if we can do these four things to a description of user need we are that far ahead. And removing the ambiguities and telling the specification—in the specification very clearly what our actual need is.

Now there are other examples of about that we will shortly discuss. And let's look at it where we find the user needs. So to—find the user needs—and since they are not written we have to go to several sources. First, every operational—every agency has operational needs as we discussed previously in concept of operation. So we are going to look at those documents that we discuss earlier. As far as the standards are concerned, we going to look at Annex A—the operations. These operations provides description of features and functions that—that the RMC does. So we have pretty good solace or—a source available here and we can comfortable—comfortably actually extract from Annex A. Similarly Annex B lists the conformance groups. They're organized by function. So, again, we have a good chance or—a source available so we can extract certain user needs from that. So you have A and B. And the—and the last one here, the common architecture user needs, you will drive from the other standards. Standards such as ESS, environmental sensor stations, or dynamic message sign standards. They have actually listed architectural user needs. These are generic. This you can apply to any device. They don't have to be specific to ESS or DMS. They could be exported to RMC unit. And that's what we are doing here. So we have three sources, operational needs from the documents of the agency. Standard itself has two parts, A and B, we will use. And then we will also go back to the other recipe successful standards and derive from them. So these are the key sources where we get our user needs. Let's loop this whole discussion in terms of advice. What can we tell you to learn how we use particular source? Look at Annex B that covers functionality. Conformance groups are designed by nature—they have been designed so that they—present functionality. So if you read Annex B, and you look at the listing of conformance groups you will see the features and functions organized. We understand how conformance group acts in terms of facility. So every conformance group can be traced to a particular user need and functionality. So that's the second nature of what we can learn from Annex B. And then we also look at the objects. Objects are a big deal. Every conformance group has a certain number of objects in it which are—organized, again, by—the function it represents. So—this a good way to look at it—look at it—Annex B. If you apply similar thought to description provided in Annex A. Annex A is more operationally oriented. It actually tells how the RMC you need actually works in the real world. So it has operational parameters. It has occupancy. It has the speed data. You have a functional response rate. So all those data tell us how to organize our user needs. And then we look at the description in the sense that, although they are written in a nice language, so you can relate you have to actually relate that to user needs. In other words, they are not written in a consistent language of systems engineering process. That's unfortunately Annex A has—Annex A has not done. So we have to—we have to do a little extra work and extract this user needs the way we have done for dynamic message signs, or ESS, or other standards. And that's what this means. So when the Annex A provides operational details if the language issue is there, and we have to understand very thoroughly what it means.

How do you organize after getting this user needs from different sources? Question comes up how do you organize them? Why? Every agency has its own way of organizing user needs. And if you look at number of specifications out there you will see different aspects in—in how the document speaks to you. So we are suggesting to use this organization so that we are consistent with what we have done in the systems engineering process with standards such as dynamic message sign and ESS. So in every standard we more or less have Section 2 as a background information. And—then RMC user needs, I meant. And then you list architecture user needs as 2.1, 2.2 as the features, and 2.3 as supplemental needs. So this we have adopted from the other standards and the other standards probably has you thinking that good use of uniformity is necessary. So when you organize your user needs we look at three things, architectural user needs, features and functions—in this case RMC unit performance—and special needs. And this section underneath are telling us how to organize them. And we will actually apply this—what we are just discussing.

So what is our approach to architecture user needs? Well, based on the NTCIP 1204 ESS Standards, which is a widely now recognized in the—in the clarity wise as well. And then we—can use that structure and say, okay, we're going to call this user need User Needs 2.1.1 or Live Directions. This is an architecture user needs because it—sets the whole thing up and allows us to function in a really organized way. So here are these and management station central software has a need to conduct a live data exchange with RMC unit to be clear and set up data at any time. Very clearly written applying those four criteria that we had discussed earlier.

Other user needs—similar format. This time we are talking about log data exchange. So sometimes when you have a situation where communication is lost or not available or you are using dial-up environment this user need becomes important. And then the third one example is telling us that how to help you actually make an inquiry through the device and the device will give you the data you need.

Approach to finding user needs from Annex A is a little difficult, but it's doable. And here we are suggesting that you use these two steps. Step one, is identify section. Annex A has listed, Version 2, actually has listed the Annex's, and it tells us where this particular section will provide us different, different section will provide particular functionality related design data. Or, in this case, we are talking about user needs. So look at, for example, in—in the box at the top. A.5.1 is about fixed rate. A.8.3 is metering operations—signal intervals. A.9 is about queue ride. So if you look at this box collectively all three things are telling us that it hints towards a particular user needs. So if you're going to write a particular user need—in this case fixed rate user need then you will be using all these three sections to pull your user needs together. So that's what Annex A, Step 1 tells us. How do you fill the later user needs so that they are sitting next to each other, and they get the functionality done? Box 2, bring the same thing. Different example, 5.2 is about traffic response metering, which is also very widely used. It's a user need. So in there you have another section that tells us 7.1—it says metering plan, 7.2 says metering rate, and so on. So these four sections are collectively telling us that you need all your user needs for traffic response metering, they're here. These four sections—or actually five sections now, with the report listed also. So these sections will provide you collectively traffic response metering. The first box mean the same thing for fixed rate. The second box is doing for traffic response metering. So imagine now you have Step 1 actually identifies section where you can find these user needs. A second one, our job is identifying is done in Step 1, but it's not complete yet. So to complete our job writing user needs criteria will have to be applied to what we just extracted in—in Step 1. So in this case in Step 2, we're going to be very careful. We're going to provide ID number. We're going to provide the MDC. We're going to provide rationale, and we're going to maintain our emphasis keeping it solution free. So in Step 2 we're going to bring back the criteria again. Now let's look at some of the examples. The examples will make it very clear.

Here is user need 2.4 that is based on Annex A. And it's about fixed rate. It says the agency desires to implement a fixed metering rate selected by the central system—or locally based on a time of day schedule to control ramp traffic for each metering lane—for each metered lane. Currently the agency intends to assign the left lane as a priority lane and the right lane as a common lane. So this description has user need 2.4 in organization. It has a title. So it's uniquely identifiable. Now let's check see if the other criteria are met. Unique ID, you can conform, it’s done. Look at the MDC. MDC's about fixed rate. That's something we want from the RMC. Rationale is to control traffic on the ramp, and nowhere do you see how it's to be done. They didn't tell—through this description we didn't tell the system developer how it's to be done—how it should be done. So we kept it solution free.

Other example, in this case, user need 2.5, queue override. It says that the agency desires to implement a queue override operation in the event that occupancy of a queue detector, which is a mix, which is a certain threshold by increasing faster metering rate to flush the ramp traffic to curb delays. Now if you are walking in the room, and you don't know what this thing is about, and someone says please read this. Is this right or wrong? And you say, okay, oh you have User Need 2.5. It’s about queue overriding. Oh, right, yeah, we need this because sometimes there's a lot of traffic out there on the ramp and we need to—we can't keep those vehicles out there. And therefore, we need to do something. Well, here it is the user need that will do something that you expect. So this is a general discussion we are having. Suddenly this user need is speaking to you, and it has all the four criteria that you're looking for. Uniquely identifiable, you have MDC, you have solution free, and you haven't told someone how to design. And then so there's—there's no solution in it. So it’s solution free. So you keep doing these things. Applying this criteria to the other aspects of the RMC operations and—extract the user needs and write them we will begin to make a good level of effort to be with reality.

User Need 2.6, it's about traffic responsive. The agency needs to implement a traffic responsive metering mode. Obviously this is a different strategy. So let's look at unique ID, MDC, rationale—MDC being to implement a traffic response metering. Now not every agency implements traffic responsive. So if your user need—it's not your user need then it will not show up here. So it will not be in your specification. But on the other hand, if you want traffic responsive metering in your specification then there better be User Need 2.6 included. And, again, it is written in such a way that all four criteria are applied here.

Let's look at the Page 8 that has the state diagram, and the state diagram generally indicates how the sequencing between the indication green, amber, red are taking place. So how does actual signal works. So we are discussing things—this diagram here because it also provides us some user needs. This is why it's in the standard A. Now in the previous Version A—Section A was written, but it was not inserted in the state diagram. Here at least we have a state diagram that tells us where to read about that particular section in Annex A. So it's a little more information than before. So the top portion tells us how long metering-to-metering will work. The bottom portions tells us how metering will be reduced to no metering. So we can understand this diagram and begin to write certain user needs that are important for us in our specifications.

So this example, based on the state diagram, as a source user need number 2.7 is about signal service. Again, you read the text and in the text what we have is the unique ID number. Then let's look for MDC. MDC means that to transitioning from a non-metering state to a metering state. So that's the capability we are looking for. That's why we wrote that expression in there. Also, it's solution free, and it has a rationale. Rationale means that we need to advance to warning sign. If you're not going to do the metering then we have to turn on the sign that says metering is off—O-F-F. So for that requirement in our operational needs we have to come back with this language.

Another example similarly done metering and non-metering the RMC unit sees all metering and—signalized control when there is nothing going on. So, our approach works very well as well. Unique ID, MDC, MDC being cease all metering, rationale being at the end of the metering cycle, and it's solution free. So every time we look at this text example we see these four criteria are applied.

So here is now another source—here's another source now, Annex B. So far we discuss Annex A, and what we get out of it. Now let's discuss what have in Annex B, and how we can help ourselves. So Annex B is functionally organized and has the listing of configuration. So we can look at all of this number of configuration and the title we can recognize what they offer. So each one of them is listed here, and on the right it's a description. Just let us—let's—look at an example for B.5. So it says meter lane. And on the right it says meter operation. So if you're going to do metering you really need B.5. So right away our job is set up for us. So if you're going to do metering so you going to have to look at all this conformance group. So how does it play out? Well, this is mandatory. So you will see in the standard tables “M” is mandatory. So mandatory conformance group, in this case B.5, generates the minimum set of user needs. This is your beginning. This is your beginning. We have to start here so that we can say oh, yeah, if I'm going to do metering my first user need is this. So you look at this listing here on this slide. And we are going to react to that, and say, so what am I going to request. So fixed rate traffic responsive and the rest. So the RMC—the user need—will have to be written so we can tell in user need that this is what we want RMC to do for us. And this is mandatory—B.5 is mandatory.

Let's apply this generic process—excuse me. We have developed this generic process in Module A202, and we're going to use it here for conformance groups. So first we need to read the conformance group. So in this case—in this example we were going to set—we going to read the conformance Item 1. Item 2 we are going to read the management information base, MIB. When we read these two things together you're going to recognize certain objects. When we recognize these certain objects we are also going to look at the functionality they perform. So each object actually performs a functionality. So we're going to recognize that as a middle step, and as a third step, we're going to infer the MDC. Just by reading the functionality of object we're going to infer MDC. MDC means major desired capability. It’s always in front of us. If you do the MDC correct then we are going to have a substantial chance of writing our user needs correctly. So this last step is very important in this process.

Let's take a look at an example here now. How we can apply the generic process we just discussed to a real-world situation. So in a real world, for example, we want to do a traffic response to you strategy. So by the way, we are talking about B.4 as a conformance group—traffic responsive conformance group. We’re going to go to page 187 and read it, and we're going to now go to a little more difficult step to recognize it. So on Page 15 you'll find the clause that's listed in 187. And that clause is not going to appear in front of us as an object. So 3.3.2 is a maximum number of mainline lanes. So we recognize and understand that this one is talking about the, how many lanes that we're going to identify as a syntax. So is this going to be one, two, three, four—we don't know. So we're going agree on four that because it's going to be present as an MDC. So—the mainline could be three lane highways, one direction—could be four, could be five—even eight. We don't know. And no one knows it. So we have to actually put a concrete number. So that's what we're inferring as MDC in Step 3 of generic process. So meaning to say M stands here at a syntax maybe four, maybe five. But it's not hundred. No highway has a hundred lanes in one direction. So—we had to be very specific in terms of what the capabilities should be. And that's what it means. Sometimes we need to extract MDC. We need more than one conformance groups. In the previous example we looked at B.5 as one. Well, sometimes we need two as this example shows—B.3 and B.4. So general configuration, there are certain objects attached to that. There's B.3 and B.4 is particular conformance group which is a traffic responsive, which may need maybe four objects—five objects. We don't know that. So what we are saying here is that for traffic responsive plan our user needs are going to come from more than one conformance groups as—this example has shown us.

Let's take a look at an example of a user need. So what is our user need? So you want to say, again, look at the ID showing up 2.9. It says computer RMC unit—very nice title. So now we are saying what will be the MDC? So the MDC is a need to retrieve information. All we are doing is retrieving information from the unit. What a simple way of saying how to do it kind of thing. And then it has the rationale. The rationale is coming from to produce expected operation. Without configuration we cannot do anything. Configuration is the most measured thing we do in terms of telling device what to do, or what not to do, for that matter. So we have to set up these devices in the field, and therefore we need these user needs—very basic one. Again, we didn't tell anybody how to do these things—so solution free.

Another example right away we going to apply the criteria and this is about command source priority. So after doing these things several times you will see the—title itself is telling you what it's about. So command source priority and if you remember we discussed five commands before. So when you write this user needs you're going to see how the textual discussion is taking place. So it says, for example—on second line it says, "For five priority-based mechanisms to control the RMC unit to take metering actions." The source is designed in priority, and they're listed. Manual is first one. Command source is—and the rest of the details appears. This detail is necessary. This particular user need requires this level of details so that it is complete. Again, it's MDC, rationale, and solution free.

Another example, in this case the command source itself what it is going to do? So this one is telling you that any type of one—any one of those four command—or five command sources that we discussed will have to do four actions. First, it has to take an action—the particular action. It has to even provide the metering rate. Have a prior metering plan and provide for grade indication—how many vehicles. So these are the type of action that coming through the parameters. So every command source must prove true. Now we say what about just like action, and they know what they're doing. Let the vendor decide how it's going to be done. Well, you may have an incomplete user need here, which will create an immediate situation and the interpretation will not be good. So I'm reminding you at this stage why this is important to write in a complete manner. User need must be complete so that we can make the meaning.

How all these things coming together? Well, we just so far discussed user needs. We also have discussed functions—what the RMC do. And now we are saying what action they will take. So one of those five actions is going to be done on the right-most side in the box—action. So each command source will be charged to take one of these actions at the request of the traffic management center operator. So if you look at this slide as a general discussion of how RMC is going to work out for us and that's what we want to focus on. So the last five actions are actually important in terms of how the standard supports it as well as how they use it in each other. So about example—in this example we're talking about metering direction. So now remember this we are already in development of User Need 2.12. So we have done pretty good work actually in this module by identifying 12 user needs. So if you keep doing this thing in your specification you will also achieve this progress. Now, around this time when we identify user need number 12 we are actually speaking about the action. What action the meter will perform. So there are five actions every meter must perform. So very clear. So dark, resting green, fixed rate metering, traffic responsive, and emergency grid. So we have left nothing out based on our needs. So any Vendor A, any Vendor B, and C everybody's going to read this user need the same way. So that's the beauty about writing using this criteria. So it has ID, has the MDC—MDC being five metering operations capability. It has rationale. So we manage recurring traffic congestion. Why? Because if we have fixed rate, and we have responsive things change in the field. So we have pretty good handle in terms of our current needs. And then we are keeping it solution free. There’s no indication of how it should be done. So this a good list of user needs. There are 12 here. This is also in your supplemental. So I would suggest that you also consult your supplemental. And if you're agency level you should have a very good list of user needs generally along this line with the similar titles and you can—you have now organize way of presenting your user needs in your specification.

So what to do if certain user needs are not met by the RMC standard? Well, you saw the list of 12, and obviously that is not a complete list. So you can say, oh, this is not that. This is not that. And now what do you do? So in your real world situation if something shows up and says I got this need, but standard is not speaking about it. Standard is not supporting it. What do you do? Well, here is some comfort that we are providing you through this module. Establish whether any non-standard capabilities are necessary. Not just RMC but particularly not I'm seeing here. But in general we have to pay in our mind—mindset that, yeah, is non-standard capability really belong in the middle of we are deploying a standard. You have to look at it very closely this particular issue. Once you establish that there is a real need, and this discussion ends there. Then there is another part to this. However, you must establish whether you really need this capability or not. So if you don't need the MDC don't ask for it, otherwise you going end up providing the solution, and that's not going to work out.

Second point to this discussion is ramps are local. And each ramp has a customized solution. So we look at the corridor and you have 10 ramps in the corridor and you have four or five of them working differently than the rest. And you don't want to be in that situation. Think about that. Because your central system has one control software, and you're not going to make exception in every location. And you are going to lose the whole thing. Also, this is part of the Freeway Management System. We'll talk about a little later this particular discussion about the interoperability, but I will hint with a little bit saying that we want standardized solution in the corridor not customized one. Or, custom solution which our propriety I meant. Also the cost implication. If you extend the feature there's going to be a special specification. There's going to be special testing that's going to be maintenance. So proprietary solution always brings this cost issue big time. So if a proprietary custom solution is warranted due to additional needs functionality. The user needs driving the solutions should be documented. So there is a propriety of the solution in the wing, and you will have sensed it you must create the user need that describes it. Why the rationale so everyone can understand it, and they understand it in the context of, yeah, this is why this user need exist. So, okay, so there is a treatment for that.

Our activity here is related to this question. What is the best source of user needs? A) freeway traffic management concept of operations, b) the general ideas architecture, ramp metering service package, c) NTCIP 1207 Version 2 Standard documentation, or d) all of the above sources. The correct answer is D, all of the above sources. It’s correct because we need all of the above sources and all of our sources have links to user needs. So we really need to asses each one of them. A, is incorrect because, yeah, I agree with you that traffic management counts of operation has good detail. And that's why we talked about it in learning objective 2. So we agree with that. But it's only partially true. You only get certain information from concept of operation. So that's why it's incorrect. B, again, we know about ATMS 04 Service Package, but again, it's distinctive to the framework. It does not touch the ground level reality in the sense that it doesn't have enough details. So that's why it's incorrect. And the answer c is also incorrect for similar reasons that they are providing us information in Annex A and Annex B, but it's not complete. It’s not sufficient. So in all of these three incorrect answers we want to say that they are good sources, but they are insufficient. But, together we need all of them. We need all three of them so we can complete our work. So that's why the answer d is correct, all of the above.

So summarizing learning objective 3, we realized that RMC user needs don't exist so we had to extract them, develop them, and write for our acquisition process. We discuss how to extract them, write them, we use a four point criteria. We have several examples we went through. And we also touched base with what we should do if the standard does not meet our user need.

Now we turn our attention to the last learning objective for this module. Explain how to evaluate conformance to the RMC standards. There are two points here. One is that what are the minimum conformance requirements? And second one is that how to address backward compatibility issues. So what are the minimum conformance requirements? So conformance is a very widely used word or terminology and it relates to meeting rigid requirements or minimum requirements. In this RMC standard we have two ways to look at these things. One is the mandatory objects or mandatory conformance groups actually and related objects, which are basic types of conformance requirements. So M means mandatory. So to conform to 1207 Version 2 Standard we must list those conformance groups in the specification. Also, we have certain conformance groups—actually one conformance group that we need from 1201—NTCIP 1201 Version 2, which is a global standard, which lists design data on checks for all devices not just this one. So every standard—every device that we talk about in NTCIP require both standards—both this conformance groups. So RMC requires many data conformance groups as well as conformance from configuration conformance group from conformance from 1201. And then you have optional conformance groups, which are based on what the agencies needs are. If the agency decides the certain functionality they require than they will have to select optional conformance group from the list. So let's look at the—the table. This is the Table B in the standard. And our job here is to understand and learn how we can help our specification. So, for example, B.5 is M. Everything M is required to conform to the standard we're going to have to pick—select support for—for that conformance group. That's why B.5 is—is circle here with yes. Similarly B.12 from 1201 is circled as a yes. So these two conformance groups are required to conform to the standards. And the rest are optional. So if you select optional any one of those optional you will have to circle yes. At that point they will become part of your specification, which will be required. So the word mandatory is created for that reason to point to you that they are the minimum requirement as we just discussed.

Optional as picked or selected by the agency. Here's an example of mandated conformance groups which is selected yes which is a meter lane conformance group, which has a certain number of objects listed here, which are also required. So this will become part of the specification and selected yes. So for conformance to the standard this conformance group is required. And for optional, similar, we have to select yes in this case we have selected yes because it's a metering plan, so this will become part of our specification.

So this one we going to say is compliance issue. So optional relates to the compliance issue. We have selected so we're going to make sure that whoever works on this project will have to comply to this optional objects as well. So there is this general separation of how this technology work. Conformance is to the standard. We want to say that clearly. Conformance—when we say conformance we are saying minimum requirements of standard must be met. Compliance is to the specification. Whatever the user—or the specification writer has provided in terms of optional, yes or no. It if shows up yes it's a compliance issue. So compliance generally refers to what the spec says.

How do we address now conformance and user needs? In this particular standard, unfortunately, we don't have much to go by except that we have conformance group in front of us, and they do lead us to the user needs the way we learn in the generic process. So every conformance group has link to the user need, and that's what this table shows. So in your specification a table of this nature should be there so that you can tell actually what conformance group and what user needs are linked.

Now comes the interoperability issue. This is a very important issue. We have talked about it earlier—early on in the presentation. Here we are saying that the item specific discussion says that RMC needs a remotely access and may be controlled by a management station located at the TMC or other operation centers. So—and remember that ramp metering the concept is part of the Freeway Management system, which is a larger effort. Freeway Management System also includes multiple devices that are necessary, ESS, sensor station—so many different things. So we want to make sure that the interoperability among the TMC's—different TMC's exchanging information with each other is—is achieved by keeping RMC at the level where it's accessible. Information related to RMC is accessible. And that's only going to happen if you keep the specification at same for all agencies that they want to do that. For example, user needs must be same, design solution must be same, design data objects, dial-up must be same. And suddenly the common protocol for compatibility. So you're talking about different issue. So interoperability it's not just the RMC for traffic controllers themselves, but you are talking about Freeway Management Operations. And eventually, you will be also concern about the efforts we make in ITS. ITS is about improving interoperability in general. So those are the larger issues.

Ramp metering is a component of Freeway Management System and—multiple agencies are also involved in it. So you can be certain about that some kind of information about the freeway management is going to be exchange between the centers. So that will also require a center-to-center protocol of the standards. So there are several interoperability issues, but the reason why we are discussing this particular point here is that we want to make sure that we understand that ramp metering is part of the Freeway Management System, which is part of the ITS operation conducted at traffic management centers to respond to our operational needs in highways and in our corridors in the region. So these are general issues.

Backward compatibility is also another concern because we are talking about Version 2 here, and Version 1 is out there before us—before this version. So you might say well, what if I did something in Version 1, is it compatible with Version 2? So luckily the Standard Version 2 does not have too much of an issue here except for some minor few things. So Version 2 is compatible with the exception being that we have to understand that in some syntax notation we used to use zero to 255 as the range of a syntax. So if you are consultant or a developer you should make a note of that and realize that in this version we start with 1 to 255. So there's a syntax change in there. The dialogs are not available so we have model dialogs from the other standards, ESS for example, that we discussed. So to maintain the consistency may be an issue. So we have to really sure how we implement our dialogs as well.

And then third thing is the mixing of ATC, for example. This is a very important question to answer. Can we mix the traffic controllers? Well ATC is here and 170 was back then. So now we say, yeah. Answer is yes, you can actually do this if you are carefully implementing the user needs and the local interface. So these three issues are related to the compatibility, and we have to pay attention, and actually check off one at a time.

Our last activity then is answering this question. Which of the following is a false statement related to the NTCIP 1207, RMC, Version 2 standard? A) Only metered lane conformance group is required to conform to the standard, b) Traffic responsive conformance group is optional, c) Version 2 Standard is not compatible with the previous version, and d) A conformance group represents one or more RMC unit function. The correct answer is c. Version 2 Standard is not compatible with the previous version. It’s correct because the statement is false. We just discussed it that Version 2 is actually comparable with the previous version. So that's why it's a correct answer. A, is incorrect because the statement is true. It is mandatory conformance group. Meter lane conformance group is required in every specification. B, is also incorrect because the statement is true because agencies do take optional traffic responsive group conformance group. And d, is also incorrect because a conformance group is actually is a grouping that represents a function.

So summarizing learning objective 4 that we reviewed the RMC standard conformance requirements as stipulated in table B2 including mandatory conformance groups. We also reviewed interoperability and backwards compatibility issues. We also actually, touched base with saying what a conformance based conformance is to the standard and compliance is to the specification. So we also discussed that to remove the confusion.

What have we learned? In this module, well, NTCIP 1207, Version 2, Non-SEP Standard does not have user needs. And we must identify and write them using criteria. Two, RMC user needs can be found in concept of operations, conformance groups, and operational descriptions. Three, a user need must be uniquely identifiable, defines a major desire capability, and provides a rationale, and is solution free. Four, types of metering include pixelate metering, traffic responsive, and corridor-wide metering adaptive. Five, highest priority command source in RMC is manual followed communications. Six, all mandatory conformance groups must be included in the specification for conformance to the standard.

Our next module on RMC is about requirements, understanding requirements for ramp metering control and units based on 1207 Version 2 Standards. This module will also basically tell us about what the testing requirements are about the RMC units. The sources for this module are plenty. The standards are available at the NTCIP site or you can actually download the standards and also there is an NTCIP 9001 guide that's written about the NTCIP, which will help you to understand what the subject matters are. Also A202 is Identifying and Writing User Needs When ITS Standards Do Not Have SEP-Content. So this a particularly useful, and related to what we are discussing today. In your student supplement we have provided general overview of the practice—RMC practice. It also has an RMC user needs list and references on the practice in general. So we recommend that you review the content of the student supplement. The third important aspects of RMC is also shown in this video. It’s a very short four minute video, Kansas City SCOUT. The link is provided here, and we recommend that you hopefully have a chance to view that video and understand this subject. So it will give you some broader aspects of policy and ramp metering.

So some off the questions that we encounter in this subject that previously we have seen includes, such as, say, for example, one question generally comes up is that “I have this 170 traffic controller, and we are now going to have, on several ramps we are planning to install ATC. Can my central system handle that?” And the answer is, yes. The standards it's independent of the type of controller that you use. Whether it's 170, or 2070, or ATC. So that part is pretty good. The standard provides all the functionality necessity, and it will be handled by any type of device. Another question often shows up is “What is the role of central system?” Now, this is one of the reason why we wanted to make sure telling you in this module that the intelligence about the RMC resides in the traffic controller at the local RMC level. So if you have ATC, for example, and it's powerful enough—and ATC is powerful. So you can actually put all your information in it, and you'll be done with the system functionality there. So ATC can perform that. One other question also has been raised in general preparation of this module whether the TSS 1209 Standards—NTCIP 1209 standard can be also included in the specification. And if so then what is the role? Yes, TSS stands for traffic sensor stations, which collects the occupancy vehicle speeds and flow rate, how many vehicles related whether they are passing at any given time. So such information is vital. And it's available. And it could be used for different purposes but for RMC TSS general view data can also be used.

One other point in this general discussion about the RMC unit is that the data that we generate in between—in the corridor you have so much data being available. Can this be used? And answer is, yes, we try to say that this data requirement for TSS is very many part—sorry—for the RMC and it is very minimal. It only requires four traffic responsive purposes. And if you have every two seconds data that's fine. If you have 10 seconds data minimum data is also fine. So all of these things are doable in the general context of Freeway Management System.

One last question that I will also raise here that there are some of the propriety solutions that are coming up on practice in the country on ramp metering includes density—traffic density versus traffic occupancy as we discuss in this module because this standard support proprietary traffic density base algorithms. The answer is, no. This standard supports the data based on occupancy, flow rate, and speed. So these are some of the questions that might help you understand what is doable, what is not doable, what are the limitation, and this brings us to our module completion.

#### End A309a Understanding User Needs for Ramp Meter Control (RMC) Units Based on NTCIP 1207 Standard ####