Module 14 - A311b
A311b: Specifying Requirements 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.)
ITS Standards can make your life easier. Your procurements will go more smoothly and you’ll encourage competition, but only if you know how to write them into your specifications and test them. This module is one in a series that covers practical applications for acquiring and testing standards-based ITS systems.
I am 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 helpful.
Module is A311b - Specifying requirements for DMS Systems based on NTCIP 1203 Standard. The target audience includes transportation operation managers, transportation operation personnel, systems integrators, device manufacturers, specification writers and DMS procurement officers.
Your instructor is Patrick Chan; he is Senior Technical Staff at Consensus Systems Technologies. He has been on the NTCIP DMS Working Group since 2000. He has been involved with the development of several ITS standards in the last several years including NTCIP 1203 version 3 which is the object definitions for DMS and added test procedures to the standard. Patrick has 20 years of ITS experience.
Good afternoon everyone as Nicola said my name is Patrick Chan; I’ve been involved with the Dynamic Message Sign Working Group since the year 2000. I currently work for a company called Consensus Systems Technologies where I specialize in region ITS architectures and development of ITS standards. Prior to joining Consensus Systems Technologies I worked for a public agency where I was an ITS Project Manager and one of my first jobs was to project manage procurement of Dynamic Message Signs, that’s how I got involved with Dynamic Message Sign Working Group.
So I first joined as a procurer, a person, an agency representative interested in purchasing the Dynamic Message Signs and using the standard and since then I joined ConSysTec and I remained involved and now I’ve been helping develop the ITS standard. So that’s a little about me.
This module there are actually several recommended prerequisite modules that you take before this module. It is recommended because these modules go over some of the basic information about the ITS standards, about something called Systems Engineering Process. What we will do in this module is build on some of those concepts that were discussed and taught in the earlier modules but apply specifically for Dynamic Message Signs.
These are the first modules, several modules that are recommended. I101 is an introductory module that provides an overview of the ITS standards. A101 module provides key information on procurement strategies for systems that plan to use or will use the ITS standards. Module A102 provides instruction on how to select user needs for standards and A201 provides guidance on the selecting the appropriate standards for your system and there is also A311a which focused on user needs for Dynamic Message Signs based on the NTCIP 1203 which is the standard for Dynamic Message Signs. This is just the same information but graphically. As you can see right now we are at A311b module and prior to this it’s expected that participants have already taken A311a which is the user needs for Dynamic Message Signs.
This particular curriculum path uses the Systems Engineering Process. But now just remember we call that Systems Engineering Process is an interdisciplinary approach and a means, a process to enable realization of successful systems. By using the Systems Engineering Process we focus on the customer needs of the needs of the agency and what the functionality is required by that agency in procuring and implementing systems. We use the Systems Engineering Process to document your user needs, document your requirements and then we will continue, it helps you with the design implementation and finally how to test your systems to make sure that the system that you build or procure satisfies your user needs, fulfill your requirement and that you’re building the right system. Your system might be built correctly, in conformance with your requirements but if you built the wrong system and it doesn’t satisfy your user needs, meet your user needs then what good is your system to you, so that’s why we focus on Systems Engineering Process because by using it we help you cut down your risk. We help you develop a system so that it solves the problems that you may be having.
As I mentioned again, just to refocus, this is actually module A311b, what we’ll be focusing on today is the specifying requirements, how to use the standards to figure out what requirements you may have and this module is the second of three modules relate specifically to Dynamic Message Signs. The first one was A311a where we helped you look at the Dynamic Message Sign standard and figure out, determine what are your user needs, what user needs apply to you.
Now in this module we’ll talk about the requirements based on the user’s needs selected. What are your requirements, what do you need a system to do. The third module that follows after this is called T311 - Applying your Test Plan to the NTCIP standards. So based on the user needs you have, based on the requirements that you have, how do you develop a Test Plan. To test yes the system that I end up with satisfies my user needs that it conforms to NTCIP 1203 standard.
So the learning objectives for today’s module are listed here, first one discuss the structure of the standard. We’ll be focusing on version two of the NTCIP 1203 standards specifically. What requirements are supported by the standard? We’ll discuss how to use these requirements to build and specific your Dynamic Message Sign system.
The second objective is there’s two tables in the standard, one is called Requirements Traceability Matrix, the other is called Protocol Requirements List and we’re going to discuss how do we use these tables, what information do these tables provide you, how do we use these tables to specify your implementation and test your implementation and ultimately to get interoperability which is a key benefit and objective of these standards and we’ll discuss a little bit more about interoperability in this module.
Learning objective three is how to include the requirements from these PRL tables and RTM tables in your specification. So what’s the big picture, well we’re going to discuss well how the standard and how can we extract the requirements from the standard and then include it in your specification. That way your DMS specification is complete and properly and correctly specified, use the standards.
And finally we’re going to talk about some requirements that are not covered by the DMS standard. The Working Group has made efforts to cover most of the basic, if not all the basic functionalities of a Dynamic Message Sign but we realize there are a couple of requirements that we do not support in the standard and that in the future as we continue implementing DMS systems that there may be innovations that may happen, new features, new things that Dynamic Message Signs can do that the standards just can’t see right now. So we’re going to discuss how do we support that, how do you specify requirements that currently aren’t supported by the DMS standard.
So what we’re quickly going to do next two or three slides is do a quick overview of the NTCIP 1203 standard and NTCIP 1203 is a communications interface standard meaning we are covering the communications information that goes between a management station which might be a laptop in the field, it may be your traffic management software in your traffic management center with the communications between that management station and your sign controller in the field. The 1203 specifically talks about the data dictionary meaning what information gets passed back and forth between this management station and sign controller.
One example is if you think about the English language, the English language is actually a bunch of rules, protocols, how do we communicate, these are the rules for communicating between two people. But in this case it’s a management station and a sign controller. But what the 1203 does is we focus on the object definition, what are the words that we use in the English language to communicate that allows us to monitor what’s on my Dynamic Message Sign, what it’s status is, how do I control it, how do I send commands to the Dynamic Message Sign. Please activate this particular message, display this message. So that’s what the standard focused on, this is really the vocabulary; these are the words that go back and forth between a management station and the sign controller.
This module shows the differences between the different versions of NTCIP 1203, we are currently up to version 3 which is currently a recommended standard but version 1 came out approximately in 1998 and it did not include a Systems Engineering Process; it just a bunch of data objects that went so we defined the vocabulary. Once we started implanting version 1 we realized there’s a problem because we didn’t provide the context of how these objects were going to be used. There were some difficulties in using it; people were misusing the data objects. So in about 2001 we started working version 2 and in version 2 we introduced Systems Engineering Process.
By incorporating the Systems Engineering Process we defined a bunch of user needs. What is it that we need a Dynamic Message Sign to do? So that’s what we mean by the user needs and then based on those user needs we did actually define requirements that are supported by the standard. Okay these are what we need the system to do, how do we do it? So those are the requirements, so we added that and based on those requirements we came out with a better design, we came out with designs so if I had this particular requirement this is the design. These are the data objects that you’re supposed to use; these are the how you’re supposed to use those data objects so that’s what we mean by design.
As a result of using the Systems Engineering Process we better support interoperability. So now systems vendors whether it’s the software vendor or the hardware vendor or the systems integrator, we weren’t misusing the objects, we using the data objects in a consistent way to meet a specific need. So that’s what interoperability is. So that it doesn’t matter whose software vendor you use, who your systems integrator is or who’s sign you purchase, if you conform to the standard the system will work together. An actual analogy would be for example Wi-Fi, no matter whose laptop you’re using whether it’s Dell or HP and no matter where you try and connect to the internet whether it’s Starbucks or the Airport, you know if my computer is coffee shop supports the Wi-Fi standard you know we will be able to connect you to the internet. That’s what interoperability is and that’s what we’re trying to accomplish by incorporating Systems Engineering Process in these ITS standards.
Version 3 recently just came out as a recommended standard; version 3 is actually similar to version 2 except that we add the Test Cases and Test Procedures. So now we’ve added a section, almost 300 pages of Test Procedures so now agencies or systems integrators know, or vendors know okay if I want to test for conformance to the standard, how do I do it? So we have added these Test Cases, these Test Procedures in version 3 so that then everyone knows okay how are we going to test that we conform to the standard.
Right now we’ve reached our first poll so we just want to get a better idea just of who’s participating in the audience. So we just want to ask the participants if your agency or who you are, whether you’re a consultant, if you’ve deployed Dynamic Message Signs before and if you used the standard. If you’re using the version 1 standard, please indicate that, if you’re using version 2 standard, please indicate that. If you deploy Dynamic Message Signs and if they aren’t using NTCIP standard that would be number three, if you’re not sure, feel free to select number four. So I’ll give everyone a few seconds to select. Not everyone has selected a choice so I’m going to give it five more seconds.
Okay I guess that’s all the voting. So as you see from the results poll, about a third of you have used or are using version 1, the Dynamic Message Sign standard. About half of you are using version 2 and the rest of you aren’t sure and that’s probably typically. Version 1 came out a while ago and I think most agencies have been using version 1, version 2 is more recent. But perhaps you have used version 2. Thank you everyone for participating.
What this table shows is a Comparison of Table of Contents between version 1 and version 2. As I mentioned version 3 is similar to version 2 except that we added an additional annex, Annex C where have the Test Procedures for this standard. But if you look at version 1, all we’ve talked about is the design, what the objects are, there’s something called multi tag, stack control, the features of how a message will appear on a sign and we have some conformance statements which talk about how do we conform to the standard. So as I mentioned earlier this is very design centric. It doesn’t provide a context on how to use objects, and how to be used. If you had opened the standard you’d see a bunch of objects and then you’ll see the definition and information about the object but it doesn’t really help you, how do I use it, how do I specify which object to use, how do I know which object to use. So as a result when version 1 first came out we did have some difficulties, people were misusing objects, people for something that oh I thought I was supposed to use this object. We had some implementations where people were like I’m not sure which one I’m supposed to use so let me try this one. So we had some interoperability issues. So version 2 we added Systems Engineering Process to try and fix that.
So we now have two additional sections, section two concept of operations where we provide the context, this is what the problems we’re trying to solve are. This is some of the needs that we’re trying to support with this standard so that’s in the concept of operations. We added section three where we get a little bit more detail; we talk about okay based on the user needs, based on the problem we are trying to solve, here are the requirements, this is what the system shall do or this is what the standard in our case will support. So that’s a functional requirement and we’re going to focus primarily on section three in this module. So this just provide- give you a little information about the other sections, section four talks about dialogs that’s the sequence of events, sequence of exchanges that’s going to happen between sharing information. So in dialogs we’ll talk about how the data objects go back and forth.
The management information base is the object definition so that’s where we describe the objects and MULTI remains the same that describes how we use these multi tags to control how the message will appear on a Dynamic Message Sign.
So what are requirements? I’ll let you read it here but the requirements is a statement that talks about what is it that the system will do. In our standard the requirements really are derived from the user needs and ConOps. The user needs define the why or what of a design feature, why is it a problem, what is it that we’re trying to do and based on those user needs, the requirements define how the user need is satisfied. It defines how are we going to do it so if the problem for example or the user need for example is I need to provide travel information to my travelling public, the requirements say okay now that I have that need, how am I going to do it? What is that I’m going to do to provide the travelers with the information that they need?
And so requirements are in the form of “shall” statements meaning all the requirements has the word “shall” in it. Other words such as should or may or must can be confusing or can be ambiguous meaning okay well it sounds like I can do this but I really don’t have to. So in the standards we are very clear about the “shall” statement. The system, the Dynamic Message Sign shall be able to do this. If you want to learn a little bit more about the requirements I’m going to refer you to module A103 to review that and provides you more information of what’s considered a well formed requirement.
I just noticed that on the chat pod someone’s asking about what version we’re using? So with the focus here is really on version 2 for this module is really version 2. Some systems are using version 1 and that’s actually perfectly fine if it works for you, that’s fine. Version 2 we just tried to make the standard a little bit more clear to better support interoperability and to make it easier for agencies to use the standard rather than have a bunch of data objects with now we guide you toward using how do I specify the standard.
So continuing, as I mentioned we’re going to focus on section three of the standards so this is what’s currently in section three. The first starts with tutorial, so it gives a quick overview of what’s in the section 3 and what the requirements are.
The next subsection is called the scope of the interface. We actually don’t have much information in scope of the interface, the intent of that was to discuss more of how to deploy a Dynamic Message Sign so let the agencies know how they want to deploy it. So the standard’s actually pretty silent on that.
Then there is something called Protocol Requirements List if you’ve taken the earlier modules and we’ll review it again later, if you’ve taken A311a you’ll know Protocol Requirements List is a list of the user needs and then it shows the relationship between those user needs and the requirements associated with that user need. Architectural requirements define the required behavior of the system in exchanging data across the interface and so it’s like how does the information go back and forth between the management station and your sign controller? The data exchange and operational environment requirements talked about what data is going past and forth, what’s the system going to do in terms of exchanging data across that interface?
And finally there’s something called supplemental non-communications requirements. Those are really additional requirements for the system; they help you better define the capability of the system. It’s not necessarily the data that goes back and forth so that we can monitor or control the Dynamic Message Sign but they help better define what your system is supposed to do and performance requirements for example, how many fonts do I want it to support. So that’s what the supplemental requirements are and we’re going to go into detail in these over the next couple of slides.
Architectural requirements as I mentioned it’s part of section 3.4 of the standard and its related to communications capabilities of a Dynamic Message Sign. So now we’re going to start going through some of the requirements that are supported by the standard. So the architectural requirements that’s support by the standard include support basic communications, so this is where we say okay these are some of the basic functions, these are the basic things that we need the standard to do. So the standard for system shall exchange information between the sign controller and the management station and we call that the management station maybe a traffic management center or a field laptop for a maintenance person for example at the sign controller. So that’s what I mean by support basic communications.
When implemented you have to be able to communicate, you have to be able to get information from your controller, you have to be able to send information to your controller and set things, manage, change things in your controls so you can activate a message or change a font or download the message or find out okay what’s going on in the controller cell that’s what it means by support, basic information, the ability to communicate with your Dynamic Message Sign.
The second one is support logged data, especially with the earlier Dynamic Message Sign, probably not as true now but in the early days Dynamic Message Signs were mostly dialog, telephone lines, meaning I could dial up maybe every 15 minutes to my Dynamic Message Sign and say okay here I want to change the message or let me check your status. That was mostly because communications were very expensive at the time, so rather than have an expensive communications line that was always hot, we would just dial up maybe every 10 or every 15 minutes to the Dynamic Message Sign.
So the Dynamic Message Sign had to support logged data meaning if something happens in the Dynamic Message Sign between phone calls, I want my Dynamic Message Sign to log that recent information. Oh something failed or the message went bad or it changed message. We wanted the Dynamic Message Sign controller to say just log that piece of information so that the next time I logged in, dialed into the Dynamic Message Sign I can get that piece of information. Oh I know it failed or it ran into a problem at 12.05 for example. So that was one of the requirements that the Dynamic Message Sign has to be able to log data and for us to the management station, the agency to be able to get that information from the Dynamic Message Sign controller.
A third requirement was something called support exception reporting. Actually the standard currently does not support that. The communications that we use, the NTCIP that we currently use for communicating with the Dynamic Message Sign assumes that a management station or a laptop is going to go into the sign controller to get the information whether it’s to get status or send information that I want to change the message. So the management station initiates it. It does not support right now, currently if a controller sees something, hey I saw something wrong, they’ll be able to initiate these communications, let me make a phone call. Unfortunately NTCIP currently does not support that. So that’s what exception reporting is. We do hope it’s the draft stage; we just haven’t been formally excepted yet. But that’s what exception reporting is, it’ll allows the sign controller in this case to initiate the communications and say hey something happened, an exception, I want you to know about it so let me initiate a phone call, let’s you as the management station know something’s wrong or something happened. Again right now it’s totally dependent on the management station calling, initiating the call to the Dynamic Message Sign controller but we hope to have that feature available very soon.
And the last one is manage access that’s the ability to control who has access to the design controller. So that’s a requirement, I need to be able to control who has access, is it the administrator only that can change something or can it be an operator who has access to certain parts, an operator, or is it a supervisor that may have access to more parts of the Dynamic Message Sign. So those are the architectural requirements.
Now I’m just going to briefly go over data exchange requirements so by now we’re talking about okay what requirements does the standard currently support in terms of exchanging data. The first main topic is manage the DMS configuration. I need to be able to change the configuration of the data for that Dynamic Message Sign or at least find out information about the Dynamic Message Sign. So the first one is identify Dynamic Message Sign, what sign type and what technology are you using. That’s actually very key to standard because there are various types of Dynamic Message Signs and there are specific requirements that are dependent on what type of sign it is. So examples of sign types for example might be a black out sign, it’s a sign that either turns off that’s off or shows a single message, do not enter for example, it’s either do not enter or it’s blank, so that’s a blank out sign. We have changeable message signs which are signs that display two or three fixed messages, these are messages that really can’t get changed but you’ve got a choice just to have those on or off, you may have a choice of two or three. For example a toll agency they may have a changeable message sign that says do not enter or the easy pass lane or it’s a cash lane. So those are the only three choices, so that’s considered a changeable message sign.
You may have a variable message sign where you can change the message, you could the font, you could change the graphic so that’s what we mean by a variable message sign. And there’s certain requirements that will be dependent on what type of sign type it is, meaning oh this particular requirement is only applicable if it’s your variable message sign. Whereas your blank out sign it doesn’t apply to you so that’s why it’s very important to understand what kind of sign type you are.
Technology is another one that’s very important, what technology are you using, ones that we support include fiber optics, flip disk, LED’s those are just some examples of technologies. It might be a lamp, so sometimes there’s a combination, you might have a fiber optic and a flip disk at the same time. So when we talk about identifying Dynamic Message Sign we have to know okay what kind of Dynamic Message Sign are you, so we know what you can support or what you don’t. Can I change your message, can I change your font.
So the next one is determining message capabilities, so this is where we find out additional information about the Dynamic Message Sign. What size are you, how many characters across can you support, do you support three rows, beacons, there are some Dynamic Message Signs, some states that use beacons, these are the beacons that are mounted somewhere on the sign where when it flashes or it turns on, it’s an indication to the driver, to the traveler that hey there’s an important message occurring on my sign, please take a look. Access, is there rear access or font access so that when I do maintenance can I enter the back of the sign or do I have to stand in front of the sign display to perform maintenance. Determine maintenance capabilities, what’s the size of the sign face, meaning how many pixels across, how many characters can I fit on my sign face, how tight are the pixels from each other, is it a couple of millimeters apart. The smaller the pixel spacing the more tighter the pixels are. So you might be able to get a higher resolution fonts and the fonts may be more clearer. Determine message capabilities, how many pages can you support, how many messages can you support, can you support color. By pages what is meant is when you see congestion ahead and then you flip to a second message please slow down, each one of those messages is a page. So in this case it would have been two pages. The first one that says congestion ahead, the second one being please slow down. So that’s what we mean by page. Manage fonts, for variable message signs there’s a capability to change the fonts, you can define your own fonts, you can change fonts, you can change how each character looks, the size of the character so that’s what would be by manage font.
Some of the newer also supports graphics, so you can put on an interstate shield for example. You might be able to show a picture of a tow truck for example so that’s what we mean by managed graphics. Another requirement is to be able to configure the brightness of a sign, is the sign bright or not, if it’s at night you may want to make the sign less bright so that you don’t get any glare but during the day time especially when the sun is behind you, you want to make it brighter so that you can see the sign better especially with the sun behind the Dynamic Message Sign and there are different ways to configure it, the brightness, you can do it manually or you can have an algorithm so that based on light sensors the Dynamic Message Sign will automatically adjust the brightness of the sign.
So those are managing the functions of a sign, the next requirements that we support is control the Dynamic Message Sign. First one is manage the control source, meaning where is the sign message coming from, where do the instructions come from. We do support multiple agencies being able to control the signs so agency A maybe will control the sign and agency B might be able to control the sign at the same time. One will take preference. It might be at the sign controller so that maintenance person can be testing the sign, so that’s manage the control source. Reset the sign controller, especially for rural areas, sometimes the sign’s having a problem, there’s some error message. You may want to reset the sign controller remotely. This allows so that again especially for rural areas you don’t have to send any maintenance person to go all the way out there just to reset the sign, so this allows the traffic command center to reset the controller remotely.
Control the sign face, activate a message, what message do I want to show on the sign right now. I can do scheduling so that based on the time of day, day of week I can change what message appears. I can manage the message library so that I have a library of messages and all I have to do is say oh please select message number 30 because that’s a message that we use quite frequently. There’s a way to manage event based message, being based on something, we can activate the message, based on some kind of occurrence.
Control external devices, there’s a way of building so that we control other devices that might be out there, for example maybe activate a light, a light that’s connected to the sign controller or maybe activate some other device that might be out there. Being able to control the sign brightness we’ve discussed briefly, this is actually controlling the brightness and manage the exercise of the pixels. This is the ability to test the pixels. For example we can make sure that all the pixels are working properly or if you’ve got a flip disk or drum they on occasion can freeze during the cold winter, during cold temperatures so you may want to force the flip disk to turn around just so that it doesn’t get frozen, so that’s something that a feature that we support.
Monitor the size of a Dynamic Message Sign is also important; your want to be able to perform diagnostics in case there’s a problem, a lamp’s out or a LED’s out or there’s a temperature problem. For example pixels can overheat if the temperature gets too high or a power supply might fail so we provide functionalities, the standard supports functionalities so that we can control and monitor the Dynamic Message Sign and make sure that it’s in good health. Monitor the current message, so what message is currently on my Dynamic Message Sign. Monitor status of Dynamic Message Sign control functions and that has to do with some of the external features, being able to control external devices, so we want to check okay does everything look okay and finally the last requirement that we have was support multi-version interoperability.
As we saw in the earlier poll there are still many implementations of version 1, Dynamic Message Signs that are out there and we wanted to make sure that there was a way for us to support those signs, even though we’re on version 2 so that way if you have a version 2 software, it can still support version 1 sign. So that was very important to us that we don’t break, so we don’t have to jump-, so agencies don’t have to jump, oh well I’ve got version 1 sign so now it won’t work with version 2 software, that’s not true, so there are ways that our version 2 software can support a version 1 sign.
And finally we reach supplemental requirements, so there are additional requirements that doesn’t really have to relate to us sending information back and forth to the Dynamic Message Sign but are still important to completely control and monitor a sign. So for example we have supplemental requirements for font, hey I want to be able to support five different fonts for example, so that’s a supplemental requirement. Brightness, these are the different types I want to be able to support at least four different types of brightness for example. Control modes, this involves being able to control a Dynamic Message Sign with locally, remotely and in the field, there’s something called also central override for example what happens if a maintenance person takes over the control of the Dynamic Message Sign while he’s doing maintenance and so now he’s controlling it, but then he walks away and forgot to put it back under central control. So there’s a feature in there that says oh the maintenance person has already left, he forgot to put it back to central control so that the traffic management center can control it, let me force it back to central control, so that’s a feature.
There’s also supplemental requirements for message definitions so now we can say okay we want to support centered justification, left justification, top justification. How many pages do we want to support, how many colors do we want to support and what colors. We can support moving text, we can support data fields, meaning hey I want to be able to show what the existing temperature is right now and why do I have to change the message every time the temperature changes, it’s just a field that we put out there, it’s like oh figure out what the temperature is, display it. Date and time is another example of a data field. So these are all features, supplemental requirements that we want a Dynamic Message Sign to report to make it more complete. The purpose of the supplemental requirements is to help the agency better specify, more clearly specify the Dynamic Message Sign system. So that’s the point of these supplemental requirements.
The Dynamic Message Sign Working Group tried hard to make the standard support all your specifications, your procurement, your implementation as much as we can.
We’ve reached the first activity so this is just a quick short exercise to make sure everyone understands a little bit about the requirements. So if you’re using your chat pod you can type into the chat just answer this question, don’t worry you’re not being graded. But which of the following requirements fulfill this particular user need? The user need is this feature enables the operator to determine which component(s) of a subsystem are reporting errors and/or warnings so that the operator can plan a proper response.
So we’re saying okay here’s a user need, I as an operator need to determine what part of the DMS is reporting an error or providing a warning. So which of the following requirements are associated with user need? Monitor power errors, manage the exercise of pixels or manually control brightness. Great I think everyone got this right, the answer is actually monitor power errors and here’s the hint on why too actually. If you look at the previous other two messages, we talking about monitor and when I say to determine, we do actually mean monitor. The other one’s manage the exercise of the pixels and manage your control brightness are actions, these are something that we want to control but in this user need we’re just talking about determine, I just want to know, I want to monitor. So that was actually kind of a hint what the correct answer is. We’re not talking about controlling anything, we just want to say hey I just want to know something, I want to determine something so that’s why monitor power errors was actually the great answer. I think everyone got that right.
As I mentioned in the learning objectives there, there are actually two tables that will help you help agencies, procurers, use the Dynamic Message Sign standard and this is the first table, the Protocol Requirements List, we had discussed this in detail in the first module but we’ll just go over it again and we’ll go a little bit further in the Protocol Requirements List this time. The definition, it’s a table that’s in the Dynamic Message Sign standard that maps the user needs to the requirements.
So based on my user needs that I have, what are the requirements that are related to that specific user need? The PRL table was designed so that it can be part of an agency specification, meaning once you complete or fill out a PRL table you really can just cut it out and paste it and put it into your agency specification. What the PRL table in your specification will do is show interested parties, your contractors what is it that I’m trying to-- what your agency needs or specify for the communications interface and we’ll talk about a little bit more later. And it’s designed to help you specify what you want your interface to do, what you want your Dynamic Message Sign to do functionally.
This is an example of what a PRL table looks like, on top you have the user needs so the user need in this case, high level, there’s monitor to staff of Dynamic Message Sign. Specifically stated in performing diagnostics and more specifically trying to determine the error conditions on a high level. So it says just basically give me a quick short status of the health of my Dynamic Message Sign,so that sign please tell me are you healthy or not and below that we have different requirements related to that specific user need and the requirements we have here are execute lamp testing, activate pixel testing, climate control that might be your air conditioning unit for example and the other one is just provide general DMS error status information, that’s just a quick snapshot of what the health of the Dynamic Message Sign.
So that’s what the PRL table does and under conformance that’s where we indicate okay you’ve selected this user need, determine sign conditions, high level diagnostics, okay which requirements are applicable to you and this is where it depends on what type of sign you have or what type of technology you’re using and that’s where you can find under the conformance column. It will tell you well I had this user need, is this requirement necessary for me. So the standard will tell you, is it mandatory? Meaning yes. To satisfy this user need it is mandatory to also support this requirement. Or is it an optional meaning it’s up to you, if you want to have that requirement then go ahead and add it, if not you don’t have to. But the conformance column will help you indicate that.
So looking at the first row, execute lamp testing, you’ll see lamp or fiber :M, mandatory. That means if you have a Dynamic Message Sign that uses lamps or fiber optics you have to support this requirement. This requirement is required for you, meaning that your implementation has to support executing lamp testing. So if on the other hand you have a pixel, use a pixel technology then it doesn’t apply to you. So the PRL table helps you select, determine which requirements are applicable to your implementation based on what your user needs are. So again for the first one if you have a lamp or fiber optic Dynamic Message Sign you are required to support execute lamp testing is a requirement for you. If you use some other type of technology you don’t have.
Let’s look at the next one, activate pixel testing, if you’re a matrix sign and a matrix sign is you have a whole bunch of different pixels, little, it could be LEDs or it could be be lamp lights it’s usually the way it’s a variable message sign, where you can put graphics or you could change the different fonts. But if you’re a matrix type of sign then it is mandatory to support pixel testing and pixel testing is just a way so that the Dynamic Message Sign can determine oh are my pixels working right or is one of my LED not working, is one of my lamps not working for example. So that’s what pixel testing is.
Execute climate control equipment testing, that’s optional so that means depending on the require list of what type of technology you use, it’s totally optional if you want to support climate control equipment testing. If you’re in a location where it’s very cold for example where you have heaters then yes you may want to say oh it’s optional but it’s important to me because of where I am. So you may want to select yes even though it’s optional I want to support it. If on the other hand if you’re in Florida or Texas where it can get very hot, again you may want to oh I have air conditioning units, I’m worried about my Dynamic Message Sign overheating so you may want to select it. And if you’re in parts of California where the weather’s always moderate and you’re not concerned about it, then you may want to say no, not necessary for me, so you’re allowed to ignore that requirement. If the standard supports it but you can say no it’s not necessary for me.
And the last one provide general DMS error status information is just a quick data object that we send back that says okay this is a quick overview if my Dynamic Message Sign is healthy or is not. If there’s any sort of problem, it will tell your management station it’s having problems and that’s mandatory so that means no matter which type of Dynamic Message Sign you are, you will have to support this particular data object to conform to the standard.
So as you can see through these requirements, this is how we’re trying to help you, how we try to help the agency to procure and to specify and use the standard. It makes it a lot easier than way, you know I need to support these objects or I don’t necessarily have to support these objects based on what my user needs are. And conformance really, the conformance column really discusses what’s mandatory or what’s optional based on what type of sign technology or what type of Dynamic Message Sign you’re using. The support project requirements actually where we circle to indicate yes I want to support this requirement or user need for my project and that’s where you would actually circle it. So in this case on this slide manage traffic, it’s optional if you a variable message sign, if you’re not a variable message sign you would circle N/A meaning it’s not applicable to you. For example your blank out sign, it’s either single message or not. You can’t change the graphics so it’s not applicable to you, so circle N/A. On the other hand if you’re interested in supporting characters, you have no interest in supporting graphics you may say well it’s optional for me and I have no interest in supported graphics so you would circle no. On the other hand if you do want graphics or you believe somewhere in the future you may be interested in supporting graphics go ahead and circle yes, meaning yes I may not use it right now but we do plan to in a year or two. So I want to support graphics so you would circle yes and that’s a user need and looking below you see that we have three requirements related to that to specific user need and they all happen to be mandatory, meaning if I have this user need to manage traffic, these three requirements also have to be supported by your limitation according to the standards.
And finally reached the final column which is additional project requirements, again trying to make the standard as easy to use as possible and as complete as possible for the procuring agencies, sometimes in this column we’ll provide additional fill in columns or information to these agencies, to the procurers who specify is to help them write a better specification, it’s better to make more clear about what is it that I want. So we’ll use this space so they can add additional information that might be useful. So for example for the first requirement, determine maximum number of graphics we put in that the DMS shall support at least blank graphics. If we then put it in it’s possible it may never occur to you, oh I really want to specify how many graphics I want to support. So we’re asking if we fill it in because that will just make it clearer to the vendors what it is exactly that you want to support. If you think you need about 40 graphics, go ahead put in 40. If you think you need 80, put in 80. We don’t suggest putting in infinite because you’re just going to drive up the cost. So try to be realistic about what information you put in, what numbers you put in.
The next is determine maximum graphics size, the DMS can support a maximum graphic size of blank bytes so this is where it says oh we want to have at least one megabytes of graphics for example. Again please try and be realistic and the other one is support maximum block size of how many bytes you need, how much memory do I really want to support just for graphics. So those are just really additional information for you to fill in to help you better define, more clearly define what it is that you want for your DMS.
So just as a quick review, the specifier and procuring agency is cautioned against selecting all requirements. Again it’s just simply going to drive up your costs, it’s not only the costs of the equipment or the software but it actually makes your system more complex, it’s more complex to maintain, it’ll become more complex to test, more complex to operate. So please only select only the requirements that you believe you currently need or expect to need in the future. Also try to be consistent, meaning if you have LEDs type of sign, why would you require lamp testing for example, it’s not necessary and makes no sense if you’re procuring that LED sign. This is just an example how you would just fill in the PRL table. This is the user need is to activate and display a message and that’s mandatory for all Dynamic Message Sign conforming to the standards so you didn’t have a choice so you would select yes, yes, yes. Activate a message with status is only mandatory if you’re a drum sign. If you’re not a drum it doesn’t apply to you so you would select not applicable but if you are a drum sign it’s mandatory so you would select yes in that particular case if you were a drum sign.
Reached the polling. This is just a quick exercise. Using the poll which of the following elements is not a purpose of the PRL table? Sorry, hold on. Just launching the poll. Which of the following is not the purpose of the PRL table? Associate user needs with requirements. Specifying requirements for specific projects. Determine which objects to use or determining what requirements are mandatory to conform to the standard. So, again, select which of the following elements is not a purpose of the PRL table? I’ll give everyone a few more seconds. Another five seconds.
Okay. Closing the poll. So most of you did get it right. The correct answer is determine which objects to use. The PRL table as we’ve demonstrated does associate user needs with requirements meaning based on one’s user needs what requirements are related to that user need. So by filling out, completing the PRL you can provide information to vendors what your requirements are for that specific project. Realizing that sometimes you may want different types of dynamic message signs with the same specification. So, for example, I may want to purchase five blank out signs and eight variable message signs as part of the same procurement. In that particular case, you may actually two different PRLs, one for the blank out signs, one for the variable message sign. But by completing the PRL you’re letting your vendors know this is what I want my system to do. This is what I want to procure.
And the last incorrect answer is determine what requirements are mandatory to confirm to the standard. So the PRL is specifically telling you, oh, based on what user needs you have and this came from the first module will also indicate which user needs are mandatory. There are certain features that we have determined that is basic to all dynamic message signs. So all dynamic message signs must support these features. For example, you have to be able to activate a message. That’s a mandatory need. If I can’t change the message, activate the message, what’s the point of implementing the dynamic message sign. So based on that the PRL table also determines-- tells you what requirements are mandatory to conform to the standard. We do not talk about hot design at all and the data objects actually are a design feature. So that takes care of the first table, the protocol requirements list.
The second table that we have in the standard now is something called requirement traceability matrix. Most agency persons may not be interested in the requirements traceability matrix. The requirements traceability matrix starts getting to the detail. Based on what requirements you have selected the standard now using this requirements traceability matrix says okay I have this requirement, activate a message. This is the design. These are the data objects. These are the sequences. This is how you fulfill that requirement. We define the design in a standardized way.
There’s only one design meaning I have a requirement to activate a message. The standard says this is how you do it. These are the objects you’re going to use. This is the sequence of events that has to occur to activate a message. And you must support the sequence to conform to the standard. And there’s only one design to fulfill a requirement. This is how we reach the interoperability by defining specific, exactly, the objects that you have to support, the sequence of events that has to occur. That’s how we define the standard. This is how we support interoperability. Anyone that conforms to the standard has to recognize this sequence of events. Has to recognize and support these data objects, whether you’re the software vendor or whether you’re the sign. So this is what the requirements traceability matrix does. For each of the requirements that is supported by the standard, you’ll be able to find a requirements traceability matrix and it will tell you yes, this is how the standard says this is how you will do it.
So that’s the purpose of the requirements traceability matrix. It’s more for the tester so now they know what to look for. It’s for the system developer so they know, oh, this is how my sign is going to behave and what it’s going to do. And it’s important for the device center because now they know oh, okay, they have this requirement, this how my system is supposed to work to conform to the requirement and to the standard. Not that the agency may not be interested in it and if you’re interested and you really want to understand how the sign works, yeah, go ahead, and take a look at the requirements traceability matrix. If on the other hand you’re not interested and you say oh I just want to make sure the sign works and as long as it meets my needs and satisfies- and- fulfils my requirements, I’m happy, then you don’t need to go into the requirements traceability matrix. But if your answer is you’re curious, yeah you can definitely go take a look at it.
So with the requirements traceability matrix to conform to the requirement of the standard, the DMS system must support the standardized dialogs and objects specified in the standard with the expected result meaning if you do this, if you go through this exchange of data, go through this sequence that we’ve defined as a standard, this is what we expect to happen. By doing this, by defining this that’s how we achieve interoperability. So, again, it doesn’t matter whose vendor we use, whose software you use, whose dynamic message sign you use it’s going to behave the exact same way. This is an example of the requirements traceability matrix. I’m going to pause right there. I see there’s a question in the chat pod. Does the standard organization determine what is mandatory? Or does the procuring agency determine what is mandatory in the PRL? That’s the difference between what we consider conformance and compliance. Conformance is conform to the standard meaning the organization, the standards organization, in our case, the working group has determined to conform to the standard this is minimally what you have to support meaning these are the mandatory user needs.
These are the mandatory requirements that the dynamic message sign must support to conform to the standard. However, there are a couple other optional things that there are things that are optional meaning it’s up to you. If you needed it, if you need it to do this this is how you will do it. This is how the system will do it. They’re totally optional. It’s up to you. By selecting what is optional for you in your specification you may say, okay, this is optional for the standard but it’s necessary for me. So you would select, okay, that’s mandatory for your specification. That’s what we mean by compliance, meaning, to meet your needs, to meet your requirements that’s compliance.
So the PRL says for us on complete it says this is minimally what you have to meet to conform to the standard. Everything else is optional. But once you fill it out then it’s mandatory for your agency. And it has to be compliant to what you-- that’s compliance, that’s what you need for your system. So the answer is actually-- it is both based on what you’re looking for. For the standards organization we’ve defined this is what’s mandatory to conform to the standard, plus, for you when you complete the PRL you define what’s necessary to be complaint to your specification. So it may not be mandatory to be conformant to my standard because it’s optional but to comply to your specification because you selected it is now to comply to your specification, they have to satisfy that requirement, fulfill that requirement also. So hopefully that answers your question.
Going back to the slide, this is the requirements traceability matrix. The first line or the headings of the requirements what’s in the requirements traceability matrix? So we had the functional requirement ID, a short description of functional requirement. The dialog ID. So the dialog points to a sequence of events. And so this is what’s supposed to happen. The object IDs described and the object names describe what objects, what pieces of information are supposed to go back and forth between the management station and the dynamic message sign. And we’ll go that’s actually on the next page. So that’s what the object ID and object name is what goes back and forth? What pieces of data goes back and forth between the management station and the dynamic message sign? And additional specifications just like in the PRL is based on additional pieces of information that we can provide to make it clearer, to make the standard more clearer, to make your specification more clearer we will add it in this column.
So here’s an example of something that would appear in the requirements traceability matrix. There’s a functional requirement that says activate a message. This is one of those mandatory requirements to conform to the standard, again, it’s a basic need. I have to be able to activate a message whether it’s turn it on, turn it off. That’s a basic requirement.
So all implementations have to support this. But how do I do it? How do I fulfill this requirement? So there’s a dialog called 22.214.171.124, so section 126.96.36.199 that describes if you go there, we’ll go there in the next slide, it will describe the sequences of events that just occur to fulfill this requirement. But below that these are the data objects that has to be supported by the implementation to fulfill this requirement. So if there’s a data object called dmsActivateMessage, you have to support that object. If you want to find more information about that object you will go to section 5.7.3. There’s a short error date option called short error status. If you recall one of the earlier in the PRL we talk something about general description, a quick snapshot of the health of the dynamic message sign, that’s what this is, the short error status. It’s a small data object that describes hey is everything fine or not in my dynamic message sign.
And there’s some additional data objects which I’m not going to read off. But if you want to find more about it you can go to those sections. So these are the objects that has to be supported by the implementation to activate a message. But how do we activate a message? So we will go to section 188.8.131.52 and this is what the dialog says. What this dialog says is to activate a message this is the sequence of events that must occur for the dynamic message sign system to activate the message. The first one is a precondition meaning hey we’re assuming that this has occurred or this condition exists. So the management station, traffic management center, for example, your traffic management center software. So I’m sure that he design message is supported by dynamic message sign. Meaning I’m trying to activate message A, management station please make sure you have a message A in the library somewhere. If I have to download it to a dynamic message sign controller then go ahead and please do that first. But we assume that message A is all ready there.
The next step is the management station shall now set the object dmsActivateMessage to the desired value. Oh, so now we’re going to say send this object, dmsActivateMessage with a value of A because I wanted to activate message A and say we’ll send a message to the sign controller and say hey activate message A. This causes the controller to perform a consistency check on the message.
So now we say okay we set it and now the controller is supposed to go through a consistency check. The consistency check is something that we make the sign controller go through to make sure that nothing’s changed. We want to make sure that the message you’re activating is exactly what you wanted, that looks the way you wanted. So part of consistency check may be oh, let’s make sure that the fonts, for example, hasn’t changed since you loaded the message because if the fonts change suddenly your message is not going to appear the way you expect it to. So that’s part of consistency check, making sure that nothing else has activated, nothing else has occurred that might effect how you sign on your message will appear and that it will appear as you expected when it goes up on the sign.
And there’s some additional notes. There’s different types of message types. There’s such a thing as permanent messages. These are messages that are permanently in a sign controller. There’s changeable messages. There’s a blank message. So that’s what’s in this dmsActivateMessage object. It’s actually a bunch of different pieces of information in this object. So continuing down the sequence, step C says if the response indicates no error the message has been activated and the management station shall get that object which is the basic health of the dynamic message sign to make sure that there are no errors.
So we’ve activated the message. We might only want to make sure, okay, we think we got the message let’s make sure that nothing else is happening. Does everything look okay? If everything’s okay then great you can exit. If on the other hand you get back the message like hey something happened and the message didn’t activate the management station now is supposed to get these two other objects to find out what the error message was. And these continuation oh, if I get this error message, this is what I’m supposed to do.
So in the standard we define these dialogs that say these are the sequence of events that we expect all dynamic message sign systems to do to go to perform to make sure that we conform-- so we can support interoperability so that we get the result that we have expected. Sometimes these dialogs also provide something called sequence diagram that graphically displays the events that occur. So right now having to read through the text as we did in the previous two slides we do show it graphically. So they appear from time to time.
As a note, though, we do put a disclaimer. If there’s a discrepancy between what’s in the sequence diagram and the text, the text takes precedence meaning the text rules and not the sequence diagram. And as an example of the sequence diagram that’s clearer in your student supplemental handout I believe it’s on page nine. So final notes about the requirements traceability matrix the order of the data exchange is important unless the dialogs state otherwise. Interoperability may be compromised if you don’t follow the sequence of data exchanges. As a little note, the standard does specify these data exchanges as sequence data exchanges.
There is technically nothing preventing a vendor from using their own sequence. They typically are allowed to but when we perform testing, when you test for conformance, we will go through the sequence that are specified in the standard and it better come up with the expected result or else it’s not going to conform to the standard. They want to use a different sequence that’s technically fine. We don’t recommend it. But they’re allowed to as long as the sequence that define in the standard comes up with the expected results we’re fine with it, meaning it will still conform to the standard.
Another poll, which of the following elements are not part of the requirements traceability matrix? Similar to the previous one. Now, we’re asking about the requirements traceability matrix. So which is not part of the requirements traceability matrix? User needs supported by the standard, requirements supported by the standard, standard dialogs to fulfill the requirements or data objects to fulfill the requirements? So again, please complete the poll. Which of the following elements are not part of the requirements traceability matrix? So I’ll give everyone a couple of more seconds. Only about 20 percent of you have voted so far. So I’ll give everyone a couple of more seconds to get an opportunity to vote.
Okay. Time to close it. The correct answer is actually one. Which of the following elements are not part of the requirements traceability matrix? Recall that the requirements traceability matrix maps the requirements to the design. So user needs are not supported. And the design, actually, consists of standard of dialogs, sequence of events and data objects. So the requirements traceability matrix, again, traces between the-- talks about requirements and what are the dialogs, and what are the data objects to fulfill the requirements? The PRL table, the protocol requirements list on the other hand maps between the user needs and the requirements. So the user needs only appear in the PRL, the protocol requirements list. So the correct answer what’s not supported, what’s not in the RTM is the user needs.
So now we’ve gone over the requirements traceability matrix. The next topic we’re going to talk about is how this, again, the PRL becomes part of your specification. When you create a specification for a dynamic message sign system the communications interface which is what the standard covers is only part of the specification. And indirectly we do cover-- it covers what goes back and forth, how do we communicate? How do we exchange information? How do we control the dynamic message sign for my traffic management software?
So that’s what the standard covers. And indirectly we actually also cover functional requirements. As we mentioned earlier, we talked about expected results. Though technically the standard is a communications interface specification, what data goes back and forth. We indirectly also cover functional requirements meaning there’s an expected result, an expected something to happen by sending this piece of the data. So I might send an object that says hey, please, activate the message. I expect the dynamic message sign to activate the message. I said this piece of information about oh, this is what font I want to support I expect the dynamic message sign to support this font and display the font at the appropriate time, or display the brightness, or display this message, or support this color.
So there’s an expectation. So indirectly we are supporting functional requirements. I mentioned earlier about the protocol requirements list, by completing this PRL table we do indicate what are my requirements for my dynamic message sign. So the completed PRL really could, probably should become part of the specification that you put out on the street in addition to your other contractual requirements and hardware specifications.
So completed PRL defines your project requirements for the communication interface. Specify what standards are to be used. These are some hints. You wanted to say okay, this is the standard I want to support. In our case, we want to support NTCIP 1203. You want to be specific to what version. As we mentioned earlier, there are actually currently three different versions of the standard. So you want to be clear, hey, I want version two or maybe version three. Version two or version three, again, are essentially the same. It’s just that version three actually corrected a couple of little minor errors that we found. And it includes the test procedures.
So yeah, you could probably use-- you should-- but it’s only a recommended standard now. I mean it’s not totally completely-- it’s currently being balloted but we expect it to be finished relatively soon but you can specify version three also. It’s pretty stable. And the specification should include a PRL, your completed PRL. And if you recall in the last column of the PRL you have additional specifications. We fill that out because that will help clarify certain parameters like how big is your event log supposed to be? How many messages are supposed to be supported? And we provide that additional information in that last column of the protocol requirements list. The supplemental requirements, again, please fill out that supplemental requirements table, also. And the last part of PRL there’s other things that we include.
I apologize. I misread this. There are certain things that we do not cover by NTCIP standards like how many devices are on each communications channel, to polling rate how often am I going to send a message to that dynamic message sign to say hey, what’s your status? There dialup industry seems to be fixated on every 15 minutes will dialup the dynamic message sign to check on its health. If you’re on an Ethernet, for example, system you might be able to support 10, 20 different devices on the same communications channel. We, unfortunately, don’t address that specifically in the standard. So as much as we do try and be complete we really are not.
There are a couple of areas where we don’t include the information to make a complete standard so don’t totally rely on just the PRL table. Response times are just in a different standard, see below. This says how responsive when I send a message to dynamic message sign how responsive is my device supposed to be? So I send a message, hey give me a status, I’m expecting a message back in roughly about 100 milliseconds. This is covered by the NTCIP standard. So don’t say- if I send you the message, hey, what’s your status? I’m not expecting an answer one minute later. We expect it to be relatively responsive. So that’s actually covered by the standard.
The requirements in your PRL should be consistent with the hardware specification meaning if my hardware specification talks about oh, we’re going to purchase some lamp-- I’m sorry, we’re going to use LEDs for our dynamic message sign, don’t fill out the PRL table looking for lamp errors because those are different types of technologies. So try and be consistent with your hardware specifications. You got, for instance, with LEDs, select the requirements having to do LEDs and don’t select the requirements having to do with different technology. This should include a statement that only standardized design solutions that’s why the RTM will be implemented, meaning that we expect you to conform to the design that’s specified in NTCIP 1203. And, again, the best way to do it just complete-- provide a completed copy of the PRL and include design specifications. And that particular PRL becomes part of requirements. And when you do testing it actually becomes part of your test plan, also. So that handled specifications.
And now we’re going to talk about extensions. Extensions are discussed about how do we handle requirements that are not covered by the standard. Again, as much as we try to be complete we realized that there were a couple of areas where we did not support-- several requirements that we do not support. But that said, there are ways that the NTCIP standards can support these requirements that an agency may have that the standard does not support. So, for example, we’re going to go through some examples later, an example later, but legibility was something that came up in the dynamic message sign that we don’t currently support meaning that hey it’s still the message because of errors or failures in the LEDs, for example, or in the sign. The message is partially not legible, please blank it. We don’t want a bad message going up there.
So but the standard currently does not support that specific user need or have that particular requirement. So if it’s something that’s important to your agency go ahead and say, okay, we have this requirement. A user need, you have this requirement that’s not currently supported by the standard so we want to support it. And now we’re going to use these dialogs, these objects, create these new objects that says, okay, let’s test for legibility, create these dialogs, and say, okay, this is how the sequence of events I expected to occur and include it in your specification. We do allow that. There are ways to do it in the NTCIP standard.
On the other hand, that doesn’t mean because we allow you specify your dialogs and objects, that does not mean you can define a new object or a new dialog for a requirement that’s all ready supported by the standard. For example, I have a requirement that’s supported by the standard to control brightness, for example, well, the standard says this is how you will control brightness. You will use this dialog, this sequence of events. You will support these objects. That does not mean that now the implementer, your vendor, can say I don’t like the way to do it. So I’m going to create my own objects. I’m going to create my own sequence of events to do this.
Well, I’m not going to create my own objects. They are not allowed to do it. They have to minimally support what the standard says. You will use these objects. You will use this dialog. You have to support it otherwise we will never reach-or you will never reach interoperability. You will have difficulties with reaching your implementation. It won’t be interoperable.
I have a question here in the chat pod are 1203 versions backward compliant?
Yes, there is specific ways that a version two can support a version one sign. We do address it in the PRL. We do address it in the version two standards. So if you do have a version one dynamic system and decide to purchase a new software, for example, using version two that new software using version two will support version one. And, again, version two and version three are actually the same. There might have been some minor fixes or errors that we found that we fixed in version three. But version three and version two are essentially the same thing.
Going back to extensions-- oops. We’ve reached another activity. Using the chat pod we’d like you to write down what do you think are some of the benefits and drawbacks associated with extensions allowing and creating them to the NTCIP standards? So this is an opportunity for you to reply and make sure that you understand what we mean, why some of the benefits are of the extensions and what you think some of the drawbacks of the extensions are. So please go ahead and use the chat pod and write down what you believe your benefits and drawbacks are for extensions.
And while you’re doing that, there’s another question when do you think version three will be available?
The way the standards process works version three is actually technically available now. It’s a recommended standard which means that the NTCIP joint committee has made it available and said we believe this is stable. So it is recommended. We believe it’s stable enough that you can recommend it. However, the member agencies we have yet to go through a formal ballot to fully accept the standard, meaning we haven’t formally approved the whole-- all of the organization has not formally approved the standard yet. However, that said, the recommended standard is available. I’ll discuss it a little bit more. I’ll show you a slide, there’s a slide at the end of the module that discusses where you can find it, but it’s on the NTCIP.org website. That’s the website for all of the NTCIP standards. If you go to the document link then go to 1203. You actually can download the recommended standard right now. It’s available.
Version three is currently available from that document link so you can download it as a PDF. So it’s currently available now. The formal balloting actually has started. It’s about a two month process. And it went out I believe in the beginning of September, mid September 2011. So hopefully by the end of the year it will be a fully approve standard and then it will be made available definitely as a PDF. And I expect it might also be available in print but I’d recommend using the PDF version because it’s about 600 pages long. There’s about 300 pages for the standard itself and maybe another 300 pages for the test procedures.
I’ve gone ahead in the chat pod and some of the answers are one of the 12 active extensions are not interoperable. You may have some conflict, is it all compliant?
Some of the benefits are that you can pick a feature that you will like. So if you have any extra requirements that’s not covered or new ways of using a dynamic message sign that’s not currently covered by the standard, you can go ahead and do that. So we’ll reiterate it now. Benefits allow procurers to use the family of standards and still support operational user needs not currently supported by the family. So the benefit is yeah, we want you to use the standard. So if you can use it, terrific, please use it. It’s an extra feature or two there shouldn’t be too many. The extra feature or two that you need that’s for your agency, go ahead and use it. And then you can create these extensions to support these one or two additional things that the standard currently does support. We want to use the standard. We believe it will lead to interoperability and it will reduce your costs over time especially when you go ahead and upgrade your dynamic message sign system or expand it.
So example, I talked about legibility. Legibility is an important concern to the Agency A. Their definition of legibility, this is why legibility was never standardized by the working group. We couldn’t agree, it was more like there were different ways to define legibility. So rather than having us define it we decided, okay, let’s let the agencies do it themselves. However, they want to define legibility that’s up to them. And then they can support this feature. So in Agency A if a certain percentage of pixels have failed, the agency’s operating procedure is to blank the sign until the sign can be repaired. And this requirement, this legibility is not currently supported by NTCIP 1203. So what the agency can do is create two new objects. Again, this is just an example.
You may create an object A which establishes the criteria, for example, A, if more than 25 percent of my pixels have failed, that’s when I want the sign to blank. So object A may be percentage, for example, 25 percent is my criteria. Object B may be current percentage of pixels failed. So it’s a value that’s dependent on how many pixels are currently failing? What percentage of pixels on my sign has currently failed? If it’s 15 then so be it. If it’s 25, 30 percent, so be it. But that would be captured in object B. So then you will also create-- the agency will create a new dialog. And the dialog, maybe, for example get object A. Let me find out what the current percentage of pixel failed is. If the value-and- the next step would be if the value of object B is less than object A do nothing. It’s only 15 percent. Object A said 25 percent. Okay, it’s fine. Do nothing. On the other hand if the value of object B is equal to or greater than object A blank the sign. So if object B is like 25 percent and object A is 25 percent hey it’s equal blank the sign. So that would be an example of a new dialog.
And then in the PRL table and the RTM table, now you want to edit it. You want to edit and add this requirement, hey, I have a new requirement. It might be requirement 184.108.40.206, for example, and it’s for legibility. And then it’s mandatory for your implementation, for your project. And in the RTM table you say, okay, for this requirement 220.127.116.11 you would add a row and say okay for 18.104.22.168 this is my new dialog to fulfill this requirement. So the dialog might be 4.5.8, again, I’m making things up. And then it’s your required support object A, whatever it’s called, or whatever number it’s assigned and object B, whatever it’s called and whatever it’s assigned. So you would update both these tables, the PRL table and the RTM table and include it as part of your specification. So now when the vendors or potential vendors look at it, they’ll go oh they have this new legibility requirement. This is how they expect to support it. I’m going to support these new objects. I’m going to support these new dialogs. Now, they know. Now, you have your legibility user need that’s satisfied. And you can still use the NTCIP objects that still use the standard, but you’ll still also support your agency specific user need or requirement. So that was some of the benefits.
Drawbacks, just review the drawbacks quickly we had some discussed some of this. Interoperability maybe compromised. If other management stations, if another-- if you decide make your dynamic message signs available to other agencies or to a new vendor software and say it’s time to upgrade, you have a new software, it may not work. Or the dynamic message sign software from the other agency may not work also because hey, they aren’t able to exercise this new capability. Oh, so let’s say just this software I purchased it, I put it right in and it’s like hey what’s this feature legibility, I don’t know anything about it. So I don’t know how to support it. So interoperability may be compromised. If you’re not consistent on how the requirement is fulfilled interoperability cannot be achieved. So again if you use a different sequence of events you may end up with a result that you didn’t expect. So that would be a problem. And the same thing, again, if you share it with other agencies the state may end up coming up with a result that they didn’t expect if they control your dynamic message signs.
And also test plans need to be expanded. So now you have this new feature how you’re going to test it. How you want to test it, so you have to expand your test plans to support this new extension.
This is a final note conformance by definition implementation to add extensions not defined by standard are technically no longer conformant to that standard. So technically by adding extensions you are no longer conformant to the NTCIP 1203. Now, you still may be conformant on the other aspects meaning that yeah I follow the NTCIP standard everywhere else, but by definition you’re no longer conformant to the standard.
So that’s it for the instructions portion of it. I just wanted to go through a summary of what we covered in this module. We’ve discussed the structure of dynamic message sign standard specifically. We did look at the differences between version one and version two and version three. Version two added the sections on the concept of operations and the requirements. So we provide a little bit more context about what the standard-and- how the standard is supposed to be used and why we want to use the standard. Version two I did mention this we do add, provide additional functionality. Version one standard, for example did not support fonts or graphics. Performing diagnostics and power supplies is different. It was a little bit more difficult also. For example we-- versions one I can find out a power supply failed, or one of my climate control equipment failed but I couldn’t tell which one failed. So if I had five power supplies I didn’t know which one failed.
So version two we added additional functionality so I can drill down and say, oh, it’s this power supply number three that failed. So that’s some of the functionality that we had. We added support for colors and graphics also. Version two also added a system engineering process. We added the user needs, concept of operations, the functionality requirements. Both of these make it easier for agencies to use the standard. It provides the context and the background of why we want to use the standard. We added a protocol requirements list. That makes it easier for you to specify how you want the standard to work what your requirements are for your agency. And we address backwards compatibility. There is a way for our version two implementation to support version one. So you don’t have to junk your version one, toss out your version one system. It will work with version two systems. So if you have version one you can go ahead and start transitioning to version two systems whether it be signs or software. We do support the backwards compatibility. We went over how to use the two different types of tables that’s in the standard the requirements traceability matrix and the protocol requirements list.
The protocol requirements list, again, traces the user needs to requirements by completing the protocol-- well, it traces the user needs to the requirements. And the requirements traceability matrix traces the requirements of the designs based on the requirements on what’s required to select. This is to design the sequence of events, the data objects that the standard specifies to fulfill a requirement. And by specifying a single design to fulfill requirement that’s how we support and obtain interoperability. We include-- we discuss why you should include your requirements in the PRL and the RTM in your specification. More specifically use the completed PRL, fill it out, complete it and include it in your specification. It will clearly define to your vendors, what is it, what is it that you need your system to do, you want your system to do, what you will be tested against. And it makes it clear to them what it is that you want. That way you get the system that you want.
And we also talked about extensions. The standard does support extensions. We don’t recommend it if possible because it will compromise interoperability. But if you do need it, again, it’s more important for the agencies that they use the standard wherever possible. So we prefer that you use the standard. And if there’s a couple of requirements or user needs that we do not support by the standard go ahead and extend it. Here are some resources. The current version that’s out there as a recommended standard is version 3.04, again, it’s similar to version 2. There are a couple of little fixes there, errors, that’s we’ve corrected. And more importantly we included plans and test procedures to the standard.
Version two is also available. A lot of the information now are version two. Both standards, the recommended standards and version two can be found at, again, NTCIP.org. If you go to document links and look for NTCIP 1203 you can download both standards, both versions of the standards from that document link. They’re available free of charge right now sponsored by USDOT for your download in PDF version. If you want additional information about how NTCIP family of standards work, again, go to www.ntcip.org and download the NTCIP guide. A lot of what we covered today, in general, is covered in the NTCIP guide also.
This module focuses on dynamic message sign. If you want to find out more about requirements in general there’s the IEEE 830 standard on how to write requirements. The next module for dynamic message signs is module T311 Applying a test plan to the NTCIP 1203 standard. Based on the user needs that were selected, based on the requirements that were selected this module reveals how to apply the test plans that’s in version three to verify that the dynamic message sign system that you procure meets your specifications and that conforms to the standard.
During the module, we’ll discuss the relationship between testing for conformance to the standard and how it fits into an overall testing program, meaning, it’s only part of the testing that you-- the testing of the standard, the specific standard is only part of an overall test plan, for example, testing the hardware. So we’ll discuss how that fits in. So at this point, that ends the module.
So I’ll open it up in the chat pod in case anyone has any questions. I’ll stay on for a little longer to answer your questions. If there are no questions in the meantime I thank you all for joining. Again, if you have a version one dynamic message sign there are ways that the version two and version three do support backwards compatibility so please continue using your version one system until the end of its normal, useful life. But if you purchased new dynamic message sign we do recommend that you do purchase a version two version of the sign. They will work together. But even if you decide oh, it sounds difficult, I’m happy with my version one sign then it’s perfectly fine also to stick with your version one sign especially if you don’t need any new features that version two supports. So, for example, if you’re satisfied with the level of diagnostics that you’re getting with your version one sign. If you don’t need fonts, you don’t need support for color.
Again, if your version one sign is perfectly fine for you then stick to it. There’s no compelling reason right now for you to use the version two especially if there’s no additional need. But if there are additional features that you would like and you prefer, if you think version two is easier to use then go ahead and use the version two sign. There is really no strong reason for you to go to version two if the version one works for you. How can the use of extension make a device noncompliant if the standard allows extensions?
It’s more of a technicality. It’s a technicality by adding an extension. We do support it meaning to support extensions so that essentially it’s a processing saying we’re recognizing that we do not cover everything. That’s why we support it. We want everyone to use the standard. So if there’s only one or two features that we don’t support we do define okay, you wanted to add to it, go ahead and add to it. It is a technicality though that if you add an extension you’re no longer conformant to the overall standard. Now, notice how I said that. You can still be conformant to a requirement of the standard. So overall from a big picture point of view you’re no longer conformant to the standard but your implementation view you can still be conformant to a requirement understanding. So that means hey I support this requirement. And I conform to how the standard says this is how I’m supposed to conform to this requirement so I’m conformant to the requirement. It’s more of a technicality of it. So if I have a requirement and I fulfill it according to the standard so 95 percent standard-- 95 percent of your implementation or of your requirements are supported by the standard and you conform to the standard those requirements are conformant to the standard. But technically you’re not conforming to the overall standard. So that’s why I keep using the word technically. Everywhere else you’re conformant. But unfortunately because you added that one extension which might be the one percent by definition, only, you’re not conformant to the NTCIP standard. You’re still compliant with the specification because you say hey I have these requirements and I’m pointing to these in the standard wherever I can.
And for this one requirement that it’s not supported by a standard I’m defining this is how you fulfill my requirement and as long as they follow how you specified the requirement and how you designed it yeah it does comply to your specification. But, again, technically you’re not conformant to the standard. So I hope that answers that question. I hope that was clear to you.
I’ll just stay on another 30 seconds in case there’s any additional questions. Another question. For two users to achieve interoperability or share control of their DMS they should have the same version PRL and RTM in the specification, correct?
The RTM-- the answer is yes. The question is for two agencies to be able to control each other’s DMS systems, for example, they should have the same PRL. The answer is actually yes meaning they have to support the same features. They also have to support the same requirements for their implementations. At least they have to support the ones that they’re going to share. For example, there are some basic requirements that different agencies may have. For example, we both want to be able to activate each other’s messages. So both PRLs have to include that. Both of them have to activate the messages.
On the other hand, for example, I’m Agency A and I say I want to control my message. I want to be able to change my messages but I don’t want to allow Agency B to be able to change my messages that’s in my sign controller. So in Agency A’s PRL they want to have his PRL for his sign that he purchased has to at least support being able to change the messages in the controller library. It doesn’t necessarily have to in Agency B’s PRL because they’re not going to be able to control it. If they want that functionality in Agency B their software has to be able to support that functionality. If you don’t want them to have it, they don’t need it, then you don’t need to include it in their PRL. Hopefully that came across. So whatever you want both agencies to be able to share control of or whatever requirements apply to both agencies those requirements has to be selected and user needs have to be selected in the PRL.
If there are certain features that it’s not necessary for both agencies then it doesn’t have to appear in both agencies’ PRL. Implementation-wise realistically if there’s a region that wants to be able to share control whether it’s monitoring or control of a dynamic message sign it’s probably a good idea to control a regional PRL meaning we, different agencies in this region, agree we’re going to be able to share or control, perform, have these requirements for regional control in the region. So you’ll create a regional PRL. And that PRL will contain the basic functionalities that all agencies agree to that they will support in that region. So Agency A, B and C says this is our PRL. It will support these minimal functionalities. Now, Agency A then can go ahead and say okay I’m going to write my specification now and my specification, my PRL will minimally support the regional PRL. So it will support the regional PRL. But in addition, Agency A may say I have some additional requirements that I want to include in my specification. So I will include those additional stuff in my PRL. Agency B will have the same thing, minimally in their PRL they will have the ones that are in the regional PRL. Minimally satisfy those requirements, add those requirements, but regions A, C, B may say but I have to use additional other requirements. So I will include them in my PRL. So implementation wise for regions it’s probably a good idea to have a PRL where you agree okay for these signs where we’re going to be able to share information or share control these are the requirements that we agree to that whenever we specify or purchase a new DMS system we will minimally support these requirements for our region.
Okay. Great. I believe there’s no more questions. So, again, I thank you for your participation. And this ends this module A311b requirements for dynamic message signs. Thank you.