Module 10 - A311a

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

HTML of the Course Transcript

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

 

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

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

Nicola Tavares
Today's module is A311a: Understanding User Needs for DMS Systems Based on NTCIP 1203 Standard. The target audience for this module is engineering staff, TMC operations staff, system developers, private and public sector users, and other stakeholders.

Your instructor is Patrick Chan, senior technical staff at Consensus Systems Technologies. Patrick Chan has been on the NTCIP DMS working group since 2000. He has been involved with the development of several ITS Standards the last several years, including NTCIP 1203 version 3 which is the object definition for DMS and added test procedures to the standards. Patrick has 20 years of ITS experience. And the next voice you will here will be of your instructor.

Patrick Chan
Thank you. Hello, everybody. Just a little bit more background on myself. I've been working with ITS for about 20 years now, first as a consultant dealing with traffic signal systems, then as an ITS project manager for a public agency in the northeast United States.

Before my current position at Consensus Systems Technologies where I'm a systems engineering working with regional ITS architectures and ITS standards, I first got involved, as was mentioned, with the dynamic message sign working group back in 2000 while I was still working with a public agency. So my interest at the time was as a public agency looking to deploy dynamic message signs.

Since I left the public agency, I still stayed involved with the working group, eventually being one of the consultants that developed the latest version of NTCIP 1203, which is the standard work I'll be focusing on today. And as was mentioned, version three now just added test procedures to the standard and we'll talk a little bit more about that in the coming modules.

A little bit about the prerequisites. This is some of the modules in the year one series that we assumed have been taken, I think, completed by the participants prior to this module. If the participant hasn't already taken these modules, it is highly recommended that the participant take these modules since this course builds on some of the concepts that were originally taught in these early modules. Just to review these modules, the first one is I101, which is an introductory module providing and presenting an overview of the ITS Standards in general. The next module is A101, which provides some key information about procurement strategies for procuring light stand systems that use these ITS Standards. A102 provides an introduction on how to select user needs for standards. So based on the agencies or the procurer's own specific user needs that module tells you how to use the standards, they determine how the standards will help them with their procurement. And A201, the last module, provides guidance on selecting the appropriate ITS Standards for procuring standards-based systems.

This is just a graphical overview of the curriculum path that's expected leading up to this particular module which is A311a, Understanding User Needs for Dynamic Message Signs Based on the NTCIP 1203 Standard. The system engineering process has been discussed in earlier modules, but we'll discuss in greater detail in this specific webinar and specific to dynamic message signs. So we'll talk about how the system engineering process is used for procuring dynamic message signs. For now, just realize that the system engineering process is an interdisciplinary approach, meaning we get different parties representing different stakeholders involved in developing and using the DMS standard. And by using the system engineering process, we increase the probability, the chance of having a successful implementation, because we focus on user needs and the required functions that you were liking in dynamic message signs early in the development process, not yet. And the process also helps you document these requirements and then the standard, the process, helps you, guides you to design the implementation and eventually the testing of the system.

This slide shows the three modules relevant to participants. It's interested specifically in dynamic message signs. The module should really be viewed as a group and taken into sequence. These modules will help participants understand the dynamic message sign standard, how to specify, and just as importantly, how to perform testing to ensure that the system that you purchase is conformant with the NTCIP 1203 standard. So the group, again, participates and consists of A311a, which is this specific module. The module after this is A311b, which focuses on specifying requirements for your dynamic message signs based on the standard. And the third module focuses on testing, Developing a Test Plan Using the Standard.

The learning objectives for this module are as follows. First, we're going to discuss the structure of the standard. So we're going to understand the differences and advantages of the ITS Standards. There are different versions of the NTCIP 1203 so we'll go over the history and the differences between the different versions.

Second learning objective is to identify specific dynamic message sign operational needs. So what we're going to focus on is what user needs does a procurer have and that the dynamic message signs supports? So what is it that you need of your system? How does this standard help you realize those needs when you implement it?

The third learning objective is a table in the standard called the protocol requirements list. And that table will help the procurer to specify, determine what user needs are supported by the dynamic message sign standard and determine which ones are applicable to your implementation. And then from there, using this same table will help you figure out what are your requirements for your sign? What is it that you need? What are your requirements?

And then finally, the last objective is we're going to explain how we can use this protocol requirements list (PRL) table and use it in your dynamic—put it in your specification. How does it help just specification be better, be clear, and unambiguous?

So the first thing we're going to do is just review the dynamic message sign standard, a high level review. The standard we're interested in right now is called NTCIP 1203 and it's part of the NTCIP family of standards. This family of standards provides rules for communicating. We call them protocols. So we're talking about how do we communicate between different traffic systems, whether it's a dynamic message sign or signal control or a ramp meter. And then we also provide the vocabulary which we call objects necessary to control these traffic systems or share informant between these traffic systems. This module focuses on NTCIP 1203 dynamic message sign which is the information content.

So we're talking about what is the vocabulary that we're going to use to communicate with our dynamic message signs? A good analogy for the NTCIP family is the English language. If you think about it, we have a grammar. We have a language called English. And then we have a grammar, which are the rules for communicating in English. So that's the protocol. But we also have a vocabulary, a dictionary of words that mean something. So that's what NTCIP 1203 does; it provides that vocabulary. It provides the words that we use for communicating and controlling dynamic message signs. So that's the overview of NTCIP family of standards. Specifically, what is NTCIP 1203? Well, it is, as I mentioned, the vocabulary for communicating with a dynamic message sign. But when we talk about communicating, we talk about management station to a controller. So it is what we use, the vocabulary for it that gets exchanged between the management station which could be a traffic management center, or more specifically your software, your TMC software that you use to monitor or to control a dynamic message sign.

And at the end of the day, we're talking about the sign controller specifically as the processor out in the field that's going to—we're going to communicate with and that's going to control the dynamic message sign. So the focus really is between the management station and the sign controller. And there are different types of signs out there, dynamic message signs out there.

Some of the signs are blank out signs where we have a single message that's either on or off, so it might be, for example, a “do not enter” sign. You may turn it on. You may turn it off. That's a blank out sign. We may have changeable message signs where we have perhaps a drum sign, for example, as an example where we have a couple, two or three, fixed messages that we alternate between those two or three messages. Or we may have a variable message sign where we can create our own messages and put them up on the sign or we can edit the signs. So that's an example of variable message sign.

So when we talk about a dynamic message sign, we're talking about all of these three types of signs, a blank out sign, a changeable message sign, and a variable message sign. A little history about the standard. The first version of NTCIP 1203 was published in 1999. And based on that we deployed several dynamic message signs and we discovered that there were a couple of ambiguities, a couple of things that we missed that we needed to address. There were some areas where it was published and we were like we're not quite sure what that mean, so Amendment One was issued and approved in 2001 that clarifies some of the objects and how to use the standard.

And then in 2010, we came out with version 2 of the NTCIP 1203 standard. The new standard, version two, added a bunch of new functionalities based on new functions that new user needs that we discovered by deploying these signs. And for example, we discovered some people were in—some agencies were interested in providing graphics or needed color. So we added those new functionality into version two. But more importantly, we added a systems engineering approach to it. So now it was easier to use the standard. Version one, there was despite amendment one, there was still some discrepancies. There were some areas where we weren't sure well what do we really mean by that? How am I really supposed to use it? So we'll talk a little bit more about that in the next couple of slides.

But to complete the history, there is now a NTCIP 1203 version 3 that came out as a recommended standard in 2011. As when we're doing this module, it's currently going through balloting and we're hoping that it comes out to be fully approved by the end of 2011, but essentially similar to version two but just adds test procedures. So now we have some procedures on how to actually test for conformance to the standard.

So right now we've reached our first poll. So the purpose of the polls, of this particular poll, is just to get an idea of the audience. We want to know what type of experience the participants had in terms of using NTCIP 1203. So using the chat pod, which should appear right now, please indicate if your agency has previously used the DMS standard and if so, which standard? Or if you're not currently using a NTCIP standard, or even option four, if you're just not sure. So I'll just wait a couple of more seconds for everyone to answer. Okay, just maybe about five more seconds. Okay. About to close the poll and share it with everyone. So about one-third is not sure. One-third is not using any dynamic message sign standards right now. And of the ones that have deployed NTCIP, most agencies or most respondents have been using version one of the standard, which is fine. I think, again, version two came out in the late maybe about 2008, 2010. So it is expected in most implementations right now that are out there do use version one of the standard.

So now we're going to go ahead and review the differences between version one and version two of the standard. What I'm showing in the screen right now is just the table of contents. And you'll notice that in version one there's an introduction. And then the standard directly goes and defines the words, the objects. So it talks about what objects are we support—what words are we supporting right now in the standard? So notice version one only has what we call design aspects. The objects we talk about, the tags which defines how the message looks. And we don't really talk about how the standard doesn't really talk about how to use the standard. So we address that in version two when we added the system engineering process. It includes a concept of operations that's section two and that talks about user needs.

What are the user needs that we address with a dynamic message sign? And based on those user needs, we come up with requirements and that's section three. So what is it that you need the system to do? So those are requirements. And then we start talking about the design, which includes the dialogs which is a sequence of events that has to occur to do something. The management information base, which is section five which is the same thing as the object definitions. So that's where the vocabulary is. And section six talks about the MULTI tabs which are tags that impact how the standard looks like. So the SEP content is actually much more useful and helps the agencies determine what is it that they want and how to use the standard. So this module is really going to focus primarily on section two but a little on section three which is the requirements.

So NTCIP 1203 version 2, as I mentioned, we added a concept of operations. So it defines the user needs supported by the standards. What is it that the standard does for you? What user needs does it support? So, for example, monitor the status and the message. I want to know what message is currently up there so that's a user need. So the standard has a way of supporting that so you know what messages are currently shown on your dynamic message sign. Defines a functional requirement supported by the standard. What is it that the standard can do? Well, one thing we can do is monitor the current status. And it's traced to a user need. Well, we needed to monitor the status of the message. So that's something the standard can do. But just importantly based on those requirements and those user needs, the standard also defines the design for each requirement. How do I fulfill the requirement? How do I monitor the current status? And so the standard says this is how you do it. This is how I monitor the current status. This is the information that goes back and forth. This is the vocabulary. This is the sequence of events that the sign has to go through or your management station has to go through to go to monitor, to see what your current message is.

By doing that, we support interoperability, which is one of the key goals of the ITS Standards. By supporting interoperability, we reduce risk. And by extension, we also reduce your costs for procuring these systems. An excellent example of interoperability is the Wi-Fi system. A Wi-Fi is actually a standard. And by conforming to the Wi-Fi standard, it doesn't matter where your laptop came from - meaning who manufactured it, whether it came from Dell or Hewlett-Packard. And it doesn't matter where you use the Wi-Fi - whether it is at the Barnes & Nobles or the airport. If the equipment on both sides support the standard and are interoperable, that means your Wi-Fi will work. It doesn't matter if I'm Barnes & Nobles and you set the laptop I know it's going to work because it meets the Wi-Fi standard. So that's the key and that's the goal of our ITS Standards program so that no matter whose equipment you use or whose software you use, we wanted to be interoperable, meaning if I want to purchase a piece of equipment from a different vendor, I know it's going to work on the software that I currently already have. So that's the goal of interoperability. And that's the goal of using the system engineering process.

So by using the system engineering process, which we used in version 2, the result is it's easier to use. The agencies, the specifiers it needs to be determined what user needs they have, what requirements the standard supports. So we'll tell you this is what our standard does, this is what NTCIP 1203 version 2 does. Is it something you need? And if it is, we'll help you specify it. So it's easier to specify. And based on the requirements that you've selected and because it's a single design, it makes it easier to test. So the standard provides, and tells, us this is what the information is going to go through. This is the sequence of events. So now, because it's clearly defined, it's easier to test so it's easier for an agency to test. Yes. Is what I purchased conformant with the standard? So because of the advantages of version two using the system engineering process, the remainder of this module will really focus on using version two of the standard. Version one is still perfectly fine but version two just makes it clearer how the standard is supposed to be used. And we'll talk a little bit more further down the road about how version two still supports version one implementation if you already have version one implementation. So, just again, this is reinforcing what was talked about earlier. Version two supports off-the-shelf interoperability. We wanted to make sure that there's consistency between interoperability between your software, your charting management software and equipment that you purchase.

So here's the second poll. This is just to reinforce some of the work, some of the things that we've discussed, the question here just do a quick test, which of the following is not an advantage of using the system engineering process for ITS Standards? So which one is not an advantage of using the ITS Standards? So using your poll, please answer whether it's one it supports interoperability; two provides a variety of potential designs to fulfill requirement; three allows clear development of test procedures based on the requirements selected; and four determines what user needs are supported. So which is not an advantage of the system engineering process? So okay two more seconds. Two, one. I'm going to close the poll now. And about half of you said provide a variety of potential designs to fulfill requirement and that's actually the correct answer. That is not an advantage because using the system engineering process we do specify there's only one design to fulfill the requirement. If there's a different possibility to fulfill requirement, well multiple designs that's when you can't fulfill interoperability because one system, one vendor might do something one way and another vendor might do things a different way to fulfill the requirement. And that causes problems. That's what causes problems when people start doing things differently. So that's why we want to use the system engineering process. That's why we wanted to use the standard. That's why we wanted to have only one design to fulfill the requirement so that everyone does things, at least, supports things the same way and that's how we reach interoperability.

So now we just start talking a little bit about user needs in general. And then we're going to start going over the user needs that are supported by the dynamic message sign standard. First definition of a user need - the user need is a major capability desired from a system. So what capability? What is it that you want your system to be able to do? There's some little minor notes. Only people have needs. So when we talk about user needs we actually mean someone. It's not the system. It's either a traveler. I'm a traveler. I need information about what's happening coming up. TMC operator, I need to be able to control the sign and see what's currently on the sign. And maintenance personnel, I need to be able to find out what's going on, why is my message sign not functioning properly? So a system doesn't have needs. A TMC does not have needs. It's really the people that have needs. So when we start doing the system engineering process for NTCIP 1203, we looked at the standard from that perspective. So what user needs might a dynamic message sign satisfy?

Here are some potential user needs. Well, a public agency may need to convey information to the traveling public whether it's advisory information or please be aware there's wet roads ahead or there's traffic congestion ahead or regulatory information. A variable speed limit sign, for example, is regulatory. So we can establish what the speed limit is at a certain roadway segment based on the roadway conditions. And we need to enable management information that's currently on the dynamic message sign, possibly from multiple locations and multiple agencies. There are some areas, usually metropolitan areas where you may want to have a dynamic message sign out there that can be controlled by more than one agency, or more than one location, especially, for example, you have a remote location and a center that's open and operating 24/7 and both may need access to the dynamic message sign.

The signs can be stationary or portable. So we're not focused just on the large message signs that are over the highways. We also cover the portable signs that might be work that you might move around as your work zones move around. So those are some of the user needs. So we covered that in the section called the concept of operations. A concept of operations is a document that's written in English, in plain spoken English. It's not a technical document. It's not intended to be a technical document that describes what is it that the system is going to do. So we use it to communicate what the users' needs are and what the expectations are from the proposed system. What do we expect the system to be able to do? How do we expect it to make our jobs easier? So it's providing operational context, meaning when is it that we need to use the system? Why do we need to use the system? So we sent out a poll. So this one, again, continues to test basically to reinforce some of the things that we've discussed. Which of the following two user needs may be satisfied by a dynamic message sign?

So there's actually two correct answers. We need to be able to inform motorists about alternate route. Need to be able to control traffic flow at an intersection. Need to warn travelers about expected delays. And need to monitor a traffic incident on the roadway. Five more seconds. Terrific! I think everyone's pretty much got it right. The correct answers are need to inform a motorist about alternate route and need to warn travelers about expected delays. The first one is more about controlling traffic at traffic signals. Or then the second one is more about monitoring traffic congestion, for example, or traffic speeds. So everyone got that right. Terrific. So now we're going to start talking about some of the user needs that are addressed by the dynamic message sign.

The first thing we address is the operational environment meaning what is it that—how are we going to communicate? So we're talking about how do we do it? How are we going to share the information between, in this case, a management station and a dynamic message sign? So our first need is be able to provide live data exchange, meaning that a management station has to be able to communicate in real time, whatever real time is with a dynamic message sign. That management station or TMC or it could be a laptop out in the sign has to be able to issue requests for status, what's the status, and issue commands to a dynamic message sign. Please go ahead and put up the sign—put up this message for example. So that's one of the first user needs that's addressed by the standard.

However, we also recognize that, especially maybe less frequently now, but most of the early implementations of dynamic message signs use dialup telephone lines usually because of communication costs. It was very costly to have an always-on telephone line to a dynamic message sign. So because of that, we needed to be able to support dial-up telephone. And by doing that, we also needed to be able to create event logs because if something happens while we're not connected to the dynamic message sign, for example, there's a sudden power failure, we need to know that. It could be important, especially for maintenance purposes. So one of the things we put in that the standard addresses is to be able to log events, too. So if there's a power failure, for example, or LED blows or something blows, or we lose communications for some reason, the data can be logged, put into a logging event, and then next time I dial up to that dynamic message sign, I can get that information so I can see in my log, oh, something happened at twelve o'clock this morning. So that was the purpose of the logged events. So that was one of the needs that the standard supports.

Now, we're talking about more about the features, the operational needs, the features that currently are supported by the standard. The first thing we need to do is be able to manage the configuration. And these are some of the sub needs below that determine the dynamic message sign identity. I need to know what type of sign you are. I need to know your identification number so I can talk to you. I need to know who manufactured it. So that's one of the user needs. Another one is I need to know your sign design capabilities, display capabilities. Are you an LED? Can you support color? Can you support multiple fonts? Or can you only support one message? Another need is manage fonts. If you are a variable message sign, I mean I can change the messages. I might be able to change the fonts. So I might use different fonts depending on the time of day or perhaps the type of message that I'm trying to put up. If it's an important message that's critical that we really need to travel and see I might use a bold-faced font, for example. So I need to be able to manage it. I need to be able to change the fonts. Manage graphics with some of the signs, you can support graphics. So I need to be able to change what the graphics look like. Manage brightness - that's the ability to manage how bright the sign looks. This is more prevalent in certain types of technologies, not all technologies, but for example, an LED. Do I want it to be brighter during the day time, especially if the sun is behind it? Or can I or want to adjust the brightness so that it's less intense at night? That way I save on energy but I also increase the lifespan of my LEDs. And address backward compatibility. This is a need to allow agencies to support older features of versions of a dynamic message sign. Recall that this module is really focusing on version two.

There are some functions that were version one that we no longer support. So we need to be able to take a look at that and support it somehow actually. What do we do now when I come across a version one sign and it's a little different? How do I still support that functionality? So that handles that. That slide talked about the manager of the dynamic message sign. This is actually control the dynamic message sign. So these are some of the user needs that are addressed by the standard. The ability to control a dynamic message sign from more than one location. I have a 24/7 traffic management center, but to have a more local traffic management center that may not be 24/7, I may be able to control that dynamic message sign for both locations. Remotely reset the sign controller. That is if the sign is in a very remote location, rural area, I want to be able to reset the controller so I don't have to send a maintenance person out there just to reset the controller or restart it. Control the sign face, that's essentially controlling what message or what's being displayed on the dynamic message sign. Control external devices. There was a need so that if I'm a dynamic message sign, I might be able to control something else that's connected to dynamic message sign. Maybe control another sign, for example, to turn something on, a flashing light LED for example. A flashing bulb that says hey there's a message somewhere, an independent device that is a local near dynamic message side. Control the brightness outputs and be able to control how bright or manually control how bright I can make it a little bit step brighter, for example. And perform preventative maintenance. This more depends on the technology of your dynamic message sign. For example, we used to have flip disks or shutters, the shutter sign. And in areas where it gets cold, you want to be able to exercise those shutters every like once or twice a day before it freezes up. So you wanted to exercise it. Or just go do a pixel test and make sure the LEDs are working right. So that was the purpose of the perform preventative maintenance. And the third major user need that we support for NTCIP is monitoring the status of the dynamic message sign.

This could be really summarized into two. One is perform diagnostics. A dynamic message sign, especially the large ones, consists of many components. You have power supplies. You have temperature. So a power supply fails, for example, you want to know hey a power supply failed, please let me know that. So we can monitor power supplies or temperature readings. You also want to know if a pixel's out, for example, or a board is out. You want to be able to know that. So that's one of the things that the standard supports. These pixels are out. I'm not getting a reading from them so you may have to send someone out to fix the pixels if enough pixels are failed. And for the operators be able to monitor the current message. What message is currently being displayed on my sign?

Again, just to reinforce it, we went through some of these needs, but some of these needs are specific to what type of sign it is. And by what type of sign, I mean whether it's a blank out sign, a changeable message sign, a variable message sign because, for example, fonts and graphics, the ability to manage the fonts and graphics won't be important to you if you have a variable message sign. Will only be important to you if you're a variable message signs because on changeable message signs and blank out signs, they are single message or fixed messages. You won't be able to change the fonts or graphics. So those user needs are not applicable to you. It may also depend on the technology use. For example, exercising the pixels. If you're a flip disk, that's very important to you because you don't want the flip disk to freeze so that's why you would exercise the pixels. But if it's just simply an LED sign that may not be important to you. So while those are the needs that are supported, which ones are applicable to you will depend on what type of sign you are purchasing. I saw a poll question that asked the difference between a changeable message sign and a variable message sign.

A changeable message sign is more than one message but it's usually fixed, meaning you can't change it. You can select between two or three different signs, for example, a rotating drum sign. That's considered a changeable message sign. A variable message sign you can edit, you can change whatever message that you wish to display, so those are editable. An example of a changeable message sign might be the E-ZPass. A lot of toll agencies have really just re-fixed signs whether it's E-ZPass only, whether it's a cash lane only, or whether the lane's closed. And those don't change, so that's an example of a changeable message sign. It has only three fixed messages, as opposed to a variable message sign where you can keep changing whatever message you want. The blank out sign is just a fixed message, “Do not enter.” It's either on or off.

I saw another question about MUTCD where it discusses font sizes for dynamic message signs. I'm actually not sure about that. I know there are studies out there that talk about based on or recommendations that talk about based on the speed and the length of the message how big the message should be, you know, in terms of height and width. But beyond that, I don't know that there is a font size specific for dynamic message signs. So I hope that answers your questions. User needs not supported by the standards. As much as we like to be complete and support everyone's user needs when the standard was developed we recognize that we were not able to do that. We took the most common needs that we were aware of at the time and tried to address it in the standard. But there were a couple that we considered but decided no, they're regional or it's not that prevalent, so we didn't support those user needs. But again, also, recognizing that there are innovations we want to support those innovations. So if someone has a new use for dynamic message sign or a specific user need that the standard doesn't address, we want to be able to at least support it.

So NTCIP 1203, like all of the NTCIP standards, allows for extensions, meaning there's a way, there's a method, a procedure for adding additional functionality to the standard so that the protocol, the data objects can support that additional functionality. We do recommend against it, if possible, because that does run into interoperability issues. So now you may have purchased a sign that supports that additional function but any other signs in the future or any other software in the future will have to be edited or created or modified so you support this new function. Or either that or it's just not going to support your extension. So extensions are discouraged but we do recognize that sometimes there are features that you do need it, that your agency may need so we will support it. There are ways to do it.

So we reached our first activity. Using the chat pod actually, not the poll, can anyone identify a proprietary extension that may be necessary or have been created for a dynamic message sign? So especially for the ones that currently argues the standard, can anyone talk about or type in the chat pod, what extension, what features, can you think of that may not currently be supported by the standard? That whether your agency needs it or not. Again, as much as we try to support all of the user needs, there are a couple out there that the standard doesn't support. So if anyone can think of one, please go ahead and type it in to the chat. So here are some of the user needs that are currently not supported by the standards that have been discussed or that have been brought before the dynamic message sign. These are just two of them. There are a couple more. I'm sure that someone else could think of a couple. Support for triggers, in some of the earlier versions of the earlier drafts, we actually supported something called triggers, meaning there was a way for me to trigger something or to trigger a specific message or the dynamic message sign. For example, if I had a speed gun, for example, that was measuring vehicle speeds and someone was going too fast we wanted a trigger so that the sign would say, hey, slow down you're speeding too fast. Or your speed is so-and-so. Originally, that was in some of the earlier trials of the standard, but it actually started becoming too complicated. We had a design, we actually had several designed but we kept running into problems. And it just started getting so complex that ultimately, in version two, we actually dropped it.

So support for triggers to bring up a specific message is not supported in the NTCIP 1203 version 2 or 3. Another one was support for legibility. This user need is that there was an agency that was interested in if enough pixels or certain types of pixels, parts of the messages would no longer display that they wanted to blank the sign rather than have a sign that didn't make sense or that was no longer—that might accidently display a different message. So they wanted that functionality. That's, again, a functionality we discussed, the DMS working group discussed, but ultimately decided not to because there was just too many different ways of measuring legibility. So we couldn't agree on what's a standard way of doing it. Again, for us to support interoperability, we wanted one design to fulfill requirements. So there were just too many designs and we couldn't agree on one. So we ultimately decided not to. So it's something we don't support. If an agency has a specific way that they want to support legibility, they can go ahead and add it to their implementation using NTCIP, but using it to their implementation.

On the screen right now - this is just an example of what happens if the right modules, if the right LEDs break down, you might have the wrong message. So instead of “This is a test message.” if the right modules break down, you might only see “This is a mess.” and that's not the message you want to display to the general public. Someone did mention parking availability as a function that might not be supported by the standard, parking availability in a parking garage. In a way, it is because we do display the message so you can say, change to message to support this is how many parking spots are available on the parking garage. So you can do that. It's a use of, it's an implementation of a dynamic message sign. So it's not specifically a user need, but the user need really is I want to be able to display this message and that we do support.

So another person mentioned, I'm sorry I'm reading in the chat pod, another person mentioned that they used wind speed to trigger wind restriction messages. Unfortunately, as I mentioned, this would be a trigger that we currently just don't support. So that when the wind speed gets to a certain speed, for example, you trigger a message. And unfortunately, right now, there is no way to support it. It's still under consideration for future versions but it's not in the standard right now to do that. So wind speed, let's say, reaches 40 miles per hour for bridges is pretty common. So the wind speed reaches 40 miles per hour, unfortunately some alarm, some trigger has to go back to the traffic management center, for example. And the traffic management center will have to manually change the message to say wind restrictions, no trucks allowed now. And right now, there is no feature supported by the standard that will automatically do that - oh, my wind sensor detected 40 miles per hour sustained, go ahead and activate this message. Unfortunately, our standard just doesn't support it right now.

Now, we reached protocol requirements list table. This is a table in version two of the standard. The table serves multiple purposes. The first thing it does is it maps the user needs of the standard to the requirements. So, for example, if I have a user need to monitor the sign environment, what's the current humidity? What's the current temperature in the cabinets, for example? We say, okay, if you selected this user need, these are the requirements that are associated with that user need. So it also specifies the standard. So by saying this is my user need, you're essentially saying, okay, for my implementation I need the dynamic message sign system to support this capability. So the PRL, by filling out this PRL table, a completed one will essentially tell other people what is it that I want as a procurer in my dynamic message sign system. It has to be able to support these needs. It has to be able to support these requirements because these are my needs, these are my requirements.

So a completed table tells the vendors, the software vendors, the hardware vendors this is what I need my system to be able to do. So now we're going to go more in detail about how this system works, how to use the table. The first thing we displayed the first line of the PRL table is the headings. So the headings are the user needs section number - what the user need is. So the section number says, okay, well, where can I find this user need? So it identifies the user need. The user need is a text that describes what is it that we're trying to do. What it is about user needs? In this specific case, it's determined a sign display capabilities. That's my user need. And where can I find more information about the user need in section 2512?

So moving on. We've reached another activity. And the exercise asks when will this user need be required for the agency. The user need, being the operator, needs to be able to define and edit the appearance of fonts used to display messages on the sign trace. So when is this a user need? When might you have this need? So please use the chat table. And the hint is - consider what type of sign. So consider, is it a blank out sign? Is it the changeable message sign? Is it the variable message sign? What type of sign? What you see in procuring when this user need might be applicable to you? So the ability to edit fonts, again, we talked about this briefly earlier, when we talk about editing fonts, we talk about how it looks like. So that means we can change the width of the size. We can change the height of the font. We can change whether it's bolded or not. And that's something we need for variable message signs. So for variable message signs, you want to be able to change the fonts. Changeable message signs because the signs are fixed and blank out signs because it's already a single—it's only a single message that's on or off. You really don't need that capability to manage fonts.

The slide now shows the full text of the user need for manage fonts. So I'm not going to read it to you out loud but this is the full text. So if you already have messages that you already predetermined, or sometimes it's also possible that even though you have a variable message sign, you decide this is my agency's standard font. We always use this font. We have no plans to change the font that we use because it's nice, it works for us, it's clear. So, in that particular case, even though you have a variable message sign, you may decide I don't need the capability to change the font. So you may decide, hey, I don't need this user need. So this user need may not be applicable to me. So, again, maybe, even though you have a variable message sign, if you decide you don't need that capability, then go ahead and just say no we don't need this capability.

So this is a different user need that's in there, the ability to just determine the sign display capability. So we want to know how many—is it pixels? How many pixels across is it so that if I create a new message, how many characters can I fit across my sign? So, for example, the pixels, if the sign can only show 100 pixels, you can't put up a message that's 101 pixels long. So that's why you need the sign display capabilities. Again, is this user need for you? Well, yeah, it might be if you're a central system, you want to see exactly how the sign looks like. If I put a message, I want to know what does the message look like? How will it look? So for those central systems with that capability, you know, what you see is what you get. You want your sign to support, determine this particular user need, so you can visualize and see what the message will actually look like. But if it's a simple blank out sign when you know what the font is and it's a fixed message, you may not necessarily want this particular user need.

So the purpose of showing these two example user needs was every implementation is going to be different. Every agency is going to be different. So please do go through the user need and say hey, is it applicable to me? Does this make sense for my agency? Even though I've got a variable message sign and I can change the font, I may decide I don't need that capability, so I'm not going to put it in my specifications. The next thing in the protocol requirements list table, a PRL table does is it identifies a user need or requirement, and we'll cover requirements in the next module, but for now we want to determine if a user need is mandatory or optional. Most of the user needs are optional. There are a couple that are mandatory. No matter what type of dynamic message sign you have, because we determined that to be considered a dynamic message sign, there are certain needs that are fundamental that all signs need to support. For example, the ability to activate and display a message is a basic need. If you can't activate the message, what's the point? That essentially means I can't change the message. I can't turn the message on or off. So that's a fundamental user need. So to conform to the standard, there are certain needs that all dynamic message signs must support. Another example of a fundamental need is determine identification, the sign ID. If I can't talk to it, I don't know who you are. If I don't know how to address you, how can I control you and get the status? So that's another fundamental or mandatory user need in the standard. So there are a couple of user needs that we say that the standard says you have to support this user need to be conformant to the standard. However, there are a couple of, or bunch, that we consider optional, so I mean it's up to you. It's up to you as an agency, as a procurer, as a specification writer to say I want this capability or not.

Sometimes, though, there are choices that have to be made, meaning it has to—your implementation has to obviously support one of a couple of choices. So, for example, so we showed that in the PRL table with a dot-something. So in this case, we have a destination, O.2. The dot-two means there's a group of something. So this is group number two. And for group number two, we have a choice of non-matrix or matrix. What's the difference? A non-matrix signs means the sign is fixed in what we can do. So, for example, it might be a character matrix, which means that essentially you can't change the font if it's a non-matrix font. You can't make the font wider or larger. And matrix, on the other hand, is like a variable message sign. You've got a whole bunch of pixels with no spaces in between them. So that I can do whatever messages, I can put whatever graphics I want on the matrix side. On non-matrix, I don't have that capability. So when you specify a sign, you have to specify, in this case, you have a choice whether it's a non-matrix sign or a matrix sign. So the one in the parenthesis after that says I have to at least select one of them and only one of them. So in the example shown in the slide, it's either non-matrix sign or matrix sign. Sometimes you'll see a one in the parentheses, a one-dot-dot-asterisk, which means I can select one or I can select more than one. So you may be looking for additional capabilities besides just one option. You could select multiple options. And, I think, later, in the slides, we'll show an example where it's dot-dot.

There are also in the PRL table something about predicates. Predicates means that this user need or requirement is applicable only under certain conditions. Recall, again, that we have different types of signs: blank out sign, changeable message sign, variable message sign and that we have different technologies, whether it might be an LED, a shutter sign, a fiber-optic sign. So there are some requirements and some user needs that are applicable only if you have a different type of sign or you have a different type of technology. So in this particular example, when we have a user need managed fonts, and it's optional only if it's a variable message sign. So if it's a blank out sign or a changeable message sign, this user need is not applicable to you. You can't change it. You can't change the message. You can't manage the fonts. That's not a capability of a blank out sign or a changeable message sign, by definition. So in that particular case, there's an NA, it's not applicable to me. However, if you are purchasing a variable message sign, then it may be applicable to you. That's why it's optional. You may decide, hey, I want to be able to change the fonts. I want to be able to change whether it's bold faced or not. I want to change how my characters look. In that case you would circle yes.

On the other hand, you may say I've got a variable message sign but, again, my font is good. I know which font I want. I don't need this capability. In that particular case, you would circle no. Managed fonts is one example. Another example is managed graphics. Again, if you don't want the capability to manage graphics and, again, that assumes you have a variable message sign. But if you don't want the capability to manage graphics, just circle no when you get to that line in the PRL table. So as we go through this, so the agency specifies we should really go through this PRL table and look at the user needs and say circle yes if you want that capability of that user need. No, if you say it's not mandatory for me, so go ahead and circle no. Or circle NA if they say, based on the type of sign I'm purchasing or I'm interested in, it's not applicable to me. So we want the agencies to use this PRL table. And by going through this, you make it clear to yourself, to your agency, and to your vendors, what is it that you expect to purchase? What capabilities are expecting about for your DMS implementation?

So one of the other columns at the end is something called additional projects requirements. That's a space that the standard uses to help the procurer of the agency make clearer what capabilities that they want. So there are additional notes that we hope that we can fill in to make your implementation clearer. So, for example, at the bottom of the last row of the PRL table that we show here, you say DMS one user need. This just shows the DMS matrix configuration. So this is hardware-wise, we wanted to say okay, what size is my dynamic message sign? So underneath additional project requirements, we have some spaces for you to fill in. That way you can still—to help you say, okay, this is the size that I want from my dynamic message sign is how many millimeters high, how many millimeters wide. The same thing for borders. We want now both borders to be at least this wide or this high. The purpose of borders are to make up—to provide some space to make a sign clearer so the message stands out a little bit better. So some of the user needs requirements at the end will have some additional project requirements. It's up to you if you want to fill it out or not. It's just there to help you, but we do recommend that you go ahead and fill it out.

We've reached another poll. This one you'll need your supplemental material to fill this out. This is kind of a test to make sure that you fully understand how to read the PRL table. So on page seven and eight of the supplemental table, materials, handbook, we want to ask you which of the following is not a mandatory user need for this procurement. We are assuming that you are purchasing an LED sign, full matrix sign, which is a variable message sign. So which of the following is not a mandatory need, based on the PRL table and the supplemental handouts? Which is not a user need that's mandatory? Define a message, is that a mandatory need or not? Control the brightness output, is that a mandatory need or not? Managed graphics, is that a mandatory need or not? And determine the DMS identity. And I've shown the user need ID. They sort it by user need IT supporter. And I'll give everyone a little more than 30 seconds to fill this out. So the question is: which of these user needs are not mandatory for an LED full matrix variable message sign? And you'll probably need the supplemental handbook, the student handbook, to fill this out. Just five more seconds. Terrific!

Closing the poll now. And the correct answer, and most of you got it right, is manage graphics. If I look at the options, define a message is actually a capability that's required, mandatory for variable message signs. Controlling the brightness output is a user need that's mandatory for LED signs. So this is an LED sign. So if you purchase an LED sign, it is mandatory that you be able to control the brightness output. Managed graphics is not a mandatory need for an LED full matrix sign. But determine the DMS name is actually a mandatory need for all dynamic message signs. It's one of those fundamental basic needs that we've identified. So the correct answer is actually manage graphics. It's totally optional to your system whether you want it to support graphics or not. So completing the PRL. Below the user needs, we've been focusing mostly on the user needs. But as we showed on one of the slides, below the user needs are actually a new requirement. And the point of—the purposes of the PRL table is to show, based on what user needs, what requirements are associated with that user need. What's the difference? Well, the user needs define why and what. What is it that I want it to do? What do I need the system to do? What capabilities? And based on that we wanted to get a little bit more details. So the requirements now talk about how do we do that? How do we satisfy a desired user need? So the PR table standardizes that. Again, based on a user need, what requirements are associated with that? What requirements are associated with that user need? And by taking these steps, that's our first step in creating interoperability, based on what you want your system to work, what implementation to work, what are the requirements, and by selecting what requirements are applicable, that's how we support interoperability.

So for each user need, you want to indicate the user needs requirements required for your implementation. Once you select the user need, the PRL will tell you what requirements are associated with that need. So for a monitored sign environment, there's a monitor sign—the requirements that are associated with that user need is to be able to monitor sign housing temperature, to monitor sign housing humidity, to monitor the control cabinet temperature, and the control cabinet - the humidity and to monitor the ambient environment, the environment around you. So those are requirements related to being able to monitor the sign environment, so based on that user need. So it's like which requirements do you mean that the monitor to user need was, you know, you want to get an idea what the environment is, and specifically what the requirements tell you specifically what is it that you really want to monitor. Let's just get to get. So similarly, we do the same thing with the functional requirements that's similar to user needs. There's a section number that says this is the identifier and this is the section where I can find out more about this functional requirement. But just as important, the identifier, okay, so I can identify what requirement am I talking about. And then next to that, we did provide a short description of the functional requirement. My user needs activated and display a message. My requirements are how do I activate a message? I need to be able to activate a message from the management station. I need to be able to retrieve the message. And I need to actually have messenger status. The status is something specific to drum signs. Drum signs are the rotating drums. And because of how they work, sometimes you need to wait a couple of extra seconds for those drums to rotate properly to the right position. So if I tell the sign controller for the drum sign to activate the message, it may take a few seconds before the controller—before the drum actually moves. So that's why there's a specific requirement for drum signs.

So what else has the PRL table done? Just some information about the PRL. Requirements associated with the user need are found under that user need. So these are requirements associated with that user need. Each user need will have at least one associated requirement. So if I have a user need, I've got to have at least one requirement. I have to at least select one to satisfy the user need. Each requirement in the standard is associated with at least one user need. What that means is we don't have any requirements in the standard that says doesn't satisfy user need. So it's in there for a reason. It's got to satisfy at least one user need. If there's a requirement that's not associated with the user need, that requirement really doesn't belong there. The result is the standard is complete. We have no unnecessary requirement and all user needs are at least satisfied by at least one requirement.

Just some tips - a little bit more about the PRL table before we continue to the next topic. Do not select all of the user needs. Please do go through the user needs and figure out what is it that you really want, your agency really wants, because it can get expensive. You're asking for additional functionality that you really don't need, that you've decided you don't need. So it gets expensive to purchase that particular sign if you select all of the user needs. And more importantly - to test, because now you should test through all of those different functionalities and those user needs and those different requirements. So you're highly encouraged to only select those user needs that are applicable to you. It makes it easier for you in the long run. Also, because you're only purchasing what you want. That said, we do encourage everyone to complete the PRL because by completing the PRL, you make it clear to the vendors what is it that you want your system to do, what your DMS system needs to support. So we want you to be part—we want you to fill out the PRL and put as part of your spec, your procurement specification.

The slides currently shows examples of what goes into a specification. So there's your hardware specification, the software specification. But the PRL, we always complete your communications interface specifications by just taking the PRL and completing it. You could just really slip it in to your procurement specification. And that would take care of your communication needs from an interface point of view. Note, the completed PRL has to be consistent with a hardware specification, meaning if you're purchasing a fiber-optic technology sign, don't specify an LED sign. That's just inconsistent. Or if you don't include a temperature gauge in your hardware specification, don't select the user need to support temperature. So you want them to be consistent. That way you clearly show the intent. The people interested in bidding on a specification clearly understand what is it that you want your system to do and what is it that you're interested in purchasing.

There's a difference between conformance and compliance. When we talk about conformance, we talk about conforming to a standard. So to claim conformance to the standard, a vendor shall minimally satisfy the mandatory requirements selected. So that means when you select a user need and certain requirements, the standard will say these are my requirements. You must minimally support these requirements. Now, vendors can give you more features beyond what's in your completed PRL if they want. They'll still be fine as long as they still satisfy the standard. By that, I mean, for example, I may say in my PRL, completed PRL, and say I don't need you to manage fonts, it's optional, I don't need it though. But if the vendor decides they want to give you the capability because it's part of the standard software that you can manage fonts, yeah, then that's fine, they're still conforming with the standard. But if they give you that capability to manage fonts even though you didn't ask for it, but if they give you that capability, they still must satisfy the requirements of the standard because down the road the standard is going to say what's my design for fulfilling this requirement? So the vendor still has to follow the standard. Even though you didn't request for that feature. If they give you the feature, you still have to follow the standard. So that's conformance.

Compliance is a little different. It's complying with your specifications. So in your specification, you will say this is what I want my system to do. That's in your specification. So they have to comply with the specification.

So just to make sure that we're clear on the difference between conformance and compliance, here's a little activity. Again, using the chat pod, answer the following questions. There's three questions. An engineer running a specification to purchase a variable message sign - would an implementation providing for variable message signs be conformant or compliant? So, am I conforming to the specification or am I complying to the specification? The second question is - a dynamic message sign supports a feature that the sign will automatically blank when the message is no longer legible. Is that conformant with the standard? And the third question is - would an implementation that does not support the DMS device ID, so the identity of the DMS, be conformant with the NTCIP 1203 version 2 standard? So go ahead and type in your three answers into the chat pod. And I'll give everyone about thirty seconds, half-a-minute. Notice, by the way, I did specifically say for the last question, NTCIP 1203 version 2. It is important, when you do specify standard in your specification, that you indicate what version. So be clear on that so that there's no questions in case a vendor provides you with a version one software, a version one dynamic message sign. If you want a version two, and we do recommend the version two, that we put in a version two.

And at the end of the module, I'll talk a little bit more about what to do if you have a version one sign and whether you should specify a version two sign or not. Answers are coming in. So, I think, from what I can tell, everyone is getting the answers right. The correct answers for the first one it is compliant because we are talking about compliance to a specification. When we talk about conformance, it is conformant to standard but it's compliant to a specification. The second one - the answer is actually no because as we discussed earlier, the standard does not currently support legibility. So if you have a feature, if you have a sign that supports legibility, it's not conforming with the standard per se because it's not defined by the standard. It still might comply with the agency specification, because the agency is going to say, hey, I want you to support legibility. So if the vendor provides that feature, yeah, then they're compliant with the specification. But you're not conformant with the standard because the standard doesn't support it.

And the last one is - if the implementation does not support a DMS device ID, it's not conformant because as we mentioned earlier, it is mandatory to provide the identification of the device to conform with the standard. The last topic, last discussion about the PRL. This is from the vendor's perspective. Up until now, we've mostly been talking about from a procurement or agency perspective. From the vendor's perspective, they may actually provide you with a completed PRL because the vendors can use it now, use the PRL, to show what user needs and what requirements their product supports. So, for example, if you're interested in a vendor's software or hardware, you can say which features of NTCIP 1203 version 2 do you support? And they can give you a completed PRL with everything circled. Yes, I support this user need. Yes, I support this requirement. No, I do not support this requirement. So vendors can use the same PRL table to show interested parties or other vendors or agencies what is that their product supports. So ideally, in an ideal world, you can go to your vendors and say, hey, please tell me what features you currently support in your products and they'll have a completed PRL showing that information.

Backwards compatibility. As I mentioned, what happens if I already have a version one sign, am I required to support version two? Well, the answer is, unfortunately, it depends. One thing that version one did not do was support dialogs. We did not define dialogs. Dialogs, again, mean that it's a sequence of events. For example, to activate a message, the standard defines a sequence of events that a dynamic message sign has to go through to activate a message. Some of those steps, some of those sequences included checking that all of the messages are valid, checking that the fonts haven't changed, checking that the message structure is correct. So there's a series of checks and things that the standard requires the dynamic message sign go through before they go ahead and activate a message. For example, there's a font that's changed since you first—let's say you created this message using a specific font. And then somewhere in between, you changed the font. Wow, suddenly you're not sure whether the message really displays properly because the font has changed. So this is the type of check that the standard forces the dynamic message sign to go through, make sure that the font hasn't changed. Otherwise, if the font has changed, you might show a totally different message or the message may look different. So we require that before you activate the message, go ahead, please go through this consistency check.

Version one didn't do that. We didn't have dialogue. So implementation may not be fully interoperable with each other or with version two. So even though version one—you may have version one signs from different vendors—they may support the same objects. But to activate them, they might do different things. So it may not be fully interoperable. Chances are they are, meaning, yeah, they'll go through the steps, or some type of steps or similar steps. And chances are they'll work fine, but we're just not sure. We can't guarantee you 100 percent that it will be interoperable. So that's the problem with having version one signs. The risk is low, but it is possible. As I said, we talk a little bit about what happens if I already have a version one sign. Should I purchase a version two sign? And the answer is - you probably do, but you don't have to. If your version one signs work perfectly fine right now and they do what you need and they don't exhibit any weird behavior, if you want to purchase another sign, you can. It's probably perfectly fine to do a version one sign. But if you want to do a version two sign, yeah, go ahead. You can do that, too, because when we did version two, when the DMS working group created version two, we made every effort to make sure that it was compatible with version one. There are more rules with version two signs that we put in to make sure that we can have interoperability. But if you already have an existing investment in version one, both hardware and software, and it works for you, there's no reason to junk it. Just continue using it through its normal lifecycle and then when you upgrade, yeah, go ahead, we recommend that you go to version two. But there's no reason that you have to junk it right now.

I did have a question. Is version two the current version? Version two is the current version right now. Version three is a recommended standard. It's out for balloting right now, meaning that the standards development organizations are currently in the process of approving it. But probably—version three is really not different from version two. We found that the working group found a couple of little minor errors and ambiguities in version two that was corrected in version three. But the main difference with version three is we added the test procedures. So if you're interested in the testing, the dynamic message sign we do recommend that you do look at version three for the test procedures. And at the end, when we go through the references, I'll show you where you can find version two and version three of the standard.

So just to summarize what we went through, what we covered, the topics we discussed today. We went through the structure of the dynamic message sign standards, specifically version two. The difference between version two and version one is we do add support, some additional functionality, and in version two, we do include a system engineering process. We added user needs section. We added a functional requirements section. We added a PRL table to help make it easier for you to specify the standard. And we add a design section. But we did in version two address backwards compatibility so it will still most primarily work with version one. There's one or two, I think, three functions, but they're minor functions that we no longer support in version two as opposed to version one.

Identify specific dynamic message sign operational needs. So what are the needs the dynamic message supports, the standard supports? We support the ability to manage the configuration of the dynamic message sign to know how the dynamic message sign is configured. We provide capability to control the dynamic message sign, be able to manage fonts, manage graphics, activate messages, delete messages, and to exercise pixels for maintenance purposes. And to monitor the status of the dynamic message sign, a message that's currently showing. We talked about the PRL table, how we can use the PRL table to link the user needs with the requirements. What are the associated requirements? We talked about how to use the PRL table to indicate what your user needs are. What requirements are, what your requirements are to make your procurements easier. And so you know if your implementation conforms with the standard. We explained how the PRL fits into DMS specifications, how we recommend that the PRL be part of specification, and how the PRL table specifies the communication interface.

There are some resources. If we go to the biggest resource—is probably for—is go to www.ntcip.org. If you go to the document links, scroll down to NCTIP 1203, you actually find the standard there. USDOT has made, I don't know for how much longer, but USDOT has made the standards available free of charge to agencies, actually to whoever is interested in it. The current approved version, published version is NTCIP 1203 version 2. It's 02.039b. So that's all currently at the NTCIP website. Version three is actually on there also, the recommended standard. The way the standards process work, it becomes a recommended standard. But then the standards organization has to vote and approve it. That's when it becomes an approved published standard. So version three is currently in the process of the balloting. If you wanted to learn more about the NTCIP, in general, there is a document called the NTCIP Guide. It's NTCIP 9001. And that explains how the NTCIP family of standards work. And if you just want to know a little bit more about user needs, this is a standard, IEEE 1362, that talks about the concept of operations document since this module is focused specifically on user needs. So we've completed another step for specified dynamic message sign.

The next module after this is actually A311b. It talks about specified requirements. We'll continue working down the PRL table and looking at the requirements. And then from the requirements we'll talk about how to determine what the design is. What is it that the standard says you need—implementation needs to do or support to fulfill a requirement? And also, show the relationships between the requirement design and how to refine requirements so that it supports the user needs that are selected in the PRL. The approved version is NTCIP 1203 version 2. So that's actually been published. And it's available as an Adobe Acrobat download. So you can just go ahead to the NTCIP website and download it from there. So at this point, are there any additional questions for me?

There is. Someone asked about how to access the prerequisite modules. If you go back on your chat, the chat pod, expand the chat pod, Nicola had already mentioned earlier she wrote down the information on how to find the additional other modules. Let's see. I'm looking back right now. The website link is www.pcb.its.dot.gov/standardstraining. And actually, let me copy that and put that on the chat pod. The PRL table is actually inside the standard. So when you download the standard, if you look at section 3.3.something, you'll find the PRL table inside the NTCIP standard.

Just waiting a couple more seconds to have any other questions. From the previous time when we did this module, one of the questions that came up was about support for other characters, actually other languages. That really came up, especially with Canada, because in some parts of Canada, French is the prevailing language. It's just a character set. So when you define your fonts, define your characters, you can go ahead, and as part of your font set change, create different characters for whatever language you are using. For example, I know one vendor, a DMS vendor, actually using a character set, the ASCII character set that support Asian languages right now. So Asian languages do have a character set and they went ahead and instead of using it as graphics to support those languages, they actually used the character set to support the Asian language. And probably something similar to Arabic languages. I see another question - are matrix or single font DMS support cheaper? Probably if you have a single font. Again, that's a user need and it's an optional user need, the ability to manage fonts. Theoretically, if you have one font, you don't need the additional capability to manage fonts or graphics, for example.

Theoretically it is probably cheaper to—a sign is actually probably cheaper if you only have a single font and use only one font. Again, that's theoretical. But, I think, most DMS vendors right now do support most of NTCIP actually. So they probably already support the ability to edit the fonts. Their software might be a little bit more complicated because they have to have additional features so there's more room for errors or for problems in the software. But realistically, I don't think it's probably that much more to add the capabilities to support editing of fonts. It's a little more complex but, again, I think it's part of everyone's standard product right now. All of the DMS vendors probably supports editing of fonts. So you might need a little bit more memory. It's a little bit more complex. But they probably all do it right now. So it probably doesn't cost much more than other signs.

Someone asked about NTCIP 1201. How is this different from 1203? NTCIP 1201 actually is a different dictionary, but it's actually referenced by NTCIP 1203. NTCIP 1201 is global objects. There are a couple of features that NTCIP considered standard. That's a terrible word, but that are applicable to multiple traffic devices. For example, the ability to keep time, global time, the ability to manage the event log, the ability to keep a database, manage a database. Those are features that are common to multiple devices, dynamic message signs being one of them. But think about it: traffic signal controller has similar needs. A ramp meter has similar needs. Detector systems have similar needs. So rather than create an object that's different, unique for every type of traffic device, there is a standard called the global objects that are applicable to everyone. So if you want to look at how dynamic message signs or traffic controllers keep time, you go to NTCIP 1201. That's where we define—this is how we keep time for our traffic devices. This is how we manage databases for all data traffic devices. This is how we manage the event log for all of the different devices. So 1203 contains the vocabulary, the data that's specific to dynamic message sign. But we also use NTCIP 1201. So when you fill out the user need, the PRL table actually, and look at the requirements, some of the requirements do point to NTCIP 1201.

Yes, I guess if there aren't any more questions, again, we do recommend if you have a NTCIP 1201 implementation those are perfectly fine. The 1203 mimics 1201, but we just made it a lot more stringent. We put in more checks to make sure everything works right and we supported additional features. If your version one sign system works perfectly fine and you don't have any new features that version two supports, then let's stick with your version one sign. If you purchase any new ones, we do recommend a version two. But otherwise, there's no need to junk your version one sign. I guess if there's not any more questions, thank you everyone and this.

Wait. One question suddenly popped in. How soon will version three be voted upon? Right now, it's a recommended standard. So that means we do—it has been to the working group, the NTCIP body of standards have agreed, yeah, this standard is pretty good and it's usable. It is unlikely that we'll change it. Anything in version three - we might find a couple of little errors in there that we'll correct. But otherwise, for all intents and purposes, version three is probably pretty much stable. The voting process usually takes about—officially it's two months, but realistically, it takes about three months. So hopefully, by the end of 2011, it will become an approved standard. And then an announcement will go out saying that the final PDF version of the standard will be published. Okay. I think that's it for the module. Thank you, again.

How do I get on the list for the announcement? Someone just asked how do you/we get on the list for the announcements? If you're interested in a particular standard, not necessarily just the dynamic message sign standard, but some of the other standards, there is something called a reflector, which is an e-mail reflector. That's where announcements and information about the standards get sent out. If you go to ntcip.org website, I think if you go somewhere on there, you can send an e-mail to the standards coordinator asking that you be put on a list, on the e-mail reflector list. For dynamic message sign, go to, again, once you're on the website, go to the document library. Look for NTCIP 1203 and in there, I believe, should be an e-mail to the coordinator where you can e-mail the standards coordinator asking to be added to the e-mail reflector. So okay. Thank you, again, everyone. And Nicola, I think, this concludes our module for today. Thank you.