Module 24 - A304a

A304a: Understanding User Needs for Field Management Stations (FMS) - Part 1: Object Definitions for Signal System Masters Based on NTCIP 1210 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: This course is sponsored by USDOT ITS Professional Capacity Building Program. The ITSPCB 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 A-304a, "Understanding User Needs for Field Management Stations, Part One: Object Definitions for Signal System Masters, based on NTCIP 1210 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 question 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. Your instructor, Ken Vaughn, received his bachelor's degree from Tulane University and his master's degree from Texas AMU. He coordinated traffic signals in Los Angeles County in the early 1990s, and his graduate research studies, the performance of actuated signals in coordinated systems. He's a member of the NTCIP joint committee in 1995. He has provided consulting and NTCIP testing services for signals and signal systems for numerous agencies throughout his career. He will lead the discussion today on the user needs for signal system masters.

Kenneth Vaughn: Well, thank you, Nicola. And today we'll be talking about the signal system masters. The target audience for today is traffic engineering staff, traffic management center operations staff, system developers, and public and private sector users, including manufacturers. The recommended prerequisites for today include I-101, Using ITS Standards, and Overview; A-101, Introduction to Acquiring Standard-Spaced ITS Systems; A-102, Introduction to User Needs Identification; A-201, Details on Acquiring Standards-Based ITS Systems; and C-101, Introduction to the Communication Protocols and their Uses in ITS Applications. Those five modules follow one after another prior to this module, A-304a, Understanding User Needs for Field Management Stations, Part One: Object Definitions for Signal System Masters, based on NTCIP 1210 standard. There is one module that follows this module, A-304b, Specifying requirements for field management stations, Part One: Object Definitions for Signal System Masters, based on NTCIP 1210 standard. There is a slightly different curriculum path for those using non-SE-based standards. Learning objectives for this module include reviewing the structure of the NTCIP 1210 standard; identifying specific field management station user needs within the context of signal system masters; using the protocol requirements list, PRL, to select the user needs and linkage requirements; and explaining how the PRL table of the NTCIP 1210 standard integrates into the FMS specification. For the first learning objective, reviewing the structure of the standard, we're going to talk about the purpose of the standard, where we are in the V diagram of the systems engineering process, and identifying components of the standard. The first thing we need to point out is this module is based on version 1.53. It's labeled as the ballot-ready version. However, we now know that this contains design flaws and is not really ready for field deployment. You should be looking for an update before you deploy this standard. The user needs and requirements are not expected to change; that's the good news. That means the specification process should not change, and the overall intent of this module stays consistent. However, there are details within the standard that will be changing. The NTCIP is a family of standards for ITS. It can currently be broken out into two levels, the information-level standards that define the data to be exchanged, and the underlying standards that define how data is exchanged through lower-layer protocols. That's shown in this figure in what's called the NTCIP framework. The top level, information level, is called functional area data dictionaries, which can be defined into two categories: the center's center-data dictionaries, the NTCIP data dictionaries. The NTCIP 1210 is an NTCIP data dictionary. This uses other protocols that define data objects and dynamic objects and files. Primarily for this standard, it uses data objects and potentially dynamic objects if you choose to use STMP for a more bandwidth-efficient operation. Other standards within the NTCIP that relate to the standard include SNMP and STMP, that define application-level issues. UDP/IP, TCP/IP, and T2/Null define transport-level operations. PPP, Ethernet and PMPP define alternative subnetwork-level standards. The NTCIP 1210 is a communications interface standard. It forms part of that communications interface. Specifically, it's designed to define the communications between an SSM, signal system master, and monitoring systems, such as essential systems. And SSM is one type of field management station. Plus, related to the SSM is actuated signal controllers. After all, this is a signal system master; it manages local signal controllers. Thus, the standards related to the actuated signal controllers, NTCIP 1202, is also of interest for people deploying the standard. The good news is that this standard, NTCIP 1210, includes a systems-engineering process content. In other words, it includes user needs, requirements, design elements. It simplifies the process of specifying the standard. The structure of the standard generally follows the systems engineering process. It defines the user needs, such as implementing a plan based on a time-based schedule. It then defines functional requirements for these needs, such as synchronizing the clock with a traffic management system, so that implementing a plan is a basic user need, whereas defining the setting and synchronizing a clock is more of a requirement. It's a lower level that doesn't achieve the end-user need, but supplements and works with that end-user need. Those requirements are then implemented through specific designs for each requirement, one design for each requirement. Defining a precise design gives you that interoperability that everyone is searching for. Now, this is the typical V diagram of the systems engineering process. You see in the upper left the systems engineering management planning followed by concept of operations, followed by systems requirements. Now, what must be recognized is each design element repeats this V diagram over and over again, so once you define your system requirements, you define an architecture as part of your high-level design, and then you define the needs for those architectural components, and then subsystem requirements for each architectural component, and that's exactly what the NTCIP standards are doing. They're not defining the high-level system requirements for the overall system; rather, they're defining the user needs and requirements related to a particular architectural component, specifically in this case, the signal system master. And that's shown by the shaded box I've just highlighted, that the high-level design subsystem requirements and detail design are what's covered by the NTCIP standard in this case. You'll also notice that it does not cover the entire range of high-level design and subsystem requirements. Rather, it's one small slice, specifically that slide related to interface requirements. Now, the structure of the standard does frequent the systems engineering process. It follows a general section up front; followed by the concept of operations; functional requirements, which includes what's called a protocol requirements list, a traceability table between the user needs defined in concept of operations, and the functional requirements. It then has design sections: Sections 4, 5, and 6: Dialog Specifications, Signal System Master Object Definitions, and Signal System Master Blocked Object Definitions. Section 5 you can think of as the atomic-level definitions of individual pieces of data. Section 6 would then be kind of the more molecular level of data. And Section 4 defines how that data flows back and forth between the different components. Annex A, then, provides another traceability matrix. This time we're tracing from the requirements defined in Section 3 to the design elements defined in Sections 4, 5 and 6. The device and information profile is an alternative view of how you can claim conformance that some of the manufacturers wanted to include in the standard. And Annex C, a control hierarchy, defines how the signal system works from a hierarchical perspective. So, does the time-based management selection occur as a highest priority, or does the traffic-responsive? It's the traffic-responsive, and then that's defined in Annex C. Some of the advantages of the current design of NTCIP 1210 is that it includes the system engineering process that makes it easier to use and easier to specify. You can go down to the protocol requirements list, identify the needs that they have, and then identify the requirements that relate to those needs that they have, and quickly specify the standard-- the product that they need for their project. It also makes it easier to test. By clearly defining each and every requirement, you now have precise, measurable requirements to test against. Finally, because it defines the full design of every requirement, it supports interoperability. Well, that brings us to our first activity, and please feel free to go ahead and select the process once you know the answer. The first question is: What is the purpose of the systems engineering process? Answer A is it provides a structured and reproducible approach to specifying a system. Answer B is it provides a structured and reproducible approach to testing a system. Answer C: It provides checkpoints at various stages of development to ensure the system will deliver what is needed. Answer D: All of the above. So go ahead and make your selection, and we'll move forward in a second.
<pause>

Kenneth Vaughn: Well, the answer is Answer D: The SEP provides a reproducible approach for specifying and testing a system, and provides checkpoints to ensure all user needs are fulfilled. Answer A was incomplete because the SEP includes testing and validation checkpoints. Likewise, Answer B was incomplete, because the SEP includes specifying and validation checkpoints. And finally, Answer C was incomplete because the SEP includes specifying and testing the system. In summary, Learning Objective One: The standard includes user needs, functional requirements, a protocol requirements list that provides traceability between those two, and then dialogs, object definitions, and requirements traceability matrix that traces between requirements and the design concepts. That brings us to Learning Objective Number Two, Identify Specific FMS User Needs for an SSM. NTCIP 1210 ConOps includes architecture, architectural needs, and operational needs, and we'll go through those. We'll also introduce components of the signal systems master system. The NTCIP 1210's concept of operations focuses on the system and its users. It considers the lifecycle of the system, defines the user needs supported by the standard, and provides an operational context for the system. It starts off with a problem statement. Agencies are required to efficiently manage system-wide traffic flow. This is something we know, and we know that that includes traffic signals. However, there are competing definitions for what efficient flow is. Some might say it's minimizing delays, or minimizing stops, and/or minimizing travel times. Others might say it's maximizing throughput, or perhaps even minimizing emissions. All of these are competing demands on a system and they must be managed. There are competing algorithms within each one of these concepts to optimize these measures. So the standard has to allow for all of these different capabilities. Traffic data also changes in real-time, which means we need a system that can manage and respond to those real-time traffic changes. Finally, signal system locals and SSMs are located remotely throughout the city, and need to be managed remotely. So you don't want to have someone sent out in the field every time you want to change a timing plan; you want to be able to do those things remotely through a communications protocol, which is what this standard is intended to serve. So the standardized architecture-- typical architecture that's been around the industry for years-starts off on the right side of this diagram with a traffic signal that is controlled by its local signal system local controller, also called an actuated traffic signal controller frequently. That's typically located at the signal location at the intersection. That may be connected to a signal system master in some architectures, those architectures related to this module. That master is typically located in the field somewhere along that arterial process, arterial street. That master is then connected to either a field computer, a traffic management system, or both. And the NTCIP 1210 standard standardizes that final link between the traffic management system or the field computer to the signal system master. Also of interest though is NTCIP 1202. That communications link is what's used to control the traffic signal local. So, the signal system master needs to be aware of NTCIP 1202 concepts as well as the NTCIP 1210 concepts back to central. Now, there are two architecture alternatives within this of how they actually connect. One, the more traditional, older style, was remote-to-signal systems perhaps, say, a dialup operation, where the traffic management center only dials into your signal system master periodically-- maybe once a day, maybe once a week, or less often. The other possibility is a hierarchical distributed signal system. This is where the signal system master is always connected, but the pattern selection is still performed by the regional SSMs. The advantage of the second alternative is now you can monitor your real-time operations more efficiently. But they both provide for the distributed operations signal system. Based on this architecture and these alternatives, the standards defined the different architectural needs for the standard. The first one is providing live data. This is defined as a mandatory user need. It includes data retrieval, commands, the basic capabilities to exchange data when connected. A second mandatory user need is providing offline log data. This allows dialup connections to work, but it also allows monitoring exceptional conditions, such as I want to know when some unusual condition exists. That way it's detected in the field, the system records it, and then I can later pull that information. That allows the management system to maintain control over the communications on the channel but still be notified when anything unusual happens. So logging is important for situations without communications, or without permanent communications, or when recording field information. The third mandatory architectural user need is connecting communication networks. This is, the TMS often needs to connect to the SSL directly. For example, it made want to change the timing parameters within the signal system local. In order to do that, it has to go through the signal system master. So, the SSM has a user need that it needs to be able to pass through this data seamlessly. It's sits between the two; it needs to be a seamless operation. And the final architectural user need is defined as optional. It's supporting legacy communication networks. We recognize that there are some systems out there that user very low-speed communications through, typically, legacy arrangements. It's not worth replacing these older infrastructures yet; it's better to just standardize the protocol to make more efficient use of the available bandwidth. And in that case, this option is provided. There's actually two options to increase bandwidth efficiency, and you can select the one that's most appropriate for your needs. Most modern systems though are designed with high-speed connections to the SSM, if you're installing a new infrastructure. Well, that brings us to the more operational needs of the standard. So we've talked about the architectural needs and how things are arranged; now we'll talk about what data needs there are in the system. And the operational needs are often called features, and that's how they're listed in the standard. They relate to the informational needs of the users, and they're divided into two major areas: managing the SSM, signal system master, and managing the signal system local device. The signal system master features include configuring cycle timers, managing system timing plans, and monitoring system operations, and we'll go through each of these. Configuring cycle timers and unit backup time includes determining capabilities of the SSM; configures the SSM network of SSLs; and configuring a sync pulse for SSLs. So it's kind of a broad set of just configuring the system at a very basic level. The second is managing the system timing plans. There are several sub-features of this, including a managed section definition set; implement of manual selection plan; implementing a plan based on, either manual selection, TMS command, time-based schedule, or based on traffic conditions; configuring plan selection, mode schedule-, and we'll talk about that a little bit; synchronizing clocks of SSLs; and configuring the cycle length by plan; and we'll talk about each of these. Managing section definition set is defined as mandatory. It allows a TMS operator to assign a coordinated SSL to a section, so you're simply configuring your sections-- this signal will go with this device in this operation. Each section is timed as a coordinated system, so I can group all my signals together in one section, or I can have multiple sections monitored by a single SSM unit. The second is managing system timing plans. Implement a manually selected plan is a mandatory requirement that allows a traffic management system operator to manually override plan selection, and this override will stay in effect until it's changed, once again, by the operator, either by going back to one of the standard plans, or by manually selecting another plan. And similar to, implementing a plan based on TMS command, which is also mandatory. From the SSM perspective, both of these commands are going to be originated by the traffic management system. The difference is, if it is actually generated by the TMS itself, if for any reason the SSM loses communications, it will revert back to its standard default operation if that communication is lost. If it is manually implemented, then it will keep that plan until it's changed. So, why would the TMS system change plans? Well, it might be a time-based logic, or it might be advanced algorithmic logic that is perhaps not supported by the SSM locally. Another way to select your time-based plan or select your plans is by a time-based schedule, which is also a mandatory user need within the standard. It allows the TMS to automatically select the plan based on time of day, or even day of week and holiday. It's very useful when traffic patterns are predictable, and it kind of serves as a default. If you lose communications with your traffic management system, your signal system master has a default schedule applied to it. And then the final way it can select a timing plan is through a traffic-responsive mode. Now, there are in fact two different ways you can select traffic-responsive mode defined in the standard. One is through a threshold algorithm. The other is through signature selection. One of the two has to be selected and you can't support both. This particular user need allows configuration of the features common to both algorithms, whereas each algorithm is separately defined as its own user need. Each algorithm allows selection from a wide variety of plans with different cycles, splits, and offsets. But then that does bring us to the threshold selection and signature selection. As I mentioned, these are optional, but you have to select one or the other. The plan selection is based on the case of threshold selection, it's based on weighted system detector readings as they cross upper and lower thresholds. System detectors are grouped into nine different groups that jointly determine your cycle, split, and offset parameters. In comparison, your signature selection defines a set of signatures based on different traffic flows and then says this plan is based on this particular signature, and how close the current conditions match those signatures is used to select which timing plan is selected. The next user need is configure plan selection mode schedule. Now, we've talked about having a schedule-based selection of your timing plan; this is kind of one level up from that. So maybe on Monday through Friday, I want to use time of day operation, but on the weekends my traffic's so variable, I don't want to use time-of-day operation, I want to use the algorithmic selection, traffic-responsive selection. So, by selecting which schedule, which traffic plan selection mode I use based on schedule, I can say during the week I'll do it time-of-day, and on the weekends, I'll be traffic-responsive. The next option is synchronizing clocks of SSLs. This is also a mandatory user need. It allows SSM to synchronize the time-of-day clocks within the SSL, basically setting the time in the local devices. It provides each SSL with its own common reference point when timing is done using its own signal operations, rather than waiting for a sync pulse. So it's an alternative to a sync pulse. A sync pulse is something that's sent out once every cycle, just basically a pulse on the wire, usually using a separate wire, that is a simple pulse that says, "This is the start point of my cycle." Now, that's a more traditional way of doing things, a perhaps more legacy way of doing things. More modern equipment usually has a clock with feature controller. As a result, the sync pulse is designed as an option within the standard. But if you do use sync pulses, this particular user need is mandatory. So it allows each plan to be associated with a cycle length; the SSM can then generate a sync pulse so that all signals have a common reference point every cycle. So it's an alternative to synchronizing clocks. The next major set of user needs we'll talk about is monitoring system operations. Monitoring system operations includes managing a variety of alarms, which we'll talk about; managing system display data; and monitoring traffic and conditions. The first type of alarm is loss of control of SSLs. This occurs when we lose communications within the SSL from the SSM to the SSL. It allows the TMS to monitor the number of signals it's lost communications with, and it allows that system then to revert back to normal operations, or to revert back to, say, a default set of operations. If I don't have communications to some of my signals, it doesn't make sense to be traffic-responsive, because signals in the middle of my system aren't going to be responding properly. It makes much more sense to revert back to a time-of-day operation. Failed system detectors, similar sort of scenario. If my system detectors aren't working, or if enough of them aren't working, it doesn't make sense to be traffic-responsive. So this allows the SSM to terminate traffic-responsive operation if the number of system detectors fall below a defined level, and it also, of course, allows the TMS to manage the number of detectors that have failed. Other alarms can also be reported. This includes flash conditions. Once again, if you have a signal in flash in the middle of your system, it doesn't really matter if you're going to be traffic-responsive or not. Coordination failures, stopped time, low battery, power restart, a variety of alarms can be reported back to your signal system master and then to your traffic management system. The last group of alarms that are included are SSM alarms, alarms occurring within the signal system master itself. And literally any parameter within the unit can be set people to monitored, and if it exceeds or goes below certain thresholds, then those conditions can be reported back to the traffic management center. The next group of operations that we have user needs for are managing system display data. This allows a TMS operator to monitor data needed to ensure proper, efficient operation of the system. For example, this may be data that's shown on their main user screen or the system map. It includes fault information, current configuration and status of the SSM, and certain status information for each SSM. And the final system operation user need is monitoring traffic conditions, which is also mandatory. It allows a collection of volume and occupancy data summarized over a period of time, and this can be particularly useful for determining when new timing plans might be needed. You can record what these values are when you first install the system, and then monitor them over time, and when they exceed certain thresholds, you can say, "Well, we need to retime our system." And that brings us to the next major grouping of user needs, which is actually just one major user need: Managing signal system locals. Now, this is defined as optional within the standard, but really, if you read the details of the standard, you discover that in fact every single deployment will have to include this, because every single requirement traced to this user need is defined as mandatory one way or another. And in fact, this repeats largely one of the previous user needs for connecting SSL networks. So it allows communications with an SSL; data to be exchanged is dependent on the type of SSL, but since we're dealing with signal systems, it's largely defined by NTCIP 1202. The standard label is this is optional, but in fact it is required because of the architectural requirements. That brings us to our second activity. Which user need allows the SSM to instantly notify the user of unusual traffic conditions? And I emphasize the point "instantly notify." Which one allows the SSM to immediately report, regardless of whether or not the TMS is asking for information? So, the options are, A: Provide live data. B: Provide off-line logged data. C: Forward SSM alarms and events. Or D: This user need is not supported by the standard. Please go ahead and enter your information now, and we'll review the answers in a second.
<pause>

Kenneth Vaughn: All right. Well, the correct answer is the user need is not supported by the standard. Now, we recognize that some agencies do in fact want to use this and have this as a true need. That means your project will need to define how this will be achieved. Recognize we are working on a solution to this within the standards process that won't be defined in this particular standard it will be defined in the lower layer standards but this effort is active currently and we are trying to find a solution. Providing live data is incorrect because SSM will only provide live data in direct response to a request. Same with Answer B, providing off-line logged data. It does not respond an instant response; it only provides logged data, in direct response to a request. Finally, even forwarding alarms and events only provides this data to direct response to a request. So in summary of Learning Objective Two, we reviewed the operational needs, and they include configure cycle timers, managing system timing plans, monitoring system operation, and managing SSLs. Learning Objective Three is use protocol requirements list to select user needs and link to requirements. We'll learn how to indicate which requirements are to be implemented for a project, check conformance to NTCIP 1210, indicate capabilities of an implementation, and check the interoperability with another implementation. The protocol requirements list is a table that maps user needs to requirements. It traces them so that we know which requirements are associated with which user needs. It can be used to select requirements for a project; it can be used to assist deployments by providing a checklist; or identify capabilities supported by an implementation; and finally, it can compare two implementations for interoperability. Selecting user needs is dependent on mainly four columns in the table in the protocol requirements list. The first two columns relate to the user need. The first defines the clause number, and the second defines the title of that clause. So that clause number allows you to go specifically into the standard and read as much as you want about that user need; whereas the user need title gives you a shorthand notation for what that is. The other two columns of importance are your conformance column and your project require column. The conformance column defines whether the need is mandatory or optional. And in this case, we have a more complicated conformance of definition of O.1 (1..*). The O means it's optional. The .1 means it's part of the first option group, so it'll be multiple records all part of this option group. The 1..* implies that there is one or more options from this group is required. So, out of this option group, configuration threshold selection, it is part of one option group-- so it's not strictly mandatory-- but you must include this or one of the other options within the group. And if you remember what we just discussed, yes, this is the user need we talked about where you must select either this threshold selection or the signature selection. So one of these two options is required, but you don't have to support both. The way you select your proper value is by simply looking at the project requirement column, where it'll tell you either yes or no. If you want to support it, select yes; if not, select no. That brings us to the next activity. In this case, we have a scenario, a sample project to deploy SSMs. Suburbanville wants to upgrade its old closed-loop system so that it supports ITS standards. They want regional masters to control normal operations. They want to be able to monitor detailed operations of local controllers when needed. And they want time-of-day operation selection, and signature selection for traffic-responsive operation. Finally, they want instant notification of unusual traffic conditions. Which of the following user needs does not need to be selected for our scenario? Answer A: Implement plan based on time-based schedule. B: Configure traffic-responsive mode. C: Configure threshold selection. D: Configure signature selection. So take a second and go ahead and answer, and we'll talk about the correct answer.
<pause>

Kenneth Vaughn: Well, we find that the correct answer is configure threshold selection. This user need is part of the first option group and can be omitted if 251-253 is selected. And in fact, since we require it as part of the project plan, configure signature selection-- that's a stated project need then this option can be omitted. Option A, implement plan based on time-based schedule, is incorrect. This user need is needed for time-of-day pattern selection and is defined as mandatory. Option B, configure traffic-responsive mode, is incorrect because it is also defined as mandatory. Option D, configure signature selection, while this is optional, it is required to support the stated project objective of signature selection. So that brings us to the next question: Which of the following user needs does not need to be selected for our scenario? Answer A: Provide live data. Answer B: Provide offline log data. Answer C: Support legacy communication networks. Or Answer D: Manage system display data.
<pause>

Kenneth Vaughn: Well, we find out that the answer C is the correct answer, support legacy communication networks. This optional user need is not necessary for the project's stated goals. Answer A is incorrect, providing live data, because that need is defined as mandatory. Likewise, option B, provide offline log data, is also defined as mandatory. And option D, manage system display data, is also defined as mandatory. Well, the protocol requirements list is a traceability to requirements. It has user needs to describe what features that device needs to support and why. Functional requirements refine the user needs into detailed, measurable specifications. Within the PRL, the relationships between user needs and the functional requirements are standardized. User needs justify and explain requirements, whereas requirements refine needs to measurable concepts. This promotes interoperability. It does not provide interoperability yet; that's done within the design. But this promotes interoperability by putting everyone on the same page up front. The other columns in the table include the functional requirement ID and the functional requirement title. Once again, the ID references a specific clause within the standard that you can go read about, whereas the title provides a shorthand notation for that. Likewise, the requirements include a conformance column. That column includes all of the notations we've discussed before, and you may also see a predicate condition. For example, in this example, we have threshold:M. The threshold is a predicate and it means if threshold is supported, then you must support the mandatory must support the particular requirements. The specific predicates are defined in clause 3.2.3.2, and you can look up that clause in the standard and see what threshold means, and it points back to the user need we talked about before of threshold selection. Now, it should be noted that right now the threshold is defined to be user need 2.5.1.2.5.1. That's actually a typo in the standard, and is one of the various typos and issues within the current standard that need to be corrected. It actually should be 2.5.1.2.5.2, but the intent is clear: If threshold selection is supported, then this requirement is mandatory. The protocol requirements list's conformance column has a built-in predicate between needs and requirements. So in this case, if you select Configure Threshold Selection User Need, then the requirements underneath that user need automatically include that predicate. So, Configure Detector Grouping, if that need is supported, then it becomes mandatory. Otherwise, you don't necessarily need it. Likewise, Configure Queue Detector Override Thresholds is defined as optional, and that means it's optional even if you select Configure Threshold Selection. So, what does mandatory versus optional really mean when you go down to the requirement level? If user need is not selected, its associated requirements are not necessary, unless they're required by another user need selection. So in this example, we have manage SSLs is defined as an optional user need. So if I decide I do not want to select Manage SSLs, then the requirements underneath that are no longer necessarily applicable. Explore SSL data by the TMS is not necessarily needed. However, elsewhere within the PRL I have Connect Communication Networks. That user need is mandatory. Therefore, I must select that user need, and by selecting that user need, I will automatically get the mandatory requirements underneath it, including Explore SSL Data by the TMS, which, as we just discussed, was included under Manage SSLs. So even if I don't select the requirement at one location, if I select it anywhere, that means it's required on the project. Additional Project Requirements is the final column in the PRL, and it's used to enter additional notes and requirements. Defining performance ranges and sizes of data tables is the typical use of that column, and it's to provide further details about implementation. So the example given here is I might define responsive start time for all requests shall not be greater than however many milliseconds. That brings us back to our next activity. Once again, we have our sample scenario. Suburbanville wants to upgrade its old closed-loop system. It wants regional masters to control normal operations. It wants to be able to control and monitor detailed operations of local controllers when needed. It wants to use time-of-day pattern selection and signature selection, and it wants instant notification of unusual traffic conditions. So our question is: Should the following user need be selected for our project? The user need is configure cycle timers and unit backup time. So go ahead and make your selection.
<pause>

Kenneth Vaughn: Well, the correct is Yes, it is a mandatory user need, and therefore it is required. The mandatory need is always selected. So the next option then is: Should the following user need be selected for a project? In this case, we're talking about configure threshold selection, yes or no.
<pause>

Kenneth Vaughn: And the correct answer is No in this case. The user need is not needed to fill stated project capabilities. The configure threshold selection user need is optional and it's not required since it does not support traffic pattern signature capabilities, which is the stated focus of the project. It's a little bit more complicated, but hopefully you got that one right as well. And what about configure signature selection? Is that user need selected for this project or not?
<pause>

Kenneth Vaughn: And here the correct answer is Yes. Configure signature selection is the need that is stated in the project requirements, and No would be incorrect because it's required for the capabilities we selected. The protocol requirements list can be used in a variety of ways once it's filled out, and can be filled out for a number of purposes. In the agency's PRL, the PRL that the agency fills out can be used for a variety of ways. One is specify the needs and requirements for a project. So I can tell manufacturers the product I'm looking for my particular project. The requirements map to interoperable design, and that way I make sure I will get something that works with my system. That specification can be included within your PS&E package, or plans, specifications and estimates. And a vendor then may provide a product, and that product may actually exceed what you asked for. This is kind of the meet-and-exceed specification. That means it can support features not selected, and it allows the vendor to create one product, and he can then bid on multiple projects. So maybe his product supports both signature selection and threshold selection, and he can bid on either one of the two projects using a single off-the-shelf product. It can be used as a checklist during development, and serves as the basis for selecting test procedures. Now, the vendor himself may have filled out the PRL, and he may do this to reflect what he provides as his off-the-shelf equipment. This quickly tells agencies which features the particular device supports, and the agency can archive this information with the project documentation; that way when the next system upgrade occurs, they have a better idea of what's actually out in the field, rather than just what they asked for. Finally, it could be used as a valuable tool to gauge the degree of interoperability. For featured work, both the management system and the device must support a feature. Likewise, interchangeability is similar, but interchangeability deals with replacing one device with another, and you're comparing the two devices-- two PRLs from the two different devices. So in summary, the PRL links user needs and requirements; it allows selection of user needs and requirements; it provides a checklist for features to consider; it provides a listing of friends supported by an implementation; and provides a useful way to compare products for interoperability. Our next learning objective deals with explaining how the PRL table of the standard integrates into an FMS specification. A completed PRL defines the data requirements for the interface. When this is combined with the communications specification, as discussed about in C-101 and other modules, it forms an interface specification, a complete interface, not only just the data requirements, but also the lower layers. A deployment may need multiple interface specifications because a management system may need to operate multiple types of devices, in which case it needs a different interface specification for each different device type. Likewise, you may need to support legacy protocols. So, both the device and the management station, or one or the other, may need to support these legacy protocols. A device may need to support it because you may be adding it to a management station that's older. Or a management station may need to support it when you're putting in a new management station and you're expected to work with the older equipment. What's also very important is that your specifications are consistent throughout. So, the interface specification must be consistent with the remainder of the specification; in particular, the hardware specification and the software specification. As an example of this, you can think of synchronizing clocks. That's one requirement we talked about. It implies the existence of a clock within the SSM, and it requires software logic for the SSM to periodically synchronize their clocks. So all of this must work together as a single unit, and there have been cases in the past where the specifications have been inconsistent and the manufacturer has come back and said, "Well, yeah, we support the interface. We just don’t support the hardware capability." So what you want to make sure is that you have completely consistent specification throughout. So, some sample text of the PRL should be properly introduced within the specification. A copyright disclaimer should appear with a PRL. That's a requirement of the PRL as defined by the NTCIP standard. And additional requirements are actually needed for the NTCIP 1210. This is another area where the current version of the standard is lacking. NTCIP 1210 fails to identify all the necessary additional project requirements, such as number of intersections that must be supported by the device. Now, this isn't absolutely something that has to be in the standard, but it is a very useful tool and it really should have been included. Instead, we've currently included them in the student supplement, so you can look at the sample text within the student supplement and you can identify all of the additional project requirements that should really be included in your filled-out PRL table. That brings us to the next activity. Which of the following statements is false? A vendor may support features not selected in the PRL. The PRL forms a complete interface specification. A deployment may support multiple interface specifications. This interface specification must be consistent with the hardware and software specifications. So go ahead and make your answer.
<pause>

Kenneth Vaughn: And the correct answer is the PRL forms a complete interface specification. That is false, because the PRL must first be coupled with the communications specification in order to form the complete interface specification. The vendor may in fact support additional features not selected, and that allows them to provide a single product to different projects. That's meeting or exceeding the standard. A deployment may in fact support multiple interfaces, and we discussed that a traffic management system may need to support multiple devices, and thus multiple interfaces. And likewise, a field device may need to support a legacy protocol as well as the current standard. Finally, the interface must be consistent with hardware and software. All interface portions must be consistent with all parts of the specification. So, in summary, the PRL should be included in the specification; should not conflict with other portions of the specification; and should be supplemented with additional text per the student supplement. Well, that concludes our presentation today, with a summary of: NTCIP 1210 defines the concept of operations and user needs for signal system masters. NTCIP 1210 follows the SEP approach. There are four major categories of SSM user needs: configure cycle timers; manage system timing plans; monitor system operation; and manage SSLs. A protocol requirements list is used to link user needs to functional requirements. Then finally, a completed PRL should be integrated into the project specifications. Additional resources are available at NTCIP 1210 version 1.53, Field Management Stations, Part One, Object Definitions for Signal System Masters. That is the actual standard. The NTCIP Guide is also a useful tool, as found in NTCIP 9001. Both of those documents can be downloaded from www.ntcip.org. And you may also be interested in IEEE 1362. That’s the guide for information technology system definition concept of operations document. It defines what's in a concept of operations and how that's put together. That can be found from www.ieee.org. One question that frequently comes up is a little bit more information about the content of the final annex of the standard. And the final annex of the standard deals with the hierarchy of the different options of signal timing. So, for example, the traffic-responsive plans are the most important, or the highest alternative of timing operations. If you don’t have a traffic-responsive plan defined, then it slips back to other needs. And all of that is defined within the standard in the final annex, and all of the configuration logic for that. And with that, that concludes the standard, and I thank you for attending this session. The follow-on module is Specifying Requirements for Field Management Stations, Part One: Object Definitions for Signal System Masters, based on NTCIP 1210 standard. It reviews the requirements contained in the standard. It shows relationships between requirements and design. It shows how to select and refine requirements using the PRL. And it's the final module in the SSM procurement path. You may also be interested in the testing curriculum path, as we mentioned before. So, thank you for attending the session today, and we look forward to you attending future modules. Thank you.

#### End of 2013-01-15 13.09 A304a Final Recording.wmv ####