Module 23 - A312b

A312b: Specifying Requirements 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.

Kenneth Leonard: ITS Standards can make your life easier. Your procurements will go more smoothly and you’ll encourage competition, but only if you know how to write them into your specifications and test them. This module is one in a series that covers practical applications for acquiring and testing standards based ITS systems. I’m Ken Leonard, the director of the U.S. Department of Transportations intelligent transportation systems joint program office. Welcome to our ITS standards training program. We’re pleased to be working with our partner the Institute of Transportation Engineers to deliver this approach to training that combines Web-based modules with instructor interaction to bring the latest in ITS learning to busy professionals like yourself. This combined approach allows interested professionals to schedule training at your convenience without the need to travel. After you complete this training we hope that you’ll tell your colleagues and customers about the latest ITS standards and encourage them to take advantage of these training modules as well as archived webinars. ITS Standards training is one of the first offerings of our updated professional capacity training program. Through the PCB program we prepare professionals to adopt proven and emerging ITS technologies that will make surface transportation safer, smarter and greener. You can find information on additional modules and training programs on our website at 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 and thank you, again, for participating and we hope you find this module helpful.

Nicola Tavares: Throughout the presentation this activity slide will appear indicating there is a multiple choice pop quiz following this slide. The presentation lecturer 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 even more improvements to our training modules by completing the post course feedback form. This module is A312B Specifying Requirements for Transportation Sensor Systems Based on NTCIP 1209 Standard. Your instructor Ralph Boaz is chairman of the Transportation Sensor Systems working group for NTCIP. In 2002 he founded the 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.

Ralph Boaz: Welcome. It’s my pleasure to be your instructor today. This is the second half of training on the NTCIP 1209 standard. This is for transportation sensor systems. During this course we will have quizzes and we’ll give you a little bit of time to make your selections and then we’ll go over the results of those quizzes. Let’s get started. Our target audience today is for traffic engineering staff, traffic management center operations staff, system developers and private and public sector users including manufacturers, which kind of covers everybody. So we may have a diverse group and we are going to get into a lot of details. If you work keeps your involvement with standards at a higher level, you will still want to know enough to get what you want from your consultant system integrator or equipment supplier. These are the modules that are recommended prerequisites. I-101 provides an overview in the use of IT Standards. A-101 provides information on procurement strategies for standards. A-102 introduces how to identify user needs for standards. A-201 shows how to select the appropriate standard. C-101 explains the NTCIP framework. And A-312A is the direct predecessor to this module. In A-312A we focused on user needs for a transportation sensor system. And we introduced a lot of terminology and sensor system concepts. Well, we’re not going to into all of that detail here in this module. And I’d suggest if we get to a term that you don’t know, please consult the participant supplement. This is a graphical representation of what we just covered. Generally, the PCB program has two paths arranged towards the target application. And in this case, we have the curriculum path or the systems engineering process content. These are our learning objectives today. We’ll describe requirements included in the 1209 standard. We’re going to be talking also about the user needs discussed in A-312A, actually the requirements for those user needs. Then we’ll introduce the items about the PRL that we had in A-312A. And then here we’re going to go into more detail and look at the PRL as a tool to specify an NTCIP TSS interface. Next, we’ll talk about achieving interoperability and interchangeability using the requirements traceability matrix. And the requirements traceability matrix or RTM is a tool to implement an NTCIP interface. Fourthly, this sounds a little funny but it says we’re going to incorporate requirements not covered by the standard. There are times where we need to add requirements that aren’t covered in the standard to a specification. But there’s a way to do this so that you can still achieve interoperability and interchangeability. That’s what we’ll cover there. And finally, we’ll explain the NTCIP 1209 version 2 SNMP interface and dialogs. And this is explaining how messages are exchanged.

Ralph Boaz: Okay. Learning objective one, describe requirements included in the NTCIP 1209 version 2 standard. We’re going to review the components and structure of the standard. That’s a review of A312A. We’ll use the PRL to trace the user needs to requirements. And then I’ll look at the organization and decomposition of requirements within the 1209 v.02 standard. Just to refresh your memory, this is the definition of a TSS, a transportation sensor systems defined as any system or device capable of sensing and communicating near real time traffic parameters using NTCIP. Although we say transportation sensor system, it’s actually a device as far as NTCIP is concerned. We call it a system because it may be made up of many components, but as far as NTCIP is concerned it considers the TSS a device. This is the NTCIP 1209 detection architecture. On the left you see the management station. And then you see NTCIP communications connecting to a controller which has inductive loops as the sensor technology attached to it. And that works together as a single TSS device as far as the management station is concerned. And the second we have video detection being used. And there’s other technologies that are available, radar, magnetometers, acoustic detection and many others we’ll talk about later. But as far as the management station is concerned all of these devices are TSS’s of one form or another. Just a history of this standard, NTCIP 1209 version 1 was oriented towards inductive loops and it did not contain systems engineering process information. NTCIP 1209 version 2 we added this information. We reorganized the standard towards features of the TSS devices. And then we had added option for selecting requirements for the specific technologies, such as loop, machine vision and we left place holders for others. The structure is conducive for adding additional specific technology requirements in the future. Let’s talk about the structure of the standard. In the general information we have things such as-- well, actually scope, references, and definitions. In the concept of operations this describes a system from the users perspective, and this is where we find the user needs and in the standard they’re listed as features. We spoke about this in general in the past courses and in detail in A312A. Next we have the functional requirements which are actually requirements for the interface covered by the standard. They’re derived from user needs for the system discussed in the ConOps and they’re expressed as shall statements. We spoke about this generally in A312A. In this module we’re going to go into it more detail. Dialog describes the exchange of messages required to accomplish the functional requirements. There’s also state diagrams and we won’t go into those in this module. Then we have the management information base and that contains the object definitions or data elements used in interfacing a TSS to a management station and we’ll go into that in detail. Continuing with our structure here we have Annex A that’s the requirements traceability matrix. And this is where we have a requirements trace to the design items of the interface which are the objects and dialogs. In Annex B we have an object tree and this is just kind of an upper level hierarchical diagram of the objects and the management information base. When we have a placeholder for test procedures there are currently no formal test procedures in the standard. And then in Appendix D, we have document revisions summarized.

Ralph Boaz: And now we have an activity. This is your opportunity to exercise your skill and knowledge from what we just covered. What tool is used to show the relationship between requirements and dialogs within the standard? Is it A, object tree; B, protocol requirements list; C, requirements traceability matrix; or D, dialogs. Please make your selection. <pause> If you said C requirements traceability matrix you’re correct. The RTM shows requirements traced to the interface items which are the dialogs and objects. If you said A, this is incorrect. The object tree shows the hierarchical organization of the objects in the MIB. If you said B the PRL, this was incorrect because the PRL shows relationship of user needs to requirements. And if you said D, this was incorrect. Dialogs show the exchange of messages. Now, we’re going to take a detailed look at the PRL and see how it is used to trace-- user needs are traced to requirements. In this first column we have the user needs section number. And this is actually the section number that you can find in the document. You can go to the 1209 standard and find this paragraph, and this paragraph number 2517 will be titled configure outputs. This is the name of the user need which we just said was configure outputs. Configure outputs, this feature allows the management station to configure the outputs to report the state of zones. Recall that an output of a zone is simply an on or off state. A physical output pin on the device or an output indicated in a data message can be mapped to various on street zones or virtual zones. And I also want to remind you that you have your participant supplement if you’re rusty on these terms. The output of the zone can be conditioned based on the extension, delay, sequencing, arming enables and arming inputs. And they can also be programmed for various modes of operation. Now, if we look at sort of a deconstruction or decomposition of this user need or relationship to the requirements we see the functional requirement section number. And, again, just like in the user need these numbers correspond to paragraphs or sections within the NTCIP document. This is the functional requirement name. Let’s take a look at these. We have get output sensor zone. The TSS shall allow a management station to determine the sensor zone assigned to an output. We have another requirement that says get output failsafe mode. The TSS shall allow management station to determine the last failsafe mode command. We have get output mode status. The TSS shall allow a management station to determine the current output mode status of an output. The next one is get output label. The TSS shall allow a management station to determine the label assigned to an output. And, again, there are other functional requirements for this user need, but they’re all listed here in the PRL. This next column is the conformance column. In this simple case, requirements are either mandatory which is indicated by M or optional indicated by O. Mandatory means that the user need or requirement must be satisfied in implementation of the standard to be considered conformant to the standard. Optional means the requirement does not have to be included in the implementation of the standard to be considered conformant to the standard. Since this user need is mandatory, then all of the requirements that are mandatory must be satisfied in the implementation to conform to the standard. The optional requirement means that that requirement does not have to be included in the specification device even though the user need was mandatory. So while output-- get output sensor zone, get output failsafe mode, get output mode status are mandatory, get output label is optional. Here we have the project support column. And in here we have the choices that a specifier may use for each of the user needs and requirements in the standard. And you can see that since all of the mandatory conformants items have a yes because there is no option there, but in the case of the optional requirement we have a yes/no possibility. Finally, in the table here we have an additional specifications column and that allows for tailoring of the standard such as sub ranging values and we’ll discuss this further later in the module. Now, we’ll look at the organizational requirements and we’ll be going down through each of these areas; think of these as groups of requirements. So what do we want to do? We want to be able to manage the TSS configuration. We want to be able to monitor the current status. We want to be able to collect sample data. And then we’re also concerned with multi version interoperability. You may recall from earlier modules the formula for a well formed requirement here we have actor, action, target, constraint and localization. So the actor identifies who or what does the action and this is typically a system or subsystem shall kind of statement. The system shall do this et cetera. The action identifies what is to happen. The target identifies what is to receive the action. And then the constraint identifies how to measure success or failure of the requirement. Localization identifies the circumstances under which the requirement applies. And both of these constraint and localization we say they make the requirement mean something, right. We need something at the end of this shall statement to say give it a concreteness. Let’s take a look at an example TSS requirement. Remember, our form act or action, target, constraint, localization. So the TSS, this is our actor, shall determine, now this is a little bit different. The TSS document listed the requirements in terms of the TSS device instead of versus the central system. So we have this form that TSS shall allow a management station. They could have said the management station shall do something, shall be able to determine. So you just have to get used to this little twist on the well-formed requirement. So we have the actor is the TSS. And then we have to determine as our action. And the target is the label. And then we have the localization which is assigned to an output. We’re going to now look at the composition of the requirements for each of the four requirements groups we’ve mentioned previously which was manage the TSS configuration, monitor the TSS configuration, collection of sample data and multi version interoperability. Manage the TSS configuration. Now, think about this, what would we need to do? If we wanted to be able to manage this device out in the field, what would we need to do? Well, we would want to be able to identify the TSS. Those are requirements for determining the sensor technology used to manufacture model firmware, et cetera. We want to be able to determine the TSS capabilities. These are requirements to determine the maximum number of zones, maximum number of outputs of classes, et cetera. We want to be able to control the TSS. These are requirements for restarting the TSS, reinitializing, causing the device to perform diagnostics, et cetera. We’d want you to be able to manage the real time clock. This requirement for the real time clocks such as setting and receiving the date and time and daylight savings operations. We want to manage sensor zones, these are requirements for zone options and attributes such as zone logic, paring, max presence time, et cetera. You want to be able to manage output these are requirements for configuring outputs of the TSS device such as the output sensor zone, arming enables open label. And manage the camera. These are requirements for managing the configuration of the camera for a video detection device, establishing baseline image, image overlay and other camera related functions. Remember, that in the future, there may be other technology specific options that are desired and can be included in the TSS for other sensor zone technologies. Monitor the current status of the TSS. Incidentally, there were 122 requirements for manage the TSS configuration. There are 13 requirements for monitor the current status of the TSS. We have get system status. This allows the management station to determine the overall status of the TSS device. We have the TSS sensor status. These are requirements for the parameters for the detection portion of the TSS such as getting the zone inductant’s frequency image, et cetera. So the first one, get system status is all about the overall status. TSS sensor status is about the detection portion of the device. And then monitor output states allows the management station to determine the on/off states of an output group. Collection of sample data, there are nine requirements for this collect sample data area. There’s retrieve historical sample data from the TSS. That’s where we get the historical sample end time, volume presence, present occupancy, et cetera. We get the zone class label. This is data that may be arranged by class such as vehicle classes, motorcycle, passenger car, pickups, vans, busses, et cetera. In this case the label allows the management station to determine the identifying label assigned to the class of the zone. And we have a get number of sample data entries. This allows management station to determine the number of sample periods the zone is currently using. And then we have get number of sensors own classes. This gets the number of classes that the zone is currently using to bin data. Now, we look at multi version interoperability. We also call it backwards compatibility. There are 22 requirements for this. These requirements are traced to deprecated data objects. Deprecated meaning the object is only valid in limited circumstances and may have been replaced by others. And this is here to support previous versions of the standard. Now, you won’t get off the shelf interoperability when using this multi version interoperability option because version one of the standard did not use dialogs which can lead to differences in message sequences. Secondly, if off the shelf interoperability is desired, then version one devices and version two devices should be on different communication channels. The central computer essentially needs to know which device it is talking to.

Ralph Boaz: Now, we have another question. Which of the following is not a major group of requirements in NTCIP 1209 version 2? Your answer choices are manage the TSS configuration; manage the camera; collect sample data; or D, multi version interoperability. Please make your selection. <pause> If you said B, manage the camera, you’re correct. Manage the camera is included in manage the TSS configuration so that it’s not its own major group. Monitor the TSS is the remaining major group from this group that we just listed. Again, we said manage the TSS configuration, that’s a major group of requirements covering configuration control of the TSS. Collect sample data. This is not a correct answer because this is a major group or requirement and refers to collection of near real time data. And then, of course, multi version interoperability. This is a major group of requirements refers first to the design of the standard in NTCIP 1209 version 1. Summary of our learning objective here is describe requirements included in the NTCIP 1209 v.02 standard. We reviewed the components of structure of the standard. We looked the PRL and how it traced user needs to requirements. And then we looked at the organization and decomposition of requirements of the NTCIP 1209 v.02 standard. Okay. Now, that we’ve described requirements, in our next learning objective we’re going to use a protocol requirements list to specify an NTCIP interface. Here we’ll specify performance criteria for the functional requirements within the PRL. We’ll specify limits or ranges for functional requirements within the PRL. We’ll use optional requirements and predicates within the PRL. And then we’ll use the PRL in a specification. Here is another example or section of the PRL that’s found in the NTCIP 1209 standard. We’re going to take a look at this last column. This last column for additional specifications can be used for various things. Here we’ve added performance criteria to our copy of the PRL, to the functional requirements in the standard. In this case, we circled the user needs of requirements. We want to then set an additional specification that we require certain types of information every second. Here we’re specifying limits of ranges in a similar fashion for a different user need and requirement we require a parameter to be set to a particular value. The standard allows a range of one to four. In our TSS specification, we want to have the maximum number of historical data entries to be four. This means anyone responding to an RFP based on our specification would have to support this value. Note that to be conformant to the standard, only sub ranging is allowed. Sub ranging means that additional specifications are allowed to be more restrictive than those in the standard. The standard may allow values of on 1 to 255 on a given requirement or object. But the specification may be more restrictive such as values 1 to 40. If a user of the standard requires a value outside of those stated in the standard to be conformant to the standard the user must create new objects and include them in the specification. Now, we’ll look at using optional requirements and predicates. Recall from module A312A the use of predicates and numbered optional requirements. In this example, we have determined that we’re using video detection. So the video predicate is true and makes the user need mandatory. We have decided that we do not require the option to turn detection on and off, but we do want to be able to build images from the camera and send them via NTCIP communications for maintenance and verification purposes. So we indicate yes, for those requirements. Since we have indicated an option or O.2 requirement, all requirements with the O.2. regardless of where they are in the PRL must also be included. Note that since video is specified for the user need, then the associated requirements become a yes or no decision. If video was not specified, then the project requirements become not applicable. Now, we’ll talk about using the PRL in a specification. PRL shows the relationship of user needs or features to requirements. It’s a primary tool for specifying the NTCIP 1209 interface. And a completed PRL should always be included in a NTCIP 1209 specification. Just a review from A312A of the predicates used in NTCIP 1209. We have loops, productive loops. We have video for machine vision. RTC for real time clock. We have speed, timing, sample and version one. View of the conformant status used. We have M for mandatory, O for optional, O. # (number), this is where number indicates the group number. O.2 means option group 2. And if a requirement associated with a particular option group is supported, then all requirements in the standard that are associated with that option group must also be supported. Of course NA means not applicable. Now, we’ll go through a process where using the PRL in your specification, how to fill out the PRL. First, make a copy of the PRL table. Then we’re going to determine which predicates apply to your specification of NTCIP 1209. So we’re going to step through each user need in the PRL and indicate whether it is to be included. We’ll circle yes for all user needs indicated by an M and we’ll circle yes or no for all the user needs indicated by an O. We’ll then circle yes to all user needs indicated by a predicate M for the predicates that we determine in step number two. Next, we’ll circle yes or no for all user needs indicated by a <predicate> : O or a <predicate >: O #. These are for, of course, these two items are for our predicate for our option groups. And then we’ll verify that all of your user needs with the same option group have a yes circled. Then we’ll circle no or not applicable as appropriate for all of the remaining user needs. So this is so far we’ve gotten through all of the user needs in the PRL. Now, we’re going to repeat the process for the requirements. We’ll step through each requirement for each user need in the PRL that had a yes circled. We’ll circle yes, which is what we just said here. And then B we’ll circle yes or no for all requirements indicated by an O. We’ll circle yes to all requirements indicated by a predicate M or the predicates determined in step number two. And we’ll circle yes or no for all requirements indicated by a <predicate>: O or <predicate>O#. And then we’ll verify that all of requirements of the <predicate>: O # have a yes circled. Finally, we’ll circle no or not applicable as appropriate for all remainder requirements. Then we’ll go through and enter any limits or ranges to be applied to any of the included requirements and we’ll enter any performance criteria for any of the included requirements. And then we’ll enter any other special instructions for any requirement in the PRL.

Ralph Boaz: Let’s do a quiz. If video colon O2 is used in the conformance column of the TSS PRL, what does it mean? Is it A, it’s a second of 20 optional video requirements in the standard; B, it identifies the second highest priority optional video requirement; C, it says that if one Video:O.2 optional requirement is used in the project then all Video: O.2 requirements must be used; or D, is it none of the above. Please make your selection. <pause> If you said C you are correct. This is the method used to identify an option group. If one Video:O.2 option group is used then all requirements that have Video O.2 indicated must be used in your specification. If you said A, this was incorrect. There’s no numbering of requirements in the conformants column in the PRL. If you said B, this is incorrect, there’s no priority of requirements indicated in the conformance column. And if you said D, none of the above this is incorrect because there is a correct answer listed. Let’s summarize our learning objective two. Use the protocol requirements list to specify an NTCIP interface. We looked at specifying performance requirements within the PRL, specifying limits or ranges on requirements. We used optional requirements and predicates and then we showed how to use the PRL in a specification. Now, that we’ve described requirements and we learned in a detailed way how to use the PRL NTCIP interface, now we’re going to show how to achieve interoperability and interchangeability using the requirements traceability matrix. We’ll look at how the RTM traces to a single design, that being something that can be implemented by everyone, how to determine that a management station and device will be interoperable. Because of the RTM and PRL this can be done in an easy manner. And then how to determine the two devices will be interchangeable and we’ll look at there. We’ll look at how interoperability enables interchangeability. How the RTM traces to a single design, well it shows the relationship requirements to specific design items of the interface. Those are the dialogs and data objects found in the standard. It’s used by system software and TSS manufacturers implementing the standard. It’s useful for identifying data objects within the standard that may be sub ranged within the specification. And the RTM information presented in the standard does not need to be repeated in an agency specification. In other words, this is a single design. There are options on the RTM itself if you were to require any sub ranging of values, et cetera, that would be done in a PRL. Here’s an example from the standard of section of the requirements traceability matrix. We’ll step through this. Here we have a requirement ID, this is like the PRL this represents a paragraph for a requirement, a paragraph number for a requirement in the standard, in this case 3.4.3.1.7 is listed and you can go right to the standard and find that. And then we have the name of the requirement which is Getzone class label. The next column we have the dialog ID. This lists the paragraph number of the dialog definition found in section four of the TSS dialogs of the standard. Here we have the name of the dialog. Remember, the dialog represents the exchange of messages. In this column we have the object ID. This column of the RTM lists the paragraph number of the object definition found in section five of the management information base. We call the MIB the data dictionary of the interface because it defines the data that’s to be exchanged. And here is the name of the objects listed. As an implementer, you can then trace a requirement to the dialog that describes the exchange of messages and then to the objects that are used to fulfill the requirement. If you were to include additional requirements for the interface with a TSS device that are not in the 1209 standard you would need to include RTM entries for the additional requirements, include them in your specification. So if you stick to the standard requirements and data elements then you don’t need to include the RTM information. But if you are adding requirements and new data elements, then you would need to add this type of information to your specification. How to determine that a manifestation and device will be interoperable? Let’s review our definition here of interoperability. That’s the ability of two or more devices to exchange information and the ability to use the information that has been exchanged. So how do we do that? Well, the RTM provides for interoperability by defining a specific design to fulfill the communications requirement. The PRL indicates which requirements are supported. A comparison of the PRLs for the management station and the field device allows a quick determination of interoperability. So you can actually do this on paper. When we’re talking about interoperability, we’re really saying can the management station and field device fulfill each requirement in a cooperative way? Now, let’s talk about interchangeability, how to determine if two devices are interchangeable. Interchangeability is defined by the same functional and physical characteristics so as to be equivalent in performance and durability. And the ability to exchange devices in the same type without alteration to the device or adjoining items. In both of these cases, this is somewhat subjective. So how do we determine if two devices will be interchangeable? Well, it must be interoperable within the same system. It must be compatible on the same communication’s channel. Standard functions should provide the same results. And the subjective measures that are important to the agency like accuracy, maintenance, et cetera, then you have to make sure that those are equivalent. And, again, those are subjective and each agency is going to have to make their own judgment. So when we’re talking about interchangeability we’re really talking about is it close enough for you. Now, this is really important regarding off the shelf interoperability and interchangeability. Systems using only standardized requirements data objects and dialogs facilitates interoperability and makes interchangeability a possibility. Systems using requirements, data objects and dialogs not in the standard make interoperability and interchangeability difficult.

Ralph Boaz: Now, we have another quiz. Which statement is true in regards to achieving interchangeability for TSS equipment using NTCIP 1209 version 2? Your answer choices are A, using user needs from the standard guarantees interchangeability; B, using only requirements, data elements, and dialogs from the standard guarantees interchangeability; C, adding communications data elements that are not in the standard makes interchangeability impossible; or D, using only requirements, data elements and dialogs from the standard makes interchangeability a possibility. So which statement is true in regards to interchangeability for TSS equipment? <pause> The correct answer was D using only requirements, data elements, and dialogs from the standard makes interchangeability a possibility. It provides the best opportunity for interchangeability and, again, there’s other subjective measures that an agency may use to determine what they feel is interchangeable. If you said A, A was incorrect because user needs identified in the standard are at a high level by themselves and not explicit enough for interchangeability. If you said B, this was incorrect because interchangeability may be affected by other aspects of the TSS device not just communications. And if you said C, this was incorrect because using data elements not in the standard may limit your choices of manufacturers willing or able to provide support for those data elements. But interchangeability is not impossible technically. So that was a bit of a trick question because if you’re adding communications data elements that are not in the standard, it doesn’t mean interchangeability is impossible. It just means it may be more difficult. Here we have another question. Which statement is true in regards to the RTM NTCIP 1209 version 2? The answer choices are A, shows the relationship of requirements to the specific design items of the TSS interface; B, it shows the relationship of user needs to the specific design items of the interface; C, it should always be included in an agency specification; or D, it’s not used until integration of the system and the TSS device. Please make your selection. <pause> The correct answer was A. The design items include the data objects and dialogs. So the RTM shows relationships to the specific design items-- the relationship requirements to the specific design items of the interface. If you said B, shows the relationship and user needs to the design items, this was incorrect because user needs are found in the protocol requirements list not in the RTM. If you said C, it should always be included in the agency specification, this is incorrect because at RTM information is only needed in a specification, if there’s something different from the standard. If you said D, not used until integration of the system and the TSS device, this is incorrect because the RTM is used by system software and TSS manufacturers to implement the standard. So this may be done long before any integration is taking place. So let’s summarize learning objective three. Achieve interoperability and interchangeability using the requirements traceability matrix. We looked at how the RTN traces to a single design. We looked how to determine that a management station and device will be interoperable. And then we looked at how to determine that two devices will be interchangeable. Now, that we’ve talked about what’s in the standard, now we’re going to talk about incorporating requirements that are not covered by the standard. We’ll talk about the conditions and context for extending the NTCIP 1209 standard, and we’ll look at some examples of extending the standard. Now, when we say extend the standard, it’s kind of slang because we’re really not extending the standard, but we’re adding to the standard in our specification. So it’s just a slang word but I think you get the point. Conditions and context for extending the standard, we need to consider the warnings in the previous learning objective using only standardized requirements, data elements, and dialogs facilitates interoperability and interchangeability. And using requirements data elements and dialogs not in a standard makes interoperability and interchangeability difficult. So we have to ask ourselves when we’re adding a new requirement, is there a standard NTCIP method to accomplish the same thing? And you’re strongly urged to do that and not take other methods that are outside the standard because you may make interchangeability and interoperability difficult. If you do extend the standard, the extension should be documented and made available to anyone. Extending or adding to this TSS standard can make sense to provide for control features and requirements that are specific to certain technologies. In other words, there’s some technologies currently included, but there may be other specifics for other technologies that are used for detecting vehicles, and pedestrians, et cetera. And then also if there’s data available and sensor technology is not yet covered in the standard. So here are the sensor technologies that may have technology specific features. We have loop video, microwave radar, magnetometer, acoustic, ultrasonic, infrared, laser, PC electric, pneumatic, light sensitive and there are others. The technology specific features that are currently included in the NTCIP 1209 standard are both loop and video. It should be noted that most of these technologies can still work using the standard objects. You just wouldn’t be able to access certain features specific to the technology that would be, for instance, a low battery condition in a magnetometer, or a microphone adjustment to an acoustic detector. So those are the kinds of things that you may not have access to using the standard objects, but you can still use the other objects all ready included to utilize that technology in the field. There’s a configuration option in the TSS device so that if you needed to send down configuration information to a TSS device and it had all of the special items, you could send that down as a single file and then adjust the configuration in that fashion. You just wouldn’t have access to the particular objects in a singular kind of way-- the particular features in a singular kind of way. Okay. Now, let’s talk about an example of extending the NTCIP 1209 standard. Here we have a feature that is common amongst microwave radar devices and it’s called 85th percentile speed. And this is a speed at or below which 85 percent of the people drive at any given location under good weather and visibility conditions. And it’s considered as the maximum safe speed for that location. So here’s our scenario. We’re an agency that wishes to include 85th percentile speed in our TSS specification. Now, assuming we’re writing a specification we might arrange our spec in this fashion. Sections one through five cover requirements and specifications identified in the majority of our-- of the TSS devices. Section six covers extensions to the NTCIP 1209 standard; 6.1. has some introductory information; 6.2 identifies needs and features; 6.3 identifies any state’s requirements; 6.4 describes dialog; section 6.5 provides object and benefits. We’ll go deeper in this requirement level to be able to illustrate how adding to the standard to the standard is accomplished. So here is our need or feature. This feature allows the management station to obtain the 85th percentile speed from the TSS. I will look at requirements that came from this. We have get 85th percentile speed which is the TSS shall allow management station to retrieve the 85th percentile speed for each zone. And the next one is reset 85th percentile speed. The TSS shall allow a management station to reset the 85th percentile speed. Note that we’re using the section numbering that we described previously. So we have this addition to PRL. Note the user need number, we have 6.2.1, the name of the user need. We have our section numbers for the requirements. And the requirement names and we’re saying for our implementation here we’re making this mandatory. Now, this is the case where we need to add a RTM to our specification because it’s outside of the design that’s all ready in the standard, so we add these following items. We have a requirement’s ID, the names listed as you would think. Then we’ve invented a dialog 6.4.1, retrieve 85th percentile speed. And then we’ve added, then, again, we added a dialog to the reset 85th percentile speed called initialize 85th percentile speed. So the get 85th percentile speed we said we have this dialog, again, retrieve. And what it’s going to retrieve is this data element called zone 85th percentile speed. And then if we’re resetting the percentile speed, we’ll be initializing percentile speed and then we’ll be returning a data element called reset zone 85th percentile speed. And we need to define our data element and we’re using the abstract syntax notation ASN.1 to describe this data element in the management information base. And this has been covered by other modules, but we’ll highlight a few things for our new data element. The name of it is zone 85th percentile speed. It’s an integer. And some of the options here can be integers, sequence, bitmap N, octet string. These are some of the elements there. When you say bitmap N that says the N is the size of the bitmap. Access in our case is read only. You can make objects read only, read/write or not accessible. Our case, our status is mandatory. It can also be optional, Deprecated, obsolete. Here is the English definition of our object. It says indicates the 85th percentile speed for a zone. There’s also some more techy information in here. It gives what the object ID would be in the MIB, for the MIB. And this says, this last one says that it is this data element is the first data element of the table called zone speed data entry.

Ralph Boaz: Okay. Let’s do a quiz. Which of the following is justification for extending the standard with a new feature, A, when you’re not worried about interoperability or interchangeability; B, after you have waved the risk of making interoperability and interchangeability more difficult against the benefit of the feature; C, when you want to disqualify a second vendor because you’ve done business with another one in the past; or D when a proprietary method to accomplish a feature is more familiar over a method used in the standard. Please make your selection. <pause> The correct answer was B. The time to add a requirement and data element to the standard is after you’ve weighed the risk of making interoperability and interchangeability more difficult against the benefit of the feature. It should be a significant enhancement. If you said A, when you’re not worried about interoperability or interchangeability this is incorrect because if you’re not concerned with interoperability or interchangeability why use NTCIP at all. If you said C, if you want to disqualify a second vendor, this is not a good reason. You may find yourself trapped by one vendor in the future even if they perform poorly. Remember, if you may have a favorite vendor now and things can change and you don’t want to be trapped and locked into one vendor in the future. If you said D, when a proprietary method to accomplish the feature is more familiar this isn’t a good reason. If there’s a standard method to accomplish this same feature it’s best to use it. And, again, this is so that you can create-- you have your best chance at interoperability and interchangeability going forward. Summarizing learning objective four, incorporate requirements not covered by the standard. We looked at conditions and context for extending the standard. And we looked at an example of extending the standard. And we want to go further down. We spoke about the requirements traceability matrix and how it went to dialogs and objects. Now, we want to take a look a bit more at the dialogs. So in this section we’ll look at example dialogs from the standard. And then we’ll look at an example of a dialog extension to the standard and we’ll be using our example that we had previously described. So this is a way of representing a dialog, it’s called a sequence diagram. And what you see here is you have a management station on the left and your TSS device on the right, and you see the sequence in this case, a get message going from the management station to the device and then the response coming from the TSS device to the management station. This is just a way of illustrating it. And this is actually the common SNMP get dialog that’s used for all of the NTCIP center of fields standards. Now, here is an example, a textual example of a dialog. And this is taken right from the standard and it’s called retrieve, sensor zone class labels dialog. Recall that the classes represent typically are classes of vehicles, trucks, sedans, et cetera, motorcycles those kinds of things. And what this dialog is to do is to retrieve the class labels for a given zone of the TSS device. Secondly, we look at the MIB and that defines the structures for the zone and the class information within the TSS device. Well, the purpose was the first statement. The second one tells us a bit more how we’re going to accomplish this. So we’re going to go to the MIB and we see how where these zone and class information is stored. And then the management station knows about these structures and how to reference them to get the desired data. So the management station has the MIB for the TSS device, so it knows how to get that information. So for this dialog, the management station must retrieve the number of classes for the zone and then loop through retrieving the class label for each class of a zone. So figuratively, you can think of this as a data structure out there of a table with zones listed on the left, and the number of sample data entries that’s how many entries it holds and the number of classes on the right. So there’s a zone sequence table entry described in the MIB and held in the device. It’s actually not of this form per se, but this is the way you would think about it conceptually. There’s also the structured zone class table entry where we have a zone index. We have the class, each class listed for each zone. And then we have the class label for each index. So here’s our dialog. So the dialogs in the TSS are done using this written form. In this case X and Y are indexes corresponding to the sensor zone number and sample zone class respectively. It’s beyond the scope to go into all of the indexing details here. But when accessing the data, the table’s reference reversed from the manner you might naturally think of it. So A, you want to make sure that the sensor zone number is valid and the TSS support sampling features, otherwise, if there’s no sampling features, there’s no classes. B, we’re going to perform an SNMP get message to retrieve the number of classes for the sensor zone number. Then, C, we’re going to assign the sample zone class to the number of classes we created in step B. D, performs an SNMP get message to retrieve the zone class label from the TSS using the class number and zone number. And step E, if it’s greater than zero we’re going to decrement the sample zone class number and go back to step D to get the next one. And then when this falls through, when it becomes zero, we’re all done. So that’s the sensor-- that’s retrieve sensor zone class labels dialog. Now, here’s our proposed dialog for our 85th percentile speed. Remember, that our new object zone 85 percentile speed was a table called zone speed data entry which has the speed accumulated by zone. Access and index corresponding to the sensor zone number. So in step A we’ll make sure that the sensor zone number is valid and that the TSS supports sampling features. And step B we get the zone 85th percentile speed from the zone speed data entry table for the sensor zone number. And C, we’re all done. The 85th percentile speed is by zone and not by class of vehicle. So there’s no looping through the classes required.

Ralph Boaz: Okay. We have a quiz question. Which statement is true concerning dialogs used in defining a TSS interface, answer choices are A, a dialog is best defined by graphical pictures; B, a dialog is not necessary when adding features outside of the standard; C, a dialog is only necessary if there are several exchanges of messages; or D a dialog is important to defining the exchange of messages to accomplish a requirement. <pause> Let’s review our answers. The correct answer was D. It’s critical for software developers to implement the interface so a dialog is critical to define the exchange of messages so that interoperability is possible. If you said A, a dialog is best defined by graphical pictures, this is incorrect. There’s multiple ways to define a dialog. If you said B, a dialog is not necessary when adding features outside of the standard this is incorrect because requirements for features that are outside of the standard may require dialogs also. And if you said C, a dialog is only necessary if there’s several exchanges to the messages, this is incorrect. Every exchange of data has a dialog even if it’s only a standard SNMP set get or get next operation. To summarize what we’ve learned, in this section, in this learning objective, explain the TSS SNMP interfacing dialogs. We looked at example dialogs for NTCIP 1209 version 2. And then we looked at an example of a dialog extension to the standard. All right, let’s summarize what we learned today. We described requirements included in the NTCIP 1209 version 2 standard. We learned to use the protocol requirements list to specify a NTCIP TSS interface. We learned to achieve interoperability and interchangeability using the requirements traceability matrix. Four, we learned to incorporate requirements not covered by the standard. And five we learned to explain the TSS SNMP interface and dialogs. Listed here are resources you can go to to find out more information about what we covered today. Please also refer to your student supplement and to the USDOT PCB website. Thank you for participating. Before we concluded we did want to run over a few questions that have been sent in previous versions of this module. It was asked where can I get sensor systems that are using NTCIP 1209 version 2? Well, currently version two is not yet published but is due to be published in May 2013. And once it’s published you should see vendors implementing it in their systems and in their products. And you should see agencies specifying it. And I encourage the agencies to do that because if you spec it, the manufacturers will provide it. And then you will get a more powerful and more interoperable systems. Again, that’s due in May 2013. Now, you might ask this seems all too complicated. I just wanted to buy it and everything works. Now, what we have to understand when we’re dealing with this kind of technology is we don’t have a market size of personal computers or cell phones. And so it does take some integration and some careful spec’ing to get the interchangeability, interoperability that we desire. So you can be a bit more hands off if you’re not operating at these lower levels of actually implementing or spec’ing these standards, but you need to make sure that it gets done. So that’s why it’s important for the various levels of an agency or manufacturers and such to be aware of the standards and what they bring. So I want to thank you so much again for your participation and this concludes this module.

### End of A312b_Final.mp3 ####