Module 33 - A317a
A317a: Understanding User Needs 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, director of the ITS Joint Program Office for USDOT and I want to welcome you to our newly redesigned ITS standards training program of which this module is a part. We are pleased to be working with our partner, the Institute of Transportation Engineers, to deliver this new approach to training that combines web based modules with instructor interaction to bring the latest in ITS learning to busy professionals like yourself.
This combined approach allows interested professionals to schedule training at your convenience, without the need to travel. After you complete this training, we hope that you will tell colleagues and customers about the latest ITS standards and encourage them to take advantage of the archived version of the webinars.
ITS Standards training is one of the first offerings of our updated Professional Capacity Training Program. Through the PCB program we prepare professionals to adopt proven and emerging ITS technologies that will make surface transportation safer, smarter and greener which improves livability for us all. You can find information on additional modules and training programs on our web site www.pcb.its.dot.gov
Please help us make even more improvements to our training modules through the evaluation process. We look forward to hearing your comments. Thank you again for participating and we hope you find this module helpful.
Nicola Tavares: Throughout the presentation this “Activity” slide will appear indicating there is a multiple choice pop quiz following this slide. The presentation lecturer will pause at each quiz section to allow you to use your computer mouse to select your answer. There is only one correct answer. Selecting the submit button will record your answer and the Clear button will remove your answer if you wish to select another answer. You will receive instant feedback on your answer choice.
Please help us make even more improvements to our training modules by completing the post-course feedback form.
This module is A317a: Understanding User Needs for CCTV Systems Based on NTCIP 1205 Standard
Your instructor is Raman Patel. He had close to 30 years’ experience at New York City Department of Transportation as Chief of Systems Engineering and seven years at Parsons Brinckerhoff. He is currently teaching ITS and transportation engineering at NYU-POLY in Brooklyn, NY and working on road safety projects in developing countries. He has served as chair of ITE’s Standards Committee for the past 15 years. He is a member of the NTCIP and xxTMDD committees. The next voice you will hear will be your instructor.
Raman Patel: Hi. I’m Raman Patel, your instructor for this webinar today.
Raman Patel: The target audience for this module includes the engineering staff who are involved in managing traffic at the Traffic Management Center, the operational staff who work around the clock 24/7, the operators who are engaged in managing the day-to-day and the operational staff who are traffic engineers who are writing traffic management strategies. Also the system developers, those are the people who put different type of devices and systems trying to make them work together in an integrated manner; they will benefit from the use of standards. And also the private and public sector are users who are engaged in collecting information as well as providing the different types of cameras, all those that we use in normal use, for video surveillance; they would also benefit from the use of 1205 standards. Of course the private sector also includes information service providers; they are specifically collecting current conditions on traffic and then they are providing that information in realtime. Their customers, the end users who use that information to make management decisions. So there’s a range of target audience module who will benefit from this discussion today.
Raman Patel: The recommended prerequisites for these modules include several of them. The I101 at the top here provides an overview what the ITS standards are about, the benefits and general listing of the standards as well as the A101 here tells you how to acquire a standard-based system and what are the issues involved in those implementations as well as a little discussion on how to prepare your procurement process. A102 specifically deals with the user needs; how to identify them and what they mean in each different aspect of our operations. A103 specifically for requirements or every user needs there is a requirement attached to that and that A103 module deals with that. A201 is about how we acquire a standards-based ITS systems in details: what to do; what not to do; how to be prepared for certain issues that may have constraints; all those issues, the pitfalls, are all dealt with in that module. A202 is a very specific module that deals with when you don’t have user needs in the standards SEP documentation then what do you do? So, it deals with the process, a generic process, and introduces us to how to actually develop the user needs space to available sources. A203 is a similar approach there also but for requirements; how do we develop of requirements when it doesn’t appear in the documentation or they don’t have it available in this Standard documentation. C101 is a very specific course; this introduces the communications protocols, NTCIP protocols and how do we use them in ITS applications and it prepares you with the concepts used in applying general communication protocols for general purposes. So these are the requirements, prerequisites for our module today. The curriculum path basically provides us for non-SEP standards; what do we do in terms of getting acquainted with what we have to do. So there are a series of modules put together here for us to be aware of it and prepare ourselves. So last there here in the row, for example, the CCTV related specifically; those three modules are helpful to us in preparing how we prepare specification, for example, with the A317a is a subject matter we are going to discuss today. The next module b, A317b, deals with the requirements. And then, of course, how do we test it so that we can ensure what we are specifying is actually what we are getting at the end of the system implementation. So those are the three modules that connect to CCTVs systems.
Raman Patel: Basically speaking systems engineering process SEP is an abbr, systems engineering process is a definite process we use in developing our ITS systems as well as the process has been used also to develop certain standards. When SEP process is used in developing ITS standards that allows us to say that typically they provide us the detailed discussion or detailed documentation about what the standard is about. And here in the list, for example, you see the general discussion is provided in every standard that is based on SEP; concept of operation actually deals with the user need; it provides the listing of it. Requirements are also listed in the documentation and also the design details that go with the requirements. Also more information, detailed information, about certain portion is also contained in the annexes. So, this makes it easier for us because the details and the clarity this documentation provides, it makes us ready for the specification preparation. That is not the case when non-SEP standards are not involved; they are very difficult to use sometimes because we don’t have that documentation available. Here we have the overview, for example, of a general discussion about the particular device standard and then you have general information and it provides the design details. So what is missing is the requirements and concept of operation user needs but that’s where we need to help. So that’s about the non-SEP standards. Now, we have to also realize that the key difference between standards that have SEP and those that don’t have SEP is that with the user needs, requirements and traceability we can verify and validate that the design will satisfy operational needs. We can’t do that when we don’t have the SEP content available to us; and that’s a hurdle we have to overcome. That is one of the subject matter that we are dealing today in terms of CCTV system operations.
Raman Patel: So there are four learning objectives designed to provide you additional skills to prepare ourselves for the specification to acquire a standard-based CCTV system. The first one here is to review the structure of the NTCIP, develop high standards, what it offers, what it doesn’t offer, and how do we realize ourselves in that standards. The second learning objective is very specifically deals with the operational needs in what circumstances we use CCTV; why do we use it, why do we need camera operations of certain locations; things like that will help us to identify the high level operational needs and from there jumping into learning objective three, we’ll be able to identify and write well-formed user needs based on the operational requirements or operational needs. The last learning objective is to evaluate conformance. How do we ensure that what we are getting meets the standards or conforming to the standards? So these four learning objectives will prepare us by providing additional skill that we need to prepare specification.
Raman Patel: Learning objective one deals with the definition: What is a CCTV system? What are the family of the standards that our NTCIP family offers us? What is the purpose? What are the benefits of it 1205 standards? Why do I need 1205 standards? That question is to be answered. And there are components of these 1205 standards. What is the detail available in the standard itself? What is offered by the standard? What is not offered by the standard? And all of those things we need to be aware of so that’s what we will review in this planning objective.
Raman Patel: It starts with the definition of closed circuit television. We all know television but why closed circuit television? What does a closed circuit mean? Well, closed circuit means that it is a circuit that’s connected to the camera and the central management station and in between we are able to see the camera images. These camera images that we generate or produce at the camera site is not broadcasting; it’s not available to anybody outside of the circuit. So that’s what closed circuit means. Now, what is a CCTV system means? Well, camera is one piece in this whole discussion but you also have the circuit that brings the video back to the central station. We also have display wall where we are actually displaying all different images on different locations, right, so that a bunch of things that come together; that’s what we call system. So these are equipment; they are different purposes. Perhaps they are located at different locations but they make up the whole video surveillance system.
Raman Patel: So what are the components of the CCTV system? Typically, you will have a central location where you have a monitoring station; you have a video wall where you are displaying all different images from different cameras; and then you have some kind of switching device which will allow you to move one camera from the other and bring back different images so that you can sort it out what’s going on, right? You have also in the field camera unit itself with the lens. Then you have pan and tilt assembly which is separate from the lens but it allows you to move the camera. And then you have a receiver. The receiver is where you receive signals from the central management station and make the camera control possible. In between we have communications that’s taking place on leased circuits or shared network or whatever medium we use. So this is our main topic today to figure out how the communication takes place so that we can control camera from a central traffic management station.
Raman Patel: The camera control architecture begins with the traffic management system where we have several aspects of operation; so certain objectives and you also have architecture service packages, now it’s called service packages in the latest architecture, version seven. So, this traffic management system is communicating through a camera controlled receiver in the field and this is a device that receives signals from a central traffic management system and that’s our subject today and we will discuss that in great detail so we can understand how and where we need to make certain adjustments. The lens itself, the camera lens and the pan and tilt and zoom assembly, they are being controlled by the proprietary data between the receiver and the camera lens itself; so that’s a subject that the vendor will deal with. We are not concerned with that part because we generally get the whole camera control unit and everything together. So our main interest is in this area here where we are dealing with how to communicate to the center camera unit. Okay?
Raman Patel: So now, some of the terminology that we should be familiar with are listed here; they are also in your student supplement in detail. Let me just take a few of them here. For example, what is an analog camera and what is a digital camera? We need to be aware of it so when we make a purchase we know the implication and requirements that go with it, right? So, analog cameras are now in the last few years are being replaced with digital cameras; so both of them are used in the mix but we need to understand. Number eight here, iris, for example; it’s a way we control the light going into the lens of a camera. So if you are involved in a night operation 24/7 you may be concerned with how do we use camera a little more effectively during night or low lighting conditions. So those are the kind of issues. Eleven here, number eleven, presets for example; why do agencies actually look for large number of presets? What does preset mean? Because we have to specify all these things, you know, with specification we should know the real meaning, correct meanings, of each of these terminology. Preset, for example, is the way the Traffic Management Center operator will be able to go through the camera position direction without moving the camera around. You push a button and it will take you there. So that is how we begin to understand the details that each of these terminology provide to us.
Raman Patel: The NTCIP family is providing us these common standards that we have been talking about in NTCIP where we are talking about the CCTV standards but there are other devices. Also DMS, for example, dynamic message signs, traffic controller, environmental sensor station; all of those are standards where it’s used in part of the family. And basically there are two issues that we should be aware of very quickly here. The information level standards actually provided us the data objects or data elements; and those are the ones that we exchanged from a central management station to the device itself. Then you have underlying protocol standards which allow us to communicate these messages to the device. The 1205 standard; it’s information level standard, and that supports the CCTV operations. And let’s look at a little more closely how the communication actually takes place in the medium using the 1205 standard. So let’s look at the framework here. The framework allows us to say that the two standards, NTCIP 1201, global object; it’s also a dictionary. This dictionary contains common objects for all different devices, not just CCTV but also for dynamic message signs and every other device that we have in NTCIP family. So, 1201 is one dictionary; it’s always used in every implementation. Then in our case, today, we are talking about NTCIP 1205, CCTV camera control; that deals with the camera only, the data objects. You have at the application level we have a SNMP; SNMP stands for simple network management protocol which we have discussed in detail in C101 module. The SNMP is a preferred protocol for today’s topic at 1205 standards for CCTV camera control uses SNMP. Then underlying protocols allow us to move data from point A to point B and at the lowest level we are talking about different mediums at the plant level. You have coaxial cable. You have fiber optics. And lately we are also using wireless, the medium’s methods to bring the camera back, pictures back, to the central station as well as talk to the camera, communicate to the camera using wireless medium as well. So some of these things we are dealing with at the plant level issues. Now, if you are a communication engineer or a telecommunication engineer you will be more concerned or more interested at the lower levels activities here. For example, RS232 wiring; you have an interface, you have a bandwidth analysis. How many cameras can I put on one channel? All of those issues are pertinent to the communication aspects might be of your interest. On the other hand, if you are a software engineer or a traffic engineer, system integrator you may be more interested or concerned with how things work out at the application, the upper two layers, application level as well as the information level. How do you move the data and how do you format the data and all those issues that come up in that sense.
Raman Patel: Now, the purpose of the NTCIP 1205 standard is to generally support the operational needs as we know it at the very high level but more specifically, the 1205 standards makes it possible for us to actually bring the remote capability to the table; that means that we can now configure a device remotely. Also we can monitor a device, see what conditions the device is in, what is going on now; we can monitor that, as well as we control camera position. Not all cameras are in a remote position, right? We would like to move camera from left, right or any direction we want; so we can do that using controlling aspects of the camera position control functions. We also want to be able to adjust autofocus of the lens, iris, the light control, and there are other functions; so that capability remotely is also now made possible by 1205 standard. And also the retrieving images; the data is collected at the local site or the camera and we want to be able to get that data when we need them and both in the condition when the communication is live and when the communication is not live, so offline condition.
Raman Patel: Let’s look at this example of operation here. It’s very interesting to see that the CCTV system operation is also now shown here in this example with the capability, the remote capabilities that we just talked about. How do we look at this picture? Well, we can look at the big picture first and say okay, I see what’s going around town in the highways, bridges, tunnels and also you can focus on a particular location and see what conditions are prevailing and based on the information that we collect we can make management decisions. So what it does, the system brings us the capability and information which eliminates the uncertainties and it provides us both a big picture view as well as the specific location. This example also shows how the operation is conducted using software interface, a common control mechanism; ADMF is shown here. All of these tools are integrated. Now the systems are complex and they default from location to location, place to place based on the needs that we have but the general concept of controlling camera from a remote, from a TMC, is pretty much intact. No matter what type of system you have you will be always dealing with that aspects of camera control. So, while the software capability may be from region to region the basic functionality is something that’s the common in all applications more or less, right? So we can also summarize here that the information we get is very important to us because we now can use that information and make traffic management decisions. And operational decisions are made in realtime so it supports the overall traffic management operations. So this system concept of how a device is made useful in carrying out your objectives, your agency’s mission and objectives, is very strongly supported by the standard; in our case it’s 1205.
Raman Patel: So, where and how the CCTV standard fits in the procurement process; let’s start with the high level design, detail design; that’s when we first came up with the ITS or the question of what standards and where and how it works. So that takes us to the particular standard; in our case it’s 1205, what we are discussing about camera. So this standard actually does not have what we are looking for; information about user needs, right, and also the requirements to satisfy those user needs. So the only thing we have is the design solutions. So how do we write specification based on whatever this information we have in terms of design? So we have to sort out. So we have to prepare specification and we have to actually overcome this issue of not being able to have the user needs readily available to us, all right? So let’s take a look at it. What should really go in the specification? There are three components that will go. The first component in the specification is the user need. Stepping out of the operational needs, the high level operational needs, now we have to go and detail out specific user needs; so we have to identify them and then write them in a very proper method, using proper method so the detail description is produced. So that’s what user needs are to be handled in specification purpose. The next two components includes the requirements; requirements a little more specific in a way and they are written in the “shall” language and they relate to a very specific expectation that we have or functional requirements that we need to satisfy user needs. The last component, the design solution, are, as I said, we already have them in the standards; so now we have to map them and say whatever the standard offers, how do I map it to the requirements? And then we write them in those specifications. So there are three components that we have: user needs, requirements, and design solution. And user needs actually help us to relate our operational needs to the design of the system. So, getting it right first time, specification is that step. We must get things right at the beginning so we don’t end up in some kind of issue or problem that we have to deal with later on. All right?
Raman Patel: So the benefits now why do I need 1205? Why do you have to use it? Well, it facilitates ITS deployments; it eliminates the need for proprietary solutions. These are the very good two benefits that we can happily generalize right away at the beginning. So let’s look at in terms of how it will show up in reality; reality as it unfolds. For example, the Traffic Management Center deals with an ability to control camera remotely. We said that we want to be able to do this remote control of all types of cameras we acquire from different vendors. So we don’t want to have a situation where we can control the camera obtained or purchased from one vendor and not be able to do the same thing from another vendor; so that is the remote management capability which is based on a standardized method so we can actually control cameras from all different vendors, right? So that’s a good thing to have. So that’s one way to benefit that we talked about. The second major benefit is the system expansion. We have what we have today but we always add things, right? We want to be expanding our system; in that we want to do it in a consistent manner. We want to develop the interface which allows us to add more equipment, in our case cameras, so that they will all work together in the part of the system. So, easier system expansion is a second benefit that we are actually highlighting here. The third benefit comes from the fact that the industry standards. We have no industry standard. We are now having 1205 in front of us so it establishes a common platform, a common understanding of ITS system features. What is the user looking for? And it’s everyone’s business to know what kind of functionality this camera system brings to us for traffic management purpose. Traffic management, we are more concerned about certain ways of controlling cameras and so on. So all of those issues are important to us and we need to deal with that. Now there are agencies who originate user needs. There are system developers who build the systems and there are vendors who supply the camera products, right? So, those are all the beneficiaries that we have acknowledged here. So industry standard is what’s developed all these three advantages. Then we have multiple vendors. We want to have a very healthy competitive market where more vendors sell products to more users. So it’s a win/win situation for the vendor community, for the users who are trying to acquire products from different vendors or multiple vendors and they’re perhaps looking for cost competitiveness as well. So that’s the other benefit that we look at it. So when you put all this together, all these different benefits together, we want to be able to say that we really want a healthy and a very competitive market where we can actually go out and purchase our equipment.
Raman Patel: So there are three outcomes that we should be aware of it because they impact our deployments and they also deal with the issues of investments. So, all these three components that we will talk about are discussed in this slide here. Let’s look at it one by one. First thing is that we have a lot of different mediums that we use in ITS: coaxial cable, wireless, fiber optics and so on; and we have different devices and they all actually use these mediums so we want these devices to be compatible. We want them to work together on a wireline or wireless medium and operate in a harmonious way without interfering with each other; that is only possible when we use one common protocol. So we need to use a common protocol so that we make the devices compatible with each other. The second thing is the interoperability. The interoperability is allowing different types of devices to coexist in the medium. And there is a meaning of the message and the content so we have to have the messaging structure, for example, that requires the same language. Thirdly, we will talk about interchangeability here. Interchangeability is now “I have this camera today and now I want to replace it,” for example, “But can I swap it with a newer one and they will just work fine.” which is a very good way to look at it and say “Okay, now I want to replace the old analog camera with the new dome digital camera.” So interchangeability aspects of equipment, in this case camera, is also very important. So we look at this compatibility as an outcome because it has a common protocol issue; interoperability because the device, data objects and the message it creates should have a consistent meaning; and then you have interchangeability or vendor independence who can purchase, actually-- excuse me, purchase equipment from different vendors and you build your system as you go along. So these things are very important in ITS deployment.
Raman Patel: So what does this standard offer? Well, let’s look at the structure of the standard. The 1205 standard has several sections. Section one deals with an overview. It discusses benefits. Some of these benefits that I just discussed with you actually came from the section one and the CCTV system description. Section two deals with the general terminology and references and also has annex A which provides you with the glossary. Now take a look at the section three which is the core of the standard, 1205 standard. The CCTV MIB; MIB stands for management information base, which is a collection of data objects; so these data objects are eventually compiled and they are turned into some kind of database which resides in a device. So this is a very core section that we have to be familiar with; this is where all the functionality is listed, all the functions are listed, and that’s where we build our specification from, more or less. Section four is conformance. Conformance is a listing of the group, of conformance groups. There are four of them for this standard and they also provide us with a statement, what is a conformance statement.
Raman Patel: What is offered by the NTCIP 1205 standard? The current standard offers the following. For example, it gives us the data objects. So in terms of a single design, okay, it is a direct way of saying that if you’re looking for this operation or this functionality this is the design for it. So that is why we say single design. Then you have the management information base which contains objects I just mentioned to you before and this management object, management information base definitions are created, the objects are created to support user needs. However these user needs are not documented. So, on one hand we have the MIB, the management information base, which seems to be doing a good job for CCTV operation but we don’t have the documented user needs that drive that MIB. So we have to overcome that part. The third component in the standard that it offers is the conformance groups. There are four conformance groups. The conformance group is a grouping of related objects. There are certain functions that require a bunch of objects together, all right? So the standard developers have put together four conformance groups which actually list different objects in each one of them. The CCTV configuration is a general-- is a required extended function; it has all detailed discussion about if you want certain aspects of the operation. Motion control deals with bend, tilt and zoom. And onscreen actually deals with the menu inside the camera. The last portion here is the conformance statement; it said that if you want to be compliant to 1205 standard what are the minimum requirements?
Raman Patel: What is not offered by this standard is also important for us to know because if we don’t know how to get around what is not available then we’ll be actually also facing certain issue. So, for example, the standard does not define user needs, right? We have said that early on. The standard also does not define the requirement. But the standard does provide the design. So now how do we specify, how do we write user needs? And if you don’t write user needs and then say “Well, why do I have to write user needs?” you know, you may ask that question but if you don’t write the user needs then we are leaving everything to the guesswork. The vendor will say “You didn’t tell me what your needs are so here it is what I have,” you know; and in that case, without the user needs, you may get something that you don’t need and you may miss something that you really need. So that’s where the user needs come in. Writing user needs in a proper way and presenting it to the vendor will allow us to get what we need. So, summary is that we do not have user needs and we do not have requirements and therefore we have to identify them and write them.
Raman Patel: What is not offered also includes the video formats. The video formats are necessary to facilitate transmission of the video images and also the storage of video images. These issues are not core. Right now we rely on the industry standards, internet standards, and that’s fine. So we have to be aware of what these standards are. There are several of them here. We are flagging them actually so that you are aware of it. We will have more discussion in the next module. So MPEG-4 is moving pictures expert group standards that allows you to actually collect the images and store them, move them; and H.264 allows us to do videoconferencing as well as the coding. ONFV, open network video interface forum, which is the IP video, which you already know that every time you go on the internet to get a video image from a TMC chances are very good that you will be on ONVF kind of format. So these are the kind of formats that we will encounter in our application, CCTV system application, and we should be aware of them. We’ll deal this a little more in detail in the next module.
Raman Patel: Let’s have an activity here. The question is which of the following applies to the NTCIP 1205 standard? There are four choices. A, supports video signal compressions formats. B, provides CCTV system design objects. C, provides documented CCTV user needs. And D, provides documented CCTV requirements. Let's review the answers. The correct answer is B, provides CCTV system design objects. It's correct because standard does provide objects. You know so that's we discussed before that MIB, Management Information Base actually has objects in them, alright? Answer A is incorrect because video signals in a compression format such as one we just discussed, H264, ONVF are supported by the Internet and industry standards. It's not an NTCIP-based standards. Answer C is also incorrect because CCTV user needs are not documented by the NTCIP 1205 standard. And answer D is also incorrect because requirements are also not documented. So the last two for example is telling us again that we should develop that user needs needs to be written and so the requirements. So Summary for Learning Objective #1 is that we have defined what a CCTV system means. We also reviewed the family of standards and the framework and the benefits it provides. We also reviewed the structure of the NTCIP 1205 standards, the key components which provides the CCTV MIB. What it doesn't provide, it does not have video format standards. We also realized that system user needs are not documented and we must identify and write them. We have repeated that several times and we need to be acknowledging that. We also said that the formats, video formats are not discussed and we'll repeat that later on in the next module. Let's go to Learning Objective #2. Now learning objective 2 is to identify CCTV specific operational needs. What are your operational needs? Why are we even talking about CCTV camera operations? Why do I need camera? What will I do with the video images? How will I use them? All those things we need to understand with clarity. Then we have to explain ourselves with how the operational needs are actually helping traffic management applications. So we will have to tie this together. So let's look at the Specific Operational Needs, Concept of Operations. This is the big picture discussion. Concept of Operations tells you why do I do certain things the way I do it? I have my agency missions, objectives. I need to do certain things. It also involves the who-are-affected parties, who is benefiting from this deployment, who will be using the services or functions produced by the devices. So those are the stakeholders we are talking about. Then there are operational scenarios. Operational scenarios are the reality. They are the what we call the core of this whole discussion because they tell us in the real world how things work out or how things don't work out for that matter. And what trouble we get in and how do we help ourselves? All of those things are present in operational scenarios and we learn a lot by analyzing operational scenarios to extract what our needs are. And what happened last time we had an operational scenario like this and something didn't go right, right? And why it didn't go right, then we learned from it, so all of those things are very important to understand. Then there are user needs, what are our user needs? We had to put things together stepping out from the operational needs we have now to really get down to the details of the user needs. Then are there any regional aspects? Are we deploying this product the ITS project so that there are other people who would also benefit from it? Are their issues related to that? So in that case are we sharing these devices with the other stakeholders? All of those issues will come up and we need to understand those issues in terms of operational needs. We also have discussed ConOps in Module A202. So I would also urge you to go back to that module and revisit and understand a little more and discuss in details. There are institutional issues that we should be aware of. Are we sharing videos? We are talking about today CCTV system and certainly we need to address this issue. Am I going to allow my video camera images to be used by other people? Will they be able to look at it? So are there video films that will be made available for private sector service providers for example? Chances are very good that if you do have real-time video some people want it you know whether they are private sector or whatever service creators they are they will be interested in it. Then you have a shared control of cameras with pre-assigned priorities is established. Regional architecture always talks about how you can share information with your partners in the region in your neighboring jurisdictions. So in that case we have to be sure that the equipment is shared or controlled or the priorities are assigned, whichever may apply. You have several service packages that tell us how certain subsystems would be affected. There are two mentioned here for example Roadway Subsystems and Security Monitoring Subsystem. These subsystems also use video surveillance capabilities. So Illustration here tells us that if you are producing video images in this case here from traffic management to the roadway and you have to now also understand that alongside your own use of the video images in real time, there may be other people also interested, other traffic management centers may be interested in receiving or controlling even these surveillance images that you are developing from the city operations. Example here, The Shared Camera Controls in regional aspects, in emergency management, traffic and emergency management centers mutually have agreements with each other to share devices or use the camera images and sometimes may control camera within different jurisdictions or adjoining jurisdictions, for example. So all of these things are out there in a cooperative or coordinated manner, so if that's the case, then we have to be aware of how we can provide control and share this different images, different devices with the different regional partners. Specifically we have outlined here General Purpose subsystems, traffic surveillance system, video system, surveillance system and traffic management systems we mentioned earlier in the beginning. That also includes for parking management system for example, you know whether there are parking spaces, empty spaces are available or not. And with your camera you can actually detect that and make it available as a good information to you. Congestion monitoring, incident detection, verifications. Incident detection and verification is a primary beneficiary of application for camera images. And we'll talk in more details shortly. Public and media information, managing weather/disaster emergencies. Lately we are having a lot of different emergencies weather emergencies. And in all of these things tell us that if we know the conditions out there during these bad events, we can do something about it or we can control our resources how we use them so that we send the response to the proper locations. So that's very important. It has become very, very important in the country and a lot of people say "Good thing that I knew because now I have your images available to the camera operations." Of course the infrastructure security, bridges, tunnels, observing that security is very important using camera operations. What does Caltrans use the CCTV for? Let's look at these how the agencies perceive or how they see their primary uses of cameras. In this case Caltrans is very clearly telling us that there are two basic aspects of this whole business is to provide motorists with the visual verification of weather and traffic conditions. What is happening on the infrastructure of facilities is now provided to the motorists. So that's one general user class that we have. The second one is the Caltrans itself for example. The agency itself is using these measures at the TMC to improve response to traffic and weather-related incidents on the highways. So in both cases the motorists and the agencies, the owners, also benefit from the CCTV, system operations. Here's another agency Perspective on CCTV Operation, the Virginia Department of Transportation. It's also talking about providing traffic management center with this ability to detect incidents. Not only detect incidents but also verify incident information. And then monitor traffic conditions. So just like we have discussed about the Caltrans perspective on camera operations, here also VDOT is confirming that knowing what is happening in real time is helping them as well as the other regional partners that they share this information. So both these missions stated by these two agencies tell us that CCTV operations actually are very critical in terms of how TMC operations are run. And in many cases it's 24/7. Take a look at this example from Arizona DOT. A tunnel environment, tunnel environment we really need to know what's going on inside the tunnel 24/7, how each lane is moving for example. So how do we know all these things in real time? What is happening in real time? It's a very important observation we have to make. So to do that the agency actually installs cameras around the tunnel to get a general view, and then inside the tunnel as well so if something do go wrong or something does happen unfortunately, you are able now to move traffic around and help yourself in running traffic management operations smoothly. Here's an Example from Multi-Agencies' perspective. This example shows that the camera images are now made available in real time through more than one agency, not just one TMC but there are several TMCs looking at the same image at the same time. And when you do that you are actually deciding what role you have in that particular event or accident for example in this case. So you look at these pictures and say yeah, this is what I have to do as my agency is a support to provide this support. So you can zoom on the information and help yourself to decide what you have to do. So such uses of camera operations are also from multiple agencies, multi-agency operations. Let's take another activity here. Which of the following is not a true statement related to traffic management. Four choices, A, TMC typically performs assessment of traffic conditions. B, TMC typically shares incident information with other centers in the region. C, TMC does not share camera images with the public either indirectly or through travel information. Or D, operational needs are part of the Concept of Operations. Let's review the answers. The correct answer is C, TMS does not share camera images with public either indirectly or through travel information. It's a correct answer because agencies do that. We just talked about Caltrans and VDOT as well and agencies do share camera images with public directly on the Internet or through travel information. And so A is incorrect because the statement is true. The TMC typically does perform assessment of traffic conditions. And answer B is also incorrect because the statement is true. TMC typically does gather information during an accident. And answer D also incorrect because the statement is true, so Concept Operation is part of the operational needs discussion we just had. Let's look at an example here of Incident Verification with Camera. TMC needs to first verify an incident in order to ensure that the incident is real. And once the incident is confirmed and the reported conditions are analyzed at the location what is happening, then the proper response is prepared. So verification is a step before the response. And all incident management standard operating procedures are based on these steps. So looking at this picture, this overturned truck here and we see that the proper resources are at the site. This example here tells us about if you do have certain scenarios in your jurisdiction and if you archive, if you collect the information when it happens, you can actually later on learn what went wrong. What worked, what didn't work? So one of the uses we have in archiving video images in a very selective way is the scenario-based images. And this for example in this case there was an incident in 2005 and it's still being used as a training purpose in the sense that we really did something wrong. We did cut the guardrail, we should not have, and as a result a secondary incident occurred where a truck actually fuel tank got ruptured. So all of these things tell us something what not to do, not just what to do but in incident management it's also important to know what not to do. So video images are helping us to strengthen our standard operating procedures. This example tells us about Sharing Live Video Images with the Public. Public specifically is looking for information that you have and making it available in real time either by posting to the TMC websites or some other means you can retrieve it for later use. But the public is making their decision in an informed manner. If they know the current conditions, they can decide what to do whether to delay their travel or whether to take alternate route. Whatever decision they make, but it is based on the reliable or current conditions that is supplied by the public agencies. NTCIP 1205 Standard Supports Operational Needs; we have said several times basically providing us the interface so that we can use the objects in creating a remote capabilities. So the remote capabilities is available to use both during the live detections when the communication is intact, also sometimes when we lose the communication or the device is offline, we can also talk to the device later on and retrieve data. So during the Live Data Exchange for example we are able to configure a CCTV device. We can adjust the parameters one time and set it up so the device will work properly. This is an absolutely necessary function that we have to do. You cannot put a device in the field and not configure it and then expect good results. That will not happen. So we need to configure a device and set it up so that it will work properly as intended. Second is the monitoring capability. We need to monitor a device so that the current conditions are known to us. What is happening? What the device is doing now. What does the temperature reading look like in an enclosure, CCTV camera enclosure? What is the humidity level? All of these things, the conditions can be monitored in real time. Then you have the control of a camera, a control unit. A camera control unit is out there. We need to communicate with that particular unit so that functions can be ordered. For example we want to move camera from current position to a new position we want to check something or verify something. So all of these control capabilities will come from this live detect exchange. When the camera is Off-Line, device is off-line, that is also something that the device logs locally and so we want to be able to retrieve data later on when we need it and when we use this connection we have the situation we have to actually go back and revisit and get these conditions and see what really happened so we can find out the underlying issues or problems that the device had. Alright so this is very important so connecting to the log data also very important. For example in the new Dome cameras the IP network cameras that we mentioned earlier, it's locally processing and it collects a lot of data on a continuing manner so you really want to know what happened, that is the best way to reach out and get that data to you in the central location. So logging is an important situation and without communications when or recording data is intermittent. So Summarizing Learning Objective #2 discussion we had. Identify CCTV specific operational needs. We reviewed several scenarios operational needs and how agencies perceive the use of CCTV cameras to support the mission's objectives, traffic management operations 24/7 real time, sharing information with public, all of those things are operational requirements or needs that we have. And we reviewed in traffic management operations with the remote management as a principle focus. How do we get this remote capability so that our operational needs are connected or met using the remote aspects of the camera? For Learning Objective #3 so learning objective 3 now is to Identify and Write Well-Formed User Needs for a CCTV System. How to identify major desired capabilities example in a user need? We also need to generate or develop the user needs using the generic process that we have already discussing module A202 and we will bring that generic process to this learning objective as well here in this module. Then we will learn how to write well-formed user needs. So What is a User Need? A user need describes a major desired capability. It's called MDC. And it captures the intent. So MDC is the key discussion point for us because it talks about capability. It answers the question why is this capability operationally important to us? We talked about a lot of operational needs earlier, right, in previous learning objectives. Now we have to say well why this capability operationally important? We have to really write in that context. Then we have to be sure that when we procure it we really know why we actually need it. And if we are to- if we guess in that case that this is what I really need, we have to make sure that the system will do what it is expected to do. So there is a need connection to what the system will do for us and what problem it addresses. So there is a reason why a user need surfaces. It begins with the operational needs as we discussed earlier and it ends with very specifically what the system will do, what the system is expected to do. And what problem it will address. So that is how user needs are defined. Continuing in the sense with a little more detail what does a user need, it describes a major we have just discussed that and is why is the capability operationally important? Which is not really procuring systems without first knowing what it's going to do for us, right? And then we have to also we have also be aware that user needs actually help us to asses or validate if the system really did what it was expected to do. So user needs are helping us to not only operationally support us, but it also helps us to make sure that the system that we are obtaining, the equipment we are getting is actually going to do what we expected it to do so we validate that with user needs. Take a look at this system engineering "V" diagram as we call it. You've seen that before in the previous modules. So here we have three different aspects that we know about where the user needs are located. When we have stakeholders needs assessment, the general architecture, we talked about the service packages before so that's one source that we have with the user needs presence in that. Then you have the operational problem solving needs and agreements where we have concept operation with the stakeholders we will need these things and why we need it so those are the sources that we have operational needs as well as the user needs presenting that. Then after we have certain systems working, we already know what worked, what didn't work so there is a gap analysis also involved, reassessment. Did we really miss something? We should have these and we didn't have so now let's go back and we put it. So sometimes we bring these three things together and then we realize that this really all a user needs. We define what user did in the proper perspective. And we also mentioned here that the user needs actually help us to validate the system at the end of the procurement process. Let's have an activity here. The NTCIP 1205 CCTV standard does not provide the documented user needs for the acquisition process. So you already have acknowledge that. Now question is what is the best source of user needs? Four choices: A, traffic management concept of operations. B, regional ITS architecture. C, standard documentation or D, all of the above? Let's give you the answers. The correct answer is D, all of the above. It's correct because all of the above sources have links to user needs. We discussed them and then we realized that the assessment of each will ensure our purpose to identify user needs. Answer A is incorrect because exploring ConOps is one of the sources. It's very important source but it's only partially true. Same thing for B, answer B is also incorrect because the framework is only a partial source; architecture framework will allow us to look at but it's only a partial source. And answer C, similarly is also incorrect because standard only offers design solutions. It does not provide us user perspective so we only have design with us in answer C. So therefore answer D is the correct one because we need all of these things together. So What is a Major Desired Capability, MDC? What will be required from the system to address a user need? The MDC addresses that. An example here is Pan-Tilt-Zoom. This is a major capability delivered by the CCTV system. Pan because pan allows us to move the camera horizontally to the left to the right. Tilt allows us to move the camera vertically up or down. So we have to have that capability understood in our specification properly. Zoom allows us to look at near or far so when you say PTZ is a major capability, it's a very serious statement because most of the cameras are generally used for pan-tilt-zoom capability. And in fact if you miss this capability question could be asked are you only working or only running fixed operations? In other words fixed cameras don't need pan, tilt, and zoom but most other cameras probably would need PTZ. So that's what MDC references here. MDC can be extracted from CCTV standards through conformance groups. This is the only resource we have to link MDC to conformance groups and we'll explore that. So Extracting MDC is our main topic here. How do we get MDC using the standard, right? So this is a generic process we discuss in module A202 and we are now revisiting it here again so there are three steps. The first step is read. Read the conformance groups. Read CCTV MIB. There are 70 objects in this MIB. Conformance groups and objects must be read by the system specification preparer. We must read that so only when we read it we will realize that there are four conformance groups. One, CCTV configuration conformance group. Two, extended functions. Three, motion control, and the last one is on-screen menu. So you will be aware of it that our MDCs going to come from those four conformance groups, right? We go and recognize that. Now we recognize that. We firmly establish that we have to understand that there are certain functions categories are present in those four conformance groups. And then the last step we will infer it. We have no other choice, we have to infer that this is probably what it meant, this is what it means, actually not "probably", but actually means. So we now say MDC is coming from these four conformance groups and that is how we will start writing user needs. Let's take a loot at an example here. Extracting a Capability from the CCTV Configuration Conformance Groups this time. So CCTV configuration conformance group is a very important source for us. We read and we look inside the conformance group and we see what? We recognize that at least several objects, at least presets, position PTZ, and position lens parameters. And all of these things are labled in parametersrangeMaximumPreset. So we recognize that. Only after reading we recognize it, right? So now we're going to go and infer that an integer-number, there's an integer-number can be considered an MDC. In this example 32 is mentioned so preset is an integer in the sense that it is a major capability. We want 32 presets as a user need that is demanded by TMC. The next example is the motion control conformance groups. This is the second important source for conformance group. Second conformance group that gives us the motion control capabilities. Take a look at this thing. In the examination it shows us that the petition objects are listed and they are presetGotoPosition. So we recognize that and we read the standard and we recognize that and then we infer and we infer that the TMC operator has a capability to jump to a camera position at a preselected locations. So preset means that when a TMC operator pushes a button the camera will jump to that particular location and if that is what you need, that is what your user need is. How you write it. How you write it the way you're going to use it at the TMC. Take a look at the situation where we have multiple conformance groups. In this case auto-focus, a measure of desirability is auto-focus of lens. We want our camera focus be adjusted remotely from a traffic management center. So if we want to do that, then we need two configuration groups. The first configuration group CCTV configuration group uses object 1 and object 2. The second one extended functions configuration group will give us object 3, 4, and 5. We need these five objects so that we can remotely adjust the focus of the lens. In that case we will now write the user need saying that the operator has a need to remotely adjust the auto-focus of the camera lens, status, and confirmation. So these things are done when we have five objects put together and that's what will translate into the user needs at the bottom. Another example "Auto-focus" in more detail with the detail listed objects. There are five objects we just talked about. Here they are listed with their title. Each one of them has a very specific title so they are not repeated. And five are required and now we write an MDC. The operator has a need to adjust lens for near-far view for details. So when we write this MDC you can see that it's pretty concrete. It's not a guess work but it's pretty concrete so MDC brings that strength and a description of a user need. We are now summarizing in that particular discussion we had so there are two conformance groups, CCTV conformance groups has two objects that we are looking for and there are three from the extended groups so when you put the five together now we can actually write a user need which has a good MDC in it. A "TMC operator has a need to focus camera automatically from near to far limits within 50-500 ms interval, activate or deactivate lens components, and check lens status and availability." So those five objects make it possible to extract the MDC and then we wrote this statement here which now correctly reflects the MDC in it. And that's what makes the user need complete. So this is writing process. Now we will look at it, what will generate a Well-Formed User Need. But first we have a criteria for writing well-formed user needs. We have also discussed these things in previous modules but here we are repeating it again. So each user need, every user need that we write must have a unique identifiable title, it must have structure. This title or identification of ID you might call user need, UN, it should be unique. It cannot be repeated and it has to have structure. Second, it must identify one or more MDCs. Right? What function and features? So it should be in it. Then it should be solution-free. User need is not a design, it's not how to get it done. User need is solution-free. User need cannot contain how it's going to be designed. And lastly it should capture rationale. Why Is it even a user need? Why do we even have a user need? What makes it a user need? What purpose? What it's going to do? So when you put these four criteria points together a really good solid user need will be developed. Let's take an Example here. User need Need to Configure a CCTV Device. This is the most fundamental user need, absolutely necessary user need in a CCTV system operation. Alright? So this is a user need number one, configure a CCTV device. If you don't configure the CCTV device it will not work properly in the field and that's not something you really want to happen to a device. So for that reason this statement appears here very clearly. It says that "A TMC operator with access to management station has a need to retrieve information about the configuration of the CCTV device to properly communicate with the device." So it has ID, unique ID, UN 1 configure the title is very succinctly written. It captures what the intent behind this description is; configure a CCTV device, right? That's the intent. It also has a major design capability, MDC. It says that need to retrieve information clearly. Then it says rationale. Rationale is to communicate with the device. Why do I need to configure a device? Because I want to properly communicate to the device so there is a rationale that follows the MDC. And when you look at this whole description you will see there is no solution in it. It doesn't say how this is going to be done. It doesn't say how we're going to configure it. Leave it to the software engineer or the system integrator who is going to do it, right? It doesn't say solution. So when you write a user need you are not a software engineer who is providing a solution. You are simply writing what your need is. So we make that clarity here properly. This is also the time to say that eventually every user need becomes part of some kind of data base, you know? Somewhere it's going to translate where it's going to be implemented through requirements and design details. So we have to be very, very clear about it, so these four components and criteria are there for good reasons. Second Example, the Need to Share Video Images. We discuss about sharing video images among the regional jurisdictions. For whatever reasons they want to have your video images but that need is there and we need to state it clearly. It says that "video images with the regional stakeholders" and specifically identifies state and local DOTs, police, fire. These are emergency responders. So in such a case we need to write in a proper way and all of these four criteria points are now typed in here. Uniquely identifiable, rationale, rationale is that we want to coordinate it. It has an MDC. MDC says that it allows the control of your camera. And it's not solution in there. It doesn't say how we're going to do it. So that example actually allows us to reiterate what we discussed in the previous example. There's a third Example, a Need to Control Camera in the field. This is a major requirement on part of the TMCs. They need to control camera so this is a very good user need. A TMC operator has a need to control and monitor cameras from a main facility or a backup TMC. Now this is why it's a user need here. Generally you say well it's one location TMC is good enough for me. I can control it from TMC and if you forget about backup or second or third location then what? So then you will miss that situation. So if you really have this need to control camera from multiple location, then you should generate another user need that is separate and has to have rationale why you really need it. So in this case it says the "TMC for gathering information in normal and emergency operations." Normal when TMC is functioning. Backup is an emergency situation if the TMC something goes wrong or shuts down or under flooding condition if you lose the building then you have a backup location somewhere where you can operate from. And that this situation does happen like that so if that's a need, you should be considering a separate user need and that's the reason why it shows up here. User need 4 is a TMC a supervisor-induced camera tour. What is a camera tour? Camera tours are generally several sequence presets so they automatically sequence so that it will take the operations attention from one location to another to another automatically so you don't have to move around camera yourself physically. The presets will do it for you and sometimes when a shift change occurs at TMCs and the new supervisor will come in he or she may want to know how the cameras are set up so he or she may just use presets in the sense that the camera tour is taking place. So that is a need itself. Sometimes we have zones. Several zones are lined up and we enter from one area to another and these texts will show up, text messages will show up, programmed text will show up and say you are now in this particular area and now you are going to the next area particular overlapping area. So when you put it together all this overlapping view you see a whole zone mechanism from one zone to another zone to another zone; and sometimes when you manage incidents this thing comes up very handy and people do have a need for such zones so this is a user need. So this user need may or may not be presented in every TMC but in a regional sense in a large area it is definitely one of the user needs that's out there. Let's have an Activity here. Which of the following is a well-formed CCTV user need? Four choices, A, the TMC operator has a need for 64 presets. B, CCTV system must allow for 0-360 degree panning. C, the CCTV system must provide up to 100 labels. D, the TMC operator has a need for monitoring current value of the temperature in the camera enclosure for proper operation. Let's review the answers. The correct answer is D, it's correct because it contains MDC. It has a rationale and is solution-free. All of those criteria that we discussed before points are present here in this statement. A is not correct or is incorrect because 64 presets is a specific requirement. It's a solution you already now designing system and we discussed before that user need does not allow you to have a solution in it. Same thing applies to B because it contains a specific range of solutions, 0-360 degrees. That's not part of a user need. That's part of the requirement. So C is also with the same reasoning it contains 100 labels it's also a requirement for a specific range of solutions so therefore is incorrect. So Summary of Learning Objective #3, identify and write well-formed user needs for CCTV system. We reviewed in these learning objectives how to identify major desired capabilities which is the full strength of user needs. Then we reviewed the three-prong generic extraction process, read, recognize, and infer to derive user needs from NTCIP 1205 standard, how do we use configuration groups and get our answers from that. And then we also discussed the criteria, four-point criteria to write a well-formed user needs. We have to have a unique ID, a structure should have a major desired capability in it, then it should be with a rationale why we need it, and then it should be solution-free, no design in the user needs. So we reviewed all of these things in learning objective 3. Moving on to Learning Objective #4 is to Evaluate conformance to the CCTV standard. What are the minimum conformance requirements set by the standards? That's what we need to review in this learning objective. So conformance group is a basic unit of conformance to the CCTV standards. It is what we use and ensure that it is either mandatory or optional. Mandatory means that this particular conformance group, if it's made mandatory it is required by the standard. Optionally something the user will select for a specification. Section 4 of the standard 1205 actually provides a summary of conformance groups. Conformance Statement, lists required conformance groups. There are four listed here from 1205. The CCTV configuration is the only one that's mandatory, must be required to conform to the standard. The other three are left optional. If you want to for example if you want to have extended functions, then the optional conformance group will be selected by you, motion control, the pan tilt and zoom, that's also optional. But if the user needs it then you need to select that. And then you have on-screen menu. This is inside the camera. It's optional but if you really want those menus to be seen at TMC, then you need to select that. Also the 1201 we mentioned that the 1201 is a companion standard. Every implementation, every NTCIP implementation must have 1201 in it and here also we need 1201 there are certain global objects definition we have to derive take from that standard. So some objects from that standard are also mandatory. So to comply with the NTCIP-based implementation CCTV implementation, system implementation you will need 1205 configuration, CCTV configuration group and you will also need some mandatory data objects from 1201. So the reference to mandatory is very important because they must be selected. And optional as I said earlier left to you to be selected by the user so we have two activities. One we have to make sure that we are selecting mandatory. And in our case in this standard there's only four of them I know it's only one so it's very easy but we have to make sure that we are doing it correctly, properly. And the second one is optional. There are three optional and we have to make sure that whatever your local project requires you, you must select that. So these conformance groups, they contain certain mandatory objects as well and if you select the conformance groups, those objects go with it, they must be selected as well. So otherwise it's an incomplete process. So if the project user needs process does not map to these items both mandatory and optional conformance groups particularly, you will be missing out and your process will become incomplete. So this Example will make it very clear to us that CCTV Configuration Conformance Group is an absolutely necessary for CCTV system implementation. This is mandatory by standard and you really need it to put the device in a proper order so it will work properly, configure properly and then we functionality will come with it. So there are 30 or so objects here listed and they are all mandatory. So for this particular implementation system you need to implement all 30 objects in these conformance groups, alright? And each of these objects I mean also has a certain range in it and definition and form of syntax and they have a range so we have to select that so there are certain details that we need to pay attention to as well. For "Motion Control" Configuration Conformance Group which is optional, right? So if you select it and you are going to put this in your specification for pan, tilt, and zoom you already have in the third column here the last column you will require these objects. The objects are mandatory, absolutely. You cannot not select them. You have to select them and therefore they are mandatory. So for both motion control and the configuration before we have to understand that we need to provide these mandatory objects in our specification. Now this traceability table, this table does not exist by the way in the standard. We are showing you here as an example so that we need to create one for our project specification. The user needs must be traced to a particular conformance group. Every user need must be traced. It cannot be left alone and somebody will guess it and say yes, this is what you really want or desire. That's not going to work well. So you need to trace every user need to a particular conformance group that it relates to. In this case user need number one configure CCTV device traces to a conformance group 4.1.1 in the standard and it says CCTV Configuration. It also traces to 4.1.3 Motion Control. So both of these are necessary conformance groups to implement this particular user need. So then you list the others and the need concurrently and complete this table. So as I said we don't have a standard. This standard does not have a table like this but there are newer standards such as dynamic message signs They do have a table that's called Protocol Requirement List. It's only done for us and these PRLs in those standards do a very good job in tracing every user needs. Unfortunately we don't have that in our standard here so we have to overcome that by preparing it ourselves. Conforming User Needs Traceability, let's take this example here to see how we are doing it. We said that earlier user needs says that the "TMC operator with access to management station has a need to retrieve information." So now how do we ensure that these user needs are traced properly? So in this case it's traced to CCTV configuration group objects. So those objects will be necessary and should be selected so that we can meet the user need as desired. In this particular case it's about motion control or PTZ. So to communicate to the device and change the configuration we will be making sure that we are selecting proper objects. Now the final discussion in terms of Interoperability will come to us with a view that what is that we are actually concerned with? Well several things. CCTV systems are remotely accessed and controlled by management station located in the field. We are reiterating that thing. This remote accessing is very important issue. And then if we are going into one camera and another camera and they are all different, then we'll have problem. So we want to make sure, actually that we don't run into the situation when we cannot control different cameras, so accessing and controlling camera units out there is an important aspect of our interoperability requirements. To achieve interoperability we must select the same user needs. We have repeated that same theme several times. We need three things that must be properly paid attention to. User needs must be same. The design solution we select for our implementation must be same and we must use common protocol or compatibility. So those agencies who are interested in sharing each of those camera systems, they must pay attention to those three needs: the user needs, the design solutions, and a common protocol. Without this train we will not be able to expect it to do what we expect it to do. Interoperability will not be possible. Now the third point here is the Legacy platform. We have a lot of analog cameras out there in the country and we have new cameras coming up, digital cameras are already here. Dome cameras we show several times in the presentation. So and Dome cameras are also network cameras. They also bring IP with you the Internet camera. So a lot of these challenges are entering in terms of types of cameras. Analog cameras require some conversion in the way of controlling camera from one central location. They need to be converted, the signal needs to be converted. And digital cameras on the other hand they will be working fine because of the process information in all aspects of digital movement of data. So if you want to make sure that if you are looking for interoperability you need to make sure that these points are pretty much understood and covered when we write the user needs. Our final Activity is that which of the following is not a true statement related to the NTCIP 1205 CCTV standard? Choice A, supports video formats. Choice B, all mandatory conformance groups must be selected for conformance. Choice C, extended functions conformance groups allows on-off device remotely. Or D, supports PTZ capability for remote control operation. Let's give you the answers. The correct answer is A. It's correct because standard does not cover the video format standards. It's the industry standard that we are using. Answer B isn't correct because mandatory conformance groups are required to be conformant to the standard 1205. C is also incorrect because this particular conformance group, extended functions conformance group does support on-off control. You can turn the camera on or turn the camera off remotely. And answer D is also incorrect because this standard does support PTZ capability. In fact it is one of the main capabilities that the standard has brought to the table. So Summarizing Learning Objective #4, evaluate conformance groups to the CCTV standards. NTCIP 1205 standard has four conformance groups, one of them is mandatory. We discussed about that CCTV configuration conformance group should be an implementation. There are three optional conformance groups: motion control conformance must be selected if you really desire PTZ. And PTZ is generally a very highly demanded major capability in every implementation. And the third is that 1205 also depends on selection of some objects from 1201. So there are two standards we always need for NTCIP implementation data dictionaries, 1201 and 1205 in this case. So What We Have Learned in this module, a CCTV standard does not provide user needs. And user must identify and write them for project specification. Two, user need is the first step towards achieving interoperability and vendor-independence. Third, user needs can be found in the traffic management Concept of Operations. Four, a user need must be uniquely identifiable, defines a major desired capability, captures a rationale and must be solution-free. Five, we learned that NTCIP 1205 standards offers conformance groups which are defined as a grouping of the related objects. And NTCIP 1205 CCTV standard MIB provides objects for CCTV system design. Some of the Resources that are available for preparing specifications. A lot of this information, good information is provided in the Student Supplement that you can look at it. There is some discussion about the operational aspects of CCTV system, what questions you need to ask up front. How am I going to use the CCTV system? There's a very good document prepared by Federal Highway Administration that has been include a portion of it in this supplement which will allow you to clearly understand what the CCTV operations are about. Also has a definition of key terminologies that we have used and also discusses certain video formats, definitions. So good stuff in the Student Supplement that I encourage you to look at it. There are other sources includes the standards themselves are available at NTCIP.org website, both 1201 version 3 standard is out there. Also 1205 camera control standard is available. NTCIP guide, NTCIP 9001 is information report. The guide is a pretty detailed document. Has a lot of implementation aspects covered and a lot of framework diagrams are in the guide that you may be interested in seeing how all these different things come together. So please visit NTCIP.org site and get all these things that you maybe are interested in. Also as you do look at module A202, identifying and writing user needs when ITS standards do not have SEP content. It's available at this website link here presented and this very specifically written has a lot of good discussion in the generic extraction process, a lot more in detail and you will benefit by looking at that module. So please consider that. Question? There are certain questions that can be discussed in a brief manner here. Some of them are frequently asked questions that have come up. I will raise with you several of them here. Question one: "Why there is no mention about parking management?" Well we did say something about the parking management. For example in today's module here the parking management is part of the application of the traffic management. It's part of the traffic management system. So good information about parking space availability. Camera can be used to say what is parking situation look like? Is it full or are there some spaces available? So it's a good application. Second question is "Is archiving video data a liability?" Well in some ways it is. If you are not careful in terms of how we are going to use these things, certainly for traffic management learning purposes, standard operating procedures improvement, we can use the operational scenarios and see what worked last time, what didn't work, what mistakes we made, what we should not do next time around if something similar happens. These are all the good things that we learn from archived video. And we have improved a lot of standard operating procedures as we move along. And SOPs are living document at every TMCs. So I would encourage you to look at the operational scenarios and they don't have to be alone also. They can be from your neighboring jurisdiction. A lot of people have similar issues. For example the weather emergencies that we are facing in the country currently there is the extent and the scope may change from place to place, but the underlying reasoning and nature of the response mechanism probably are common in many cases so we can learn all of these things. And we can only learn all these things if we look at the archive videos. So yes, there are certain ways you can benefit and we are not in the areas where we need to go, traffic management purpose only and not indulge in other parts of the business that you might be thinking about using the video images. "What does SEP base standard mean?" That's the third question. SEP means Systems Engineering Process. It is a definite process used to develop ITS project, also the standards. Some standards, newer standards were developed using SEP process. However today’s discussion we said several times this is camera control standard is old one and it escaped that SEP so we don't have documentation. We don't have content of user needs requirements. We only have design of a label in the non-SEP. So that's the reference of SEP based standard we had. Question four: "Do you need to specify all of the parameters values of the mandatory objects?" Yes, I did say something here today. We do need to handle mandatory objects and the ranges, parameter ranges in the proper way. For example if you are looking for 32 presets the object has a range 0-255. So if you say zero you're not going to get any presets capability. On the other hand if you say give me everything 0-255, 255 no one uses 255 and your need may be just 32, right? So therefore we have specified the parameters in that sense. "Does NTCIP 1205 standard support IP network base?" Yes, the standard is independent of how you use the cameras so the answer is yes. "Can we use NTCIP camera manufacturers proprietary protocols at the same time?" The answer is clearly no. We cannot use two protocols at the same time. You can choose to use proprietary protocols and not get interoperability. And you can use the NTCIP protocol and then you achieve the interoperability that you're looking for. And final question "Is the first to hear that analog cameras and digital cameras." Now I mentioned several times also that analog camera that cameras if you want to control them from the same TMC location using the same mechanism then analog cameras needs to be converted the digital signal needs to be converted. The analog signal needs to be converted to digital signal that is so that it can control the camera properly using the same terminal as that. The IP cameras are digitally controlled. So these are some of the typical questions that you may encounter. And with this I will now go to the last slide we have. In the Next Course Module we will be dealing in A317b which is Understanding Requirements for CCTV Systems Based on NTCIP 1205 Standards. Here in this module we will discuss how to complete specification process by putting requirements in order. We will explain how to write them and include them so their specification is completed. Specification is not completed with the user needs along. We need requirements as well. And it will explain how we will create a relationship between requirements and the design of the standard, design process that we got from the standard. So it will close the gaps that we will face. And then it will also discuss the interface, how do we communicate with the device? What are the interface details? So these three important issues will be dealt with in the next module and we urge you all to revisit and come back when this module is ready and take it at your convenience. With this the discussion on this module is now coming to close and thank you all for taking this course.
#### End of 2013_05_06_10.14_A317a_Final_Recording.wmv ####