ITS Transit Standards Professional Capacity Building Program

Module 5: Transit Management Standards, Part 2 of 2

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

Mac Lister’s Introduction

ITS Standards can facilitate the deployment of Interoperable ITS systems, and make it easier to develop and deploy regionally integrated transportation systems. However, these benefits can only be realized 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 promoting multimodalism and interoperability in acquiring and testing standards-based ITS transit systems for public transportation providers.

I am Mac Lister, Program Manager, Knowledge and Technology Transfer in the ITS Joint Program Office of the USDOT. And I want to welcome you to our newly redesigned ITS Transit Standards Training Program, of which this module is a part. We have worked closely with the Federal Transit Administration and the American Public Transportation Association to develop this material. We are also 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 these webinars.

ITS Standards Training Program is one of the offerings of our updated Professional Capacity Building, PCB, Training Program, specific to transit and industry domain to promote the use of ITS Transit Standards, such as TCIP, automated fare collection, and transit management, to name a few. Through the PCB Program, we prepare professionals to adopt proven and emerging ITS technologies that will make surface public transportation system safer, smarter, and greener, which improves the livability for us all. This series of online courses based on ITS Transit Standards is in addition to a 35-module series available for free on ITS Standards for practitioners in the State and the local highway agencies, and transit agencies. You can find information on additional modules and training programs on the USDOT website at ITS PCB Home.

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

Jeffrey Spencer’s Introduction

ITS Transit Standards help simplify the complexities, overcome procurement challenges, and reduce costs of acquiring ITS Systems. I would like to use a simple example to explain how this approach to ITS Transit Standards is analogous to our day-to-day life. Imagine that when buying a computer, and you want to buy an upgrade, a printer, or anything else, that you must always buy that same brand at an exorbitant price. Of course, this is not the case, because standards have been successfully implemented to allow interoperability. Similarly, transit standards have been developed by transit professionals like you at a national level to encourage competition and limit costs within our industry.

I am Jeffrey Spencer, ITS Team Leader in the Office of Research, Demonstration, and Innovation of FTA within the USDOT. And I would also like to welcome you to this ITS Transit Standards Training. FTA actively supports the development and implementation of transit standards. And we hope that you find this series of online courses a useful tool in promoting standardization. We look forward to your participation and input.

Narrator: Welcome to the ITS Transit Standards Professional Capacity Building Program, Module 5, Transit Management Standards, Part 2 of 2. This Activity slide will appear, indicating there is a multiple choice pop quiz following this slide. You will use your computer mouse to select your answer. There is only one correct answer. Selecting the Submit button will record your answer, and the Clear button will remove your answer if you wish to select another answer. You will receive instant feedback on your answer choice.

Carol Schweiger: Okay. I want to add my welcome to Module 5, Transit Management Standards, Part 2 of 2. My name is Carol Schweiger, and I’m the President of Schweiger Consulting LLC. And I have about 35 years of experience in transportation consulting, most of which has been in the transit technology area. So I’m looking forward to going through all of the learning objectives here, and helping you understand about using transit management standards.

So let’s talk first about the target audience for this particular module, so that you understand a little bit better the curriculum. So there’s really three groups of folks that this particular module targets. It’s technical staff that are in the transit agency working in various areas within the agency. It’s also for vendors and consultants, as well as procurement and grant staff. And as you can see on this slide, the prerequisites for this particular module include Modules 1 and 2. And Module 2 was Transit Management Standards, Part 1 of 2 that just preceded this. So we’re looking for you to have a basic understanding of the transit portions of the National ITS Architecture, as well as a very basic understanding of systems engineering, which we presented in Module 2. And then you can see for each of the basic groups that we were talking about, the curriculum path. So you can see on this slide the box that has a red line around it is this particular module, which is Part 2 of 2. So you would have started with Part 1 of 2, and preceding that, you would have taken the Introductory Module, which is Module 1. And that’s if you’re in the project management area. If you’re in the technical area and a project engineer, it really looks very similar. And you would go through, take this particular module. You’d move to the TCIP modules, the traveler information modules, and then the arterial management signal priority, and then the optional modules might be the fare payment systems, which is Module 10, and the connected vehicle area, which is Module 11.

So now we can get started looking at our overall four learning objectives for this particular module. And they’re summarized here on this slide. Learning Objective 1 is really to summarize the key concepts from the Part 1 of 2, which was Module 2 that you took before, just a very brief summary. Learning Objective 2 is to show you the structure and the use of standards in transit management systems. So it’s how to look at data exchange using standards. Learning Objective 3 is to be able to select the appropriate standards for the project that you’re working on. And Learning Objective 4 is to show you how to apply the standards when you’re doing a procurement.

So in our first learning objective, we’re going to briefly talk about the taxonomy and the technologies, which is the very brief review for you of the prior Module. We’re going to talk a little bit about the relationships and the information exchanges in those technologies. Briefly mention systems engineering, just to remind you of a couple of key concepts there. And talk about the service packages in the National ITS Architecture that are related specifically to transit management. So there are four categories of systems and technologies that we’ll review very, very quickly. And I’ll flip to the first slide that looks at that first category, which is fleet operations and management. So that category covers technologies that are implemented to facilitate transit operations, and provide input really to senior management in terms of looking at the overall transit system’s performance. So you can see here—I’m not going to read everything on the table—that we have a variety of technologies that are being used to help to operate the transit system as well as provide input to management. This list of five technologies here, as well as on this slide there are five more, so there’s a total of ten technologies. And you can see in these two tables that we show you what each of those technologies is dependent upon, and we’ll come back to that in a little bit.

So that’s our first category, Fleet Operations and Management. What I wanted to show you in this slide is an example of the relationships among some of those technologies. So very simply in this particular slide, which is in a flow chart format, that in the center you have the central server that has some of those technologies that we just looked at in those two tables. So we have a CAD/AVL. We have a Passenger Counting Module. We have a Scheduling Module, we have Signal Priority, etcetera. So that’s central to the technologies. And then if you look off to the left, the clouds that are on this chart represent the communications portion. And you can see that there is communications taking place between some of those technologies and the fleet, for example, which is in the upper left-hand corner. And then if you look off to the right, we have some more technologies that are actually happening mostly onboard the vehicle. So that gives you an overall picture of how the technologies are related to each other from the central side. And then on the next chart, we show how some of these technologies are related to each other onboard the vehicle. So you can see all of the gray boxes represents specific technologies that are on board each transit vehicle. And you can see that they’re all interconnected. And one of the things that we’re going to get to later in this module is talking about how standards facilitate the communication among those different technologies that are on board the vehicle.

So that gives you an idea of what the relationships are. So let’s move to our second overall category in the taxonomy is the Safety and Security area. And that category really covers those technologies that improves safety and security of, not only the passengers, but also of the transit staff. And that’s both on board the vehicle as well as in any of the transit facilities. So you can see we have four technologies, and you can see in this table what they’re dependent upon.

Our third category is maintenance. And this specific category covers technologies that facilitate all kinds of activities that happen with maintenance. So you may have vehicle component monitoring where the components onboard the vehicle are being monitored to ensure that they are within a certain tolerance for their operation. And then you’re going to be tracking things like scheduled maintenance activities, maybe unscheduled maintenance activities where you’ll be looking at entering work orders and making work assignments for that maintenance. And then the final aspect of that is typically inventory, and fuel management, which is really part of that as well.

And then our final category is really data management. And this covers a pretty wide variety of areas. You can see on the slide. It covers our databases that are being populated by using the technologies that we’ve seen previously. We have integration among some of those technologies which you saw in a couple of those flow chart slides. GIS, which obviously uses spatial data. And then we have coordinated service where some of the data might be shared with some other agencies or other transit providers. And then finally, open data. And that’s often provided by the transit authority, so that third parties can come in and develop applications, for example, for smartphones, so you could get on your smartphone and see when the next vehicle is arriving at your stop, for example. So that’s the data management category.

So just briefly, I wanted to review the Vee—we call it the Vee-Model for Systems Engineering. And it’s a "V" that has some wings. And very, very briefly, which you saw in Module 2, the wings on the left really lead you into the planning of a technology project, and provide some basis for you to develop what the system is going to actually do functionally. When you start to go down the left-hand side of the Vee, you can see that you’re defining the system requirements. What does this system need to do? As you get further down the left-hand side, you start to define the actual design of the system, which says, "How will you perform those functions?" The functions are the "What?" The design is how you’re going to do that. So what kinds of screens do you need in your software? What needs to happen with the hardware? And then at the very bottom of the Vee is when you’re actually implementing the system, both the software and the hardware. If we go up the right-hand side of the Vee, we’ve now been doing some installation, and we start to do our testing in a very systematic way. So first, we’re going to test at the real component level to make sure that all the components work. And then we’re going to integrate the components as we do our installation, and then we need to test to make sure that they all work together properly the way they were intended. And then we put the whole system together, which is made up of all the components that are integrated, and we need to make sure that the systems function as a system. So now, we can actually validate what our original thinking was about how we develop the system. And that’s why there are lines that have arrows in both directions that go up the middle of the Vee. We’re going back to something we defined before to verify did we actually accomplish that? So now on the right hand side of the Vee, the wing, it shows now we’re in operations and maintenance of the system. We built it, we tested it. So now we’re operating it, 24-7. And then we have a couple of activities where we might be making changes or upgrading the system. And we will eventually be either retiring the system or replacing it. And so we need to be mindful of that as we’re going along. So that’s the Vee-Model.

The other part by way of just recalling Module 2, is that one very important part of the National ITS Architecture is called Service Packages. And they address very specific kinds of services. So those services might be composed of certain components and some hardware and software and some data exchange. And that’s why these are very important, because that’s really the crux of what we’re talking about today is data exchange and the standards that facilitate that. So there are 11 Public Transportation Service Packages in the National ITS Architecture. This particular slide shows five of them at the bottom of the slide, the sub-bullets. And I’m going to show you an example of what one of those looks like, but there are five of them. And then there are six more here on this particular slide. All of these deal with transit management technologies, and they’re very important in discussing the standards. And I want to show you a diagram of one of them so you get a sense of how to depict what one of these Service Packages are. So on this particular slide, which comes directly from the National ITS Architecture Documentation online, we see that this happens to be the first Service Package that was in that list on the first slide, it’s the Transit Vehicle Tracking Service Package. So you see some boxes and some lines with arrows, and some oval boxes. And this just shows that in the purple boxes, those are actually parts of the architecture. The transit management box is actually called, quote, "a sender." And we’re going to get to that in a little bit and explain that a little bit more. And then off to the right, the purple box that says, "Transit Vehicle," is our vehicles that are operating in our transit system. And you can see that there’s information coming from each of those boxes, and going to other places. Some outside the system, and some inside the system. So if you look at the transit management box in the center, there’s some data emanating from that, going to two boxes that are crosshatched. Those are outside of the transit authority. One’s an information service provider. And you can see there’s some data being exchanged there. If you look at the transit vehicle, it’s providing some data to the transit management center. So you can see that as well. And then you can also see data coming from the transit management center to and from a map provider. So the map is being updated, and the location of the vehicle is being updated as well. And there are diagrams for each of the 11 Service Packages that relate to Transit Management through the Architecture Documentation.

So our first activity, our first quiz, if you will, here is our question "How many Public Transportation Service Packages are there in the National ITS Architecture?" And the answer choices are: a) 4 packages, b) 10 packages, c) 11 packages, and, d) 15 packages. So now if we look at the answers, Answer c is correct. I had mentioned there were 11 Public Transportation Packages. And as you can see, the other ones are not correct, because they’re not the number 11. So now we can move on to another quiz; "Which of these are not Public Transportation Service Packages?" So if you recall the 11 that I listed on those two slides, which one of these really doesn’t belong? And the answer choices are: a) Transit Vehicle Tracking, b) Multimodal Connection Protection, c) Multimodal Coordination, and d) Broadcast Traveler Information. So now the answer, the correct answer is D. Broadcast Traveler Information. It’s not specifically defined as a Public Transportation Service Packages. It is somewhat related, but in this list of four, this would be the one that you would say does not belong in the list. So A belongs. We actually talked about that, and I showed you a diagram of that. Multimodal Connection Protection is also one, as well as the Coordination—Multimodal Coordination.

So to summarize Learning Objective 1, we really have a couple of key highlights. We showed in the tables that all of the technologies that we’re speaking about with transit management are dependent upon other technologies. The Vee Model is very important to keep in mind as we go through this module, because it defines when you’re going to do—perform certain activities—when you’re developing your system. And there are 11 Transit Service Packages that you can utilize as you are designing your system. So that’s our summary of Learning Objective 1.

So let’s move into Learning Objective 2. While there are only two sort of sub-bullets here, there’s quite a bit of material to describe how standards can be used really to meet user needs. That’s really what we’re looking at. And there are a lot of benefits to using this particular approach. So we’re going to cover these two sub-bullets now as we go through our slides. So what do we need to understand at the beginning of this is you’re building a system to meet user needs. You’re not building a system just to build it. And so we need to understand what the definition of user need is. It’s defined as a user requirement for a system that a user believes would solve a problem that they’re experiencing. So you’re really trying to solve a problem. You’re not just trying to put technology out in the field for technology’s sake? And so by establishing those user needs, and understanding what the users want, the system is eventually going to be built to meet those needs. And that’s a very, very important part of the system’s engineering process. Very important. And we’re also going to be looking at other aspects of using standards. And that has to do with customizing some of the solutions, and selecting what’s the most suitable way to solve these problems, and to build these systems. So by way of continuing, we’ve got another aspect here. What benefits do you really get from using standards? Do you really need them? Are they really doing anything for you? And the fact is there are direct benefits from using standards. Primarily they can be used as a tool for reducing the complexity of this system. And consequently the cost, which we’re also going to talk about in the procurement, it brings the cost down. If you’re using standards that are widely accepted, the cost of that system is going to be reduced. And also the complexity of just developing this system will be reduced. And one other aspect you want to be concerned about is the competition. When you actually have a procurement, you want to attract the widest possible variety of suppliers for you and encourage that competition. So, that’s what we really want—what we’re looking at with benefits.

So let’s look at an example. Why would I be using this standard? So in some cases, user needs are directly satisfied by using standards. And here’s an example for you. Let’s say a transit agency wants to provide real-time information so that developers can develop a smartphone application. So I get on my smartphone as a rider and know, you know, real-time information about my vehicle, when it’s arriving. So what do I want to do? I want to use standards to make it easier for developers. If you’re using standards, all the developers know what those standards are. So what do I need to do to provide that real-time information is I need to provide some information about where the vehicle is going to be located. And one way of doing that is to use what we call a de facto standard, which is the General Transit Feed Specification or GTFS. And there’s a form of GTFS called GTFS-realtime, that’s actually the name of it. And that could be used to provide this data to developers so they can develop an application. Now could you provide that data in other formats? Sure. There’s no reason why you couldn’t. But if you provided in GTFS-realtime the developers already know what that standard is. And their applications typically work with that standard. So you’re making it easier, both for you to generate the open data, and for the developer to consume the open data. So that’s an example.

And let’s talk a little bit about the value of standards meeting user needs. And we have on this slide sort of three major bullets. I’m just going to cover the major ones. So the first one is really protecting your investment. If you use standards, you’re, you know, it’s basically saying that any product that uses a standard is probably available from a variety of different suppliers. And the cost is lower. So you’re really protecting your investment. And you’re perhaps enhancing the life of that system by using a standard as well. And then you’ve got some specific advantages here, the sub-bullets. Being able to modularize the system and do an incremental development, maybe get some module in place first for us to move on. Choice of suppliers, we already talked about. And reuse is really being able to specify, reducing the cost in specifying the system. Interoperability, briefly, you’re using data from a wide variety of external and internal systems, and you want to make sure that they’re interoperable. So the standards facilitate that part of it as well. And then the quality and the value, that’s another proposition that’s very important. If you’re using a standards-based product, they typically have proven components. These components have been proven in the field. They’ve evolved over time as the standards often do. And usually, they have a higher level of use than one-off customized solutions. So they’ve been extensively tested in the field, typically. That’s on the quality and value side. So those are very, very—those three key sort of value propositions. And then, we need to look at, "Well, how do you evaluate a standard for its use?" And you need to look at technical considerations as well as organizational. So how well does that standard actually help you solve your problem? And what technologies is it assuming are already there? And then organizationally, which to me is probably the most difficult part of this, the technical part has been solved over and over again, but sometimes the organizational part is a little tougher. So you want to look at how mature this standard is. Is it actually still under development, has it been out in the field? How long has it been out? Is it supported by the vendors? You can specify any standard you want, but if it’s not supported by a vendor community, it’s going to be very hard to put in place. And then you also want to know what its longevity is. Is it a short-term standard developed for a particular reason, or is it longer-term?

So how do I start the process of figuring out what the most appropriate standard is? So the National Architecture kind of sets up this nice structure to help you figure out the most appropriate standards. So what we’re looking at is a couple of things. One’s called application areas. And those are categories that focus on commonly deployed systems. So we would be looking at commonly deployed transit management systems. And the application areas are further—sorry—there’s another term that I want to introduce called "interface classes." So the architecture is divided into interface classes, and those are further divided into the application areas. So in our case, in transit management, we’re going to be looking at three interfaces classes: Center to Infrastructure; Center to Vehicle—and if you recall, my Transit Vehicle Location Diagram that I showed you earlier was actually an example of a Center-to-Vehicle example—and then the third one is Center to Center. So we’re going to be talking about each of those. And I think the important point for you to understand about interface classes is they’re defined by the type of system that’s being used. So that’s why we use the terms Center Infrastructure, Vehicle, those kinds of terms. And all of these have bidirectional communication. So in other words, if I say Center to Infrastructure, I’m implying Infrastructure to Center as well. So you can see at the bottom, it’s bidirectional communication. So let’s say, for example, you had some electronic signs at a bus stop that are showing when the next bus is arriving. That data is coming from the transit management center. And it’s being sent through a piece of infrastructure, which is that electronic sign, so that would be a C2I, or Center to Infrastructure example.

So let’s go through each of our areas here, the interface classes. And we’ll talk about the different capabilities in applications that we have here. So our first one is Center to Infrastructure. And again, that could also mean Infrastructure to Center. And that really covers the interface between a transit management center, or it could be a maintenance center or something like that, and a specific kind of equipment in the field. In this case, one that provides information to travelers. So that’s one type. And we call that sometimes dynamic messages signs. Well, what I was alluding to as an electronic sign. And then another kind of infrastructure that the transit management center could communicate with is for signal priority. There are signals in the field, and I’m not going to spend a lot of time on that. But the center could be communicating with, for example, a set of signals in a signalized intersection to control local traffic. But what I did want you to know is signal priority is handled in detail in Modules 8 and 9 of this overall course about Transit Standards. So that’s our Center to Infrastructure.

And then we have Center to Vehicle, or Center to Traveler. So C2V, as sometimes it is called. And the first one is, let’s talk about the vehicle. And that’s the interface between a transit management center and the vehicles that are operating in the transit agency. So if you think back to the diagram that I showed you earlier, that’s a case of C2V. So you can see the bullets here talk about the different kinds of information that might be exchanged between the transit management center and the vehicle or visa-versa between the vehicle and the center. And then also in C2V is the traveler part of it. So that covers the interfaces between traveler information providers, which could be our transit agency, or it could be an external Information service provider. And then the devices that are used by folks that are traveling. And that could be a smartphone, or just a regular phone with texting. Or something of a landline. So, and these are the kinds of information that would be exchanged that you see on this slide.

And then our final category is Center to Center. And this really covers the interface between a transit management center and other centers. They could be other transit management centers in a region where you have multiple transit providers. Or it could be other centers that are operating like a State department of transportation district, might have a transportation management center, and information is being exchanged between the two. So just a couple of examples on these bullets. Providing multimodal coordination, which I alluded to earlier between some agencies, and you know, other providers in a region. Potentially providing some emergency information to other operation centers if something happens to the transit operations because of an accident or something along those lines. And again, you can think of it the other way around. If the transportation management or traffic management center encounters an accident, it can communicate with the transit management center to say, "Hey, there might be an issue with you operating your vehicles in this area." Also, potentially coordinating with financial institutions for payment. That’s also another module that you can take, where you can learn about the standards for that. And potentially coordinating with law enforcement as well.

So now in thinking about that, how does that help you choose the appropriate standard? Well, the good thing is, you’re going to be looking at a particular class, so our example could be, let’s say, Center to Center. Let’s say that’s an example. If that’s your interest, that’s in the transit management area. And when I click on that in the National ITS Architecture Documentation online, if I say I’m interested in transit management centers, it generates this list of standards that you see on this slide, and it says, "Here are all the standards you should consider as you’re thinking about your system, and what’s the status of each of those standards?" In this case, they’re all published. So that’s a good thing. They’re not under development. Or under any kind of modification. So you kind of have a built-in way of looking at which standards to consider.

So now what I want to do is I want to get into talking about the way standards are structured a little bit. There are a wide variety of standards. All standards are not structured exactly the same. But I want to talk about the key structures that you will see when you’re considering some of the standards, like the ones we saw on the previous slide. So what I want to look at first is—would really cover the Center to Infrastructure area—which really looks at transit management sort of, the communication between the transit management center and infrastructure that’s in the field. And this whole area supports something that we call open system interconnection, which is really an international way of representing a standard that is in that Center to Infrastructure area. And this OSI contains seven layers, and I’m very-—I’m going to very briefly define them. Layer 1 is called the Physical Layer. And that conveys the bits and bytes that are being transmitted that make up really the data stream, but it’s in zeros and ones, if you think about it. That’s the very, the most detailed, very bottom layer. The next layer up is called the Data Layer, or Data Link, you could call it that. And at that layer, the bit streams are organized into packets, and they’re encoded and decoded so that they can be transported to the right pieces of equipment. Layer 3 is the Network, and that’s the layer that provides how the data is going to be rooted in your system. So you’re going to have—your data’s going to be going through a path to go from one technology to another. So that’s the Network layer. Layer 4 is called the Transport Layer. And that actually provides transferring the data. Layer 5 is called the Session Layer. And that establishes, manages, and terminates the connections when those exchanges are taking place, once the transport has taken place. Layer 6 is the Presentation Layer. And that really provides some independence where some of the data that you’re transporting might look different from some of the other data in the same system. So it’s a way of presenting the data so it’s understandable. And then Layer 7 is called the Application Layer, and that supports all the applications and what you’re doing with the data. So that’s our OSI Model.

And we’ve got a little quiz to see how much you picked up on that. So our question is "Which one of these is not a layer within that OSI Model that I just talked about?" So the answer choices are: a) the Application Layer, b) the Data Layer, c) the Service Layer, and d) the Physical Layer. So which one of these does not belong. And you can see Service is actually not a layer. It’s not one of the seven layers that we talked about. But all of the others, a, b, and d are actually layers within that OSI Model.

Okay, let’s talk about one of the most common Vehicle Area Network Standards that we have. So this is one of the first standards that was really ever developed in ITS. And it dealt very well with putting a network onboard a vehicle and being able to plug in our different technologies so they can all speak to each other. So this Vehicle Area Network is analogous to what you’ve heard the term Local Area Network, which you might have in your office, where all the computers are plugged into that network. In this case, all the different onboard technologies are plugged into this Vehicle Area Network, so they can all talk to each other. And it provides a means of transferring the data among those different onboard technologies. So why am I going to be interested in this? Because I want to minimize the cost, again, by using this standard that’s been widely accepted in the field. So that’s a good thing. It gives you some flexibility of adding technologies to your onboard system, and just plugging them into this network, and it uses standard industry electronics as well. It this particular case, this standard only describes two of the lowest layers that we talked about, the Physical layer and the Data layer, or Data link layer. And then it’s used in conjunction with another standard, which is defined at the Application layer. Which is what uses the data that’s being transferred among these different onboard technologies. So that’s really what’s important to recognize in J1708. Now interestingly enough the way standards develop we have the standard SAE J1939, which is actually an updated version of the standard that we just spoke J1708. And that’s because it is—it operates at a higher speed, and it uses something called the Controller Area Network, which is a form of communication, it’s a form of serial communications that was developed for in-vehicle networks, primarily for the automotive industry. When you think about a current automobile, there’s a lot of electronics and a lot of parts that speak to each other. And they operate on those Controller Area Networks. So this was something that was in existence since 1985. Why don’t we utilize it, because a lot of the suppliers already use it. So that, 1939 network is really a successor to the J1708 network. As you can see here on the slide that it basically works the same way. It allows components onboard the vehicle to talk to each other. Just at a higher speed.

So if we pull this apart what does this look like? We have a little diagram here that happens to show the seven layers. In the case of this particular standard, two of them are missing. And that’s just because they’re really not needed in this particular standard. But you can see we’ve got Layer 1, which is the bits and bytes; Layer 2, which is our Data link, it’s putting those bits and bytes into data packets; 3 is the Network, which we need; 4 is the Transport Layer so we can move the packets around where they need to be; and 7 is actually the Application Layer, which is using the data that’s being moved around. So you can see in the diagram that’s basically what it looks like. So it’s using five of the seven layers.

So we’ve got another quiz based on what we just covered. The question is, "Which of these standards are onboard Vehicle Area Network Standards that we spoke about already?" And the answer choice are: SAE J1939 that we just talked about; ISO, which is an international standard, 11898; c) is SAE J1708, which is what we started our discussion about; and D is all of the above. So our correct answer is all of the above because these are all standards that all deal with vehicle area networks. So you can see the other answers are actually correct as well but that’s taken together.

Okay. Let’s talk about another kind of standard and we actually covered this in more detail in modules six and seven. This is a standard, a file standard, if you will, for exchanging information about public transportation schedules and their associated geographic information. And I had already said something about GTFS before. So it defines a common format for schedules and geographic information. And one of the things that it’s really, really powerful in doing is allowing transit authorities to open up their data and to provide data in this format that pretty much everybody knows how to use so that third party developers can be out there developing applications like an itinerary planner. How do I get from point A to point B? So GTFS contains static schedule information for transit agencies that includes things like stop locations, route geometries, stop times. And it uses very simple common delimited text files. There are six mandatory files as you can see on the slide and there are seven optional files that can be utilized. It’s a de facto standard. In fact, when it was first developed it was called the Google transit feed specification. And they changed the name to "general" because it’s so widely accepted by so many suppliers and developers that it’s just used for a wide variety of transit management applications today. Then there is a variation of GTFS which is called GTFS-realtime which takes real time information being generated mostly from a vehicle location system and putting it in a standard format. It’s an extension to GTFS which is why it’s called GTFS-realtime. And it’s designed around the same kinds of ideas for making it easier for suppliers to utilize the information. But it focuses mostly on traveler information. So when someone is traveling they want to know if their vehicle is delayed, are there any changes, are there any alerts on this system. My vehicle is delayed or it’s detoured. Or you want to know where a vehicle is so that’s when you might use GTFS-realtime. The format is based on something called protocol buffers which is also a widely accepted standard and a lot of developers use this particular standard. And then just so you know, the protocol buffers it’s a language and platform neutral mechanism for structuring data. So if you know anything about XML it’s actually like XML but it’s smaller and it’s faster than that. It’s also simpler. So that’s the data structure that it uses. Okay.

There are a number of other relevant standards and they are used in all of our interface classes, are a Center to Center, Center to Vehicle, and Center to Infrastructure, and I’ve listed several of them here and I’ll give just a quick definition of each of them. JSON is Javascript object notation and that’s a data interchange and text format that is completely language independent. So it doesn’t matter what language the software is written in but it uses conventions that are familiar to programmers that program in the C-language. So it’s very easy to use. And protocol buffers I already mentioned those, language neutral, platform neutral sort of like XML but a little bit faster and simpler. And then we have REST which is the representational state transfer. Those applications use what is called HTTP which we’re all familiar with on the Internet to post data or to read data or to also make queries or actually delete data. So that’s what REST is. SOAP is also something that’s simple object access protocol. That defines a way to move XML messages around from point A to point B so you’ll see that being used. And XML is a very simple flexible text format and that’s used quite extensively. And then I just listed some other standards that you see at the international level. And I cover some of those in modules six and seven.

So to summarize our learning objective 2 we talked about three interface classes a couple of times. We talked about the structure of those onboard standards to facilitate the exchange of information among technologies on board a vehicle using the different layers that we talked about. And then we talked about some of these other standards that are used as well. And one thing I want you to remember is we had a little technique for selecting what standards to use when we could actually use the National ITS Architecture to help us choose which standards are the most appropriate. So that’s our learning objective 2.

Learning objective 3 I want to talk a little bit about lifecycle cost which is not something we’ve covered yet and give you just a couple of case studies of using standards in some of the areas that we’ve actually talked about already. So basically, our discussion about lifecycle costs really starts by saying that using standards can really significantly reduce deployment costs. Standards, how did they get developed? Typically by a body of people who understood that exchange of information very, very well so it’s experts. It’s people who know about that data exchange. So you’re really able to use something that was already developed by experts. And you really want to have a wide variety of suppliers. We talked about that before at a lower cost. And you also want to look at a longer lifetime for the system that you’re building and standards provide all of that for you. We did talk a little bit about modularization before in some prior slides, but really what I want to focus on is allowing for an incremental approach to developing your system and deploying it over time. You can’t always do everything at once. You don’t always have the funding to do it all at once. That’s the way our transit technologies are often funded. We only have part of the funding. So you want to put the basics in place and be able to add on to it later on. So having that incremental and modular approach is very, very important. We did talk about the choice of suppliers, how important that is generating composition. And then being able to use standards over and over again, which means they’re well-known in the field and it makes it easier for you when you’re doing a procurement.

Moving on from there I have six other things that I want you to think about when you’re thinking about cost. That’s the complexity of the standard. We really haven’t touched on that yet. Some standards are very complex. We have a standard TCIP which has two modules for you to learn about it in this set of this particular course, and that’s because TCIP part of it can be very complex and part of it can be very simple. But you need to understand the complexity and you may need special expertise to use it. So you need to think about the standard and how complex it is. How available is the standard? And in the case of TCIP it’s been out there for a while. It’s known. Some of the other standards I talked about well-known like 1708 and 1939. I want to know how available it is. What happens if the standard changes, which does happen periodically, are there additional costs to maintain the standard? You need to be aware of that. If you’re not using standards and you’re doing a procurement, how much am I changing my landscape in terms of suppliers and the whole marketplace, and have I introduced more technical issues? Adapting. You may have never used that standard before and your organization may need to get familiar with it and use it moving forward. You may need to put some training in place, for example, so you have to adapt sometimes. And the other thing that a standard can do, which is probably about the only negative thing that I can think of, is that it may provide things that you absolutely don’t need. And you should be mindful of that. I think that’s a very important thing to keep in the back of your mind.

So we’ve got a little quiz based on that last set of slides, and the question is "Which of these issues typically drive the cost associated with using standards?" And our answer choices are: a) adaptation, b) abstraction, c) testing, and d) all of the above. So the correct answer is actually adaptation which we just talked about a little bit. The standard, the organization may need to adapt to the standard and a standard may need to evolve as well. But that’s the correct answer. Abstraction typically, I mentioned this earlier, that standards based products usually have a higher level of sort of this says generality but it’s something that’s commonly used if it’s standards. And so it may be a little more general than what you’re looking for. And then testing which we’re going to spend some time on down the road, here, that doesn’t necessarily drive the costs associated with standards but it does when you’re looking at something that’s proprietary and you’re not using standards it could conceivably increase the costs. We’ll get to talking about testing in detail and all of the above. We already know that A is the correct answer.

Okay. So let’s do a couple of case studies, give you some ideas how this was done in the field. So I’ve had the great fortune to work with this particular transit authority in Grand Rapids, Michigan, pretty progressive. They’ve deployed a series of technologies. And you can see some statistics about them and they had several years ago put a vehicle location system in place. And they wanted to move forward and provide real time information to their customers. What they wanted to do was to put some what we call dynamic message signs or electronic signs in the field in two locations. One at their major transfer facility and one at a smaller transfer facility. And they said okay, so we know that we need to send data from the central system that’s recording all the vehicle locations and how fast the vehicles are moving and all of that, and we need to calculate when the next vehicle is going to arrive at these locations, these transfer points and then we need to put that on a sign. So that’s really what they needed to do. And so they had a vendor and the vendor developed the solution using GTFS, as it turns out. Each sign was equipped with its own sort of PC board that could process real-time—GTFS-realtime as well as static information. And this kind of involved using thirteen separate files that GTFS specifies and that’s a lot of data. And because of the way they defined a solution it took a lot of processing time. At the sign it was very slow. So customers are waiting either at the platform or at the bus stop and they wanted the information. They don’t have to wait for the sign to tell them something. So the vendor suddenly realized our original solution was probably not the best one. We could have used something a little bit faster. What can we do to make it faster? So they kind of took a step back and they said, well first of all there’s a lot of unnecessary data going to the sign. We don’t need all of that data to tell the customer the real time information of when a vehicle is arriving, departing, how far away it is, that kind of thing. So they knew that they really would have to change the amount of data that they were transferring to and from the sign. That was going to improve their solution. So ultimately instead of using GTFS, which provided all of the extraneous data that they didn’t need, they decided to use REST which we identified earlier. It provides sort of the most flexibility and you don’t have to keep sending all of this unnecessary data to the sign and having to have the sign do a lot of the processing. So using that solution gave them the ability to use JSON and XML which are very easy formats to use HTTP. There were a couple of other formats they were able to use. And it was also they were able to filter the data and only look at the data that was necessary to be displayed on that sign. So one of the benefits of using REST is that you can still do the data, so that was something they recognized after they had come up with their initial solution. And this shows a picture of one of the signs at central station in Grand Rapids which is the major transfer point. And it says the bus is on Route 1, which happened to be called the Division Route, that’s the name of it. One of the buses is getting ready to depart and another one is arriving where that sign is in eleven minutes. So that’s a case study there.

So here’s a question related to the case study. And the question is "What de facto standard did ITP or the Grand Rapids vendor use to successfully exchange data between the dispatch center and the dynamic message sign in the field?" And the answer choices are: a) GTFS, b) XML, c) JSON, and d) REST. And if you remember what we just talked about REST is the correct answer. That’s what they ended up using. They didn’t end up using GTFS. They started there but they realized it wasn’t helping them. They didn’t use XML although the data coming out of REST could eventually be in XML format that was not the solution. And then JSON as well. REST was the answer.

So we have another case study. A little bit different, this is talking a little bit about vehicle component monitoring and you can see that this is the Chattanooga Area Regional Transportation Authority which is in Chattanooga, Tennessee. And you can see some statistics there about their operation. And what they were looking to do was to monitor the major components on a vehicle. So engines, transmission, breaking, those kinds of things. They wanted to monitor that because they recognized that if they knew that one of those system was operating out of tolerance they would be able to pull that vehicle off the road before the problem became catastrophic and they’d either have to tow a vehicle or replace an engine or something very costly. So this was what they wanted to do. So in 2009, they implemented this vehicle component monitoring and they made it available to the maintenance staff. And think about it this way it’s by exception. So the maintenance staff wasn’t hearing about every component on every vehicle all of the time. They were only hearing about it when it was a problem, when that component was operating out of tolerance. So they very successfully implemented it. And what did they do? They used a standard the J1939 to provide the component information and how the component was operating out to the maintenance system. So that’s the standard that they chose to use because it really facilitated exchanging that component data with maintenance. So that’s another example of using a standard. So how did they select 1939? This is a photo of part of their dispatch facility. They went through and they said we don’t want a standard that hasn’t really been out in the field and used. We want one that’s been there for a while. We want one that the vendors are going to use. So all of those factors that I mentioned earlier they looked at the applicability to their needs, was it available, mature, and had vendors accepted it? And so when they chose that standard when they wrote their specifications to purchase this system they in their procurement they discussed the standard and talked about it in the appropriate location, in the procurement documentation, and the specifications. And in your student supplement, you actually have the language that they used to show you how they used that standard in a procurement, in the procurement documents.

So we have a couple of other cases here and this is Tri-Met, which is in Portland, Oregon and you can see they have a very large number of vehicles that operate. And they’re looking at using ITS standards. They’ve been looking at it for a quite a while. And what they wanted to do was they wanted to do some integration between a new system that we’re buying and an old system that was already operating. So that’s kind of they said, "Gee, are there any standards that would facilitate that integration?" At the time that they were doing this there were no standards for LED signs which is what they were implementing. So this is years ago. This was their first set of LED signs that showed real time information. But there were no standards for that, no standards to exchange information. And so it forced them to consider some of those electronic sign vendors that had their own proprietary protocols. So what they did was they said, well, this may not exist now but we’re going to force it to exist so they required the sign vendors to actually interface with some protocols making it easier for them in the future when those signs needed to be replaced. So there was a definite advantage to them to actually using kind of forcing the issue, I guess, and requiring the sign vendors to use those protocols.

Another case has to do with a fare collection system in the greater Seattle area, which is also called the Central Puget Sound Area, seven different transit authorities all collected fares a little bit differently. This is a project that took a fairly long time to implement. And the experience of trying to get one regional fare system implemented showed that modifying or customizing a particular technology what comes with that is a greater risk because you’re customizing something. It’s not necessarily standard off the shelf. And so in order to meet the needs of these seven agencies they really had to look at something that was a customized solution. There was really nothing out there that was going to meet the needs of the agency. Remember, that’s where it all starts. Here we have seven of them. So what they did was they had to customize a particular display unit that they were using on board. So in this case, customization was the right answer, but they recognized when they went that route, that they were some more risks involved with that and that was something they were probably going to pay a little more for down the road.

And then we jump back to Tri-Met for a minute talking about new software that they were implementing and so a little bit different than the sign case but similar in the sense that they were integrating a new system with an old system. What they did was they had a new system estimate real time information. And so that was the new system and they were able to use, in this case, some of their existing legacy systems. And because they were using some of the TCP/IP standards that we talked about before they were able to save on some development case. All of these last three cases are all documented online and you can see in your student supplement where to go to see the information about them.

So we’ve got a quiz question here. And the question is "Does complying with standards and using commercial off-the-shelf technology help make it easier to integrate existing systems with new ones?" So "existing", we used the word "legacy" before, we talked about that a little bit. And this is a yes/no question. So answer choice A is yes, answer choice B is no. So the correct answer is yes combined with standards and using commercial off-the-shelf systems can really help save costs minimize the risk. It’s not always possible to do it but that is the correct answer. If you’re going to be modifying or customizing you’re going to raise the risk and potentially increase the cost as well.

So to summarize our learning objective 3 we covered quite a bit of material here but on the slide I showed you those six main areas to consider when you’re looking at lifecycle cost of the system and using standards. And the cost of standards can be attributed to these six areas. So that’s something that’s to keep in mind. And we talked about how using standards can really significantly reduce the actual deployment costs as well. And then we talked about some issues with integrating with legacy systems.

So that’s our summary of learning objective 4. And now we’re on the home stretch learning objective 4 talks about how to actually read a standard. What kinds of flexibility do we have when we apply standards? How do we incorporate it in a specification? Testing. We’re going to talk a bit about that because that’s really important. How do I know that I’ve conformed with a standard? How do I actually know that? I want to talk briefly about intellectual property which is an issue that comes up all of the time.

So what’s the first thing we need to recognize? We need to recognize that different standards are structured in different ways. They’re not all the same. For example, when I talked about GTFS, GTFS doesn’t use the OSI layers that the on-board vehicle network standards do. And the on-board vehicle area network standards don’t use any of the other standards that we talked about like XML or anything like that. So I gave you some examples here of how they’re structured differently just so you keep that in the back of your mind. And what do you really need to understand? Not so much the bits and bytes, but you need to understand how to identify the most appropriate standard, based on user needs so that goes back to one of our first things in learning objective 2 is making sure that you’ve identified the user needs. And then really defining that standard in a specification and understanding how it’s going to be tested to determine compliance. So those are the things we’re going to talk about. If you were to get on the web and say "Gee, I really want to look at what J1939 actually looks like", so what it looks like is a series of documents. And they’re numbered. You can see the examples here. And so it’s a series of documents that deal with different aspects of the standard. And you can see in this list that some of these documents just deal with one layer of that OSI model. So kind of halfway down this list we see Data Link Layer. That’s the Data Layer or layer two. And you can see there’s a separate document that talks about that layer. So that’s really what you want to understand as well as some other pieces of information. For example, most messages that are defined by the J1939 standard are actually intended to be available to all of the equipment on-board. So that means that the data is transmitted without regard to where it’s going. It’s just available to all of the technologies, all of the systems on board. So that permits any device to basically be plugged into the network, that’s the beauty of using this standard. And if some other system is generating some data that it needs, it’s going to be readily available. So that’s something to think about as well in this particular example of J1939.

All right, what does GTFS actually look like? You really look at what it looks like remember, it’s basically a bunch of text files. So pretty easy to look at. Here’s an example of all of the file names. The ones that are bolded are the ones that are required by GTFS and the ones that are not in bold are optional. And so it’s a bunch of text files and here’s what a couple of them look like. An agency text file looks like that. It’s got an agency ID. It’s got a name. It’s got maybe a website address, the time zone, the phone number, and the language. So it’s a text file separated by commas. The stops file similar. It’s information separated by commas, the route spot, et cetera. So that’s what the GTFS standard looks like. It’s comma delimited text so it’s pretty easy. So we know that different standards look different and they’re read differently. Okay.

Let’s talk a little bit about flexibility. And this is important because you can become easily swayed by the way vendors sometimes provide information about their products. So let’s talk about that. Standards aren’t perfect. They actually do change sometimes over time and you just need to be well versed. If you’re going to use a standard be up on it. Make sure you understand what’s going on with it. You can take a standard and you can actually add your own extensions to it if you want, but if you do that you need to remember that you’ve done that because staff is going to change in the agency and the same people who wrote those extensions might not be there in the future, and how are you going to know what those extensions were? So you really, everything needs to be well documented if you decide you’re going to extend a standard. Then here’s where the vendors come in. So a lot of vendors they have products, they’ve been out in the field, and they’re going to tell you we conform to all of these different standards. But how do you know that? Have you seen their testing program? Have you witnessed actual tests that show that the standards that you’ve identified are—their products actually comply with that? So what we recommend is that you stay away from—vendors have these spec sheets and they say, in this product it complies with these or conforms to these standards. Well, you don’t really know that. It’s just on a piece of paper. So we really try to steer you away from just saying "Oh well look at that data sheet that product it complies with all of the standards I care about." Do you really know that? Probably not. So we try to steer you away from that. What you really need to stick to are what are the functions that you need to meet the user needs and the concept of operations, which is defined very early on in our Vee model. That’s on the upper left-hand side. So stick to that. You will eventually know whether that product conforms to the standards that you said they needed to, eventually. And here we’re just trying to steer away from a lot of proprietary features and objects. So.

All right, and we’ve got a little quiz. "A good approach to defining the functions of your system is to select items from a manufacturer’s data sheet." So remembering what I just said this is a true/false question. Answer choice A is true. Answer choice B is false. And the correct answer is false. Again, they may claim this but you may not want to believe it. So you really shouldn’t be cherry-picking from their datasheets.

Okay. Now, in incorporating a standard into a specification. In the concept of operations, again, upper left hand side of our Vee model for systems engineering, that’s where it describes what you want the systems to do. In your specification you’re saying "Well what are my expectations for my system?" "What do I expect it to do?" And you start with the concept of operations, and then you move into something called functional requirements where you’re saying "This is what I want the system to do." I haven’t yet said exactly how I’m going to do it but is there a possibility here to use standards? And the answer is absolutely, yes. But if I’m going to do that I need to understand how the standards are going to be tested. So I need to think about a testing program and you’re thinking well, "Gee, I haven’t even built it yet. Why am I going to think about it now?" But that makes it easier when you are actually testing—you already have a testing program defined. So what are some of the things that—this is actually showing what I just said in the flow chart. I know some people are not fond of flow charts. I start with my concept of operations which says what you want the system to do. And then I say okay requirements wise I have to document functionally what it’s going to do. But then I should be developing some test procedures. I should be thinking about that, or I should be asking a vendor to do that so that I can verify that things are going to be tested properly and that the system is going to conform to the standards that I identified. So that’s what I’m doing. All right, so this is a lot of words. I don’t expect you to read it. It’s in your student supplement. What this shows is some of the language that was used in that CARTA example for their component monitoring and it just shows how the standards were actually incorporated into the specifications language. So I wanted to give you that. They went through the process that we just talked about. So that’s how they identified it and you can look at it in detail in the student supplement.

Testing. One of the last things we’ll cover is what are we looking for? That the system is performing the way we expected. It’s robust. It behaves the way we expect it, it does what we think it was supposed to do, and potentially, if it’s supposed to be interoperable with something, we have to test that as well. So one term that I want you think about which is important here is conformance. How I know that I’ve conformed to a standard. There’s conformance testing which is testing to determine if the implementation or the deployment actually meets the requirements of the standard. So what you need to make sure is that you have a testing program that’s going to test for every aspect of that standard and that you’ve conformed to the standard. And so in the case of conformance testing there’s other testing that goes on which is the testing the performance, and the robustness, and the behavior, and all of that. But conformance testing is a little bit different than just looking at the performance because there may not be a standard associated with performance. So the conformance testing is different in that the requirements of the criteria for conformance has to be specified in your specification. So you have to say this is the criteria by which we will determine conformance. If you don’t say that, it’s open to interpretation. So keep that term in the back of your mind. We need to prove beyond any shadow of a doubt that the implementation conforms with that standard. Now, there is another kind of testing besides conformance testing, which is called falsification testing which is, in fact, what a lot of people do and that subjects a system to various combinations of legal and illegal inputs. So if you’re testing a piece of software and it says you need to enter a number, falsification testing might say I’m going to enter the letter A and see what happens. That’s falsification testing. So it compares the output to what’s expected. What you would expect there is that the system will not accept the letter A because it’s not a number. So if you find errors you can deduce that the implementation doesn’t conform to the specification but how can you test everything that way? And that’s why conformance testing is very, very important. All right, so you can have, again, we said you have to have a conformance clause in your specification. And you can specify minimum requirements for functions, specific values that you’re looking for. And it’s possible you could extend the standard but, again, you have to document that and then you have to document how you’re going to do the conformance tools. And what are the overall benefits? This goes way back to what we talked about in learning objective two. You’re producing a quality system. It’s going to be interoperable if that’s the way you’ve set it up. You’re going to ensure that interoperability. And you’re going to make sure that you had the best competition around building your system. You’ve got the best possible product that you could get. So in conformance testing we’ve got two major components. You need the tools. Sometimes there are test suites or, you know, tools you can use. And then you need the testing program that probably has some applications in it that will, again, ensure that you’re showing conformance and that you’re not just doing the falsification testing. So the end of this is you’re going to specify a standard. What’s the tool that you’re going to use to do your conformance testing? What are your test procedures? You need to review those. And then who’s actually going to do the testing? Is it going to be your organization? Is it going to be the vendor? Is it going to be a third party, maybe? That’s done oftentimes with transit technology.

All right, so we’ve got another quiz. "Which of the following elements are included in a conformance testing program?" We talked about that a bit. The answer choices are: a) standard or a specification, b) procedures for testing, c) organizations to do the testing; issue certificates of validation and arbitrate disputes, so that’s the organization that are going to do that, and answer choice D is all of the above. The correct answer is d) all, of the above that you need all of these elements for a conformance testing program. All of them constitute that.

And then briefly about standards and intellectual property a very, very important topic. You could probably take an entire course about this. But where we have such a competitive industry and companies invest significantly in development of products. This is something that’s very, very important. They want to protect their products with intellectual property rights, which are pretty common, but what are the kinds of things that you need to be concerned about when you’re dealing with that, is that standards developments anticipate technology typically rather than follow it. So there are times when there are going to be conflicts between the standards and intellectual property or patents and we’ve seen that in our industry in some very strange ways. We have some patent trolling that has gone on with some real time traveler information systems. Most of that has been shut down by now. But there are some resources where you can look that up. But you need to really be aware that if there’s a patented technology that’s incorporated in a standard without the patent holder agreeing to sharing it you could be in—you could really have a conflict there. And the patent holder may be the only entity that can really comply with that standard so it makes it a bit complex. So you need to really verify whether if an essential patent for which you need a license is really—you really need that—and whether you’re going to be granted a license. You really need to understand that. Generally, you can find that out from the standards development organization. And then there might be some licensing that you might have to pay for so you need to look at that cost. And then you may be looking at something that’s protected in the end. So you just need to be aware if that’s incorporated in the standard. And then finally, you want to look at whether these things are really essential. If they’re really essential the patent holders might pool them where they’re readily available. And then again, you might be required to license something where there’s a cost associated with it. So when you’re looking at selecting the most appropriate standards—so I’m going back a ways there to learning objective 2—this is where you want to look at whether there’s something that’s patented within a standard so that you understand at the beginning of your development process whether you’re going to have to pay anything to actually license it or if the licensing is even required. You really need to know that up front.

So the summary of learning objective 4 is we’ve got several components that we looked at incorporating standards into procurement, what a conformance testing program includes, and what you need to look at if there’s really patents that you may have to obtain a license, do you really need them? Is it really required?

So now, to summarize the whole module, we have sort of a little fill in the blank quiz for you. What have we really learned here? And it kind of goes step by step throughout what we covered in each of our learning objectives. So service packages represent slices of the blank that address specific services like surface street control. And the blank is physical architecture. We talked about that with the National ITS Architecture. Two, the use of the standards is desirable for both business and technical reasons. The principle benefits of standards are as follows; and we’ve got blanks for A, B, and C. So the principle benefits if you remember those three major bullets, one is protection of your investment. B is interoperability. And C is improved quality and value. We spoke about all three of those. Three, blank provided a starting point for identifying the ITS standards and other resources. And our deployment oriented categories that focus on commonly deployed ITS services or systems. And that’s the application areas that we talked about within the interface categories. Four, using standards in a deployment can greatly blank component development costs especially if standardized off-the-shelf components are available. It significantly reduces the development costs. And five, the requirements or criteria for blank must be specified in the standard or specification and that’s our conformance which we’ve spent quite a bit of time talking about previously. So that summarizes what we’ve learned in the course.

And we have quite a bit of resources that are actually listed quite a bit more than just these that are listed in the student supplement.

The next course modules which you saw in a few of those flow charts, which types of labor categories would deal with what modules coming up, the next several we mentioned 2 for traveler information module six and seven, part one, which is an overview of transit traveler information. And then module seven which speaks specifically to the standards. And then module nine which is the arterial management and signal priority. Module ten which is about fare payment systems and standards. And module eleven which is the connected vehicle environment which is becoming very important to understand.

So at this point I want to thank you very much for completing Module 5. And give you the opportunity to provide some feedback which we would really appreciate as we move forward with this module. Thank you very much.

#### End of Module5_Final.mp4 ####