(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.)
Ken Leonard: ITS Standards can make your life easier. Your procurements will go more smoothly and you’ll encourage competition, but only if you know how to write them into your specifications and test them. This module is one in a series that covers practical applications for acquiring and testing standards-based ITS systems.
I am Ken Leonard, director of the ITS Joint Program Office for USDOT and I want to welcome you to our newly redesigned ITS standards training program of which this module is a part. We are pleased to be working with our partner, the Institute of Transportation Engineers, to deliver this new approach to training that combines web-based modules with instructor interaction to bring the latest in ITS learning to busy professionals like yourself.
This combined approach allows interested professionals to schedule training at your convenience, without the need to travel. After you complete this training, we hope that you will tell colleagues and customers about the latest ITS standards and encourage them to take advantage of the archived version of the webinars.
ITS Standards training is one of the first offerings of our updated Professional Capacity Training Program. Through the PCB program we prepare professionals to adopt proven and emerging ITS technologies that will make surface transportation safer, smarter, and greener which improves livability for us all. You can find information on additional modules and training programs on our website ITS PCB Home
Please help us make even more improvements to our training modules through the evaluation process. We look forward to hearing your comments. Thank you again for participating and we hope you find this module helpful.
Carol Schweiger: Welcome to Module 23, which is Leveraging Communications Technologies for Transit On-board Integration.
And as you can see in this graphic, it shows where on-board Internet of Things is moving access to the cloud is being made through an on-board Mobile Gateway router which we’ll be talking about throughout this module also, Known as a wireless gateway from Passenger devices accessing traveler information or making Fare payment and from customers using other Mobility Services.
My name is Carol Schweiger. I’m president of Schweiger Consulting and I have 40 years of experience in Consulting in the transportation technology space and have been working in many areas including systems engineering preparing technology strategies for public agencies specifically public transit agencies, providing Consulting related to traveler information as well.
And at this point I’ve assisted over 60 different transportation agencies in procuring and implementing technologies systems. I’ve also conducted other modules similar to this one, which are available online through the PCB program.
So, let’s move right into the module where you can see on the screen. There are three learning objectives reviewing key Concepts from Module 19, which I will be referring to a fair amount in this first set of slides. Module 19 is available for you to take and it’s somewhat of an introduction to On-board Transit Management systems for buses; the second learning objective today is to describe how to use current communication technology to integrate the systems that may be on-board a bus and the third learning objective is to give you examples as to how to procure systems that utilize current technology, Technology for on-board systems.
So, let’s move right into our summary of Module 19. And what we will begin speaking about is a standard called SAE J1587, which is the specification that defines messages that are transmitted on a network that uses another standard SAE J1708 and J1708 which we’ll cover in a few more slides specifies the data link and physical layers while J1587 specifies the transport the network and the application layers.
At this stage in the transit industry J1587 is somewhat outdated and being replaced by a newer standard which I will also review for you and here the purpose of J1587 is to define the format of the messages and the data that are being communicated between different Technologies within a Transit bus and it is always used with J1708 which defines the requirements for hardware and protocols that is needed to implement J1587. So, you can see here at the bottom of the slide that messages start with a message ID and that stands for message identifier and indicates the source address of the transmitting node.
The next value is a parameter identifier, which indicates what parameter the following data corresponds to: the data and length of the data are defined by the parameter ID value after the corresponding data, either another parameter ID is present or the messages terminated with a checksum. So, moving on a little bit I had mentioned earlier the J1587 is somewhat outdated but it is all it is found in Legacy systems that utilize J1708 as well.
So the message is defined in J1587 are the vehicle and component information that pertains to the, operational status and performance of the vehicle routing and scheduling information which relates to the planned or actual root of the vehicle. And finally, driver information which relates to drive activity. And we had mentioned J1708 which I will define in an upcoming slide for you. And then with the J1708 Backbone in place SAE completed the network with J 1587 to add some general on-board information sharing and Diagnostics. And as I mentioned earlier 1587 in 1708 are used together.
So now let’s move to the 1708, and as I mentioned 1708 is a specification that supports communication among devices that are installed on a Transit vehicle. The purpose of J1708 is to address the transmission of electronic signals and information among Bus components or bus Technologies. Those are often called Electronic Control units as well, and J1708 identifies the minimum hardware and procedural requirements for routing messages over the network that is within the transit vehicle also known as a vehicle area network and it establishes a way to determine which device is communicating information. Is it the engine? Is it the farebox? The length of time that each device is allowed to communicate which device has priority in accessing the network when two devices try to get access at the same time.
And then the message, it checks to make sure that the message was received correctly. So J1587 that we just had a few slides on defines the actual data or functions to be transmitted and J1708 only defines the hardware and basic software. So, since J1708 only describes the lower layers of the OSI model which we went into a fair amount of detail in Module 19 as to what the OSI model is. 1708 only describes the lower layers of that model and so it’s used with an overlaying application layer, which is higher in the OSI model and an example of such a layer is actually J1587.Which is used for data exchange as we mentioned earlier. J1708 describes the physical and the data link layer according to that OSI model.
So, some other key characteristics of J1708 is the transmission speed and the fact that the message can be up to 21 bytes long and a message contains a one-byte long message identifier followed by a number of data bytes and then a checksum so similar to what we saw. J1587. So here J1708 is allowing the communication between a vehicle logic unit. Also, sometimes known as an on-board computer and a variety of different technologies or components that are on-board the vehicle. So, some of the examples of functions that are made possible through that on-board integration are for example combining passenger information systems with vehicle location. So that the vehicle can announce the next stop coming up and provide some signage that shows the name of the next stop you could also combine fare collection with passenger counting.
You could combine on-board camera systems with vehicle location so that when you store video images on-board the vehicle and you review them at a later time, it will indicate the location of the vehicle when that video was recorded. And then finally you can combine Health monitoring capabilities of the on-board components with vehicle location as well.
So now let’s move into a more updated standard that is being used a little bit more than J1587 combined with J1708. It’s SAE J1939. And this defines how information is transferred across, again a vehicle area network to allow. The electronic control units to communicate information, you know for things like vehicle speed there are 17 documents that actually describe J1939 and they were listed in Module 19 in the section that talks about how to actually read a standard. So, the J1939 network is capable of handling all the requirements handled by J1708 in J1587. But in this case, J1939, that network spans all seven of the OSI or Open Systems Interconnection layers. And also, it has a data rate of 250,000 bits per second, which is much faster than J1708 and additionally it permits the connection of up to 30 technologies that are on-board a transit vehicle.
It’s unlikely that you would ever have that many but that’s compared to a maximum of only 20 for J1708 and also another key piece of information about J1939 is that it uses the 29 bit identifier that’s defined within the CAN 2.0b protocol. And let’s talk a little bit about that.
So, we’ve already mentioned that J1939 covers the design and use of devices that transmit signals on-board among different components. We talked about the 17 documents. And we talked a little bit about the controller area network 2.0b protocol. That protocol permits any of the Technologies on-board to transmit a message on the network when the network is idle. So, every message uses an identifier that defines the message priority.
From which component was it sent and the data that’s contained within it and then another piece of information that’s important to note is that there could be a collision of data if two components are trying to communicate at the same time. So, what’s important to note here is that collisions are resolved as a result of sort of this arbitration process that occurs while the identifier is being transmitted. So, the process requires that the transmitting component listens to the network in order to avoid collisions. So whenever that network is free, any component can start to transmit a message and any possible conflicts due to more than one component transmitting simultaneously are resolved by this arbitration process and during arbitration.
Each component is transmitting its message identifier and is comparing that with what level is it hears from the network. So, if it wins the arbitration and the transmission process continues, otherwise it stops and then it tries again at a later time when it doesn’t hear anything on the network and I had already mentioned that the J1939 messages are built on top of CAN 2.0b. So now we’re going to move onto just very briefly talking about wireless access points, which are used to facilitate the transfer of data to and from vehicles when they are in or near a garage facility and wireless access points use an 802.11x standard.
What we are seeing in the field right now is most agencies are using 802.11ac. And 802.11x is also being used for on-board Wi-Fi for it for agencies to use in a private mode and for passengers to use for on-board Wi-Fi. So, I wanted to mention a little bit about single point log on we cover this fairly extensively in Module 19, but the computer aided dispatch system allows for a single go Point, log on for all on-board system. So, with one log on the driver can initiate the systems that are connected to the computer aided dispatch system like your automatic vehicle location system on-board, the fare box on-board, possibly the head signs on-board.
And so another feature of single-point log on is where there’s more than one GPS unit on-board the single point log on provides one GPS location and date and time stamp so you don’t have to be utilizing multiple GPS On-board. So, this was an example we used in Module 19 of a single point log on and it shows the on-board architecture for connecting.
What were at one time King County Metro in Seattle their new fare boxes to a vehicle logic unit on-board using a Mobile Gateway router, which is what we’ll be covering in the Learning Objective 2 and 3. So, the log on is done via the driver display unit in this case as you can see. So, the mobile access router is connected to the vehicle logic unit here and it’s also connected to the driver display unit to a fare transaction processor and the vehicle logic unit is connected to other On-board devices. So, this was part of when King County Metro was replacing a lot of their on-board systems.
At this point I’m going to briefly go over three of the case studies that we covered in module 19. They were from the Norwalk Transit District in Connecticut as they were putting in a new CAD/AVL’s system the Capital District Transportation Authority in Albany, New York as they were beginning to implement their CAD/AVL replacement and the Ann Arbor Area Transportation Authority in Ann Arbor, Michigan as they were deploying their new CAD/AVL system as well. So, this diagram shows the on-board systems for the Norwalk Transit District, and I wanted to mention that the orange boxes shows systems that were existing and already on-board the vehicle and when the new CAD/AVL was coming on-board. So that’s the fareboxes and head signs, the voice radios, the door sensors and the wheelchair sensors. The purple boxes in this diagram show the core systems that were being deployed and the red boxes show the systems that they were looking to deploy in the future so we gave that example.
And we provided in Module 19 some information about specification language that was used to actually procure this new CAD/AVL system. So, in Albany DTA, the Capital District Transportation Authority is the transit authority in Albany. They operate close to 300 buses from three different facilities. And on a typical weekday, they have about 55,000 customers. So, they conducted a solicitation to replace their old CAD/AVL system that had been around for quite a while and these were these specific functions that they mentioned in their specification that utilize the technology that technologies that we’ve just talked about. And then in Ann Arbor, Michigan, the Ann Arbor area Transportation Authority was deploying a new CAD/AVL system and just like in the Norwalk Transit District example, one of the first activities in the procurement process was to identify the systems integration using the standards that we’ve already talked about. So, at a high level the system integration was initially defined.
Using a J1939 vehicle area network to connect the on-board computer or mobile data terminal with the farebox, the head sign, the automatic passenger counter controller, the digital video recorder the on-board announcement controller and the interior Dynamic Message Signs for those announcements. They wanted a single point login as well and some other integrated functionality. And in this diagram, it has the same colors which indicate some existing technology as well as some of the technology that was being added. So that wraps up our review of Module 19.
And so we have a quiz for you, and the quiz question is, which one of these differences between SAE J1939 and J1708 is not true? In the answer, choices are A - J1939 is much faster than J1708; B - J1939 permits a connection of more devices than J1708; C - J1939 is based on the controller area network; and D - J1939 covers the same number of OSI layers as J1708. So, the question is which one of these is not true. And the answer is D. J1939 covers the same number of OSI layers as J 1708 that is not true. J1939 covers all seven layers of the OSI model while J1708 only covers to so the other response is a B and C are actually, correct. So, here’s our correct answer and here are the other review of A, B and C.
So, now let’s move into learning objective 2 which is to describe how to use current Communications Technologies for this systems integration on-board Transit vehicles, and there are four key points that I’m going to cover in this particular learning objective. The first is the use of Mobile Gateway router is and I’ll actually define that term in a couple of slides integrate on-board technology provides communication between the vehicle and important locations outside the view like the central dispatch office or a Data Center and it also can provide Wi-Fi for passengers.
Secondly, the use of Mobile Gateway routers determines and selects the best available wireless network to roaming across all of the available networks. Another key point is the use of cloud platforms and web services allow remote access to, for example things like data analytics so that that data analytics may not be on-board the bus but it may be available in the cloud and that provide some other functionality like payment transactions and we actually have an example of that coming up. And then the last key point is learning objectives is I’m going to give you some examples of current communication technology that actually conduct some on-board functionality like automated fare payment and Transit signal priority.
So, by way of introduction to the module just to sort of set the stage here, the new communication technologies is really what we’re talking about in this module and the impact of using these new technologies with the on-board devices is really two- fold. Data from on-board devices that are being communicated outside the vehicle like to a Dispatch Center or a data center might be communicated a bit faster. But the data is not any different than it ever was so I want to make sure that folks recognize that we’re talking mostly about the way to communicate the data.
The data itself is no different and then the Mobile Gateway routers, which access the communication technologies like a cellular connection or Bluetooth connection or Wi-Fi. They prioritize which communication technology should be used to communicate with on-board data. So, I want you to keep that in mind and so the content of the module really focuses on the communication Technologies rather than the actual applications that are utilizing those technologies. With that kind of setting the stage I want to provide some definitions so wireless gateways add intelligence to the activity of connecting a technology to the internet.
They translate a private local Internet Protocol to a public network Internet Protocol that’s assigned by typically the cellular service carrier. They can also have some routing capabilities, although that’s not the forte of wireless gateways. The Gateway connects a local private device or local private network to the carrier’s public network and the internet but now perhaps most importantly for this module, we’ve got a definition of Mobile Gateway Routers. So, they perform all the functions of a wireless gateway and add sophisticated routing capabilities as well as multiple Ethernet or Wireless local area network connection. So, these capabilities involve things like port forwarding or mapping and port routing. The single public IP addresses assigned from the carrier may be mapped in the router itself.
So that one port of the single public IP addresses is map to a camera another might be mapped to a sensor and yet another might be managing the router itself. So current communications technology utilizing these two devices effectively moving functionality to the cloud and that’s really one of the most important things to keep in mind as we go through this module. Also integrating functions with the customer experience and new Mobility options and improving situational awareness in performance metrics for the folks that are actually operating the vehicles and dispatching them and then another important sort of direction that we’re going in this evolution of on-board the on-board Internet of Things (IoT) Edge logic and I’m going to talk about this in several slides.
Let’s kind of start by looking at the chronology of on-board communications technology. So, in the 1990s in this what we call sort of first generation of communications technology on-board, it really relied heavily on what is called Land Mobile Radio. It was basic Radio Systems utilizing specific frequent frequencies, and a lot of the data on-board was being processed on the vehicle. So, then in the early 2000s, we sort of moved into what we call generation 1.5 which is where we started to see these Mobile Gateway Routers and they were really providing more flexible communications and better integration of on-board Technologies today. What we’re seeing is what we’re calling a second generation.
We are now seeing the Internet of Things gateways where core functions still remain on-board the vehicle, but the actual analytics and the “smart” part of everything is moving into the cloud. So, here we have a diagram with a bus in the lower left-hand corner and some functionality that is now sort of showing us what Mobile Gateway Routers are going to allow us to do in the future. So, the on-board devices are utilizing that Mobile Gateway Router to facilitate the integration of devices. On-board the vehicle as well as communicating with the cloud with the internet and other locations that are off the vehicle. So, while this particular graphic is representative of the second generation, not all transit agencies are this sophisticated as yet. More likely what you’ll see in the field is what we call generation 1.5 and I’ll be describing that. Also, again the Mobile Gateway router can provide it internet access to passengers.
And then as we’re seeing in this diagram in the left-hand side of the diagram where it says Edge Computing Analytics. Edge Computing is beginning to be used on-board Transit Vehicles. It allows the data that is being produced by The Internet of Things (IoT) devices to be processed closer to where the data is actually being created rather than sending a very long distances. And so this Edge Computing is very new and public transit and it’s starting to be implemented. It implemented by some of the larger agencies. And what we’re seeing is data exchange is kind of moving more towards streaming than it has been in the past.
In the upper right-hand corner, you see a number of different cloud services that are communicating with other Mobility Options. And actually, the vehicle is actually being integrated with these other Mobility options. So, for example, these other Mobility Services, like say a bike sharing or scooter sharing they can utilize the same Cloud that the transit vehicle was using to facilitate something like integrated payment. So, if we think about the use of Mobile Gateway Routers in the applications that sort of use these communications technologies. It’s all of the communications that you are all familiar with that are listed on the slide.
Each of these applications used to have its own independent method for communicating its data off the vehicle, but now instead of doing that individually all the connectivity can be accomplished through a Mobile Gateway Router. Which is that single connection platform. And this is really significantly reduced the need for having multiple on-board Hardware components and here I’ve listed a few more of the applications that actually utilize on-board Communications Technologies. So, let’s pull apart with some diagrams what various Communications technology architecture looks like on-board a Transit vehicle. So here this slide shows currently how on-board devices are utilizing the communications Technologies. We call the Generation 1.5. However, one thing to note here is that not all of the on-board devices are actually Internet Protocol ready yet, which means that we still are going to need to have some kind of on-board computer and the technologies that are on-board are shown in this diagram.
There are a variety of different current technologies, and they include farebox, automatic vehicle location, transit signal priority, cameras, etc. So, what is the advantage of using this approach compared to what we did in the 1990s? Here everything is centered around the Mobile Gateway router and that provides a lot of flexibility. It means you can swap in and out technology that you want. They will automatically be connected to the vehicle area network using this Mobile Gateway router. You can also have end-to-end information technology monitoring and the whole environment is connected together through the Mobile Gateway Router and its really good transition, if you’re going to move into generation 2 which I’ll talk about in a minute or the second generation.
There are some disadvantages to this approach as I noted on the slide and have already mentioned not all devices are in an Internet Protocol ready. So, you may still need to have that on-board computer or vehicle logic unit. So, as we’re moving into generation 2, you see here in this diagram this shows how the future is looking and there are some agencies that are beginning to utilize the second generation still kind of in the early stages, but the advantages of this approach is lowers your long-term costs. And it provides a fully integrated Ethernet and Internet Protocol on-board environment and you can see that there’s just the one Ethernet and Internet Protocol network throughout the vehicle in the diagram and it reduces the dependency on a single Transit technology solution provider and this is really, really critical as we talk more and more about Open architecture. Without open architecture, agencies often have to go back to the vendor that provided some initial Technologies in order to add them and we want to be in a more open environment the disadvantages of this approach her in sort of still in the early stages.
But we still may need to deal with some backward compatibility as we sort of move into this particular architecture and it’s just kind of another view this shows how the Mobile Gateway router is connected to various on-board Technologies and is also connected to a the cloud or a data center in an operations center and could be still utilizing it on-board. Which here we’re calling the mobile data terminal which is shown in the very front of the vehicle. So, moving on remember we mentioned how do we determine the best network for each data stream? That’s something I mentioned at the very beginning. In years past prior to the use of Mobile Gateway routers, a dedicated separate router was deployed for each Technology. Remember I mentioned that before. Fortunately, the current technology includes a single Mobile Gateway router that provides the encryption, the authentication, and the message integrity also not all the data that is being generated on-board and be being communicated between dispatch and the vehicle has the same value or the same priority.
So certain subsystems such as Fare Payment or data about the engine and how well it’s performing may take priority while some other functions such as passenger Wi-Fi and digital signage are less important. For example, you don’t want a fare payment transaction to be blocked because of the passenger is using Wi-Fi and streaming some video. So, let’s get into this a little bit more. When we talk about how that traffic, that data traffic is prioritized, really that’s one of the goals of the mobile gateway router. So generally, does prioritization can be accomplished using what’s called the internet engineering task force standard (IETF) for differentiated services, which is an enhancement to the Internet Protocol that allows the configuration of bids in the IP packet header to designate the priority of the traffic.
So, using quality of service (QoS) settings at the Mobile Gateway Router, you can specify the importance of the data in that particular packet of data. The IP packet receives priority through its journey all the way to the back office or the Dispatch Center or the data center. This ensures that the connectivity prioritizes the data traffic that really matters the most like we were mentioning fare transaction, something like that. And then just a side note, quality of service is a family of evolving internet standards that provides ways of giving preferential treatment to certain types of IP traffic like we mentioned before. We talked a little bit about connecting to multiple communications systems here on the left-hand side of the slide. I wanted to mention that some Mobile Gateway router can actually connect to two different wireless carriers. For example, Verizon and AT&T, if one carrier goes down or is unavailable some Mobile Gateway Routers can switch to the other provider automatically.
So, there’s no interruption in data transmission. Sometimes the two carriers are included for redundancy. But sometimes different carriers are used to carry different data that’s also the case and then the functionality of Mobile Gateway Routers that is typical is listed here on the right-hand side of the slide. So, let’s run through a rather complicated data transaction example that shows how the Mobile Gateway Router is be used, so fare transactions are probably some of the more complicated transactions that are being done on-board. In the case of Fare Payment using a debit or credit card through a Mobile Gateway Router, the agency has to take into account that the payment card industry standard for security and what is called PCI or payment card industry compliance. It’s required for processing any card base payment. This involves not only securing components but securing the whole fare payment process.
Some Mobile Gateway Routers can actually provide security that means PCI standards because the requirements can actually be incorporated into the mobile gateway router and those particular Mobile Gateway Routers that can provide that security: they include things called the Stateful Firewalls, which watches traffic streams from end to end and they are aware of various communication paths and can implement internet protocol security functions such as encryption and tunnels and then we have encryption, we have segmentation of the network, we have event logging, and then user authentication so that can actually be incorporated into some Mobile Gateway Routers.
Another key component of generation 2 is utilizing various types of cloud platform and web services which years ago we didn’t have a lot of cloud platforms and it was very hard to access web services. So, cloud computing is really designed to provide an on-demand resource that you can utilize for any application or database or a server or other IT or information technology infrastructure as needed. There are three types of cloud services that I wanted to mention because transit can utilize all of these. One is a public cloud service, which is hosted by a third-party provider and it’s generally accessible through a web browser and then some examples might be like Amazon Web Services, Microsoft Azure or Google Cloud. Then there are private clouds which are usually dedicated and accessible only to a single transit agency or organization and you might have heard of things like HP Enterprise, VMware, IBM has those. So those are the private clouds and then we have hybrids that combine various aspects of public and private clouds that allow organizations to have more control over their data and provide some other benefits.
So when we talk about various cloud service models, we’ve got really three major categories one is called infrastructure as a service, which is a cloud layer offering that enables a self-service model for managing a virtual Data Center and its infrastructure. So, customers actually pay for on-demand access to these resources and then the resources could be something like storing data and also operating systems. So that’s infrastructure as a service. Then we have platform as a service, which is a cloud layer offering that provides some tools and computing infrastructure. And so this typically supports developers and programmers and it allows the organization to build and run different web applications.
And then we have software as a service (SaaS) which many of you may be utilizing now with Office 365 or Adobe: they a provide software as a service and that’s really consisting of applications that are hosted by a third party and are usually delivered over a web browser that is accessed by the client. So now I’m going to give you some examples to wrap up this particular learning objective. And here we are going to be talking about Valley Regional Transit and they were having significant issues with intermittent communications connectivity and was creating a lot of problems. They would get in accurate data, they were getting no data at some point and all of their equipment was relatively old. So, what they did and I’ll talk in a little more detail about this is they deployed new Mobile Gateway for others in their buses?
And so they also had Wi-Fi access points which we talked about before and some other integration and they’re also utilizing one of the cloud model that we talked about. The other example is Los Angeles Metro and their cloud-based transit signal priority system and here they did an analysis of next-generation traffic/transit signal priority that was based on cloud computing and is actually renamed Transit Signal Priority as a service model and so here the reason for utilizing these seven core elements that you can see on the screen is that LA Metro was asking more and more of the systems that utilize to support their operations. And so they really needed something new, second, they needed to look at scalability. So, this new generation of transit signal priority is designed to handle and scale the sort of task that you have that are very computationally intensive.
Third, they needed to create a common platform for operations and analytics. So, that was very important to them. And finally, they needed a means to quickly connect and use various applications over network connection. And so here there’s only a single backend and client-side software. They can be done using this particular approach. So those are the two examples. Let’s get into them in a little more detail.
So, Valley Regional Transit. It’s also called Valley Ride provides public transportation in the Boise area and provides about 1.3 million trips per year and they have about 70 Revenue Vehicles so before they deployed their Mobile Gateway Routers, they had some 2G and 3G modems in fixed route buses that had basically started to break down. And so they had all kinds of problems with these there were a lot of failures data not being communicated between a vehicle and dispatch and so it really prevented that on-board computer from doing its job effectively. What they did was and this was done, by the way at the same time that they were building a new underground Public Transportation Hub. So that required even more, which was constant, you know, how we’re going to ensure a GPS access when the vehicle goes underground? So those questions will be inserted the same time and they wanted to do things, like offering free Wi-Fi for passengers so they installed Mobile Gateway Routers.
Within each Transit vehicle each Bus with an external antenna that’s mounted on the roof, and they’re also utilizing a cloud manager for being able to troubleshoot problems with on-board technology remotely and providing firmware updates and upgrades over the cloud and some other benefits as well. So, you can see on the slide what they were able to do with their Technologies. And then finally they were able through this new Mobile Gateway Router to provide uninterrupted vehicle tracking, which is what they needed.
Another benefit was a significantly reduced the number of customer service calls because they had improved all of the on-board data that was being communicated. So they reduce the number of calls from between 9,000 and 10,000 calls per month. They reduce that by about 25% and as I mentioned earlier they were able to provide free passenger Wi-Fi and when that started they had about 350 passengers per day utilizing that but that number has gone up pretty significantly since then. Let’s move to our second example, which is LA Metro. This diagram with the bus in the lower right-hand corner and the traffic signal cabinet in the lower left-hand corner. This was the way that LA Metro had been doing Transit signal priority. And as you can see multiple on-board communications devices were utilized they each had their own antenna and so it pretty confusing and it was pretty hard to maintain all these separate systems. So what they did was moved to now this way of operating and this architecture which is cloud-based.
This diagram shows the sort of next-generation transit signal priority, which is cloud-based and it utilizes a Mobile Gateway Router. And so it’s there’s the priority logic component which is part of that Mobile Gateway Router and the logic can be migrated fully to the cloud. But what Metro did was they preferred to keep that logic on-board so that they could operate in corridors where there were legacy Transit signal priority system. So that allows them to not only communicate with the new systems, but with the older ones so now this final diagram for LA Metro includes all of the pieces. So first the bus regularly is transmitting its location and priority information to the cloud. This is in an ongoing basis the cloud identifies the appropriate downstream traffic.
Signals and then routes the formatted priority request messages according to specific logic the signal or the advanced traffic management system, then takes action it either grants signal priority or denies signal priority and it reports the action and took back to the cloud and then the cloud performs analytics and provides data and reports back to the agency that is utilizing it. So, LA Metro had conducted transit signal priority concept exploration as part of this sort of new angle signal priority system and it came up with all of these approaches that you see listed on the slide. And so as of October 2019 LA Metro’s new advanced traffic management system was combined with their bus signal priority infrastructure and it allowed other municipalities to use that architecture for their signal priority. Diagrams of all of these concepts are included in the student supplement so you can see them all there and one example was the bus signal priority system that was deployed in the city of Arcadia.
So now to sort of wrap up learning objective 2 we’re going to ask another quiz question and that question is: What is the difference between Generation 1.5 in Generation 2.0 of the on-board architectures? The answer choices are A, the Mobile Gateway router was introduced in Generation 2; B, not all on-board devices are Internet Protocol ready in Generation 1.5. C, on-board analytics and smart they on-board in Generation 2 and D, Ethernet are no longer used in Generation 2.
The correct answer is B, not all on-board devices are IP ready in Generation 1.5 and you can see the response to A was incorrect because the Mobile Gateway Router was introduced in Generation 1 .5. C, was also incorrect because the core functions remained on-board the vehicle with the “Smarts” and the analytics moving into the cloud Generation 2 and D was also incorrect because Ethernet continues to be used in Generation 2. That wraps up learning objective 2 and now we move into learning objective 3, which is to show how to procure systems that utilize Mobile Gateway Routers for on-board systems. And this learning objective gives you three fairly detailed case studies about how to procure these mobile gateway outers and its systems that utilize them.
So, let’s go to our first example and that is again from Albany which we mentioned was used as an example of Module 19, and that’s because one of these significant parts of their procurement for their new CAD/AVL system was to utilize Mobile Gateway Routers they call them on-board Mobile Gateway Routers.
So, the abbreviation is [a] little bit different but it’s exactly what we talked about. And in their request for proposal, they detailed the specifications for the wireless data communications, which includes the on-board Mobile Gateway Router and that section is included in its entirety in the student supplement. So, the on-board Mobile Gateway Routers are being used for the purposes that are listed on this slide and excerpts from the specifications are included in the student supplement.
You can see that they were moving towards an open payment system infrastructure and a new Central data system as well as on-board Wi-Fi. So, I want to talk just briefly about how did they make this decision to use a mobile Gateway router and they finally settled on a specific Mobile Gateway Router due to the capabilities that it had and that was it had a four port, multi-card, redundant configuration. So that allowed them to utilize multiple cellular cards like we were describing in an example earlier where you might send some data using Verizon for example, and some data using AT&T. The mobile gateway router was going to house the two SIM cards that it needed and in Albany case what they did was one card is used for private connectivity.
So that’s the agency only using that and the other card is for public Wi-Fi and the private connectivity would be to transfer Real Time information, alarms Vehicle Health monitoring canned messaging, passenger counts and camera footage. So that’s the private side that only the agency can utilize that and then the there’s a cloud-based app for the future of farebox transaction data. So, they needed to choose a specific mobile gateway router that would be able to perform all of these functions they also, we’re going to use it to wirelessly transfer all the data collected on-board the bus back to the garage. So, that was another reason for them selecting this particular Mobile Gateway Router. And as part of this decision-making process, they wanted a proven solution. So, they wanted to select Hardware that had already been deployed in the field and had some history and proved to be reliable.
They wanted the router to come with software management, software that allowed the agency to maintain the equipment as well as configure it the way they wanted it and to monitor it as it was being used. They wanted multiple inputs to that router which makes sense because they have multiple technologies on-board and they needed to be able to operate both a private and a public network for the reasons that I just described on the earlier slide. So that gives you some idea about how they made their decision about utilizing a specific Mobile Gateway Router.
Now we’re going to talk about a second case study or example, which is TriMet in Portland, Oregon and it has to do with them deploying what they call their Hop Fastpass, which is a payment system that they first put into place in 2017. And so they have consistently been able to add new features to this system because of using a Mobile Gateway Router. So, instead of building a closed fare payment system, which we still see in the industry and they didn’t want to be having to use proprietary software and hardware they chose to use an open architecture fare payment system. And so the open architecture really allows them to capitalize on technology constantly changing and the cost going down and avoiding negotiating with a systems integrator that you would have to go back to continually to obtain new technology and they wanted more flexibility and they wanted to get away from this proprietary situation.
So, in the RFP TriMet emphasize that the systems integrator would need to provide open application programming interfaces that would enable any vendor to connect easily to their fare payment system and those application programming interfaces are really the heart of the open architecture parts of the specification that they used for the procurement is in the student supplement so you can see that. I want to give you a little bit of a chronology. So this Hop Fastpass system went live in July of 2017 with a smart card. So in order to utilize it you had to have an actual card in your hand and you can use it on try not vehicles and the Portland streetcar which is separate and C-TRAN which is another Transit Agency whose service touches TriMet. And so what that afforded customers even though it was only a card-based system was that they can autoload their cards.
So if the value of the card got down to a certain level you could automatically be added to it and they implemented Fare capping which is becoming more prevalent in our industry today where you give the customer the lowest possible Fare based on their trip. So that they were able to do that, but then they decided that they wanted to include people being able to pay using their smartphones, so they also started providing in the Fall of 2017. Apple Pay, Android Pay, which became Google Pay and Samsung Pay but then they wanted the people utilizing a smart cards to get the same benefits as the people who are using cards. So that’s the automated reload and the fare capping. So, in Spring of 2018, they allow the people using Android payers or Samsung pay to create a virtual card that gave all those benefits and then in May of 2019 Apple Pay users could do that as well.
Now this is only part of their architecture diagram that shows the fares system, which includes the Mobile Gateway Router which I have shown here in this sort of circle that’s on the diagram. This whole diagram is in the student supplement with all of the various pieces identified. And so this slide just shows you some of the requirements that were contained in the specifications that indicated how the mobile gateway router would facilitate this complex transaction processing that was going on. So, that wraps up the case study for TriMet.
And now we’re going to move to our final case study, which is it AC Transit, which is in Oakland, California. So AC Transit CAD/AVL system in their radios systems had been in place for almost 20 years. They were starting to fail. The integration of new technologies was very complicated. And really those Legacy systems were not integrated to the extent that you can perform integration now. And they felt that they needed that systems integration in order to conduct their operations the way they needed to so the Legacy system had a lot of separate components like passenger announcement, operators sign-ons, passenger counting, and payment. They needed something that was scalable and used open architecture. It provided in effect better service for their customers and it allows them to manage operations much better.
So you can see on this slide what they did moving away from the older systems that have been there for almost 20 years into a new open architecture platform that gave the passengers and themselves a lot of benefits. Another way of looking at that is the slide which shows sort of the key features of what they knew was available and they wanted to utilize so with the advances of 4G + 5 G. The Broadband is much more capable of handling the communications requirements in a Transit situation than the old Radio Systems that a lot of agencies had. Also those radio deployments were very expensive because of the infrastructure requirements. So, they decided to deploy a voice over IP solution, which they felt could save them 50 percent over what they were paying to maintain the old radios. A system and its infrastructure and with voice-over IP. They realized the capital investment at the beginning is considerably less than what you would do for an older radio system. So let’s look at what they did.
They had a variety of these different technologies and they said well now that we have this open architecture and support for application programming interfaces we’re able to integrate their basic CAD/AVL system with other systems outside of CAD/AVL like GIS, like their enterprise resource planning system, operators scheduling system and they have an enterprise asset management system. So this really provided the architecture to now seamlessly connect to all of these other systems.
And then they identified a number which you can see on this slide of benefits to utilizing not over not only voice over IP, but the Mobile Gateway routers. So, now their buses are equipped with these new Mobile Gateway Routers that provide high-speed computing power and integration capabilities. And one thing that makes their voice over IP deployment pretty unique is that it’s actually a hosted solution. Most voice-over IP systems are not, but they felt that this was the best way of utilizing a hosted environment that has a primary data center: it has a backup data center and it provides redundant communications path. So these were number of the benefits. Then I think perhaps the most important thing, is that [it is] a very high-level for AC Transit.
This is what they call their digital framework and it incorporates their major stakeholder departments or entities if you will and provides a really good platform for each of those stakeholders. So the center of the diagram, it sort of shows the data and analytics platform, it’s connected to each stakeholder and it provides that computing power and business intelligence that each of these stakeholders requires based on your functionality and it fits into their Connected Enterprise is what they call it where individual departments no longer work in silos. But they now work in a very connected environment and you can see if you look in each of the corners of the slides that each stakeholder group is connected to another stakeholder group. So this connectivity could not have been possible without initially deploying Mobile Gateway Routers and voice over IP in their vehicle. That concludes the third learning objective.
And we have two quiz questions for you here. The first one is CDTA’s. That’s Albany’s selection of an on-board Mobile Gateway Router, which included which consideration? A, Need to operate both private and public networks for internal data transfer and public Wi-Fi. B, Flexibility to handle multiple inputs antenna and multiple SIM cards for redundancy. C, Hardware needed to be already deployed and proven to be reliable and D, All of the above.
And here you can see that the correct answer is all of the above. All of the statements A, B, and C are correct. So now we will move onto another quiz question for learning objective 3. Which one of these benefits has been experienced by AC Transit due to their implementation of multiple technology Communications? The answer choices are A: Limit service area coverage. B, Provide a path for technology evolution. C, Eliminate land mobile radio (LMR) assets, and D, Reduce the number of FCC licenses. And here we see that the correct answer is B: one of the major benefits of them upgrading their communications technologies was to provide a path for technology evolution that will not tie them to one vendor and would give them a lot of flexibility.
So that concludes our module today, here are the other answers to the questions that were incorrect. And what I want to do now is just briefly provide a summary of the whole module and so in learning objective one, what we really talked about was selecting the appropriate standard to incorporate in specifications basically procurement specifications based on the standards. Availability. So there we might look at what standards are being used by particular vendors the applicability of this standard to what you’re actually deploying the maturity of that standard and vendors acceptance of the standard.
In the second learning objective, we were describing how you would utilize communication technology to provide this on-board systems integration. And now what we really talked about was the fact that Mobile Gateway router is really facilitat[ing] that integration as well as providing you with the way to communicate with the cloud with the internet and other external entities outside the vehicle and then learning objectives three; we had three sort of case studies to discuss how you might procure systems that utilize that new communications technologies and here why we were looking at that was really to create scalable open architecture and integrated platforms that allow an agency to operate and maintain the technologies that they need for us to customer service for operations, for maintenance and for overall management of the operation.
So at this point, I thank you very much for taking this module. And since we are always looking for feedback in our various PCB modules, what we would really appreciate is if you could use the feedback link to provide us with an evaluation of this module. And if you if you think there were specific aspects of it that were really good or that needed more work. You can let us know that through the evaluation. So again, thank you very much for taking this module.