Module 11 - A313a

A313a: Understanding User Needs for ESS Systems Based on NTCIP 1204 v03 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.)

 

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.

Raman Patel: This module A313a, Understanding User Needs for ESS Systems based on NTCIP 1204 v04 Standard-- this is an updated module. We have revised it since the last one based on the current version of NTCIP 1204, so the standard has a little bit more elaborate user needs arrangement, a lot more new approach in terms of user needs, so this module is reflecting that.

Raman Patel: I am Raman Patel. I was working for New York City for about 30 years as Chief of Systems Engineering. I have been involved in standards-making process for the last two decades or so, and currently I am teaching at New York University Tandon School of Engineering, master's graduate program, and urban infrastructure programs.

Raman Patel: This module has four learning objectives. Review the structure of the standard. Second learning objective is to identify specific ESS operational needs. Third learning objective is to use the PRL to select the user needs and traceability to requirements. And the last learning objective is about discussion on how to prepare a project-level PRL, which stands for Protocol Requirement List, for ESS specification.

Raman Patel: So collectively these learning objectives give us the skill set we need to prepare a good specification. The first learning objective will allow us to go into the structure of the standard and figure out where the information is.

Raman Patel: So, let's look at some of this terminology that we are going to use in this module. Sensor. What is a sensor?

Raman Patel: A sensor is a device that responds to a physical stimulus and transmits a resulting impulse to a remote processing unit. So it has only one output, and that output is transmitted to a remote processing unit nearby.

Raman Patel: Environmental Sensor Station, ESS, or sometimes we also refer to as a plural—Stations. And it is a location where all the sensors are located for that particular area. So it is located perhaps on a bridge or a roadway, and it collects weather data using range of sensors. As you can see on the left, you have the station; on the right you have a little more details about how a particular ESS station collects data from sensors.

Raman Patel: A Remote Processing Unit, or RPU, is a part of a controller, ESS controller out there in the field, as is shown here on the right side. An RPU is part of the controller inside the controller to manage the different sensors that we get. It collects data from the sensors and then it transmits it to the Central Management Station.

Raman Patel: Road Weather Information System, RWIS, is another terminology that's being used heavily in the weather management systems. It is a network of ESS that relay road and weather conditions to a computer system. Usually the computer system is located at the central traffic management station. As you can see here on the left side, we have an image of a roadway where all kinds of weather information is shown, and also on the right we have multiple sensors mounted on a pole and then there is a map in between. So what it tells us, that RWIS as a system; it is providing us weather-related coverage over a wide area, over a region, perhaps, such as the metropolitan areas.

Raman Patel: There are three types of RWIS. The permanent, or fixed locations-based ESS, provides us sensor data information from one particular location. The portable one is a vehicle base but it moves and then also supplies, continuous supplying, the information that the sensors collect. So it's a maintenance vehicle sort of providing mobile data. The third one is transportable. Sometimes you have a location where you need to put a vehicle-based system, and then you are done with it and then you want to move it to some other location, right? So it could be transported to a newer location where you have similar information available. However, in the transportable mode, you can only transmit information once you go to the next location. So it does not transmit data during the moment.

Raman Patel: Flashing beacons are mounted on the roadsides of some locations where you want to alert people, or public, traveling public, motorists, for a new message. And it's just a lamp that flashes to gain attention from traveling public. For example, there is an optional video monitoring also. Whenever there is a beacon, there is some kind of camera statement is also available so that you can see what's going on in the general area.

Raman Patel: This example from Iowa DOT for Road Weather Information System collectively projects, different range of sensors. For example here, seven of them are listed on the pole, on the right, and also there is a video clip available that you look at this discussion on Road Weather Information System from Iowa DOT, how they are actually doing it. It's a short video and we have provided a link that you can use it and get on and look at the video and see what it says. So first example here is a wind speed and a direction sensor mounted at the very top of the pole. Antenna for communication right there next to it. Also the traffic speed and counting station sensor mounted there. You have a pan-tilt zoom color camera in a dome that's shown here. Precipitation and visibility sensors. Air temperature and humidity sensors are also shown at the bottom. And then also you have the road surface temperature sensor, or subsurface temperature sensors, below pavement. So collectively these seven different sensors are providing them the input in the Road Weather Information System.

Raman Patel: The NTCIP framework provides us the range of capabilities to provide data dictionaries so that we can actually create a message using the data dictionary elements. So that's at the information level. At the lower levels, you have other protocols that are needed to move the message from one place to another. So, for example, you have SNMP, Simple Network Management Protocol. That protocol is a ruleset. It allows us to move data. It has a built-in messaging structure that we use in this module and the next one.

Raman Patel: So major component of ESS system includes a management station at the central location. You have RPU, Remote Processing Unit, in the field, which actually has inside it a sensor manager, ESS manager, and a PTS manager. PTS stands for Pavement Treatment System. So collectively these three task managers actually provide information to the central location using NTCIP 1204 interface.

Raman Patel: The ESS standard has evolved to v04 in 2016. So recently started process was non-SEP, meaning that it was done without systems engineering process, and therefore there were no user needs written down or described. So then we had Amendment 1 slightly after that, and then v02 brought the SEP process to it, whereupon we have user needs or features already defined. Then we go into v03 in 2009, which actually updated the SEP content, but also provided test procedures. So we have in Annex C that detailed procedure is now available. The current version,1204 v04, was released in 2015 with a lot of new materials, lot of new user needs, such connected vehicles related. It also reflected lessons learned from the previous versions and deployments.

Raman Patel: Structure has several sections in it. The standard General section has information, administrative details; Concept of Operations in Section 2; Functional Requirements, Section 3; a PRL, Protocol Requirements List, is an important tool that we will be discussing in this module, is in section 3.3; Dialogs are Section 4; MIB, which is called Management Information Base, which is the definition of object of design, which is located in Section 5.

Raman Patel: There are several annex that come with this standard in v04. Annex A has RTMs, or Requirement Traceability Matrix; Annex B has Object Tree; Test Procedure is in Annex C; and Document Revisions, and so on. So the rest of the others are providing general information to back up the information in the main sections.

Raman Patel: So how does the structure relate to the agency ESS RWIS specification? Well, going in, we need to develop specification based on several things. First, concept of operation, which is the Section 2 user needs. Right? We need user needs. Section 3, we need the requirements, and design is in Section 5. In addition to that, we have a PRL, RTM, and test procedures. So all of these six things, six items that we are showing here on this map, on this slide, is actually mapped to the concept of operation, requirements, and the design on the left side of the Vee leg.

Raman Patel: Standard also supports the Road Weather Data Collection Service Package from ITS architecture. So the interface is created which will support actually what goes on between the roadway and traffic management as far as communication interface wise between the two ends.

Raman Patel: The user needs not covered in this v04 are sampling periods. For example, we collect a lot of weather data; air temperature-- for over ten minutes or fifteen minutes interval, or sometimes maybe five-minute interval, right? So and then we average it and send it back to the central. That part is not configured. We have not defined user needs, how to do it, because it's left to the project level treatment at the traffic management center. Also, something called File Transfer Protocol, or FTP, to transfer camera pictures, snapshots across the agency network. This is also not standardized, because some agencies permit it, some don't. So standard has made no attempt to standardize that. As you can see on the right side, the pictures tell us-- the image on the top tells us a lot of details, actually, about the condition of the roadway and the image on the bottom is maintenance vehicles, how they're managing out there. So this image with the sensors on the right, on the tower, actually tell us how user needs are met in terms of standards or description of the user needs.

Raman Patel: First activity. Which of the following is not a correct statement related to the ESS standard? A, standard supports RWIS, Road Weather Information System. B, standard supports communications interface. C, provides traceability tools. D, states sensor hardware requirements.

Raman Patel: The correct is D, states sensor hardware requirements. The statement is false. ESS standard does not cover physical hardware requirements for sensor. For example, temperature range. A -28 degree, 258 Fahrenheit degree requirement is not part of this standard. It's covered in the hardware specification separately in another standard. A is incorrect statement, is true. The answer is incorrect because the statement is actually true. Statement does support RWIS. B, similarly, is also incorrect answer because the statement is true. Standard does support communication interface. Similarly, answer C is also an incorrect answer because the statement is true. The standard does provide traceability tools such as PRL and RTM. In fact, PRL and RTM form a key part of the standards help for user specifications.

Raman Patel: Our second learning objective is to identify specific ESS operational needs.

Raman Patel: So, let's look into see what are the operational needs that relate to the ESS. So we start with the road environment. So, road environment. So, what are the elements affected within the road environment? Affected by weather, that is, right? So you have four elements that we need to acknowledge. First is the roadways themselves. The roadway itself is affected in many ways because there are weather conditions out there that will render roadway less useful or less efficient, if you want to look at it that way. The motorist then are also affected because now the weather is slowing them down. The speed has dropped, and their maneuverability is now increased,- limited in visibility and things like that. Vehicle is affected because the roadway conditions have made the pavement more or less efficient, shall we say, but also friction is now less friction available, so the traction and vehicle maneuverability is also limited to a great extent. So that part is very important to understand, where the safety issues lie. And then finally, the assets. The roadside has a lot of assets. There's a divider, there's a marking, there is all kinds of assets out there-- boxes, controllers, other furniture out there that are also affected in some ways, and the condition of the pavement in general will also deteriorate or will be damaged.

Raman Patel: So roadway operational environment weather variables. What are the kind of variables impacts the roadway environment in general? Well, air temperature and humidity comes to mind right away, right? Precipitation. Wind speed. Fog. Water level. Pavement temperature. Pavement condition. Snow and sleet. All of these things make the operational environment less safe maybe, less efficient maybe, and also maintenance-wise, it also has impact on it. So collectively we can say that the weather variables are more than one. There are quite a few that really impacts the operational environment upon roadway.

Raman Patel: Visualizing what really these images are telling us, the first image on the right is telling us how the CBD, Central Business District, is isolated because of the flooding condition over the bridges and viaducts and highways. Right? Another image is showing us that because the water is collecting in the roadway, the cars are just piled up there. They can't move further. A third image showing us at the bottom a hurricane, tornado. On the right we have a snow removal process underway. So all of these images collectively tell us that rain and flooding, snow and ice, low visibility, hurricanes, high winds-- these are all the events that affects, adversely affects, or impacts roadway operations. That's what we want to say.

Raman Patel: So here is a picture of Central Business Districts where all the routes are now hampered because there's five feet of water. Right? So we can see that the flooding is also a major issue that the inner cities and metropolitan areas have to deal with.

Raman Patel: So generally, in a situation like that, lots of access routes. So flooding almost always removes, or creates impairment, for example, to Central Business District access.

Raman Patel: Operational concerns for roadway drivers and vehicles. There's always a combination of roads, drivers, and vehicles. So let's look at what are the adverse impacts of roadway conditions. On the roadway conditions, we have a situation that now impacts in a way-- reduced capacity. The roadway was designed three lanes moving, now maybe two lanes moving; maybe one lane is partially moving. So roadway conditions results in terms of reduced capacity. So access, we just looked at the access issue is present in the adverse weather condition, throughput, number of vehicles passing through a given section. And the speed. It's not 55 miles as the highway is designed for. It may be 20 or 30. So there is a reduction in speed. So that's one of the parameters. Visibility impairment impacts the driver's behavior. If you don't see far ahead and you suddenly stop-- so stop-and-go kind of driving. There is a quick reaction. There is also maneuverability of vehicles. Drivers attempt to move this way, that way, trying to find safer ground, perhaps. So all of these things leads to the safety as an issue, as an impacted variable. Then you have vehicle. The vehicle is impacted by the traction, availability of friction. Wet weather reduces the friction. That allows the vehicle to not go fast. It does allow, actually, the vehicle to go fast, or as desired, so performance of vehicle is also now impacted. The skidding process continues in wet weather because the pavement don't have friction. So relatively speaking, crash potential also rises with the bad weather.

Raman Patel: Then you are measuring adverse impacts on the safety specifically. Well, this is a big issue. So 1.5 million or 23 percent of annual vehicle crashes in 2015 related to safety that's impacted by weather. You have 800 thousand injuries. So, 7000 fatalities, or 20 percent of total 35-thousand-plus, attributed to weather-related vehicle crashes. These statistics tell us that 20 percent is a large portion of the safety-related crashes and then fatalities coming from there. So in this chart here we are showing on the right, bottom right, you see that the flooding is a big issue-- 155 fatalities attributed in 2015 to just flooding conditions. You have tornadoes and you have heat, and so on. So all of these add up to poor safety during the bad weather.

Raman Patel: Measuring adverse impacts on mobility. Since highways and infrastructures are designed to provide mobility, we focus in a real way and look at it very closely and say, "Well, what really happens on the roadway?" Well, you get the roadway's closure, right? You got to close the road. Certain roads, they are not conducive to driving, whatever. So that in turn impacts the capacity. Capacity, speed, volume, right? Everything goes down sort of. And the motorists, traffic signals, vehicles, trucks-- you name it-- all road users are impacted in terms of mobility, and its effectiveness on delivery process.

Raman Patel: If you measure the productivity as an impact in terms of how we lose the dollar and cents and economic benefits-- so 20 percent of winter maintenance by state DOTs. That's the budget, right? They spend 20 percent on winter maintenance. So that's pretty high burden to maintain winter weather. Then you have delays. Right? It costs. Every time you are delayed, there is a cost that go with it. Then maintenance worker safety is also impacted. They're out there, they're doing their thing, and suddenly, because of the bad weather or poor visibility and so on, there are additional issues that come in terms of protecting workforce. As an industry, as a sector, trucking loss, they are engaged in goods movement-- 3.5 billion dollars lost in just roadway damages-- potholes, things like that. So trucking losses and roadway damages combined just goes a lot more than the 3.5 billion dollars stated here. As example from Pennsylvania DOT, for example, their budget for 2013/14 winter was 189 million dollars, and they ended up spending 284. This gives an idea that winter maintenance is not a small issue for state DOTs.

Raman Patel: Operational need. Assess roadway condition with sensors-supplied data. So we have traffic management center. You have a workstation there which has the roadway weather information system. In the field you have conditions out there which are measured by sensors. So we measure the visibility, precipitation, high winds, temperature extremes, pavement conditions, pavement friction conditions, snow, ice, rain. All of these things are measurable in many ways and that information is allowing central location at the TMC to put that as a part of the RWIS and come up with a good formation that we can use to run the operations.

Raman Patel: User needs are translations of operational needs. So once we know what the operational needs are, the user needs can be defined, as it's done in this standard. So section 2.5.2.1 here, for example, has monitor weather conditions, monitor atmospheric pressure, monitor winds, monitor air temperature. So the list collectively tells us that there is a way each one of the operational needs that can be met by user need.

Raman Patel: Operational need deployments Road Weather Information System as a decision support system to take action. So RWIS is a decision support system. Using the RWIS, the management center actually makes a good decision, and then they will come up with the action. So what do those actions look like? Well, the first section is to advise, right? So advisory is classified as first action. Second one is the control. Well, you may have to control the assets; roadways, bridges, tunnels. So that's a control mechanism that we have. And then treatment. We have to send workers out there, maintenance workers out there. They go out there and treat the pavement or close the bridge or close the lane. So whatever they need to do in terms of making the roadway safer-- that has to be. So there are three actions: advisory, control, and treatment.

Raman Patel: So in the actions that we take, generally by advising motorists, we do that through the display message signs, variable message signs, or dynamic message signs, right? We put a message on that. We also supply information in a 511 system, providing text messaging, emails, put the messages on the web, right? Web messages will provide the picture as well as a description of weather condition. And also we inform media. Media has interest in receiving information from the public agencies and public agencies have a responsibility to providing information so that it reaches out to a very wide area, region, or very wide population. So everybody wins from that effort. So actions, for example. Now things are bad, and then we tell them in a specific manner what they should do. For example, the sign here on the hurricane warning, right? Hurricane warning. Well, there's a short time available; the opportunity for making people safer is very short. So if you know about it and the message is out there, people will actually be advised and say, "Well, seek shelter," and that's a powerful message, and say, "Please leave the roadway and go to a safer place." Also in the dense, for example. The sign on the bottom left shows there's a dense fog ahead. Well, if the fog is ahead and you are not near but if someone tells you that there's fog ahead, that's additional information you have that will help you to make a better decision. This image on the lower right is telling us the conditions out there on particular arterials.

Raman Patel: When we have to take control actions related to weather, we are either closing the bridge or a tunnel or a section of a road. For example, due to the fog, as we see on this sign on the right and left, we say the icy conditions, and, "Do Not Enter. This Section is Closed." That kind of thing. So these are very timely and also very effective way of letting public know what they are not expected to do.

Raman Patel: Treating the roadway condition. In many ways-- we all have heard about the black ice, for example, on the roadway-- the ice you cannot see because at 30 degree the ice will freeze and it will be hiding underneath the pavement, disguising sort of. Not underneath, but in a way it will blend with the color, so that's where it carries its black ice name. Now, last several years in the countries we have been experiencing a lot of black-ice-related accidents, and then many agencies are now well prepared to deal with it in proper locations or where they have identified certain needs. So during the winter weather, this issue has come up, and then the agencies are preparing themselves ahead to do the maintenance work.

Raman Patel: Annex F.1.1 has the architectural needs that supports operational environment. So these architectural needs are to provide live data when there is a connection, right? So you can actually continue talking to the field device from a management station on the left, and then device will provide you continuous data. So that's during the live operations. Compressed data-- we don't transmit data every second or so. There is a possibility that the network is not efficient, or have sufficient bandwidth. So in that case, we will compress data and send it in one shot. Instead of sending continuously, we will compress the data and send together in one piece at a certain interval. When we lose a connection to a central device-- or sometimes we use dial-up connection, right? So when we don't have communication, the device continues keeping log and stores data. That data is available. So when there is no communication in offline condition, we will be able to download data, log data back, and then we can clear the memory and say, "Okay, we've got the data now." So these operations are supported by architectural needs. The generic features are also supported by the architectural needs.

Raman Patel: So there are three categories of features supported. Features are user needs, sort of. They're supported by ESS Manager Features in Section 2.5.1; Sensor Manager Features in 2.5.2; and PTS. PTS stands for Pavement Treatment System. Those features are provided in Section 2.5.3.

Raman Patel: Let's look at one by one. ESS Manager Features supported by standard. ESS Manager manages both a Sensor Manager and a PTS Manager. So it's kind of a master manager sort of, if you to say it that way, that communicates with the central location. Specific ESS features are generally generic features, general for different devices and types. A specific one, monitor door status, 2.5.1.2; monitor power, 2.5.1.3; monitor mobile station data, 2.5.1.4; and what type of ESS exists out there, and you want to figure out and want to know about it, inquire about it, then you can do that through this feature. So there are several ESS features which are widely used because are supported by the standard.

Raman Patel: For example, 2.5.1.2 is monitoring door status, right? A transportation system operator may wish to inquire if any doors on the ESS equipment are open, without having to send somebody at the location. So this is a good feature. So we say, "Okay, let me just go make an inquiry and see what the message come back with."

Raman Patel: Other way to look at overall statewide deployment, for example, of weather station-- this example shows very well from Idaho DOT. You have a region-wide treatment here. More than one ESS stations are out there located in the region. That is kind of-- multiple sensor stations are out there, right? On the left you have an image coming from a camera. So it's a snapshot of the terrain, how it looks, how the highway looks like under weather condition. Then you have variables providing you different level readings of sensors: precipitation, visibility, wind speed, gust. All of these things are coming. So collectively the deployment examples-- so there collectively, we get all the benefits from ITS applications that agencies generally have in mind using these kind of weather stations.

Raman Patel: More examples of deployment of ESS. Alabama has, for example, 26 sites on ESS, shown here on the map on the left side. Georgia, next to it, shows over 27 RWIS sites. Florida, on the right, shows 52 sites. And all of these deployment examples collectively provide information that can be used at the central location through the RPU, the remote processing unit, and also this information can be provided to public on various different means such as the cell phones and messaging devices.

Raman Patel: This example from I-10, Florida DOT, you can see on the left there's an RPU mounted in a cabinet on the pole. On the right side you have several images shown of the sensors. Each one of these sensors provide us numerical data in terms of variable ranges, and these ranges and data used very heavily as part of the RWIS system.

Raman Patel: Purpose of ESS deployment by transportation agency. The map of U.S. showing here deployments are quite widespread across all the states. This is a 2008 map, but it tells us the extent of how the progress has now occurred. Collectively, these ESS stations provide timely, accurate, and relevant road weather conditions. So this is just not information that is going to sit there; this is the kind of information that ESS provides which is actually used to make decisions so that the operational conditions can be assessed-- that is roadways, what condition the roadways have, and whether the motorist will be safe, whether the motorist can easily navigate, things like that. So, many ways, motorists will make their own travel decisions and adjust to the roadway conditions. So once you are on the highways you are there, so all you can do is to adjust your decision based on whether the roadway is conducive to travel or to whatever necessary in terms of making travel decision.

Raman Patel: Some examples of ESS Manager. ESS Manager monitors power. System operator may wish to monitor the power for the ESS to ensure proper conditions. This can be done remotely. As you can see, the workers on the right side image are providing a structure. They're erecting something to support the ESS. So such things can be actually remotely monitored also. Monitor the data, what data is out there available in a mobile as well as in a fixed environment. Some generic features are also covered.

Raman Patel: This slide shows sensor manager features. Sensor manager will monitor weather conditions, pavement condition, and monitor subsurface conditions, monitor human readings, water levels, and so on-- air quality and biohazards-- ozone levels, for example, right? So these are all the examples of how sensor will collect different types of information, and these capabilities are provided by the standard.

Raman Patel: For example, here, manage mobile spray system, right? So during the winter, this is one of the most common thing that occurs is the salt trucks are out there spraying salt and then deicing liquid as well on the right side. So both anti-icing and de-icing chemicals are used collectively in winter maintenance management.

Raman Patel: Our activity here is now to answer: Which of the following is not part of the ESS standard. Answer choices: A, collection of atmospheric and environmental data; B, monitor the status of the ESS; C, assessing if an ESS is permanent, transportable or mobile; and D, creating a weather advisory message on a variable message sign, right? VMS.

Raman Patel: The correct answer is D, creating a weather advisory message on variable message sign is not part of the standard. This standard does not support. But another standard, called NTCIP 1203 DMS standard does. Answer A is incorrect because the feature is supported by the standard. B similarly is also incorrect answer because this feature is supported by the standard, monitoring the status of ESS. And C is also incorrect answer because assessing if an ESS is permanent, transportable or mobile is actually supported.

Raman Patel: So that brings us to our Learning Objective 3. We have to discuss now how to use the PRL to select user needs and traceability to requirements.

Raman Patel: So, what is a PRL? PRL stands for Protocol Requirements List. PRL is a table. It is a matrix. Right? It provides the standardized relationship between user needs and their requirements, and as a template with fixed columns and multiple rows. It guides users and DMS manufacturers and suppliers. So you see this image of a PRL cut-view here, there are certain columns. The columns cannot be changed, and the rows have information about particular user needs.

Raman Patel: Standardized relationships provided by the standard. Well, agency may have one user need which could be met by one requirement. Agency may have one user need that will require two requirements or more requirements, right? And then you can also have a situation where many user needs can be served by just one requirement. So such situations are out there and the standards can take care of all of these different needs.

Raman Patel: So PRL is a place where we get this guidance. PRL template guides agency to select proper user needs, and project-level user needs. PRL then presents associated requirements. So this is a two-step process PRL is handling pretty well, right? So the agency completes the rows with the text from PRL provided by the standard. So the columns actually tell-- the first column is a user need ID; second column is user need; third column is functional requirement; fourth column is the requirement title; fifth one is the conformance; sixth column is support; and the last one additional specification, allows you to put some notes. So this is the basic structure of a PRL in terms of how it provides the guidance.

Raman Patel: Let's look a little more closely. As I said, the first line is the headings for the PRL. Here the user has no role. We cannot change anything. That's the way the PRL is, right? In the second line, an example of a user need shows 2.5.1.2. That is the Monitor Door status. That is a user need, right? Anything that starts with Section 2.5 is a user need. In the second line, we have the section number and its title. Then you go down further and then you see the optional user need. Under Conformance, O stands for optional, and M stands for mandatory. So optional need is selected by a user by selecting yes or no in the next column, which is called Support.

Raman Patel: In the Conformance column, much more information is provided than we think. See, here it says that you have to identify the user needs and a requirement is mandatory. The standard has marked all mandatory requirements in the PRL and all optional also in the PRL. So, sometimes we have more optional user needs and then the role for the user is to select at least one of them so that we can complete the PRL. So some basic user needs are considered mandatory by the standard. So they have to be selected. We have no role. We have to accept that and select M, marked user needs. For example, ESS type. What does the station look like? Is this a permanent station? How can we identify that? How do you make sure that some location that you are not aware of it probably has a transportable, which is another type of environmental station? Or, a truck, a maintenance truck, may have a mobile environment where you have the measurement plus the communication network to transport data back and forth, right? So such things are important to assess in terms of what are requirements are, or the user needs are.

Raman Patel: So, what should an agency do? Well, first circle Yes to indicate support for project-level user needs. If you have a user need that you really have identified in your project, you must select Yes. If there's no identified user need, then you select No. If the conformance shows selected user need is mandatory, you must select M, then you must circle it, regardless. So like we are showing here, we are circling Yes.

Raman Patel: So, in the last column then, what we will do, we have placeholder to provide additional information. So if you think that it what I'd like be required and help-- in some cases you do require to put additional information-- then this is the column that will do for you.

Raman Patel: Let's look at this example for monitoring winds. The agency has established that there is a need, operational need, to monitor winds. There's a high bridge structure shown here on the right, so obviously you can see that there is a need to measure wind condition over and around the area on the bridge, around the bridge vicinity, for measuring wind conditions. So this user need will be implemented with the associated requirements in the third column. So if the user need is identified and is required yes, like in this case, Yes, then the associated requirements will be identified, as we are showing here on the right two boxes-- two red boxes on the right side.

Raman Patel: Completing a project PRL, functional requirements, a very important job that we have to go through. These requirements are also coming from the standard. So for each identified user need, standard has already done a complete job of identifying particular requirements that you will have to deal with. So for every user need, there are associated requirements in the PRL. So again, we don't have any job on our own except to select Yes and support is required or no. Those are the kind of things we'll be doing in completing the PRL. So in this case we selected Yes, because we want to monitor winds around the bridges and whatever other structures. So in that case, we have selected Yes, support. That means that everything "M" is selected Yes, and also everything "O" is selected Yes. So collectively, once you select operational user need Yes, you have all associated requirements will be included in this specification.

Raman Patel: Partially filled-in PRL example shows here how we allocate support. So, again, we are going through these four columns. First one, user need. Second, user need title, then ID for functional requirement, and the requirement itself. And then we are selecting Yes, monitor door status. This is another example. If you select Yes, the requirements associated will have to be completed in the PRL itself.

Raman Patel: So, agency's perspective for project PRL is pretty good, because agency says, "Here's my user needs. Here's my PRL." So I'm communicating to the outside parties that these are what the user needs our project has established. So it communicates. PRL communicates the scope of the desired ESS interface. That's a very important point. It makes it easier to specify what interfaces to do, because now we can customize. For each user need, we can lift the requirements from the standard and combine them in the project-level PRL. Third, it spells out conformance requirements. After all, we have to conform to the NTCIP standard, right? So, PRL will help us do that. It spells out. It acts as a checklist. Checklist, because every user need is listed in the PRL and we're going to verify and we say, "Check it out later on," and we're going to go into elaborate process and say, "Are we really at the stage where they have built the right system as per our user needs?" At that point we will be also making sure that we have achieved interoperability or not. So it acts like a checklist. In general, PRL does provides multiple services through a very nicely organized structure.

Raman Patel: For vendors and system developers, it's also a connected world. You are connected on the same page with your client or user. So if you understand what the user wants, then you will understand through the PRL that's a pretty good benefit. It eliminates guessing. "What does my client want? What do they really want? Why do they need this thing?" Well, wait a minute, they made a decision. They gave the PRL, so now all the guessing is behind us now. There is no guessing actually to be had. So with that, it also brings the element of reduction in risk. If you know what someone wants, your client wants, user wants, then you are actually also embarking on a right way in providing the capabilities in the system. So, the vendor actually confirms at the end and says, "Okay, you asked for this? Here is what I'm providing you." So ESS functionality is confirmed. Right? First time from the user side; second time from the vendor side. So it's a good thing. Then it offers optional features. Vendor can also list optional features that he's willing or she's willing to provide to the client.

Raman Patel: Our activity now is to answer: Which of the following is not a correct approach to preparing the project PRL? A, select YES Architectural needs; B, select Mandatory ESS Manager features only; C, select YES project-specific features; and D, let the vendor select ESS features.

Raman Patel: And the correct answer is D, let the vendor select ESS features. The answer is correct because the statement is false. You don't want the vendor to select ESS features. You want the agency to select the features, right? So the entire purpose of providing PRL in specification is to communicate what an agency desires. So a vendor can respond to the PRL, but it is the users telling vendors what the user really wants. Right? That's the way we need to strengthen understanding. A is an incorrect answer because the statement is true. Architectural needs are provided by the standard. Answer B is also incorrect because the statement is correct. ESS manager selects mandatory ESS Manager features only. Third is selecting YES project-specific features. That's incorrect, because PRL must select YES optional user needs. So that's the whole idea about the conformance column in the PRL.

Raman Patel: Our last learning objective is to discuss how to prepare project-level PRL for ESS specification.

Raman Patel: So let's go over some of the key elements of what should be in the specification.

Raman Patel: First, let's briefly just gather some understanding that ESS actually gathers weather data and it sends it to the central system management station for further processing. So ESS actually gathers weather data. Second, central management station monitors ESS as part of the RWIS. So RWIS is umbrella system. It's the larger element in the overall capability that exists at the traffic management center. Third, ESS specification begins with identifying user needs and specifying requirements. That's where we want to start. We want to start with identifying user needs.

Raman Patel: So procurement specifications generally have hardware specification. Hardware specification entails to functional requirements, performance requirements, structural requirements, size, shape, mechanical requirements, fan components, electrical requirements including power-- all those different things-- voltage, current. Environmental requirements includes maybe temperature, humidity and all of the different things, including other environmental-related issues. So collectively, hardware specification provides that kind of detailed information from the owner's standpoint for the procurement process. Second is also software specification. There are functional requirements, performance requirements. Third is what we are discussing here in this module and the next one, is the communication interface specification. Right? We need user needs, we need functional requirements, we need project-level PRL, completed RTM, and also testing documentation. At the end of the day we will be also selecting how we will be testing the ESS. So all of these occur at a system development, testing, deployment, integration, operational, maintenance, and in general project-management level.

Raman Patel: So, let's look at the key points to remember while completing the project PRL. First, the PRL must be consistent with the hardware specification. So we said that hardware specification is separate, so whatever we say there must also match here in communication interface specification-- ranges, quantities, things like that. ESS specifications should have project-level PRL. PRL must be based on the version 1204 with SNMP interface. And finally, it must include need-based specific parameters. We don't want to make PRL or specification that says, "Give me everything you have," or "Give me all I can get." So we want to be staying away from this concept of getting everything in sight, and that's not helpful.

Raman Patel: So conformance and compliance issues. Conformance means a specific standard is met. How? To claim conformance to a standard 1204 v04, the vendor shall minimally satisfy the mandatory requirements selected YES. Everything "M" in the PRL must be conformed to. Vendor that provides additional features beyond the completed PRL are still conformant as long as they will conform to the requirements of the standard. So keep in mind that standard must conform at every level. And compliance means meeting specification requirements.

Raman Patel: So, filling in a PRL, or populating the PRL with user needs requirements. So, we will use the YES in the support to do that, right? So, monitor winds is a user need. So what do we say? We're going to select YES. So in the support column you have to find a place where YES/NO is listed, right? That you're looking at right now. So if you have selected yes in terms of your project needs, monitoring wind capability, then you have to identify the requirements related to that, and let's just do that.

Raman Patel: So, everything selected yes includes architectural need, generic features, and all that things, and if you look at it in the conformance column-- so you have M, M, M, M. Right? So everything is selected YES because M is selected-- M, M, M, M. So in other words, you are selecting or completing mandatory needs for conformity. So that's one. You are selecting YES for a project-level requirement. Now here you have a choice, yes or no. If it's optional and if you figure out and say your operational needs require you to have this capability, the user need, then you have to select YES. So that's what you will be doing in Support column. And as soon as you select Support column YES, all the associated requirements will also come by in a manner that is selected in that particular user need. So here, for example, we are showing Yes or No for permanent ESS station. There are three stations out there, ESS, in user need 2.5.1.5, permanent, transportable, and mobile, right? We don't really know. And you probably have one of the three, right? Or maybe two of the three. So you as the agency will examine whether it's required or not required. So, in this case, YES is selected for permanent. That means no for mobile and no for transportable. So these are the kind of user needs. So this will also remind you that you select what you need so you don't add additional cost for things that you don't need. And if you select something that you don't need, it will add cost-- not only just the cost, but also as complexity. So all those different things tell us that we better do a good job in terms of selecting YES/NO in a support column.

Raman Patel: Addressing generic architecture. These are the basic things. These are the basic communication required. We always have to select them, right? So that's what this thing means. So they're already selected YES. Select NO if not needed. Not everything is needed. A compressed data scheme may not be necessary if you have a wide bandwidth, right? And most agencies today, after 20 years or so of investing in high-speed networks, bandwidth, there's probably no need to compress data. It's okay to have every two seconds data coming in from the field to the central location, and that's how you can look at this as YES/NO, as good or not. So, offline data capability. Yes. You should always probably select YES, because sometimes when you lose the communication, you want to be able to restore it through the log data process.

Raman Patel: Version 1204, compatability to v03, v02 and v01 is near complete. If you really need the support for these past versions, old versions, then you have to use PRL and actually indicate that you are actually looking for information related to-- support related to a previous version. So v04 is updated with the view that it has to be compatible to the previous version. Other point about this thing is that some of the newer sensor technologies that we have in v04 and then technology is changing, so these kind of sensors, devices, are also not done in old versions but there are newer versions out there, so they will be also a point to remember. Some headings are changed in the tables, PRL. These are minor issues not to be concerned with too much.

Raman Patel: Our activity here then is to answer this question: Which of the following is a false statement related to ESS specification? Answer A, ESS specification includes a PRL; B, conformance requires only meeting mandatory user needs; C, compliance requires only mandatory user needs; and D, vendor must use project PRL.

Raman Patel: The correct answer is C. The statement is false. Vendor must meet mandatory and select optional user needs for compliance to the specification. Answer A is incorrect because the statement is true. Agency specification must include PRL. Answer B is also incorrect because statement is true-- conformance requires only mandatory user needs. Answer D is also incorrect because the statement is true. Vendor must use agency PRL.

Raman Patel: So, summarizing the module, what we have discussed today: Review the structure of the standard, discussed where the information is, sections, PRL, RTM, all those different things in the NTCIP 1204 v04. Identifying specific ESS operational needs, why agency use data, weather data, and how it's being used, those kind of things used for RWIS. We also learned how to use PRL to select user needs and associated requirements. We also discussed what to do in the specification, key issues, and prepare the good specification based on the PRL.

Raman Patel: And we have completed A313a module today, Understanding User Needs.

Raman Patel: The next module will be A313b, specifying requirements for v04 ESS standard. So in that module, you review the structure briefly; user the PRL and RTM to specify standardized structure of requirements; use the RTMs-- the RTM stands for Requirements Traceability Matrix-- to specify standardized design; also how to specify requirements not covered by the standard; and finally, infer the relationship between certain selected requirements and testing. That's what you will be learning in the next module.

Raman Patel: So we thank you for completing this module, and we appreciate your feedback providing us, at the end of the training, and again, thanks.