Module 10 - A311a

A311a: Understanding User Needs for DMS Systems Based on NTCIP 1203 Standard v03

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.

Ken Leonard
I’m Ken Leonard, the director of the U.S. Department of Transportation’s 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 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 www.its.dot.gov/pcb. Please help us make even more improvements to our training modules through the evaluation process. We will look forward to hearing your comments, and thank you again for participating, and we hope you find this module helpful.

Raman Patel
Hi, this module is A311a: Understanding User Needs for DMS Systems Based on NTCIP 1203 Standard Version 03.

Raman Patel
I am Raman Patel, your instructor for this module. I have very extensive experience in SDO process standards development organizations where we have been involved in NTCIP—a device standard—and SEP-standards, which also includes dynamic message signs. I was formerly at the New York City DOT, and Chief of Systems Engineering for over 30 years or so. Currently, I’m teaching at NYU’s Tandon School of Engineering and Transportation-ITS courses in Systems Engineering.

Raman Patel
We have four learning objectives for this module. The first one is to review the structure of the DMS standard: what’s in the standard and what kind of information will be interesting, and where can we find the information. In Learning Objective 2, we'll identify specific DMS operational needs—what is that we are trying to do with the DMS system. Learning Objective 3 will take us into PRL, which is the Protocol Requirements List, where we will begin to understand how the user needs are organized. And in the last one, we will discuss how to prepare a project-level PRL, which is required for every specification whenever we try to acquire a DMS based on standards. Together, these four learning objectives will prepare us and give us additional skills to prepare a specification to acquire dynamic message sign-based systems.

Raman Patel
Objective one is to review the structure of the DMS standard: what's in it, what kind of information we can use to prepare our specification. We will review that in detail and familiarize ourselves with it.

Raman Patel
What does a dynamic message sign mean? Well, the standard defines a dynamic message sign as any sign system that can change the message presented to the viewer. And what it means is that there are a number of types of signs that are covered in this standard. The word “dynamic message sign” actually covers a range of signs that we use in practice.

Raman Patel
Major components of the DMS systems include sign housing. This entire structure that we see on the roadways is called sign housing. The sign faces the front portion where the actual message appears. It's the surface where the message is written and we see it in a changing manner. The cabinet itself is located nearby the sign and has a trap controller in it, which controls the signage operations and also provides the power and the details that come through in terms of networking. This controller is any kind that comes from the device manufacturer. It will be alongside the sign in general provided by the DMS vendor.

Raman Patel
The NTCIP framework. You have probably seen this framework before, but if you have not, the framework provides us the necessary protocols and the information level. We have a device dictionary or vocabularies. For example, 1203 NTCIP. 1203 is for DMS. We also have a companion global dictionary that allows us to combine data sets for different devices. At the Information Level, we have the dictionary. At the Application Level, we have SNMP—a Simple Network Management Protocol—which allows the message to be carried back and forth between the device and the Management Station. The other subnetwork level protocols that you see underneath this structure help us to communicate the data set back and forth and use a networking kind of subset protocols. For example, TCP/IP or UDP/IP. These are a transfer protocol to take the message further into networking. And we have others shown here on the diagram that will allow us to complete this step. You need the whole service from this network set.

Raman Patel
DMS characteristics supported by the standards. DMS types are the capabilities that DMS offers for handling messages. DMS technologies are various types—different manufacturers supplying science with different technologies. DMSs are also organized by the way they show the message on the surface by configuration.

Raman Patel
Let's look at each one of them in terms of the signs that are manufactured for particular message types. Blank out signs, they only display one message or nothing, and they are used, for example, for showing no left turn or also at the toll plazas when you pay the toll. The changeable message signs—or CMS as they are referred to—they have predefined messages. They are fixed messages. There may be one, two, three—as many as eight—but they are fixed messages. One of them can be displayed on the sign at a time. On the other hand, a variable message sign, or VMS, is a very widely known terminology in our industry. It has the capability to display real-time messages. What it means is that you can remove the message that's existing right now, and then put in a new message. Variable messages are understood in the sense that they provide capabilities to change the messages any time you want.

Raman Patel
There are many DMS display technologies: fiber optics, light emitting diodes, shutter, the old lamp matrix, drums. All of these types of technologies are supported by the standard.

Raman Patel
Where you write the message on the sign surface is a very important methodology that we do in many different ways. All technologies support this. A Full Matrix is that you write a message anywhere on the surface, as is shown here on the top of the box. The Line Matrix in the middle allows you to display your message in three lines, but each line is separated from the other and there is a space in between. The third type is the Character Matrix that is shown here. Each of these characters is separated among themselves as well as between the lines. Every character is usually shown, and then a message is created that way. All of these three types of matrix structures are used in the field.

Raman Patel
It's very important to realize that messages are effective only if they are organized and displayed with each line stating a specific meaning clearly, and in sequence. With that said, the first line always identifies what problem it is that we are identifying for motorists to view. The second line always identifies the location. If it's not an exact location, it's an approximate location—like in this case it says “after I-90.” And the third line is always reserved to identify what action it is that's needed—what you want the motorist to do. These three important criteria are applied in terms of how a message is organized and displayed.

Raman Patel
Sometimes if you have a longer message, what should you do? The first page considered as a page is a first message with three lines. If you have a longer message then you need another page—as it's called—with a different continuation of the message. You can build your longer message in sequence in a proper way using the word “page.” The page is also sometimes called a “panel.” It's a different name, but in the standard we will use the word “page.” The terminology that's used is page. Page one here, for example, will show the message that you want motorists to know right away. Then a few more details will come up in the second page, and so on. Sometimes, you also have the ability to increase to longer messages by providing additional pages.

Raman Patel
How is the message actually displayed on the sign surface? There is a language called Markup Language for Transportation Information. It's called MULTI. MULTI is actually based on HTML—the one that we use very much on the Internet accessing pages. This language allows us to have in our DMS standards about 18 tags. Using tags, we can display the module. The first tag will say “module.” The second tag will say “A311a.” The third one will say “is.” The last one, “about,” and then continuing with the “DMS UN.” All three lines are built by using these tags. We don't have to know too much about this because all vendors support this MULTI language, and we are okay with that.

Raman Patel
Reference architecture for DMS. How many different ways can you control a sign? On the left here, shown at the bottom—Management Station, for example, can directly communicate to the Sign Controller on the right side. That's one way to do it. The second way is to have a laptop computer actually communicate to the controller. The third way is to go local, where you can actually go to the DMS controller and use the keys on the front and communicate to the sign that way. So there are three ways to do it. The communication between the controller and the sign itself is proprietary in nature. We don't really have an interest in it. It's done by the manufacturers themselves. That part is not covered by the NTCIP standard.

Raman Patel
NTCIP 1203 Version 03 documentation is organized into two parts. In Part 1 we have several sections. Section 1 has the general information, detailed administration, normative references; Section 2 has a concept of operations and user needs, which is our focus today in this module; and in Section 3, we describe functional requirements that also include the Protocol Requirements List. It's a matrix that we will talk about today in this module. We also have Section 4, which is dialogs. Section 5 has the management information basis to the design of the DMS data elements and the last one—Section 6—has the MULTI language, which lists the text.

Raman Patel
A couple of annexes are also organized in Part 1, starting with A, B, D, E, F, G. They provide additional information. One of them is RTM—Requirements Traceability Matrix—which also helps us to connect requirements to the design. You have separately, in Part 2, something called Annex C, which details these procedures. These test procedures help us to test whatever we buy. Design-wise and requirements-wise, it will be tested using such test procedures in Annex C.

Raman Patel
What's new in NTCIP 1203 Version 03? Well, Version 01 was published way back in 1997. It was amended in 2001, but had no SEP-based content. It was just a design, so there were no user needs. After the initial experience, we learned a lot of lessons that got translated into Version 02, which was published in 2007 and added new functionalities and new user needs. It was SEP-based. What that means is that now we have described standardized user needs as well as the requirements that connect to those user needs. We learned a lot because we deployed in the field, and we learned what worked/what didn't work. That got refined in Version 03, which was published in 2011. All of these Annexes that you saw before, including Annex C, were added to enhance the value of the standard and provide more information.

Raman Patel
What's really new in terms of focus? Annex C provides the test procedures, which is very important information that's available to users. Second, it made minor corrections to what didn't work in the past. It's already documented in Annex D. Not to make the document very heavy, it was divided into two parts. Both versions are SEP-based—02 and 03—and they provide user needs, requirements, dialogs, PRL, and RTM. Both are compatible.

Raman Patel
What are the user needs? User needs are standardized statements that describe what a DMS should do. They describe features and functions. If every user need has a unique ID, these are the criteria. There are four of them. Every user need has a unique ID. It provides a major desired capability—MDC, it's called in short. It has a rationale why that user need exists—what it is that we need it for, and it is solution free. When you write down the user need, there is no solution in it. We have to wait until further down in the sequence of events for a solution. However, the user needs will have major desired capabilities, which is a substantial portion of the description.

Raman Patel
Let's look at an example here as an illustration. Blank a sign. The user need says that this feature enables the operator to remove any messages displayed on a sign causing the sign to blank. If you don't want to say anything on the sign, you can eliminate that message by implementing such a user need. It has a unique ID-Title, it has remove message as an MDC, and it has a rationale for this being a user need—why we really need it. Like you say on the left here, you have a message, and on the right, you have a complete blank out. That's what this means.

Raman Patel
DMS user needs organization in NTCIP 1203 Version 03 is pretty straightforward. The most basic Architectural Needs are organized in Section 2.4. There are four types underneath which support different functions in terms of communication between the Central Management Station and the device out there in the field. Then you have 2.5 User Needs or Features—the standard causes features. There are three types. The first set is to manage the DMS configuration putting the sign in order, location ID, all of those different things that the sign carries with it in terms of which asset base. That's covered under 2.5.1. And for Control, the DMS functionality, is provided under 2.5.2. And then additional capabilities, what the users' needs will bring to the features for monitoring the status of the DMS sign, are covered in 2.5.3.

Raman Patel
Let's have our first activity.

Raman Patel
Which of the following is a false statement? There are four answer choices here: A, B, C, D. A) DMS standard contains SNMP interface; B) DMS standard lacks testing documentation; C) DMS standard supports all types of DMSs and technologies; and D) DMS standard includes protocol requirements lists, or called PRL.

Raman Patel
The correct answer is B because the DMS standard lacks testing documentation. It's really not true. It's a false statement because Version 03 does provide test procedures in Annex C. Answer A is a true statement: The DMS standard contains an SNMP interface. Answer C is also a true statement: The DMS standard does support all types of science and technology. That is a true statement. And also, D is a true statement because the DMS standard includes protocols. In fact, it's a big part of the standard that we will review today in this module.

Raman Patel
Learning Objective 2 is to identify specific dynamic message sign operational needs.

Raman Patel
Let's go ahead and look at different ways dynamic signs are used in the real-world environment.

Raman Patel
What is a concept of operations? We have heard this term before. The concept of operations communicates user needs and expectations for the proposed dynamic message sign system. What it is that you are looking for from a dynamic message sign will be the subject matter for the concept of operations. It provides an operational context of a DMS sign: how it's going to be used, where it's going to be used, what it will do, what kind of function it will perform. All of those things will show up in the concept of operations. Let's look at this description here from the standard itself. The fundamental needs of driving DMS deployment—what it is that's driving this whole process. It says the provision of timely and reliable information to the traveling public. To improve public safety and convenience by providing advanced notification of items that may be of interest. And then going down in detail, you can also see the road conditions—for example, what is really happening on the road. And then the arrival of transit vehicles—another part of the concept that dynamic message signs do. This descriptive nature of what drives this DMS system deployment is very important in terms of understanding user needs.

Raman Patel
Let's look at this example—concept of operations from Indiana DOT. It's really a nice case study. This is actually what the agency is saying—that the DMS provides dynamic operational information to motorists, including incident, traffic, and road condition information, emergency alerts, travel time information, and other advisories. You're looking at the sign below and it is slow traffic I-69 north near the116th/mile 204—all lines slow. This information is now provided to the motorist. What does the motorist do? Motorists can use this information provided in real-time to select an alternate route, or divert, or delay, or even cancel their trips to avoid traffic delays. Such a combination of information—the road condition, for example, or emergency alerts—allows motorists use that information and make alternate decisions. This whole concept emerges in two parts. First, the information is provided in real-time; and second, that information is used to make another decision, or several decisions, to utilize that information and make the roadway condition more appropriate for the motorist's use.

Raman Patel
Who benefits from user needs or the use of DMSs? Look at three different ways—the public sector, road users, and the private sector. Let's look at the public sector. The public sector deploys so many ITS devices and operational strategies. DMS is part of that overall ITS deployment, as we all know. To achieve ITS objectives, DMS is playing a really good part because it connects to the motorists by providing that information in real-time. Also, it provides safe and efficient mobility capacity. If motorists are kept safe, the roadways are kept safe—safe for the efficiency of the roadway in terms of speed management—how many vehicles can pass through a particular section of Broadway—all of those things are very important in terms of efficiently managing the mobility and the capacity constraint that we have. And then real-time messages to the public. DMSs provide real time messages so we don't have any delays. If the agency knows at the Traffic Management Center—or TMC, as we call it—the public should know it at the same time. These benefits are occurring for the users of dynamic message signs. At the road user's level, the users themselves see visually—they don't hear any voices. What they actually see is a clear-cut message out there, and they say—this is what's happening. They read it, and then they make informed decisions. This is what they can do. You see, making informed decisions requires some input information, and that's what dynamic message signs provides to them. The private sector has a very large installed base. The whole industry is engaged in providing different types of technology—different signs capabilities. This is a huge marketplace activity that dynamic message signs are engaged in. And we have a pretty healthy way of looking at all of these three things together.

Raman Patel
Operations staff use dynamic signs to improve operations in a very straightforward manner, like we show here on the left. The Traffic Management Center provides real-time information with three types of information—advisory information, regulatory information, and specific event information. The traveling public make decisions based on real-time information. This information is used in terms of improving all of the outcomes. We benefit in four different areas. One is the traffic flow. The public gets information and implements their decisions in real time—that will improve the traffic flow, speed, throughput, and all of that. Also, this makes roadway safety much better because people suddenly don't change. This isn't based on information they are given. That actually helps overall, and it helps the overall environment. Everything moves smoothly. In general, we want to say that mobility management benefits from all of these different things that the DMSs will do for motorists and the traveling public.

Raman Patel
Our first level of activity is to convey advisory information to the traveling public. This sign on the left says, “Road closures, road work Exit 53.” This kind of detailed information is provided about the roadway closures. On the right sign, we have a message about the condition of the traffic. Both the road closures and the traffic conditions are advisory information. It's given to the public as it's available, and the public can make their decision based on what the information says.

Raman Patel
Convey advisory information to traveling public one more time in terms of weather warnings. Suddenly, the weather changes—winter weather or whatever condition that is occurring—this information is provided to motorists in real time. Black ice, for example, as shown here on this slide on the left: It's a huge issue in this country, and we have been experiencing this for several winters. These are real time messages. They help us in warning motorists to slow down. Similarly, if sharp curves are ahead, motorists may not be aware of it. In fact, they probably will benefit significantly if you provide them information ahead of time and say there's a curve, and your speed is this much and you should slow down. This kind of beneficial information also helps to remove or reduce accidents in these sharp curve areas on the highways.

Raman Patel
Conveying advisory information to the traveling public. What is the advisory travel time, for example—estimated travel time. These are significant improvements from where we were 10 to 15 years ago to what we are now displaying across the country. This kind of information is predominantly available in most highway systems we now have. It provides you the approximate time for travel from your approximate highway location to further down the road using some kind of milepost or something. People feel good about that when they see some kind of advisory available in terms of estimated time.

Raman Patel
Similarly, for transit vehicles, if you stand on the subway platform waiting for a train and you see the sign showing that the next train is in two minutes, you feel much different than when you have no information available. This has also changed in the transit area—the arrival time of buses and so on.

Raman Patel
Advisory information for the traveling public—for example, HOV lanes, which is a very substantial portion of highway operations in the country. HOV lanes are design built for proper operation for speed management as well as efficiency. They are segregated—on the side on the left, shown here. You don't want to be in that lane if you don't have any intention of traveling in the HOV lane. These kinds of warning signs are put ahead. Some motorists are kept away from the HOV lane if they don't intend to use it.

Raman Patel
Regulatory information is very important. This sign shown here conveys regulatory information. It begins with telling people that the speed limits are there. The activity shown here is fixed speed or variable speed. There are a lot of signs now showing variable speeds on the highways. For example, in the travel corridors where you have some activities going on. Also TDM—Travel Department Management—techniques also allow you to use the shoulder. Whatever methodology is used, you have information available. This also includes mandatory detour information. Things can go bad, and occasionally on the highway system you will see these kinds of signs that tell you what to do. For example, an evacuation is underway. Evacuation is a big part of highway management. As we all know, at times we have to use certain segments of a CBD—or Central Business District—or part of the region to make travel smoother in terms of evacuation. These signs are put along the roadways and they provide real-time messages.

Raman Patel
Convey special event information. Sometimes we have a very express need to provide high-value information, as shown here on the left sign. We're showing that there is blasting 30 miles ahead, which is very substantial highway information. You don't want people putting themselves in harm's way. Also, we want people to know what's going on. Many different reasons are out there for them to know what is occurring in the general vicinity of their travel area or travel corridor. Amber Alert is another area which has a timely value, and that also goes out in terms of conveying special event information on what is occurring. On the right side, we show two signs for extraordinary events that occur in metropolitan areas, which requires closing down busy tunnels until the enforcement activity is cleared. All of these things are also very important. Together, this message tells us that at any time there is a special event that is occurring, keeping the public informed as the event progresses is very important. This is especially true in metropolitan areas.

Raman Patel
Activating a flashing beacon to draw attention. If something has changed and an important message needs to be brought to the attention of the traveling public, then a beacon—which is a flashing light—will go on and it will tell people there is some kind of message. People will pay attention to that a little more closely. The sign on the right here, for example, says the speed limit is now 45, and to watch for changing conditions towards where you are traveling.

Raman Patel
Managing information from multiple facilities. There are all sorts of centers out there now. Traffic Management Centers, for example. Roadside signs are out there, moveable portable signs, vehicle-based signs—all these things can be controlled from more than one location. Also, transit platforms—train stations and bus depots—and parking facilities. Wherever you have a need to control the information process from more than one location, the signs come in very handy.

Raman Patel
Generally speaking, supporting the operational environment with the communication interface. This is the focus of what we do using standardized processes. We can have a Management Station on the left here shown communicating to the Sign Controller on the right. In between, the architecture communication process takes place. These user needs allow us to maintain our communication requirements by providing the proper user needs. At the bottom, we show a sign that displays messages. This sign needs to be controlled from the Central Management Station. There are three types of operational needs that come up here. One is the configuration of the sign. The sign itself has to be properly organized and identified location-wise, and have many other things on it. Then there are the capabilities of features to be controlled—what the sign will do, what kind of message it will display. All of these control mechanisms are present in the operation. And then finally, we also want to monitor the sign—what it is doing in current time. It can see both the architectural communication needs and the operational features at the bottom coming together to support the operational environment.

Raman Patel
In terms of live data exchanges, whenever we have communication connections always on we can communicate with the sign in a request and response manner. We ask the sign for some kind of information; The sign will respond to us. This happens continuously using a request and response mechanism. In terms of changing the message, we issue controls and commands. We issue a command message and say you should do this right now for us, and the response will come back. This occurs whenever there is continuous communication between the Traffic Management Center on the left and the sign in the field on the right.

Raman Patel
Sometimes when the communication is broken, or in the old days when we were using dial-up communication and there was no cabling available and no high-power networking available. In these cases, we use a methodology to retrieve data which is logged internally in the traffic controller in the field. For example, on the right we show that the traffic controller door was open at 2:00 a.m. The power was on at 3:15 a.m. Something happened. These kinds of events are logged inside the sign controller. When the communication is restored, the Traffic Management Center will actually get that information and be aware of what really went on. Remember, it is the business of the Traffic Management Center to know what the sign is actually doing at all times. Whenever there is a communication, they should know. But when communication is lost to the sign, they should also be aware of what really happened in the last period.

Raman Patel
Let's summarize operational needs supported by the standard. There are four areas we discussed. One is the managed DMS configuration—the sign putting itself in order configuration-wise, location identification, manufacturer, and whatever else about a particular sign. The second is controlling the sign—the functionality of the signs. We want the sign to do this, this, and that. That part of the user need is supported. Monitoring the status of the DMS—what is DMS actually doing at the current time? All of that monitoring process about the health of the sign, or the status of the sign, is known to the monitoring. Performing diagnostics is closer to what is really not working, what is working, what the condition inside the inside the controller is, what the pixel level is—for example, some pixels may be bad or not working. All of these things tell us that we can remotely perform diagnostics to the sign so we don't have to send people into the field. Managing the configuration, controlling the DMS, monitoring the status of the DMS, and performing diagnostics. These are the four key areas where all user needs are organized by the standard and supported.

Raman Patel
Managing DMS configuration—for example, what type it is, what is the make, what is the location, what is the ID number. Over the years—as shown here in this regional map, for example, on the right—you have a number of manufacturer's types of signs out there. In order to find out what the signs are and where they are located, the configuration will identify each sign by DMS type, make, location, and ID. For example, this is a Daktronics sign, as shown here. Or this is any of several manufacturers, some of which are shown here. That's important to know.

Raman Patel
Managing the DMS configuration. As shown here, Interstate 95 on the sign on the left side. It could be on the right. Who knows? We don't really know. We need to manage how the sign will actually look—how it will display the message. Managing graphics, managing font size, color, height, weight. All of these things are important in terms of how a particular message will show up on the surface of the sign. Brightness—if you are using LEDs, there will be a need for maybe changing the brightness. If the light condition changes in the field, maybe the TMC operator wants to change or adjust the brightness at some place. This can be done through the configuration process. But you have to set it up for that. And this determines size display capabilities. All of these things can be required—what the sign can do for you. That's all part of the configuration.

Raman Patel
Controlling the sign is very interesting because this is a 100 percent operational activity. This is where the TMC actually uses the sign to coordinate, control, and inform other people—for example, more than one Center. The way it works is shown here in the diagram. You can control the message from one Center. Another Center can send a request to you. You can remotely set the sign controller in the field. You can also adjust and control the brightness of the outputs of the sign. You can also control external devices. For example, there is another small sign somewhere or a beacon. All of these capabilities have a controlling nature. There will be a time when somebody will intervene and change the condition or request some kind of different action. All of these things are now done in the real world in a very intense way because Centers do share and control each other's signs and information.

Raman Patel
Monitoring the status of the sign is a very important activity. The operators are trained and they have interests in looking at signs in real time to see what it is doing now. If they need to change the display mechanism, or the display matter, or the display messages, they could do that remotely from the Traffic Management Center. The TMC shown here on the left upper-corner is now monitoring the sign—that's way below on the right corner—passing through the DMS controller. Eventually, an operator will see the message on his workstation reflecting what it is out there in the field. It's an exact replica of the message that's being shown. With that conformance, the operator will be feeling good about it, or he may not feel good if the message does not match the way it was expected in the software. These are important types of monitoring functions that are being performed.

Raman Patel
Performing diagnostics is a very important activity. After all, a DMS is a heavy investment device out there. Things do go wrong, and we often need to perform diagnostics—maybe a scheduled diagnostic or unscheduled event. Whatever it is, performing diagnostics is an important activity. It allows us to determine the sign errors—also at the high-level diagnostic, we can find that one out—but it's also with the label we can also see what the errors are about, what is the environment inside the sign—the temperature, the humidity, the pixel, the module failure, the drivers. Something has failed, something is not working—what is it? All of these diagnostic activities are real things. They are not just sitting out there—they are being used, and people are aware of how to utilize these capabilities because they are pretty much standardized through the Remote Point Management process.

Raman Patel
A little more detail about the test to operational status of the system components. Here, we list monitoring door status. Is the door open? Are controller software operations performing properly? Are the power sources okay? Are the voltage ratings fine? Pixel status—are any of the pixels bad? All of these things are very, very real in terms of physical, as well as operational activities. From the remote operation in the diagram—you can see the photographs on the left telling you that a person sitting at the desk is actually looking at what the traffic controller status is, what is showing, and other kinds of data. He could actually verify a number of things in terms of physical parameters or the variables the sign has to offer.

Raman Patel
With all of these different discussions we have had about user needs, what if a user need is not found in 1203? That may be a question out there. Somebody wants to know is everything supported by the standard? What if something is not? Then what do you do? The standard allows for extension. You can extend the standard in a proper way. Proprietary extensions are not desired. You do not want vendor-specific solutions because you'll have multiple vendors, you'll have multiple solutions, you'll have multiple issues with it. Also, interoperability rests on standardized user needs. If everybody has a different set of user needs at their locations or for implementation, there will be no interoperability. Interoperability will be compromised if proprietary extensions are made, and it will not be possible. This is one thing the standard is not encouraging. As the deployers in the field, we also have to be aware of this: thatif we do such things, then they will have consequences. Other issues of a technical nature also come up. If you have particular user needs, automatic features are not supported. For example, you have certain triggers if something goes wrong, and you want the sign to automatically switch to another message, that's not supported. These are called triggers. They are not supported. Automatic operations are not supported. We want a very methodical way of the diagnostic situation, problem definition, and then move on to that way. Such efforts are not supported in standards.

Raman Patel
Transportation operations that use DMSs. DMSs are part of the whole issue that we have been discussing in terms of how the concept of operation develops—what it is that we are trying to do to improve the mobility and safety of the highway system, for example. In this context, we have several operations where dynamic message signs play a very important part. Freeway management, for example, where we have information about the condition of traffic roadways, lanes, management, and travel information in real time. Every time there's an incident on the highway, we also know how to use dynamic message signs to display messages, alert motorists, and also advise them to take an alternate route and so on. Then there are work zone management activities where many of the things that we don't want to happen do actually happen. Secondary incidents, for example, are a primary concern in work zone management. By placing the messages ahead and posting speed requirements, you are alerting motorists to the work zone ahead and they can slow down. These things help us. In fact, traffic control in general and managing parking facilities are also helped with all of these different uses of traffic dynamic message signs in the transportation arena.

Raman Patel
Transportation operations that use DMS, particularly for route diversions—these are specific issues that we actually address and deal with. Dynamic message signs are a big part of that. One that comes up right here is alternate route all the time, and the sign on the right shows that. The sign says “I-5 North Closed; After I-90, Use Alternate Routes.” Alternate routes are important aspects of motorist information. Operationally we also need to do that so that roadway conditions can be cleared up. Evacuation is an event-driven issue. There are a lot of times the highways are used for evacuation. Therefore, the signage also plays an important part. Public service and safety in general benefits from the operational uses of dynamic message signs. Road weather information or environmental sensor station systems—ESS, as we call it. This information is also very helpful in terms of managing winter weather conditions. Across the country for many, many years now, we have experienced all kinds of highway operations suffering due to adverse weather conditions. In these situations, we have to keep the public informed, and in fact we do. That was a really big part of traffic transportation operations.

Raman Patel
The outcome, at the end of the day, is what do we really get out of these different operations of dynamic message signs? In general, they improve traffic flow. Dynamic message signs do help us to improve traffic flow and roadway conditions—mitigation of that. There are so many ways we can say that traffic flow is improved through user dynamic message signs. During incidents, we coordinate a specific activity. We have to coordinate not only the location where the accident has occurred with the adjoining area, but we also want to inform motorists not to go towards the incident area. That's another part of the whole coordinated effort. Reduce travel time by providing information in real time. People do make decisions ahead or en route, and that helps in terms of managing travel time and reducing travel time. Work zone safety, we just discussed about the speed issue—particularly slowing down in time so that they don't get into trouble. Signage plays a big part, and it's been acknowledged that it is one of the outcomes they are seeking. We are actually actively looking for signs to help us reduce secondary incidents and verify speed limits are being observed. Speed limit enforcements—as shown here on the sign on the right side—the speed limit of 35 is constantly shown as changing. If it's a current speed, it's going to change. It will show up and it enforces a speed. Speed limit is one of the variables that has been deployed alongside the information we provide in the dynamic message sign content.

Raman Patel
We come to our second activity.

Raman Patel
Question: Which of the following is not a dynamic message sign's operational need? Four choices, again: A, B, C, D. A) Management station remotely configures a DMS sign; B) Management station monitors and controls a DMS sign; C) Management station activates the beacon during an incident; and D) Management requests current traffic flow data from the dynamic message sign controller.

Raman Patel
The correct answer is D: Management station requests current traffic flow data from DMS controller. It is a false statement. Dynamic message sign—or DMS—is a display device. It doesn't collect any data. Traffic flow data is not collected by DMS, so it's not available to the Traffic Management Center. A is a true statement: The Management Station remotely does configure a DMS sign. B is also a true statement because the Management Station monitors and controls the DMS signs. And C is also a true statement: A beacon is activated to flash the mode to make motorists aware of the current situation. Motorists may be passing by, but when they look at the beacon and it's flashing, they say there is something going on, so let's check it—that kind of thing.

Raman Patel
We are now coming to Learning Objective 3, which is to describe the purpose of the Protocol Requirements List—PRL—matrix and benefits.

Raman Patel
PRL is a major part of the dynamic message sign standard, and it's a matrix—t's a table—and has very defined benefits that we will discuss in this learning objective.

Raman Patel
What is a PRL? As it stands, PRL—Protocol Requirements List—is a table; is a matrix. You can look at it any of three different ways. It has a listing of user needs. It is in a table format—it has rows and columns. And it's a matrix because it connects different things together. It provides a standardized relationship between a user need and a requirement. User needs and requirements are always present in PRL. They can never be separated because PRL makes sure that both of them are listed in the PRL. It has a template. It has seven columns. These are fixed columns—nothing a user can change. They are fixed by the standard and have multiple rows. Since we need them to list user needs, they will provide additional rows. Tables are made out of columns and rows. The first aspect of the table format is that it's an organized structure that PRL has provided to us.

Raman Patel
Standardized relations provided by the standards. If there is one user need, there has to be at a minimum one requirement. The standard template actually links the whole thing. One user need may require more than one requirement. One user need can be only fulfilled by Requirement 1 or Requirement 2. Or many user needs can support just one requirement. You have this variation of how user needs are in relationship with the particular requirements shown in the PRL. The PRL provides specific guidance to the agency to select project-level user needs. Without PRL, you wouldn't know how many user needs you should specify. We have to use PRL to prepare a project-level PRL based on what the standard is offering.

Raman Patel
A standard provides guidance through PRL. PRL presents associated requirements. Whatever the number of user needs are out there for a particular project, associated requirements will show up through the PRL. It's a definite structure that is given to us by the standard. The agency completes the rows. We don't have any row in redefining the columns. We have to use the columns the way they are given to us by the standard. But the agency can insert rows based on their local project user needs. If you have “x” amount of user needs, you will have your own user needs listed, and then associated requirements will come from the corresponding standard.

Raman Patel
Let's look at the structure of the PRL. The table shown here has seven columns. We show one row here—2.5.1.2: Determine Signal Display Capabilities. The first column has the user needs section number. The second column actually lists the user need. The third column has a functional requirement section number. The fourth column has a functional requirement. The fifth column has conformance. The sixth one has support requirements. And the last one has additional project requirements. These columns have a specific purpose. For us to understand them, we need to understand that each one will guide us in a particular activity that we're supposed to conduct when we build our PRL. The first one tells us what the columns stand for. We cannot modify them. The second line is an example of a user need. 2.5.1.2 is a specific user need section number and it has a title. The title says “Determine and assign these capabilities.” The section number is 2.5.1.2. It's listed on Page 25, and it defines the user needs.

Raman Patel
Determining if the user need is required. You've got to go 2.5.1.2 in the standard and read the description. If it matches with your need at your project level, you will choose it and put it in the PRL. It may be desired; it may not be desired. That's the decision you have to make after reading these things. Here's an example. For most of our needs, we may not need a blank out sign. A blank out sign is very specific for a particular area and not every application needs that. When you read this 2.5.1.2 user need in the standard, you will make that decision—whether you need this user need or not—and then go forward that way.

Raman Patel
Let's look at the example beginning with the step for completing a project PRL functional requirement. We just looked at column one and column two—User Need Section and User Need. Looking at columns three and four. Column three is “Functional Requirement Number.” It's 3.5.2.3.1. The fourth column actually says “Activate message, retrieve message, activate a message with status.” These three are requirements. They are standardized by the standard. It has the section number. The third and fourth column list the functional section number and title as described in Section 3.5 of the standard. These are specific requirements for that particular user need we listed about. We need to understand this connection. For every user need, there are standardized requirements available in column three and column four.

Raman Patel
Column five is a “Conformance” column and it has “O” or “M.” In this case it shows “O.” “O” means optional, and “M” means mandatory. The Conformance column will guide you and say is this required or not, and you will make that determination by identifying whether it's mandatory or optional. The standard has made several requirements mandatory and several user needs mandatory. Most are optional for users to choose as they are needed. Mandatory stands for “M,” and if they are mandatory, you must select “Yes.” You will see this in the sixth column, which is “Support.” DMS metric configuration is mandatory—“M”—therefore should be selected in the next column.

Raman Patel
Let's look a little more closely at the Conformance column. We are still in column five. In column five under Conformance, User Need 2.3.2.3 says it's mandatory—M—in the Conformance column. The Support column says “Yes”—required. Below that we have two rows—one is non-matrix and the other one is matrix. These are related to each other. They are a group of user needs which are closely stated here so users can make a determination. At least one of them is required. The sign is either non-matrix or matrix. You have to figure out that one upfront. In the PRL, you have to make way or you have to insert that information. This illustration tells us that the designation O.2 (1) refers to “O—Optional.” Two means there are two user needs, and (1) in parentheses means that we must pick at least one of the two: non-matrix or matrix. We must pick at least one—not both—but you have to pick at least one. In the group of two, we select one. And in the sixth column, we will say “Yes”—whatever we select we will say yes.

Raman Patel
The last column shown here also comes up in a little more detail with information that you can insert in that last column. So if a condition or another feature is required, it will also show up in Conformance. In Conformance, for example, in this case, “Manage font” is the user need: 2.5.1.3. In Conformance, it says VMS O. In the “Yes/No/Not applicable” in the sixth column—the Support column—you will have to make a determination. So in a variable message sign, you can manage the font. You will have to select “Yes.”But there are other types of signs. For example, blank out signs or changeable message signs. Fonts are already fixed because the message is fixed. In this case, you will choose “Not Applicable” in your Support column. Certain types of technology will come into play—variable message signs. It's a type of dynamic message sign which you can change fonts with. But with the other technologies—the other types—you cannot. Therefore, this issue will come up in PRL. The Conformance column actually guides us in what we have to really do in the PRL. That's one good advantage in this complexity of picking and choosing.

Raman Patel
The Supporting Project Requirement column enhances the value for everybody. By selecting “Yes” or “No,” you are indicating your requirement. You are concretely saying that we have chosen this user need, and therefore, the requirements that come with it. If the conformance statement for the user need is mandatory, you must circle “Yes.” If it's optional, you can choose according to what we just discussed.

Raman Patel
Let's look at additional information. The last column—“Additional Project Requirements”—it's very important in terms of providing more clarity. If you have something to say about clarity you must use this column—the last one. In this case, for example, we are saying that there is a user need—determine the maximum number of pages. It's a requirement specifically connected to the User Need 2.5.1.2, which is “Determine Sign Display Capabilities.” This requirement shows up in there. Requirements are concrete and now you have to adhere to them. The last one says “Determine Maximum Number of Pages.” How many pages? One page means you have a three-line message; two pages means you have a longer message; or you can even have three pages for much longer message. This determination cannot be made until you ask yourself does the project require this? You have to make that determination and come up with a number—one, two, or three—whatever the number, it will go in the last column. That's how the PRL enhances the value by providing us with the last column, which is called “Additional Project Requirements.” That shows here.Take a look at these things. How many pages or question do you need to ask. One? Two? If it's one or two, it's going to show up on the right side of the software module menu. Here it shows two. Do you really need three? If you accidentally say let me have a three-page message, you are probably injecting damage here, and it's going to cost you more money and the complexity will rise. It would also require memory space and many other things that we really don't need to go into details about in terms of getting our feet wet, as we say. Why ask for something that you really don't need? If you look at this slide in a very concrete way, the last column brings everything together. If you have something more to say, please make use of that column.

Raman Patel
More examples in terms of conformance—M, M, M. Every row shows M more or less, except for the last ones in terms of the 2.5.1.2. You have to make a selection, so we select it. Because it says “M,” we have to select for Support—“Yes.” We need that support in the PRL. We can skip Optional, but for “M” we have to select “Yes.”

Raman Patel
What does the PRL do for us? Let's look at the agency perspective first. What does the project PRL do for an agency? First and foremost, it communicates the scope of the desired DMS communication interface. If PRL cannot communicate properly, then the whole thing is on the wrong footing. PRL actually communicates the scope of the desired communication interface very clearly. Second, it makes it easier to specify what the interface is to do. It's customizing. The standard has so many things in it, which one we need? Our PRL will speak to that, and whatever I'm showing in my PRL is what it has customized, and I need that. It's very easy to specify that way. Third, it spells out the conformance requirement. We just went through M—mandatory—and optional. It spells out clearly M, M, M. This means mandatory, mandatory, mandatory. It clearly tells the vendor or the suppliers what actually is required through the PRL. It acts as a checklist—have we forgotten anything? The checklist means the PRL will say this is my user need. If down the road you have “x” amount of user needs, you can use this as a checklist, and you can validate using this checklist when the system is built. We're going to go back and say does this meet my user needs? Let's just stay with the user needs right now. The checklist will help us validate a user need, regardless of whether the right system is coming to us. Finally, we are concerned about interoperability. We want to achieve interoperability. Going in, we made it very clear that we want to have our system interoperable with others. In that sense, PRL actually helps us to do that. Collectively, the perspective of the agency is to make sure that if they build the right system by recognizing all of the user needs, we are now making sure the right system has been built.

Raman Patel
In terms of vendor perspective, things are similarly enhanced. The vendor and the user and the developer—everybody is connected, and everybody is on the same page. It's very important. You have three or four parties involved in the procurement process, and the delivery process, and the development process. This one will help everybody in the same way. It eliminates ambiguity. There are many ambiguities. What does the user need? Somebody guesses it. Somebody said this user need can be met with this requirement. How do we know? No one knows. PRL is a very concrete tool that eliminates all of these different ambiguities. Once you eliminate ambiguity in a development process, you also correspondingly will reduce risk tied to or connected to not knowing what we are doing. It reduces risk for designers, developers, as well as even venders. Vendors confirm that this is what I'm giving you. This is what you are asking for. I'm now giving you this so the PRL from a vendor acknowledging this is a very good thing. It's peace of mind. And if there are optional features—meaning every vendor has something additional to provide—then of course, standardize. That means standards. But if it's optional—nobody asked for it, but here it is because I already have it, so I'm giving it to you—and that's the case, then a vendor can easily put that in the PRL and say look at this. In addition to your own PRL, I'm giving you this additional thing. When he returns to the PRL or acknowledges the PRL, he can make this observation in there as well. With a completed PRL, your agency, your vendors, your system developers, all parties know what is expected from the DMS implementation. That is peace of mind. This is the overall concept of PRL coming to the table on our side and helping all of us together.

Raman Patel
The next activity is now here.

Raman Patel
Which of the following is not a correct statement? Again, four choices: A, B, C, D. A) PRL is used to ensure conformance to the standard; B) PRL only identifies mandatory user needs requirements; C) PRL is used as a validation checklist; and D) PRL may be used to provide additional notes.

Raman Patel
The correct answer is B: PRL only identifies mandatory user needs requirements. This is a false statement because PRL goes more than just mandatory. It also connects to the operational requirements and user needs. Answer A is a true statement; it's valid. We do use PRL to conform to the standard. Answer C is also true because PRL is used to validate a checklist. In fact, it is a wonderful checklist to use overall, and to figure out whether the system is now conforming to the user needs or not, or to validate that way. And then the final statement here—D—is also a true statement. PRL may be used to provide additional notes. That's the whole discussion we had about the last column. The last column—the number seven column—is actually reserved for you to provide additional information for vendors so they can be more help with details.

Raman Patel
Learning Objective Four. The last one for us is to discuss is how to prepare a project-level PRL with the user needs and their associated requirements.

Raman Patel
That will give us a general idea of what it should be in terms of requirements for a project-level PRL.

Raman Patel
The project procurement process starts with a hardware specification. These are general requirements you have in a project specification—functional requirements, performance requirements, structural requirements, mechanical, electrical, environmental, temperature, humidity, size. All of those are physical in nature—they're come in through hardware. At the second level, we have software specifications. In this level, there are more details about the way the system will behave and deliver the functionality. The third area of interest in this module is a communication interface specification. This is the one that we are focusing on because we need to list the user needs based on the standard. We've got to insert a project-level PRL and RTM—Requirements Traceability Matrix—and testing documentation. In general, these four elements make up the communications interface specifications. That's what we are talking about in this module and the next one. The DMS interface specification will emerge at the beginning of PRL. At the bottom left, the picture shows the TMC trying to communicate to the picture on the right with the Traffic DMS Controller. You can see that in order for this to happen, you need a PRL to guide us through the user needs and requirements. There will be many contractual requirements. They will also come up with the specification in general. They will have a discussion about the system development, a testing procedure, a testing mechanism, deployment integration, operational maintenance, and project management, in general. These are the components where all of these things come together to make up the specification. Our interest is in the communication system interface, which will be part of system development.

Raman Patel
Key points for completing a project PRL. We have to ensure that our understanding is solid in terms of how do we actually complete a project-level PRL? We do know that we will have a standard which has a very big table in the standard itself, which is to standardize user needs and requirements. We are aware of that. But how do we bring that to our particular project? Your DMS specification must have a fully completed project PRL. Completed—not just one line or two lines, or one or two rows—it should meet your project's complete needs. That's what this is. The table shows that in the columns, we are also selecting “Yes” and “No.” The PRL must be consistent with the hardware specifications. In the previous discussion, we mentioned the hardware specifications are part of the general specifications. In the interface, we talk about the PRL. For example, a temperature gauge, or an LED sign, or fiber optics. These are physical in nature. When you try to procure them, they contain hardware specifications. When we come to the interface design and interface specification through the PRL, we have to be consistent. For example, if you specify that signs should work in a minus 40-degree to 140-degree Fahrenheit temperature environment, this should be consistent with that parameter in the PRL. Similarly, LED signs—if you are buying LED signs, then other user needs may not apply. The same with the fiber optic signs. Each technology will have its own unique level of user needs that need to go into the PRL. That's the consistency issue. Second, is that the PRL must be based on 1203—NTCIP 1203 Version 03 with SNMP interface. We definitely have to insert that in our specification. Third is to include need-based specification DMS parameters. We don't want to inject everything and anything that we are familiar with—or maybe somebody told us that it's a good idea to have this one. We should always go back to a project. If you need it, that should be the only user need appearing in a user need. It's not a wish list. So please—user need PRLs are not to be looked at as a wish list item.

Raman Patel
Conformance versus compliance. It's important to understand what both of these terminologies mean. Conformance means it meets a specific standard. In our case, it's 1203. To claim conformance with NCTIP 1203, a vendor must select, at a minimum, all mandatory requirements. They should be selected for conformance. The vendor must provide additional features based on the PRL. There's nothing wrong with providing additional features, but this should be within the context of the standard, and it must conform to the requirements of the standard. Compliance means it relates to the agency's specification. Whatever the specification is implying or asking, you have to comply with that. That's a notion that's definitely changed. To comply, you have to follow the guidance provided by the specification. To conform, you have to follow what the standard actually dictates and says.

Raman Patel
Filling in the PRL with user needs and requirements. This is a step in the right direction for us to make sure that we are getting everything that we are actually looking for and need. That will be our essence in the column called Support, which is—in the sequence of columns if you look at the numbering—one, two, three, four, five, six. But it was the end of the conformance, so it captures everything that we need to capture in terms of whether the project will come out based on the user needs and their requirements. Use the support project requirements to indicate your needs—mandatory and optional. If “Yes” is selected, associated requirements will be implemented and further the process.

Raman Patel
After completing the PRL with the user needs and requirements, you must select “Yes.” This is the first step to achieving interoperability. We keep repeating this because to achieve interoperability, we have to select user needs and associated requirements. If there are two agencies or two implementations looking for interoperability, this applies to all these conditions. We must select the same user needs and same associated requirements for achieving interoperability. As displayed in M, some mandatory “Yes,” and mandatory “Yes.” That's the only way to ensure that we will end up with the desired interoperability.

Raman Patel
A little more information about mandatory and optional areas. The specification selects yes, in this case, for example, if the door status is monitored. Every agency may have a different level of requirements and needs to continue that operation. Some of these hidden user needs may not show up. If that's what your focus is, you should be actively looking for whatever the project requires and then prepare the PRL accordingly.

Raman Patel
In this example of controlling a DMS, the user need is Section 2.5.2.1. The title is Control a DMS From More Than One Location. Dynamic message signs commonly control both from the central location—which is where the Computer Management Station is—or locally in the field with a laptop, or some other available depot or maintenance facilities. These issues are highlighted in the PRL, as shown in this example, by selecting “Mandatory” and “Yes.” In summary, PRL has all your user needs and associated requirements in one place, together with a solid relationship. I emphasize that this is a solid relationship. User needs and requirements never get separated thanks to the PRL. The PRL has linked them very concretely through this solid relationship.

Raman Patel
Our last activity.

Raman Patel
Which of the following is a false statement related to dynamic message sign specification? A) DMS specification includes the PRL; B) Conformance requires only meeting mandatory user needs; C) Compliance requires only mandatory user needs; or D) Vendor must use the project PRL.

Raman Patel
The correct answer is C because it's a false statement. Compliance requires only meeting mandatory user needs is a false statement. The vendor must meet mandatory, as well as selected optional user needs for compliance with the specification. A is a true statement because the PRL must be in every project specification. Similarly, choice B is also a true statement. Conformance requires only mandatory user needs to conform to the standard. D is also true because a vendor must use the project PRL as provided by the agency, and return it to the agency with multiplication or notes on it or whatever the vendor needs to say.

Raman Patel
To summarize this module, we have reviewed the structure of the dynamic message sign. We realize where the information is and what the sections are. It's a two-part standard. We went through the process of where the user needs and requirements are—test procedures in Annex C, and so on. Familiarity with the structure of the standard is very important—identifying specific DMS operational user needs; how many ways our agency conducts operational dynamic message signs; conveying information, regulatory information, advisory information, special event information. We also discussed the purpose of the Protocol Requirement List—PRL—what is the agency's perspective, what do we get out of it, what are the benefits? And finally, we also discussed how to prepare a project-level PRL in detail so we don't miss anything and we get what we really need in terms of using PRL as a checklist.

Raman Patel
We have now completed the module A311a in the DMS Curriculum. We have three modules. Module A is about user needs based on the 1203 standard. Module A311b, which is the next one, specifies the requirements for the user needs selected in the previous module based on NTCIP 1203. Finally, we have a third module that actually deals with testing T311. It will actually test every requirement we identified, and will test it so that we end up getting the system as desired by the agency.

Raman Patel
The next module will be 311b, which will describe requirements in detail. In today's module, we discussed user needs. Similarly, we'll discuss requirements in the next one. We will review the structure and the standard briefly. We will explain the Requirements Traceability Matrix—RTM—and its benefits. We will learn how to prepare a project-level RTM based on the supplied standardized requirement and the design content. Then we will go through the checklist to make sure that the specification is complete so that we meet the requirements.

Raman Patel
I want to thank you for taking this course, and we would like to request you to complete the feedback. Please use the feedback form and complete it and provide us with your comments about the value of the training. Again, thank you for taking this course and making use of your time and for using this module. Thank you.