Module 15 - A313b

A313b: Specifying Requirements for ESS Systems Based on NTCIP 1204 Standard v04

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.

Ken Leonard: I’m Ken Leonard, the Director of the U.S. Department of Transportation’s Intelligent Transportation Systems Joint Program Office. Welcome to our ITS Standards Training Program. We’re pleased to be working with our partner, the Institute of Transportation Engineers, to deliver this approach to training that combines web-based modules with instructor interaction to bring the latest in ITS learning to busy professionals like yourself. This combined approach allows interested professionals to schedule training at your convenience without the need to travel. After you complete this training, we hope you’ll tell your colleagues and customers about the latest ITS standards and encourage them to take advantage of these training modules, as well as archived webinars. ITS Standards training is one of the first offerings of our updated Professional Capacity Training Program. Through the PCB Program, we prepare professionals to adopt proven and emerging ITS technologies that will make surface transportation safer, smarter, and greener. You can find information on additional modules and training programs on our website at ITS PCB Home. Please help us make even more improvements to our training modules through the evaluation process. We will look forward to hearing your comments, and thank you again for participating, and we hope you find this module helpful.

Raman Patel: This is Module A313b—Specifying Requirements for ESS Systems Based on NTCIP 1204 Standard v04. ESS stands for Environmental Sensor Stations. This module has been updated to reflect v04, and also the field practices that relate to the ESS. Some new user needs have also been identified—such as connected vehicles, Clarus, Iteris, and other efforts in the country. This module collectively reflects all the current practices in terms of how agencies use ESS systems, as well as the standard—which has been updated to v04.

Raman Patel: I am Raman Patel. I was formerly at New York City’s DOT as Chief of Systems Engineering. I worked there about 25 years. Currently, I teach ITS and Urban Infrastructure and Systems Engineering at New York University’s Tandon School of Engineering. I’m also been involved in the ITS standards-making process over the last two decades or so. This module has been of particular interest to me since we have been working on it for a while. V04 reflects all the collective changes.

Raman Patel: There are five learning objectives for this module. The first one is to review the structure of the standard and discuss the information available. Learning Objective 2 will deal with the Protocol Requirement List (PRL) and the Requirements to Traceability Matrix (RTM). Both of them are used in specifying requirements. Learning Objective 3 is to understand how to use the RTM to specify standardized design. Learning Objective 4 is about how to deal with the requirements which are not covered by the standard. And the last one is to infer the relationship between selecting requirements and testing. So collectively, these five learning objectives will provide us the skill, knowledge, and information necessary to prepare a good set of requirements for ESS.

Raman Patel: What’s in the standard?

Raman Patel: The standard has a relationship to this NTCIP family. You have probably seen this stack before. At the top, you have the environmental sensors data objects, which are the vocabularies and words necessary to create a message. They are at the Information Level. At the lower levels, we have protocols and rule sets available to exchange data from the Central Management Station to the field devices.

Raman Patel: The structure has several sections. Section 1 has general information. Section 2 contains concept of operations or user needs and features. Section 3 has the functional requirements. Section 3.3 has a PRL. Section 4 has dialogs. Section 5 has object definitions, or MIB—Management Information Base. Collectively, we get this information—such as user needs, functional requirements, PRL, standardized dialogs, and object definition. We need this information to put in our specification. If we are specification writers, these are the sections that will help you to collect the necessary information.

Raman Patel: There are several annexes: Annex A has the RTM; Annex B has an object tree; Annex C has test procedures; Annex D has revisions that we made up to v04; Annex E has some user requests; Annex F has generic clauses—these are specialized clauses for table types of dialogs; Annex G has some sample block objects which are not necessarily important to us in this module discussion today; Annex H has the necessary configuration objects. Annex A and Annex C are actually very important to us in today’s discussion because the RTM and test procedures are related to requirements.

Raman Patel: What has changed in v04 compared to the previous v03? Primarily, changes are now occurring at the multiple sensors level. For example, we have different types of sensor readings. Now we can use infrared technologies to help collect the data from various sensors and then report it in one single device format. That’s a major change. Also, certain metadata have been changed—metadata is the data about other data. We have included a test procedure in Annex C. That’s also a major change in v04.

Raman Patel: In addition, what we have learned has been reflected in practices that have occurred over the past several years. All the lessons that we have learned also have been reflected in 1204. We also have identified certain newer user needs—such as connected vehicles and other corridor type of projects. V04 is backwards-compatible to v03, v02, and v01. Both the PRL and RTM tables have some newer headings. Not many, but they still should be referred to between the various versions.

Raman Patel: What is a requirement? The INCOSE Systems Engineering Handbook provides this definition of what a requirement is. It allows us to say that a requirement is actually an unambiguous statement. It’s clear, consistent, unique, and standalone. It also is verifiable, and it’s a necessity that reflects in this statement from the stakeholders’ point of view.

Raman Patel: If you look very closely at what the standard is providing us in how to define requirements, the requirements are directly derived from the user needs. They are also defined in terms of the features, property, and behavior of the ESS systems. It’s a little closer to the user needs we see in the real world.

Raman Patel: The examples here show how this agency effectively mitigates the impacts of weather impacts on traffic operations. There are at least two aspects that we need to review in terms of requirements. One is that agencies routinely close roadways and bridges. For example, if they are under a weather threat in terms of safety and other aspects. The second point here is that once we have the weather data and information about the condition in real-time, the information is passed on to the traveling public. In the dissemination process, as you can see here in the lower dynamic message sign message, it says, “Hurricane Warning. Seek Shelter.” That kind of information is very important when there are conditions that are affecting safety, such as flooding conditions and hurricanes and tornadoes.

Raman Patel: This is an example from Florida DOT’s best practice about wind alert systems. Florida DOT has deployed a high-wind alert system for road and bridge structures. The purpose of this system is to assist agencies in collecting real-time data. For example, wind-speed status during severe weather events, in particular. That information is then used by the managers to make appropriate decisions and to assist the traveling public, as shown in this example of closing bridges.

Raman Patel: Retrieving wind data is probably one of the most important and routinely-used requirements in ESS systems. It allows us to collect wind speed and the average time interval—10-, 15-minute intervals. It also provides the direction of the wind and of course the speed of the wind itself. Such data can be retrieved from a Central Management Station from a device in the field.

Raman Patel: What do we monitor? We monitor weather condition in real-time to get data that we need. We can retrieve weather data such as air temperature, humidity, wind gust, direction, visibility, and all of the things that are important in making decision. Such information is also used in a seasonal way. For example, winter weather response—trying to mitigate efforts to make the roads clearer or snow removal programs, as you can see here in this diagram on the right. Such types of requirements will create a standardized way of collecting data from various devices from the field—the standard supports that.

Raman Patel: Where do we find these requirements in the standard itself? Section 3 has all the functional requirements listed here. For example, the Architecture Requirements—which are the common and basic communication types of requirements. You have Section 3.5—which is about Data Exchange and Operational Environment Requirements, and they’re further broken down in several places. For example, you can see here ESS Manager Requirements, Sensor Manager Requirements, PTS—Pavement Treatment System Manager Requirements—and certain conditions for Backward Compatibility Requirements. Section 3.6 in particular lists non-communications types of requirements that don’t belong to either the architecture or the data exchange requirements. This supplemental requirement actually has several components—such as atmospheric pressure sensors, wind sensor, and temperature sensors. The range of sensors is listed as the Supplemental Requirements.

Raman Patel: In Annex A we have the RTM, which is the crux of our discussion today in this module. The RTM has requirements related to different types of requirements that we just discussed. This table is very useful to us in preparing our standardized elements. The RTM leads us through the design of the ESS system.

Raman Patel: Several parts of the RTM must be discussed. Columns in the RTM are fixed—they have a particular setup that we must follow. The first column is Functional Requirement ID—Identification—and this is carried out from the PRL table. It’s the same requirement you have seen in the PRL that now comes right back to the RTM as the first column. The second column is the Functional Requirement title, followed by Dialog ID, then Object ID, then Object Name. The final column is Additional Specifications. These columns are fixed. Then underneath the columns you have rows for each requirement for entry. When we see these requirements listed one after another, they also carry with them particular or allocated dialogs—there’s one here in G.1. You then have the related or allocated objects that you can see in 5.2.1, 5.2.2, 5.3.1, and so on—with their titles. The RTM is a very organized table that we have seen before. It provides us with consistency for each requirement and related object definitions—including the dialogs. Dialogs are listed in Appendix G as G.1, G.2, and G.3. G stands for generic. They’re applicable to multiple type of devices in the NTCIP family. Object names and locations are derived from the MIB in the Section standard.

Raman Patel: There are several parts of the RTM. One here is shown as an example of what a G.1 dialog looks like. G.1 is a generic SNMP. SNMP stands for Simple Network Management Protocol. This is a Get Interface. The generic dialog allows us to communicate to the remote processor unit—RPU—in the field, which is part of the ESS system. G.1 is a conversation that we have with the RPU. In there, the messages are going back and forth between the Management Station and the RPU in the field.

Raman Patel: 3.5.1.1.1 is the Retrieve ESS Characteristics Requirement. We’ll rely on the example of G.1 and see how RTM actually connects us in retrieving ESS data. This example says that there are three types of ESS devices out there in the field. Fixed means they are permanently located either on the bridge structure or the highway; portable means they can be moved from one location to another; and transportable means there are also different devices that can be actually moved from location to location. Each one of them has a specific purpose. A Fixed ESS continuously provides the data in real-time; Portable provides the data while in transit as well; transportable is the only one that provides data when you get to the different location. There are various purposes for that. How do we identify and how do we retrieve data and characteristics about these particular stations? That’s what this requirement is about. Retrieving ESS characteristics using the G.1 dialog and related objects are listed here in this table.

Raman Patel: What are the benefits of RTM? RTM actually provides us with order for interoperability. It also acts as a conformance tool. What does that mean to us? In the real world, we have so many different things that we have to do in order to get a particular set of data from the ESS devices. RTM now provides us a method to get the information we are looking for—but this has to be done in an orderly manner-like sequence. Sequence of dialogs is very important. That’s what the RTM provides us. The RTM is a tool. We have seen this in many ways—it helps us think how do we conform to the standard. Anyone who is interested in conforming to the standard will benefit from using the RTM. It also reduces the design work. Why? Because the standardized design for each requirement is already done by the standard, so we don’t have to do this again and again and again. That kind of process is already done by the RTM. In addition to that, when we go through this design process, it provides unambiguous definitions and dialogs—we have that available to us. As shown here in this diagram, for example, you start with the standardized requirements. Then you collect the dialogs listed in the table—which are generic. You then have standardized design objects that relate to that particular requirement. This creates a common understanding among all the parties involved in producing ESS systems. For example, you have agencies, then you have developers, then you have vendors. All these parties have a common understanding of what the requirements are about and what they will do to get the ESS system that is desired. This removes all the ambiguities and it brings everybody to a common understanding. Sometimes we say that we are on the same wavelength—meaning that everyone understands what is expected from the procurement. That’s the part that’s played by the RTM in a big way.

Raman Patel: That brings us to our first activity.

Raman Patel: Which of the following is a false statement? A) ESS requirements are standardized by the standard; B) RTM provides benefits to vendors only; C) RTM provides standardized design; and D) NTCIP 1204 v04 is backward-compatible to previous versions.

Raman Patel: The correct answer is B: RTM provides benefits to vendors only. This is a false statement. The RTM creates a common understanding, as we just discussed, among all concerned parties—agencies, developers, and vendors. Everybody’s on the same wavelength. They understand each other’s needs and see what the procurement is about. Answer A is a true statement. All ESS requirements are developed by the standard. Answer C is also a true statement. The RTM actually provides a single standardized design for each requirement. Answer D is also a true statement, because v04 is fully compatible to older versions—03, 02, and 01.

Raman Patel: Our second learning objective is to understand how to use the PRL and the RTM to specify requirements.

Raman Patel: By using the PRL and the RTM in specific projects, the agency can actually state what is expected from the procurement.

Raman Patel: There are two terminologies that we must review for interoperability. What does that mean? Interoperability is the ability of two or more systems or components to exchange information and use that information exchange for some other purpose—such as improving winter weather management. That’s the meaning of interoperability in terms of how we benefit operationally. Off-the-shelf interoperability is enabled by the standard and is obtained by well documenting user needs with the corresponding requirements and design. What does that mean? Because the standard has done all the work for us—the user needs are standardized, the requirements are standardized, the single design for each requirement is also standardized, and the dialogs are also made available generically—they can be used for different devices. If everyone uses the information provided by the standard and then goes about their procurement, they can achieve off-the-shelf interoperability provided by the standard. The role of the standard is pretty good. We have to understand this in the context of ESS because ESS is the type of system where we have so many sensors—temperature, precipitation, wind. Many, many different sensors are involved at the basic data collection level. Then you have the RWIS—Roadway Weather Information System—that also has data management, data synthesis, and other things. Operationally, you also have to deal with the RWIS. Then, in general, you have ITS itself, which has many, many applications—ATMS, ATIS, and all those other things. Collectively speaking, it’s very important for us to get all the things working together. Off-the-shelf interoperability for ESS actually relates to these three or four different levels.

Raman Patel: What we must do to achieve interoperability? There are two basic conditions that we must fulfill. The first is that we must select the same user needs and requirements provided by the PRL. In the PRL you have mandatory user needs. Mandatory user needs and their associated requirements must be selected. That’s an absolute necessity. Second, optional user needs and associated requirements must also be selected by agencies looking for interoperability. That’s the first condition. The second one is that we must select the same standardized dialogs and objects—sometimes, we refer to it as a single design—provided by the RTM. At one level, we deal with the PRL; at the second level, we deal with the RTM. Collectively, to achieve interoperability, we must use the PRL and we must use the RTM at the project levels.

Raman Patel: Using PRL to Specify. What do you want this interface to do? The first thing we do is to map our project’s operational needs, such as the ones we’ve seen before—like a hurricane condition or flooding condition. We map those operational needs of what the operation requires to the user needs provided by the standard. In this table, for example, the PRL allows us to select all those operational needs that we have and map them so we can see what the operation requires and which user needs are available to support their operational needs in the standards. For example, in this lower table here, we say 2.5.1.5. This is a user need. It says we need to identify what type of ESS we actually want to deal with. It says Mandatory for conformance in the Conformance column. If you select “Yes” for the Support, for every M—Mandatory—we must select “Yes.” The standard has made it mandatory for you to select whatever the standard has identified as M—Mandatory. If you look underneath, you have Permanent Station, Transportable, and Mobile. For example, what are our needs? Some agencies may need all three of them. Some agencies may only have one permanent ESS—perhaps on a bridge or highway structures. In that case, there are certain requirements that will show up that we have to select “Yes” by selecting the user needs here. For example, the PRL will provide us the ability to reflect what our operational needs are. What needs to be done is going to be answered through this part of the PRL. 2.4—Architectural Needs—are very basic. They are the communication type of user needs that we must select “Yes” for the Support. In the PRL, we have M, M, M at the top, as you see here. They must be selected “Yes.” We are answering the question what needs to be done by selecting mandatory and optional user needs.

Raman Patel: How is this done? Again, we are using the PRL to specify what we want our interface to do.

Raman Patel: In that sense, we have to look for mandatory user needs for conformance and select optional user needs as the project requires it. Not every agency requires everything in the same manner as some other agencies. All agencies have to go through this analysis through the PRL and actually populate the PRL with whatever the project requires. Certain user needs are optional, but if they are selected by the agency, then all the requirements associated with the user needs become mandatory. As soon as you select “Yes,” then all the requirements attached to that user need are automatically made mandatory by the standard. In this example of the PRL, you can see in the Conformance column you have Optional. There’s a group of four user needs, and you have to select “Yes,” “No,” or “Not Applicable.” Underneath that you see 2.5.2.1.1—Monitor Atmospheric Pressure. It requires five requirements as a group, but a minimum of one must be selected. That allows the agency to choose whatever the project requires, and then move on with the mandatory requirements—O for optional and M for mandatory. The table is populated. That’s how an agency expresses what their needs and their requirements are. The PRL allows you to do all these different things, but we also should be very considerate in not ending up asking for everything. We should only ask for capabilities that we need. The PRL is not a nice-to-have list. That’s what we want to say here. We want to make sure that unnecessary user needs are not reflected in the PRL. Why? Because unnecessary user needs add costs. Cost is only one component—the other one is that it will actually hamper interoperability. Some agencies may have selected certain operational needs and therefore requirements—some may not. This mismatch among agencies or applications may not be conducive to achieving interoperability. This is one of the reasons why we emphasize in all Professional Capacity Building (PCB) modules to only select what the agency’s operational needs are, and therefore the PRL doesn’t become populated when you say, “Give me everything that you have.” That message is avoided by populating the PRL very, very carefully.

Raman Patel: ESS Requirement Categories. Architecture requirements are basic communications in Section 3.4. Section 3.5 has data exchange and operational requirements. Section 3.6 has supplemental requirements, which list only non-communication requirements, which are not covered by 3.4 and 3.5. Supplemental requirements, for example, has a range of sensors—in this example, atmospheric sensor, wind sensor, temperature sensor. There are several other types of sensors in 3.6. There are actually 24 additional supplemental requirements the standard provides us.

Raman Patel: 3.4 is Architectural Aspects of Various Requirements. For example, we have three types of requirements stated here in this diagram. We want to communicate to the Remote Processing Unit field device—called RPU—on the right, and the Management Station on the left. The communication between the Management Station to the RPU field device takes place in three different ways—when the connection is live, when the connection is active, when you provide live data in real-time. The Management Station will try to retrieve data from the RPU and you have it. That’s one way to get the system working—operationally and functionally. Another requirement type is that sometimes we have multiple sets of data available that we don’t want to continuously send. For example, the bandwidth may be low, the network speed may be low—and you don’t want to clog it. In many ways we can think of compressing various types of data and then sending it at one shot. That’s the second capability that architectural requirements provide. The third one is that we may not have live connections all the time. When we have offline conditions; for example, we only dial-up when we need to. In that situation, when we have communication problems, we lose communication with the field devices. In the meantime, the devices have collected this data, so that data is available. When the connection is restored or made available to the field device, we can bring back the data available in the device. We can also clear the log and say, “I got the data. Now let me just clear it up so the next time it can be helpful to us.” These are the basic requirements relating to communicating with the device.

Raman Patel: There are certain requirements for data exchange and the operational environment. One shown here in 3.5 is the ESS Manager. The Environmental Sensor Station Manager has three different types of requirements. Configuration requirements, for example. We want to understand the location and about configuring and retrieving information about that particular station—Permanent Station, Transportable Station, Mobile Station. All of these characteristics and their location can be configured through this requirement. Monitoring requirements—for different sensor data we can retrieve from the device. Then mobile—when the location is moved and the ESS moves from one location to another, we can also retrieve the location, speed, direction; whether it’s northbound, southbound—all of those different things or particular capabilities. Particular is associated with the particular sensor—the direction of the wind. All of these details can be retrieved and communication can take place through this data exchange.

Raman Patel: Monitoring. Sometimes we need to monitor what the condition of the field devices is. As this example shows us, the cabinet is out there in the field and we want to know whether the door of the cabinet is open or closed, without having to send somebody into the field and say, “Go out there and check it out.” The Central Management Station can retrieve the current ESS door status. Is it closed or open? Such capabilities are provided through this requirement.

Raman Patel: Sensor Manager is a second component in the RPU. Sensor Managers collect the raw data from the sensors themselves. The sensors provide only one output. Whatever data they have to report, they report to the Sensor Manager. These sensors are configured for that purpose. For example, we have a camera out there—a device—and we want to get the snapshot—we want to configure the cameras. We also want to monitor the current status of the sprayers—for example, number of sprayer events out there in a truck spraying the salt during the deicing condition. We can monitor all these activities through this requirement. Then also sensor metadata—our basic data that’s available and collected. Metadata means data about the data.

Raman Patel: The third type of requirements belongs to the PTS, or Pavement Treatment System. They also have a similar situation with configuration, monitoring, and data retrieval. For example, when the sprayer is out there, we want to know how much is used at that particular time and the width of the spray—how wide the material is being dispersed. You can do this in real-time without having to go there and check it, or calling somebody and asking for it. This data is transmitted to the Central Station. The data retrieval process is similar. Maybe you want a manual or have operational needs that come up in a particular activation process—a specific time period, for example. All of these capabilities are built into this requirements set.

Raman Patel: Data Exchange and Operational Environment Requirements for Backward Capability. We are currently using v04, and you have previous versions—01, 02, and 03—where a number of stations have already been installed in the country. Is this v04 compatible? The quick answer is yes. During the process of populating the PRL by rows, this backward compatibility capability is built in. v04 is compatible with v01, v02, and v03. The way to do this is through the PRL. The PRL is actually a pathway to making sure that backward compatibility is achieved.

Raman Patel: Supplemental Requirements. There are several. They are neither communication nor the functional operational type. For example, number of temperature sensors—how many? Every agency has different needs. This requirement needs to be dealt with in terms of quantification—how many sensors of a particular type? The PRL allows us to provide that information from the standpoint of various sensor requirements. For example—the required number of temperature sensors. It may be 5, 10—but it’s not going to be 255. That’s the ultimate limit in the standard—and it begins with 1. If you say I want 10 temperature sensors that’s a good thing. But if you don’t say anything in the PRL, you will only get 1. The default value is 1. We have to deal with these aspects of what our needs and supplemental requirements are. All supplemental requirements are now met through the additional specification, which is the last column in the PRL. One by one, all the sensors are dealt with for quantification—how many particular sensors you really need in a procurement process.

Raman Patel: Our second activity.

Raman Patel: Which of the following is a false statement as applied to ESS? A) Remote Processing Unit (RPU) contains ESS Manager; B) Sensor Manager collects data supplied by each sensor; C) PRL allows users to select user needs and associated requirements; and D) Backwards compatibility is not addressed by the PRL.

Raman Patel: The correct answer is D. This is a false statement. Backward compatibility to v01, v02, and v03 is built into the PRL as optional. The user must select “Yes.” If you want support for backward capability, you must select that in a PRL. As per 3.5.4, the entries can be made in the PRL. Answer A is a true statement. The RPU does house the ESS Manager. It does house the Sensor Manager. It does have the PTS Manager in it. Answer B is also a true statement. The Sensor Manager manages metadata from all the sensors. And C is also a true statement because the PRL is the only method to select user needs and associated requirements. The PRL begins the whole process.

Raman Patel: Our third learning objective is to use the RTM to specify standardized design.

Raman Patel: How does the RTM help us to specify standardized design?

Raman Patel: When you look at the agency process in preparing specifications, there are several parts to this. The first one is hardware and software specifications. Hardware specifications are generally functional requirements, performance requirements, structural requirements, mechanical, electrical, environmental, temperature, humidity—all those physical constraints and physical ranges and everything else. Size, shape, and ranges for parameters are specified in hardware specifications. Software specifications also have functional requirements and performance requirements. The second component that we will discuss in this particular module is the communication interface specification. How do we actually communicate to the device from a central location to the field location? That requires certain user needs—which are standardized; functional requirements—which are standardized; also the project PRL and RTM—which the agency needs to prepare; and then testing documentation—which includes a test plan. Eventually, you are going to actually test the ESS system and make sure that we get what we were actually looking for. These four components make up the communication interface specification.

Raman Patel: We need to coordinate the communication interface specification with the hardware specification components. The example here shows that in the hardware specification we want to measure a temperature range between minus 22 degrees Fahrenheit to 150-plus Fahrenheit. We want to be consistent in the interface specification as well, because both have to be the same because the ranges are also in the PRL in the communication interface specification. This coordination between the hardware specification and the communication interface requirements must be consistent. Another example could be a camera. Some agencies may require a snapshot camera—they want to actually see the roadway conditions in the winter, for example. They may have camera requirements. If they are specified in the hardware specification, they must also be in the interface specification. That’s the coordination required. On the other hand, if you don’t have a camera in the hardware specification, it should not be in the communication interface requirement. Such examples tell us that coordination is a key issue between the hardware specification and the communication interface specification.

Raman Patel: How do we make sure of all these different things in the PRL and the RTM for traceability, conformance, and interoperability? These are the three key things that we have to keep in mind—user needs and requirements are connected through the PRL. That’s the basic step. Then you have requirements and design dialog—objects connected through the RTM. Both tools have a specific purpose. The PRL begins the process in identifying the user needs and traces it to the requirements. Then the RTM traces the requirements to the design process, which is a single design for each particular requirement. We want to conform to the standard—we need both the PRL and the RTM. We want to achieve interoperability—we need to have the PRL with the same requirements and user needs and the RTM with the same requirements, design objects, and dialogs. These are the kinds of conditions we have in front of us for the PRL and the RTM.

Raman Patel: There are certain aspects that we must review—certain steps towards preparing the communication interface specification. A completed PRL traces the user needs to requirements for the communication interface. Completed means all the rows must be populated as per the specific requirements of a particular project. That’s one thing. The PRL only deals with the information level data objects. If you have a particular application in the data, that’s what it provides. The PRL only provides user needs and the associated requirements that go with it. The third thing is that the underlying communication standards need to be specified. We mentioned SNMP—Simple Network Management Protocol. It has a rule set that we use to communicate from the central location to the field device. The SNMP must be specified. Then there are also lower-level protocols. You saw that in the NTCIP stack earlier. They must be specified—like transport, or the device level, communication interface level, or physical device level. All of those standards must be also specified. Then you have to reference the interface standards. They are more than interface standards and referred to in different ways—they must be specified. Then you have the specific version number. Right now you’re probably procuring using v04, so you should be saying v04 and using the issue data for a particular standard. Such detailed information is a necessity to ensure that the communication interface specification is complete.

Raman Patel: Performance Requirements. The ESS standard has not provided us with a set of specific performance requirements. For example, how many devices can there be on a channel and network? What is the time lag and latency? What is the polling rate—how often you have to talk to the device? All these things are left to the individual application at the integration level. The standard doesn’t deal with all those different things. For example, in this diagram we show a Management Station communicating with the RPU in the field. What happens on the network is not described, nor how it happens in terms of performance—how quickly, how often. That kind of treatment is not covered by this standard.

Raman Patel: The performance requirement is covered in terms of response mechanism from the field device—how quickly do you want the field device to respond? NTCIP 1103 v02 has a limit of 100 milliseconds receiving the last byte. That requirement is specified. However, if your agency has a different requirement for how many milliseconds response time you need, you have to deal with that in an additional specification column. The PRL has that capability for an agency to specify a different number. If you don’t specify anything, the default value is 100 milliseconds—that’s the takeaway from this discussion.

Raman Patel: Handling Additional Requirements in the PRL. There are supplemental requirements—there are 13 or so—which may require you to put additional notes in the last column, which is called Additional Specifications. There are certain things that have already been done by the standard to provide you with the default values. But there may be certain needs that you may have to consider based on agency conditions, constraints, and requirements—that kind of information can go into Additional Specifications. There are ways to handle additional requirements specific to your particular agency procurement using the Additional Specifications column, which is the last one in the PRL.

Raman Patel: Environmental Images. This example is shown here to understand that if an optional user need—O—is selected by the agency using the word “Yes” in the Support column, it will be incumbent upon the procurement to get all of the mandatory requirements. If you select an optional user need, all associated requirements will also become mandatory—that’s what the PRL allows us to consider. For example, 2.5.2.1.8 says View Environmental Image. That’s the user need. But underneath, you see a significant number of requirements are listed. Some of them are M, some of them are O—Optional. As soon as you select this environmental image as a “Yes” here, in that sense you are selecting all the Mandatory—M—requirements, plus whatever the agency specification is about—choosing through “Yes” with all the optional ones. For this example of an environmental image, you’ll be completing the requirement listing by selecting M and O as per your local project needs. This circle over M shown here is because we selected “Yes” in the Support column. In the Additional Specifications column, we look at this note saying, “The ESS shall support at least blank, 1 to 255.” The default is 1. How many snapshot cameras will a particular agency require in this procurement? That is left open—blank. You as the agency have to select how many. It’s 5—it’s not 255. That’s a very large number. If you don’t enter anything, you will only get a 1 camera capability. That’s the difference we need to understand—and to make sure that we enter the correct number.

Raman Patel: Let’s look at a case study here from Idaho DOT.

Raman Patel: The Statewide Weather Station Deployment. Here you have three different things shown—a snapshot. It’s an image of what the condition looks like out there in the winter. Then you have a map on the right, which is a large general region. You have ESS stations located in different parts of the region, so they are shown together. You have a third component here which provides the data for each different type of sensors. On the left side you have, for example, temperature sensor data—78 degrees Fahrenheit in the summer. This kind of information can be made available in winter conditions or in summer conditions. These three things come together in terms of how the ESS Station and the RWIS—Roadway Weather Information System—come together. This is common. The diagram pretty much reflects a common way of creating a RWIS for winter management and other times.

Raman Patel: How do we do that? How do we communicate to the field devices so we get the information we are looking for? This example uses the RTM with a specified dialog in 4.2.2. The diagram reflects how a conversation with the device is taking place from a central location. The central location is the RWIS and the field location is the RPU—Remote Processing Unit. There’s a conversation between these two ends, and the conversation is carried out through this standardized dialog called 4.2.2. This dialog is very orderly and is given to us, so it’s not missing anything. That’s the best part about the RTM—everything you need for order and sequence is laid out very, very cleverly by the standard. We as the users—you and I—don’t have to worry. If you’re an agency and if you’re a developer, both of us have this responsibility to make sure the dialog is carried out as in 4.2.2. To retrieve the snapshot, as shown here in the diagram on the right, you will see there is a camera at the top of the pole, and then at the bottom you have a snapshot image. This image is shown as one here, but it could be multiple images—one after the other. These images can also be stored. They can be removed. They can be also labeled. This timestamp shown here on this image could be any information you want. But the important thing is that the RTM has made sure that you need the dialog 4.2.2 and the conversation—the way it’s taking place is already shown here. This example tells us that dialogs are very helpful. They’re provided to you during the procurement process using the RTM. That’s the role of how to specify dialogs in the RTM.

Raman Patel: Furthermore, in terms of retrieving a snapshot there is a functional requirement to retrieve a snapshot. Dialog 4.2.2 is identified by the standard. The standard has identified and allocated two objects—5.17.1 and 5.17.2. These two dialogs relate to the discussion in the Additional Specification column. They allow us to bring the snapshot to the Central Management Station.

Raman Patel: This depicts the communication from a central station. The Management Station on the left is communicating with the RPU on the right. You have a snapshot of an actual real-time condition out there—how the sprayers are being used in the field. You see these three sprayers lined up one after another—their job is to spray specific material in the direction that they have chosen—the width and the direction and all those different things show up at the Central Management Station without having to send somebody out there, or talk to somebody on the phone, or something like that. These are the kinds of capabilities that the standard provides us—these are real-time actual usages in the field. We use such methodologies during winter management.

Raman Patel: Using the RTM requires you to understand that whatever the PRL has identified is coming to the RTM as well. In this example, we are talking about the PRL. The Manage Mobile Spray System is selected “Yes.” This standard has been made optional—O—but not every agency is looking for this particular capability. In that case, certain agencies that need it will select “Yes”—the rest of the other requirements underneath will be applicable. When you select “Yes” in the Support column, the remainder of the column is also selected Yes, Yes, Yes, Yes. First you select User Need as “Yes” in 2.5.3.2 here. Then all the associated requirements also show Yes, Yes, Yes, Yes. That’s how you secure—and in fact, make sure that your procurement will have the mobile spray system. This is a good example to show what the PRL can do for us.

Raman Patel: RTM entries specifically lead us from the requirement to the design. Our main focus for each requirement is what does the design look like? During the design process, you have two components. One is the dialog itself. It shows up here in the Dialog column: F.3.3.1, F.3.3.1 again, and then F.3.3.3 at the bottom. These are generic dialogs. Sometimes they are referred to as Table Dialogs in Annex F. They are there. When you try to procure, the dialogs are neatly organized in Annex F. These dialogs are then connected to the particular set of objects in the Object ID column next to it. These objects will actually allow you to manage the pavement treatment system. That’s how you complete your data retrieving capabilities using particular dialogs. ESS has this Annex F that has these dialogs that we are looking for.

Raman Patel: To summarize: Certain steps are necessary to achieve conformance to the standard. This is the central thought on everyone’s mind—”Am I conformant to the standard?” In fact, people probably are even worrying about it, and saying, “Did I miss something?” To make sure that we are not missing anything that impacts us achieving conformance to the standard, there are four basic conditions we must be aware of. First, we must secure user need support by selecting “Yes.” Yes in the PRL should not be left blank. We have to circle this and say, “Yes, I need this support,” and all mandatory requirements must be met. Wherever you see M, you must select “Yes.” That’s one. Second, the RTM identifies dialogs. When dialogs are properly done, they have a sequence, an order—there is nothing you or I can do about changing it. We should not make any attempt to even think of that. The dialogs are sequential—in order—therefore, they must be selected. That’s through the RTM. Third, the RTM also has identified objects. You and I as users, developers, and a combination of vendors—and anybody else for that matter—do not have any role. The RTM has made sure that all the objects you need to meet a particular requirement are lined up by standard. We have to select these. And then finally, both the PRL and the RTM are required for conformance to the standard. Many times we may think I have the PRL, or sometimes we may think that we have the RTM—we need either one of them, but maybe not both. So we are here making sure that both PRL and RTM are required at the project level to conform to the standard. These are the four steps we must take to conform to the standard. One more question we have to answer—all those implementations, all those agencies wanting to achieve interoperability—what must they do? What should they do at a minimum? We emphasize again and again that to achieve interoperability, you must use the same user needs, you must use the same requirements, you must use the same dialogs, and you must use the same objects—in the proper order. Those who want interoperability must also make sure that these conditions are met.

Raman Patel: Our question here is to answer: Which of the following is not a correct statement as applied to communications interface specification? A) Project PRL lists standardized user needs; B) Only PRL is necessary for conformance to standard; C) PRL lists optional user needs; and D) RTM provides complete design.

Raman Patel: The correct is B. It’s an incorrect statement. Both the PRL and the RTM are needed to ensure conformance to the standard. Answer A is a correct statement. The PRL actually does list ESS standardized user needs. C is also a correct statement because the PRL lists both optional and mandatory user needs. The specification must indicate support for optional needs. And answer D is a correct statement. The RTM provides dialogs and objects in order to complete a message to the ESS device.

Raman Patel: Our fourth learning objective is to understand how to specify requirements which are not covered by the standard.

Raman Patel: Sometimes you may have a need that may require certain procurement conditions and the standard doesn’t support that.

Raman Patel: Under those conditions, what must we be do so that we can meet that particular requirement? The context here is when do we extend a standard—and why? V04 has been developed based on previous experience, lessons learned, and many other current input that we have received. V04 pretty much reflects what additional features are necessary—including some of the new ones. However, there may be some feature—requirements specific to a certain application. They may not be covered yet or may be missing. In one example here an agency may have a need for monitoring overhead sensors at a tunnel entrance. Maybe there is a user need somewhere out there but the standard does not support that. This sensor is not included in one of those 13 or so types of supplemental requirements. What do you do in this case?

Raman Patel: We normally don’t encourage anyone to go out and do extensions—the standard does not encourage that. What are the conditions in case you have to extend a standard? At a minimum what should you do? Adding new objects to meet certain user needs—ESS MIB—is possible if it’s documented properly and it’s made available to anyone. “Anyone” means the agency—there may be other vendors and developers involved. If you are in procurement and the vendor allows this process to occur, this is a good starting point. It should be made available to all those who are affected by it—agencies, developers, and other implementations. The second point is that vendor-specific ESS design objects are based on the ASN.1 format. ASN stands for Abstract Syntax Notation. This is a standard that we use in constructing our NTCIP standards. It’s the format standard. If you have a proprietary object or design, it must be based on ASN.1 format and the MIB structure that’s prescribed by the standard. These conditions are basic. You have to adhere to these two conditions. The third point is to specify a dialog and private objects in an approved RTM manner. In other words, you must have a proper dialog to carry out the proprietary objects conversation. All the private objects must be in the RTM. You cannot say that the RTM does not have proprietary objects. These things are important for what should be done at a minimum.

Raman Patel: There are quite a few technical conditions. One of them is that when a new requirement associates a design object the behavior of the device may be affected. A proprietary object may make the device respond differently. That may be a surprise to you. It is a technical way of looking at things—whether or not it’s going to affect your operation or functionality. ASN.1—Abstract Syntax Notation-based objects—must support the Read operation. Read means we want to retrieve information. And we want a Write operation—meaning we want to control a device. These things are important for capabilities at a Central Management Station. The syntax must be a non-negative number. When you structure the data and messages, this important issue comes up. You then have to worry about Object ID. It has to be a unique ID given to a particular MIB node. That’s also a requirement. Only a Simple Network Management Protocol—SNMP—interface will be allowed. You cannot have a proprietary protocol from a vendor and say, “I’m going to use my own protocol. We’ve been using it internally so we’re going to give it to you.” That’s not going to work for an agency. All agencies are using an ESS procurement SNMP. NTCIP is based on SNMP, so 1204 v04 is not going to be able to work with a unique proprietary protocol. That’s the point that needs to be got across.

Raman Patel: There may be certain benefits—maybe we are still within the family of NTCIP. What if you have one or two proprietary objects? We may be able to deal with that kind of thing. Eventually you’re going to probably say, “I’m comfortable about it.” That’s one benefit that you might bring to the agency. The second thing is that ITS is evolving, expanding—however you look at it. We are modifying applications. We add different things. Lately, we are focusing on connected vehicles. It’s a new application—a new activity out there. Integrated Corridor Management—ICM—this is another effort. All of these things may bring back certain user needs that we’ve not covered before. They may identify certain things that we didn’t think about it when we prepared v04. Time may tell that story. However, they can probably say, “We’re going to expand this by region, and we need this, and the standard doesn’t support that.” Such conditions may occur. Who knows? They may possess a certain way of doing things, so therefore extending the standard could probably bring an additional benefit to the program.

Raman Patel: Drawbacks. There are several of them. Once you use a proprietary situation to manage a particular device, you will lose the ability of the Central Management Station to control. Other management stations—besides the proprietary one—may not be able to deal with this issue. Secondly, it will add cost. Each time you want to integrate certain things, it’s going to cost you, because it has to be done in a very proprietary manner. It will also require you to conduct tests—and we don’t know how to test the proprietary objects. There are additional constraints as well as requirements—expertise may even be required. Such things add costs. Vendor’s reluctance to share features with other implementations. Vendors may say, “This is my own thing. I’m not going to allow you to share this with other implementations.” That could pose a problem. You may have an issue with the bugs. Who knows? It could bring the bug to you, which you may not have anticipated—software and performance measures may be affected. In many ways, these situations are unknown. That may be an issue out there. Private objects also impact interoperability. You may not be able to swap the parts—for example, one sensor with another type of sensor. Such issues have an impact on the RWIS. The RWIS is considered to be a general application in many ways. If you put certain restrictions or proprietary objects in between, you may have one part of the system working and the other part not working in terms of interoperability. Such drawbacks should be identified and made aware of.

Raman Patel: Our activity is to identify.

Raman Patel: Which of the following is a correct statement related to ESS extension: A) Extension will be conformant to the ESS standard; B) Extension will break regional RWIS interoperability; C) ESS implementation with extensions is manageable; and D) Extension does not affect remote operation of ESS field devices.

Raman Patel: The correct answer is B, extension will break regional RWIS interoperability. This is a correct statement because extended design in one implementation will not be known to other deployments or versions—user needs and requirements may be different. This could cause a serious problem for regional RWIS interoperability. A is an incorrect statement. A testing process is needed to prove that an extended implementation conforms to the standard. The extension will be conformant to the standards. Testing is a major issue for extension. Answer C is an incorrect statement. The additional cost of integration, test procedures, and maintenance will not be in the best interest of the agencies. Every time you try to do something different, this will be a cost issue. Answer D is also an incorrect statement. Remote operations by management stations are affected by extended implementation and may result in a local operation only. You may not be able to control everything from one location because somewhere in between you have a proprietary solution.

Raman Patel: Our last learning objective is to infer the relationship between selecting requirements and testing.

Raman Patel: How do we make sure that the requirements and testing are connected?

Raman Patel: We have been discussing the SEP lifecycle process in several ways using this V diagram. We have always identified that the test planning stage is at the beginning. When we look at test documentation preparation in the high-level design or detailed design-level system requirement areas on the left side of the V diagram, and then on the right side, we are conducting tests. We want to verify and validate the system approach and development process—we’ll use these two criteria. One is testing for validation of user needs. At the end of the day, we want to make sure that all the user needs are met. Then testing for verification of requirements. As we are going through this process, we want to make sure that every requirement is verified and every requirement is met. These two levels of activity are carried out through the V diagram process. Test planning is done during the earliest stage—testing comes at the later stage.

Raman Patel: The relationship between requirements and testing is explained in Test Procedures in Annex C. Annex C has a large number of test procedures applicable to ESS. There is a table in there called the “Requirements to Test Case Traceability Table”—sometimes it’s also referred to as the Matrix. They both mean the same thing. This table allows each requirement to be connected to a test case—and the test case is a design. Then you have a set of procedures and processes, which will use the steps. That’s something you’re going to learn in detail in the next module called T313, Applying Your Test Plan to ESS. I defer that discussion to that module.

Raman Patel: Specifications should include test procedures. Annex C provides that. This is the format that the standard has made available. At the end of the test procedure, it leads you to say Pass or Fail. Has that particular requirement been met or not? That’s the criteria applied in assessing whether requirements are met. You will learn a lot more about these things in the Testing module. Here, we want to make sure we have the capability, I have the requirement, to see if the door is open or closed. I should be able to do that without having to send somebody remotely. That requirement is now tested through this test procedure—the same test procedure steps we are using to make sure this is the case, that we can do it. That’s what this example is telling us.

Raman Patel: Our last activity then is to answer.

Raman Patel: Which is not a correct statement as applied to ESS testing: A) Test procedures connect requirements to testing steps; B) NTCIP 1204 v04 standard provides test procedures; C) Test plan documentation includes test procedures; and D) Test planning is done at the testing stage.

Raman Patel: The correct answer is D. This is a false statement. It is because test planning occurs at the early stage of the user needs requirements setting—not at a later stage. At the later stage, we do the testing; in the early stage, we do the planning. Answer A is a true statement. Steps to testing are listed in test procedures. B is a true statement. Test procedures are provided by the standard in v04 in Annex C. And C is also a correct statement. It’s a true statement because the ESS test plan does include test procedures. In fact, it’s the last component in a test plan. Without test procedures, you cannot carry out the testing process. It’s very important to realize that.

Raman Patel: To summarize the module: We discussed and reviewed where the information is in the 1204 version standard. We also discussed how to use the PRL and RTM to specify requirements. We discussed using the RTM to specify standardized design. We also discussed what to do if certain requirements are not covered by the standard. And lastly, we talked about how to test each requirement and then we discussed the relationship between requirements and the testing process.

Raman Patel: We previously completed Module A313a—User Needs. Today in this module, we dealt with requirements related to ESS.

Raman Patel: In the next module, we’ll cover the testing of requirements related to ESS. There are four learning objectives in the next module. The first one is to describe within the context of the testing lifecycle the role of test plans and testing to be undertaken. Learning objective 2 will identify key elements of the1204 v04 standard relevant to the test plan. Learning objective 3 will describe the application of a good test plan for an ESS system being procured—so we can apply that. The last learning objective will describe the testing of an ESS using standard procedures. Some of this we discussed today. That next module will cover the complete process of preparing a test plan and how to go about testing.

Raman Patel: Thank you for taking this module, and we appreciate your feedback on your thoughts and any comments that you may have about this particular module and the training process. Thank you.