Module 6 - A201

A201: Details on Acquiring Standards - Based ITS Systems

HTML of the Course Transcript

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

Shelley Row
ITS Standards can make your life easier. Your procurements will go more smoothly and you'll encourage competition, but only if you know how to write them into your specifications and test for them. This module is one in a series that covers practical applications for acquiring and testing standards-based ITS systems. I'm Shelley Row the director of the ITS Joint Program Office for USDOT and I want to welcome you to our newly redesigned ITS standards training program of which this module is a part. We are pleased to be working with our partner, the Institute of Transportation Engineers to deliver this new approach to training that combines web-based modules with instructor interaction to bring the latest in ITS learning to busy professionals like yourself. This combined approach allows interested professionals to schedule training at your convenience without the need to travel. After you complete this training we hope that you will tell colleagues and customers about the latest ITS Standards and encourage them to take advantage of the archived version of the webinars. ITS Standards training is one of the first offerings of our updated professional capacity training program. Through the 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 website, ITS PCB Home. Please help us make even more improvements to our training modules through the evaluation process. We look forward to hearing your comments. Thank you again for participating and we hope you find this module to be helpful.

Nicola Tavares
This module is A201, Details On Acquiring Standards-Based ITS Systems. The target audience are project managers, engineering staff, public and private consultants. Your instructor is Robert Rausch. He's the Vice President with TransCore ITS. His experience includes more than 40 years in the design and implementation of intelligent transportation systems, communications systems, and ITS field devices such as traffic controllers and variable message signs. He is the chair of the TMDD steering committee, a member of the NTCIP joint committee, the ATC joint committee and participates in various NTCIP and ATC working groups. The next voice you will hear is of your instructor.

Robert Rausch
Thank you, Nicola. With TransCore we build central systems so the implementation to talk to the field devices is critical. The standards, the NTCIP allow us to build systems that can talk to all the various devices without custom drivers as used to be the case about 20 years ago.

As we have indicated, some of the prerequisites we kind of assume that you have with this class is you've taken the first three courses indicated above, but we assume that you have a basic knowledge of Intelligent Transportation Systems or ITS in general. Have some experience of managing ITS deployment projects. That you have knowledge certainly of your own government procurement processes. And that you've been acquainted with the System Engineering Process through one or more of the training programs that's been around to date.

There are two possible curriculum paths. One for, as noted here, those standards that have been through the Systems Engineering Process (SEP), and the second path for those that have not. The particular path that you take will depend upon the standards that you need to use and that largely will depend upon the particular device or devices you're going to deploy. This course is A201 which deals with the acquiring standards-based ITS systems at a fairly high level. The other- and following this one as can be seen here, you have other classes dealing with how to use the SEP-based standards for the procurement process. The System Engineering Process will be discussed at a little later in a slide. The other, the non-SEP which is those standards that do not have the system engineering content and by system engineering content I mean it doesn't have the well-formed user needs, well-documented user needs, the functional requirements are well-documented and include a requirements traceability matrix, a protocol requirements list. The other standards, the non-SEP standards don't have those and has and is significantly more difficult to put together a procurement specification dealing with those standards.

The courses that follow A202, A103 and so forth will deal with in much greater detail the process of acquiring ITS systems based upon using the standards with non- that do not have the SEP content. The learning objective for this particular class is this is a high-level class to view the application of the standards. There will be additional courses to provide the details for the application of each standard as it applies to the acquisition process and actually there will be details for each of the individual device types that you're likely to need to purchase. One of the goals of this particular class is to understand the role of the ConOps and be able to identify which standards are likely to be applicable to your procurement process or your particular devices, and pick from both the SEP and the non-SEP standards. We throughout this course, we're going to walk through some of the content of the standards and show how exactly how this process works, how to actually use the content of the standards at a high level anyway, in the system device procurement process.

Before I get started I kind of wanted to put out a poll question that is really going to ask questions about potential problems you've had and the first set of questions deal with the purchase of NTCIP conformant traffic controllers. So let me see how many of you have had some sort of experience with the procurement of an ITS or in this case an NTCIP conformant traffic controller? Meaning the street corner traffic controller? Again, I'm looking for: Have you been there? Have you done it? Have you tried to procure this particular device? And we'll talk later about the standards process and how you've done it. Still waiting for a couple of people to chime in here. We're getting there. Almost. And alright, let's see what you all had to say here. As you can see a majority actually have tried to purchase NTCIP traffic controllers so the next question I'm going to launch to you here should be an interesting one and that is. When you did that, what kind of problems did you actually encounter? Did you specify any special functions or features that were not part of the standard? Did the vendor provide any special features unique to your operation and were they interchangeable with the previous traffic controllers without changes to your cabinets or your central systems? And I'm waiting to see how we do on this one. How are we doing here? ...We need a few more people to vote. And the question is going to also come up I'd like to know later whether all features and functions were interchangeable or not. I can't tell who is on the line but interesting. It looks like you have been very fortunate in that the majority of you have actually purchased NTCIP controllers and that they were interchangeable with the previous traffic controllers. Again, I'm assuming they were interchangeable without all of the results. I'm waiting; we need a couple more people to vote. Maybe two more people? Alright, one more? I'd like to get up to the same number we have last time. If you voted I'd like to see you hit one of these. I guess that's about it. Alright I'm going to share this one and see what kind of results we got here. They were 100 percent interchangeable. That is really, that's surprising. Usually in a traffic controller environment there are either special functions or special features or additional ways of doing things or something special that vendors have introduced that makes them non-interoperable unless it was the same vendor's central system and field system or that in fact they were not the special functions were not accessible through NTCIP.

Let's move on then to look at a second question which is how many of you have actually tried to do the same thing with dynamic message signs? And the same question would be have you purchased NTCIP conformant dynamic message signs? And in most cases, most everybody, most of these _ in town have purchased these. I should have asked perhaps one other question whether you had purchased non-NTCIP conformant devices. Most changeable message signs that we purchased these days do in fact conform to the NTCIP standard, which means they plug and play on most central systems across the board. Your results here were about the same except that not as many of you have evidently there's a fair number of you have not purchased dynamic message signs or NTCIP conformant signs and that may be the particular agency. For those of you that did, I'm going to ask a follow up question and that is the same question as before. Did you or did you receive any special functions or features, did the vendors provide any special functions or features, did you specify any special functions or features, and ultimately were they interchangeable with the previous DMS deployed without changes, without tweaks, without adjustments as it were. I know there will be fewer voting this time but I'd like to get feedback from everybody that did procure an NTCIP sign to get me some indication as to whether they were in fact interchangeable or had any special features or functions. Whoa, okay. I see we have some that did and some that did not. I'll give it a couple few more seconds here and we'll end this poll. I'm done. And the results here are interesting in that it looks like some of you did in fact have vendor provider special functions, and those of you now, this is not indicative of anything in particular but for the most part they were interchangeable but you did not specify any non-standard features. Thank you for that.

At this stage, these were the polling questions. The reason for the questions was to look at the procurement of NTCIP conformant devices and the issues that people have had have had to do with special features, special functions, special options. And with this one I guess I would- I'll ask to see if I can get any further information based upon what happened in the polling questions. If you were in a multi-vendor environment, did you have any particular challenges in a multi-vendor procurement or were all of the vendors the same? Did you get the same vendor both times? I'm looking for anybody to enter a comment or so in the chat box where we can all see it. That's the only feedback, the only mechanism of feedback that I have at this point.

So I'd like to know what was your greatest challenge in the multi-vendor procurement? And that was could be DMS, could be anything for that matter, have you had challenges where you tried to procure standards-based, NTCIP-based standards but in a multivendor environment that proved to be somewhat of a challenge. And I'm not getting any feedback here which means that evidently things went clockwork and either you had the same vendor both times around which means everything will plug and play, or that the subset of the operations that you specified were small enough that they were interchangeable. The issue that I would then would have asked for is how could you have prevented this problem or mitigated the risks associated with your procurement? And the answers there typically are to get more detailed in your application of the standards or to be sure that you exactly specified or precisely identified the features, functions, and functionality so as you went- when you go through the standards that you make sure that there are no ambiguities left that can lead to non-interchangeable or non-interoperability. [Laughs] The comment I'm seeing here is "Yes, the mitigation is exactly that." Detailing in the procurement documents every word on the doc, and you have to actually pay attention to everything you've got and make very sure that you specify very precisely what you had in mind.

I'm going to move on here and look at how the standards fit into the overall ITS procurement process. And basically we're going to start with the concept of operations or the ConOps which identifies the operational role of the systems and devices that you plan to deploy. And then the standards support two aspects of the specification process: the communications interface, the requirements between the systems and devices. Or you may have some specific construction requirements. The procurement process in this case should be driven by the ConOps which identifies what you want to do or accomplish by the introduction of your ITS systems and devices.

This course will focus on the NTCIP standards which cover the interface between the central system and the ITS devices, i.e. the communications that will go on to allow your central system to manipulate, manage, command and control, or configure the field device. The important consideration here is that most systems will be deployed incrementally and by properly employing the interface standards, the NTCIP standards and testing those systems up front for conformance in the standards or to your project specifications, you can then add or incrementally add devices, extend your system geographically. But you'll be able to expand your system with additional devices with a multivendor environment and you won't be locked into any particular procurement. It's just none of us gets all the money we need up front. It's important that it's geared to the standards identify exactly how to procure the various devices so that we can add them as time goes on.

The application of the standards then is essentially that you start at first you identify the concept of operations, i.e. what you want your system to do for you. Then depending upon the particular devices that you're choosing or the systems or the interconnections, there will be a protocol requirements list or PRL that you can select the different specific requirements or functions or features of the device that you want to meet your specific needs for the system. Then the standards themselves and that's what's highlighted in yellow, then standards themselves if they are the system engineering content standards will directly to the dialogs, messages and the newer standards even include the test procedures. So for the SEP standards this is a very straight forward process working from the top which is the concept of operations. The only other issue you will run into is the need to specify that in fact they do conform to the way the standards require the implement. The later phases as you continue with the procurement process, the devices, device manufacturers, will in fact proceed to specify the specific dialogs, messages, data elements and test procedures. But in general for an SEP standard, SEP-based standard the agency will be able to stop at the requirements definition and needs selection, whereas in the non-SEP you have to actually trace down to and identify the specific dialogs, messages, and data elements.

Let's look at where this fits into the system engineering process. The system engineering process is sort of a multidiscipline approach that for the development of a system and if you follow the approach from the left side where you deal with your regional architectures feasibility concepts down to gradually defining your ConOps, requiring your system refining those for the system develop your system requirements. From the system requirements you're either going to going to require or you're either going to develop or purchase a system to wherein your- the contractor would then deal with the high-level design, the detailed design and finally get into the software design and implementation. Then walking back up on the right hand side of the V diagram we start rebuilding or building a system and integrating the various components and as we go along each step of that V diagram the detailed design for example will give us what we want to develop test plans for the unit testing device. The high level design will define what we need to test at the subsystem level and so forth until the top level we're going to actually do system validation checking to see if the system actually does what we wanted it to do. And then we roll in our maintenance operations and then the more we learn about the system the more we're going to wind up changes and the process will iterate. What is important to this whole process is that we clearly identify and document our concept of operations, and the next couple of slides are going to look at what we would do at an ITS systems for developing our concept of operations. Because before you can identify the standards you need to use you need to understand what your system is intended to do. What needs are you trying to meet? What do you want? Why are you deploying this system? What do you want to do using this system? What ITS devices do you need to deploy to support that system and then what do these devices need to be able to do to satisfy what you were trying to do in the system in the first place.

So as you're documenting it you need to be as explicit as possible. For example DMS could be a shared regional resource used by multiple agencies to manage road closures, alternate routes, special events. And when you look at exactly what it's supposed to do for you that should give you an indication of the features, functions, size, placement and so forth that you would need to use. The IEEE-1362 provides a reference that can be a helpful guide in the development of your concept of operations. There are other courses that will follow this one dealing in what's much more detail and development of the concept of operations. One starting point for the development of your concept of operations is to read and understand your regional architecture. This was developed for your region and it's specific to your region and it provides you the stake holder's perspective. It's important to leverage from the work done to develop the regional architecture since you did bring together all the agencies and operations and they all through that identified their roles and responsibilities so that is a good starting point for what you want your ITS system to do. Regional architecture also identifies the ITS level functional requirements and the unit connections that you're going to need between the systems and actually these are good insights for development of your concept of operations for your local ITS deployment.

In developing your concept of operations or ConOps let's consider some of the examples that you might want to deploy in advanced traffic management system for example and the associate interconnect between these systems and devices. So if you sort of look at what's on the slide here, these are all concept of operations. What do I want to do? For example I want to provide traveler information. Only you're going to refine that, what level of detail do you want for what purpose? I want incident detection. What types of incidents are you trying to detect and how quickly do you expect them to detect? All of these are part of the development of your concept of operations. And as you can see there's quite a list here that you can get into. As a matter of fact there are a handful of slides going to keep coming up that look at the types of things we want to do because the developing of the concept of operations is the starting point. Do you want to support off-hours operation? The slide also shows you here what solutions might be considered and I'm going to look at the last one for example, the last two. Everybody wants to do active traffic management. Well how might you deal with that? There's that dynamic lane control, dynamic variable speed signs, ramp metering, diversion and detour management. How do we increase roadway capacity? Perhaps we use a reversible lanes, lane control signals, HOV (high-occupancy vehicle) or high-occupancy toll lanes. All of these are concepts that you can look at for the concept of operations. Here's another set of examples.

When you start looking at some of the other standards, standards such as the traffic management data dictionary also looks very broadly at the user needs for regional integration. And this looks because of the concept of operations for the TMDD standard which has been through this system engineering process was developed by a collection of experts, system operators, actually a significant amount of public sector involvement that said these are the types of things that I need to do in a center-to-center environment. If you're looking at the devices, you can also look at standards such as the DMS-1203 or the environmental sensor stations 1204 that have a very broad discussion of the devices, device capabilities that are included in the front section because they have a concept of operations. So these are all sources that you might use to develop your concept of operations. Again there's more. Ultimately the procurement documents you're going to have will identify a system to satisfy the specific operational needs that you've identified and the system will be integrated through a series of ITS devices and the specific ITS devices you select will determine which standards you're going to have to employ and the specific needs of those devices or what you want those devices to do for you will in large part determine the features, functions, and requirements for those particular devices.

Once you have at least an overview of your concept of operations you're going to wind up developing the details. An important aspect here is to look at the overall system design your plan will specify. You need to identify what you're trying to accomplish and what operationally you want to do. If you're an example is if you're going to introduce such concepts as diversion planning or incident management whether you want travel time measurements, you're going to have to identify what devices do you plan to deploy where and how those devices will meet your particular concept of operations. This is also your opportunity to find the interactions you would have with other systems. What are you going to share for data with other systems? Is it a cooperative incident management program? All of these lead into the concept of operations defining it, documenting it, and bringing it to the next level. As you move on with your concept of operations, you need to look at the purpose and intended usage of the data or the device to determine your performance requirements for your data acquisition. This slide for example shows do I need second-by-second? Is once per minute good enough? Is it 20-second data or is it event driven? The concept of operations should help you define your specific performance requirements and these will impact certain aspects of the selections you make in the standards. For example in the NTCIP standards we have a number of different protocols one of which is a much more efficient protocol. If you need second-by-second data then you may have to look at more efficient protocols.

Again these are all important aspects to your specification as it were, and the development of your concept of operations to know what we need to do and why. The next aspect is development implementation architecture. Now the implementation architecture is going to give you a physical architecture that identifies what devices you are likely to use, at what locations, in their role that they're going to play within your system. It will also identify the other systems you're going to interconnect with and their role and the nature of the data that you're going to want to exchange.

This second bullet is understanding because the agencies need to identify the specific communications links so that based upon their role. If it's traffic management or emergency incident dispatch or what have you will determine which method sets, what the necessity is for the communications. And again, your regional architecture should have outlined the centers, the roles of those centers and the interactions and responsibilities of the various centers within your region. And that again go back to that, it's a starting point for your regional architecture. You need to document your communications requirements. As part of your deployment plan you need to quantify what numbers beside the actual communications requirements and this gets you into a whole lot of very detailed information with respect to how you're going to use your system as well as will depend on the media. An example is if you're supporting intersections, traffic controllers, do you need once-per-second polling? Or is your media or something such that no, I need to deal with exception-based reporting? In all cases the choices you make should have a why, and should tie back to your concept of operations. If I need second-by-second, why? What's the purpose you're trying to do it? If you and some of the other issues that you make and your concept of operations you might ask what your bandwidth is, how frequently do I need to talk to my devices? If it's a changeable message sign it makes a difference but does it need to react in sub-second time or is once every minute good enough? All of these will depend upon what you're going to want the product to do for you or the ideal device.

So before we move on to standards, let me recap at this point. We discussed the preparation for invoking the standards as development of the concept of operations. The concept of operations which identify what you wanted your system to do for you and once that's done then we're going to deal with the functional requirements from the devices and the informational exchanges between those devices. That will also lead us to the particular performance requirements for the actions and exchanges.

The next slide looks at the high-level physical architecture, where are you going to put your systems? What ITS field devices you deploy and where? What equipment and systems you plan to deploy to meet your ConOps? And you want these devices to do for you, what are the specific functions for the various devices? The ITS standards NCTIP in particular simply identify the information exchanges between these systems or between the systems in the field devices to accomplish these functions. Which objects, which devices you use would depend upon your ConOps. The standards cover the data objects which are used then to actually configure a device, control a device, or monitor the device's status. What's important from the standards' perspective, is that in order to be interoperable the devices must perform the same function when subjected to the same data exchanges from the central system. And the central system has got to be able to manage that device utilizing only the exchanges within the standards following the standards. Anything else will lead to a non-interoperable result.

We now have another activity which we're going to try again. Again I have to worry about the chat box and we'll talk through some of this. In particular we're going to look at in the applications of the standards let's look at a particular configuration. This is a roadway network that we'll pretend exists. It's not intended to represent anything in particular although I live in Atlanta, there's a big ring around Atlanta. It's shall we say it's pretty typical, the normal commuter runs are the suburb to city. You have through traffic. You have an event generator, and you have a series of things you're trying to accomplish with this. You have a freeway breakdown caused by the inrush of traffic at peak hours and at this time we're not trying to look at anything exotic. We're just trying to look at what might be classic solutions to how we might what we might do and how we might deal with this particular situation.

Let's walk through this particular example. What might some of the suggested goals be for this system? There are a number shown here. Anybody who wants to enter any more in the chat box, please do so. But this is classic. I want to provide travel times for the route options. I want it so that people approaching can make alternate route decisions depending upon the time of day, disruptions, special events. I want to provide alerts, provide especially traffic directions and alternate routes. I want to distribute incoming traffic to available parking for special events. It can also be for downtown parking. And I want to mitigate freeway traffic breakdown that appears during the peak hours. Typical, these are concepts of operations. These are what I'm trying to achieve with a system or system problems.

Now let's assume you will be constructing a single central system or adding to one that you already have. What ITS devices would you deploy and for what purpose? I'm looking here for a couple of examples that you might type in the chat box, please, because I can see them, but just what type of ITS devices would you consider installing and for what purpose? And what other systems would you likely need to communicate with in the construct? Again I'll back up a number of slides here. This was our general construct. And I'm looking to see that in fact what other systems, what other devices would you likely to deploy and where? And some of the suggestions you might come up with, looking, we have DMS that would be the traveler information, we have traveler information application with connected vehicles Wish the connected vehicle happens soon, yes? The DMS travel times, CCTV, yeah, CCTV is probably a good thing to help you certainly with the incident quantification and to get you trying to anticipate breakdown. Ramp metering was one, yes, time travel, time, I've seen that come flying by. Parking information for the stadium at [ph?] events, route diversion, freeway monitoring for travel time, yes, you did CCTV. Overhead lane control or dynamic message signs is the only one that I haven't seen come flying by the quick thing about it.

The focus will be on understanding that the intended usage of the device will determine the features and functions required for that device and those in turn are critical as we look to what standards we invoked and what aspects of the standards we actually invoked. And this was a-- hey this is not necessarily the right solution but this was a solution. And as you can see here there's a distribution of ramp meters, dynamic message signs and I suggested one way to collect travel times is RFID, assuming there's a toll road it may be an automatic license plate readers or Bluetooth, you could actually even consider purchasing the travel time information from an outside vendor as the vendors begin doing more and more of this traffic time, travel time collection.

If we had it connected in vehicle environment and then we're using that as probe data there's another source of probe data. The DMS is strategically placed, we can see where they need to be, their usage and so forth would be as we might need them depending upon whether it's route diversion, how many messages we want to apply and so forth. What other systems might we need to interconnect with? There's the parking system or the stadium system or maybe the surface street traffic management system where we're dealing with alternate routes and so forth. So we document the concepts of operations of the device requirements identifying the specific concepts, the specific ITS systems device requirements based upon our discussion. And if you're looking-- I'm looking in the chat box, for the purpose of the remaining slides we need to have some method in here or something that are specific requirements.

I've mentioned the dynamic message signs up here a couple of times. I'd like to know what you think might be some of the requirements for the dynamic message signs for these particular applications. Anybody can answer this one now. What do you want the dynamic message signs-- what might be some of the requirements that you'd have the dynamic message signs? I'm going to move on because we are going to have a slide that looks at some of those as we get deeper into it. Such things as the number of lines, the size of the sign, width of the sign would have to do with the messages you're trying to display, if you're trying to display travel times between some very short areas then it made a smaller sign, if it's just incident information, the smaller portable ones might do. If it's permanent route diversion, accident alerts, travel time alerts, they require bigger signs. But in the next section we're going to look and describe the role of the standards in the typical ITS deployment. And let's get a handle on which standards might be applicable to the high level physical architecture particularly the one we just looked at. What is covered in the ITS standards? Well the ITS standards, the goal of the standards was to actually allow for the incremental deployment of the various ITS devices such as those shown here over time. And if your devices conform to the standards then you can clearly add more devices as time goes on. And the center-to-center standards, standards such as the TMDD or the IEEE 1512 and I have references to those later or the NTCIP standards and we're going to look at those in more detail that deal with the center to the road signs. However I have one caution, the standards that we'll be discussing do not dictate the actual operation of the traffic management center. Each traffic management center, that's shown in the picture here is assumed to independent and run or operate under its own rules of engagement as it were.

Currently there are no standards that address what the central systems have to do internally. The standards simply describe the information that we need to transfer or exchange between the center and the field devices of center and center. In particular the NTCIP standards have been developed to meet the-- from a physical architecture as shown here. We have two sets of standards for these communications. One is the protocol standards which tell us how to move the data and the other is the detailed what are considered to be the device interface standards, all those data elements, data objects that configure, control and monitor each one of the devices. Again, each one of the devices here includes actuated signal controllers, CCTV camera. Note that we've highlighted those that currently have SEP content and those that do not. Most notably the two devices that are most readily used are actuated signal controllers for which there is no SEP content and dynamic message signs which actually have recently been _out_ now with the full test procedures included as well. I point out at the bottom of the sheet in green we have the cabinet monitor unit there is currently a development on the way NTCIP 1214 to try and establish an interface standard so that we can have some standards on how we talk to the cabinet monitoring device, the MMU, the 2010, 210 conflict monitors so that there's a universal way that we can bring back their logs, see their current operation and see what the failures are. The communications infrastructure, understand that the actual requirements for each device will have to be known before you start dealing with the specific solutions. You need to identify the bandwidth latency requirements for the devices. How do you determine that, based upon your concept of operations?

The communications infrastructure you're going to have to lay out something based upon either what is available or whatever your broader communications plan may be for the area and you may consider a wide variety of services or technology such as the list shown here. And again it may easily be a mixture of these as well, it may be that your agency has fiber out to certain points and then you have to either lease or go wireless from those existing points. Today's ITS systems are typically using a combination of all of these and the older systems of course have only 1,200 bit per second dial-up communications. Again, it'll depend upon what you have in your area. And keep in mind that this is also a very rapidly changing area and the technologies we have today, in many cases the wireless technologies we're using today we would never even considered perhaps five years ago yet they become inexpensive and reasonable.

We have new frequency bands opening up such as the 4.9 gigahertz for urban, for emergency management centers and government agencies to the newest and the WiMax and 4G and LTE, there are all sorts of thing. So this is not a stable environment, you need to make sure that you're preaching the communications media that'll be optimal for your particular deployment. As I indicated earlier, the NTCIP has two sets of standards. One I'll consider the protocol standards which is how do I get the data, how does the information whether it be configuration data, status data or command data, how does it get from my center to the field device or center-to-center? And there's a number of standards in here that we're not going to go into any detail on that deal with and have developed for the transport level, the protocol level that allow you to achieve interoperability between systems at that level. It's important that you match the protocols at the lower levels amongst your system elements to ensure interoperability and when developing your specifications, the communications media may, I say may determine which of these standards apply. Although you may have specific media such as the ancient 1,200 bit per second twisted band copper where you're going to have to use features and functions, there won't be any TCP/IP transport in those cases, it may be just point to point protocol or point to multipoint protocol using older modems. But the NTCIP standards, the ITS standards for protocol have been in fact developed so that you can support NTCIP over a wide variety of media. Often people would say, "Well I can't use NTCIP because, because my communications is too slow, because the bandwidth is too great." None of those are true; the NTCIP has various techniques that can be used. STMP noted on the bottom side makes field communications far more efficient to where second by second can be achieved with four units on a two wire line, traps are being used with exception based reporting, on a wireless, make a very good solution and you can use standard SNMP where you have an IP network such as fiber or leased DSL or cable drops. So the NTCIP in fact as a set [ph?] of interface standards will work on a wide variety of media.

There are also hardware standards that we're not going to talk about those in any detail here but obviously if you're developing your RFP or procurement specifications you're going to have to deal with the hardware and what you're going to specify there will also define, your cutoffs will define some of the hardware requirements for your RFP. The caution here is that you should work from your concept of operations to determine what you want the ITS device to do, not so much from what's available in the catalog or what I can buy but what do I need and then you temper it with what may be available. Examples of the hardware standards, NEMA has a TS4 standard for dynamic message signs. The TS2 standard for traffic signal controllers, both the hardware and an operations standard, it's what dictated the current traffic control philosophy that's used in over half the intersections today which is the multi-ring barrier actuated coordinated operation. Some of the states, California have their own standards and we are still the advanced transportation controller standards which includes the 2070 by the way has a family of standards as well, the applications programming interface, the ATC hardware standing [ph?] and the ITS cabinet standards. Again, these are all standards in the ITS arena but they're on the hardware side. The TS4, TS2 and most of the state hardware standards do not deal with the system engineering process, those are now being applied to the ATC so that will be more complete there. It's important that you know your devices and the NTCIP is a very flexible, very broad standard, not all the devices support all the protocols or capabilities described in the NTCIP standards and the example that I list here is the dynamic message signs for example, none of them support the STMP or simple transportation management protocol which was a simplified mechanism to try and decrease the bandwidth requirements and increase the throughput that could be achieved on basic two wire 1,200 baud or two wire 9,600 bit per second support. Only the ASC for example is known today to support traps and I believe there's only one or two vendors doing that, requiring for example a dynamic message sign or a traffic control of the 255 locally stored messages or requiring that a traffic controller have 255 phases just because the standards says this is a possible limit.

It kind of doesn't make sense unless your concept of operation somehow shows that you've got different phases to be used or different messages that you need to call up remotely all the time. It's also important that you understand what features and functions are generally available rather than specify a custom collection of requirements. A custom collection of requirements can often lead to an unbuildable or very expensive product as it were. Reviewing back to the application of the standards, we discussed the concept of operations. So we've described what our system will do, we've got a list of what we want our devices to do, what's next? Next is we take out concept of operations and user needs and go to the protocol requirements list which is to select the specific requirements for the device or devices that we want and the standards will then describe using either the PRL or in the case of the TMDD, the needs, the requirements traceability matrix will actually identify then the value ranges you need to fill in as the purchasing agency or the values where necessary and then the PRL will identify the dialogs, messages and data elements and then the standards themselves will have test procedures that you will have to select from based upon what your specific requirements were and in many case they're above optional or mandatory requirements so this is a stage that you have to do. And the example I list here, when you've got to select specific value ranges, the example listed here the number of messages supported or the number of fonts you want to support your changeable message sign.

The PRL make it clear very often what you as the agency need to identify or fill in the blank as it were to assure that you're going to get the device you wanted to. Going back to the system engineering process once we have the concept of operations then the requirements emerge from that and drive the remainder of your project. So it's first the system and then we're going to look at each device. At this point the RTM then points to the specifics, in this case contained within the standards and those specifics are the data objects, the dialogs, the message sets to be used to communicate from the central system to the field device. For the non SEP standards it's far more difficult because you don't have this tracing from the high level, from the concept of operations to the specific data objects and there you as the agency actually have to do the homework, do the leg work and you would have to specify, identify the specific objects needed and identify specific dialogs that you would need within the standard to meet your particular concept of operations. I'm going to back up a minute and give you two different definitions for terms that we tend to throw around and they do not meet the same thing. Conformance, and I'm going to read it straight out here, a product conforms to the standard if it meets the specific conformance requirements stated in the standard. All SEP standards have a conformance statement that say that in order for your device or system to be conformant you must adhere to these standards in this manner or must support this dialog or must support this object in this way. Compliance simply means that a product complies to a specific procurement specification, if it meets all of the requirements stated in the specification.

Typically an agency will take a standard and develop a procurement specification and then the vendor will review the specification and provide a product that is in compliance with that specification. Products which extend the standard with additional elements that do the same function with proprietary elements or blocks or do not support the dialogs within the standard those products are not conformant. So any vendor that tells you, "Well yes we run the scheduler but we have our own blocks that run a scheduler that's compatible," they're not conformant to the standard. You have to do it the way it says in the standards. And we discourage agencies from changes, or accepting changes in products like that that have adopted different ways to do the same thing, that is that they are non-interoperable and they do not conform to the standard. For a vendor to say we conform but do it this way, the two statements are not the same. If you as an agency do in fact want some additional features or functions they need to be fully documented, use objects which are in the public domain although they may be custom, they can't be proprietary. A vendor that goes around stating that, "Well I have a proprietary __________ to control my proprietary function," is a non-conformant product and if that's what you want then go about buying a sole source, take your sole source procurement rules to whatever your agency requires and so but that's not conforming to the specification, rather not conforming to the standards, I'm sorry. We're going to look at requirements examples now and we've got some very specifics here taken from the standards and let's consider the requirements for each of the ITS devices.

Focus on the DMS for example and remember we had the example that we did before. Some of the things you're going to need to look at on the DMS device is the sign type and again the standards will give you a lot of options, color, size, message content, everything that you identify that you want that device to do. There should be a why, "I'm doing it because." And again, as I stressed before, if you reference the 1203 standards for examples the 1203 standard has a great deal of material in the front that does deal with the concept of operations, user needs, it deals with the particular requirements, it looks at what you might have. Now keeping in mind what we had with the example, with our city example and our use of the dynamic message sign, what aspects of the dynamic message signs do you feel were needed and would you put a list in what might be needed here, put a list in the chat box. And I'm looking for some of the things based upon-- I've got the next slide is sort of, if you look ahead gives you some of the ideas. But for those of you who have done DMS or are familiar with what they might look at I would like to know some of the features and functions, what aspects of DMS do you think would be necessary for the applications we were looking at? And I'll give you about a minute here to type in messages. I'm watching the chat box.

Now if we're going to do travel times what does that kind of say or where are we going to put the signs, on the surface street or are we putting the signs out on the freeway? If we put it on the freeway what does that say about the length of the sign, the number of phases, and the complexity of the message. How big was the sign? Do we want to do color graphics? Some of the signs in many foreign countries use a lot of color graphics to show the traffic conditions for a city or town that you're approaching. How many phases, how many presentations? I'm looking for things that might be specific features or functions that you'd want for other dynamic message signs for our example. And I'm going to move onto the next slide which was a set that we could use. And the answers, maybe they're full matrix to be able show graphics. Maybe they're three color, we want yellow, red and green, not that we're trying to show full color but we probably may want to show highlighted messages in yellow or red or green, we may want to intermix some graphics. Sign size, I've hit on a sign size that is maybe is 27 by 120, other sign sizes depending upon whether it's line matrix or full matrix, we're going to use IP communications to go to it. Maybe the sign is a maximum of three phases, three presentations. Even that's awkward on a freeway sign when I'm flying along at 65 miles an hour in the city of Atlanta where the speed limit is, well a lot different than what most people drive, being able to read more than a single presentation is almost impossible given the sight distance in the speeds they're travelling.

I've put a couple of comments on the bottom here, all messages will be sent to the sign for display. There's no need for a message library at the sign. Do you agree with that? Does the sign need to have a scheduler? Why? If it's connected to a central system why on Earth would I want the sign to have a message scheduler? The most it can do is put the wrong message up because I can't tell it that it's the wrong message today. I'm not getting any feedback here so perhaps those of you that have bought changeable message signs, my caution to you is that when you're going through and specifying or identifying the features and functions, every feature and function that you list or you identify or you specify should have a why, a justification. Too often agencies will simply check every box in the book and figure, "Well I need the sign to have all the features, I want it to have 125, 128 local messages, I want it to have all kinds of things that-- " the question is they don't pass this test of reasonableness what are you going to use it for to do those things? I want a sign schedule. And the first day-- because I'm going to schedule it for construction activities. So on the first rainy day what happens, the sign turns on its message, "Workman ahead, right lane closed." Everybody drives through and, "Well there's nobody out here working today." You should have not scheduled it and all that happens then is the sign loses credibility.

So basically you need to look at the reasons for it. Some other considerations for the sign, will the sign be on the side of the road, over the road, how are you going to deal with the construction? These are all the hardware aspects that you're going to look at because as you were designing in your concept of operations one of your concept of operations should have dealt with operations and maintenance, how are you going to maintain this sign. I've seen agencies say that, we'll get out there and maintain them once every three months because it costs a fortune to maintenance of traffic so they can block lanes to get up to the front service signs over a freeway. And you turn around and you say, "My God weren't you supposed to be providing a service?" And as soon as you get a failure then the sign goes out of service for three or four months until you can afford to go out there and fix it. Why aren't you looking at different maintenance techniques? All these are things that need to be factored in based upon your concept of operations. Now let's look at the standard and use the SEP conduct that we find in those standards. Again, reference back to the previous section where we looked at a particular example.

Now we're going to look at the SEP content of a standard and there are two standards that we're going to look at, one is the Transportation Management Data Dictionary and the other is the 1203, the dynamic message sign content. I have also incorporated excepts in the reference material that was sent out on this does include excerpts from the TMDD and the NTCIP 1203 standards along with a brief description of the system engineering process. The reason that that was put in there, these are only short excerpts is so that you get an understanding of what is actually contained in the standard in terms of support for the concept of operations, the requirements and actually as you'll see in there the NTRM in the case of the TMDD and the PRL in the case of the 1203 standard. The ConOps is really there in the standard to aid you in your understanding of all the types of the functions. And you reference the ConOps, the example the TMDD or the 1203 standard to get a firm understanding of the functionality that you're trying to manage. What one needs to understand is that the standards that we'll deal with, NTCIP 12xx standards for example are nothing more than a list of the parameters necessary to manage or monitor or control a specific ITS device, they're just parameters. They're just the data elements that tell us to display a message, to tell me how many messages are there what the temperature is, that's all they are and the standards simply deal with how to exchange that. Well if you don't have a clear understanding of what those features and functions are then controlling them doesn't have a lot of meaning.

So in the case of the SEP content standards, the first sections of the standards will deal with the concept of operations. So if I look at the NTCIP 1203 for example it has the introductory material which includes normative references and normative references in this terminology mean that in fact the other standards that are referenced are referenced in a mandatory way, normative means you must follow what it says and it's got a glossary. Then we've got the NTCIP 1203 as a concept of operations for the device, a description of all the device functionality, user needs for the device functionality and the device functionality so that you look at it from a need and we're going to look at what each one of these actually contains.

There's a complete list of the functional requirements that those user needs break into that describes the requirements based upon those needs. It includes a protocol requirements list to be used by the specifier, you the agency preparing the specifications to identify those specific features and functions and then from there on it shows what in particular in terms of dialogs, messages, data elements do we use. And then one of the latter sections contains the actual object definitions themselves. The PRL in front of the ConOps, functional requirements in PRL are all written in laymen's terms I'll say, they're written in terms that the user community, the agency employing the device, the operator who's going to use the device understand. Not as you'll see in some cases the particular notations and technical details of the standards, they allow you to work with it at the user needs section. Again the user needs section describes the functionality from an end user perspective. All the features required are described, the section numbers relate to the specific user needs so that you can actually use the PRL and I'm going to show you that on the next slide.

So you as the agency start here on section two to understand what you want to do and it's everything, it describes all the functionality of the ITS device and in this case the DMS. An example of a user need, this is not a requirement, this is a user need so we see phrases like should, the operator should be able to-- yeah, I'm just going to read this but this is an example. This feature enables the operator to control the sign brightness either directly or through an automated algorithm, depending upon the capabilities of the DMS. At a minimum, the operator should be able to control the brightness of the sign display manually for light emitting signs. Additionally the operator should be able to control the brightness level through the use of light sensors, photocells on the FMS if available. That can detect the ambient light levels and adjust the brightness levels in an appropriate fashion. This brightness control is needed to compensate for the external environment's effect on the visibility of the message such as when the sun is shining in the eyes of a traveler. So what you have here is a very complete description of the functionality that we want from the perspective of the end user and a reason why. The next slide deals with, "Okay, that's what I want; let's look at how that translates."

The DMS functionality details the functions the sign are described in the protocol requirements list. Then we'll get to section three in a moment that actually details each design. So in this case here we have optional and mandatory. So the control of the brightness is a lamp or an LED, it's optional obviously but if it's lamp or LED then it must be yes because the requirement is or the need was for those signs that have intensity control. Determine the current photocell readings, yes, auto brightness that was a mandatory requirement. Manually direct control brightness, that was optional for version one. This function's not applicable to version one. This is a case of where the standards went through multiple versions. But you see some of the specific requirements here would be optional or mandatory depending upon the procuring agency wishes to specify. But from that drawing, or rather from that document the PRL then what we have is section three lists all of the requirements that were derived from that user need and they're indented here as shown. Section three is a list of requirements. Later courses we'll deal with this in more detail for each device. From this sample by the way it should be obvious that it's important to understand the level of detail required on the part of you, the specifier. This gives you all of the requirements necessary to support the user needs shown back in section two. Again, I don't know if anybody has any questions with respect to this but in this situation the control brightness was the high level requirement, determine number of brightness levels, determine current photocell readings, manually direct-- this is for version two, that is mandatory goes back to the previous slide.

So basically in the standard itself they've fully documented what the concept of operations is all about. Now once you've selected the concept of operations then the PRL points to all the specific requirements and-- rather points to all the specific design details, dialogs, data elements, messages and test procedures. Section four identifies the specific dialogs or sequences of messages. And this is a very simple one here, that's required to implement in order to be conformant to the standard. And this is a basic, simple set-get paradigm that simply says the management station, your central computer system, is at work, is going to set the DMS brightness value. That's the object. That's the parameter. That's the specific object, and he has the ability to set it, and the response he gets back-- if it generates a general error, then you've got to get what the error was. Otherwise, you're done. So you get the error value, as it shows in the rest of the dialog. As it says, if the response indicates a gen error, then continue. Otherwise, we're done. So if I set it and it's accepted, we're done.

This is the complete understanding of how the management station and the device are to interact for the purpose of setting the illumination brightness values. Any other mechanism or technique is non-conformant. To be conformant, it must do it this way. From the position of your procurement specifications, the dialog and detailed information need not be included, because your job actually ended at the protocol requirements list when you said "I want to be able to specify the brightness value." And then from then on, these are directions more or less to anybody testing, which object to look at, and the developer of the central system, "You got to support this," and then the developer of the product, the dynamic message sign. And to get you further into, again, the next level of detail, again, this is something you don't need to worry about as a specifier, but for each object, each function we're going to deal with, there is in fact an object whose name is DMS, a little brightness level status, and then it indicates the current brightness level of a device, ranging from zero off to the maximum value given by. And there's an object identifier. There's a huge long number sequence there at the bottom with a 1206 in the middle and numbers. And notice the five on the end is the same as the illum five on the very bottom. That gives us a mechanism whereby the protocol we can exchange, and we know exactly how to identify this particular object. And that's because in the standardized mechanism for dealing with the device, the management station simply does a set or get to this particular object.

The use of proprietary or custom dialogs in objects provided by the manufacturer to provide, again, or support special operations will not support the deployment of the interoperable systems using just the ITS standards, nor will they be conformant to the ITS standards. It's also important to note here that your central system must likewise conform to the ITS standards and that the only way the central system should deal with this device is as specified in the standards. The new standards which contain the SEP content also include a requirements traceability matrix that traces the requirements to the dialogs and specific objects. One other point of note here is that there's a whole collection-- as I showed earlier on the slide with all the devices, there's one other NTCIP standard, NTCIP 1201, that's the so-called global objects that contains those objects which are common to all ITS devices. The 1203 standard, because it's been through the system engineering process, identifies all the necessary elements in the NTCIP 1201 standard. Again, I reinforce, to be conformant, the device or system-- both of them, by the way-- must implement the interface as contained in the standard, and you're going to deal with-- the details for the individual devices will be dealt with in other course materials to follow.

Looking now at the TMDD standard, which is a different exchange-- this is intended to support between systems. The concept of operation explains the needs for inter-system exchanges. The TMDD data dictionary-- TMDD is the Transportation Management Data Dictionary-- was originally developed as a common data dictionary so we could achieve interoperability between systems. If we all talk about the same thing, then we at least have some chance for being interoperable. As we migrate to quotas and regional management and as our regional architectures expand, it's essential that the centers be able to exchange this data. And the version three out of the standard now focuses on the data elements, messages, dialogs and exchanges between centers to provide cooperative incident control, traffic management and sharing of ITS devices. And version three of this standard was released about three years ago, I think, now and includes the concept of operations. It includes the user needs, the user-specific requirements and then gets into all the options that can be selected. And it is a good starting point. Any time you're developing a concept of operations for your interactions between centers, the TMDD is also a good starting point to go to say "Okay, where do I get started?" or "How do I get through it?" If you start there, you're relatively assured at least it will represent to you a great deal of the reasoning behind the exchanges of data between centers.

The TMDD includes the requirements [inaudible] exchanges. It includes the needs to requirements matrix, which we're going to see in volume one, which traces the user needs and the specific requirements and then allows the agency to identify those that are optional, because not all agencies were prepared to deal with all the features and functions. And then volume two is where all the details are for the dialogs, message lists, content and so forth. The TMDD is-- volume one, section two identifies the typical user needs for the center-to-center communications. Now, in this case, it's a higher-level abstraction of the device. We don't deal specifically with-- you didn't see the intensity level. We don't see whether the diagnostics are there or the pixel tests and so forth. This deals in a higher level of abstraction.

What is interesting to note under 2.3.6.4 shown here is that all of these deal with-- and all the devices are similar in their interaction. I need to share DMS inventory. I need to update the DMS inventory. Alright? Those two, I got to figure out a way to figure out what signs the agency I'm connected to has, where they are, attributes of the signs, you name it. I need to know everything about the signs so I can either place them on my map or I have a complete view of what ITS tools may be available from the corresponding neighbor system. Then I need to know the status of the device. Tell me what's on it. Tell me what's on the message display. I want to be able to verify control status. Did I get control, or did I get another cue? I've got message requests for a cue and control status, so in this case it's a device, but I want to be able to control the device between centers. So in a case like TransCon has in the Northeast, where the signs themselves may be owned by another agency, the hope and the intent within a regional context is that we can use the signs to the greatest advantage to divert traffic as far upstream as possible to avoid snowstorms in an area or alert people back in rest areas "Don't bother to venture out, because 100 miles ahead we've closed the roadway," which is part of the reason we want to be able to share these devices between centers, so we can actually begin alerting the travelers at appropriate points. Then in fact if I want to be able to send a specific message to a sign, as you see in the last three, I need to know what the sign looks like. How many columns? How many lines in the line matrix? I need to know what messages it has in its library. And if I want to be able to send the message for dynamic display, I can do that. Whether the center I'm talking to does it or not is a separate issue. I need the font table. With the font table, I can do a "what you see is what you get" interpretation of the sign.

Based upon the sign message appearance, I can make sure that the sign does not overflow. Don't try to put a message that's too long for the sign. But this is the user needs as it were for the establishment of interaction with the dynamic message sign. This gets into refining the user need. The other one was just a summary of the headings. This takes a particular one, need to share inventory, and I show this one because-- and read it-- the center needs to exchange DMS inventory information so that DMSs operated by a center can become known to other centers. Well, the inventory information therefore needs to include things like locations, including direction of traffic the DMS is facing, the size, physical dimensions, characters per line, so forth, and the technology to be used. By knowing that, I can know what messages can appear, what can I put on the sign, where is it. I put it on my map, and I can determine whether it might be useful for the mitigation for a certain collection of incidents. The TMDD content examples go further. Again, this is the requirements for the center-to-center communications with respect to the TMDD. You'll notice the section numbers match exactly what we're looking at of the user needs.

Now, if we choose a need, we've got a specific requirement that deals with the sharing of the various devices. It was a direct correlation between the two. To further drill down to an example of a requirement in the TMDD, this is the contents of the device information request. And the required device information request has to have a unique identifier for the owner, device type, device information. This gets you the detailed requirements for the message that needs to go between the centers. The details of how to actually use the TMDD to accomplish this will come in later courses. I haven't seen any questions. I'm going to pause here if anybody wants to throw any questions, because we're about to wrap-up the system engineering side of life. We've got one more in this family, but if you have any particular questions, now is the time to put them in. This is the TMDD needs to requirements traceability matrix that, again, I continue with the column three, which is the user needs selected. If the user suggests that, yes, I want to share the DMS inventory, "Yes, I do," then in fact the conformance requirements are thus mandatory, and we would hope-- it must be supported. Notice as you go down the list here there are a whole lot of optional features. When the various parties were developing the TMDD, many of the people involved were public sector, public agency owner-operators of centers, and the concern there was "Well, my center doesn't do this, but I want to be able to be conformant, so make it optional," and hence a lot of stuff was made optional.

Within a region, it's important that your procurement documents all be consistent in their selection of what's optional within a region so that you can all share the data. All the systems will interoperate and expect all the same data. But there are occasions, again, in the support column-- and actually there's another column that may be where you have to specify a specific entry or value, a time constant. One of the issues that you'll see when you get to the TMDD is "How long does he have to respond to me?" If your replier takes too long to reply, I assume he's not there. I'm still looking for anybody who wants to ask questions in the chat box while we move on.

At this point, let's review the standards with the SEP content. Standards with the SEP content include the following. One, a concept of operations which describes the user needs in laymen's terms. Number two, they include the functional requirements that break-down those user needs into a detailed set of functional requirements. Then they include a protocol requirements list, PRL, that connects the user needs to requirements, and the agencies use the PRL to identify the specifics. Then there is a requirements traceability matrix that actually traces the requirements to the specific dialogs and data elements. And then agencies use the PRL for an SEP content standard, simply mandate that the dialogs-- uses the PRL and mandate that the dialogs and data elements conform to the standards for all selected functions, and that will lead to achieving interoperability.

Let's look now-- it is unfortunate that not all the standards have the SEP content. In particular, one of the major ones that does not is actually at signal controllers, ASC 1202. Without the ConOps, it is up to the agency to identify the functions, dialogs and objects needed, and this is much more difficult. Some of the SEP standards may include protocol requirements lists but be very different. The features are different. You can't use it the way you can with an SEP content. It also requires that the agency thoroughly and completely understands the functionality and has identified those functions, objects and so forth needed. For the non-SEP standards, start with the same high level. The top two things are the same. We have to develop a concept of operations, and we have to document our requirements. But for those standards without the SEP content, as I pointed out earlier, the burden is on the agency or whoever's writing the procurement specifications to translate those needs and requirements and to determine how to satisfy the requirements from any-- in this case, they have a conformance group list-- and fill-in any of the qualifications, sub-qualifications or specific elements. And in some cases, the functionality description may be housed in another standard, such as the global objects, NTCIP 1201, or more general standards such as the NEMA TS2 or NTCIP 2301 or 1103. In this case, the agency's going to be responsible for the development of the test procedures, or you can supervise that and make the vendor responsible.

As I said, these are some of the issues that you may take up for the non-SEP 1202 standard. There are many ambiguities in the standard, and it needs to be updated with the new MUTCD functionalities, such as the flashing yellow arrow. We don't have objects for that yet. There are a whole lot of things actually we don't have objects for. We have objects for basic phase control, the phase, number of rings and so forth, but there are no NTCIP objects for interval-based control, i.e. the old pre-timed interval base, and I have a number of cities that want to use that. The objects for the control of TSP are actually contained in a different standard, NTCIP 1211, I believe. And the problem with that standard is it's a different construct than most people use. The functionality to be provided in hardware interfaces, special functions at the intersection, such as the flashing yellow arrow, people looking at flashing greens, all of those are not specified currently in the NTCIP. The scheduler is, but very often vendors have found it necessary to build their own implementation of the standard. It gets even more complicated than that, because very often agencies have been known to have their specific additions to functionality create problems, such as-- and then it goes well beyond NEMA, and hence there are no objects to control it. Remember that for devices to be interoperable, the functionality must be well-defined, completely defined without ambiguities, and the dialogs for the exchange of the data elements to manage that operation must be fully described.

When special functionality is introduced and not described completely so it's unambiguous, non-interoperable systems will result. That's not a maybe. They will. As indicated earlier, the NTCIP 1202 is based upon the NEMA TS2 standards for the functional description. So in order to understand what's being managed or controlled in the NTCIP 1202, the reader must have a very thorough knowledge of NEMA TS2 actuated, coordinated, multi-ring, barrier-type control. The standard jumps-- as you can see, section two jumps straight into the object definitions, assuming that you do understand the NEMA functionality. Section three presents block objects that were developed to simplify the downloading of the various tables and parameters, and I'm going to tell you that an actuated single controller is, bar none, the most complex device we have in ITS today. And as a result, they've put in blocks and tried to do all sorts of things, because the actual size of the database varies dramatically between vendors and tends to be very, very large. It's important that you as the user recognize the functionality and the intent of conformance groups, which are also provided. And we're going to look at the conformance groups and the PRLs sort of to make sure that you understand how to specify those.

Dynamic objects, which were essential for low bandwidth and actually for compact exchanges, are not supported by all the vendors. And you have to be very careful here that some of the vendors have chosen to make their MIB, their management information base, proprietary. So you have a whole collection of history as well as a complex device without the system engineering content.

To get you a better feel for the conformance groups, they actually put together conformance groups which group related objects together. It was intended to assist the agency in specifying the mandatory and optional data elements that you need to provide to include the specific functionality. This is a partial list only of the conformance groups, and note the concept of block objects was down at the bottom. It was a conformance group for a set of block objects. And as I indicated, the block objects were to actually simplify the exchanges so that you could do large blocks of data without the additional overhead, in this case 26 bytes per byte overhead of a normal SNMP or set-get operation that is the foundation for most of NTCIP. The next slide here gives you a feel for the conformance group. And, yes, this looks a lot like a PRL, and I'm going to kind of highlight one particular one on here. This simply states whether I want it. It doesn't describe the functionality.

I'll show you where that's described. Note that the global set ID parameter is listed as optional, the first one. It says "globe 2.2.1, global set ID parameters optional." Most of us that build central systems-- that's our only way of knowing if the database was actually changed by a field technician. So how else do we synchronize the central database? Again, there's no rationale necessarily included, and actually here's the object definition itself, but it made it optional. [laughs] Now it says mandatory. The original PRL that had the conformance group made it optional, but it specifies a relatively unique ID. As you see, this is the only description of what this parameter is all about and what it means. If I go back to the sequence that we follow on the application of the standards for a non-SEP standard, then you now can see the difference. Note that the con-option developed is the same whether you're going to deal with an SEP or non-SEP standard, and the requirements will be the same whether it's an SEP or non-SEP. But if you are dealing with an SEP standard, that's where you end. For the non-SEP standard, you have the responsibility to identify the objects, the dialogs and understand what objects will perform what functions. And make very, very, very sure that that is in fact the case, that it's well understood that what you do in fact document is the way it's supposed to look.

Your procurement documents then, to wrap this up to some extent-- your procurement documents should include the following: A discussion of your concept of operations-- I think we've been there. A listing of the devices you expect to be supplied and where you're going to deploy them and the features and functions that you want those devices to support. And a detailed listing of the requirements taken from either the NTRM and RTM-- yeah, that's misspelled-- NRTM, needs to requirements traceability matrix, or the protocol requirements list of the SEP standards that identify the functions to be supported, value range and optional capabilities. Again, optional capabilities are important, because not everybody wants all the features of every product possible. Your procurement document also should include a detailed listing of the objects, conformance classes and functions to be supported, value ranges and optional capabilities for your non-SEP standards. It is your obligation for the non-SEP standards that you need to include all of the details necessary in an unambiguous manner. And just going through and identifying the objects is probably not going to be good enough. Again, there'll be more courses that deal with this specifically, but you're going to have to go through the process of making sure that the functionality you think you're specifying is a functionality you want to specify, and it's such that when you get devices from two different manufacturers, when you plug it onto your central system and configure the same parameters, you get the same operation. To put it in a trivial case, if I send down a three-second yellow, I expect it to be three-second yellow. I don't expect it to be 3.1 or 2.9. I don't expect it-- so there are accuracy requirements, which are, again, contained in other standards. There's the specific device. I don't expect if I send down one parameter that it corrupts another parameter, but that has happened. I expect that the block objects that I use will not interfere with the individual objects either. I mean, there are a lot of considerations when you're dealing with a non-SEP standard. Include language that requires that the interface be implemented using the standardized dialogs and associated objects in order to be conformant in the case of the SEP standards. And as I indicated in the bullet point above, that's your job. You have to prepare all those when in fact there is no SEP content. And you should provide at least an overview of the testing program that will be required to verify conformance.

There is actually another course in this that will in fact show you that and give you the details on how you can put together your training program. In the case of the 1203 standard, there is already a whole set of test procedures that have been included in there. I have a couple of warnings here that I think you need to be very careful of. And it's that, number one, the standards are not perfect, and the standards may undergo some changes as technology and new functions are requested. The example I used used flashing yellow arrow. I'm sure there'll be other examples in some of the other devices. A flashing yellow arrow is a relatively new feature. People today are implementing it with all sorts of weird parameters, none of which are in the 1202 standard, and so we don't have any hope of interoperability in how you're specifying that. It affects both the conflict monitor malfunction monitor unit as well as how you configure and program an overlap. In some cases, it's being done. Right now things will happen. The NTCIP working group will have to jump on that and get it squared away so we clean that up. Extending the standard is acceptable, but, you know, "acceptable"-- it will be non-conformant but must be well-documented and follow the prescribed procedures. Any extensions like this will render the implementation non-interoperable.

Your only hope is that by documenting the need that you were trying to serve, the requirements for that need, the full function the object or objects are trying to support, and the dialog for the exchange of the support and how those objects interact with the other objects in the NTCIP standards, then in fact other vendors can build to that standard. If you're not going to do that and follow through on it, then essentially it's a sole-source procurement, and you should be prepared to justify it in some manner. And your central systems won't be able to talk to it if the demand isn't at least made public. I mean, that's just a caution, that we've seen all these things being done in the world and under the name of NTCIP-compatible. There's no such term. Vendors may claim conformance to the standards but may not provide all the features and value ranges allowed in the standards, so you need to be careful. Be sure you specify them in your procurement document. And beware of cherry-picking from manufacturers' data sheets.

You know, you can wind up picking the best features or functions and extensions from every vendor out there, or nifty little additions, but when you're all said and done, you better have had a real good reason, because it's likely to either narrow your procurement to a single vendor, one or two vendors, or to drive the price up if no vendor has it and they all scramble to implement the particular feature or functionality. Second part to that, avoid specifying proprietary features. Obviously then it's not an open procurement. And avoid specifying proprietary objects. They both defeat the purpose of the standard. If your purpose was to develop a standards-based procurement, neither one of those belong in a standards-based procurement standard. Both will result in a non-standard, non-interoperable solution. If you must have a new feature, document it. I think we talked about that.

In summary, we looked at the development of a ConOps and what it should include. We looked at it in particular with respect to the devices, the device types, where we would place them and the features and functions that are likely to be required for the individual devices. That's the thing that drives what we need in the standards. Then we discussed the content of several of the standards, and they're all very similar, both SEP and non-SEP. And if you understand what you want the device to do, then you can use the standards to help you specify precisely what the interface of the data exchange is to support that standard or that procurement. We've discussed many of the broader issues when procuring interoperable systems in the last slide, and subsequent courses will in fact walk you through the process.

This class has been on acquiring standards-based ITS systems, has introduced the process, and the other standards will get into much more detail for the individual devices. So the final review-- let me see how many people can come up with the answer. See if anybody that's still on the line here can type faster than I can hit my mouse click in the chat box. The first step in the procurement process is the development of what? We should play the same music which we hear on-- what is it?-- Trebek uses on-- anybody going to attempt, or shall I just click and uncover this one? I guess I'll uncover this one. It's obviously the concept of operations, or ConOps. Using the ConOps, the next step in the procurement process is to document the functional requirements.

For the standards with the SEP content, the following then are used by the agency to select the elements of the standards. And they are, in the case of a TMDD, the needs to requirements matrix, or in the case of the NTCIP standards, the protocol requirements list. There's more. For the non-SEP standard, the first two steps are basically the same, the concept of operations and the functional requirements. But the burden for documenting the functionality to be supported, including dialogs, data elements, rests with the agency. Non-SEP standards typically include conformance groups, but the description of the functions is shown in the content of the data elements or references such other standards as TS2. That's sort of like what we've kind of come through. And the learning objectives-- at this point, I think we have addressed all of these issues at some level, and the details will come in the next round of courses.

Note that there are different paths for the SEP and the non-SEP standards, and it's very, very likely that your system will need both, because most systems today will include both dynamic message signs and some other device, such as traffic controllers or ramp meters and so forth. The curriculum path is shown here. I would encourage you to get with the SEP content. If you have the SEP content, then the next class is the A311A, user needs for DMS, A313A, user needs for ESS, and A321A, needs for the TMDD, all standards we've talked about. Well, we didn't talk about ESS, but this is also the first year of the training program. Additional A300 modules will be developed in the future. If you follow the non-SEP, boy is your job cut out for you, but we're going to have courses to help you out. The next module in the non-SEP class is actually the A202, identifying and writing user needs when ITS standards do not have the SEP content. And this is going to deal with guidance on how to identify user needs if they do not already exist and distinguish user needs from requirements. And, again, there will be additional courses for additional NTCIP 1200 series devices. And with that, I thank you very much. Do we have any questions that I can address at this time?

Now is the time you have to use your chat box. And the issue is "Yes, I'm thrilled and I'm prepared to deal with development of the procurement standards for non-SEP content starting tomorrow." I hope the class is-- it's been interesting for me. Again, we find the standards are mission-critical to our ability to deploy systems. It allows me to mix and match vendors. We've got mixes and matches for vendors all over the country for dynamic message signs and for actuated signal control and environmental sensor stations. Wherever the standards have been invoked, both here and internationally-- and they are. The NTCIP standards have been adopted by 13 other countries. The results of the implementation on specification of the standards has been a wider selection of devices, it's been lower-cost devices, and it's been a focus on features and functions or better quality rather than proprietary procurements and extensions of proprietary systems. Seeing no particular questions here, this concludes module A201.

I thank you for your participation.