Module 1 - T101

T101: Using ITS Standards: An Overview

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.)

Shelley Row
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 Shelley Row, the 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 you.

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: ITS PCB Home.

Please help us make even more improvements to our training modules through the evaluation process. We look forward to hearing your comments. Thank you for participating and we hope you find this module helpful.

Announcer Nicola Tavares
This is the first module, I101, Using ITS Standards: An Overview. This introductory module provides an overview of ITS standards for practicing transportation professionals, public sector managers, and decision makers who are engaged in the deployment of ITS. This module will highlight the program and organizational benefits and costs of the adaptation and use of ITS standards to support the deployment of interoperable systems. And there are no pre-requisites for this module.

Your instructor is Dr. Gary B. Thomas, Center Director of Texas Transportation Institute.

Gary Thomas
As Nicola said, I am Gary Thomas, I'm with the Texas Transportation Institute. I've already put up one chat question in the chat box. I kind of wanted to know what you hope to get out of this particular webinar. And if you just want to chat in some short answers while I just talk a little bit more about my background and why I'm teaching this particular webinar that would be great.

I have been involved in the standards programs for probably maybe eight years or so as far as a standards training program goes. I've taught a number of live, in-person seminars that we've done for, again, teamed up with ITE and Federal Highway Administration. I've taught introduction to ITS Standards webinar for quite a few years. As we moved into this more online version, I'm again very happy and privileged to be able to put together this particular webinar and present it as well.

I'm with the Texas Transportation Institute in College Station, Texas at Texas A&M University and I've been here for almost 10 years. Next month it will be 10 years. And, again, I'm very pleased. Happy that you're with us today. So good morning or good afternoon depending on where you are. It may even be—you may even be in some other part of the world for all I know. I can't tell from the list. I see a few familiar names on the list of attendees. So, again, welcome and we will go ahead and get started.

Nicola had mentioned that this is just one of many webinars in a series and I'm gonna talk about two different curriculum paths that we've designed for these particular webinars and how you would determine which one, which path you want to go down. So there are really two possible paths a user can follow in implementing a system based on ITS standards. The path to be taken really depends on the standards needs that—to implement the system itself. Now I'm gonna go into a little greater detail on some of these definitions as we move along.

The identified standard could have been developed using a Systems Engineering Process, an SEP, we'll sometimes abbreviate it. Of well-defined needs, requirements, and designs or you may have developed it without a Systems Engineering Process. The Systems Engineering Process I will, as I mentioned we'll go into greater details later on in this webinar but for now know that SEP is basically an interdisciplinary approach and means to enable the realization of successful systems. That's your textbook definition of SEP.

It really focuses on defining customer needs and required functionality early in the development cycle, documenting the requirements, and then proceeding with design synthesis and system validation. So, again, the user should follow the SEP curriculum path to understand how to implement a system if the standard itself is SEP-based.

On the other hand, if you are not using standards that have been developed using the SEP process you would follow this particular path. And it's just a little bit different. It adds some additional information on introduction to ITS standards requirements development and A203 writing requirements when ITS standards do not have SEP content. So just some additional steps that you would need to go to if you are using this particular curriculum path along with your systems process, design process.

Well today I've got some very specific learning objectives that we are gonna go through. I haven't seen anybody chat in yet on what they hope to get out of this webinar so hopefully this will align with your expectations. First, by the end of this webinar you will be able to, one, identify the benefits and costs of using standards in ITS projects. Two, describe the benefits of using the systems-engineering process in ITS project. Three, identify and address high-level, technical, and institutional challenges to using standards. And finally number four; describe the role of ITS standards in ITS applications.

I mentioned that I've been involved in the—this outreach of standards for about eight years or so. Prior to that, I was a city traffic engineer and implementing a signal system about the time I was leaving. And we first started talking about standards back in those days. That was about the late '90s when we first starting to hear about standards.

Now what are these standards? Well, a technical standard, and again this is not necessarily having anything to do with traffic or transportation engineering. It's an established norm or requirement about technical systems. It is usually a formal document that establishes uniform engineering or technical criteria, methods, processes, and practices.

Most standards are voluntary—excuse me, consensus-based, and open. What do I mean by this? Well voluntary, exactly as it sounds meaning their use is not mandated by any particular law or requirement. They are consensus-based meaning that a published standard has attained general agreement through cooperation and compromise in a process that is inclusive of all interested parties. And finally, standards are open meaning that they are not proprietary and are available for anyone to use.

So that's our basic working definition of standards. I'm gonna ask you here to chat in in a second so get your keyboards ready, your fingers on your keyboard. And what I would like to know is what do you see as possible benefits of using standards? And in this particular context I'm not necessarily talking about ITS traffic standards. But we all use standards every day in our lives from the moment we wake up there are some standards that we're using whether we know it or not until the moment we go to sleep.

So if you could quickly chat in just a few things that you see as possible benefits of standards and we'll just kind of look at them as they come in. Hopefully you all aren't gonna be too shy out there. All right. Here we go in getting us kicked off. [Reads] "Ease of maintenance." Yeah. That's a very good benefit. "Cheaper deployments." Yes. "Interoperability of deployments." And we'll get into a little bit more detail on that. That's an excellent benefit. Another one says, "supports competitive bidding." Yes. That's another good benefit of using standards.

All right. Feel free to chat in a few more as I go on to the next couple of slides if you've got some more benefits you see in using standards. "It makes testing easier." Absolutely. That's another benefit. All these we will go into here shortly. What about now in particular ITS standards? That's what we're here to talk about. So we defined in general what standards are back on slide number eight, but what are ITS standards?

Well ITS standards define how ITS systems, product, and components can interact usually referring to physical connections, junctions, and media between field devices or perhaps between a center and field devices. They also exchange information, which is the data itself. And finally they are—they allow it to interact. And this would be more from the center-to-center type of transaction. And they do all of these things to deliver services within a transportation network. ITS standards are open, interfaced standards that establish communication rules for ITS devices can perform, how they connect, and how they can exchange data in order to interoperate.

Now at this point it's important to note that ITS standards are not design standards. They do not specify specific products or designs to use. Instead the use of standards gives transportation agencies confidence that components from different manufacturers will work together without removing the incentive for designers and manufacturers to compete and provide products that are more efficient or offer more features. And this is one of the things that I think back on when I first heard about standards back in the late '90s. I had initially had this concern, "Well if everything was standard, how do we differentiate between vendors?"

If everybody has to build a controller—for one example, a traffic signal controller—if everybody provides the same vanilla traffic controller what is the point of standards then and does that really benefit us? Well it does. These are—here's a bigger list of benefits and you'll see some of the ones that you chatted in will—are mentioned along this list. I'm not gonna go over each one on this particular slide but instead the next series of slides we'll go over each of these benefits individually.

So let's look at the first one about supporting interoperability. The ability of different ITS devices and components to exchange and interpret data directly through a common communications interface and to use the exchange data to operate together effectively is called interoperability. And this is a big key word that we use in our systems these days. Interoperability is key to achieving the full potential of ITS.

Seamless data exchange would allow, for example, an emergency vehicle to notify a traffic management center, perhaps trigger a change in the timing of the traffic signals on the path to a hospital in order to assist the responding ambulance. Just one example of an ITS standards and interoperability.

So it's defined as the ability of ITS systems to provide information and services to other systems and use exchanged information and services to operate together effectively. So let's take a step back here and I'm gonna build on an analogy here for the next several slides in looking back at a—how a home theater system works. I'm a tech kind of guy. I like my home theater system that I have. And so if we think about how that works, hopefully you kind of understand the basics of how theater systems work or audio-visual systems in general.

You can purchase any equipment from numerous vendors with the knowledge that the separate components will talk, if you will, to each other because they conform to communications standards. And I think of RCA cables and more—and S-video coax and more recently HDMI. So I've got kind of the picture there of the back side of my television and you can see a number of different cables in there. One HDMI. That's your high-definition interface. And then there's a number of other cables that you see there. And I've actually got some blank coaxial cables there.

So, you know, this is how these systems work. They're interoperability in that they can work with different components. The idea being that is with audio-visual standards, which have been around for decades, if you are, for example, old enough to have hooked up a record turntable up to this system—of which I count myself and I still have a turntable on my systems or perhaps even a reel-to-reel tape. Those were devices you hooked up previously.

And now today you hook up a CD player or perhaps an iPod, an MP3 player generically. And ten years from now you're gonna hook up something new. I don't what that's gonna be but I'm pretty confident we'll have some other future device that'll hook up something new. And because we use audio standards we're pretty confident that that future device if it wants to have any hope of taking off and excelling it's going to have to conform to audio standards. I hope we're not getting too much of a background noise. They have chosen this afternoon to mow the lawn outside my office so I apologize if I'm getting any background noise.

So have new standards been developed? Again, sticking with the audio visual, yes they have. Some examples? USB. We see that on our computers now. But the old ones, at least for an audio-visual system, RCA plugs, they still work. They're still there because those standards have been developed for so long. Now, are they the best standard out there? Possibly not. Whereas a television you might have hooked up using RCA cables, today you're probably going to use an HDMI cable.

Now when we talk about ITS standards there's several categories that they could fall under. Two of the most developed categories in ITS standards are center-to-center and center-to-field. So in our analogy here think of the amplifier and perhaps the receiver as being centers and the turntable, CD player, MP3 player, etc., those are field devices. Other categories of ITS standards may include vehicle-to-vehicle, which we're not gonna address very much today if at all and vehicle-to-infrastructure. And I'm not gonna draw any analogies to those with our—with the audio-visual standards here 'cause it doesn't quite work as well.

Let's move on to another benefit, that it supports Rule 940 compliance. Now the USDOT recognized the potential benefits of the systems engineering approach for ITS projects and included requirements for a systems engineering analysis in what is known as the FHWA rule or FTA policy that was enacted on January 8, 2001. The rule, the FHWA rule, FTA policy requires a systems engineering analysis to be performed for ITS projects that use funds from the highway trust fund including the mass transit account.

The rule policy actually specifies seven requirements that the systems engineering analysis must include at minimum. And I'll talk more about what is meant by systems engineering analysis in an upcoming slide. I'm also not going to go into all seven requirements. You'll find them as part of a student supplement of this particular webinar and so, again, I'm not going to go into detail on those. But what I will point out here is that number six of these seven requirements on the list specifically mentions the identification of applicable ITS standards and testing procedures.

Another benefit is that it minimizes future integration costs and I think somebody had mentioned something about cheaper deployments. By using standards, agencies are not locked into proprietary systems like we were certainly back '70s, '80s, and '90s. We typically purchased maybe an off-the-shelf system or we hired a specific contractor and they custom built an application or a system for us to run our systems. As the system needs to be expanded, standards will make this easier.

Again, let's look back at my home theater analogy that I've been talking about. Now, perhaps you don't have a Blu-Ray player right now. I don't. But I'm probably thinking about purchasing one in the next year and since they use standards, I can make a purchase confident that it'll fit into my system. And further, I'm not necessarily locked into any particular brand. Just because I have said, for example, a Sony television, I don't have to purchase a Blu-Ray player made by Sony. Similarly, if in the past I have purchased controllers from one vendor if I expand—if I plan to expand my system to include say dynamic message signs in the future, they don't have to be manufactured by the same company, which in this particular example is probably highly likely—unlikely anyway.

Another benefit is facilitating regional integration. By conforming to a regional architecture—we haven't talked too much about architecture yet that is standards based—agencies will be able to communicate with each other. Okay. It's back to my home theater analogy again. Home electronic systems have become networked with other systems in your household. Now with the proper connections your computer can talk, if you will, to your TV and your TV can communicate with the Internet.

You may even, like myself, use a mobile application on my smartphone or tablet to program your digital video recorder while you're at the beach or on vacation. "Oh, I was gonna record that program and I forgot to do it before I left." I can open up an application on my iPhone and send the command to my recorder to record it. Perhaps even more analogous is playing a video game, say for example on your whatever—Wii console perhaps with someone in another location. So I can, if somebody else has that same gaming system and you agree to hook up through the Internet, we can actually play a game against each other.

In our transportation world, this occurs when various agencies and jurisdictions can communicate with each other about say the status of the transportation network. Missed communication can be reduced when jurisdictions use the same standards. For example, when reporting an incident on a freeway, it would be very important to know whether it involved a bus, for example, say versus a car. A bus is likely going to require a higher level of medical personnel to respond. Now if one of your systems codes a bus as a number four, for example, in the database and another system, which is not using standards uses a four to define a motorcycle, that may likely cause a problem in sending the correct response team.

In coordination of field devices, traffic signals most notably, can be easier to achieve using standards. Take an example of two adjacent cities. One perhaps a very large metropolitan area and one very small where the larger city has a special weekend event that can perhaps be impacted by signal timing in the small city. The smaller city may not offer—monitor their traffic operations twenty-four seven but the larger city does perhaps. If they have a shared agreement and are using the same standards, the larger city could possibly make changes to the timing as needed in the smaller city.

And to just run down some of the other benefits, which I'm not going to go into as much detail here. You can support incremental measurable development by tying testing to intermediate milestones and allowing the agency to start using a system for the benefit of the public. Another benefit is preventing technical—technological obstacles by procuring devices that use standards that have already been thoroughly tested and proven.

I think of UL-listed devices. UL listing is an electrical communications standard if you will—an electrical standard. Almost anything you buy that plugs into the wall has probably been UL-listed, which means somebody else has already thoroughly tested and proven this device works with your standard power system that you have in your house. So, again, we don't have to worry about that as users.

It can also minimize operations and maintenance costs, which somebody else had brought up earlier by allowing jurisdictions to be able to have off-the-shelf equipment ready to install in case of device failure, which is defined as interchangeability. And you're not necessarily locked into any particular brand. Easily prepares for emerging technologies that will use the same standards. Again, thinking about your iPod connecting to the stereo system that you may have purchased 20 years ago.

It is easier to procure devices and that also was mentioned I think on there. Competitive bidding might be the closest to that. That are based—it's easier to procure devices that are based on standards because device manufacturers have a clear understanding of what the device must do. And also mentioned was testing. Testing is made easier by using standards-based devices because of the tools that are available to test standard conformance. And testing is covered in more detail in another training module, T101, Introduction to Standards-based Testing.

And finally, taking all of the discussed benefits this really leads to minimizing risks when implementing a standards-based system. And I think that's something that we all like to do when we implement large-scale projects as often times transportation projects are. All right. I'm gonna ask kind of the opposite of the earlier question where I was asking about benefits before. Now what I'd like to do is, again, if a few of you could chat in what do you think are potential costs of implementing a standards-based system? And you want to chat some quick answers in there while I pause for a moment. What do you think are potential costs of implementing a standards-based system, particularly if you don't have a standards-based system right now?

Hmm. A harder question than the benefits. All right. Here we go. [Reads] "Problems with interface with Legacy systems." Excellent. That's an example of a cost. A problem is another way of defining cost. Anyone else? All right. Well I don't want to delay so let's—we'll get into a little bit more of it here in a second. "Time." I see one chatted in there. "Time is a cost." Yeah. It's—if it's something you haven't done before, there's probably gonna be a learning curve associated with standards and that takes some time.

Well, I mentioned at the beginning of the webinar the Systems Engineering Process or SEP. It's defined, again—I'll give you the textbook definition—as an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and requirements, required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation.

Now, over the years there's been multiple ways to represent the Systems Engineering Process. The one we've been using most recently and probably for at least ten or more years now is the one that's indicated here that's just called the systems engineering V diagram simply for the shape of the V. It represents the typical lifecycle of any system or project, whether the system being deployed consists of basic computer-aided dispatch system for a transit agency or a more complex interface between, say, a traffic management center and a public safety agency. All systems will follow some variation of this lifecycle.

And if you aren't already, you should become very familiar with the SEP diagram as it's gonna be used frequently through this series of modules. And how you read it, hopefully you can see my cursor. And maybe if some of you could chat in 'cause I'm gonna use that to kind of point out a few things on this particular diagram. It just disappeared. Can somebody see it? I'm pointing at regional architecture right now and then I keep losing it. Okay. So you see it. Okay. Nicola says she sees it. Hopefully that means everybody else does.

You start over here on the left-hand side of the Systems Engineering Process with regional architecture and you move your way along here through a needs assessment, systems—concept selection and project planning. And then you really get into the meat of it here with the systems engineering management planning where you develop a concept of operations and defining your system requirements here. And then we finally get into the design. So we've got to define our system, what we want out of our system up here. Then we move into design and then the building of it down here. Software coding, hardware fabrication. And then coming up the backside here is where we do a lot of testing.

And testing is the subject of a different webinar and hopefully you'll be able to take that one as well. T101. And it helps for what's called traceability of moving back and making sure that it meets our requirements. Finally, when the system is completely implemented, you move into an operations and maintenance mode. And as we all know, we're gonna have to upgrade it eventually because technology changes. And perhaps eventually retire and we'll replace the system. So that's how it's—that's how it works for the Systems Engineering Process. Key to the success of the Systems Engineering Process is the identification of user needs and requirements.

When developing them, the focus is really on the "what" the system needs to do not the "how" the system will do it. Every need should have at least one requirement. So every user need should be able to trace—or sorry. Every functional requirement should have a user need. In the Systems Engineering Process, a traceability matrix is used to document and verify this. The matrix may be maintained directly in the database or spreadsheet for small projects or generated and maintained with a requirements management tool for a more complex project.

Using either approach, the matrix provides forwards and backwards traceability between stakeholder needs and other potential requirements sources—system environments, design implementation, and verification test cases. So functional requirements trace back to user needs and your user needs are really defined by who your users are. In this case, the system users on this diagram.

Here are a few other benefits of using the Systems Engineering Process. It provides a framework and process to verify that the system meets user needs. It also improves stakeholder participation as you involve a lot of people up front that may have a large stake in the project and they may have a small stake in the project. You develop more adaptable and resilient systems. You can verify functionality and hopefully achieve fewer defects. You get a higher level of reuse from one project to the next and also better documentation, all reasons to use the Systems Engineering Process. Stand by for a second.

Well how do standards relate to the Systems Engineering Process then? Well, ITS standards are primarily used in the design stage of the process after the higher level activities like needs assessment and concept of operations have been developed. During the detailed design phase specific messages, data elements, communication profiles, and design options are defined. However, it should be noted that when using SEP-based standards, they provide critical user operational needs and interface requirements during the project definition stage. Again, that is a little bit confusing on how this is defined as a Systems Engineering Process to develop your whole project and within this project you can use standards that were defined using a Systems Engineering Process.

So let's talk a bit about SEP-based standards. And this can be confusing for someone who is not very familiar with standards and how they are developed. ITS standards development has changed and several ITS standards are now available as later-version standards. Several later-version ITS standards have been developed with a Systems Engineering Process and now include user needs, requirements, needs-to-requirements, and requirements-to-design matrices, and design solutions, dialogues, and object or message definitions. And by using these newly developed ITS standards, deployers can better ensure that they will implement a system that is compatible, interoperable, interchangeable, and conformant to ITS standards.

For those standards that are not SEP-based, system developers will need to understand how to develop user needs and requirements. And this is a topic of discussion in other modules, not today. All right. I'm gonna ask again for some feedback on a particular question. As we move to the next one, I'm asking what do you think are the common technical challenges to implementing a standards-based system. Or you can comment on what some of the common institutional challenges are, if anybody wants to think of any of those. Technical challenges and institutional challenges to implementing a system that uses ITS standards.

And I should point out again as you're chatting in answers here, you can chat in a question at any time if there was something that you perhaps didn't understand on a particular slide and I should have mentioned this at the beginning. Feel free to ask a question or even put in a comment. Any time I teach a class, I like to hear from those that are out in the audience as well. And if you have any thoughts or experience—and I'm gonna have that coming up as well on a later slide.

Well nobody's chatting in anything. It's an awfully quiet audience out there. Okay. Here we go. [Reads] "Not enough skilled technical resources." Yeah. That can be a technical challenge right there. It kind of relates to what somebody had said earlier about—where was it? I thought somebody had said something about—well Legacy systems. I saw that up there and time. Yeah. Time was mentioned to learn about how do you become better skilled? Well, you've got to take some training and that takes some time and resources to do that.

An example of an institutional one? "Reluctance to change the way things have always been done." Classic institutional challenge for just about anything if you think about it, not just implementing a standards-based system. But there's always that first answer's like, "Well, but we've never done it that way. We've always done it this way. And it's always been fine so why fix what isn't broken?" All right. Good technical and institutional. Well let's just go over some of them.

There will always be technical and institutional challenges encountered when integrating ITS components. A particular agency may not be able to anticipate all issues that might occur during a project deployment. However, you want to anticipate that technical issues will occur and that these issues are most likely—will most likely affect the cost and schedule of the project. The key to success is to plan accordingly and develop solutions prior to project deployment to minimize issues that surface during the integration phase.

So here on this slide are some technical and institutional challenges that have been identified by others. On the left-hand side we've got gaps in existing skills, which was mentioned there. Not enough skilled technical resources. There's still something of an inconsistent industry support for standards, which is to be expected when we're so early. Still the infancy of standards I think, I don't think we've reached full maturity yet, conformance to standards. And then just this whole idea of a paradigm shift from non-standards-based to standards-based and from non-SE based to SE-based. That's a technical challenge.

On the institutional side, not everyone in the—in an agency is willing to articulate their needs. So when you're—when you've got your stakeholders they may or may not be willing to speak up and articulate their needs very well. Resistance to change. Almost verbatim there what had been chatted in.

Maybe not all the agencies have bought into regional integration. You have. Your neighbor has. But what about that other city over there? They're still kind of off on their own and haven't bought into the idea that by talking to each other, electronically if you will, benefits the whole area, the whole metropolitan region. And then you'll notice I also have paradigm shifts under institutional as well. They kind of really bridge over both of them.

Well, next I'm gonna go over several lessons from the field of actual projects that implemented standards-based equipment. And while I am doing this, still feel free to chat in any lessons that you have learned and we'll take a look at them when I get to the end of this section.

Some of the key lessons learned are summarized on this slide and the following two slides. First of all, to develop useable systems that meets user needs. This is an example of functional integration. Develop useable systems that meet user needs. Assess user needs and follow accepted usability engineering practices when developing interactive systems and using ITS when developing systems to maximize vendor flexibility and data exchange compatibility and ensure comprehension by agencies.

So functional integration is really a subset of the system integration process. During this process system components are assembled into a working system and verified to ensure that they fulfill all of the system requirements. Assembling a puzzle is a helpful analogy on this—for this step.

The challenge in an ITS project puzzle is that not all of the pieces are available at the same time. Some will not fit together particularly well at first and there will be pressure to change some of the pieces after having already assembled them. Software and hardware integration are important components of functional integration as the following discussion shows in a minute.

Jurisdictional integration—stand by one second. Jurisdictional integration, the challenge here is to create systems and plans that allow information sharing and coordination among regional agencies and states. And also consider developing an emergency response plan that coordinates command and control and communications among regional agencies. The intent of jurisdictional integration is to integrate the processes that allow seamless travel and coordination among jurisdictions, although the jurisdictions continue to operate as separate geographical and political entities.

Technical integration issues relating to jurisdictional considerations involve both the design and implementation of ITS solutions as well as coordination issues among regional entities. While jurisdictional issues often have organizational and coordination implications, these issues often interact with and affect technical system issues. And therefore, organization and coordination issues must be considered in concert with the technical integration system issues.

And finally, our lessons from the field that we'll look at here in a moment, one of them we'll deal with Legacy systems and the issues of complying with standards and select proven commercial, off-the-shelf technology when possible to save money and facilitate integration with existing Legacy systems and to identify and resolve system integration issues with existing Legacy equipment. Plan on adequate development time and thorough system testing to ensure systems are working properly after the integration.

One of the largest, most common hurdles when developing ITS is to make them compatible with existing systems already deployed. There are several important factors that must be considered when integrating new systems with existing ones and that can have significant impacts on the ITS system costs and deployment schedules. These issues include integrating with existing Legacy systems to save costs associated with implementing a new system as well as complying with standards whenever possible.

Well, let's look at a few of these here. A number of projects from around the country have implemented ITS standards in their systems. And we'll look at a few of them and if we glean some lesson that we can learn from them. In the area of functional integration experiences from the Tri-County Metropolitan Transportation District of Oregon, often called TriMet, as well as the Utah DOT, actually, show the following ITS standards and protocols helped ensure that ITS components being integrated can function together. Additionally, following ITS standards and protocols helps provide vendor and system flexibility.

In the case of TriMet, at the time of its procurement of light emitting diode signs, LED signs, no TCPIP standards for the LED sign interface had been developed. And TCPIP meaning transmission control protocol, Internet protocol. That's what basically allows the Internet to communicate.

Consequently, the agency was forced to consider sign vendors that had proprietary protocols. Now, even though no standards were available, TriMet knew it wanted the LED signs to interface with TCPIP-compliant devices, so TriMet provided specifications that required the sign vendors to interface with the protocols. The TriMet staff believed there was—that there was an advantage to using TCPIP and standard protocols that would enable the agency to use different communication methods yet retain the same applications. Complying with ITS standards and protocols helps ensure a modular and compatible infrastructure.

Also in the area of functional integration in a study of 10 traffic management centers in—I'm sorry. In a study of traffic management centers in 10 different states, FHWA determined that it was important to use multi-industry data interchange standards to integrate data information and systems. Use of standards allows better coordination of TMC efforts and more efficient management of day-to-day traffic and emergency operations. Incomplete or inaccessible information, however, often impedes the ability of TMCs and related agencies to coordinate and efficiently manage their operations.

The FHWA study concluded that the current application of information sharing and decision making at TMCs could be improved. Additional concepts of emergency integration were identified including comprehensive coordination within and among TMCs, training and coordination among operations personnel, and integration of emergency information into TMC operations. The study concluded that these concepts could be implemented using existing technologies and that they offered the opportunity to move the current state of the practice forward.

Well, what about jurisdictional integration? What have we learned there? Well, transportation agencies in the Washington DC metro area discovered the negative consequences of a lack of communication and coordination on a date I'm sure we're all familiar with. September 11, 2001. Now, following the attack on the Pentagon, there was a rush of commuters fleeing from the district to the Maryland and Virginia suburbs just as the AM peak hour was ending. There was no communication between the Virginia and Maryland DOTs and the agencies located within the city such as the District of Columbia DOT and the National Park Service, which operates some of the cities key roadways located on national park land. In addition, there was no—also no communication or coordination with the region's transit agency. The Washington Metropolitan Area Transit Authority or sometimes called WMATA.

The Virginia and Maryland DOTs employed a variety of strategies to handle the unanticipated demand and get people out of the city such as adjusting traffic signal timings for heavy traffic, displaying messages on dynamic message signs, and opening high occupancy vehicle lanes to all traffic. However, some emergency evacuation strategies could not be used due to the lack of communication and coordination among agencies.

The Virginia DOT could not reach WMATA to notify the agency that it was permissible for its buses to use the open HOV lanes. This limitation hampered those depending on transit in their evacuation from the city. This experience illustrates why it's critical to create a system that allows the state to manage implementation as a whole and to tie in with each transit agency.

When developing a statewide ITS architecture, the main goal of the Iowa Department of Transportation was to enable interoperability among local transit operators. To achieve this goal, the Iowa DOT developed a template for ITS contracts. Transit agencies in the state must agree to the terms detailed in the template as a condition of participation in statewide ITS programs.

And finally, a lesson dealing with Legacy systems. Often times one of the biggest hurdles when developing ITS systems is to make them compatible with existing systems already in place. The transit tracker project was no exception. This project builds upon the existing AVL bus dispatch system, sometimes abbreviated BDS, and the rail Central Corridor System, the CCS. Disseminating real-time transit information collected through the bus dispatch system and rail central control system to transit customers.

In TriMet's case, they did not encounter many problems integrating the transit tracker system with the existing Legacy system. The existing systems were built on the same platform that was to being cross-proposed for the transit tracker system.

This saved software development time and system costs. There were a few minor changes that needed to be addressed because of the different requirements necessary for reporting information to customers as opposed to reporting information to the dispatchers. As an example, for the real time transit tracker system, TriMet had to change the rate at which information is provided and expand the type of information provided by the system to respond to the needs of the customers.

All right. Hopefully some of you have thought a little bit about maybe what you've done out there and I see Nicola's chatted in a question there. What are your lessons learned? And I want you to type it in. And, again, feel free to type in while I'm talking so we don't have a whole lot of dead air. So these experiences that I just went over demonstrate that technical integration as a multi-faceted concept. It involves more than simply assembling the pieces of a puzzle.

This type of integration involves functional, jurisdictional, and Legacy system issues that all must be considered and coordinated to successfully integrate the components of an ITS system. Following this guidance will help to keep project costs and schedules within projected ranges and will help to foster ITS deployments that provide the anticipated transportation benefits and meet customer expectations.

So anybody have something that they want to mention that they did for a project that they did? A lesson you learned, whether it be good or bad. That's a quiet bunch out there today on this Monday. Well, I'm gonna keep moving on but that doesn't mean I don't want to still hear about any lessons learned. I know sometimes it just kind of takes a while to get your thoughts chatted down in the box there and we'll come and take a look at anything before we finish up the webinar today. So please feel free to still put something in there.

ITS applications are defined by the regional architecture as shown here as an example. This regional architecture is based on the national architecture, which is not shown, but most of us are probably familiar with, sometimes referred to as the sausage diagram. That's the national architecture. Once a regional architecture for your particular area is defined, say for example this one here, standards can be mapped to it. For example, if a system is going to include closed-circuit television, CCTV, then the system must be able to control the cameras. So I show up here on this slide video camera control.

And so if you're gonna include video camera control, it leads to the use of—there—NTCIP 1205, which is a standard, an NTCIP standard and it's Object Definitions for Closed-Circuit Television, CCTV camera control. Or if you need to collect data, you might use NTCIP 1206, Object Definitions for Data collection and Monitoring Devices. So regional architecture looks for data flows and only standards can support those flows to gain interoperable domains and systems. The SEP methodology, Systems Engineering Process methodology with ITS standards will help produce regional interoperability, sharing devices, and exchanging information across jurisdictional boundaries.

An agency will benefit from multiple vendors, proprietary situations are avoided and eventually results in maintenance efficiency, both cost and ease of it. I'm gonna check back here. As chatted in here, [Reads] "Before installing handheld zoom cameras at intersections, be sure to beware of private property and their concerns in regards to privacy."

That's a good point. As cameras have become more prolific where there's a number of years ago it was more limited to just freeway systems. A lot of the state systems were monitoring their freeways but today we're seeing arterial systems use cameras quite a bit more, particularly at key intersections. And just by the nature of an arterial street system you're getting a lot closer to potential houses and places of business. And people are—don't want to look up in their backyards and see a camera pointed down in their backyard. And that would be—cause a lot of problems.

So if you are installing PTZ cameras, you do want to be aware of that. So that's a good point, Michael. Appreciate you bringing that one out. There's ways of doing that. You can restrict how far a camera could rotate on its PTZ device. That's probably the easiest way. So things you need to take into consideration. You know, even with these video detection systems that we're using purely for detection at intersections, they can make a public a little bit nervous if they start seeing them pointing other directions. Most of them are not PTZ-type cameras though.

All right. Another lesson learned. [Reads] "ICT engineering and ITS engineering culture clash. Two different worlds." ICT could you tell me what that is? I'm not familiar with that particular abbr. Oh, okay. Information Communication Technologies. Okay. So the IT folks, if you will, and us engineering folks. We don't always talk the same language but yet we're using a lot of their language in our standards, which is important because a lot of the things we're doing now is being communicated through standards that were developed by the IT world.

I think of the—sorry, my mind's blanking at the moment. The steps the OSI, ISO seven-layer model, which was developed—had nothing to do whatsoever with transportation or traffic when it was developed but it's a way of communicating from one place to another using the seven-layer model, which I'm not gonna go into detail. So we use a lot like TCPIP. It'd be nice to say us traffic folks invented that but we didn't. But it's such a ubiquitous standard that's out there that it makes perfect sense for us to adapt our equipment to use that particular protocol.

And so sometimes when we talk about what we want to do, what we need to do as engineering and the ITS realm may conflict or, you know, not easily understood by the IT realm over there, the ones that are in charge of all the computers typically for a major jurisdiction, the computers and servers are not gonna be owned or controlled by the traffic department but by rather an IT department.

So I think that's what you were getting at Eric. I hope that's what it was. If not, just chat in something and I'll clarify further if I need to. All right. Again, feel free to chat in any kind of questions or comments that you want. I'm kind of nearing the end of the presentation portion of this webinar and I've gone about an hour so far so we're right on schedule. I'm gonna go ahead and review some of the learning objectives and I've got one or two more slides to talk about but I don't want to cut off discussion. This is the time for you to ask questions or make your own observations or comments. Again, if we can learn from each other, all the better.

So let's do a quick review of learning objectives. In this webinar, we identified the benefits and costs of using ITS standards and ITS projects. Benefits, as you may recall, included interoperability, interchangeability, reduced operations and maintenance costs, easier expansion capabilities, just to name a few. There's probably about another six or seven that I haven't mentioned here. Costs were primarily related to upfront costs of either upgrading Legacy systems or building entirely new systems.

So, again, you may have some costs up front that would be more expensive than implementing a non-standards-based system, but you hope to recoup those costs down the line as you upgrade and expand your system. Describe the benefits of using—sorry, Systems Engineering Process in ITS projects. These benefits included providing a framework and process to verify that the system meets user needs, approves stakeholder participation, and building more adaptable, resilient systems, in addition to a few other benefits.

We also identified and addressed some of the high-level technical and institutional challenges to using standards. Technical challenges included gaps in existing skills, which can be solved by—in some improved training and inconsistency in industry support which should as we mature in using standards, that should hopefully start to go away a little bit more. Much of this is done, again, looking back at my home theater analogy, I don't think we see any inconsistency in some of the standards that have been developed and how vendors support them in the AV world.

Institutional challenges we mentioned. Resistance to change. Some organizations just want to keep doing the way they did it. Not everyone might be articulating their needs completely and may not have complete buy-in from other jurisdictions in the same area. And we also described the role of ITS standards in ITS applications as part of a national or in a particular or regional architecture. By mapping out needs and functionality on a regional architecture, it becomes much clearer which standards are applicable to your system.

You should have also gotten a link to the student supplement. And I want you to look at that and have it as a handy reference that—it includes three primary things, which I've talked a little bit about today but didn't go into great detail because it's covered in the student supplement. Some of the frequently asked questions were taken from the FHWA Office of Operations web pages.

In particular, in regarding national ITS architecture and standards. Also included is some information regarding the ITS standards from the RITA website, which is part of the USDOT. And also I made mention earlier on about the rule, the rule 940. And so we've included the ITS architecture and standards final rule published back in the January 2001 Federal Register.

Somebody chatted in – [Reads] They said, "Slides 41" – it's only two slides back. I'll go back. "You show NTCIP 1206 doing traffic flow and traffic center control." And then it says, "I believe you mean NTCIP 1206, which I"—so what did you mean? I said 1206, object definitions for data collection and monitoring devices. Excuse me. So 1209. Okay. So 1209. I'll double check that to see if I just did a typo. If I typed my nine upside down and made it a six. If 1209 is indeed Object Definitions for Data Collection and Monitoring Devices then, yes, it should be 1209 and we'll make sure we double check that for the future versions of this.

So feel free to again chat in any more questions or comments right now. We've still got some time. It's only three minutes, four minutes after the hour and we've got a little bit more time that we can talk. I had mentioned some of these websites that you can go to as well. The RITA ITS website is up there. Standards.its.dot.gov. ITE has some information on standards on their website. The ITS architecture implementation program is on an FHWA page. The NTCIP website is a very good website to go to learn all about NTCIP and the various standards. And finally, I have another excellent resource is the Systems Engineering Guide for ITS on the FHWA website there. Okay.

A good question just got chatted in. [Reads] "Are ITS standards mandatory for federally funded projects?" The answer to that is no. They are not mandatory. As I mentioned kind of early, early on in the webinar, ITS standards are voluntary. The only thing that is mandated for federally funded projects is that you use a system's engineering process in developing your project, which does ask you to at least look at standards as being a part of that process. But no, ITS standards are not mandatory for federally funded projects. Good question and one that gets frequently asked.

Other questions or comments? Please go ahead and get them in. Our audience is not huge out there today so looks like we got about 17 people online today, 16 people. All right. Well, I'm not seeing any more get chatted in so we're gonna kind of finish up early today. And I thank you for your time and your attention and I hope you learned a little bit about ITS standards today and how you might make use of them and how you'd implement them in your project. Why you might want to use them. To save money and establish some of the other benefits that you can have with projects that use ITS standards. So with that I'm gonna turn it back over to Nicola.

[End of Audio]