ITS Transit Standards Professional Capacity Building Program

Module 7: Traveler Information 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: 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 re-designed ITS transit standards training program, of which this module is apart. 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 programs specific to transit and industry domains 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 systems safer, smarter, and greener, which includes deliverability for us all.

This series of online courses based on ITS transit standards is in addition to a thirty-five 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.

Jeff Spencer: 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.

Carol Schweiger: I want to welcome everybody to Module 7 and before we get started I would like to introduce this particular slide that you see in front of you that says, "Activity." Throughout the presentation this activity slide is going to appear indicating that there is a multiple choice pop quiz following this slide. You’ll use your computer mouse to select your answer. There is only one correct answer and selecting the "Submit" button will record your answer and the "Clear" button will remove the answer if you want to change it to another answer. You’ll receive instant feedback on your answer choice. And at the end of the webinar I’ll remind you that it’ll be great if you can complete the post-course feedback form.

Welcome, again, to Module 7, which is "Traveler Information Standards Part 2 of 2." And my name is Carol Schweiger and I’m the president of Schweiger Consulting LLC. I have about thirty-five years of experience in public transit consulting, most of which has been in the area of intelligent transportation systems or transit technology. And I’ve been involved in developing strategic plans, technology plans for transportation agencies, in developing specifications, in helping with procurement, assisting implementation, conducting research, and doing just this kind of training that we’re doing today.

So with that, let’s move right into the target audience, which I want to spend just a couple minutes talking about. So our target audience are mostly technical staff for this particular module because it is a part 2 of 2. Presumably, you’ve already taken Module 6, which is "Traveler Information Standards, Part 1 of 2." So you can see here this is mostly a technical audience. So it’d be technical staff from the transit agency in various disciplines; some regional traveler information specialist that’s maybe located at, for example, a state department of transportation or a transportation management center; vendors and consultants that will be assisting agencies in developing traveler information systems; the application developer community, which we’re going to be covering quite a bit because a lot of the standards that are being used for traveler information are to facilitate application developers use of the underlying data; and then also procurement and grant staff and this is an optional module for those folks.

So if we look at the recommended prerequisites I’m just going to cover those four—the project manager, the project engineer. The decision maker—it’s not required for the decision maker to actually take this particular module. You can see on this slide Module 1 was the overall introduction to transit standards. Modules 2 and 5 were specifically about transit management, and it was a Part 1 of 2 and a Part 2 of 2. Module 3 and 4 are about the transit communications interface profiles standard, Part 1 and 2. And then Module 6 was immediately preceding this particular module. So what we’re looking for as a pre-requisite here is a basic understanding of the transit portions of the National ITS Architecture as well as how traveler information is generated and that’s something that’s covered a fair amount in Module 6. And then also an understanding of the technology that’s used to generate that traveler information.

So just looking at the curriculum paths for the project manager you can see here the box in the lower left in blue that’s highlighted in red is Part 2 of 2 and you can see that the recommended prerequisites are all in green and we spoke of those before. One of the prerequisites that was not on that prior slide was Module 8, which is the first part of "Arterial Management and Transit Signal Priority." And it would be really good if folks taking this particular module had the opportunity to take that. So this is for the project manager. And for the project engineer we have one more slide that’s in green and that’s Part 2 of 2 of the "Arterial Management and Transit Signal Priority", which is Module 9.

So with that, we’re going to get right into our learning objectives for this particular module. And we have four of them. The first one is to review very quickly some key concepts that were discussed in Module 6 just as a little bit of a refresher. The second learning objective is to get into the structure of the traveler information standards that we’re going to be speaking about. Learning objective 3 is to be able to select the appropriate standards and understand what they look like from the inside. So it’s taking a deeper dive. And then learning objective 4 is to illustrate how you might incorporate a standard in procurement. It also speaks to issues about testing as well as some items about intellectual property rights.

So let’s go right into learning objective 1. And here we’re just going to be summarizing the key concepts from Module 6, briefly reviewing the traveler information taxonomy, the relationships, and the exchanges among the traveler information technology, and the transit management technologies—and just speaking very briefly about systems engineering.

So if you recall from Module 6 it covers the customer-facing technologies that provide the public with information about trip planning in real-time operation. There are four categories of traveler information as you may recall: pre-trip systems, which include both proactive and interactive information. The proactive information is regardless of what the user needs. It’s basically information that’s broadcast to the public. "Interactive" is that information that’s face based physically on what the user is looking for. So that’s our pre-trip. Second category are on-board systems; for example, automatic vehicle announcements that are made on board the vehicle. The third category are wayside systems, which can provide both static and real-time information at the wayside, like in stops or stations or at business buildings. And then the fourth category are third-party applications and social media. So each of these technologies we’ve discussed in a fair amount of detail in Module 6, so we’re not going to repeat all of that.

What we are going to talk about briefly are the dependencies between the traveler information and some transit management information. So if you look at this particular matrix, we have several categories of systems or technologies that we touched on in Module 6. One is on-board automated voice announcements. And those are dependent upon two pieces of information that are considered transit management standards: the AVL system and route and vehicle schedule data. Then we have en-route and wayside information that I just mentioned, which is dependent upon the same systems that we just mentioned as well as the computer generated dispatch system and data communications technologies. We have an on-board Internet access for passengers, which is based on data communications technologies. We talked a little bit about some of the N11 systems that are used for transit information: 511, 311, and 211 as well as Google Transit. Those are dependent upon open data. And the third-party smartphone applications are also dependent upon open data.

So now we come to our first activity. And the question here is "On-board Automated Voice Announcements, or AVA, are dependent upon which of these choices?" And we have five choices: answer A is AVA system, answer B is APC system—and you may recall from Module 2 and 5 an APC system is an automatic passenger counting system, answer C is route and vehicle schedule data, answer D is all of the above, and answer E is just items A and C. So now let’s talk about the correct answer. Correct answer is "E." It’s items "A" and "C": On-board automated voice announcements, AVA, are dependent upon an AVA system and route and vehicle schedule data.

So running down the other answers "A" is one of the technologies on which an AVA system is dependent. "B" is actually incorrect: Automatic passenger counting systems are not used in on-board AVA system; they’re used to count boarding and alighting, which you may recall from Transit Management Module. Item "C" is also one of the technologies and Item "D" is incorrect because the AVA system is dependent only on Items "A" and "C."

Okay, so moving on, we have a diagram here, which really shows the context for traveler information data exchanges and at this point generally the diagram shows the collection of data from individual transit vehicles and the transit management center feeding data from customer information servers, processing that data, and then disseminating it to users. So that’s moving from left to right on the chart. So on the far left you have some CAD-AVL systems that show operations of each of these modes to provide real-time information to that process to the right, which is called "information reconciliation." That process takes input from some of the other databases, like scheduling, planning, marketing, and customer databases. Once all that information is compiled and reconciled it’s sent to what we call a data feed layer to a real-time customer information server. That server interfaces with two things: One is the monitoring and the feedback layer and that really looks at the performance standards and also feedback of the information that you’re providing for the public; and then to the right we have disseminating the real-time information to follow these various medias that the user is going to have, including personal devices, like a smartphone, for example; or the information is disseminated to an information service provider or ISP. So you might be accessing that tool of 511 systems. Then information could be provided to third parties through open data and there’ll be an application that someone can use to access that. And then within the transit agency that information is being disseminated could be to—for example—the website, the transit agency website, or dynamic message signs, or interactive voice response. And one thing I just wanted to mention: There’s a full-sized version of this particular diagram in the student supplement.

Now you may recall this particular graphic that’s from Module 2 and 5 of Transit Management Standards. So this is an example of the relationships among some of the technologies. And the reason why I show this again is just for you to focus on those items that are within the dark dotted lines in the diagram. And what’s contained within those lines are the portions of this chart that deal specifically with traveler information. So you can see some of the components of the central server communicates with, for example, third-party developers or the website and so that’s where the information is being generated for the public. It’s also being made available through the transit agency’s own system. Likewise, in this next diagram, which shows the relationships among on-board technologies, I’ve done the same thing where within the dark dotted lines there’s traveler information specific elements of the system. So you can see there’s an on-board or interior dynamic message sign, there’s a public address system; and those are controlled by the voice announcement controller. So that would be providing the traveler information on-board.

So, again, a quick review of service packages just to remind you, the service packages represent slices of the physical ITS architecture that address specific services. And where we’re going to focus on are traveler information services. So there are 12 traveler information-related service packages within the National ITS Architecture. And the one that’s most relevant to what we’re going to be speaking about today is the transit traveler information service package. And that is shown here on this particular chart where we show there are four—actually, there are five entities—that are exchanging information in the purple boxes. It’s the one in the center is the transit management center and it’s exchanging information with the transit vehicle on the right, and information service provider on the left, and purple information access on top of that box and then, below it, the remote traveler support. So those are all opportunities for exchanging information. And then you can also see the yellow ovals that are connected to some of the boxes are actual entities within the architecture, like the traveler and media or an information service provider outside the architecture; or other transit management centers—like for other regional agencies—they may also be providing that traveler information.

So that really wraps up learning objective 1, a quick summary of Module 6. And so we talked about the fact that the dependencies on other technologies for our traveler information systems that we’re talking about. We actually didn’t really talk a lot about the "Vee", because that—the "Vee" Model was discussed quite a bit in Module 6; that’s the systems engineering process that facilitates the development and implementation of traveler information systems and we’re going to come back to that in a little bit. And then there are 12 traveler information service packages within the National ITS Architecture.

So let’s move right into learning objective 2 where we sort of take our first dive into the actual standards and what they look like. So we’re illustrating here the structure and use of data exchange standards for traveler information systems. I’m going to describe how the standards can be used to meet user needs. We’re going to start off with that and then we’re going to talk about the structure.

So let’s start off by just defining what does the user need and why do we care about this as we’re starting to develop traveler information? So one definition of user need is "It’s a user requirement for a system that a user believes would solve a problem experienced by the user." So that’s saying the word "user" three times, and the reason why we’re using it three times in that definition is because it’s very, very important. You’re not going to develop a system without there being a need for it. So this highlights the fact that everything in systems development is driven by user needs. It’s not driven by "I like that technology. I’d like to deploy this." It’s driven by an actual need for it. So users are declaring what they want from the intended system and the system has to satisfy those needs. And that’s part of the systems engineering process.

So there clearly are benefits—direct benefits—from using standards and we’ve talked about that a fair amount in prior modules. But just as a review we’re really talking about primarily a tool for reducing complexity and potentially cost in a procurement; developing and managing the systems, making it easier to do that; making sure there’s a good choice of suppliers in the industry; and really recognizing that those standards can be strategic to the performance of these systems that you’re building.

So let’s talk about an example so you can kind of say, "Yeah, that’s what we were just talking about are clear benefits." So our example is that a transit agency wants to provide their real-time data to developers to create some applications for smartphones, for example. So providing that open data is greatly facilitated by using standards, it makes it a lot easier for the developers to create the applications if they can base their applications on standards. So an agency might be able to satisfy that need by providing the open data in a standard format here requiring their data from the automatic vehicle location system, which generates that information in a format that’s called the General Transit Feed Specification real-time format, which by the way is considered a de facto standard. It is a format, but it’s been so widely accepted by agencies that it’s really a de facto standard. So the AVL data that’s driving the development of these applications could be provided in any format, but it makes it much easier for the developers if it’s provided in that GTFS-realtime format or standard. So that’s our example.

So we’re going to run through just a couple of ideas about why standards really work well in this particular environment. And so the first is talking about the value. What value do the standards provide? They protect your investment. Standards-based products are typically available from a number of suppliers and if there are a number of suppliers the cost is probably going to be lower. And using the standards, your product may have a longer lifetime. There are some other advantages, some of which you’re going to recognize from Module 6 that we touched on very briefly. One is modularization and incremental deployment. If you use a standard it’s going to allow for an incremental approach to adopting that standard that will allow users to spread out their investment over an extended period of time. And the reason why this is very, very critical in public transit is funding for deploying an entire system may not be made available all at once. You may actually have to deploy it in stages. So, again, using a standard is going to facilitate that. And then we talked about the choice of suppliers: You don’t want to be locked into one specific supplier; you want to have a variety of suppliers that are available to you. And then re-use: Once you use a standard and define in it in the specifications you can use it again if you need to, to deploy—to actually procure another system; so you’re actually saving money in that sense as well.

A little more on the value proposition in talking about interoperability. If you use standards you’re going to make it a lot easier to interface with both internal and external systems, because systems typically pull data from a number of places and you recognize that in that chart that I showed you about how traveler information is developed and disseminated. You can see there were a wide variety of databases. And so standards are going to facilitate that exchange of information. We talked about evolution already and being able to stage an implementation. And then one thing we didn’t talk a lot about is reducing the cost for managing data. So standards are going to make it easier for you to manage the data and they’re going to give you more tools to use to be able to manage the data.

Our final discussion or slide about value proposition is the fact that you’re improving the quality of the information that you’re dealing with as well as the system that you’re developing. So standards-based products really represent components that have been proven and have evolved over time. And so there’s a higher level of generality others—versus using, like, a one-off solution, developing something that’s a custom solution. And that’s because they deal with the more general level that you’d typically need and they’ve been extensively tested in a number of different environments. So it reduces your risk, both on the business and the technical side. It’s typically—they’re more robust systems that you’re building based on standards. They’ve been very well tested, so you’re testing, when you get to that point after you’ve built the system, it’s going to be a little bit easier and you’re also going to have some tools available to use to do the testing as well as look at whether you’re conforming with the standard. Modularization, we’ve already talked about and we’ve already talked about reuse. So I’m not going to mention those again.

So what we’re really looking at is how do you evaluate a standard to know whether you should use it or not? And you need to do that from two perspectives. One is technical: How well does a standard represent the problem and what technologies does it use? And then, on the organizational side, you need to be looking at how mature the standard is. Is it actively supported by vendors and adopted by the industry and how long do you think it’ll last? Was it just adopted? Has it been out in the field for a long time? What’s the exact situation?

So that leads us directly into a discussion about identifying the most appropriate standards for your system. So on this slide I wanted to just very, very briefly mention some ideas for use to use as you’re trying to identify the appropriate standard. And one thing that we’re going to cover in the next several slides are something called application areas. And an application area is a pretty good decision of what are called interface classes, which is how the National ITS Architecture is subdivided. An interface class is defined by the type of systems at each end of the communications path when you’re exchanging data. So what’s at each end? We might have a center, like a transit center; we might have some infrastructure and the field; we might have a vehicle; or we might have a traveler. So those interface classes that we’re going to briefly talk about are listed here on the slide. We’re going to get into a little more detail about them: center to infrastructure, center to vehicle or a traveler, and center to center. And one thing I did want to mention is that one of those application areas would include bi-directional communication. So it may say "center to infrastructure", but it actually also means "infrastructure to center." So it’s bi-directional. So here, on our example on our slide, is an application area within center to infrastructure, which would be communication between the transit dispatch center and dynamic message signs that are located at a stop. That’s an example and that’s a two-way communication. So let’s jump into each of these interface classes so we can talk about the application areas or the functions.

So the first one is center to infrastructure. And what’s related to transit here is divided into two parts: One is dynamic message signs and the other one is transit signal priority. I’m not going to cover the signal priority, because there are actually two modules—Module 8 and Module 9—that deal specifically with transit signal priority. So focusing on the dynamic message sign. These signs might be permanently installed or they might be portable devices and they could use a variety of technologies, like, flip panels, or liquid crystal display, or a light-emitting diode that can show messages. What you typically use these signs for is to provide riders with real-time information like when is the next vehicle going to arrive and other kinds of alerts or advisories. So that’s in our center-to-infrastructure application areas.

And then there’s center to vehicle—let’s deal with the vehicles first. So the capabilities that are discussed here are the interfaces between a transit management center and a vehicle. So it could be a regular fixed route vehicle, it could be a paratransit vehicle, but what I want you to think about are what are some of the functions of a traveler information system that are going on that would mean that you’d want to have a data exchange between the center and the vehicle. So that could be the automatic vehicle location information—the vehicle is operating and you want to continually be communicating that between the vehicle and the transit management center. Remember that’s underlying traveler information. And then you might be collecting some operational information about the vehicle itself, while maintaining the vehicle. There may be traveler information that you’re providing onboard the vehicle, so that would be transferred from the transit management center. And then you can see some of the other examples here.

Now if we move toward the center-to-traveler application areas that are related to transit, these are the interfaces between traveler information providers and the devices that you might be using as a traveler. So it could be provided pre-trip or en route, using equipment, onboard equipment like I just mentioned, the prior example. It could be using a personal computer, or a smartphone, or a kiosk, or some kind of equipment at a transit stop or a station. And you can see here, again, thinking functionally, what kinds of information would be provided. It would be the ones that are shown on this slide.

And then finally, we have the center-to-center application area functions that are related to transit, and this covers the interface between transit management center and other centers, which could be other transit management centers, or it could be a traffic management center, a transportation management center, where all the traveler information is all consolidated and then disseminated out to the public. So you can see here the types of information that might be provided in this particular application area.

So, what I want to sort of finish up this discussion about application areas is, again, that provides the starting point for you to identify specific ITS standards that you might want to consider using in your system development. How do you do that? Well, you go to the USDOT’s ITS Standards website and you look at the specific application area that you’re interested in, and there’s an ability to click on something that says Standards, and this will identify for you the most appropriate traveler information standards.

So we have a little example in transit traveler information. That happens to be in the interface class that’s called center to center, and we might take a look at that. On the right-hand side of the slide, it shows you all of the potential standards that you could be considering. So it gives you a list and you can select from that list the standards that you think will be most appropriate.

So now that you’ve actually thought about the most appropriate standards, I want to talk a little bit about the structure of some of the traveler information standards. I’m going to cover the ones that are most used in our industry, and I’m going to start with GTFS, which we introduced in Module 6. That’s called the General Transit Feed Specification, and it was originally developed by Google and it defines a common format for public transportation schedules and associated geographic information. If you have a GTFS feed, that allows public transit agencies to publish their static data for developers to use to develop any kind of third-party application. So the static information—there’s two types of static information, which, by the way, is just represented in a comma-delimited text form, so it’s very easy to write and it’s very easy to interpret. So there’s the two types of information. One is a set of mandatory files. There are six mandatory files that describe the agency, the transit stops, the routes, trips, stop times, and a calendar; and then there are seven optional files, which speak to calendar dates, like dates of service, the attributes of fare, the rules associated with paying a fare, shapes, frequencies, transfers, and information about the actual feed. The success of GTFS in our market, in our transit market, has led to really what we consider an unprecedented adoption rate by transit agencies, and in the student supplement we actually show how many unlinked passenger trips are covered by GTFS data. The other thing to note is that the adoption of GTFS as a kind of de facto standard has substantially outpaced the use of TCIP and the Service Interface for Real-Time information, or SIRI, standard which I’m going to talk about in a couple of minutes. So GTFS is widely adopted.

An extension of GTFS is also widely adopted, and that’s called GTFS-realtime. That allows public transit agencies to provide real-time updates about their fleet and their operations to application developers, and it was designed around being easy to use and it’s interoperable with GTFS, which we just talked about, and it focuses on passenger information. It was designed through a partnership of some of the live transit updates, which was done by Google, the partner agencies, and a number of developers that worked with them, and it was initially introduced in August of 2011. The kinds of information it supports are, again, real-time in nature, trip updates, like a trip’s been canceled or delayed; service alerts, like a trip has been short-termed or there’s something going on with the system in its entirety; and then some information about where vehicles are located and how they’re operating. There’s no constraint on how frequently or the exact method of providing this feed, but it generally is done in a particular standard, which I’ll talk about. It’s called protocol buffers, which is similar to XML but it’s a little bit smaller than XML, faster, and a little bit simpler, and we’re going to look at an example of that in a little bit when we do our deeper dive into what the standards look like.

Then we have the SIRI standard, which I already mentioned, and it’s called Service Interface for Real-Time Information, or SIRI. It’s not the Siri on your iPhone; it’s a different Siri. So it’s an XML protocol for exchanging real-time information. It was developed by the European Committee for Standardization, which is abbreviated CEN—that’s the French abbreviation—and it was developed with representatives from France, Germany, Scandinavia, and the U.K., and it was originally published as a standard in October of 2006, and on this slide you can see there are five parts to the standard and these are the ones that you can obtain the documentation about.

So a little bit more about SIRI. Again, it uses XML. It’s a modularized set of discrete functional services, so you can pick and choose the services that most specifically apply to you, and in one of our case studies I’m going to give you an example of that. The services cover planned and real-time timetable exchange, vehicle activity at stops, vehicle movements like we’ve talked about already, and information to assist in providing reliable connections between vehicles. All of the services that we’re going to talk about are provided over a standardized communications layer, and that layer really has two parts to it that we’re going to talk about a little bit later on: a layer that actually provides immediate responses to a request for information, and the other part of it is actually dealing with people who subscribe to specific information. So we’re going to talk about that in a little bit.

So, XML is used to define the messages and there’s a separation between how the message is transported and the actual message itself. So XML documents are used. There’s some other formats that can be used to make that data exchange, but it’s pretty straightforward using XML. And then there’s a consistent set of the protocols I mentioned before, two of those sort of interactions or exchanges. One is for a request and response, so that means that someone is simply requesting information and SIRI needs to respond to that request. The other is where someone subscribes to a specific type of information and SIRI is providing that specific information based on that subscription alone.

Okay. Another standard that you may recall from Module 6 is called TransXChange. It’s a U.K. national standard for the exchange of bus route and timetable information, and on the slide I use this term "VOSA," which is called in the U.K. the Vehicle Operating Services Agency, which kind of oversees all of the contractors that provide—that actually operate bus services, and in some cases rail services, bus mostly bus services. So the exchange of route and timetable information is amongst what kinds of entities here? The operators of bus services, what is called traffic area offices; and local authorities, which are the local transit agencies, even though the word traffic is used; passenger transport executives, which are typically more regional transit agencies. You’ll find these executives in places like Greater Manchester in the U.K. Traveline is the national passenger transport information system, so information is being exchanged with it; and then suppliers of automatic vehicle location and delivery systems. So you can see here the three components. There’s those schema, documentation, and then a tool that actually publishes the information that you want in XML format.

So what I want to show you now is a flowchart that gives you an overview of how to use TransXChange, and the good thing is we can follow along with the numbers that are shown on the flowchart. So let’s start with number one, which is to the right of this database that says Stops NaPTAN. NaPTAN stands for the National Public Transport Access Nodes Standard, which is a way of defining nodes within a transit network. So number one here is bus schedule data is being prepared using scheduling software, including the stop data from NaPTAN that we just mentioned, and also the data about the routes and any kind of other geospatial data from other sources. So that’s number one. Now, if you move to number two, you can see that the schedule is exported as a TransXChange XML document to that registering agency, and on the export the document is actually validated against the schema within the standard. So some validation is going on there with number two. Number three is when the schedule is then imported by that registration agency and a local transit authority, and there’s another validation that goes on there with number three. Then number four, following another validation, the particulars of the registration are rendered as a readable PDF file, so in Adobe format, and that makes it easier for some folks to be able to publish that information as a timetable. Then number five, which is off to the right, the schedule is then imported by information system builders, like a journey planner, or what we call an itinerary planner, or anything that gets you from Point A to Point B, and any kind of AVL system implementation. And then number six is all or part of the routes and schedules may be exchanged by the system providers. So that gives you an idea of just the process of using TransXChange.

So let’s spend just a minute talking about some other formats that I think would be very, very useful for you to know about, because they are in some cases standards and in some cases de facto standards. One of them is called JSON, and it’s a data interchange and text format that’s completely language-independent, but it uses conventions that are familiar to folks who program in the C family of languages. So it’s kind of an ideal data exchange format for certain types of web applications, like traveler information. Then we have protocol buffers, which I already mentioned to you. It’s a Google sort of language-neutral, platform-neutral mechanism for structuring data. It’s very, very similar to XML but it’s a little smaller, it’s faster, and it’s simpler than that. So that’s what’s used by GTFS-realtime. Then we have Representational State Transfer, or REST. That’s an architectural style for designing network applications. So the idea is that rather than using a complex mechanism to connect between machines that are talking to each other, you use a very simple HTTP request to post the data, to read the data, to delete data, that kind of thing. The Simple Object Access Protocol, or SOAP, that facilitates the interoperability among a wide range of programs and platforms. So it makes some of the information more accessible to a broader range of users and it also uses HTTP, which is a proven web technology, and it has some of the flexibility of XML, and it really defines a way to move XML messages from Point A to Point B. And then XML itself, which means eXtensible Markup Language, we’ve talked a little bit about that. That’s really designed to work in the world of large-scale electronic publishing, but it’s playing an increasingly more important role in exchanging a lot of data, particularly traveler information data, on the web. So we’ve talked about it being used extensively. There are some other standards you may recall from Module 6 that I listed on a couple of slides there, that were developed by the International Organization for Standardization, which is also called ISO, and I’ve already mentioned the European Committee for Standardization, which is abbreviated CEN.

So now we have another pop quiz for you, and let’s go through the question here is "Which one of these standards is not a traveler information standard?" So our answer choices are: SIRI, which, again, does not mean the Siri on your iPhone, but it’s the traveler information standard that we spoke about a little bit. So that’s answer A. Answer B is the Society of Automotive Engineers J1939. Answer C is TransXChange, and answer D is GTFS. And so let’s take a look at the correct answer, which is b) Society of Automotive Engineers J1939. For those of you that took Modules 2 and 5, you’re going to recall that that’s actually a Transit Management Standard, not a Traveler Information Standard, and it’s to define what we call Vehicle Area Networks. So looking at the other answers, SIRI is an XML protocol for exchanging real-time traveler information. Answer C is the U.K. national standard for exchanging traveler information, and D is our de facto standard or common format for public transportation schedules.

So with that, we’re going to wrap up learning objective 2, and we talked a bit about the interface classes. We have our center to center, center to infrastructure, and center to vehicle, and we talked about how to select the most appropriate standards within the application areas within each of those interface classes. So we’ve talked a bit about that, and then we reviewed what these formats and standards actually are, and we went into some level of detail with GTFS, GTFS-realtime, SIRI, and TransXChange.

So now we’re going to move into learning objective 3, and we’re going to talk a little bit about lifecycle cost considerations when you’re using standards in this kind of environment. We also have two case studies that I think really—very well exemplify how to use a traveler information standard, and we’re going to talk about facilitating—we have another short case study to talk about using standards to facilitate some integration with legacy systems, which is something that we’re always dealing with in our industry. We always have legacy software that we need to interface with.

So let’s jump into the lifecycle costs discussion. So we already know that the use of standards can pretty significantly reduce deployment costs, and why is that the case? Because there are a number of things that have happened with standards in the past that lead us to that reduced cost. Standards really embody the knowledge and experience of people who have been working in the field for a very long time. So you can use standards to potentially accelerate a project deployment schedule, because there’s been an evolution of that standard and many people know about it, and it also leads to standardized off-the-shelf components, which also you might be able to utilize, which comes with a lower cost. And standards really provide the folks doing the development and the deployment with a wider choice of options in products, and the more products you choose from, typically the lower the cost and the risk. So that’s one thing to consider.

We’ve already talked about modularization, so I’m not going to cover that again. We did talk about a wider choice of suppliers that are using standards and have adopted the standards, and we’ve also talked in the past a little bit about the reuse. If you’ve already used standards in your procurement documentation, then you can really reduce the cost of specifying other systems using those standards.

I did want to touch on several quick bullets here to talk about the cost associated with using standards, because we sometimes just think, "Well, there can’t be any cost involved. It’s a smart way of doing things." But there is something to consider when you are using standards and I wanted to bring that up. So we have seven bullets here which highlight different areas that you should be considering. One is development. So standards can be pretty complex. I mean, you could see on that chart that talked about TransXChange that there’s some complexity associated with using standards, and that means that you’re going to need considerable expertise potentially to develop and validate the use of the standards. So that could lead to a direct cost of using that.

Then we have something where we’re talking about the availability of a standard, and that’s particularly important because you really don’t want to use a standard unless it’s been formally voted on and adopted, and that it has widespread adoption in the industry. I learned that the hard way very early in my career by specifying a standard that had just been published but it hadn’t been adopted by the industry, so none of the vendors really were able to utilize it yet. Publication of the standard doesn’t mean it’s been adopted, so take a look at that.

Maintenance. Once you’ve adopted a standard, you have to be committed to keeping pace with it. If it changes, you may have to change some of what you’ve done. So that’s important. Procurement to a standard is different from procuring something that doesn’t use a standard. We’re going to talk about why that’s important when we talk about conformity a little later on in the module.

Adaptation. So if you’re going to adapt your standards, then your organization needs to adapt as well because, again, you need to keep up with it and there may be a cost associated with doing it.

And then, let’s see, certification. There may be a situation where you have to formally certify that you complied with a standard, and that certification process may have a cost associated with it.

Gold-plating. That means that if you choose to use a standard that covers a full range of requirements, then you may need to pay for something you don’t need. So that’s what gold-plating means, and that’s something, again, to keep in the back of your mind because it is a cost associated with using a standard.

So now I have two primary case studies and two smaller ones that I want to present that speak to using traveler information standards. The first one is a cast study about the Massachusetts Bay Transportation Authority, which is the major transit authority in the Boston area. You can see here they have 1.3 million riders a day on all of their services. They operate heavy rail or subway, light rail or streetcar, commuter rail, bus, ferries, paratransit. You name it, they operate it, and they operate in 75 member cities and towns within the greater Boston area. So it’s a pretty big agency. So in 2009, the MBTA opened their data to the public, and this was a big deal considering that open data was not available prior to this time in Boston, and it actually wasn’t widely available from a number of transit agencies around the country, just a few of them. So at that time, only scheduled data was being provided using the GTFS format that we’ve talked about before. Then, beginning the following year in 2010, real-time information was added to the open data program at the MBTA, and that’s because they were kind of in on the ground floor of Google GTFS-realtime, and in 2012 they actually piloted GTFS-realtime and then they started to expand their open data program to other underlying systems that were—they were providing real-time information to the public. However, what was happening is shown on this slide, where every data feed was in a different format, and so if you were an application developer that was interested in commuter rail information, you were working with a different set of standards or formats than people looking at scheduled data for buses, for example. So it was kind of a mish-mash, and so there was a sort of informal process that the staff went through to try to select the appropriate standard, and that’s really what this case study really highlights.

So first thing is the staff wanted to support GTFS-realtime. So if they wanted to support that, then they needed to use the format—which, remember, is protocol recognition to be on GTFS-realtime. So one thing they did do is they didn’t just jump to a conclusion—"GTFS-realtime, that’s the best thing." They actually looked at the SIRI standard, but they found that it was very verbose and that it can be complicated, so they decided against it. However, they did keep something open that if SIRI does become more prevalent among developers, they could actually support using the standard, but they didn’t see the point of it. And the other standard that they looked at was TCIP, which was covered in modules 3 and 4 in your training. TCIP was very well suited for communications within an agency but not for communicating with application developers. So the team decided against using it in their open data program. So the other thing that they needed to consider was the MBTA developed an application programming interface to make it easier for developers to retrieve small sets of data, not everything GTFS-realtime, because it was just going to take too long. So they needed to look at what kind of format should be used for that application programming interface, or what’s called an API, and what they did is they selected XML because that’s an industry standard for application programming interfaces.

So you can see that now the situation is pretty cleaned up, where the information that’s being provided is going through a central location and there are a discrete set of standards that are being used, unlike that prior slide where everything was jumbled up, there were a number of different standards and formats being used for different sets of inputs. So the MBTA, when you look at how did they get to that sort of cleaned-up version, is—in 2013 they started to reorganize the feeds and standards and they developed this new sort of module that you saw in the middle of that prior slide. So the reorganization consisted of a couple of different steps. There was an application built using Microsoft SQL Server and two Amazon cloud servers, so they changed some of the server environments. They based everything around the foundation of GTFS data and they changed the website and the subscription service. They use a different service for emails and SMS or text messages. So Phase 1 of this sort of reorganization was launched in 2013 and they sort of finished it up in 2014. So their overall experience with standards for their open data program is that GTFS, GTFS-realtime, and their application programming interface was very popular with developers, and to date there haven’t been any requests for TCIP or SIRI, so those two standards have not been used yet.

So now we have a quick activity for you, and the question is "Which standard is not being used by the MBTA for their open data program?" And the answer choices are: a) General Transit Feed Specification, b) eXtensible Markup Language, or XML, c) JavaScript Object Notation, or JSON, and d) Service Interface for Real-Time Interface, or SIRI. So now we can take a look at the correct answer, which is d) SIRI. The MBTA determined that SIRI was somewhat complicated and they hadn’t had a request for it yet, so they chose not to use it, but they could expand to using it later. Answer A is incorrect. GTFS is one of the standards that is used by the MBTA. XML is also being used and it’s their format for their API, and JSON is also used in the API.

So let’s move to our second case study, which is about the use of standards at the Metropolitan Transportation Authority in New York City. So they provide free real-time developer APIs to what they call their Bus Time System, which is their system that provides real-time information. After some research and consultation with some local developers, the MTA identified the SIRI standard as the one that they wanted to use, so that’s very different from what happened at the MBTA. The open nature of the standard and its growing adoption were the two primary selling points for the MBTA in the context of open architecture and standards-based—providing real-time information based on standards. So this was actually the first SIRI implementation that is public-facing and free to access.

So one thing they discovered is that there was one element of their traveler information or transit information that SIRI didn’t cover, and that’s something that’s called Distance Away, which is a prediction of how far the bus is away from where you are, and most predictions are based on times, not based on distance. So because the MTA introduced that concept in Bus Time, they wanted to extend SIRI to include distance away. So they actually did that. They actually extended the standard to be able to make it work so they could provide people with the distance away, how far away the vehicle is from where they are.

So the SIRI web service calls that are being used by Bus Time or that MTA project are vehicle monitoring and stop monitoring. So vehicle monitoring is where real-time information about one, several, or all the vehicles are tracked by the system, and stop monitoring is where real-time information about the vehicle serving a particular stop are utilized. So basically the Bus Time system provides both XML and JSON versions of their API and the calls that we just talked about—the stop monitoring and the vehicle monitoring—are using GTFS data as a reference, so that’s another standard being used, and then the OneBusAway software that powers Bus Time comes with a few utility to strip down the GTFS file to only the data that’s relevant to a specific route that you’re providing real-time information about. So it’s kind of analogous to what we spoke about with the MBTA, focusing on GTFS as their kind of standard reference. And then the interesting thing is CEN, which is the body that put out the SIRI standard, actually adopted several of the changes that the MTA made so that the most current version of the standard includes what the MTA did with it.

One thing I want to mention—I mentioned this OneBusAway as powering the Bus Time system that MTA has. OneBusAway is open source software, and I thought it would be important at this point to actually talk about what is open source software, because people get it confused with open standards and open data. So I have this slide. Very briefly, open source software, it’s free. You must have access to the source code, because anybody can change it. Modifications are allowed. Derivations are allowed. Distribution of the software that’s modified is allowed. You don’t discriminate against any people or groups or fields of endeavor. The rights have to apply to everyone who has the software without the need to execute an additional license, which is important and we’ll talk about later. And then the license must not be specific to a product that uses the software. It can’t restrict the use of any other software, and it has to be technology-neutral, which makes a lot of sense because you don’t want it to be tied to a technology that could be—it could become less used in the industry as time goes on.

All right. So we have a couple of other cases just to illustrate the use of standards. One is integration with legacy systems. So this is one of the biggest and most common hurdles that you’re going to have to jump through when you’re developing new software, because it’s going to have to be compatible with existing systems. So the integration with an existing system, this is based on something that happened at TriMet in Portland, Oregon, and what they were wrestling with is a project where they had new LED signs, and at the time there were no standards for creating the interface between the software and the sign itself. So they were forced to consider some vendors at the time who had their own proprietary protocols. They really didn’t want to do that, but what they did instead was they said, "Well, you’re going to have to use these protocols," even though they weren’t exactly standard at the time. But they knew that there was an advantage to using those protocols that they would be able to look at a wider group of vendors potentially. So that’s one case study.

And the other one is also TriMet, which is where they were—the development of their transit tracker system, which is their real-time information system—it was built on the same platform as their existing CAD/AVL system. So they saved a lot of money doing it, but they had to make some changes in order to make the transit tracker system as robust as they wanted to. So they had to change, for example, the rate at which information was provided, because all CAD/AVL systems have certain data rates within which they work. So they had to expand the kind of information that they used. So in this case, they had to identify extensions beyond the systems that they were already utilizing to make that work.

So that wraps up learning objective 3, and here we talked a little bit about lifecycle cost considerations when you’re using standards, and we ran through several case studies, and we talked about facilitating the integration with legacy systems using standards. So those were our primary topics that we covered.

So now, we’re going to move right into learning objective 4, which is our last learning objective, fair amount of information, but we’re going to get through it pretty easily. We’re going to read through a couple of the standards that we presented prior. We’re going to talk about how to apply standards in a procurement environment. We’re going to talk about testing a little bit, and then intellectual property.

So, reading this standard, what’s the most important thing you can take away, I think, from what we’ve discussed so far is that different standards are structured in different ways. You can see that the standards that I’ve presented already are all in completely different formats. So GTFS is a comma-delimited file. GTFS-realtime is based on protocol buffers. SIRI is in an XML format. So these are all different, and it’s really necessary for you to understand the standard enough so that you can identify the most appropriate standard. So you need to know enough about it to know whether it applies to your situation. You need to be able to define the use of that standard in a specification, and you particularly need to know how to comply with the standard so that when you get down to testing the system you’re going to know whether you’re in compliance or not.

So let’s take a very brief look into what the standards look like. So GTFS is composed of a bunch of text files. You saw that already. Here in bold are the mandatory test files and their names and the contents, and then the ones that are not in bold are the optional text files. So on this next slide, you can actually see what the standard looks like. It’s words with commas in between and it’s pretty easy to understand. All of these are actually not related to each other, so you can’t draw any relationship, but it just gives you an example of what some of those files look like. GTFS-realtime, remember, based on protocol buffers, and that protocol buffers are used to structure your data in a variety of different data streams. So you could be using different formats for your data streams when you eventually push this out to the public, and we talked about that already with a couple of our case studies.

So let’s look at SIRI. So SIRI, remember, it has the two patterns of data exchange. One is where somebody makes a request and the system responds with data, and the other is where someone has subscribed to specific information and the system publishes just that specific information. And as we had said before in both cases, this is in XML format. And so you can see those—if we have an example—let’s move to our example. So this is where we have a request for information about stop monitoring. That’s what it applies to. So the request consists of a header, which is very typical—header information—and then something that’s called Topics and Policies, which is specific to the function within stop monitoring; and here the request asks for departures for a specific stop, and the response has to contain up to seven vehicle journeys at the stop, which is set by the policy that they have. And if there are more than seven available, then only the first two per each route or line is going to be shown. So on this next slide, it shows you, in the language of SIRI, exactly what’s going on. So you can see there was a request for information. The request was made at a stop with a particular number—you can see that—and we’re asking for a maximum of seven returns—of seven of the next upcoming vehicle journeys. And so you can see that’s what the standard actually looks like for that one simple request.

Now let’s look at TransXChange. So, again, we’re exchanging bus routes and timetables between different computers. So we’ve got our schema, the tool that publishes the data in XML, we’ve got our documentation, and we also have some examples within TransXChange that you could actually use. So we had our—remember we had our registration example that we ran through. So in the schema, we’ve got different types of data that’s being exchanged. I’m not going to read these all to you, but days of service, what holidays are being observed, what information about the bus operator that’s running the service, information about the people who are driving the vehicles, the garages, information about accessibility of stops, like to people in wheelchairs, and things like that. And then the model has seven basic concepts, and I’m not going to read them all in the interest of time. I’ve provided a lot of information here on the slide. But the seven are service, which brings together information about an actual bus service, and it talks about whether you’re providing like a standard fixed-route service or a flexible service, and then the service is defined by what’s called a journey pattern, and we have information about who’s operating the service. Then we have our stop points that we spoke about earlier, and then we have references about the stops, and then the actual registration of the service so that everybody can look at the information. If you want to look at it from a diagram perspective, here’s a diagram of the TransXChange model, and it has those seven components that I listed. So if you look on the left-hand side, there’s a yellow box that says Service, and then below that are standard or fixed-route service or flexible, and then below the standard or fixed-route service, we would define a journey pattern. So that shows you how these components are interrelated. So that’s TransXChange, at a pretty gory level of detail.

All right, now let’s talk about some issues related to using standards in procurement documents, and there are issues we’ve already brought up in the module, but I want to kind of reiterate a couple of points. Standards are not absolutely perfect and they may undergo some changes as technology changes and there are new functions that are requested. When you think about video recordings years ago, there was a format called Betamax and it was really pushed out by a format called VHS, and so these are the kinds of things that happen, that there are standards that exist; they may not exist forever or they may end up changing. But if you want to use a standard but you want to extend it, you can do that like the MTA in New York did, but you have to be very clear about what constitutes conforming to a standard if you’re not using it exactly the way it’s defined; and the other thing to be thinking about in the back of your mind is just because a manufacturer or vendor says that they comply or conform to a standard doesn’t mean that they do, and so I strongly suggest that you don’t simply repeat something that’s on a vendor’s data sheet when you’re procuring an item that uses a standard. You need to kind of go back a little further and not assume that they’re in compliance with that standard.

The other thing that you need to do really comes out on the next slide. Remember, everything we’re doing is based on user needs, and you define the user needs in something called a Concept of Operation. In the concept of operation, you’re really addressing what the user said they needed to be able to do in that system, and you’re hoping that you can provide those functions using standards, but there are times where you might have to consider something that’s proprietary and doesn’t have a standard. So we say here avoid using proprietary features or standards. There may be a point at which you can’t do that, but you should try as much as possible to use something that’s standardized because it’s going to be widely available to the whole community and it’s going to be a lot easier to work with.

What do we need to consider when we’re incorporating a standard in a specification? We’ve got to go back to the Concept of Operations—remember, our user needs. We need to identify the components or devices that you expect the vendor to supply when they’re building this system. You have to really specify what the functions are. What are the requirements, and are there any standards that are going to facilitate providing those functions? And then what’s the language that’s going to require the use of data exchange that’s standardized, and then an overview of the testing program. We’re going to go into a fair amount of detail about testing but if you would rather look at what I just said in a flowchart, here’s the flowchart. It shows the process of incorporating a standard into procurement documents, as I just mentioned. Start with ConOps, the Concept of Operations, specify your requirements, your test procedures, and some of the specific objects and value ranges that the system needs to operate within.

Let’s look at an excerpt from the functional specification. Now, this is only an excerpt and the full text is actually included in the student supplement. We couldn’t get it all on the slide, so we just wanted to give an example. This is actually from a specific transit agency and it’s their CAD/AVL request for proposal. They wanted to make sure that they were providing real-time information so that third-party application developers could develop applications for them. So they specifically wanted an export of their CAD/AVL data in GTFS format, and so this is the way that they said in the standard—in the specification, this is what they used to discuss using the standard. So the system shall provide an interface to Google Transit using GTFS, and then there’s more detail. The contractor shall process the data, it’ll prepare the transit data as a zip file in GTFS format, blah, blah, blah. So you can look at the whole way that that was specified in the student supplement.

Now, how do determine whether you’re in conformance with a standard? So conformance is usually defined as testing to see if an implementation faithfully meets the requirements of a standard or a specification. Testing is done to determine compliance with the requirements in terms of performance, how robust is the system, how does it behave, do the functions operate the way they’re supposed to, and does the system interoperate with other systems? So although conformance testing may include some of these kinds of tests, it has one fundamental difference, and that’s the requirements for the criteria for conformance have to be specified in the standard or in the specification. You can’t leave it up to chance. So this is usually some kind of clause, conformance clause or statement, in the spec or the standard, and some standards have subsequent documentation for how you’re going to actually test it and what assertions you’re going to make about the test. So what are we trying to do? Ideally, we’d like to prove beyond a reasonable doubt that an implementation is consistent and complete with respect to the specification. However, it’s generally impossible for implementation of sort of general specifications that are written in English in a basic language. The alternative is what we call falsification testing, which subjects an implementation to a various number of combinations of legal and illegal input and compares the resulting output to a set of expected results. If errors are found, one can reduce that the implementation does not conform to the specification. However, the absence of errors does not necessarily imply the converse of that. So falsification testing can only demonstrate nonconformance. Nevertheless, the larger and the more varied the sets of inputs are, the more confidence you can place in an implementation where you don’t generate any errors. So this really speaks to this issue of conformance.

So a conformance clause or a statement is a high-level description of what’s required of implementers and application developers. In turn, that refers to other parts of the standard. So it may specify sets of functions, which might take the form of profiles or levels or other kinds of data structures, and the clause may specify minimal requirements for certain functions and it may also identify some specific values that it’s looking for, and it may also specify being allowed to extend the approaches within a standard.

So in terms of conformance testing, again, it’s a way to ensure that if standards-based products are implemented that they actually conform to a standard, and the advantages that are reported by the testing—are you have a quality product, the product is interoperable with other products or other systems, and you’ve created a more competitive environment with more vendors. So there are two major components of conformance. One is a testing program and the other one is a test tool. The testing program can’t exist without a suite or a tool to test, but the suite can exist without a testing program. However, not the best idea; they should both be there for a fully robust testing program. And then the decision to establish a program is based on the risk of sort of nonconformance versus the cost of creating that program. There’s always a tradeoff. You always have tradeoffs. And so if you think about a testing program and what it usually includes, that’ll help you determine the cost. So it typically includes a standard or a specification, a test tool, procedures for testing, what constitutes a pass or fail, and who’s going to do the testing, who’s going to certify the testing if that’s necessary, and arbitrating kind of disputes about whether it’s true or false, the testing.

All right, so now we have an activity for you, a pop quiz, and the question is "Which of the following elements are included in a conformance testing program?" We just talked about that a little bit. Answer A is the standard or specification, B is procedures for testing, C is the organizations to test or issue certificates of validation, and D is all of the above. So now let’s take a look at the correct answer, and it is D, all of the above. So all three of these elements are part of a conformance testing program. So A is included, B is included, and C as well.

I want to wrap up this particular learning objective by talking a little bit about standards and intellectual property. It’s something that comes up quite a bit in our industry today, and some of us have been exposed to situations where there are organizations that have patented certain kinds of technology and will go after an agency if they haven’t bought into that particular patent. So it’s not uncommon today that the technology for a technical standard is actually proprietary or it’s protected by one or more patents, and you really need to be aware of that. The vendor is typically made responsible, but you should be aware that there could be that situation. So the development of standards more and more frequently anticipates technology rather than follows it. So sometimes you’re on a bleeding edge, and that can lead to a conflict between a standard and a patent. If patented technology is incorporated into a standard without the patent-holder’s agreement to share its patent rights, then the patent holder may be the only entity that can comply with the standard. So that’s kind of the way we need to look into this whole area a little more specifically.

So, let’s take it another step. Any agency that plans to adopt a standard should verify if there is any patent or patents that are essential for which a license is required and the terms and conditions under which the license will be granted, and you really need to be aware of that because somebody can go after you if you needed a license. So this information is generally available from the standards development organization that balloted and has the standard and is managing those standards. If the license is obtained directly from the patent-holder, the patent-holder should be contacted by the transit agency and should be negotiating a license agreement prior to adopting the standard. You want to make sure your ducks are all in a row before you actually adopt the standard. There may also be cases in which, in order to comply with a standard, an agency may have an option of choosing from alternate technologies that don’t require the use of protected or patented technologies, or they do require the use. So you want to take a look at that as you’re looking at what technology to adopt. And in a case like that, the patents would not be considered to be essential but useful, and then there are other ways of complying with the standard that don’t require the use of a patent. So you should be looking at the full range. There may also be cases where there are a number of essential patents which may be pulled by the patent-holder and then you might only need one license to be able to access all of those standards. In any case, it’s really important to understand that to comply with a standard, an agency may have to use one or more patented technologies, which means you may need to obtain a license, so there’s a cost associated with that. But you want to make sure you do it before you actually adopt the standard. There are situations where the patent-holder may agree to grant a royalty-free license, but that doesn’t happen very frequently, so it’s important to understand kind of the rules of the game when you’re talking about proprietary or patented technology.

All right. So we’ve come to the end of learning objective 4, and we’ve talked about a lot of different things here. We’ve talked about looking at what the standards look like and the fact that they’re all structured a little bit differently. We looked at and we talked about extending the standard and the fact that it has to be very well documented. We had several components that we talked about, putting a standard into a procurement. We talked a lot about testing, and we just wrapped up by talking about standards and intellectual property.

So, overall, we’ve now wrapped up Module 7, and I’d like to review a couple of fill-in-the-blanks for you to kind of put our hands around everything that we covered in Module 7. So going back to the very beginning, service packages represent slices of the blank that address specific services like traveler information, or transit management, or surface street control. The blank is physical architecture. So service packages represent slices of the physical architecture. Number 2: The use of standards is desirable for both business and technical reasons. We’ve talked a lot about that. The principle benefits of standards are as follows. There are three of them: A is protection of your investment. B is interoperability with both internal and external systems. And C is improved quality and value. Number 3: Blank provide a starting point for identifying the ITS standards and other resources, and are deployment-oriented categories that focus on commonly deployed ITS services or systems. So that blank for number 3 is application areas. We talked a lot about those. Number 4: Using standards in a deployment can greatly blank component development costs, especially if standardized, off-the-shelf components are available. So they can greatly reduce component development cost. And 5: The requirements for criteria for blank must be specified in a standard or a specification, and the blank is conformance, something we just talked about in the last slides.

Here are a number of resources. This only sort of scratches the surface of resources. There are many more that are included in the student supplement that I would urge you to look at. This gives you much more detail about everything that we’ve talked about in the module.

The next course modules that you may want to consider now that you’ve taken Module 7 are Modules 8 and 9, which I mentioned at the very beginning cover arterial management and transit signal priority; Module 10, which covers electronic fare payment systems; and Module 11, which covers connected vehicles in the transit and connected vehicle environments and some other emerging technology. And with that, I want to thank you very much for completing the module, and as I also mentioned at the very beginning, we are always looking for feedback

#### End of Module_7.mp4 ####