Module 34 - A317b

A317b: Understanding Requirements for CCTV Systems Based on NTCIP 1205 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.

Ken 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 am Ken Leonard, the Director of the U.S. Department of Transportation's, 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 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 www.its.dot.gov/pcb. 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 lecture will pause at each quiz section to allow you to use your computer mouse to select your answer. There is only one correct answer. Selecting the submit button will record your answer and the clear button will remove your answer if you wish to select another answer. You will receive instant feedback on your answer choice. Please help us make even more improvements to our training module by completing the post course feedback form. This module is A317b, Understanding Requirements for CCTV Systems Based on NTCIP 1205 Standard. Your instructor, Dr. Raman Patel is President of RK Patel Associate, Inc. Dr. Patel has 40 years of experience in the transportation field and has been actively involved in the ITS Standards development and Standards Training Program and has served as Chair of ITE Standards Committee for past 15 years. He is a member of the NTCIP and TMDD Committees.

Raman Patel: Hi. I am Raman Patel, your instructor for this module on the CCT requirements. The target audience for this module includes engineering staff who are engaged in building, designing and operating CCTV systems as part of the Traffic Management System, freeway Management Systems, also the Traffic Management Center operational staff, those who work 24/7 dealing with these issues about traffic management in general and use CCTV systems in particular. System developers who actually design, build and integrate these various components of traffic management systems are also the beneficiaries of this module. Private and public sector users including the CCTV manufacturers who are supplying these products to the public sector will also benefit from this discussion today. And of course, the end user, the traveler and the information service providers that use real time information for travel management decisions will also benefit from this module. There are certain recommended prerequisites for this module. Here we see I101, A101, A202, A103. These modules are preparatory, they are introductory modules that prepare you, outline the benefits of the standards and then certain issues. A102 and A103 are actually about the user needs, a more detailed discussion on how to identify user needs and also the requirements in A103. A201 and 202 and 203 actually a little more details in terms of how to go about preparing the specification acquisition process and dealing with the issues and identifying, writing the user needs in A202 and A203 about the requirements. C101 module is specifically for the communication protocol stats. There are several levels of NTCIP stats that have been discussed in details and you should be familiar with those as well. And A317a is very close to this module class discussion because A317a deals with the user needs, how to identify and understand and building a CCTV requirements. So today we are following up based on what work we have done in that module. So the curriculum path is non-SEP systems engineering process is used for developing certain standards and this module particularly, in this curriculum path, we have not used the SEP process so the CCTV standards were developed without SEP. So at the bottom of the last row here you have three modules pertaining to CCTV and today's modules in the middle A317b is what we are discussing. So learning objectives, there are five learning objectives for this module, the first one being the how to develop requirements using NTCIP 1205 standard. We will also deal with learning objective two in terms of interoperability and vendor-independence, how do we achieve those are two key criteria and ends in the discussion about how to clarify those issues. How to test certain objects design requirements, those are part of the learning objective three discussion and in learning objective four we will be required to understand what we do if we have certain requirements which are not actually included in the standards and what do we do. So that process we have to discuss also. The last learning objective deals with the specification, how do we prepare a well developed spec so that we end up getting what we are really looking for in our specifications. So let's start with learning objective one, how do we develop requirements using the standards process that's in front of us in 1205? So we need to review the structure of the standard, what's in the standard, what is available, what is not available and then deal with how to develop the user needs based on A317a, we already did a lot of work and we'll use that part in terms of identifying requirements in this module. Configuration-control and monitoring perspectives are also very well known to us, we'll deal with those in terms of defining and developing actually the requirements based on that. Also, other standards such as dynamic message signs, ESS and a couple of other standards have been developed using SEP process so we can learn from those modules and derive how we can actually help ourselves in this module. So we'll be doing that. And then review the criteria for well-formed requirements. It's a detailed process that we have to follow because this particular standard does not have requirements written for us so we'll have to do that ourselves and we'll learn how to do that in this module. And finally, we'll have some examples in learning objective one. So let's review the structure of this standard. The first section in the structure wise is the section one deals with the overview, system overview, what CCTV is and a couple of terminology that has been used in the standard making will be covered in section one. Section two is more general, its references is in there. There are other standards that need to be used in connection with this standard so that has been discussed in section two. There's also an appendix, has a lot of extended glossary, terminology, what they mean and overall context is in there. And the key part of this standard 1205 is section three which contains about 75 data objects or MIB, as we call the collection of objects in the MIB, Management Information Base. So these 70 objects or so are there, they are organized, classified under 11 different nodes and that's what makes this system unique. Section four has several conformance groups, four of them. The first one being the configuration conformance group which is mandatory, which is required to comply with this standard. The other three, motion control, extended functions and on-screen manual, they are optional; they are used only when we really have to in terms of our requirements in the specification. So now this section three and four are very well connected by this display here about certain groupings of objects from MIB are parked under these four configuration groups. People who developed these standards have actually preselected certain objects that you will need to comply with the configuration group, for example motion control, extended functions and on screen. And the examples of these objects, may be position objects, time out objects, some control objects, leveling objects. So those are already classified and section four allows us to tap into that resource. In order to understand the specification writing process we also have to understand all the terminology being used in building a system such as a CCTV system. From the operational context, operational standpoint, we have to make sure that certain terminology, key terminology in this case should be understood so that we can actually write our specs properly. So for example, here we have on the left here, focus. So focus allows us to control the resolution, remove the blur and get the right and bright images that we are looking for. So that allows us to actually clarify the images to our satisfaction. Iris on the other hand allows us to move to control the aperture of the lens so that the amount of light can be controlled. Some situations like in the dark areas for example in tunnels, in the evening hours and so on, sometimes it's necessary to change the lens condition so we can get proper images. Not always but sometimes we use that feature very, very productively. On the right side, you have pan-tilt and zoom. These are three functions in one motorized mechanism that allows us to actually move the camera position horizontally which is called pan, vertically which is called tilt and zooming and detailed view. So this motorized function actually is very heavily used by traffic management centers and we need to understand to what degree we can control our camera and that also puts requirements in a very tight situation. So we have to understand that feature and how to write the specs accordingly, requirements. Presets is a setup or location of where the camera is actually looking at it, its position. So these are sequenced one after another so when an operator wants to look at very quickly, a certain region or area and he or she can use it a very productive way by pushing buttons and not having to actually figure out what location it is. So this is a pre-sequenced, predetermined and it's been used very heavily so people can actually use it. Sometimes we also call a guide, tour guide, meaning that one preset position will be followed by another and that will connect to parts of the areas so that people can look at in a very linear fashion in terms of the images that are coming in. Labeling is also allowing us to label where the camera is, location of course as well as the direction of the images, what view are we looking at it. People, you heard probably many times asking, what this camera is, where is this camera, what image it is showing. So that part of the discussion and the operational context is coming alive in this terminology as well. So collectively speaking, this terminology prepares us, it makes us aware of what we are about to do in requirements writing process and each one of these terminology will be used in preparing a complete set of requirements for our project. Here's an example, real world example of how CCTV camera functions are used. This is a combination of both software capabilities as well the functional capabilities that the device brings to the table. And although the software requirements are also separate, we'll return later on, but the functional requirements are also playing up very well. We just talked about pan-tilt and zoom for example. So you can view the camera position and you can move it and then you can look at the picture and then get more details as you really are looking for in terms of how you are conducting your traffic management decision making process. So collectively all these terminologies are now working out inside this interface, system interface at the TMC and we can actually visualize the images in a way we intend to. CCTV information requirements for specification, there are two that are not available, user needs are not available in 1205 standards and we talked about that in the previous module A317a. Today we are saying requirements are also not available so we'll have to develop them. Objects and dialogs are available for CCTV. As I mentioned earlier, 70 objects are already defined in 1205 and there are dialogs to carry out this conversation with a device are also available in generic sense, so we are okay with those two. However, the last two, protocol requirements list, PRL and requirement traceability matrix, RTM, these are tools, they are tables, they are not available CCTV. Some of the other devices in NTCIP environment, for example DMS, ESS, they have PRL and RTM already as part of the standard. In our case, for CCTV, we don't have them available so we'll have to develop them. So what does a requirement actually mean? So we want to say that requirement is actually a translation of user needs in a very elaborate way, descriptive specifications. It is a definition device so that has been used in our discussion and it brings characteristics, it adds to description in several ways and makes our user need definition more distinctive, it has more detail in it and it makes more usable with a requirement as a force. So with that said, let's look at this example. For example, here, in this particular requirement we are asking CCTV device to allow the management station to remotely turn on or off the camera operation. So this definition is very good because now it translates a user need in a very concrete way. So the burden is placed on the device to the requirement, burden is placed to the requirement to the vendor who supplies this device and say, "Okay, now you're gonna have to make sure that this device actually performs the way the user intends it to do." User needs and relationship to requirement is very concrete. Sometimes you have one user need that may translate to one requirement, other times you may have one user need that may require more than one requirement to build the system, multiple requirements are tied to one user need. Other times you might have just one user needs or more than one user needs probably is sufficient to be met by one requirement. Substitutions do exist in different forms and we need to be able to build with them. The approach to CCTV requirements has two inputs. The first input is coming from A317a, we discussed what the user needs are, we identified them and we have detailed analysis of what they will do for us. So we will derive from that input a mechanism for requirements. We also have configuration, monitoring and control perspectives known to us from our practice as well as from the previous, the other standards that we have been talking about like DMS, ESS. So with these two inputs, we are ready to go into a two step process to develop the requirements for CCTV. And we are also prepared project PRL and project RTMs. Throughout this discussion we'll be talking about those two and come up with some good level of understanding. So the step one for example, to develop a well formed requirement requires a structure, we need to provide a structure to the description. I said earlier the user needs drive the requirements in a sense, now we have to provide the structure to the requirement. So there are at least five major elements here that we need to view. We need to provide in the requirement an actor. An actor identifies who does the action. The action will be identified in the requirement and it says, "What really needs to happen?" And then the target, "Who will do it?" In this case, our case CCTV device will have to provide whatever action is requested by the actor for example, management station. So we have these terms attached to our components in the system. We also have certain constraints and measures of success, how do we actually measure a requirement has done what it's supposed to do, so that part has to be built in. And of course, the localization, certain conditions that may be just reporting to the local project or region or something like that. There are not that many maybe but when they are there we have to actually account for those. So these five elements make up the structure for a good requirement. Then we have certain characteristics. These are characteristics actually they form a good level of details in a very concrete way. For example, necessary, this is the very reason why we are writing a requirement, if we have necessity then certainly it should be passed into the requirement. This is the most important element in the requirement is that it must justify, it must identify why we are actually even writing this request to begin with, And it has to be concise, it cannot be just a very detailed description like paragraphs and paragraphs, it has to be concise and just succinctly written so that we can provide a format so it can be actually met. It's also written in a shall statement so it has a force of implementation of both sides, the person who writes the requirement and the people who actually fulfill it. So there is a level of implementation force. Attainable, of course it has to be practical, it has to be doable. For example, a CCTV camera look at the terrain or it looks at the pavement, right, so CCTV camera is not intended to look at the sky. So we have to be very practical and reasonable in our writing process so we are not asking for something that's not attainable. And then it has to be standalone, every requirement speaks for itself. You don't have multiple requirements trying to do the same thing more or less so standalone nature must be preserved. Then it has to be consistent, you cannot have one requirement work against the other and then somebody has to figure it out what really it means. So consistency across the requirement process is very important. Unambiguous, the nature of requirement is very appealing, we cannot write a wishy-washy language for example, if we say it that way, it has to be very concrete and very clear and it should not say something like, "Ask for the specification and leave it ambiguous," or it shouldn't say, "Ask for the agency direction," and then nobody knows what the direction is to mean. So some of these ambiguities must be removed when we write the requirements. And of course a requirement has to be verifiable, verifiable in the sense that if you inspect, if you analyze, there has to be a way saying that, yeah, this requirement is actually met or not met. So these seven components together provide us a strength and in a concrete way and make the requirement that much stronger. Now let's apply this two step process in providing types of CCTV requirements that we really need. So the first level of discussion we had about structure that should go into the requirement and then also incorporate these seven connective states and come out with a good set of requirements that we really need for CCTV. The overall purpose as we know in NTCIP environment is to achieve remote management of a device, in this case, in our case today we're talking about CCTV device, right, camera control. So we are doing that remotely. So there are types of requirements that we have to recognize. The first is the architecture requirements, it supports the communication to the device, it provides general capabilities so that we end up actually telling the device what to do and we get the information. So this communication nature of the architectural requirements is very appealing. For example, SNMP interface, it actually helps us to communicate to the device in a very concrete way. So this requirement needs to be spelled out. Second set of requirement is the data exchange requirements, what are the functions that we are trying to control? For example pan-tilt and zoom will fall under this classification. So data exchange requirements are-- keep out of our discussion here today. Also supplemental requirements, sometimes the standard doesn't have what we really need, maybe there's a local requirement that you have on certain projects. There are not too many of those exist out there but if they do then we have to know and acknowledge and you learn how to deal with those. So organization of CCTV requirements also follows the section I'm numbering here three like every other CCTV based standards they also use section three for requirements. So we follow that pattern as well and we have organized our CCTV requirements for today's discussion in this module under section three. Section 3.1 generally deals with the background information, prepares you for what's coming your way. 3.2 deals with architecture requirements and has two main components in it, it provides the live data and provides offline data. 3.3 for example, deals with all those functions and features that we talked about, pan-tilt and zoom, configuration management monitoring. And then last, 3.4 is supplemental requirements if there are any, if they at all exist. Let's look at the architecture requirements, architecture requirements are communication related. They provide us the capability between the management station which is at the TMC, Transport Management Center and the CCTV device which is in the field. So in between, the communication process takes place and that's what architecture requirements are about. And there are at least four that we have to ensure that we are actually identifying and writing requirements about. The first one is retrieving data from a device. A CCTV device has a lot of information there and we need to be able to retrieve data from the device. Second is to deliver your data. We are now controlling a device, so we are bringing data to the device in the communication process and that should be taken care of. The third part here is the exploring, the device itself has a lot of data in it, sometimes they store it and we need to be able to explore for our advantage and use it in traffic management system as we see fit. The last one here is the access level. Not everybody has access to the device, there are certain priorities and levels of access are assigned based on that. So we need to be able to manage how to actually allow access to CCTV device in the field. Architectural requirements supported by 1205 standards starts with the providing live data control. When two systems are connected in real time we should be able to get the information to the device and get information from the device to the management station. Second part is also certain times we don't have connections to device, for example dial up links, we only get the link restored when we dial for example or when we have loss of communication for any other reason. So in this process when the communication is restored, when we have actually dial-up communication available, later on we should be able to provide offline data, we should be able to go to the device and ask the device to upload the data when the process is restored, communications process is restored. Those requirements, for example here have an operational nature. This example here about the operational user need, it says, provide live data so in that case we are also following the title of the requirement 3.2.1 is also following the green text above and titled for the user need. So the requirement here, 3.2.1 is to provide live data. So in there we have two sub requirements, one is retrieving data. So it says the CCTV device shall allow the management station to retrieve data from a camera control receiver. So that one part is good because now the device is put on notice to make sure that that capability already exists. And then also, we should be able to deliver data to the device, telling the device what to do and a particular feature control and command as we might say and the device should comply with that, device should allow that. So we have written these requirements, both of them in such a way that we are actually getting this capability that we are looking for through these requirements. Same thing for offline, as we just talked about it, earlier this condition apply when there is no connection available and then we need to get the data when the communication is restored. So in this case, the requirements are also clearly talking about it. The second one, here for example, 3.2.4 at the bottom, is about clearing a log, the log data are too many as in the previous one, so when a device is not able to communicate to management station, it stores certain data in this logging process inside the device and that is ready and unavailable when the communication is restored. So sometime when we have the communication restored later on, we are going to go and clear up the log after we download it, right, or upload it by the device, either case. So clearing is a function sometimes we ignore because we may not be aware of it, but it's a very important one. And point being that the device has a lot of data and we don't really want too much data stored unnecessarily so it allows us to formally clear the device of data log that doesn't need to be stored anymore, right? Data exchange requirements are the core part of our discussion because these requirements allow us to get what we really want the device to do. And the requirements are about managing a device configuration. A device configuration is the first thing we do, not just in CCTV but across the entire NTCIP environment, we have to prepare a device and prepare it nicely, solidly so that this mechanism works as we intend it to do. So we're going to a lot of communication into the device. So we need to set up a device for that purpose and that is what configuration is about. So we need to manage configuration device, ID number, model number, make, whatever location, where it is, all of those things are taken care of and then we move onto the second one which is the controlling device function, it could be pan-tilt and zoom as we have discussed before and all of these requirements fall into this classification. Monitoring, the device stores a lot of data, sometimes it has a condition available in real time and we need to monitor, for example, what a CCTV device is doing right now, right, and we want to know the status of it. So we have to be aware of how we structure these requirements in terms of when we exchange actually data, we are successfully conducting our dialogs with the device. So the Center to Field Communication basically deals with that in a general context. Very often we have devices share the communication channel, so here for example, we're showing a traffic signal and a CCTV are sharing a communication channel. So we need to configure them properly so that we actually talk to a CCTV device when we need to and not end up talking to traffic signal controllers. So you can see the implication of how configuration has to be done properly so that our success lies there when we do actually the first time right. Where do data exchange requirements come from? Well we said that for the CCTV user needs have been discussed in Module A317a and in that supplement for that module we have a lot of listed user needs are out there discussed in a very proper context that follows. So some of these user needs were discussed in 317a has a configuration, configuring device, CCTV device, a move and control camera in the field, set-up a camera tour, set-up zones, I mean, the camera zone as well as the video images sharing. All of these things are required for proper usage of a CCTV system and they have been discussed. So we have a source available in terms of how we're going to develop our requirements for CCTV. Let's look at the example here of a configuration of a device. So we had a user need, says configure a CCTV device. No we have to develop a requirement to meet that user need. So here it says, remotely configure a CCTV device. So the requirement has a title, a very succinct, concrete title that actually significantly says that this is about remotely controlling the device, right? And the wording that follows now includes some of these components that we have discussed. It says, the CCTV device shall allow the management station to remotely configure the camera preset position for a maximum number or 255 in this case. So you look at the management station is an actor, it initiates the action that's necessary and it tells the target device, what to do. So since the device is a target, management station again, a management station is an actor that initiates the action and the action itself is remote configuration. So you can see this combination of actor, target and action really brings the force on this description here. Let's look at the characteristics, are they present here in this discussion about configuring a range maximum preset? The answer is, yes, it's necessary because without this requirement we cannot configure a device and without configuring a device you cannot do any other things after that. So we should be able to configure a device very nicely right up front. Then we have a concise statement here, it's not a long, it's not detailed enough to confuse anything and it has attainable characteristics. Yes, we have been doing this thing for many years in the industry so it can be done, there's no problem with this particular way of writing our requirements. So it's a standalone, yes it seems like it's a standalone, it's consistent, yes, it is not ambiguous, it clearly says want to access so we're going to fill that number, right, so once we do that the ambiguity is now removed. And of course, when the system is built, we need to verify whether we have been lucky enough or successful enough to get the requirements fulfilled. So this is how the characteristics parts of the requirement development process works out for us. Example of pan-tilt-- sorry, in this case we are talking about pan, pan control. Let's look and see if it ensures the structure and characteristics, So CCTV device shall allow the management station. The management station is already an actor here, it initiates the action and the target is CCTV device. So now we can read, it says that CCTV device shall allow the management station to remotely control a camera position horizontally. Now when we say the pan-tilt and zoom, in all of those three terminologies, we will run into detail. Here, in this case of pan, for example, we are saying concretely in a very unambiguous way, we are saying that we want the camera system to move horizontally between zero to 360 degrees. So notice that, the description of requirement reflects a very concrete information. So the camera position can be now moved from zero to 360 and it's verifiable. Take a look at the tilt part of this discussion that we had earlier. Again, we ensure that there is an actor in this description, the management station is the actor, the target device is CCTV and the remote control is the action we want from the device, right? So again, the detailed description or making the requirements unambiguous comes from the fact that we are providing tilt is plus/minus 90 degrees. So we inserted this detail enough to make the requirements concrete, so there are now no questions asked in terms of where or how vertically the camera should move. We are saying it should move 90 degrees up and 90 degrees down, so we are covering our base very, very clearly. Third important function, we have always wanted to talk about and always use is zoom operation, camera has this capability to provide so that we can remotely control a device, a motorized camera lens which is sitting actually on a mechanized motorized process actually and we need to be able to move or control position remotely from the management station so that we can actually adjust the lens to give us a wider view, So our purpose is to create a wide view or viewing so we can actually gather more details. Now remember, the more details is needed to verify incidents and so on and we are all familiar with that part. So the camera capability provides us the wide viewing angle. So that's on the left, right? Now why do we need it? Sometimes we have to figure out what is going on at the location or in terms of the event. For example, if there's a chemical spill and you're dealing with leakage, so for getting a wider view we're going to look if the actual chemical is leaking through some other part of it. For example, in a bridge environment, you might have an incident on the upper level and a chemical might already have been leaked to the lower level. That happens, in the real world you'd be surprised what kind of things end up actually happening. So such notion or capability that the camera position can bring to us in providing wider view is present here in the left side of the picture. On the right side you have lots of people walking. We are not interested in the detail, good size or good view of pedestrians, but we want to know whether this area of impact is longer, it's not just small concentrated area but has the impact over a longer area, larger area rather. So that's what's on the right side. We have a lot of people are walking there and we are now addressing in terms of telephoto. So this is the capability that the camera system has that we are actually controlling from a traffic management station from TMC. So we see what kind of activity needs attention from TMC. So together this zoom operation does wonders for us, both in terms of detail and in terms of the impacts over the larger area. So these capabilities, if you want, we have to pay real attention to this because this is really the core. So actor again is the management station, the target device is the CCTV device in this case; action is remotely adjusting for wide and telephoto. Now this is standalone? Answer is yes; it's standalone because it's written very succinctly but is it necessary? Now in the nature of necessity, it also implies whether you are a small city or an urban area or, you know, it may have local conditions that may or may not be necessary. So we have to answer that question before we move on with the zoom operation. The time out limit of our zoom operation, what it suggests that if a camera is working in one position, how long is it going to stay there, is the camera going to move on its own. So this requirement addresses that. So all camera functions in CCTV standard have time out limitations, so if you don't ask for it, you will not get it. So in this case, a CCTV device shall allow management station to adjust the time out of a zoom motion for example, right, and it gives a number here in terms of milliseconds. So what happens is that if you don't write this requirement concretely and you don't write anything, it's zero, you don't get it, right, that is not provided. If you write for example one milliseconds, it's really no good, it's a very limited capability. But on the other hand, if you write certain range as in this case, about ten or eleven minutes, then that camera will dwell in that particular position and you don't have to do anything until at least that time elapses, right? So this is a very well structured requirement because many agencies, they don't want to go out and play with the camera, every five minutes, right? So you will leave that position in there and it's really a good need that exists out there and that's being addressed here. So it has a structure as well as the characteristics that should be in a requirement. The zero means, as I said, this time out feature is not supported, we have to understand that very well, okay, so between zero and the maximum is what the decision will have to come when we write the requirements. Our first activity, so the question that needs to be answered here, which is the following is a well formed requirement? Answer A, the CCTV device shall allow the management station to retrieve current status of the device features from the camera control receiver. Answer B, the camera position must be controlled by the TMC. Answer C, is operator needs to monitor current temperature conditions inside the camera enclosure. And finally, answer D is TMC shall shares camera controls with maintenance personnel located at another building. So let's review the answer, the correct answer is A. It's correct because it has ability to retrieve information that we are looking for from the camera device which is the target, right? So the management station is in full control of trying to get what information it needs. So it has a structure and characteristics. And all the other seven characteristics that we mention are present in this requirement. Answer B is incorrect because it represents user need; it's merely a statement about user need. Same is the case with answer C because it's also user need statement and therefore it's incorrect. And D is also incorrect because it's also user need statement. So what we have defined here in this activity is to understand what makes a requirement and what makes a user need. So user needs are statements and the requirements are a more concrete description that follows the user need. Summary for leaning objective one, we have reviewed the structure what standard is offering, what standard is not offering to us. We also discussed the types of CCTV requirements that we need to develop from various sources and we also discuss a criteria of how to write well formed requirements and develop examples. So we went through several of these examples as well. So let's move on to the learning objective two now which is about interoperability and vendor-independence. How do we gain SNMP interface? So we need to understand that process what an SNMP interface and dialog process is. We also need to understand the NTCIP objects, what do they do for us and the structure. And finally, we need to deal with the dialogs that we need to conduct with the device. So there are at least three issues that we need to be aware of right away in understanding the interoperability and vendor-independent issues. The first one is compatibility, the compatibility is that different devices work with each other on a channel without interference, right? So we have to be making sure that there are one or two or more than two devices will also not cause problems for each other. And then we have interoperability means that the devices should be able to share the information with the center at systems and also among themselves and then perhaps use that information that they produce to make the traffic management decisions out there at the TMC. At the traffic management station, they should be able to conduct the inquiries with different devices. We have a third element here, interchangeability, is that I have this camera now and there's a new one coming up. So it's a dome camera. Now can I exchange it, can I get this product from different vendors, after all, we don't want to get stuck with one vendor and then lose all our investment of our decision making process. So we want to move away from it, we want to have more than one vendor and so on, and we also have access to different kind of devices. So when you look at these three terminologies here, terminologies the way we have described in terms of compatibility, the interoperability and interchangeability, they really work for us if we really understand the whole process how to achieve it in terms of writing requirements, so they have a very good connection to the requirements process. How do we ensure that we get all those things that we are talking about? Well next part in this discussion is the SNMP interface. This is a standard base interface that is part of the NTCIP process and it has several components here. The SNMP manager that exists at the management station is also a software module and the other part, SNMP Agent in the device is also a software module. So the dialogs are in between these two key components and the dialogs exchange messages in these two ends, so that's what makes the SNMP interface. The SNMP messages, there are three types, the first type here is a Get message, it's designed to read data so when we want to retrieve we need to use this Get message to get whatever data we are looking for. The next one is a GetNext message, it's similar to Get message but it's more for getting more data, reading more kind of tables and rows and columns, so it actually expedites the process of getting more than one piece of data from a device. And then finally, a Set message is actually about writing the data inside the device process. So whenever we want to control a function and we want to alter a state condition from this state to the new state or change from here to there, in that environment we will be using SET message so that we can actually tell the device what to do. So each message is to be understood in the form of a command and a control. So these messages are actually commands and the way they command is by containing a protocol data unit inside it. So the PDUs as they are referred to are actually the real strength of a message because that PDU triggers certain action in a device. So how is the PDU-- where is the source of PDU coming from? What can we say where the PDU is related to? So our first stop here is object. So object being the data piece, right, we have talked about there are 70 objects in CCTV standard and these objects are designed based on ISO language ASN.1, Abstract Syntax Notation. So that structure we are following here has six parts in it. The first part is the name, the name of object. Every object in NTCIP, not just the CCTV device but in all our NTCIP devices we have a specific unique name for each object. So that's what we are seeing here, rangeMaximumPresets object. Now this object name, you or I cannot change it, it's done for us and we have to follow, right? Second part is there is a syntax that has a range in it that allows us to look at the different values present. And then we can access this object or can we do a reading or can we do writing, so there are only two ways you can talk to a device by accessing in terms of reading or writing. So that is very clear as part of this structure, six part structure. Then there's a conformance issue, whether this object is mandatory, is this required, is this really absolutely necessary. In this case answer is yes but there are other objects that may or may not be needed to do what we are trying to do. Then there is a description, every object is very nicely in English text, in human readable text described in a proper way, so we understand what is this object about, right? So in this case it says, the preset is a pre-specified position. This is something that'll help for us to understand the object's purpose and what it's intended to do. Last one is very important; last one is a unique ID number. Every object in NTCIP environment has its own ID number. So with this ID number we are now able to carry over what that object is going to translate throughout the process of communication. So these two key parts, the part A is the value which comes from the syntax and part B, actually if you want to call it that way is the OID. So syntax is a value and OID is a unique ID number, both of these form a pair which we will use to form a PDU. So this is the connection of an object to the PDU. The example here is a rangeMaximumPresets has now a range syntax in there which is the 255 and we may select any number between these two end points and then we have the OID. So with OID and the value we are now forming a pair which is sometimes referred to as a VarBind. So if you look at the literature, you will see VarBind or VarBindList. VarBind means there is one pair and VarBindList means there's more than one pair. So essentially they form the core of a message and that message gets encapsulated, the VarBind actually I meant gets encapsulated in a message. Now a message has a structure of its own which is not a concern here today in discussion but the VarBindList is the key component of a message and that's what we are saying. So for CCTV VarBindList will come from those 70 objects that we mentioned earlier. And eventually this message will flow or move and the NTCIP step that we have discussed previously at different levels and then eventually this message will get out on the wire line in terms of data going to the device. That's how the message moves. There are three dialogs that will allow us to move the message from a management station to the CCTV device and they are generic. So generically defined here, D.1 is the SNMP Get interface to retrieve data. Anything that we want from the device we will end up using the Get interface. D.2 is again for a detail or more data retrieval from a device, for example, building a table, rows and columns, things like that. And the last one here, SNMP Get interface is designed to actually tell the device what to do. So we send data to the device and then device SNMP agent will use that data and try to interpret it and then do the rest and then prepare a response and send it back. So this mechanism of dialog works request message and then a response message from the device. So this is a pair of messages that is going on in between in a generic way. So this is what D.1, D.2 and D.3 means. So D.1 for examples are details. This is a representation using UML, the Unified Modeling Language. It allows us to have a management station on the left initiate as an actor; management station initiates a request, a Get message in this case in the middle to the control which is a camera controlled receiver on the other end. So the message goes out to the device and the device mirrors a response and sends it in the form of Get response to the management station. So this is to retrieve data from the device. D.2, same thing, again, management station is actor, initiates getting more data through GetNext on VarBindList, gets inside that. So in this case you might have more than VarBind, one pair, right, you might have multiple pairs in there and they may bring different kinds of data to you back to the center station or management station. In terms of D.3, we can say that this is a Set interface dialog, so if we want the device to do this function and then we want a device to do the other functions, whatever change we want, Set will be the way to do it. So Set message will initiate the request from the management station, management station is an actor here and it will ask the device, say, "Hey, change this thing," a pan-tilt and zoom mechanism will be now involved for example. In that case there will be a value that will trigger a certain position of a camera. And the camera will do it and then return the response through the Get response back to the management station. So this is very heavily used, D.3 is very heavily used command and control function in the NTCIP environment because through this D.3 we can control features in a device, in any given device. In our case it's a CCTV device. Our second activity here, let's go through that. Which generic SNMP interface will allow the operator to monitor the current temperature within a camera enclosure? A, SNMP Set interface, B, SNMP Get interface, C, SNMP GetNext interface or D, any one of the above?

Raman Patel: Let's review the answers. The correct answer is B, SNMP Get interface, it's correct because Get operation retrieves or reads the data currently in the system, in the CCTV device. So in this case it's the temperature, current temperature, what is the current temperature? For example it could be 105 degrees Fahrenheit and in that case the device will say, "This is the temperature, now you do what you have to do next." So that's why it's correct. Answer A is incorrect because it's a Set operation, writing, this is not intended here, we are monitoring, we are not asking device to do anything. So that's why it's incorrect. C similarly is also incorrect or perhaps it's incorrect in this sense because you can effectively use GetNext interface also but it may not be the right way of doing things, you can do it but it's not the right proper answer of doing unless you have more data. In this case we are only trying to read one temperature data, one piece of data so there is really no need for GetNext interface, we can sufficiently get what we want just using the Get interface, so we don't have to rely on this. This is why it's incorrect in that sense. Answer D is definitely incorrect because you cannot use all of these things in any way you want. Each of these three SNMP command messages have specific or unique assignment, so they cannot be mixed up with each other. So this exercise or activity clarifies which command is used in what circumstances. So now we have to ensure the interoperability. How do we ensure the interoperability? So the minimum requirements and specification, we should be paying attention to these three things here. First, the objects must be same, specification must select the same objects to achieve interoperability. Then messages have to be right and the PDUs have to be right, part of the messages. And then finally we must use the same dialog. So the objects, messages and dialogs must be same in any specification that's really looking for interoperability. So MIB objects, there are 70 objects out there in the CCTV, there are three command messages that we have just discussed and then you have a VarBindList that will come from the PDU performance which will derive from the MIB objects but it will be part of the messages. The three generic dialogs that we have identified and discussed and this goes for the entire NTCIP environment, not just CCTV, so we have D.1, D.2 and D.3 and these three dialogs are available to us so they have to be the same for meeting interoperability requirement. And then camera control receiver will be able to respond if we have the same MIB objects, same command structures, messages and then dialogs. That's how we will end up with ensuring the interoperability in our specification. Example here of a Set operation. Let's look at it and see how this requirement, is it written properly, does it have all the ingredients that we discussed earlier? The D.3.1 says that support of a Set operation; this is the title of the requirement. It says the CCTV device shall allow the management station to perform the Set operation on any supported object indicated in the CCTV specification RTM. Now grant you that RTM has not been discussed so far, it stands for Requirements Traceability Matrix and we'll be dealing with shortly, so please stay with me. But let's look and see if there's an actor. So the management station is the actor. CCTV device is its targeted device, so the target is there. And then what action we want, the action we want from this command and this requirement is a Set operation, right? So very clearly it says that the CCTV device shall support the management-- at the request of the management it should support the Set operation. So all actor, target and action combination together provides us a very strong requirement that will achieve what we really wanted to do. So it's written unambiguously. Now this part we have to understand as we move along in a later discussion. The RTM is a tool for that particular device that will tell us that this is what you will have to do. So we will revisit when we come to it in a short while. Example of requirement for presets. Presets as I said earlier are known position where the camera can now move to and it can jump from one preset to another, right? So we have a requirement structure here that says that I'm going to select 1 to 32 or 1 to 10 or 1 to 15, whatever number is selected, it's going to reflect in this requirement that is at the top here. So now look at in our example we said, it has an OID and it has a 32 as a range value. So this pair of VarBind we actually arrived at in earlier example, it's now coming alive. Now let's look at, see how it's going to be translated in the dialog process, okay? So the management station which is the actor is now going to ask the device which CCTV control receiver device which is the target and this actor is going to tell the target that I want you to do the Set operation which is the action and with using this OID 32 VarBind. So the concrete nature now emerges with OID and 32. So camera control receiver, the target device actually realizes what the management station wanted to do. And this is how the requirements are written so that we can actually get whatever action we are looking for from the device itself. So the summary for learning objective two includes that we discussed the interface parts and the dialogs process for communication, we also discussed the minimum requirements for interoperability and interchangeability, what we really need to make sure, ensure in the requirement and then we also looked at several examples of sample dialogs, how the message actually gets translated to the device. Now let's move on to learning objective three which requires us to understand traceability. So there are three components that we have been talking in general in NTCIP environment, so user needs is one, requirement is next and then we have design elements or design concepts that we need to use, right? So now how do we trace among these three different things? So we need to understand the user needs and requirements are traceable to each other, right, that's one. Then we have a traceability to this design, the requirements are related to design process. And then we also have to understand the benefits of doing this traceability so we'll discuss that for user needs as well as the requirements. So what is traceability? Traceability is the ability to follow or study the logical progression among the needs, requirements and design details in a step-by-step fashion, right? So when we develop a system, we are gradually moving from one stage to another and we need to keep track of it what we are actually doing at each different stage. So traceability brings that understanding, what we really need to do and how to do it in terms of activities at these different stage. So for example, the PRL, protocol requirement list will trace all the requirements to user needs, that's in the backward direction. So requirements are here and now we will go back and see, do we really get your user needs complied with or met in this requirement. A PRL will help us to do that. In the forward direction our requirements are now taking us to the design process, the design concept and are we actually able to do that. So RTM will help us in that in that process. So both these tools PRL and RTM are actually helping us to make sure that interoperability is there at different stages. So this is the format of a PRL, right? So it's a table and the first two columns of the table are reserved for user needs, first column is a user need ID and second one is the user need title, right? So now we're going to attach three more columns, requirement ID, requirement title and additional specification if you have in the final column. So these columns are now set for us to populate them with what we want to connect in terms of user needs and requirements. Now the reason why we are doing it is that CCTV standards does not have PRL, the other standards such as dynamic message signs and ESS, environmental sensor standards, they do have PRLs and also RTM for that matter. But in our cases in CCTV we don't have PRL or even RTM so we're going to have to develop them. Now this table is PRL so let's now try to populate it. So first user need ID was 1.0 and the title says, configure CCTV device. We looked at that earlier. That user need produced several requirements and you can see them in column three and four we have listed. So 3.3.1 is the heading for data exchange requirements and underneath we have classified all the requirements for configuration, okay? So in this case we have more than one requirements, so we are reflecting that. Also we are providing additional detail if there is a need in the final column, the third column. So it's actually the end column will say if specific requirements are there if we want to say something more in this case it says 32 for dome cameras. So we ensure that we are configuring CCTV device properly, correctly and then we set it up one time so the mechanism will work for the other exchange requirements, monitoring requirements and so on, right? So the configuration is always needed to be done on any ideas or NTCIP device. So this is what we have taken care of it. Now what are we going to say here? We're going to say that by collecting these requirements in the fourth column we have made sure that to fulfill that user need we are actually providing this requirement, so we haven't missed anything, this is the best part of PRL is that it traces all the requirements that are absolutely necessary to fulfill that user need. So PRL's job is very complete here in that sense. Okay? So we can move from PRL, now the configuration part to camera control. So here's another set of requirements that emerges because of the user need number 2.0 it says remove camera control. There is a need to control camera remotely, right? That user need translated to several requirements. Now we are only showing here two requirements, but they tell you the story that to control a camera you need several requirements. First one says here, preset, right, go to position then it says move camera to a stored position then there is a zoom operation that we talked about earlier then there is a camera pan and then there is also tilt and so on. So these requirements now form a cluster of requirements that are attached to the user need and that's how PRL satisfies the camera control. Take a look at the monitoring function, right, monitoring requirements are also structured the same way. In this case our user need is number three, 3.0, it says remote monitoring. How do we do the remote monitoring using these definitions of requirements, right? Again, if you take a look at that temperature example there that we discussed earlier, it shows up here as a requirement. If you want to monitor a CCTV device in real time using remote monitoring process then this will be a requirement and PRL will make sure of that, okay? So the purpose of PRL is to ensure that every user need we have now requirements are pressed to that user need. So the benefits then is to make sure that there is a relationship between user needs and requirements, that's what PRL does, right, every feature is taken care of. Then there are three people in all in this process, the users who write the specs, the vendors who supplied the products and the developers who make sure their decisions are built accordingly as desired and all of them know about these PRL. When they know PRL, they are on equal footing, they're on the same wavelength and that's the best part of PRL, PRL keeps you all three together in this whole loop so that we don't miss anything in terms of user needs and the requirements that they impose. So at the end of the day, again, the PRL helps us out because it becomes a checklist. In the validation process, later on when you check and say the system missed my needs, you know, if you have to answer that question and we all do have to answer that question, then the PRL will be a checklist, it will be a checklist that will help us and that make our day, right? The summary then is that it eliminates the guess work, we want to make sure that there is no guess work involved in terms of user needs and the requirements they produce. So this guess work is now removed by PRL, this is the reason why we are actually asking to prepare a PRL at project level. Same situation exists in a different fashion here but let's talk about the RTM now. The RTM relates the requirement to the design process, it now takes further into the system building process. So we have dialogs, the first two columns are the same, requirement ID and requirements haven't changed, but the last two columns are new in RTM. One is dialog, what kind of dialog we are talking we are talking about, is it generic dialog, D.1, D.2 or D.3, they are only three dialogs that we have been talking about, right? So RTM will show up, which dialog that you are talking about. And then it brings out all the design objects that we really need to fulfill that requirement. So they're lined up here in the orange section, right? So requirement is now locked or traced to the design concepts. So we can compare and say, "Yeah, okay, for this requirement I need the following dialogs and I need the following design concepts. So RTM has created that understanding that every requirement is now traced to the design concepts, okay, or in this case the object that we have lined up. So for example, configuration, right, it's not complete until we look for those design objects or objects from those 70 that I mentioned earlier, right? So we have to make sure that each one of them is now identified and that's what this column is doing for us, the last two columns. In terms of camera control, again the requirement is now 3.3.2, it says camera control, very specific designation now given. So these objects are collected by standards, all right, they are there but through RTM, we are collecting them, we are collecting them from standards and we're making sure that the RTM properly reflects. To do a camera control, these objects are necessary and to control, this dialog is necessary. In this case, D.3, it says, D.3 generic, SNMP Set interface. We can only control the device using this Set interface, okay? So RTM spells out everything we need to make our design process smoother, effective and correctly laid out. So that's the value of camera control through RTM process here. Same thing goes for the monitoring, here we are having a dialog D.1, right because we are now monitoring device and retrieving information. So for example temperature, pressure, whether we have a level of understanding about where the camera is. The last one for example talks about label objects, what are they? Well they will tell you, when you have a need to label a camera, the location is always there but you want to set direction for example or you want to put down a little description in English text, you should be able to do that through this ID generator. So that's the requirement we have. So monitoring allows us to look at various ways, what the device is doing. The benefits are also similar to PRL. In this case the RTM produces the relationship between the requirements and design process. So design process includes dialogs and data objects. Second thing is that the data objects within the standard and the ranges are specified. Sometimes we have to break the range or the value, we might say 1 to 10 or 15 to 32 or something like that. So RTM is a place to do it, it's the right place to do it, so if you do it in the RTM it catches the attention of people who actually will build the system and specification becomes stronger. So the end point for this benefit is the real way, say when we accept the system. This question always comes up, "Did they build the CCTV system right?" I mean we got the system finally through the door and we stand there and we ask this question, "Is this really built the way we expected it to be built?" So that question is answered through RTM. And then, "Does my interface deliver?" At the end of the day, at TMC, CCTV system will be looked through the meter or eyes of interface. If the interface delivers what we want it to do then we will say, "Yeah, the system looks okay, you know, not a problem." In this case I will bring back our discussion on the earlier slides when we said, "This is a system interface at the TMC," it brings up for example pan-tilt and zoom, it tells you what's going on, it can allow you to print close-up pictures or telephoto pictures." So whatever we check, we're going to be using RTM to make sure that that interface does what we expect it to do. So this is the best part of RTM, it allows us not just to trace the components at the design level but it also makes sure that the systems are built properly and correctly. Our activity here now deals with these tables. Which will ensure the precise objects necessary to fulfill requirement? Is it the PRL table, A, B, is it the RTM table, C, is it SNMP Get interface or D, major desired capability or MDC, which one of them?

Raman Patel: Let's reveal the answers. The correct answer is B, the RTM table. It's correct because RTM, it is the only metrics where the precise objects necessary to fulfill requirements are identified. In the RTM, we take a great care in making sure that everything we need to build that particular functionality is present. So RTM table is the way to do it. Answer A, PRL table is incorrect because it deals with the user needs, not the requirements to the design process. Same thing with answer C is incorrect because SNMP is a Get interface, SNMP is a Get interface, it's not a table and certainly it does not have any information about the objects yet. The last one, D is also incorrect because MDC is part of the user need, it's not a requirement per se in this case. So let's summarize learning objective three. In learning objective three we understood the issues about the traceability, PRL traces the user needs and requirements, the RTM between the requirements and the dialogs and the design process and then we also reviewed the benefits of what PRL and RTM does for us. On learning objective four, how do we incorporate requirements that are not supported with these standards? We have to figure out what happens if we do have a certain need which is not addressed by the standard and then perhaps an example of extending standards will also have to be reviewed. So the condition under which we extend the standards, well, we started out discussing and saying that there are 70 objects in the ASN.1 format available for CCTV standards. Now, we could have a user developed requirements and 1205 and dialogs again interoperability and interchangeability, right? So that implication immediately, interoperability and interchangeability. If we have 70 objects and let's say we need 75, you know, there are five objects that don't belong there or that's not there, what do we do? So we want to say that it's going to have implication on interoperability and interchangeability. So if you mix standardized objects and non-standardized objects then we're going to run into issue, or problems. So adding new objects to CCTV MIB is possible, we are not saying entirely it's not possible. But they need to be documented and make available to everyone, so this later part, making available to everyone is very important in terms of interoperability. If we don't make it available to everyone, the whole theory about interoperability will be suffering. So conditions in extending objects, it makes sense sometimes when the features are not supported by standards. So for example, in current standards we don't have objects for IP network cameras, right? So IP network cameras are used in large numbers nowadays and in recent years but the standard does not support it. So the question come up, what do we do or what are the other features or requirements that may come into play? So let's look at these examples objects. There are several that are being identified after the 70 objects have been standardized in the current standard, so there is an amendment process to add a few more objects and there are at least four of them related to query, position, pan, tilt, iris, focus and zoom and preset position are identified. So the people who have built the standards over the years have also recognized for additional objects and they are responding to that need through this amendment. Now this amendment is not official yet and it's not approved as the standard is, but the process that the amendment has taken is the same that we would expect someone else to do, all right, so this is the reason why we are talking in this context. So extension conditions then are for critical ones. The critical one is that has to be done on ASN.1 based on standard. If you don't do it and we do proprietary objects and write anyway the user, I'm sorry, the vendor might want to do then we will not be able to read and write the objects the way ASN.1 allows us to do. So this is a primary requirement, so any proprietary objects or extended object must be designed based on ASN.1. Second, the syntax must not be in a non negative fashion or integer should be non negative, it should not be negative integer, it causes a lot of errors if you have a different type of integer somewhere in the process. So we avoid that. Third, object must have OID and MIB in the note. CCTV has only a design or defined structure under 1205 and we cannot violate that. So if you have a new object that you want to work with, it should have a unique ID and it must be within the _notes structure that NTCIP, CCTV 1205 has identified. Finally, SNMP is only allowed in CCTV communication. So NTCIP 1103 standard specifies how protocols work. So SNMP is the way to go. So if you try to extend your object through a proprietary protocol it will not work, it will break the interoperability, in fact the system will not work with your object. So these are some of the key conditions that are necessary, absolutely necessary if you want to extend an object. The drawbacks are many, there are several drawbacks that we must be willing to accept and deal with it. So for example, if you have your own management station and your management station is an actor, right, so you may be able to do it, but there may be other management stations out there in the network, they may not be aware of the objects that you are now talking about. So the drawbacks are resulting in the sense that the awareness is not there in that network process and this extension will cause a distortion. So interoperability may not be achieved and the requirements may not be fulfilled if you have more than one stations or you are connected in original context. For example, an extended object here is the shutter speed, this is a real world specification driven extended object. Someone, a large agency at the state level specified that they wanted shutter speed. The only problem is that shutter speed designed object is not available in 1205, we do not have this object defined using ASN.1 so now what do we do? What happens to with interoperability? Only the state level agency may be able to successfully implement it and the vendor will be glad to supply it to you at cost and complexity but then the rest of the management stations within the original structure or connectivity may not be aware of this or may not have specified in their specification so the interoperability is now broken, they will not be able to access this CCTV functionality. So if they really want it then this object should translate in every specific case. So this is one of the reasons why we want this proprietary object must be published and must be available under the non disclosure agreement so the vendor cannot say that this is only for the state agency and not for the surrounding counties or cities, that may be part of the CCTV network. So such drawbacks are out there and we should be able to pay attention to that through this analysis. Our activity in this area is now which of the following is not applicable to the following extended CCTV requirement? Extended object reads like this, "The CCTV device shall allow the management station to remotely control selectable shutter speed of the field camera." The answer choices are, A, all extended requirements are non conformant to the standard and depend on proprietary specific objects, answer B, the requirement is well developed and meets criteria, answer C, this requirement will break the interoperability or answer D, the project RTM will ensure the interoperability?

Raman Patel: Let's review the answer. The correct answer is D, the project level RTM will ensure interoperability. We've been consistently saying that RTM is the way to go and it is correct, this answer is correct because the statement is false. So here we are saying that the RTM is the way to go and now we have this proprietary extended objects and answer is incorrect because the project RTM does not reference private objects or extended objects. That is why it's incorrect. RTM speaks about your own specification and it says, "Based on the standard and the preparation we conducted we have now produced an RTM which now is incumbent upon the vendor to deliver the system, CCTV system, right? So that message will be lost, so that's something we have to understand. Answer A is incorrect because the statement is true, the statement is true that extended requirements are non conformant. Any time you write an extended object, it will break the standard, you will not be conformant to standard. Answer B is also incorrect because the statement is true, the requirement is well developed. Even if it's well written, still it doesn't solve the purpose that we are talking about, right? And finally, answer C is also incorrect because the statement is true, so private objects, extended objects will break the requirement. So the way the requirement is written is now working against us. So this is why we have to understand how we can actually manage or handle proprietary objects. Summary for learning objective four, we reviewed the condition and context for extending the CCTV standard, we have to understand this through the examples perhaps and the shutter speed example was a good one. Then we want to say again and again that if you extend the standard it will break the interoperability. And by all means we should be avoiding this situation of extension and not encouraging it. So you will hear from us, from NTCIP developers, generally keep telling us that we should not be engaged in extension if at all. Our final learning objective five, is now to figure out how to develop a good set of system specifications. So what should be in a specification package and then what should be in the checklist of the elements that we must be aware of. In transportation sector, in our industry we generally starts with this plan-specifications estimate, short PS&E, it's very widely used now And this PS&E is a methodology for us to acquire systems and build systems and so on. So generally, typically it has three parts, part one being the hardware specification, function requirements, performance requirements, electrical-mechanical requirements, boundaries, temperature, pressure, a lot of these different boundary level issues, a range of issues are present in those specifications, also the environment requirements. Then we have part two, we have software specifications, we have functional requirements, performance requirements and all those things. The part three is what we are talking about today, communication interface. When we want to talk to a device, you can talk to a device two ways, you can to a location of a device where it's existing and when you were-- or program it and do your thing and communicate to the device locally, right, but you have to go out there in the field and add the device and do your thing. So one and two will get you the device that works in the field but it will not get you the capability, the remote management capability you are looking for, that will come through only part three here which is the communication interface specification. If you really want to manage your CCTV device from a management station, which is part of a TMC, then you should be preparing a good set of checklist for interface specification, both in architectural requirements and data exchange requirements. And that's what we're talking about in three. So at minimum, the communication interface spec to address the interoperability issues. Again, remind you that you will not get interoperability automatically, you have to work towards very hard in dispatch in making sure that that happens. We need to put PRL and RTM in the specification. For every project there is a PRL, for every project there is an RTM, right? And then communication is one aspect of what we are trying to do so we need to coordinate our requirements with other parts of the specs as well. So that said, we are now saying about the video formats because CCTV device is basically a video image mechanism and therefore we need to understand what formats are out there or what standards are governing this whole process. Let's look at the interoperability, we have discussed this thing very often in our module here. But we summarize here, to achieve interoperability agency must fulfill these two conditions, one is that they must use the same user needs and design solutions, right, and second they must use the same common protocols. So we have two part system interface here, management station and the CCTV device, so the messaging in between will carry out using the same dialog process and support the same features and that will come through the same level of design objects that we have been talking about. What are the implications? If we don't do that, how do we analyze or gain insight into this particular issue? So there are implications, so generally speaking at the traffic management stations we are using traffic incident management for example and the CCTV is a big part of traffic incident management system. When there is incidents or events, we actually move camera here and there, we try to get more information by looking at the terrain, or longer views, telephoto zoom operations, all those things, right? So the CCTV operation comes alive when there is actually an incident out there, right? So with that said, now as this example will clearly identify or say to us that there are implications. What are the implications? There are three video systems shown here in this image, they are out there, they are working but they are working on their own usually, right? And you have three separate controls and now you have to jump from one to another to another in order to coordinate the activities that you have on your hand. So what are the implications, that the systems are built over time and grant you, and in this case, particular case here there's more than one entity, there are actually two, one is a state, one is a city and both of them are big agencies so resources is not an issue, right? But the systems will require over time in a different timeframe for example so that makes different specs and these specs are not well coordinated or the requirements are not well coordinated so now you end up with three systems sitting next to each other and they don't allow you to communicate from one central interface, right? So what do you? So the implications are that we have to write the specs properly so we end up getting what we really want in a way that the system is intended to do. Many times we don't pay attention until we look at it or it's too late. Now in this case, I found out after the interview process in preparing this, but the point is that the requirements were written in a poor environment so that is the reason why you have three different systems and not one single interface. So you want to avoid these kind of implications, that's the point. So our value of this discussion is not other than-- is actually only learning from these kind of systems out there so we end up making sure that the next time we write the specs, requirements, they will speak about the interface very clearly, right? We started out our discussion more or less talking about how does a real world system interface look like and here we are talking about the same thing. So both ends of our discussions are now telling us that we better be prepared writing very good requirements so that we end up getting what we are looking for. So one way to make sure that that happens is integrating PRL in this project specification. As I said, every project has its own PRL which deals with the data action requirements, communication interface, also deals with protocols at various levels. You know, we are talking about SNMP here but NTCIP has at least different levels, you have different protocols that we need to be worried about or concerned about. And then we have to reference the standards in such a way, right that the current standards are identified by versions and publication dates so it's a small detail but it's a very important detail that will address or pay attention to. And then complete the PRL with the object ranges should be part of the project specification. Coordination of requirements, as I said, this is one aspect of the overall project building and so we have to coordinate with the data aspects. Communication interface is just one consistent way of doing so we need to coordinate with other parts as well. And here, the RTM is also permanently used because standardized solutions occurs through RTM, right, because the RTM will take us to the particular design objects in which we are interested in for that particular requirement. So completed copy of both PRL and RTM should form the specs and also they'll be used for your testing process later on. We have been talking about video systems formats. It's not part of the 1205, it's a separate discussion here. But some of the key video format standards that are out there, one important one being is the H.264. Now in your supplement we have provided you a lot of details so you can read through what these standards mean, formats mean and how they actually create implications for project specification. One particular one here is IP cameras, they are becoming more popular. IP cameras are now controlled through this ONVF, Open Network Video Interface Forum standard which is an industry standard, this is not part of the NTCIP. And we are okay with that because a large number of vendors are supporting ONVF and that standard seems to be doing its job. So we'll strictly benefit from it and without developing any objects for our side of the transportation in NTCIP. So there are certain legacy-based implementations out there, for example has some issues with the video formats and in the supplement we have provided detailed discussion on that. For example, if you have analog camera and now you have digital cameras, how could they be mixed and what the requirements are or what needs to be done so that they become controlled from one particular interface. Our last activity then is which of the following statement is false, A, a CCTV system vendor may support features not selected in the project PRL, B, the project RTM specifies the objects and dialogs, C, analog cameras can be controlled with common digital camera control interface or D, the interface specification must specify SNMP?

Raman Patel: The correct answer is, C, the analog cameras can be controlled with a common digital camera control interface. The answer is correct because this statement is false. The analog cameras must be first converted, the signal must be first converted to digital using an encoding mechanism for a common control from a digital interface. This is a requirement. Answer A is incorrect because the statement is true. Answer B is also incorrect because the statement is true and answer D, the last one is also incorrect because the statement is true. So summary for learning objective five is develop a system specification. We have gone through the checklist, what should be included in the interoperability issues and we have to deal with that. We also discussed with the specification where it fits, it's one of the three components in the overall package that we need to create for the general specification. So what we have learned in this module, we have learned that requirements-- CCTV standard does not provide requirements and user must develop and identify and then write them for project specification. We have learned also that a requirement is a translation of user needs and has a structure and certain characteristics. We also learned that requirements are linked to interoperability and vendor independence. Specifically at the project level each requirement is traced to at least one user need in the project PRL. Requirements should be traced to objects and dialogs in the project RTM. We also learned that to retrieve data reading operation from the CCTV device, SNMP Get interface is used. To control a CCTV device writing operation SNMP Set interface is used. And finally, to support the same features, the management station and a CCTV device must have the same MIB and must use the same dialogs. Some of the important resources, where do we find additional resources, student supplement is a key, we have a lot of good material in it. One is that there is a complete or near complete list of user-- sorry, the requirements in the supplement and this supplement lists what requirements are under each headings of the tree types, architectural and the data exchange and the special departments. Then you have the source of the NTCIP 1205 and 1201 and 9,000 which is a guide. These three documents are available at ntcip.org. So this is the official site where we have all these important documents located. Also, there are training modules out there already available now, module A103 will prepare you for requirements process, how to review and form well formed requirements. Module A203 is also about how to write requirements when SEP content is not available, right? And we also said Module A317a deals with the user needs, that module is also now available at the PCB sites. Some of the frequently asked questions about CCTV I'll also briefly review for your benefits. For example, a question was asked or being asked is, "Can the title of a user need and requirements be the same?" And the answer is yes, you should probably have the same user need title that's followed from A317a Module, earlier module and then B, you should have requirement title the same so they match properly. Second question is, "What is the difference between compliance and conformance?" Compliance refers to the specification, a vendor or a responder must supply equipment and a system compatibility that is spelled out in the specification. And the conformant is to the standard, whether the system conforms to 1205 standards that will come through for CCTV, it will come through the conformance groups as part of the specification. So those are the two key differences out there for compliance and conformance. There is also a question very often asked, "Can a design consultant that an agency hires also appropriately develop PRL and RTM for a project? Is it a good idea? Is there a risk in asking the same people who designed the system to develop PRL and RTM?" The answer for that kind of situation could be that yes, under the circumstances because you hired a consultant and has the expertise and knowledge of what the current standards are so that should be not a problem. However, the force of the requirement will come from the agency in that you want to make sure that your requirements are clearly translated into the requirements listing that we have. That is one of the reason why we have this slide that you saw on the interoperability implications towards the very end. We had agencies have three different systems sitting next to each other and they don't have a single interface. And there is a reason behind that as the interface was probably designed or written, the requirements were written by vendors who were people not aware that the agencies will someday come together and sit next to each other and use this system for each other's benefit and by virtue will talk about the single interface. So yeah, these kinds of situations do occur and you have to deal with them in making sure that the requirements are on the table and are not assumed by the designers and they forcefully should be brought to the discussion and say, "This is what we want, we want interface that should do this, this and that." So we need to spell that thing out. So these are some of the questions that encounter. Again, we have a lot of good information in the supplement, both in A317a and also in A317b, so we recommend that you read those supplements and make sure that your questions are answered. So thank you for attending this Webinar and this completes the presentation.

#### End of A317b_Final.mp4 ####