ITS Transit Standards Professional Capacity Building Program

Module 1: Introduction to Intelligent Transportation Systems (ITS) Transit Standards

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 multi-modalism 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 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 the webinars.

ITS Transit Standards training is one of the offerings of our updated Professional Capacity Building (PCB) Training Program specific to transit 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 systems safer, smarter and greener which improves 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 state and local highway agencies and transit agencies. You can find information on additional modules and training programs on the USDOT web site at ITS PCB Home.

Please help us 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.

Bruce Eisenhart: Welcome to the ITS Transit Standards Professional Capacity Building program, presentation of Module 1, Introduction to ITS Transit Standards. I'm going to be presenting information at a high level about transit standards, and throughout the presentation I'm going to present some activities to the slide look here, indicating that there's some multiple choice pop-up quizzes that will follow that slide. First let me introduce myself. My name is Bruce Eisenhart. I'm the vice president of operations at Consensus Systems Technology Corporation in—I live in Centerville, Virginia. I've got 40 years of experience in system engineering. The first 18 of those were with developing large defense systems; the last 22 have been in ITS. I've been involved in all phases of system development, from requirements to design to testing, and for the last 22 years in ITS, I've been working on the national ITS architecture. I've been working on that since its inception back in 1993, and for about a decade I was the chief engineer on that project, and I've been a senior engineer for the last decade or so. Over the years, I've developed over 80 regional ITS architectures that use the transit standards and all the other standards in ITS that are out there, and I've also been a trainer. I've trained with the National Highway Institute. I currently do classes with the National Transit Institute on project management for the transit professionals, and I've been active in the development of ITS standards, working on the Traffic Management Data Dictionary and the connected vehicle standard, J2735.

Let me first talk about the target audience for this introduction module. Because it's an introduction module, it's really useful to pretty much all the different audiences that are out there in the transit world—the transit management staff, transit planning and operations and maintenance staff, procurement staff; obviously transit staff that are working in ITS could benefit from learning about the basics of ITS standards for transit; and also the contractors and the consultants that are going to be deploying ITS; transit technology vendors, the vehicle manufacturers and, finally, the transit IT staff—people that keep all the computers and the networks and the systems up and running.

There are no recommended prerequisites for this class because this is the introductory module in a series of eleven modules that have been put together by the Professional Capacity Building program.

I'm going to talk briefly about the curriculum for these eleven modules in the next couple slides, but I will actually return to this at the end of the module and discuss it in more detail. You can see Module One up to the top of the slide there—that's the one we're presenting now—and pretty much the next two modules after that—Transit Management, Part 1 of 2, and TCIP Part 1 of 2—are recommended for everybody who's interested in this, and then there's the modules in blue down there are optional modules that decision makers may want to listen to. In the area of project managers, a larger number of modules are very directly applicable to project managers, and same with project engineers, the people who get involved with the more technical details of ITS transit projects. You can see most of the modules there are recommended that they take a look at those as we go through the series.

So let me talk now about our learning objectives for this module. We've got five learning objectives. The first one is just to define what transit standards are and look a little bit at their benefits and costs of using those standards. After that, I'm going to talk about the systems engineering process and look at some of the benefits of using the systems engineering process in developing ITS transit projects. After that, I'll talk about high-level technical and institutional challenges to applying ITS transit standards. Then I'll look a little bit at the role of standards in transit ITS applications, and basically give a little bit of a preview of some of the things that are going to go into more detail as we get to the next modules. And finally, as I said, I'll go back to the roadmap of transit standard modules and talk about what each of the modules are and what—you can take from that what modules you might be interested in attending beyond this one. So the first learning objective: Defining ITS transit standards and examining the benefits and costs of using those standards. For sub-objectives in here: First, what are ITS transit standards? I'll talk a little bit about the development process for developing standards, look at some of the benefits of using standards as part of transit deployments, and then finish up with—look at some of the costs of using or of not using transit standards. So, first off, what are ITS transit standards? And I'll start with a more general thing: What is a standard? And here's an accepted definition of standards: An established norm or requirement about technical systems that establishes uniform engineering or technical criteria, methods, processes, and practices. So that's a high-level definition of what a standard is. In the case of ITS standards, what do they do? Well, they typically define how ITS systems, products and components can interconnect, exchange information, and interact to deliver the services. There are three basic types of standards, ITS standards that are out there. The majority of those are standards that relate to the data that's transferred on an interface. There are some that talk to the communications protocols that are actually used to send the data—a standard that talks to an XML protocol that is used to transfer information from center to center—as an example—and there are just a couple of standards that actually are hardware definition standards, but these are somewhat rare in the ITS realm. Now, one other thing that's important to note about these first two types of standards there is they're not design standards. We're not specifying products or designs to use; we're just defining what the information is, how to send the information across an interface.

So let me next talk about the standards development process. Standards are typically developed by a standards development organization, and the standards development organizations have three key characteristics. First, they're voluntary, meaning the use isn't mandated by any particular law or requirement, and that's true of the standards that we have in ITS. They're consensus-based, meaning the published standard has attained general agreement through cooperation and compromise; their process is inclusive of all interested parties, so it's not just one company coming to the table and setting a standard. It's set by a variety of interested parties. And finally, standards are open, meaning they're not proprietary and they're available for anyone to use. Now, this particular diagram here that shows the process for developing standards is the development process used by IEEE, or the Institute of Electrical Electronics Engineers, which I happen to be a member of. You can see on the top right there where you initiate the project. They mobilize a working group of people who are going to develop the standard. They actually make a draft of the standard, and then they go off to balloting. And balloting is where all the interested parties get to review the standard and provide comments on it, and either approve or reject that standard, and eventually get final approval and once the standard is out there, then the group usually stays in place they discover issues with their deployment, they go back, they fix them, and that's the circular process that you get in the standards development process.

So, what are some of the benefits of using ITS standards? Well, there's a number of them shown here, and in fact I'm going to spend a little more time—I'm going to have a slide or two on each one of these. So let me just run through them briefly. First, it facilitates regional interoperability, and I'll talk more about that, defining that term in the next slide. Having standards supports compliance to FTA's policy on ITS architecture standards. It can facilitate systems integration within an agency. It can reduce future integration costs, reduce O&M costs, and if you're using standards, it's easier to apply boilerplate specifications, copy procurements from other standards, or from other agencies that have used it. So it's basically easier to procure a product if you're using standards.

So let me start with the benefit of interoperability. What is interoperability? It's the ability of an ITS system to provide information and services to other systems that use the exchanged information services to operate together effectively. Interoperability is really one of the keys to achieving the full potential of ITS, because ITS is all about sharing information within an agency and between agencies, and to do that, you need to be able to have this interoperability of information. Now, rather than diving right into the details of ITS, let me use an analogy to explain the idea of interoperability with a home theater system. These systems have been around for a long, long time, and there have been standards in place to define how audio information is transferred from one part of the system to another. In the old days, there were a lot of individual components people had. They had amplifiers, they had receivers, maybe they had record turntables a long time ago, and as time went on they transitioned to CD players, and in recent times people have transitioned to MP3 players, and who knows in the future what devices might be added as we go on. But because the audio standards were developed, actually starting back in the '40s, if you have a system with these standards you can take a new device and you can put that device onto the system and you know it'll work. Now, in the old days, these standards were—it was analog systems. The standards were physical in nature. But as we've entered the digital world, now we have digital standards and we have Wi-Fi standards, so you now can hook things up wirelessly to your system. So basically because we have these standards, there's an interoperability that allows different devices to play together and plug and work together. So that's an example of interoperability in the general nature. Talking about interoperability as it relates to transit, the idea with this is that if you have interoperability with standards, it'll allow you to support regional information sharing—for example, sharing real-time bus information between the agency, traveler information systems, and the public in general. Having this interoperability supports the Code of Federal Regulations 23 Rule 511 that was developed a couple years ago. It's called the Real-Time System Management Information Program, and this rule requires states and metropolitan regions to collect and share real-time traffic and travel conditions. Now, while the emphasis of this rule is on traffic, the fact that it has travel conditions in there indicates that, yes, transit is a part of that, and the diagram that is shown here is a portion of a diagram of the RTSMIP taken from something called the Data Exchange Format Specification. That is a specification of the type of standards one might use in sharing this real-time travel conditions and traffic information, and you can see the transit agency there sharing information with transportation agencies, sharing information with public traveler information provider systems, or private third-party provider systems—apps or things like that. So this idea of interoperability is key to allowing transit agencies to share information in the outbound way, and also to receive information from other agencies—for example, receiving information from the traffic agencies that are out there.

Another benefit of using standards is it supports compliance with the FTA policy on ITS architecture and standards. There's a corresponding FHWA policy known as Rule 940 that you may have heard of. Now, the USDOT put this in place, this policy with FTA and the rule with FHWA, because they recognized the potential benefits of using the systems engineering approach with ITS projects, and they included in this some requirements for systems engineering analysis in these rules. Both of them require a systems engineering analysis be performed for ITS projects that use funds from the Highway Trust Fund, which includes the mass transit account. The policy actually specifies seven requirements that system engineering now must include as a minimum. I'll talk more about what is meant by system engineering analysis a bit later in this module. Now, I'm not going to go into all the requirements. You can find those as part of the Student Supplement. So if you're interested, you can go look at that. But what I will point out is that number six of the seven requirements on the list specifically mentions the identification of applicable ITS standards and testing procedures. Now, the FTA policy is not mandated, which the FHWA rule actually is, but FTA does monitor compliance of agencies with this policy through triennial reviews. So they have in the last few years become more insistent that transit agencies pay attention to this policy on ITS architecture and standards. So as I said, one of the other key benefits of using ITS standards is it can facilitate systems integration, integration of systems within an agency. What might that be? Systems between your services, between fixed route and paratransit, between modes, like bus or rail, or just between departments, say between operations and maintenance. And how does using standards make this system integration easier? Well, data created as one part of the agency can be input and used directly by another part of the agency. It removes the need for any costly translation from one form or another. Using that home theater analogy again, home electronic systems have become networked with other systems in your household. Now with proper connections, your computer can talk to your TV, your TV can communicate to the Internet. We have all kinds of connections within our home all because of the standardization of that communication. Another area of benefits that you can obtain from ITS standards is the reduction of costs for integration and maintenance. In terms of how does using standards reduce integration costs, well, for one thing, you're not locked into one company's proprietary systems because if you have one company system, it becomes more difficult and it may be more difficult to change capabilities, to add capabilities, it may be more difficult to change to different systems. Expansion of systems is going to be easier and likely cheaper because you can procure systems competitively rather than being forced with each expansion into using a single vendor solution over and over again. Because standards define all the interfaces, they don't constrain vendors from creating innovative solutions that work within the standards, but they do increase the flexibility an agency has for procuring solutions, because you can have a choice of vendors rather than being locked into a single one. Vendors do go out of business, and if you're locked into one that goes out, you may have to re-procure a lot of equipment, so using standards can help to reduce that risk because it'll make it easier for other equipment to come on and be used with the existing equipment you have. In terms of reduced O&M cost, documented standards-based interfaces are easier to maintain and update. Why? Just because they're well documented, and the documentation is a key to maintaining an interface. In addition, the standards are involved through the consensus process; errors get corrected and features get added. So a system that's already using one version of a standard is going to have an easy time updating that to the next version of the standard and obtaining the fixes and the features for any of those revised versions of the standard that come out.

The final benefit, if you will, of using standards is that it can simplify the procurement process. Once an agency commits to using standards-based procurement, they can look to other agencies that have already gone through the process, can possibly even borrow portions of procurement packages already developed to procure similar systems. However, an agency needs to understand that standards need to be tailored, so you can't just copy other people's specifications, but you can borrow them and use them as a starting point for customization.

Finally, with this simplification, with a clear version of procurements that go out, you can lower the implementation risks because you get a better understanding of what you're actually going to get with the product when you're procuring based on standards.

Now, I have talked a lot about the benefits of using ITS standards for deployments, but are there costs associated with standards? And the answer is yes. The initial use of standards may come with additional costs, over using that proprietary solution that vendors are trying to sell you. Why is that? Because you have to go through the effort of understanding what you need and properly specifying how standards are to be applied. This takes extra time up front and your decision makers must support spending this additional effort, which results in additional costs for the agency at the front end of a procurement. But the benefits to using standards, as mentioned in the previous slides, are real.

Is there a cost to not implementing using ITS standards? Yes there are. Not necessarily in the initial deployment, but being locked into proprietary systems can cost more for upgrades and additional deployments than if you are working with open standards.

Activity Slide: So, now let's look at an activity that will give us a multiple choice question relevant to that last learning objective. So, what are some of the benefits of using ITS standards? And the four answers are: facilitates regional interoperability, supports compliance to FTA policy on ITS architecture and standards, facilitates systems integration, or all of the above. Well, if you're looking closely at what I just presented, the last few charts, the correct answer for this is all of the above, because each of those three things is a key benefit to using ITS standards. Facilitating regional interoperability is probably one of the biggest benefits—information-sharing across agencies. Supporting compliance, using standards as identified as one part of the policy requirement for systems engineering analysis. And finally, facilitates system integration within a single agency—the data created by one part of the agency can be used and input directly to another part of the agency. So, let me summarize what I talked about in this first learning objective, which was defining the standards and the examining the benefits and costs. First off, ITS standards define how ITS systems exchange information to deliver services within a transportation network. Some of the key benefits using ITS standards: it facilitates regional interoperability, which allows agencies to share information, and it supports compliance to the FTA policy on ITS architecture and standards. However, the agency must do the up-front work to understand and define how the standard will be used.

Now let me move on to learning objective two. In this, I'm going to introduce the use of the system engineering process and talk about the benefits of system engineering process for ITS projects, and then I'm going to look at how standards fit into this system engineering process. So, in terms of the system engineering process and its benefits, first I'm going to define system engineering and explain what the process is. I will list some key benefits of that process, and then I'm going to talk about a related subject, which is ITS architectures—national architectures and regional architectures—and we're talking about those because of their relationship to the system engineering process. So, first I asked the question: What is system engineering? Well, first off, it's an interdisciplinary approach and a means to enable the realization of successful systems. So the idea of system engineering is that you're using a structured process to arrive at the final design of a system. The intent is the final design is selected from a number of alternatives that can accomplish the objectives and contribute—and the system engineering process considers the entire life cycle of a system, not just through the actual turn-on of the switch for a switch. It includes not only the technical merits of solutions, but also looks at the cost and relative values of alternatives. It really can be applied to any system development, whether you're making a household appliance, building a house or implementing a sophisticated transportation management system. System engineering can be used for all of those. One of the keys of system engineering is it focuses on defining customer needs, both the business and the technical needs, and then looks at the required functionality that is needed to provide those needs, and it'll look at the requirements that you need for that functionality. It creates a final design that's selected based on alternatives, and as I said, it addresses the problem throughout the process. The idea is it integrates all the disciplines and specialty groups into a team effort, forms a structured deployment process that proceeds from concept to production to operations. So it's sort of a cradle-to-grave for development of a system. Since it was first developed in the '80s, the Vee model has been refined and applied to many different industries, and the USDOT chose this as the way to express systems engineering for ITS and for transportation in general. The Vee model, as I said, has been around since the '80s. Wings were recently added to the Vee as part of its adaptation for ITS to show how project develop fits into the broader project lifecycle. It represents a typical lifecycle of any system or project, whether the system being developed is a basic computer-rated dispatch for a transit agency, or a more complex regional electronic payment system. All systems will follow some variation of the lifecycle shown here from beginning all the way through retirement and replacement at the end. I call this lifecycle a system because it covers the steps beyond just the beginning and the end of a project. The actual Vee—it starts where the project starts and it gets to the end where you have system validation for a project, but the life of a system goes beyond that. A system engineering process in general has been around for over 50 years, and it's a proven development process for complex systems. It's been successfully used in many different disciplines, and it's been successfully used in transportation in general and transit in specific. In the context of a development project, the effort begins with the development of project planning documents shown on the top left of the Vee. This shows a system engineering management plan framework on this document. The SEMP, as it's called, describes how a system engineering process is going to be applied to a specific project, identifying what activities will occur at each step in the process, and providing the schedule for the effort. Once the planning is complete, the development effort begins with the concept of operations. This document defines the user needs the system will address and describes the operational scenarios the system will support. Once the needs are defined, the system requirements are developed. These requirements are meant to answer the questions: What does the system do?—that's the functional requirements—How well must the system performance function?—the performance requirements—and under what condition must those performances occur? At this point in the development, the focus has been on what the system has to do and not how you have to do it. In the design steps, we start to get into the how it has to be done, but first you break the system into subsystems and define basic interfaces as part of the high-level design. Then you can perform the detailed design of each subsystem and the detailed design of each interface. The bottom of the Vee is the step where the systems are built—or coded, depending on what they are. Then the right side of the Vee is the testing of the system. First you have the unit-level testing, and then you move upwards to the system-level testing. The significance of drawing this as a Vee is shown by those arrows that go from the left side of the Vee to the right side of the Vee, and that the output of the steps on the left side are used to support the testing that goes on the right side. As development progresses, a series of documented baselines are established to support the steps. For example, a consensus concept of operations is developed before you create the system requirements. A baseline set of system requirements is created before you do the design.

So you progress on the left side from a general user view of the system down to a detailed specification of the design. The system gets decomposed into subsystems, I said, and the subsystems may get decomposed further into components. So you can break a large system into many smaller pieces that can be more well-defined. Now, this is a very high-level view of system engineering process. If you would like to know more about that, look at the references in the Student Supplement. It'll reference you to an ITE's E-Primer on system engineering, is a good place to start, and there's some more detailed system engineering documents that have been developed by the DOT that can provide a transportation-specific view of this overall model. As I mentioned, the symmetry reflects the relationship between the steps on the left and the right. The definition on the left is ultimately used to verify the system on the right. Now, we've been developing systems in transit for a long time, and particularly capital-based systems have a development process that looks somewhat similar to the process shown at the top, where you have transportation planning that identifies projects to be developed. Ultimately you have some programming or budgeting process that funds the projects. You go through a project initiation. Once you've initiated, you do a preliminary engineering—usually make a plan, specs and estimates, or PS&E, which is equivalent to a detailed design. You implement the project, and then you close out the project, and you go through steps of operation and maintenance, changing eventually to retire and replace. So that basic process of development is mirrored by the system engineering process, and as you can see there the preliminary engineering is roughly equivalent to the planning through the system requirements. The plans, specs and estimates is equivalent to the design steps of system engineering, and the implementation is equivalent both to the implementation which shows on the bottom of the Vee, and then the testing that’s done as you move up the right side of the Vee. One of the things I wanted to highlight in the system engineering process is this idea of having decision points—those dark little ovals that were between each of the steps represent decision points. They might be project reviews that can provide structure to organize approach to reviewing the projects, and they're really a primary method of communicating progress, monitoring risk and transferring products and knowledge. As I said, they often occur to completion of the Vee process step. Those are the decision points that must be successfully passed before you move to the next step. Of course, in addition to formal decision points like that, there may be less formal reviews conducted as part of the development process. Decision points are important to the system engineering process because the idea is to work through each step of the process, get the errors, the problems out before you move to the next step, because the sooner you find a problem, the less money it will cost to fix that problem.

So what are some of the benefits of the system engineering process? Basically these first three benefits—improving the quality, reducing the risk, and increasing the likelihood that the user needs will be met—SEP improves the chance of having a successful project, which can be defined as having a high-quality product that meets user needs while not incurring cost overruns or schedule overruns to achieve the result. The early steps of the process, done with inputs from the stakeholders, will improve the stakeholder participation and buy-in as you go through the process. Another feature of SEP is that documentation is produced at each of the steps on the left side of the Vee, and this not only gives you better documentation for the project, but it also helps you discover and fix errors earlier in the process, which is going to result with a final product with fewer problems, which is going to translate into reduced operational cost. Now that we've talked a little bit about SEP and its benefits, let me move next to a related topic: ITS architectures. The first step in that Vee diagram was called Regional ITS Architecture. Now, the concept of this architecture is defined in the FTA policy on architecture and standards, which defines a set of requirements for regional ITS architecture and describes how those architectures are used as part of the systems engineering analysis that's required for ITS projects. So there's the definition of the regional ITS architecture that comes out of the policy—a regional framework for insuring institutional agreement and technical integration for the implementation of ITS projects in a region. Basically it's a plan for deploying ITS across a region that’s used to support transportation planning and used to support project development. So, what is a region, as this is defined? Well, that is left up to each state, each metropolitan area, to define how they want to create a region. Probably the smallest region for which regional architectures are created are the boundaries of a metropolitan planning organization. For example, the diagram on the left there is the region for the Las Cruces, New Mexico, regional ITS architecture, which is the Mesilla Valley MPO. In some places, regional architectures might be defined along state departments of transportation boundaries. In the case of Florida, which is the middle diagram, the state DOT has taken the lead in architecture development and has created architectures for each of the districts within Florida. This one happens to be for District 7, which the large city that's within that is Tampa, Florida. Some regional architectures cover entire states. For example, in West Virginia, while West Virginia has several MPOs, most of them are fairly small, so they chose to create a single architecture, regional ITS architecture. It is a statewide architecture. It covers all of the transportation services, all of the ITS aspects within the entire state. Now, these regional ITS architectures are not developed in a vacuum; they are based upon a national template called the National ITS Architecture, which was developed, as I said in the beginning—it was first developed—actually the first version of it came out in 1996. It's a common framework for planning, defining, and integrating ITS, and some of the things that this architecture has, the national architecture, it defines the functions that required for ITS, the physical entities—or in terms of national architectures, these are called subsystems, where those functions reside—and it defines the information flows that connect these physical subsystems. This diagram here is sometimes called the sausage diagram of the national architecture, and it shows the 22 subsystems defined in the national architecture. Ten of them relate to centers. You can see that right dead-center in there is the Transit Management subsystem, and you also see the Information Service Provider subsystem. That's what provides travel information. You see an Archived Data subsystem that provides historical data for planning, research, and things like that. So there's a number of centers, and the architecture talks about how those centers connect to field devices. Roadway Devices might be the traffic signals that are used for transit signal priority. Security Monitoring might be the security equipment that's put on transit rail tracks or things like that. We have a set of subsystems that relate to vehicles. There's the general vehicle, but there's also specific ITS functions related to the transit vehicle, and then you see two subsystems up there that are how travelers may interact and obtain traveler information, the personal information access being the most common one now, which represents your computer, your smartphone—any of those ways that you can access information. This architecture, as I said, was developed—it's actually in version 7 right now. It's gone through seven updates in the last almost 20 years. We've got the 22 subsystems, I said, and the last one, it says the Information Flows. The key is there's roughly 600 information flows in the National ITS Architecture, and those are all used as the basis for developing the regional architectures that you see throughout the country. There's a reference down there, and it's also in the speaker notes—excuse me—yeah, speaker notes—of where you can find more information about the National ITS Architecture, if you should want to. Now, how do standards fit into this systems engineering process? Well, the first discussed in the standards to be used usually happens as part of high-level design, because a key output of high-level design is the definition of interfaces, and once you've defined the interface, that defines where standards are used. During detailed design, the use of standards is fully defined via tailoring of the standards. The standards that have been developed are all very—are all complex documents with mandatory items and optional items, and part of the work in doing detailed design is to decide which part of the optional items you want to use. Obviously you have to use the mandatory ones to comply with the standard, but you have a large selection of optional items that you can pick from—optional data elements, data frames, even messages—that you pick and choose depending on how you plan to use the standard in your actual design. So now let me go to an activity, and let me first in this ask: What is the relationship between the steps on the left of the Vee and on the right side of the Vee in the system engineering process? And I've got three choices for answers here: one, there isn't a relationship between the left and the right; secondly, the system definition on the left is used to verify the system on the right; and the third, the items on the left are performed after items on the right. Those are our three choices, and the correct answer is B, that the definitions that you generate on the left are ultimately used to verify the systems on the right. There is a relationship, and it's the one in B, and the items on the left are performed first and are used to verify the items on the right. So the correct answer was B for that one.

Bruce Eisenhart: The question is: ITS standards are typically first used in what step of the system engineering process? And the choices are the concept of operations step, the requirements step, the design, high-level and detail, and the hardware and software development. And the correct answer is high-level and detailed design. Standards are first identified when you identify the interfaces in high-level design, and they're tailored in the detailed design. So the concept of operations defines user needs. The system requirements defines the functional performance and other requirements. Now, you may actually be able to pull some of these from standards, but it defines the requirements, and the hardware development and software development is implemented based on the standards that you've defined.

This slide provides a summary of what I have discussed under learning objective two. I talked about the Vee diagram, which represents a sequence of steps in the project's lifecycle. These steps describe the activities to be performed and the results that are produced during product development. It starts with the project planning and concept of operations on the left side, goes through the system requirements, then to the system design and definition, getting down to system development and implementation at the bottom of the Vee, and going up the right side of the Vee where you integrate, test, and then validate the system, using the key outputs of the steps on the left side of the Vee.

The SEP focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem. This process ensures that dependencies among Transit Management functions/technologies are considered. Key benefits of using SEP are that it reduces the risks and improves the quality of ITS projects.

As part of this learning objective I also talked briefly about regional ITS architectures. They're used to provide a plan for regional deployment of ITS. They're actually shown as the very first step in the Vee diagram.

Finally I looked at where the standards are defined as part of SEP, which is in the design steps, the high-level design and the detailed design. In HLD interfaces are defined and standards selected to support those interface. In detailed design themselves are tailored or customized for use on the project.

Now, the next learning objective is to talk about the high-level technical and institutional challenges that can occur when you try to use standards for ITS projects. First with the technical challenges. One of the issues here is that there is inconsistent support for standards, and some vendors don’t support them, some vendors do. One of the things that is a challenge from the technical viewpoint is what to do when standards are only partially developed. Maybe there's some gaps there. Maybe there's some areas where the standards aren't mature. And also using standards can be a paradigm shift, in two ways. It can be a paradigm shift from non-standards-based to a standards-based development. It can also be a paradigm shift from this idea of the systems engineering process, from using it to not using the process. So those are the four basic technical challenges I'm going to talk about. So first, let me talk about industry support. Some vendors, some transit vendors in particular, provide custom solutions, and they don't support standards. They have very large footprints in the industry and they are not big supporters of standards. Ownership of data can sometimes be an issue. We talked about one of the benefits of using standards is to allow regional information-sharing. You need to be able to own the data so you can share the data, and there are some vendors that put restrictions on the use of data that gets generated by the systems that you've bought and paid for. So that can be a challenge, depending on your landscape, who you have supporting your agency and the background you have with that, but there are vendors out there that do support standards. There are vendors out there that support the open data, where you can use the data that's generated. So there are ways to overcome this. Another challenge is that there may be gaps in the coverage in some of the interfaces that have been standardized. Some of the transit standards aren't very mature yet. It's actually an issue not just in transit but it's an issue in other areas of ITS as well. Regarding these gaps, when we created the Data Exchange Format Specification, or DXFS, that was developed as part of that real-time system management information program that I talked about a few slides back, it was found that some aspects of data sharing were supported by Transit Communications Interface Protocol, or TCIP standard, that's been developed by APTA, and some were supported by a European standard called SIRI, which stands for Service Interface for Real-time Information. But neither of these standards supported all the user needs that were defined for travel conditions information sharing. So there's a case where, depending on the use of an interface and what you want to create, one standard might support some of it, another standard might support some of it. Regarding maturity, TCIP, for example, has been around for several years in its present form, but it's only now starting to be deployed. It hasn't been revised and updated too much based on actual deployments, so it's still a maturing standard as well, and TCIP is going to be discussed extensively in ensuing module, so you'll hear more about that. But standards are a good idea. Not all standards are mature and are ready to be used. So you have to be aware of that as you're shifting those paradigms that I talked about, from a non-standards-based approach to a standards-based approach. In the past decade, extensive progress has been made toward development of ITS standards so that options now exist for standards-based procurements, and more and more people are using standards that are out there. In terms of transitioning from a non-set to a set-based way of developing, certainly the FTA has been pushing the set-based deployment. It's part of the FTA policy on architecture and standards, and the use of standards is one of the key aspects of that systems engineering process. But these paradigm shifts can meet with resistance because they're not business as usual, and sometimes the benefits—I've articulated some benefits, but they may not be so easy to quantify—the idea that you improve interoperability or that you improve regional information sharing may not be so easy to quantify when someone starts questioning why do we need to change the way we've been working in the past—going to our proprietary vendor, for example, that you've been using for years. In the area of institutional challenges, there's three that I'll mention: a resistance to change—kind of following on that last slide—some gaps in existing skills, and the need for training to have skills to be able to use the standards. First off, resistance to change. Agency leadership has a tendency to have comfort with business as usual. Using standards or the set that goes along with them may face challenges if it isn't business as usual for your agency. When is this the case? For one, when the agency is not aggressive in applying technology. A strong case for standards-based deployment may need to be made to overcome an institutional inertia to applying technology. Note, the system engineering process in itself, with its early phases of things like concept of operations, can help to build this case for why you want to go do these things if you more clearly create that concept of operations that defines the needs, that defines the scenarios for the use of a system that you're putting in place. Another institutional challenge can be gaps in skills and training. If you don't have people in the agency with knowledge of the standards, it may make it more difficult to use them. If you don't have people with knowledge of system engineering, it may make it more difficult for people to embrace and to use that process. Basically training of agency staff is important to be able to address these gaps. Now, that is in fact one of the reasons that this set of ITS transit standards modules were developed, so that you can look at what standards to consider and how to tailor those standards. If you don't have the skills within your transit agency to be able to do this, one alternative is to contract for those skills. Hire somebody to do the front-end procurement development, do the front-end definition of what a procurement should look like in order to properly procure with the system engineering process.

Now, another activity that we'd like to talk about too is what are some of the technical challenges of using ITS standards—as I mentioned before—and the choices are: inconsistent industry support, some of the standards aren't mature, using the standards is a paradigm shift for the agency, or all of the above. Well, the correct answer, as we had in the other one, is all of the above. Each of these are potential challenges to using—technical challenges to using standards. You may get pushback from vendors who don't support them. There are some gaps, and depending on what you're doing that could be an issue. Technical skills are needed to properly specify standards in procurements, and you need to either have the skills or acquire those skills to be able to properly specify.

So, in summary, some of the high-level technical institutional challenges to using standards—the technical challenges that some transit standards aren't mature and some key industry vendors don't support those that are mature. In the institutional area, there may be gaps in skills that make it harder to implement. These can be overcome with training, which is the goal of these modules, as I mentioned.

The next learning objective, I'm going to talk about identifying the role of ITS standards in transit ITS applications. The first key point here is how are standards applicable, which really boils down to what standards are applicable and how do you apply them? Ultimately, if an agency wants to procure systems with ITS standards, they must start that process during procurement. So the second key point is how to do this, how to address standards during procurement. There are some other issues that arise with the use of standards, that are covered next, and finally, a summary of what agencies need to know to implement standards. What are some specific ITS applications which standards can be applied to? This list is kind of a laundry list of the technology-related services or applications that can make use of ITS standards: automated vehicle location, computer-aided dispatch, automated passenger counters, scheduling software, traveler information, transit signal priority, electronic fare payment. When I talk later about the list of courses that we have here, you'll see that many of these are going to show up. There's courses on transit management. There are courses, modules, on traveler information. There's modules that talk about transit signal priority, and we've got a module about electronic fare payment. So the different technology-based applications that use ITS standards, as I've shown here, are all going to be covered in the ensuing modules in more detail. So I'm here just providing a list of some of these. So if any of these applications-slash-services are something that you're going to be implementing in the future or are interested in implementing in the future, then I suggest you take a look at some of the future modules after this that will go into more detail about how standards are actually applied to doing things like computer-aided dispatch, and what those standards are, and how you would go about tailoring those standards for your applications.

So how do they apply the applications? As I mentioned, the later modules are going to cover that. Each of the modules, the ITS standards relevant to that area will be addressed and will be described in more detail. Some of the key standards that are going to be discussed in the ensuing modules are the TCIP standard, and there's actually two modules to cover just that, because that is a very important APTA standard that covers many, many interfaces in transit. SAE data bus standards. TransXChange of the SAE data bus standards is going to be covered in module five. TransXChange is a U.K. nationwide standard for exchanging bus schedules, and that's going to be covered in module five on traveler information as well. The Service Interface for Real-time Information, SIRI, is going to be covered in the traveler information modules. The NTCIP 1211 is the object definitions for signal control and prioritization, or transit signal priority, and that's going to be covered in modules eight and nine. And the contact-less fare media system standard is going to be covered in the module on electronic fare. Now let me talk briefly about the procurement link to standards. If you want an ITS standard to be used in deployment, you have to include that standard in the procurement package for the project. How do you specify the standard? Well, you can't just say, "Use the standard," or "Comply with the standard." Some agencies actually did this in the early days of ITS technologies and standards, and the result is they did not get a standards-based solution. Why? Because you have to tailor or customize the standard before it can be used. All standards provide a wide array of optional requirements, as I've said, and each agency must pick and choose what they need for their deployments. Customizing of the standards, or tailoring for individual procurements, is going to be a recurring topic in many of the modules in this series. Addressing changing technologies. But doesn't technology change quickly? We talked about how we're doing technology projects. Yes, technology may change, but the underlying functionality of that technology doesn't necessarily change. For example, think back to that audio-visual example I gave in the beginning, or the audio example. We went in terms of the—what actually plays music, from turntables through reel-to-reel tapes, to cassettes to CDs to MP3 players. They all have the same functionality, which is to play the music, but there's many different technologies but with the same functionality. Properly standardized interfaces will work no matter the underlying technology that's used to create the functionality, because the standard is going to specify the function—it's going to specify the data that goes across the interface, not the technology that's underlying to create that data.

So standards in fact reduce your vulnerability to technology change. If you're using something that's standardized, as technologies change, they continue to support a data interface or the protocols of an interface that is needed to support the overall functionality. Another issue, you may be interfacing with legacy systems. Deployments don't get to start with a clean slate; they build upon existing systems. How you handle this when you're specifying ITS standards—the key is the interface definition. As a part of project definition, it shows the new and legacy interfaces that are part of the project. If it's a new interface, if there are standards that apply to it, okay, then you use that. For the legacy interface, does it need to be revised? If it doesn't, then you go with the current definition of that data interface. If you need to revise the interface, maybe the legacy system—maybe you want to start to migrate that interface completely or partially towards the standard. So it just—so legacy systems don't prevent you from doing this, they just are one more consideration you have to have as to whether you're going to be needing to change those interfaces to legacy systems and whether you should consider some standardization as part of that, or not, depending on what the project entails. What transit agency staff are going to need to know to implement the standards? First off, what standards to consider. You have to consider this before you put out the procurement. You can't ask your contractor to decide. So as a part of the procurement, how do you specify the standard? That's one of the things you have to know. And finally, how do you test the standard so that deployment properly implements it? Just because you're saying the procurement of standard must be used doesn't mean the contractor will properly implement the standard. Part of the development should test that the implementation complies with the standard. Now, the rest of these modules are going to address that first question, what standards to cover, and to some extent they will get into the specifying standards as part of procurement. The testing of the standards implementation is going to be covered in some modules but probably not completely in this set of modules. That's a more detailed thing that may occur as other modules are developed.

So learning objective four. I mentioned some of the basic areas of transit and the transit systems that are covered by standards. They include CAD, AVL, electronic payment, traveler information, scheduling—all those kinds of things. To deploy projects using ITS standards, consideration must begin in the procurement package, in the procurement stage. Agencies need to decide what standards, how they're going to be tailored, and how they're going to be tested. The final thing I'd like to talk about is the roadmap of the modules that are coming up. I'm going to consider this roadmap in three different groups of people, and this is a repeat of what I presented in the beginning. I'm just going to talk about it in a little more detail now. I'm going to consider for decision makers, for the project managers, and for the project engineering staff. For the decision makers—by this we mean upper-level management or technical staff—we're going to drive decisions about what projects to deploy. The key modules for them beyond this one are the first module on transit management and the first module on TCIP. Now, the first module on transit management is briefly going to go and look at the transit management functions and systems within the context of that national ITS architecture I mentioned. Then it's going to go through a basic taxonomy that helps define when standards should be considered within those different functions, and it's going to talk about the different functions of transit management systems and also talk a little bit about the systems engineering process again and how it fits into that. TCIP, the first module there, is going to introduce TCIP, define what it is, give you a basic knowledge so that you can begin to apply it, and define what aspects of transit management TCIP applies to, consider the interfaces, and the different services that it can support. So those are the three modules that are considered recommended if you're a decision maker. Depending on what aspects of systems you deal with, optional modules might be the first module on traveler information, the module on fare payment systems, or module eleven, which looks at future technologies like connected vehicle and how they may apply to transit. Now, in the area—or for, rather, transit project managers, those first three modules are also recommended, but in addition the part two of some of those modules are recommended.

So the Transit Management Part 2 is recommended, and in this one it's going to introduce some of the hardware and software standards in addition to TCIP and how to use them, and it's going to help your participants identify what standards are most applicable to a particular situation so that you can reduce your lifecycle costs. And TCIP Part 2 of 2 is going to describe a suite of tools that have been developed that can make standards accessible to users, focuses on how you can access TCIP through a tool called TIRCE, which stands for TCIP Implementation Requirements and Capabilities Editor, and it's going to provide some case studies that show how TCIP and the suite of tools can be using in procuring ITS systems for transit devices. In addition, the module on traveler information is a recommended module for the transit project managers, and the traveler information module is going to look at the background that looks at traveler information systems and the standards that facilitate the implementation of these systems, briefly talking about traveler information systems, again, within the context of the national architecture, describing that taxonomy that will help define what standards should be considered where, and discussing the functions of the traveler information system so that you can conceptualize some of those technology implementations. There is a part two that is shown as optional here, and the part two for traveler information is going to provide an overview on how to identify, describe and apply the standards beyond TCIP to successfully procure and operate traveler information systems. It's going to get into things like SIRI, that I mentioned, and also GTFS, General Technology Feed Specification, that's been—it's not really a standard, but it is something that's widely used in the nation. Module Eight, Arterial Management and Transit Signal Priority, is going to introduce participants to the concepts of signal control priority systems, describe some of the components that make up the systems, and provide an overview of how to identify and use standards to procure and operate the SCP system. So that's what module eight is. It's recommended. Module nine, part two of that, is going to build on module eight, of course, and it's going to focus on using NTCIP 1211, object definitions for signal control and prioritization standard, that assist the user in specifying requirements of an SCP using the tools that are provided in the standard. So it's going to get more specifically into the NTCIP standard that relates to transit signal priority. And the other two options I showed there—again, the fare payments and the connected vehicle. If we go and talk about the roadmap for project engineering staff, the people that are actually going to have to do the procurements, develop the detailed technical aspects, then the recommendation here is for those basic modules; both the part one and the part two are recommended. And let me talk briefly about the final two—ten and eleven there. Module ten provides a comprehensive overview of standards, technology, and techniques associated with traditional as well as leading-edge electronic fare payment systems; and in module eleven, it's going to talk about the connected vehicle environment currently being researched by the USDOT, and it's going to look at some of the transit connected vehicle applications, some of the potential benefits, and what an agency might do to start preparing for some of these connected vehicle applications as we look into the future. So, in summary, the roadmap for transit management standards, recommended for all groups are this module, plus module two, the basic module on transit management, and module three, which is part one of TCIP. The remaining modules are optional depending on the types of person, their roles in the organizations, and the deployments being considered.

So, that is the introduction module. Now, to wrap it up, a little summary of what we've learned. ITS standards define how ITS systems, products and components can interconnect, exchange information—is the key missing point there—and interact to deliver service within a transportation network. One of the benefits of ITS standards is they can facilitate regional interoperability. Standards can be used as part of the systems engineering process. There are challenges to using the standards that are both technical challenges and there can be institutional challenges. Finally, these ITS transit standards can be used to support a wide array of transit applications, that include AVL, CAD, traveler information, transit signal priority, and electronic fare payment. Here's a list of some of the resources. If you go to the student supplement, you will see all of these. I highly recommend the e-primer modules on public transportation, will talk about ITS in transit; and the e-primer on systems engineering will give a little more explanation about the systems engineering process. As we said, the next course in this series of courses is Module Two, Transit Management Standards. It's going to cover technologies and systems that facilitate and automate operations, planning, management, safety, security and data management functions of the public transit system. Thank you very much for completing this module, and we'd ask you to please provide feedback on this module and how you felt about it. With that, thank you very much for attending the presentation of the module.

#### End Module_1__Introduction_to_ITS_Transit_Standards.mp4 ####