Module 22 - A312a

A312a: Understanding User Needs for Transportation Sensor Systems (TSS) Based on NTCIP 1209 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.)

Nicola Tavares: Welcome to the ITS Standards Training. This course is sponsored by the US Department of Transportation ITS Professional Capacity Building Program. The ITS PCB Program is part of the Research and Innovative Technology Administration's ITS Joint Program Office. You can find information on additional modules and training programs on this website, www.its.dot.gov/pcb. Thank you for participating, and we hope you find this module helpful. This module is A312a, Understanding User Needs for Transportation Sensor Systems Based on NTCIP 1209 Standard. Throughout the presentation, this activity slide will appear, indicating there is a multiple choice pop quiz following this slide. The presentation lecture will pause at each quiz section to allow you to use your computer mouse to select your answer. There is only one correct answer. Selecting the Submit button will record your answer and the Clear button will remove your answer if you wish to select another answer. You will receive instant feedback on your answer choice. Please help us make more improvements to our training modules by completing the post course feedback form. Your instructor, Ralph Boaz, is a transportation engineering and marketing consultant. He was formerly vice president of Econolite Control Products and transportation section manager for Boaz Systems Engineering. He is a member of numerous ATC and NTCIP standard working groups. He is the chairman of the Transportation Sensor System Working Group for NTCIP. In 2002, he founded Pillar Consulting, Inc. where he assists companies and agencies in ITS planning, implementation, deployment, testing and training. The next voice you will hear, will be of your instructor.

Ralph Boaz: Hello, it's my pleasure to be your instructor today. The purpose of the module is to provide an introduction to NTCIP 1209 and to help users be able to specify systems and equipment that use NTCIP transportation sensor systems. This particular module will focus on user needs for such systems. Our target audience for the course are, traffic engineering staff, Traffic Management Center and operations staff, system developers and private and public sector users, including manufacturers. So we have a diverse group attending the course. Some of you may be just learning about the use of traffic control equipment, while others may be experts, just looking at communications capabilities provided by NTCIP. We will try to bring everyone along as we progress through the course, so that you have enough background information to understand what we're talking about. These are the recommended prerequisites for this course. The program-- the PCB program has different curriculum paths to help users with understanding ITS standards. I101 provides an overview in the use of ITS standards, A101 provides information on procurement strategies for standards compliant systems, A102 introduces how to identify user needs for systems, A201 is for selecting the appropriate standard for acquiring standards based systems, and C101 explains the NTCIP framework of protocols. Here we see a graphic representation of what we just discussed, but it also shows-- and you'll see our course A312a, in the bottom left. It also shows the course that will follow this course, which is A312b, which will focus on the requirements for traffic sensor systems, based on NTCIP. So these are the learning objectives for our course today, review the structure of the NTCIP 1209 standard, and here we'll talk about the purpose of the standard, identify the components and structure of the standard, and discuss how the standard fits into the system's life cycle. Secondly, we'll identify TSS user needs. There we will talk about the architecture of a transportation sensor system. I will define TSS terms and concepts. This will be our big learning part for some of you that are less equip or less familiar with the equipment, and we'll also then talk about the specific user needs and in NTCIP 1209, these are expressed as features. Third, we'll use the protocol requirements list or PRL, to select the user needs and link them to requirements. We'll explain the parts of the PRL, we'll talk about the use of the PRL as a tool for project specific implementations, and then we'll discuss how this tool can help reduce the risk of failure. Finally, our fourth objective will be to explain how the PRL table in the standard integrates into a specification. We'll discuss device specifications and agency procurements, and we'll also integrate the PRL, we'll show how to integrate the PRL into a specification. Here's our first learning objective. It is to review the structure of the 1209 standard. We'll discuss the purpose of the standard, you know, what is it used for, the structure of the standard, what's in it, and again, how the standard fits into the system's life cycle. We'll relate the use of the standard back to that Vee diagram you've seen previously in other modules as part of this program. So the purpose of the 1209 standard is to define NTCIP communications requirements and specifications which provide interoperability between a transportation sensor system and a management station. So now we've just discussed the purpose of the standard, now let's define what we are talking about. So this is the definition of a sensor system, or a sensor, or a traffic sensor. These are commonly interchanged terms. It's a physical device used for sensing traffic, and there's numerous types of technologies in use today and we'll talk about those later in this presentation. There's differing -- these differing technologies have advantages and disadvantages and that might depend on the road surface, weather conditions, the kind of maintenance required and other things. And in this presentation, we're talking about sensor, traffic sensor or sensor system, these are usually generic terms used in the industry when referring to an entire sensing device, and we'll talk about more specific terms later. This is a very high level graphic representation of a typical sensor deployment. We have a management station at some central location. You see that at the left. In the center, there's a transportation cabinet in the street that houses traffic control equipment in the field. And then in the upper right, we have traffic, which can be vehicles of any type, it could be cyclists, pedestrians, just about anything that's on the road and is needing detection. Okay, now there is, starting at the right, this arrow represents the numerous ways the sensors will detect traffic, and depending on the technology used, that information, or that technique or method of gathering it may be different. But ultimately this information is retrieved and sent to other devices within the transportation cabinet. Now if there is communication between a management station and a sensor, it is usually, or often accomplished using proprietary methods, and that's shown with the arrow on the left. Now let's talk about the elements of a sensor. Now these are logical elements and it's not intended to be a precise internal architecture. We have the sensor technology element, and that creates raw sensor data using a specific sensor technology. It might be monitoring electrical current on a wire, viewing-- or capturing pixels on a video frame, it might be the pulse of radar waves, it all depends on the technology. Next there's the processing element, and that turns the raw sensor data into usable output data. That might be the presence of a vehicle, the number of vehicles over a time period, it might be speed, or other traffic characteristics. And then it also performs all the other processing necessary to perform the detection in the field. Another element of the sensor is the internal cabinet communications. Now this type of communication actually depends on the cabinet architecture. There's various architectures out there, there's 332 type of cabinets, there's NEMA TS1 and NEMA TS2 cabinets, and there's the ITS cabinet. Those are the most common types of traffic control equipment. And this internal communications is typically either some sort of a discrete output to the controller or the controller is basically a traffic computer, or it may have some other communications serial or otherwise within the cabinet. The last element we're going to talk about is the remote communications element. Now today, this is always a proprietary communication being used. Now this might be a serial connection, it might be an Ethernet communications, and these communications are intended to go to the central system of the management station. So we have the sensor technology element, we have the processing element, we have the internal cabinet communications element and we have the remote communications element. These are the sensor technologies in use today. We have loops and this is a flexible kind of technology and satisfies a large variety of applications, it's mature, it's well understood, and has a large experience base, and provides basic traffic parameters, such as volume, presence, occupancy, speed, and others. Next is video, we often call this machine vision, and this allows you to monitor multiple lanes and multiple detection zones per a lane. It's easy to add and modify detection zones, and there's a rich array of data available. We have microwave radar. This is typically insensitive to inclement weather, at relatively short ranges, and it provides direct measurement of speed, and also allows multiple lane operation. Magnetometers, these are less susceptible than loops, to stresses in traffic. Again, it's insensitive to bad weather, such as snow, rain or fog, and there are some models that transmit data over a wireless radio link. Now I'm going to refer you to the student supplement, or participant supplement to take a look at these other technologies in use, acoustic, ultrasonic, infrared, laser, piezoelectric, pneumatic, light-sensitive and others, and our references at the end of the course, as well as the supplement, can help fill in those technologies and their benefits and their-- and challenges. So NTCIP supports all of the elements common to most of these technologies, and it has special objects can be used for inductive loops and video detection. Other specific technology data elements that are not specifically included in the NTCIP standard, can still use the data elements in the standard as they apply. Here we're looking at a couple of examples of the sensor technology elements. These pictures came from an intersection that's near my home. Note the camera at the left, it's looking down at the road for video detection, and the picture on the right, this is for inductive loops. You see the cut in the street where the loop wire was inserted into the ground. This is what we meant by the technology element. Here we're looking at the processing element. Now we show the inside of a transportation cabinet on the left. Now this is the 332 style, but it's just an example of a style of cabinet. We're going to be focusing in on, in this particular cabinet design, into this area and this is called the detector rack. And this is the location used to house the processing elements of a sensor system. To the right, we see a blow up of the detector rack, and we have two things highlighted. In the top part of the rack we have a loop detector, or inductive loop detector highlighted, and in the bottom part of the rack, we highlight a video image processor, which is used to process the data that comes from a video detection camera. So this is the processing element or an illustration of the processing elements used in a sensor system. Let's talk about the communications elements. Now this area that is highlighted is actually the back plane of the detector rack, and you notice there's an open space here. Now this kind of communication isn't covered by NTCIP 1209. There may be other methods in which the detector communicates to other portions of the cabinet, but again, this is a factor based on the kind of cabinet architecture that is used. Now on our video processor here, we see a serial connector that's highlighted, and in this case, on this particular processor, it's using a serial connection for remote communications. This is the ideal place for NTCIP 1209 to be applied. Now in more recent equipment, almost all manufacturers are making this kind of remote communication an Ethernet connection. Now we spoke about sensors and sensor technologies, let's look at the definition of a transportation sensor system. A transportation sensor system is defined as any system or device capable of sensing and communicating near real time traffic parameters using NTCIP. So it must be able to sense traffic but it also must be able to communicate using NTCIP. When we talk about near real time, we're talking about data that depicts an event as it existed at the current time, less the time it took to process that information. The data varies from true real time data, because it's dependent on the type and speed of the transmission. Still, at the rates that are available, this data is still usable for identifying changes in traffic flows. Now let's look at a TSS deployment. In this diagram we see a management station, that's at some central location in our agency. There is again, we have this cabinet as we described, in the street, and again, on the right, we have our traffic. This is the picture that we saw previously. The difference is, now is, we see we've created this communications defined by NTCIP 1209. And this allows the interoperability and interchangeability of the sensor equipment because we're using the standard. Now you won't always see a TSS when it is there. You're driving along, you don't see it. But if it's not properly configured, you'll feel its effects through higher congestion, more red lights, longer wait time, skipped traffic movements, and you'll know that, hey, wow, it would be nice if they would fix that, referring to your agency. But this is NTCIP allows a lot of power to run these systems from a central location. Let's clarify some technologies-- or terminology, especially since you've covered some-- a lot of system talk in terms, in other modules. A transportation sensor system is considered a field device, from an NTCIP perspective. It may be a relatively simple device, or a combination of devices working together, thus, that's where we got the term of sensor-- transportation sensor system. But we don't want to confuse a TSS with other systems that require center-to-center communications, so think about this as a device. Now we'll talk about the benefits of using the NTCIP 1209 standard. It identifies the operational user needs for traffic parameters within the system, volume, occupancy, etcetera. It also allowed in its development, it forced the parties involved, the stakeholders involved, to agree on what the scope was, or should be for such a system. Establishes a common understanding of the essential features for TSS equipment. People in the industry have different terms for the same thing, and if you're well involved, you can flip through the different names and people understand each other, but others don't have that background, and so it's important to have specific terms and use them specifically. And then it facilitates testing by providing clear and verifiable interface requirements and specifications. Other benefits, it promotes understanding of the standard, by providing traceability between the user needs, requirements and the detailed specifications. It gives you context and organization, and the thought process, as we said. It provides tools, which we call them tools, but they're really tables for users to include in their specifications that accurately define an NTCIP TSS interface. Specifically, these tools are the protocol requirements list, and the requirements traceability matrix. And finally, it facilitates compatibility, interoperability and interchangeability of TSS equipment between a center-to-field system, and we're going to review these terms in the following slides. This is the definition of compatibility. Equipment is compatible with each other as long as two pieces of equipment are compatible, as long as both can run or simply reside in a network environment without adversely affecting the behavior of the other. Here's a graphic illustration of compatibility. The traffic controller you see on the left, we see a dynamic message sign, and we see a video detection camera, all existing in the same NTCIP environment. They can all perform their tasks independently of each other, they're said to be compatible. We define interoperability here, that's the ability of two or more devices to exchange information, and the ability to use the information that has been exchanged. Here we see a graphical representation of what we just discussed. So there's an NTCIP communication between the management station on the left, and the TSS device, in this case, a video detection system on the right. What is sent as data object X from the management station and is received as data object X at the traffic sensor system. In this case, then, we say the management station and the TSS device are interoperable. And of course communications can go both ways. Now we'll talk about interchangeability. In interchangeability, we need to have the same functional and physical characteristics so that there is equivalent performance and durability. Now this is a bit subjective, because vendors may argue about their performance and durability. Some points may be valid. A valid point might be that one detector is found to be more accurate over a period of time. Another may be that one detector or another may require less maintenance. Secondly, it's the ability to exchange devices of the same type without alteration of the device, or adjoining systems. In other words, we're not changing the central management software, we don't have to do any changes there, when we replace the equipment out in the field. Now it's okay to have to configure the device or tune the device that we put in there, but it's, again, the point here is that we are being able to exchange that information out in the field, or exchange those devices out in the field. Here is our graphic illustration of interchangeability. We see the TSS equipment, the video detection cameras on the right, they're from different vendors and we can, when there's problems with one detection system, we can replace it with another.

Ralph Boaz: Okay, now we're talking about the structure of the 1209 standard in the general section, this has information such as scope, references and definitions. In Section 2, the ConOps, this describes the system from the user's operational perspective, and this is where we find user needs and listed as features in the case of 1209, and we'll discuss this more in learning objective two. We have functional requirements in Section 3, and these are requirements for the interface, covered by the 1209 standard, and they're derived from user needs for the system discussed in the ConOps. They're expressed in the shell statements and also included in this section is the protocol requirements list, or PRL. We'll discuss this further in learning objectives three and four, and go into detail about it in module 312b. Section 4 has dialogs that describe the exchange of messages required to accomplish the functional requirements. We'll discuss this further in module A312b, and then in section five, we have the Management Information Base, or MIB. That contains the object definitions or also called data elements used in interfacing the TSS to a management station, and again, we'll discuss that further in module A312b. Continuing, we have Annex A, which has the requirements traceability Matrix, or RTM. Here we trace the requirements to the design details of the interface. Again, we'll discuss this further in module 312b, and by the way, the title of that is, Specifying Requirements for Transportation Sensor Systems Based on NTCIP 1209. Annex B is an object tree, and that's just the upper level hierarchical block diagram of the objects in the MIB. You have Annex C, for test procedures. There are currently no formal test procedures included in the standard, but we have left this place here, sort of as a placeholder for the future. And then in Annex B, we have the document revisions, you can see the different things that were done in various revisions of the document. Let's look at the history of NTCIP 1209. Version One was oriented towards inductive root technology. The entire standard was kind of formed that way, and it did not contain systems engineering information. In Version Two, we added the systems engineering information, and did a lot of the things that we talked about previously, scope and language and such. We organized the standard around those features, around the features that we developed, and we put in options for selecting requirements for specific technologies, such as inductive loop and machine vision, and we have a structure that will allow others to be added in the future. And that's exactly what I just said at this last point. There's the idea was that the standard could still be used for other technologies as is, but users may want to add technology specific information and we have kind of a structure that supports that.

Ralph Boaz: Now we'll talk about how NTCIP 1209, Version Two, fits into the systems life cycle. As we said, a systems engineering process, or SEP was used in the development of the standard. Systems engineering information is included in the standard's content, and this helps ensure that the standard is complete and correct. And by complete, we mean that all the user needs listed in the standard are addressed by requirements and by correct, we mean that the requirements accurately describe the functionality that should be delivered. And then finally, we talk here about, it provides the users with the thought process of the standard's development. I guess we have some other points here to make about this. The use of NTCIP standards usually starts in the design phases of system development. When we're building a central system, the system's specifications don't get to the level of detail that we're talking about in the standards. So we say it's-- you know, part of the subsystem interfaces, IEEE standards 830, and others. You can find this referenced at the end of this presentation and in the student supplement. They have good outlines for possibly basing an agency specification or product specification out of it. And then we were talking about, helps identify user needs and requirements, we were talking about doing that for your own specifications and other documents that reference the standards. So the idea is, the standard provides this information, and then users can take that information and tailor it for their own software requirements, specs or product specs or interface control documents. Recall the system's Vee lifecycle, from a systems perspective, the standard would be used in the high level design and detail design, and so we sort of call this the little Vee of the system. See that here. This is where designers and implementers and testers of the subsystems and their interfaces, would primarily use the system, or use the standard.

Ralph Boaz: Okay, we're to our activity. Recall that we spoke about what a sensor was generically, we spoke about the logical elements of a sensor, and we defined a sensor system that uses NTCIP. Let's go to a couple of quiz questions.

Ralph Boaz: Choose the best answer for this. A, blank, is defined as any system or device capable of sensing and communicating, blank, real-time traffic parameters using, blank. Your answer choices are, a) detector; fast; Ethernet, b) controller; conformant; NTCIP, c) NTCIP; conformant; Ethernet, or d) TSS; near; NTCIP. Please make your selection.

Ralph Boaz: All right, let's review the answers. The correct answer was d) TSS; near; and NTCIP. TSS is defined as any system or device capable of sensing and communicating near real-time traffic parameters using NTCIP. If you said a), that was incorrect, because Ethernet is not the only communications medium that can be used for a TSS. If you said b), that was incorrect, because the controller doesn't do sensing, but it does use the sensor information, or provide that sensor information to a central computer. And c), this was incorrect. NTCIP is a protocol, not a system or a device.

Ralph Boaz: Here we have another question. What is the role of the processing element of a TSS? Please select the best answer from this, a) creates raw sensor data using a specific sensor technology, b) it turns the raw sensor data into usable output data, c) it transfers output data to other devices or systems internal to the field cabinet, or d) it transfers output data to other devices or systems external to the field cabinet. Please make your selection.

Ralph Boaz: Let's review our answers. The correct answer was b), it turns raw sensor data into usable output data. This is the role of the processing element. If you said, a), this was incorrect because using a specific sensor technology is the role of the sensor technology element. If you said it transfers the output data to other devices within the cabinet, this answer, c), was incorrect, because that's the role of the internal communications element. If you said, d), that it transfers data external to the cabinet, this was incorrect because this is the role of the remote communications element. So again, it's the role of the processing element to turn raw sensor data into usable output data. Let's summarize what we learned in this learning objective. We reviewed the structure of the NTCIP 1209 standard, we looked at the purpose of the standard, we discussed interoperability and interchangeability of the TSS equipment, we looked at the components and structure of the standard, had a general section ConOps requirements which included the protocol requirements list, had a dialog section and objects definitions, and then we looked at how the standard fits into the system's life cycle, that it was a part of the subsystem design stages and it pertained to interfaces.

Ralph Boaz: Now we're going to be discussing learning objective two. We just reviewed the structure of the NTCIP standard and now we're going to identify TSS user needs. We'll discuss the architecture of a TSS and we'll contrast that with the traditional sensor architectures. We'll define TSS terms and concepts, and we'll discuss user needs and user needs in this standard are expressed as features. This graphic represents a traditional detection architecture. You see a management station on the upper left, you see a traffic controller connected to loop detectors at the bottom here, and then we have illustration of a roadway on the right. Now this equipment down here at the bottom, the traffic controllers and the detectors, that's the kind of equipment that would be found in the traffic control cabinet that we showed in previous diagrams. So let's start at the right here, as we discuss this picture further. The wires in the street, called loops, define detection zones. The detectors in a field cabinet monitor the inductance of electricity on the wire. When a dense metal object, such as a car passes over the loop, it causes a change of inductance and this change is then forwarded to the controller, that there's a vehicle that needs service. Again, these loops are mapped to the turning movements in the street. Now if there is communication from a central system to the controller, there's only a limited amount of sensor data that's available, typically. And a configuration of the sensor itself is not possible. This is the traditional detection architecture. Looking at the traditional architecture from a systems perspective, there are agencies that do want to be able to communicate directly with their sensor systems, but there's a problem. Sensor manufacturers that provide this capability for their detection systems use separate application software, and have proprietary communication protocols, and that ends up being extra applications running at your central system. Now let's just contrast what we've just seen with the architecture defined in NTCIP 1209. Recall the definition of a TSS is any system or device capable of sensing and communicating near real-time traffic parameters. Well in this architecture, any detection technology can be used, as long as it conforms to the NTCIP 1209 standard, and that's why we represent this with these solid lines. The top picture shows a traffic controller that uses loop sensors. In this case, the combination of the controller and the sensors act as a central TSS providing the NTCIP 1209 communications. Also shown here is a video detection camera, and as we discussed earlier, there are many other technologies in use today. Any technology can be considered a TSS device as long as center-to-field communication adheres to the NTCIP 1209 standard. So this illustrates what NTCIP can do for you. We see a center-to-field system, and a single application that can be used to operate the various types of TSS devices and brands. Here you see a traffic controller with loop detectors, you see a couple of camera systems here, and you also see a microwave radar system. In the next ten slides or so, we'll be defining some terms and operational concepts for a TSS. Now let's talk about a zone. A zone, this is similar to a physical zone, defined by a loop, but better. It's an area in which traffic parameters can be measured, or traffic data can be gathered-- or generated. These are just a couple of examples of zone configurations. They may be at an intersection, as shown on the right, or at the bottom here, they may be zones across an interstate highway. Again, it's an area in which traffic parameters can be measured or traffic data can be generated. Here's some other terms. We have a sample, and that's a collection of sensor data for a zone, over a known time period. We have sample period, and that's a duration of time in seconds, when data for the zone is being collected, and then we have class. Now this is the technical definition. It's a subdivision of historical sample data. Now what we're really talking about here is that a class is typically just one of the more classification of vehicles defined by the FHWA. We're talking about things such as motorcycles, passenger cars, two axel vehicles, four axel vehicles, etcetera. You can see the student supplement for the official 13 classes of vehicles, and another point here is when we talk about, throughout the standard, we talk about historical sample data, we're really not talking about days, weeks, months or years, we're talking about seconds, minutes or hours. Maybe a better word would have been stored sample data, but this is what's in the standard. An output or a zone output, that's the condition of the on-off status for a zone and it's generated by a change of state. We use the word, delay, that's a feature that allows a zone output to be deferred for a user set period of time, and by extension, we mean a feature that allows a zone output from a TSS detector to be lengthened for a user set period of time. So now we'll talk about output after delay, or just delay, which we just defined. So here we have our road, this is an intersection, and you can imagine a road going north-south, to the left of this illustration. So you'll note that we have a left-- we have two lanes that-- we have a lane here in the middle, that appears to be a through lane, we have a left turn pocket, as they say, and it has a couple of zones in it. And then this right lane is a right turn lane. And in it we have our Zone 1. We say Zone 1 is on, only if a vehicle is present. Now this is user settable for a time greater or equal to four seconds. What this does, it allows right turners to roll over the zone without triggering a signal, but it provides right turners a signal call if they're sitting there for beyond the period of time. And you can see and imagine the desirable effects. You don't want to be triggering-- if we have just right turners, turning right, we don't want to keep interrupting the flow from our street going north to south. Okay, output with extension. So in this case, we want to extend the period of time that a zone is on. So output, and we're looking at Zone 2 here, is on for an additional three seconds after a vehicle is no longer present. Again, that is a user selectable or settable time period, and in this case, it increases the opportunities for the straight through movement going east to west, without changing the signal timing plan, so you don't have to change the timing plan, the detector will just continue to show an on condition after the vehicle has passed over it. We just described outputs, delays and extension, and we have some other terms for you. We have a virtual zone. This is a logical combination of one or more zones, to create a new zone with its own conditioning, I'll describe that in a minute, and arming enables. You think of an arming enables as configuring the zone when the conditioning should apply. So let's talk about what conditioning is. That's when a zone uses logical ANDing, ORing or SEQing of outputs of other zones, and-or external arming inputs and arming pins, which we'll describe in a few slides, to activate its own delay, extend or output. So this conditioning and this virtual zone concept allows this connection of zones, it's a virtual connection of zones that can be put together and have special criteria when a single virtual zone will be activated. So the arming inputs and arming input pins we talk about here, in conditioning, that tells the zone, yes, it's time to apply it. So that's what arming means in this case. So let's discuss a zone and virtual zones and this logic. Here we see another intersection, and we have this intersection coming in from the east to west, but we've also added in a-- looks like, what is a freeway off ramp that comes also to the same stop bar as the rest of the street. And we see that there, the zones, 1 through 7, in the various lanes of this intersection. Now what we have is, we can create other zones out of these zones that are already identified. So we have a virtual zone 10 that's made up of an OR, an OR condition if you will, of Zone 1, and Zone 2. And this makes sense, because both of these zones, Zone 1 and Zone 2, are covering a through movement, basically the same movement of traffic in the street. You might, as we discussed earlier, want to have a one second or two second delay here on Zone 1, but that wasn't necessary for this illustration. Zone 11 is what we call a queue detector, or queue detection, and that's by ANDing Zones 3 and 4. So we may want to put a five second delay or some seconds of delay on Zone 4, to make sure that a car is not just passing over it, but is actually sitting there, and when we do that, and Zone 4 is active, then we can say Zone 11 will be active when both of these, Zone 3, and Zone 4 are active, and that can indicate that there's a large queue and the controller might want to extend its left turn arrow. Zone 12 in our illustration here, is used to activate a wrong way detection sign. Remember, I talked about this being an off ramp to a freeway. Well it's the kind of geometry of this road here-- roadway, we can see somebody might mistakenly come in the wrong direction onto this freeway ramp, and in this case, we're saying this is a-- Zone 12 is a sequence of Zone 6 and Zone 7. So if something rolls over Zone 6, and then Zone 7, it will activate this wrong way sign. Okay, now we'll get to the-- this is probably the toughest part of this whole course right here, is just to understand these points, and we're going to go through what we mean by Arming Enable, Arming Inputs and Arming Pin. Now we're going to start at the bottom. An arming pin is a physical input to the TSS that can be monitored and used to modify its operation, that is the TSS' operation. Now this comes from loop detectors, because there are times when you only want a particular loop detector activated, so there was actually a physical pin that runs into a loop detector that may be turned on by the traffic control equipment, and say, okay, now I want you to operate, and when that signal is not there, it might say, no, we don't want you to operate right now. So it's a physical-- that's an arming pin. But now, since we're talking about messages in a communications protocol, we can talk about-- we need to talk about messages. So this where we get Arming Input Bits, and that's an external event that is reported to a TSS using the NTCIP protocol and it's used to modify the operations. So your pins which are physical pins and bits that are part of this input bit message. And then finally at the top here we have Arming Enable. This is used to set the selected state of the arming input bit or pin of the TSS that is to be used to modify the zone operation. So the arming enabled is the way that you set up the input bits and input pins of the TSS.

Ralph Boaz: So now we'll go through an illustration of that. So, on the left we see the management station and on the right we see a TSS system or TSS device that has delays and extensions and under output conditioning applied to different zones. It's monitoring these zones, zone one, two, and three. So there is an arming enable message that assigned the pins and the input bits to zones.

Ralph Boaz: Here then what happens is an arming input bits message may come in or there may be physical pins that came from the traffic control equipment, that might come in. And then these zones delays, extends, and other output conditioning would be applied according to how it was set up in the arming enables message and that would influence how the output has come out from the TSS device. This is the toughest part, this is the deepest part. If you get this you should be able to get the rest of it.

Ralph Boaz: Okay. Now we're going to talk about the operations of TSS devices. They are organized into four areas in the standard. Want to be able to configure, that sets up the TSS. We want to be able to control, that modifies its operation. We want to be able to monitor, that verifies the operation, and we want to be able to collect data. And of course as we said this is near real-time data in this case. We'll now go through each of the features of these in the upcoming slides.

Ralph Boaz: So features for configuring TSS devices. Now throughout these slides the numbers on the left are actual paragraph numbers or section numbers I should say in the TSS standard. The items on the right in parenthesis, this is what we call the conformance. Now conformance in the simplest case is either mandatory which means that the feature must be supported to be conformant to the 1209 standard or it might be optional or "O" which means that the conformant may or may not support the feature and it still can be conformant to the standard. And there are other options here or other items that will show up here and we'll discuss them when we hit them

Ralph Boaz: So this first feature is determine the TSS identity. It's used to determine the basic information about the TSS. It includes sensor technology, manufacturer, model, firmware version, hardware version, protocol, what standards version this TSS device adheres to. This is basically identifying the TSS. Second one listed here is determine the TSS capabilities. We want to be able to determine, configure, and manage the TSS so we need to find out what's its maximum number of zones, its number of historical data entries per zone, its maximum number of sample periods per zone and other information.

Ralph Boaz: Other items as part of configuring a TSS, we want to determine a sequence of sample periods, and this is used to determine the sequence of sample periods so that aggregate data can be used to identify changes in traffic. So what we're doing here is we're saying okay, how do we want to collect data? And we say that in this case, it has a conformance of sample M. This is called an option group. And this option group means that if the TSS device supports sampling, collecting of this data, then it is mandatory. That's what the "M" indicates in this case. Another feature for configuring the TSS is to determine the age of sample data, again, it is part of this sample option group and this is used to determine the age of the sample period data so that the relevance of the data to current traffic conditions can be determined

Ralph Boaz: There are some other features for configuring in TSS. We want to be able to configure the zones. And that's used to configure the sample period, the zone label, number of classes, combination of the zones, sequences and other zone parameters. And then this area also includes the special operational parameters for specific TSS technologies and we talk about that in this case the inductive loops and video detection. Another feature for configuring a TSS is configuring arming enables. Now we say this is part of the timing group, and it's optional. So a TSS would not have to have this capability even if it had this timing group, if it was part of this timing group it would still be an optional feature and this is used to configure the arming enables that are used to modify the zone output delay and extension time.

Ralph Boaz: Another feature is to configure outputs. Again this is mandatory. It's used to configure the outputs to report the state of the zone. Includes assigning, the output to the zone, conditioning, the outputs and assigning a fail-safe and fail-secure mode of operation. There are other things in there also. And then we have managing pending configuration file name. Now different technologies and different types of equipment will have maybe some large configuration files, for instance there might be in a video detection system there may be the background field of view that is stored on the camera or the camera system and so we needed a way to move large files and to be able to halt operation of the controller while it's happening so we have this feature called manage pending configuration file name and this is used to transfer, validate, and execute a configuration file.

Ralph Boaz: Just to illustrate that these features can be then decomposed into subfeatures, we're going to go through these subfeatures for determining the TSS capabilities. So here we have determine TSS support for sampling. This is used to determine that the TSS device does do sampling. We have determine the TSS support for timing. And we want to know if the TSS has timing functions. Now both of these you'll note they have a mandatory conformance because whether it supports sampling or whether it supports timing isn't the question we're asking here. We want to find out what is its capabilities.

Ralph Boaz: Here are some others. Determine the TSS support for speed, and then we have determine the TSS support for real-time clock and we're talking about that when we talk about this, we're talking about the support for a TSS to be able to provide actual local time.

Ralph Boaz: And now we have another quiz question for you.

Ralph Boaz: Which one of the following choices is NOT considered a capability for the TSS? Is it A, sampling, B, timing, C, location, or D, speed? Please make your selection…

Ralph Boaz: Okay let's take a look at our answers.

Ralph Boaz: If you said C, location, this is correct. Because providing location information is not considered a capability of the TSS at this time. If you said A, sampling, that's incorrect because sampling is a capability. We can say the same thing for B, timing, this is incorrect because timing is a capability of a TSS.

Ralph Boaz: Remember that timing is the ability for users to modify these zones through timing parameters.

Ralph Boaz: If you said D, speed, this is incorrect. It's a capability and that is to determine the vehicle's speed and store it for retrieval. That's a capability of a TSS.

Ralph Boaz: So to refresh your memory then, so the capability of the TSS are sampling, timing, speed, and real-time clock

Ralph Boaz: Now we spoke about configuring a TSS. Now we're going to talk about features for controlling TSS devices. There's a feature to reset the TSS and that is to set the TSS to a known condition such that you are needing to restart or reinitialize or retune the device. It can cause the TSS to abort or to execute abort of validate a pending configuration file name.

Ralph Boaz: Another feature here is initiate sensor diagnostics. This is used to initiate obviously start up sensor diagnostic routines that are existing on the TSS device. And then there's the ability to synchronize the TSS and that's setting a baseline reference for the sampling period. Synchronization of time reference is not a reset of the TSS as we discussed in the first capability.

Ralph Boaz: Other features for controlling the TSS devices is update arming inputs of the TSS. This is part of our timing option group and that is used to update the status of the arming input bits of the TSS. Now we get into our device type or technology specific things like managing the camera. This is video so if you had video you wanted video supported you would be part of this video option group and this would be a mandatory feature. And this is used to enable or disable detection for a particular camera location. It's used to verify that a camera is working, determine number of cameras, video formats. It can command a camera to build an image file and transfer it to the manifestation.

Ralph Boaz: Manage the real-time clock. If you have this real-time clock capability, then this would be a required feature. This is providing a time stamp for sample data. And the clock should be able to support Daylight Saving Time adjustments.

Ralph Boaz: Okay now let's go to another quiz question. We just went through the features for controlling TSS devices. Which of the following control features allows a TSS to be set to a known condition? A, is it synchronize the TSS, B, initiate sensor diagnostics, C, reset the TSS, or D, update arming inputs of the TSS? Please make your selection.

Ralph Boaz: Let's check our answers.

Ralph Boaz: If you said C, reset the TSS this is correct because that's exactly what it does, it allows the TSS to be set to a known condition. If you said A, this is incorrect because recall this sets the baseline reference for the sampling period. Synchronizing of the TSS is a time thing. If you said B, initiate sensor diagnostics, that was incorrect because that allows an operator to initiate sensor diagnostic routines. And if you said D, update arming input bits of the TSS this is incorrect because this is used to activate the conditioning on a TSS.

Ralph Boaz: So reset the TSS allows the TSS to be set to a known condition.

Ralph Boaz: Okay and we spoke about features to configure and control a TSS. Now we're going to talk about features to monitor TSS devices. So we have the monitor system status and that's used to monitor the status of the TSS such that the management station can identify that the system is operating normally and we have monitor the TSS sensor status, right? We talk about the system as a whole. Now we're talking about the sensor and this is used to monitor the status of each sensor within the TSS.

Ralph Boaz: Other monitoring features are we want to be able to monitor the output states and that of course that's what this is all about. We want to be able to retrieve the states of the outputs of the TSS of all the zones. And then also we want to be able to monitor the zone status, how is each zone operating?

Ralph Boaz: Okay we have some questions now on monitoring. Which of the following monitoring features lets a system or user know that there is a loss of contrast on a video detection camera? A, is it monitor system status, B, monitor TSS sensor Status, C, monitor output states, or D, monitor zone status? Review carefully the opening question. Please make your answer.

Ralph Boaz: Okay let's review our answers. If you said B, monitor TSS sensor status, you had the correct answer. This is used to detect a problem with the sensor portion of the TSS device. Now if you said A, monitor system status, that was incorrect. Now this may be used to detect a general problem on the TSS device, but that won't tell you that there's a problem with the camera itself so it was a little bit of a tricky question there. If you said C, monitor output states, that's incorrect because this is used to retrieve the states of multiple outputs of the TSS device. And then monitor zone status, this is used to retrieve the status of the zones. So monitor TSS sensor status lets a system or user know that there is a loss of contrast on a video detection camera. And this is just one of the examples of technologies that could be available.

Ralph Boaz: Okay we looked at the features for configuring, controlling, and then monitoring the TSS. And now we'll look at the features for collecting data from the TSS devices.

Ralph Boaz: First of all here is retrieve in-progress sample data. And to use this feature we would need to say that yes, our TSS device supports sampling and also it supports speed. I'm sorry that's incorrect. It's that if our device supports sampling or if our device supports speed, then we would need to use this feature.

Ralph Boaz: So this is used to obtain the data from the in-progress that that has started but not completed sample period. Includes things like length of the elapsed time of the reported sample period, volume occupancy, etcetera. So we have also retrieve current sample data. And this is used to obtain data from the last complete current sample period. It includes when the sample period ended, volume, occupancy, speed, zone, etcetera.

Ralph Boaz: Retrieve historical sample data. Now this is used to retrieve sample data that has occurred in the past in previous sample periods. Again by historical in this standard referring to seconds and minutes and hours, that kind of time period, not some sort of archive of data.

Ralph Boaz: Okay now we have questions about collecting data from the TSS. Which of the following collecting features identifies the user need to retrieve yearly average volume data from a TSS? I'm going to read that again. Which of the following collecting features identifies the user need to retrieve yearly average volume data from a TSS? Is it A, retrieve in-progress sample data, B, retrieve current sample data, C, retrieve historical sample data, or D, none of the above? Make your selection.

Ralph Boaz: If you said D, none of the above, that was the correct answer. The TSS device is not required to store data for long periods of time. So if you said A, retrieve in-progress sample data, this was incorrect because this is to retrieve data that has been started but not completed in the sample period. If you said B, this was incorrect because this was used to obtain the data from the current sample period, current I should say completed sample period. If you said C, retrieve historical sample data, this is used to retrieve historical or past sample data from other sample periods and again we're talking about seconds or minutes or hours.

Ralph Boaz: Let's just summarize what we learned in this learning objective which was identify TSS user needs. We talked about the architecture of a TSS. We contrasted the TSS architecture with traditional architectures. We defined the TSS terms and concepts. And then we looked at the user needs expressed as features of the TSS described in NTCIP 1209.

Ralph Boaz: Okay now that we've reviewed the structure of the NTCIP 1209 standard and we have identified the TSS specific user needs, now we're going to use the protocol requirements list or PRL to select user needs and link them to requirements. So in this learning objective we'll understand the parts of the PRL. We'll step through the table, we'll use the PRL as a tool for project-specific implementation which is what we call tailoring the PRL. And then we'll show how the PRL helps us reduce the risk of failure and have interoperable and interchangeable TSS equipment.

Ralph Boaz: Okay the protocol requirements list is a table provided in the standard that is used by specification of writers. So the standard is not to be taken as a whole and referenced as a whole by a specification or agency. The PRL shows the relationship of user needs or features to the functional requirements and the rules for conformance to the standards, how those requirements are to be used, grouped, etcetera. So specifications writers tailor as I said the PRL according to their particular system needs, or equipment needs in this case. And not all user needs and requirements are necessary or even possible in a given deployment. For instance how could a loop detector have requirements for things that are in a camera sensor system? When a deployment satisfies the requirements in the specification, which is conformant the specification conforms to the standard, if the deployment satisfies the specification it is said to be compliant to the specification. So when we talk about conformance to the standard, we talk about compliance to a specification.

Ralph Boaz: This is an example of the PRL table from the TSS standard or NTCIP 1209 standard. And it's a tool again that allows those seeking to use NTCIP to identify user needs and specify the appropriate requirements so that we get interoperable and interchangeable systems.

Ralph Boaz: So this first column is the user needs section number. This column lists the number that is directly in the standards so you can know where this particular user need or feature is in the standard and go look up its precise definition. And we have the user need name and you'll note that it spans across the table a little bit and what it does is it covers- it shows the coverage of this user need by this list of requirements underneath it.

Ralph Boaz: Let's look at the next column. This is the functional requirement section number and just like the user needs section number this goes to a specific place in the standard where you can look up the definition of a functional requirement…

Ralph Boaz: So here is a list of the functional requirements column. That's used to list the names of the functional requirements. And when we say functional requirements in the standard, we're talking about the functional requirements for the communications interface.

Ralph Boaz: The next column is conformance. And this is how someone who is writing a specification knows can determine what needs to be included in their spec. So here you can have in this case we have just simple conformance such as the mandatory or optional. You see get output sensor zone, output failsafe mode, output mode status. Those are all mandatory. They have to be included. And then we see that output label is optional. Next column is support or project requirement. So if the conformance is mandatory there the only answer to whether the project will support it or require it will be yes. If you look down at output label where we had the conformance as being optional then whether the project supports it or not or the specification supports it or not is a yes/no decision. And here we have the additional specifications column and this allows for tailoring of the standards such as subranging possible values. Sometimes in the standards we have a large number of values for instance of a particular parameter, but in an actual deployment a customer doesn't want to allow maybe certain larger time periods for instance. They may want to restrict the range on that. And this is to be discussed further in module A312b.

Ralph Boaz: Okay let's talk a little bit about the use of conformance status and predicates for specific implementations. So we already talked about mandatory being "M" and optional being "O" and then we talked about previously you saw examples such as loop or video or some other options where we had an option group followed by a number and what this is that the "O" will represent the option group, and then the number, the dot-number is which option group it refers to. If a requirement is associated with a particular option group, then all the requirements in the standard that are associated with that option group much also be supported. NA means it's not applicable, it's either logically impossible in the scope of the standard.

Ralph Boaz: Here are some of the predicates that are available in NTCIP 1209. There's loop and that refers to inductive loops and you can see the section here in this table you see the section where you can look up the definition of these things. Video or machine vision, we have real time clock, RTC indicates that item applies to real time clocks. Speed, this indicates that the item applies to speed. Timing, obviously this means that the PRL item applies to the timing group. Also we have the sample group which is very important to people who use this equipment. And then we have something called version1. In order to support backward compatibility or multi-version interoperability is another way of saying that, we created this predicate and if the specifer says version1 then this indicates that the data elements that were in version1 should be used for the specification…

Ralph Boaz: Now we'll talk about using this conformance status and predicates for a specific implementation. So we have this- we have let's say our system is going to include video detection equipment, so here we have identified the conformance and project support requirements columns. So in this column the optional .2 requirements are required and we might not require some of the others so let's go through this. So manage the camera. Since we are doing video it's a mandatory so yes, the video predicate is specified. That means we need to pay attention to all conformance items or conformance specifications that mention video. We looked at the next one. Set disable detections look at the requirement. We said okay this is video but it's optional. But in this case we said no, we're not going to include that. And the same thing for get disable detection. We said no, we don't want to include that either. And then we had the set build image parameter. Again, this is a video, it's optional, but it's part of this conformance group and we said yes we want to include it in our specification. And then finally here we have set cancel build in progress and again this is part of the option group two for video and we said yes, we want to include it.

Ralph Boaz: Sorry, talk about reducing the risk of failure. The PRL allows the specification writers to only include the requirements applicable to their system. This helps you not have superfluous acquirements that could cloud the system development or acceptance. But you have to be careful that you don't cause unnecessary restrictions and specify a good vendor out. The PRL could be used as a checklist to explicitly point out whether the product meets user needs or requirements. Future purchases of other vendors can be compared and using only requirements to be included in the standard reduces risk.

Ralph Boaz: So now let's go to another quiz question. The PRL is a good tool to blank. Please make your selection. A, tailor an NTCIP specification for a particular TSS technology, B, learn the science used in sensor technologies, C, specify Ethernet communications, or D, force TSS providers to support all requirements in the standard? Please make your selection.

Ralph Boaz: Let's review our answers. If you said A, tailor an NTCIP specification for a particular TSS technology this is correct. Different technologies can be included or excluded using predicates and user selections. If you said learn the science used in sensor technologies this is incorrect, because 1209 addresses the configuration and communications interface only and there are other texts and articles and books etcetera that can be used to learn about the TSS about sensor technologies that are used in TSS devices. If you said C, specify Ethernet communications, this is incorrect because the PRL is used for specifying the interface requirements for the field device, not for the media that carries it. NTCIP will work under Ethernet, serial communications and others. So then we talk about D, if you answered D this was incorrect; Force TSS providers to support all requirements in the standard. Again, this is not reasonable for a TSS to adhere to all requirements. For instance you may have an inductive loop not have requirements of a magnetometer or not have the requirements of a camera system or radar, etcetera.

Ralph Boaz: So let's summarize our learning objective #3 which was to use the protocol requirements list to select user needs and link to requirements. We looked at the table and understood the parts of the PRL. We used the PRL to specify project-specific implementations, and we looked at using the PRL for reducing the risk of failure.

Ralph Boaz: Learning objective #4. Now we spoke about reviewing the structure of the NTCIP standard and identifying specific user needs and also we discussed using the PRL to select user needs and link to requirements. In this learning objective we're going to explain how the PRL table in the standard integrates into a specification. We'll look at device specification's and agency procurements and we'll look at how to integrate the PRL.

Ralph Boaz: The specifications and procurements. Agency specifications are based on how the agency purchased the equipment so if it's purchasing a system it may have one form, but if it's purchasing other device such as a traffic controller or sensor equipment it may have different specifications for it. TSS devices are often bought by contractors in response to construction bids so you don’t have a big system deployment that works all the way from the top down. Contractors are just responding to a construction bid. So what happens is agencies create standing specifications for their own protection so that there is a standard in which the contractors have to bid. And agencies might have a prequalified vendors list or may have a single vendor selected through a bid process that they can use for a period of time.

Ralph Boaz: The types of requirements that are in an agency device specification cover a lot of ground. The types of requirements would be hardware requirements which are mechanical, electrical, or structural. There might be functional requirements, what the device should do. There might be performance requirements how well it should do it. There might be under environmental requirements, what temperatures it should be able to operate with or other environmental requirements. There are interface requirements and that's all of the interfaces of the device. There might be maintenance requirements such as what is the serviceability of the device? There might be procurement requirements and these might be manuals, lock sizes, special packaging, container labeling, how should the equipment be shipped for instance? There are usually warranty requirements and wants to be covered up by the vendor and the duration of the coverage. And there might be other types of or divisions and requirements that we haven't listed here.

Ralph Boaz: We are going to talk here about drawing information from the standard into a specification. So we stated earlier that the standard is usually used in the design stages of the systems although rare if a system spec is detailed enough there may be an opportunity to draw this information all the way into a systems specification. Alternatively agencies may produce a standing spec specifically for a sensor device so they can prequalify equipment and know that it will be interoperable with their system.

Ralph Boaz: Here we show how the users may borrow information from the standard to create their agency spec. On the left we have a possible outline for specification and practice. Each agency will have their own arrangement and content. Under the requirement section we have arranged the requirements based on the types of requirements listed in the previous slide and we just kind of abbreviated there to save room. And on the right we see the major sections of the NTCIP 1209 standard. Operational on the concept of operations of the standard may be listed in the concept of operations of the sensor specification. Functional requirements and design work details for the TSS device from the standard may then also be used as the interface and functional requirements in the agency's sensor specification. So not only is the PRL a tool but the entire standard can be a tool to help agencies.

Ralph Boaz: Historically TSS devices have been bought off the shelf assuming a proprietary interface to a proprietary program running separately on a central system. This is an opportunity to expand that idea so that we have or change that concept to have an NTCIP interface that will connect to all of your sensor systems. So to integrate a PRL into the specification think about the system architecture when you're writing it. Expand the interface requirements of the spec to include NTCIP 1209 version2. Use the completed PRL cable to indicate your interface requirements and include the interface requirements for the protocols being used in your system and I'm talking about the underlying protocols such as Ethernet or serial etcetera.

Ralph Boaz: A couple other things is require that the product be conformant to the NTCIP 1209 standard. And make sure that all of the requirements are consistent with the document. They're not just talking about your interface requirements. They're talking about well, your interface requirements need to be consistent with what your functional requirements were for the overall product and what your maybe your mechanical requirements are. In other words all the requirements within your spec need to be consistent.

Ralph Boaz: Okay let's take our quiz. Which item below is NOT good practice when writing a specification for a sensor? Your answer choices are A, including the protocols used to communicate with the sensor, B, excluding NTCIP requirements because your favorite vendor does not support them, C, consistency between hardware and interface requirements, and D, conformance to the NTCIP 1209 standard? Again, which item below is NOT a good practice? Make your selection…

Ralph Boaz: Let's review our answers. Well I hope you got this one which was B, excluding NTCIP requirements because your favorite vendor does not support them. This is the correct answer. Requirements should be based on your present or your future needs and not on your favorite vendor.

Ralph Boaz: Let's look at our incorrect answers, A, including the protocols used to communicate with the sensor. Of course we want this kind of information in our specification and the protocols used in a system should be identified. If you said C, this was incorrect. Inconsistent requirements in a specification may result in non-interoperable and non-interchangeable devices. And D, conformance to the 1209 standard, this is incorrect. Conformance to the standard while tailoring the PRL for a specification is essential.

Ralph Boaz: Let's summarize our learning objective and that was to explain how the PRL table and the standard integrates into a specification. We discussed how device specifications and agency procurements different from a systems spec. And we talked about how a specification is used by agencies to procure equipment and it tends to be the driving force for what's included in the spec. We discussed how the PRL fits into the specification.

Ralph Boaz: So what did we learn today? We reviewed the structure of the NTCIP 1209 version2 standard. We identified the TSS specific user needs. We looked at how to use the protocol requirements list to select user needs and link them to requirements. And we explained how the PRL table in the standard integrates into a specification.

Ralph Boaz: Some resources that we've used to develop this course, this module are listed here. I mentioned IEEE 830, Recommended Practice for Software Requirements Specifications. Of course all the other ITS professional capacity building training modules. And a great introduction into this area is we talked about this is the standard itself. Another good book is the Systems Engineering Guidebook for Intelligent Transportation Systems and this is what I was referring to. A great introduction and use of transportation sensor systems can be found in FHWA Traffic Detector Handbook.

Ralph Boaz: So questions? Well there were a couple of questions in previous versions of this module that have come up. One of them that was asked is, is it okay to do all this configuring of on-street equipment from a central system? My answer to that is typically some system setup is done in a lab, however many of these advanced sensor systems require the equipment to be set in the field before it can fully be configured. If the equipment is in an intersection, field technicians will put the intersection into a flash condition and may use a laptop acting as a management station to configure the device. It's conceivable that a sensor system could be tuned in real time from a central system such as increasing the delay extension times and other things.

Ralph Boaz: A second question was, as a user do I have to know all the details of the standard? Yes there is a lot here and there's more to come. My answer is it depends on what kind of user you are. To know or remember all of the details many of the review or participants of this course won't need to know all of its capabilities or all of the details but you do need to know the general capabilities that are available. Now people who are writing the specs or implementing the software from a systems perspective or from the device perspective, they're going to need to know all the details so consultants, implementers, manufacturers, will need to know the details in the standard.

Ralph Boaz: The next course the next module in this path is the A312b: Specifying Requirements for Transportation Sensor Systems (TSS) Based on the NTCIP 1209 Standard and in there we will describe the requirements included in the standard, the use of the PRL, we'll go into details about that. We'll show how you achieve interoperability and interchangeability using the requirements traceability matrix. We'll look at incorporating requirements not covered by the standard. This is important to know. And understand how the TSS SNMP interface and dialogues work so we'll go into details about that.

Ralph Boaz: Thank you so much for your participation today. It's been a pleasure to be with you and good luck.

#### End of 2013-01-28 12.54 A312a Final Recording.wmv ####