ITS Transit Standards Professional Capacity Building Program

Module 3: Transit Communications Interface Profiles (TCIP), Part 1 of 2: Introduction to the Standard and Transit Architectures

HTML of the Course Transcript

(Note: This document has been converted from the transcript to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included.)

Mac Lister’s Introduction

ITS Standards can facilitate the deployment of interoperable ITS systems, and make it easier to develop and deploy regionally integrated transportation systems. However, these benefits can only be realized if you know how to write them into your specifications and test them. This module is one in a series that covers practical applications for promoting multimodalism and interoperability in acquiring and testing standards-based ITS Transit systems for public transportation providers.

I am Mac Lister, Program Manager, Knowledge and Technology Transfer in the ITS Joint Program Office of the USDOT and I want to welcome you to our newly redesigned ITS Transit standards training program of which this module is a part. We have worked closely with the Federal Transit Administration and the American Public Transportation Association to develop this material. We are also pleased to be working with our partner, the Institute of Transportation Engineers, to deliver this new approach to training that combines web-based modules with instructor interaction to bring the latest in ITS learning to busy professionals like you.

This combined approach allows interested professionals to schedule training at your convenience, without the need to travel. After you complete this training, we hope that you will tell colleagues and customers about the latest ITS standards and encourage them to take advantage of the archived version of 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 website at ITS PCB Home.

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

Jeffrey Spencer’s Introduction

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

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

Dr. Jerome Lutin: Good afternoon. This is the ITS transit standards professional capacity building program Module 3: Transit Communications Interface Profiles (TCIP) Part 1 of 2: Introduction to the Standard and the Transit Architectures. And this was produced by Ayers Electronic Systems Critical Link and Jerome M. Lutin. Throughout the presentation this activity slide will appear indicating that there is a multiple choice pop quiz following this slide. You can use your computer mouse to select your answer. There’s only one correct answer for each question. Selecting the submit button will record your answer and the clear button will remove your answer if you wish to change your mind and select another answer. You will receive instant feedback on your answer choice.

I’m Jerry Lutin, Jerome Lutin. I’m retired senior director of statewide and regional planning. I was with New Jersey Transit for 20 years and I’ve worked on the TCIP program under the auspices of the American Public Transportation Association. And I also am one of the several instructors that teach the National Transit Institute Course on TCIP. So let’s get started.

The target audience for this today consists of a number of different people and positions. So if one of these positions describes your job, you’re in the right place. And if not, you’re actually going to learn things that may help you expand your role and be able to attract more business into your area. Over the past ten years, the U.S. transit industry has spent $18 million on new technology including communications, fare revenue, and information systems. So you should become a part of this target audience. There are several prerequisites that we recommend for this course. This first is module one of this professional capacity building standards course, which is the Introduction to ITS Transit Standards. Module 2 is Transit Management Standards, offered by Carol Schweiger, part one of two. And if you fall into the category and you see here we have a table that shows whether you’re a decision maker, a project manager or a project engineer you should pick the prerequisite program that kind of best fits your job description. And if you are a project engineer and going to be working hands on with these standards then module five, transit management standards part two of two also would be a good prerequisite for you.

There are a number of curriculum paths that have been presented for each of the different categories in the matrix, whether you’re a decision maker, whether you’re a project manager, and whether you’re a project engineer. And in the downloaded PowerPoint presentation you can review these at your leisure and decide how you would like to proceed through this curriculum. We’re going to go through seven learning objectives today. Learning objective number 1 is to describe the purpose and the contents of the TCIP standard. Two, we’re going to recognize what’s involved in growing traveler information in communication systems from basic systems to regional multimodal applications. Number three, explain how TCIP is used to procure and implement transit ITS systems. Four, illustrate the need for and structure of a transit agency architecture. Five, articulate the fundamentals of exchanging information among transit business systems and devices using the TCIP building blocks. Number six, we’re going to summarize the content of the TCIP standard tools and available resources. And seven, we’re going to provide some examples of who is using TCIP.

So let’s start with learning objective number 1, describe the purpose and contents of the TCIP standard. In this learning objective, we’re going to review the requirements to these standards. We’re going to give you an overview of TCIP volumes one through four. And we’re going to describe the difference between normative and non-normative content. Requirements to use standards. As I mentioned earlier over the past ten years the transit industry has spent $18 billion on ITS systems. Now, transit standards, ICS transit standards are voluntary within the industry. They are not required by law. They maybe be required by policy within your organization. ITS Standards are consensus based. They’re developed by working groups of industry experts who ballot the standard. We’ll talk about what balloting means in a minute. Standards are open and not proprietary. They can be used by all. And the ITS Standards are really the nuts and bolts that you need to use to connect transit management systems.

TCIP stands for transit communications interface profiles and it’s important that you not confuse with this TCP/IP, which is a protocol used for Internet communications. TCIP is the ITS Standard for exchanging information among transmit ITS systems and components. It is published by the American Public Transportation Association, APTA. There’s a difference between a protocol and a profile for data exchange. A protocol contains rules and a profile could contain both the rules and content. TCIP references other standards and definitions and this helps to ensure a functional system by adapting proven standards and cross-discipline consistency. So it helps to simplify integration between transit standards and non-transit systems. The purpose of the TCIP standard it defines standardized interfaces for the exchange of information among transit business systems, sub systems, components, and devices primarily for use within the transit agency. However, it does allow transit agency to comply with other federal requirements to implement regional architectures because it provides a standard to exchange data with other transportation agencies, not only within your agency. And finally, on this point there are other data exchange standards and protocols such as Google’s GTFS which you may have heard about which can be used to communicate information to the public. But they don’t necessarily incorporate a lot of the data that we need to manage a public transit system such as the operator ID or vehicle mechanical health. The history of the standard goes back to about 200—actually it goes back to the late 1990s. It was the primary transit component of the USDOT ITS Standards Initiative. It was initially funded by the U.S. Department of Transportation. And it was worked on by the Institute for Transportation Engineers and then it was transferred to APTA in 2001. APTA added material including dialogs and file transfers, a model architecture, concept of operations, and transit signal priority. Now, TCIP was balloted and approved as an APTA standard in 2006 and the balloting of the standards is done by technical working groups of stakeholder entities, primarily transit agencies, vendors, and consultants. And the standard is considered approved when the consensus is achieved by 75 percent of a representative sample of voting entities. Now, not all of the TCIP areas, business areas were balloted. The fare collection business area was determined to be not ready for balloting so that has not been balloted and it’s awaiting development in other areas of the fare collection standards. And the current version is TCIP-S version 4.0 and standards tend to be dynamic and they get changed and developed over time. So you will see that different versions will appear not only in a TCIP standard, but others standards as well.

TCIP has been published in four volumes. Volume 1 it contains an introduction and overview of the standard. It also contains some really useful information in terms of concepts of operations for ten business process areas that are found in most transit agencies. And it provides guidance on conformance and procurement. TCIP presents much more information than a set of rules, which you typically find in a standard. It includes profiles which are the actual building blocks to exchange information between business systems. And volume two actually contains these building blocks. TCIP uses extensible markup language, XML, which is a widely known and supportable data exchange format and it allows for other syntaxes to be used. And actually, Volume 3 actually contains the XML schema. So as you can see, the document includes not only the rules but actual, as you will see, message sets already coded in XML that can be assembled to use for your agency. Volume 4 contains six technical appendices, only four are used. Annex K includes some sample procurement documents which can be very useful, first of which, is a profile requirements list, DRL, which is a mechanism for conveying a transit agency’s requirements to a developer. And on the developer’s side a profile implementation conformance statement or PICS, which actually describes a vendor’s product and that can be used as part of a proposal that’s being submitted.

I want to talk to you a little bit about normative and non-normative content. Normative content is defined as that which has been balloted and is actually used to implement the standard. It includes the codes and the messages and the actual profiles and certain conformance information. Non-normative material also is included in the TCIP standard but this is material that has not been balloted but it’s included to explain how TCIP can be used by transit agencies and product developers. It provides context for the normative portions and it also contains technical materials that has been developed but not yet deemed mature enough for balloting such as the fare collection area. There is a TCIP task force established under APTA, which is responsible for TCIP developments and as I mentioned it’s determined that fare collection is not yet mature enough for balloting.

At this point, we are going to undertake our first activity. And this is the quiz. What is the purpose of the TCIP standard? And the answer choices are: a) to ensure that all transit agencies conform to the same requirements, b) federal requirement on uniformity for all procurements, c) exchange information for transit ITS systems and components, and d) TCIP is the only standard allowed for transit ITS systems. Now, let’s take a look at the answers. The correct answer is c) exchange information for transit ITS systems and components. A, is incorrect. Agencies can develop their own requirements to meet their needs. B, incorrect. TCIP use, as we said before, is voluntary. It is not required by the federal government. And d, incorrect, TCIP is only one of a number of standards that can be used.

So we are going to go on now to a second quiz here, which is what is the role of balloting in developing a standard? And the answer choices are: a) to elect members to standards bodies, b) to ensure that a consensus has been achieved on the standard, c) that transit agencies—a transit agency majority vote is needed to create a standard, and d) to ensure that federal reps agree to require the standard. Okay. Now, let’s go to the answers. And the correct answer is b. Correct. Industry working groups use balloting to develop standards. A is incorrect, standard bodies are composed of industry volunteers. They’re not elected. C is incorrect. The standards are created by industry groups with a variety of stakeholders not just transit agencies. And d is incorrect. The federal government does not require ITS Standards by law.

So let’s go on and now summarize what we’ve learned in learning objective number 1. We’ve described the purpose and the contents of the TCIP standard. We talked about the requirements to use the standard, a little bit about history and development, an overview of the volumes, and we discussed the difference between normative and non-normative content.

So at this point we can move on to learning objective number 2. And here we want to recognize what’s involved in growing travel or information and communication systems in a dynamic way from basic systems to regional multimodal applications. And this involves talking about planning for communications and discussing legacy systems, technological change, and obsolescence.

Planning for communication systems, these systems are just absolutely fundamental to transit management. We need to accommodate data collection and distribution. We have large vehicle fleets that operate over significant distances. We’ve got facilities at multiple locations. We’ve got staff operating in the field. And our customers are spread over a region. So communications between all of these different parts of the industry are necessary. And when we plan for these we need to understand that we need to add capabilities over time. Systems that can no longer be supported need to be replaced. We know that technology becomes obsolete. But the most important thing is that we need to be able to interchange information seamlessly and flawlessly. Legacy systems technological change and obsolescence. The vehicle lifecycles for transit agency typically range from twelve years minimum for a bus, to thirty years or even more for rail vehicles. But we’re finding that computer technology becomes obsolete in 18 to 24 months. Replacement parts are difficult to find and different operating systems and storage media can be phased out and not supported by vendors. And we find that existing systems may be incapable of accommodating new software requirements. We expect to replace components and systems several times during the life of a bus or a rail vehicle. So we may want to buy new vehicles and we may want to take our existing radios and put in them. But at the same time we’ve got to understand that a lot of the electronics that we buy are eventually going to fail and are going to need to be replaced. And the management systems are going to change as well. We are constantly being asked to provide new information to other managers and particularly new information to our customers.

So now let’s go on to the next activity. Which factor is most likely to lead to changes in communication systems? And the answer choices are: a) new technology becomes available, b) transit systems expand into new modes, c) new management requirements increase information demand, and d) new transit vehicles require new radios. Tough quiz. And let’s look at the answers and the correct answer is c) transit managers are seeking new kinds of information and more data to better manage their systems. A is incorrect. The availability of new technology does not mean that your existing system will not continue to meet your needs. B is incorrect. Transit systems usually can add new vehicles and facilities without necessarily making fundamental changes to their communication systems. They may add radios. They may add other elements but they might keep the same architecture and fundamental technology. And d, new vehicles may be configured to work with existing radios.

So let’s summarize learning objective number 2. Again, we recognize what’s involved in growing traveler information. We need to plan for our communications because they’re fundamental to managing our business. And we need to be able to add capabilities, particularly as new management information demands are placed on the system. And the second point is that systems that—I have to recognize that we do have legacy systems. And that systems maybe need to be replaced over time. And given that we may have a variety of components working together, we’re going to need to make sure that we can exchange information seamlessly and flawlessly.

Let’s go on to learning objective number 3, explain how TCIP is used to procure and implement transit ITS systems. We’re going to talk about procurement. We’re going to talk about how to facilitate competitive procurements and how systems can be integrated using TCIP. ITS technology applications, transit ITS projects are very often implemented incrementally in an agency and many times through separate procurements. Example, an agency may purchase a CAD/AVL system in year one and then in year five they may want to expand and purchase a multimedia traveler information system. And sometimes it can be difficult to integrate these systems and they need to exchange data in order to maximize benefits. And one of the things that we also find within transit agency is that many agencies do not have the staff and the technical capacity to define interfaces and to really deal with the problem of purchasing new technology in a comprehensive way. So help is available. There are experienced outside consultants who can help prepare TCIP procurement documents that will enable competitive procurements and systems integration and you should feel free to reach out to them. And also to peer transit agencies, many of which are willing to share some of the work that they’ve done with TCIP. TCIP can help overcome some technical challenges. Exchanging information with subsystems within an agency and between agencies, especially when it involves integrating legacy systems and defining requirements for connections between a subsystem being procured and future subsystems. And finally, accommodating future system growth when you know you need to add components and elements to it. It also can help—it can make it easier to deal with multiple vendors and allow you to use vendors because if you’re locked into one you really lose flexibility and control. It also allows you to upgrade your hardware to make sure that your systems will talk to each other. And it also is going to make the available transit data to third party developers a lot easier. And it also can help overcome some of the challenges of procurement lag in terms of the amount of time it takes to get a procurement together.

TCIP helps facilitate competitive procurements because it provides a nonproprietary standard. It allows you to go beyond a single vendor when you’re looking to add or upgrade a system. And it allows the agency to select subsystems that fulfill its need rather than limiting selections to only those that can be integrated with the proprietary standards and interfaces used in an existing system. You may have a fare collection system that was developed by vendor A, and a radio system that was developed by vendor B, and it can be difficult to integrate those two. But if you have standards for the exchange of data using TCIP, that challenge can be overcome. So TCIP has an approach that recognizes that while we’re dealing with a standard, each agency operates differently. And TCIP provides a large variety of information exchanges that agencies can use basically on an a la carte basis according to what you need. And it is not intended to be adapted as a whole or all at once. You can purchase TCIP compliant business systems gradually over time. And it will allow you to maintain your legacy systems. It really minimizes impact on developers and vendors. It does not specify interactions within the components that your vendor is developing. It does provide standard formats to facilitate the exchange of information from one vendor to another vendor. And it doesn’t really limit an agency’s communication architecture.

This is a diagram that shows diagrammatically how TCIP is used in agency procurements. At the very top level is the document that you use to procure systems and agency request for proposals or RFP. And you can see that’s wrapped around the agency ITS architecture, which also is a long-range planning document that we talked about. Underpinning this on the left are the agency terms and conditions that your procurement department and legal department provide. Requirements imposed by legacy systems. And the third leg under there is other ITS standards that we use. On the right hand side, it shows the TCIP, which is a set to building blocks that include file transfers and data elements and dialog patterns, all of which we’re going to talk to you about in a little while.

This diagram is a graphic model of how—where the TCIP data exchange occurs. On the left you see a rectangle that represents transit subsystem A. In this case it could be a data repository. And on the right transit subsystem B could be the scheduling system. These may have been developed by different vendors but using the TCIP standard in the middle provides dialogs, file transfers, and messages as an interface standard that works over the communication link between these two systems. So it enables those systems to talk to each other and exchange information using TCIP exchange protocols.

Okay. We’re now at another activity and this time we’re going to ask you which is a key risk in transit ITS procurement? And the answer choices are: a) separately procured systems won’t communicate, b) transit agencies may be overcharged for ITS systems, c) legacy systems do not have backups, and d) standards are not available to integrate systems. So let’s look at the answers now. And the review of answers, the correct answer is a) separately procured systems won’t communicate. And without use of common standards systems developed by different vendors may not be able to communicate. B is incorrect. Transit agencies can use low price as a way to evaluate bids to avoid overcharging. And incorrect a legacy system is typically defined as one that is outdated but it may still include its own back up features. And d, it’s incorrect because there are a number of standards that may be used to integrate the systems including TCIP.

Let’s go on to another question for you. Which is a benefit of using TCIP and transit ITS procurements? And the answer choices are: a) to standardize the internal components of a vendor’s ITS system, b) to lower initial procurement costs, c) to allow multiple vendors to compete, and d) to expand the bandwidth for communications between systems.

And the answers are—the correct answer is c) to allow multiple vendors to compete. TCIP is intended to allow many vendors to offer systems that could be integrated. A is incorrect. TCIP is intended to standardize only the interfaces between systems, not the internal components. B is incorrect. In the long run, TCIP may help reduce costs but there’s no guarantee. And d incorrect because bandwidth is a communication system property. It is unaffected by TCIP, which is a property of the information that flows over the communication system.

So summing up learning objective 3. We explained here how TCIP can be used to procure and implement ITS systems. It provides a nonproprietary standard that allows you to go beyond a single vendor. It allows you to select subsystems that best fulfill your needs, rather than limiting those to those that are provided only by one proprietary standard and one vendor. And c, it allows each agency to select those capabilities within each interface to reflect your particular agency’s needs. It’s intended to operate alongside legacy interfaces and even over the same communications and media.

Let’s go on to learning objective number 4. We’re going to illustrate the need for and structure of a transit agency architecture, we’re going to talk a little bit about capital and project planning for transit ITS, the linkage of the agency architecture to the national architecture and regional architectures. We’re going to talk about business areas and concepts of operations. How you diagram an agency architecture and we’ll give you a case study showing a development of a typical transit agency architecture.

Capital and project planning for transit ITS. Transit ITS system acquisitions are usually included as projects in the agency’s capital program and budget, which typically is a document that you produce every year and it basically includes what you’re going to spend in the next year in this particular area. And because it may not always fit in the budget, you may have to implement things in phases. You’re going to do certain work and buy certain products in year one. You may buy certain other products in year two. So the overall planning framework for an ITS project is called an architecture and the architecture explains how all systems are integrated and phased over time, not necessarily all systems but just those systems that you want to use to interchange information and that are going to work together.

There are, in the literature, generic architectures. There is a generic national ITS architecture and we are providing in our TCIP documentation a TCIP model architecture. And on the right hand side, the specific implementation of these generic architectures occur first at the regional level because there is a requirement to have a regional ITS architecture. And second, in a specific transit agency architecture that’s developed specifically for your transit agency.

The TCIP model architecture is a generic illustration of ITS subsystems and information systems the transit agency might employ. And it gives you a whole host of different business systems to procure from. It’s organized in a very similar fashion to the national ITS architecture, with similar diagrams. It shows how components are connected using communications. And not all agencies are going to want or going to have all components but all agencies are going to have some of the components and the architecture. And there are actually for those of you who are in the project engineer stage and need to understand some of the more technical aspects, there is a mapping within TCIP in Annex G that shows how the TCIP model architecture logical entities map on the national ITS architecture processes. So there is a good relationship there that you may find valuable to use.

This diagram is very simple—this is the TCIP model architecture. And in the center it shows transit business systems and it shows on the left the travelers. It shows external business systems, and mobiles, and portable environment, and transit field environment. And in earlier modules of this PCB standards course the national architecture has been shown and presented. So this is a version of that that’s been tailored for the transit agency world and it is—in the next slide we’re going to drill down a bit to show you all of the various business systems. Now, obviously, you can’t read all of these in here, but in the graphics that are provided with the student supplement and in the TCIP documentation itself, you will find this diagram and it shows all of the various kinds of business systems that you might want to acquire including things like a transit security system, a data repository, a fare collection system, a garage server to keep track of the buses. These are all different subsystems and components that you can pick from as you think about what your ITS needs are for your agency. So the transit agency ITS architecture is modeled after a TCIP architecture. It will be specific to a transit agency. It may look something like that we showed you on the previous slide, but it’s going to capture your specific near-term and long-term plans for technology implementations. It also can illustrate the agency’s legacy systems and the plan systems interfaces, networks, external systems, and the physical components as well.

Okay. What are the benefits of a transit agency ITS architecture? Well, it provides a framework for interdepartmental ITS planning and coordination because it gives you a visual representation of the plan and the vision for ITS development within the agency that you can share. It’s going to depict the internal and external interfaces between subsystems. Basically, it is going to be an electronic or visualization of the electronic model of your agency’s business.

Now, within TCIP we’ve identified ten core business processes that have been specifically developed within TCIP, and these include security and incident management, public transit vehicle operations, revenue and fare collection, scheduling, personnel and work assignments, asset management, which is basically vehicle management, and customer information, data repository, spatial data management, and transit signal priority. And TCIP has actually developed a lot of the messages and dialogs within these business processes. The TCIP concept of operations describes these ten core business processes. It explains how TCIP can be used to facilitate communication among the transit apps. It provides you with a typical agency implementation. It doesn’t include all possible processes, but it’s a good start for your agency. And it allows you to examine how your agency’s business processes relate to the TCIP core business process as a template. And there are additional transit business processes that may be added in the future. We’ve already added light rail to the basic business processes. Para transit is one that is probably going to be implemented in the next update of the standard.

To give you an example we’re talking about. The scheduling process. The purpose of the scheduling process is to develop transit schedule products and distribute these products to a data repository or other transit business system. And within this scheduling process, we have to gather the data for schedule writing and I think where does the data reside for these things? Develop the scheduling projects to find what they are and that includes typically writing the actual schedules, the block building—which explains what the vehicles are going to do each day—and run cutting which is going to explain what the driver is going to do. And it needs to distribute the scheduling products to the other parts of the agency and the other business systems that need to use this information.

This is a diagram taken right out of TCIP, which is a basic part that shows with a circle on top the scheduling system, and at the bottom, the data repository, the arrow shows that the scheduling system is going to provide information to the data repository. And in the legend it shows the different pieces of information that are going to be exchanged, including things like operator assignments, vehicle assignments, master schedule, trip detail patterns, time point list, and a whole host of other things that need to be transferred to actually explain what is being produced by the scheduling system. And this shows how those products and where those products may be distributed to once they get to the data repository. So you can see here this is the element of an architecture. It shows business systems and it shows information flows. We’ll elaborate on that as we go forward.

We’re going to do a case study right now and give you an example of how this might work in a transit agency. And we’re basically here showing you the diagrams. This is a baseline architecture for an agency. It’s stage zero, current year. And at the top of this diagram we see that there are three blue boxes. One says PICS system. The second says scheduling system. And the third said bus manager. So each of these communicates with a data repository, the agency database. On the bus we see that there are several boxes showing the mobile architecture of the bus. We have a fare system which is shown in yellow. There is a fare box computer and a fare mobile data terminal and information is sent from the fare mobile data terminal into the fare box. Maybe the driver is actually ringing up the fare type as he registers a fare. And then there is a short-range infrared communication that takes place between the fare box and the fare central computer when the bus gets back into the garage and is serviced and the fare box is empty. And you can see there are a couple of other boxes on the bus, a head sign controller, and a drive train computer. And they’re not shown talking to anything here. So what we see here are different business systems and sometimes these are physically independent, sometimes they are logical units. And they’re linked by different kinds of communications links. And in this particular diagram the red arrows show wired, basically Internet connections, typical TCP/IP connections not TCIP.

Okay. Let’s see that in year three we’re going to add to that architecture, and in year three, the agency has a number of additional components that they’re going to add and these are going to create new information flows. They’re going to want to add an itinerary planner for passengers and users. They’re going to want to be able to record digital announcements, the buses at Elm Street and record that so that they can have an on board annunciation system. All that stuff goes into the agency database. On board the bus they’re going to be adding an automatic vehicle annunciation system and an automatic vehicle location system. We’re going to be adding vehicle monitoring for vehicle health but all of these, again have to be linked. So this is the next stage of the development. And they’re going to be adding some wireless communications links between the automatic vehicle monitoring system and the base bus manager. So, again here, we’re adding communications capabilities—we’re adding business systems. Let’s go ahead, another stage and this is the second stage. This would be in year five. And here the transit agency is adding even more components. So you’ve seen in these three diagrams the business systems growing in the architecture, the dynamic nature of it, and the communications links, and how the different communication links are being shown here by different colors because we don’t have to link everything the same way. We can have long-range wireless communication. We can have wired Internet connections. And we can even have some custom things like infrared, and special other standards that might provide a system such as between the vehicle location system and the vehicle annunciation system. So that gives you a depiction here of how to diagram an agency architecture.

The implementation process of the architecture is first defining the architecture using the block diagrams, defining the information flows across the interfaces, specifying the requirements that support the information flows across each interface, and verifying conformance after procurement. As we go through the rest of this presentation you’re going to get to see how TCIP helps in the architecture implementation process.

Okay. We’re now ready for another activity. And at this time, the first question we’re going to pose to you is “Which answer best describes the use of an agency architecture to aid in capital and project planning?” And the answer choices are: a) shows the buildings needed to house new systems, b) specifies the cost of systems for budgeting, c) specifies how vehicles communicate with control center, and d) show which systems need to interface with other systems. Okay. Let’s go to the answers, the review of answers, and the correct answer is d) the architecture explains how all systems are integrated and phased over time. A is incorrect. The architecture in this context doesn’t apply to buildings but it applies to systems. B, the architecture is incorrect. The architecture can help budgeting but it does not include the cost. And c is incorrect, the architecture would include vehicle-to-base communications but it’s not a requirement. The architecture could only include fixed facilities if that’s what you chose.

Another quiz for you here. What are the key elements displayed in an architecture diagram? And the answer choices are: a)all transit vehicles and fixed facilities in a system, b) all business processes in an agency concept of operations, c) only those components that are TCIP compliant, and d) selected business systems and data flows. And the answer is d) selected business systems and data flows, correct. Architecture diagrams generally show selected systems and components as boxes or circles and data flows the lines. So the architecture is to show how components work together. A is incorrect. The architecture should include representation of only those elements that are linked by communications and information flows. B is incorrect because only those business processes that exchange or will exchange information need to be included in the architecture. And c is incorrect. The architecture should include all components that exchange information not just TCIP. We can use other standards as well.

Summing up learning objective number 4. We looked at the overall planning framework for an ITS project and that’s called an architecture and the architecture explains how all systems are integrated and phased over time. The transit agency architecture is modeled on the national ITS architecture and it can be included in a regional architecture to show interagency data flows. And finally, it includes a concept of operation that includes ten common business areas that are going to be typically used by many transit agencies. Continuing our summary diagraming a transit agency architecture uses block diagrams to show subsystems and lines to show information flows. And the case study showed how an agency architecture can be used to show how systems will be added over time and how they’re going to be integrated.

Let’s go on to learning objective number 5 articulate the fundamentals of exchanging information on transit system business systems and devices using the TCIP building blocks. And we’re going to talk about batch and real time information exchanges. And we’re going to talk about the actual building blocks, the data elements, data frames, messages, and dialogs.

The first thing we want to talk about is file based transfer. This is how we transfer data without the use of dialogs in a non-real time manner. And typically a computer application, it could be your scheduling system, it saves data in a file and the file is transferred to another system. It could be in a variety of ways. You could actually put it on a USB drive and hand carry it to the next department and plug your USB drive in and download the data to the next department or it could be transferred over the Internet a variety of ways. But the file is transferred to another system. It’s loaded and read by another computer application. And as I mentioned, it sometimes involves human interaction. And this interaction does require an agreed upon description for the files and TCIP messages will provide that description so that the two systems can exchange data easily.

Dialog based transfer is a machine-to-machine real-time transfer of data that is done by dialog. And a dialog specifies the operational purpose of the exchange of information. It has a particular pattern. It includes messages in the dialog. And the dialog may explain special conditions, constraints, and it also may explain its relationship with other dialogs. So it’s a little more of an involved real-time flow of information than we had in a simple file transfer.

Dialogs do not define how data is stored, translated, and manipulated. Nor do they describe how the data is formatted and presented to human users. It’s only the machine-to-machine exchange that we’re dealing with here in this TCIP dialog. And it does not define how a system’s components trigger or initiate dialogs. That comes from within the system and within the components themselves and it does not detail the interactions with human users.

This graphic shows diagrammatically how systems exchange data and the gray rectangles down below illustrate a subscriber and publisher kind of exchange where on the left we have a normal execution. In this case, we have a data repository, which is a subscriber. That system wants to get, in this case, scheduling information from the scheduling system, which is the publisher. So the data repository will say it’s maybe checking in at every morning, “Hi scheduling system. Can you give me the schedule for today?” And, in particular, here I’m interested in getting a list of the time points. And the scheduling system says “Yeah, I got that. Here’s the list of the time points for today.” Now, on the other side, on the right side, we have what we call an abnormal execution. A data repository says “Hi scheduling system, can you give me the list of time points for today?” And the scheduling system says “Sorry I don’t have them today.” And so it will return an error notice. So this is an example of a very simple dialog pattern for exchanging information one with a normal outcome, where the requested information is there and the second for an abnormal outcome when the publishing system doesn’t yet have the data that’s being requested.

Now, within this, TCIP has a hierarchy of building blocks that help you define the data. And we kind of divide this into really two different categories, the “how” and the “what.” The “how” the data is transmitted are done with file transfers which are non-real time and dialogs which are real time machine-to-machine. And we also have the ability to store dialog patterns so that we can use them. The “what” which is included in this at the highest level of the “what” is messages. And messages are comprised of data frames and data elements. This is a graphic illustration that shows you the distinction between the “how” and the “what.” There’s a blue line here and the boxes above the blue line show how the data is being transferred. On the left you see a box that shows file based transfers that we mentioned and on the right is dialog transfers and that’s composed of dialogs themselves and the stored dialog patterns that we get to reuse. That is the “how.” The “what” that we’re transferring, as you can see the highest level of that are messages and below that are data frames. And data frames can also feed into other data frames. And at the bottom is the basic building block which are data elements. And we’ll define some of these for you.

Okay. A data element is an atomic piece of information related to a person, place, thing, or concept and we have a couple of examples down here. The first is SCH-TimepointID which is the TCIP code for a time point identifier. And this could be an alphanumeric identifier. It could be ABC123 and the next one is SCH-TimepointName, which is actually the time point name and that could be, you know, 125 Oak Street or more likely Oak Street at Elm Street. And the last one, as you can see, the last example is LRMS.Latitude, which represents the latitude in micro degrees. This actually uses a different standard called the location referencing message specification. And it’s used in conjunction with TCIP because we don’t want to reinvent the wheel. LRMS is out there. It’s a widely used standard in the ITS world. And so we just adopted that and incorporated that.

A data frame is a grouping of data elements and other data frames to describe more complex concepts. And the groupings help to organize information to describe or identify objects. For example, SCH-TimepointID identifies a time point and that could include the alphanumeric identifier, the time point ID. It could also contain the time point name or it could include something else like maybe there’s an agency number or name. And another part of this could be SCH-TimepointInfo, which describes the time point. So both of these could be data frames that include other data elements and possibly other data frames. So it’s a hierarchy. A message is an aggregate of data elements and data frames into a larger more complex structure. And a message is a complete understandable one way communication that consists of data elements and data frames that convey both meta data and information. For example, we could have a message that says it’s SchTimepointList, which is a message that actually transmits the list of all of the stop points along a route, in a system, or for whatever portion of the system that you’re looking for to be sent between one system and another.

TCIP already has set up in it eleven different dialog patterns. And the first one in here is publication because publish-subscribe tends to be one of the most commonly used types of dialogs between machines and between different business systems. We also have something called command response and report, a silent alarm, a load and unload, voice radio call because this could include meta data about initiating a voice operated call. The dispatch center doesn’t necessarily want to be alerted by hearing from a driver all of the time. They might want to see it on a screen that vehicle XYZ driver is calling in and then they can press a button and perhaps talk to that person on the radio. And then there’s dialog for signal control and prioritization. There’s something called a blind notification, a push, and a traveler service request. These are all very various patterns for dialogs that are included in the TCIP profiles.

Alright. It’s time for another activity. Now, we’re going to ask you “How can TCIP be used to transfer data? And the answer choices are: a) transfer data in files and real time dialogs, b) only transfer data in real time dialogs, c) transfer data in publish-subscribe mode, and d) transfer data only over the Internet.

Alright, let’s look at the answers. And the correct answer is a. Correct TCIP can transfer both batch file and real time data transfers. B is incorrect because TCIP can be used to transfer data in batch file transfers as well as real time. Incorrect, we can transfer data through eleven different dialog patterns for TCIP not just publish-subscribe. And d is incorrect because TCIP’s neutral with respect to electronic data communication. It can be over the Internet. It can be over other types of communications mode as well.

Now, we have another quiz for you. What statement most accurately characterizes a TCIP dialog? And the answer choices are: a) a sequence of data elements, b) a digital voice communication pattern, c) a structured exchange of messages, or d) a message with two parts? Let’s look at the answers. And the correct answer is c. TCIP dialogs typically follow a defined pattern that can be repeated and it provides a structure. A is incorrect a TCIP dialog is a sequence of messages. B is incorrect because TCIP dialogs are used to transfer data. They might be transfer meta data about a voice communication pattern but not the voice communication itself. And d is incorrect. A dialog contains messages, which may have many parts, not just two parts.

So let’s summarize learning objective number 5. We have talked about the fundamentals of exchanging information. And we know that TCIP can be used to transfer data through file transfers in which a file can be transferred from one system to another or possibly on a USB drive. Or it can be transferred in real time using TCIP messages and dialogs. TCIP is composed of building blocks that includes data elements, which are atomic pieces of data. Data frames which are standardized groupings of data elements and messages, which are complete one way communications that include data elements and data frames. And dialogs, which are structured real time exchanges of messages that specify an operational purpose, the dialog pattern, the messages to be used, and any special conditions or constraints.

Let’s move on to learning objective 6, to summarize the content of the TCIP standard tools and available resources. We’re going to talk about the downloads available from APTA. We’re going to talk about a suite of tools that actually comes with TCIP. And we’re going to talk about within those the TIRCE and the message builder and test console. And finally, we’re going to overview the National Transit Institute onsite training for TCIP.

TCIP downloads are available from APTA. If you just go and google APTA TCIP you will get the link. That will actually take you to the documents that are stored on the website and includes the current version TCIP, the baseline version, which was the original one, a working version, and it archives all of the previous versions, in case you need to look up something that was used in the past. It includes tools to verify TCIP conformance and these, again, are downloadable, the TCIP test console. And it includes a download called TIRCE. TIRCE stands for TCIP implementation requirements and capabilities editor and that will allow you to develop procurement documents.

Okay. This slide gives you a diagrammatic representation of the TCIP support tool suite. And down the middle we see a series of gold boxes that are labeled with the different TCIP tools. In the first phase here we talk about interface definition and that includes defining requirements, specifying the interfaces, and producing TCIP-compliant documentation and that’s done using the tool TIRCE. The second stage is procurement and in this TIRCE is, again, used to provide an automatic comparison of vendor responses to the RFP requirements that were produced by TIRCE, as well. Developing the actual interfaces use the TCIP message builder. And the test console, which includes the TCIP interrogator and the TCIP responder. And this gives you the ability to generate TCIP messages and simulate the interaction of components and it allows you to log and view the data exchanges using actual or simulated TCIP messages. And, again, part of that test console, the interrogator is used at the verification stage and it gives you an automated way to test—to verify that a message exchange it complies with the TCIP standard. So this is all packaged with TCIP, with the standard. It includes not only the standard but we get the building blocks and we also get the tools to implement it.

TCIP implementation requirements and capabilities editor, TIRCE, guides you through a step-by-step process of converting a functional requirement into a TCIP compliance specification. And it uses the top down systems engineering approach to defining the data exchange interfaces between transit components. It needs to specify what information will be exchanged and the manner in which the information is exchanged. TIRCE puts out several very useful elements. The first thing it produces is something called a profile requirements list, PRL, and this allows the agency to specify what it’s looking for in the procurement, actually down to the level of the actual dialogs and XML messages. And it produces a vendor products capabilities specification called a profile implementation conformance statement, the PICS. And it has something called the Diff function allows you to compare the agency profile requirements in the PRL with the developer PICS, which they are being checked for conformance. So it allows an agency to determine if the offered TCIP implemented interface will meet the agency’s requirement.

The message builder actually allows the user to generate XML encoded TCIP messages. And these messages are used by the interrogator and the TCIP server applications to simulate messages. And you can load, save, view, and edit TCIP messages using this tool.

The interrogator simulates a TCIP compliant device. It is the client side of the interface. It subscribes to a provider or a publisher of data. For example, you may want to simulate a data repository. And it establishes a TCIP communications link with a TCIP device under development or test. It transmits, receives TCIP messages. Again, it allows you to view and log the messages and it provides automated TCIP message verification.

Okay. The TCIP responder simulates a TCIP compliant device and it’s really simulating the server side. So this is the kind of a system that actually provides the data when a subscriber asks for it. So this could be, for example, a scheduling system. And it may receive a subscription request from a data repository. The data is preloaded. It’s been previously created by the TCIP message builder, or you can actually record TCIP messages that have been sent between real components on your system and use this to preload, to test out the interface.

Okay. Let’s give you an overview of the NTI onsite training for TCIP. Now, in this particular series of webinars, there is a second TCIP 2 module that we are offering but in addition to the webinar the National Transit Institute offers a two day hands on course called Integrating Transit Applications Defining Data Interfaces Using TCIP. Transit agencies or public agencies, MPOs, departments of transportation can host a course by providing an appropriate venue and coordinating with NTI. And the course is provided free to transit agency and other public agency employees. However, a fee is charged, and vendors, they are charged a fee. Now, students bring their own laptop with compatible windows operating system. And typically we actually ask students and give them the ability to download the TCIP suite and downloads and tools from APTA before they get to the course. So they actually will download TIRCE and the TCIP tools on to the laptops they’re going to use and they can take it home with them. In addition, they will have completed a number of exercises that they can take back with them from the course. Now, again, that is a course that is offered free.

Now, let’s turn to our activity for this. The question here is “Why does TCIP include a suite of tools? And the answer choices are: a) to fix bugs in the standard, b) to develop an agency architecture, c) to allow developers to revise and re-ballot the standard, and d) to develop procurement documents and test compliance. And the correct answer is d) to develop procurement documents and test compliance. TCIP tools include TIRCE to develop and procurement documents, the PRL and the PICS and the message builder and test console aid and testing TCIP interfaces. A is incorrect TCIP tools are not used to fix bugs in the standard. Bugs will show up from time to time and those will be fixed in the different versions of TCIP that will be put out from time to time. Incorrect. Volume one provides a concept of operations that you can use as a guide in developing your own agency architecture. And tools are not used in developing and balloting the standards.

Let’s go on and summarize what we learned in learning objective 6. We talked about the downloads that are available from APTA for free. They include not only the text for volumes that include the standards, but it includes TIRCE, which actually allows you to access the four volumes. And it also contains the tools that you need to build procurement documents. You will get the builder—the message builder and test console. And we also provided an overview of the two-day NTI course that you can get for free by contacting NTI.

Let’s go on to learning objective 7, the final learning objective. I talk about some examples and real-world applications. We have four of the different ones for you to show here.

The first is LYNX which is in Orlando, Florida. And this is a diagram that shows a variety of business systems both already existing and proposed for a pilot application that will use TCIP over on the right. And in this particular diagram, the black arrows on the left show other types of data flows between business systems that do not necessarily use TCIP. For example, there’s a mentor, a vehicle logic unit, which is on board a vehicle that feeds another subsystem called the mentor automatic vehicle locator. And the black arrow indicates that information goes from the VLU to the AVL but it’s not TCIP. On the right, however, we see that one of the vendors, AE, is providing a schedule translator that is going to receive information from the trapeze scheduling subsystem. It is then going to translate that schedule using TCIP and feed the TCIP-compliant data into three other subsystems, a traveler information/AVL system, and advertising management system, and a different vehicle logic unit that will be on board the vehicles. This particular pilot demonstrates how TCIP is going to be used in this particular application at LYNX in Orlando, Florida.

This is a different one for King County Metro, which is in Seattle, Washington, and here they’re going to be using a TCIP in a signal priority architecture to give transit vehicles priority as they approach traffic lights on major bus routes. And here TCIP is going to provide additional inputs to a priority request generator, which will be used to supplement another standard. And this is the case where TCIP transmits some data and another standard that has been developed for signal priority is also used in parallel with it in sending the signals from the vehicle to the request generator.

Third example here, this is from the New York City MTA, and this is their bus customer information system concept architecture. And here on the left we see that the on board components on a bus, which include the login information from the operator and the bus location are then being transmitted via a 3G wireless modem using several standards in combination, a TCIP, JSON, and HTTP. That information is being provided to a customer information service bus server and which then in turn provides customer information to customers. And it’s receiving information here from about 5,000 buses I believe in real time. And TCIP also is used in conjunction with XML to provide crude crew dispatch data to a bus CIS server.

And in this particular use this is in Canada, in Montreal, where two agencies AMT and STL are going to share a center-to-center data between their CAD/AVL systems using TCIP. And in the middle here you see what looks like a pyramid divided into segments, which indicates what we often call the communications stack. And that illustrates the fact that there are different layers within the communication stack. And TCIP provides dialogs and XML messages to exchange data center to center between these two different transit agencies.

Alright. And we’re now going to engage in our final activity. And the final activity is “In what types of applications could my agency use TCIP? And the answer choices are: a) control center to control center, b) provide data to support transit signal priority requests, c) communicate real time bus arrival information, and d) communicate between vehicles and base, and e) all of the above.

Okay. Let’s look at the answers and the correct answer is e) all of the above. TCIP has been and can be used for all of the applications in question. Montreal is using TCIP for center to center. King County is using TCIP to supplement transit signal priority request generation. MTA NYCT is using TCIP for real time arrival information. And LYNX is piloting TCIP for connecting on board VLU to passenger information system.

To review what we’ve learned in objective 7, we have gone through four different systems—LYNX, King County, MTA and AMT Montreal, and we’ve shown how TCIP is being used in a variety of different transit agencies.

What have we learned? One, transit communications interface profiles is the ITS standard for exchanging information among transit ITS systems and components. Two, TCIP facilitates competitive procurements by providing a nonproprietary standard allowing the transit agency to go beyond a single vendor when looking to upgrade or to add an existing system. Three, an agency ITS architecture provides a framework for interdepartmental ITS planning and coordination. It is a visual representation of the plan and vision for ITS development within the agency. And the TCIP concept of operations describes ten transit core business processes and explains how TCIP can be used to facilitate communications among transit applications. Five, TCIP building blocks consist of data element, data frames, messages, and dialogs. Six, TCIP includes a suite of tools including the TCIP implementation requirements and capabilities editor, TIRCE to develop procurement documents, PRL, and PICS and the message builder and test console to aid in testing TCIP interfaces.

There are a number of resources that are available to you here, several downloads, and particularly you can get a lot of the material that we talked to you about from the APTA website. So at this point we want to talk a little bit about the next module in this series, which is Module 4, and this is Transit Communications Interface Profiles (TCIP), part 2 of 2. For those of you who couldn’t get enough we have Structure and Elements of TCIP, Accessing TCIP via TIRCE and the TCIP Tools. So we’re going to give you a little bit more information on that. The current course is a prerequisite for Module 4. Module four goes into the suite of tools in more depth. And it focuses also on how to access TCIP using the TIRCE tool.

Thank you very much for completing this module. Click here and this will open the feedback form, or we want you to provide us your feedback and we have an additional link for that. Once again, thank you again very much for completing this module.

#### End of Module_3_TCIP_Part_1_of_2.mp4####