ITS Transit Standards Professional Capacity Building Program
Module 2: Transit Management Standards, Part 1 of 2
HTML of the Course Transcript
(Note: This document has been converted from the transcript to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included.)
Mac Lister’s Introduction
ITS Standards can facilitate the deployment of interoperable ITS systems, and make it easier to develop and deploy regionally integrated transportation systems. However, these benefits can only be realized if you know how to write them into your specifications and test them. This module is one in a series that covers practical applications for promoting multimodalism and interoperability in acquiring and testing standards-based ITS Transit systems for public transportation providers.
I am Mac Lister, Program Manager, Knowledge and Technology Transfer in the ITS Joint Program Office of the USDOT and I want to welcome you to our newly redesigned ITS Transit standards training program of which this module is a part. We have worked closely with the Federal Transit Administration and the American Public Transportation Association to develop this material. We are also pleased to be working with our partner, the Institute of Transportation Engineers, to deliver this new approach to training that combines web-based modules with instructor interaction to bring the latest in ITS learning to busy professionals like you.
This combined approach allows interested professionals to schedule training at your convenience, without the need to travel. After you complete this training, we hope that you will tell colleagues and customers about the latest ITS standards and encourage them to take advantage of the archived version of these webinars.
ITS 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 www.pcb.its.dot.gov.
Please help us to continue to make improvements to our training modules through the evaluation process. We look forward to hearing your comments. Thank you again for participating and we hope you find this module helpful.
Jeffrey Spencer's Introduction
ITS Transit Standards help simplify the complexities, overcome procurement challenges, and reduce costs of acquiring ITS systems. I would like to use a simple example to explain how this approach to ITS Transit standards is analogous to our day-to-day life. Imagine that when buying a computer—and you want to buy an upgrade, a printer, or anything else—that you must always buy that same brand at an exorbitant price. Of course, this is not the case because standards have been successfully implemented to allow interoperability. Similarly, transit standards have been developed by transit professionals like you at a national level to encourage competition and limit costs within our industry.
I am Jeffrey Spencer, ITS Team Leader in the Office of Research, Demonstration, and Innovation of FTA within the USDOT and I would also like to welcome you to this ITS Transit standards training. FTA actively supports the development and implementation of transit standards and we hope that you find this series of online courses a useful tool in promoting standardization. We look forward to your participation and input.
Narrator: Welcome to the ITS standards training. Throughout the presentation this activity slide will appear indicating there is a multiple choice pop quiz following this slide. You will use your computer mouse to select your answer. There is only one correct answer. Selecting the "Submit" button will record your answer and the "Clear" button will remove your answer if you wish to select another answer. You will receive instant feedback on your answer choice. Please help us make even more improvements to our training modules by completing the post-course feedback form. This is Module 2 Transit Management Standards, part one of two. Your instructor today is Carol Schweiger. Carol Schweiger is a vice president with TranSystems Corporation. She has thirty-five years of experience in transportation consulting, most of it in the area of intelligent transportation systems. Ms. Schweiger is currently managing TranSystems' ITS practice and is a project manager and lead technical specialist on several ITS projects involving the planning, design, development, implementation, and evaluation of public transport ITS. Ms. Schweiger developed and is the lead instructor of several training courses for the U.S. National Transit Institute on transit ITS. And she has written numerous papers and reports on ITS for transit. She is chairperson of ITS Massachusetts and serves on the international program committee for the ITS World Congress and the U.S. Transportation and Research Board ITS Committee and Emerging and Innovation Transport and Technologies Committee. Ms. Schweiger has an M.S. in civil engineering from Cornell University and a B.S. in mathematics from Tufts University.
Carol Schweiger: I want to welcome everyone to Module 2 the Transit Management Standards, part one of two. And we're going to start the module off by just speaking briefly about the target audience. We have three categories of folks that are the target for this particular module: any transit management staff who are thinking about technology or thinking about upgrading their technology; grants and procurements folks who may be in the process of or in the future will be procuring technology; and vendors and consultants as well. This is considered an overview that will lead us into another module that will speak in detail about the actual standards, so this gives you quite a bit of background. And as you can see in this next slide, the prerequisites are really just Module 1, which is an overall introduction to ITS standards and it gives you a general understanding of how standards are used within public transit and also gives you some basic information about the national ITS architecture.
This slide shows you what we consider a reasonable curriculum path where this is a module that you take right after the introductory module, but then you have several modules you can take after that, that give you detailed information about other parts of transit technologies, for example, traveler information, which is Module 6; Electronic Fare Payment Module 10; and some future technology in talking about connected vehicles, which is Module 11. Also, this is a part one of two, so we're setting the stage to discuss the transit management standards in a fair amount of detail in part two of two, which is the next—which is Module 5, as you can see in the diagram. And there are other modules that have two parts as well: TCIP and Traveler Information and Transit Signal Priorities.
For the project engineer, as on the prior slide for the project manager, we're looking at you potentially taking parts one and two of the modules that have a part one and two as shown in the previous slide.
And now we get to our overall learning objectives for the course for the module, and we have four major learning objectives. And learning objective 1 is to really review for you some of the information that was provided in Module 1, talk a little bit about how transit management fits into the National ITS Architecture that you heard a little bit about in Module 1, and then we want to get into the details of transit management. What are the core functions within transit management and how do they fit together? We're going to go into a fair level of detail about how they fit together and what some of the dependencies are between and among some of the transit management categories of technology. And then the final learning objective is to discuss the importance of systems engineering and its role in determining what standards to use, particularly when you are going to be doing a procurement.
So learning objective 1 is to give you some very basic information about the National ITS Architecture and the public transit portion of that and to really explain, in particular, elements of the National ITS Architecture that will be very helpful to you in identifying standards.
So to review a little bit from Module 1: The National ITS Architecture provides a common framework for planning, defining, and integrating ITS; and it allows various elements of the ITS community to share information and to speak with each other about various ITS systems. So the architecture defines three things: One is the functions that are required for ITS; two is actually the physical entities that are necessary to use these functions; and then, finally, it's the flow of information among the various elements within the architecture, and that's perhaps the most important part of what we're speaking about; and, finally, the National ITS Architecture can really be used as a template for any regional architecture development.
So as an overview, there are three architectural layers, there's two technical layers and there's one institutional layer. And those two technical layers have to operate within that institutional layer. So let's talk a second about the institutional layer. That has the institutions, the policies, the funding mechanisms, and the processes that are really required to best deploy ITS in a region. And the reason why that is so important is the other layers, which are very technical, can't operate without policies being in place, without funding being in place. So that's why the institutional layer is so fundamental. The transportation layer, which is one of the technical layers, is really where all the transportation solutions are defined. So you have various sub-systems and various functions, which we're going to talk about in this module, and that's where they're located. And then we have the communications layer, which is required to allow that information exchange to take place, and that's the second technical layer.
So looking at this particular diagram on the left we have the layers that I just discussed, the three layers, but then you see other elements of the architecture. You see standards, which is primarily what the modules in this course are comprised of: discussing standards. But you have two boxes: One is called "logical architecture" and one is called the "physical architecture." The logical architecture defines the functions, the processes, that are needed to actually use the user services, which you can see are located below that. And there are data flows that are happening, which we'll talk about in more detail. The physical architecture is a structure around the data flows and around the processes that are in the logical architecture and it really identifies the transportation systems and the information exchanges that support this overall ITS picture. And you can see below the physical architecture box. We have architecture use, so that discusses how the architecture is actually being used. If you look to the right, there are two other boxes, one is called "security" and the other one called "service packages." I want to focus on the service packages, because that's going to come up in the next few slides. That's a very important part of the physical architecture that addresses specific sub-systems and architecture flows that really speak to functions within a transit system. We're going to spend a little more time talking about those service packages.
So, really, what is the purpose of having standards within an architecture? And it really facilitates that information exchange. If you're using standards, it makes it a lot easier to define how those information exchanges and flows are going to take place. And it allows you to communicate outside of transit with potentially other entities like traffic management and those sorts of things. In this particular diagram you can see the relationship between the National ITS Architecture and what we call regional architectures as well as project-specific architectures. The standards have a relationship to all of these elements on the chart. And that's what we're really going to be focusing on in the module.
So on the next slide we're starting to talk about service packages, which I mentioned before. They represent parts of the physical architecture. And in public transportation there are eleven service packages and I've listed five of them on this slide and then continued the other six on this slide.
And now I'm going to give you an example of one of the service packages and what it actually looks like from sort of a flowchart perspective. So this is the transit management service package, the first one, which happens to be called Transit Vehicle Tracking. So this is one of the eleven that you'll see if you go and look at the National ITS Architecture literature. So this particular service package monitors the location of transit vehicles using an automatic vehicle location system. The location data can be used to determine real-time information. How is the bus doing against the schedule? Or how is the transit vehicle doing against the schedule? And that information can actually be reported as you can see on the left-hand side of the slide to an information service provider that could provide that to the public, for example. And then the position of the vehicle is determined by some technology on the vehicle, which could be the global positioning system, for example. And then that location is relayed to infrastructure, which on the chart it says "transit center vehicle tracking." That's where the tracking of the vehicle is being recorded and determined. And then there's a communication link between the vehicle and the transit management center—you can see those two lines with arrows providing information to the transit management center about how the vehicle is doing. And you can also see other information exchanges within this particular service package. For example, in the yellow box that's below "transit vehicle" that's where the location of the vehicle is being determined and that information is then sent on to the transit management center from the vehicle. So this gives you one of eleven examples of a service package. And these diagrams are included in the documentation for the National ITS Architecture.
So we have our first activity and this is a question: What is the purpose of ITS standards? And your answer choices are: a) to keep up with technology; b) interoperability, compatibility, and interchangeability; c) to document data exchange among ITS systems; or d) all of the above.
And here are the answers. The correct answer is b, and that's because standards and protocols provide for interoperability, compatibility, and interchangeability. That's the correct answer. Let's run through the other ones. A is not correct, because standards don't necessarily help agencies keep up with the technology. C is also incorrect; standards do facilitate data exchange, but they don't necessarily document the data exchange. And then d is also incorrect, because all of these elements don't really explain the purpose of the ITS standards.
We also have another question for you and that is: Which of these are not public transportation service packages? So you saw—I listed the eleven service packages on the prior couple of slides and so your answer choices for this question are: a) transit vehicle tracking; b) multimodal connection protection; c) multimodal coordination; or d) traffic metering. So which one of these doesn't belong?
And here are the answers. The correct answer is d. That is not a public transportation service package. It is, however, in another group of service packages for traffic management, but it's not a public transportation service package. And the other answers are incorrect because they are public transportation service packages, so transit vehicle tracking, multimodal connection protection, and multimodal connection coordination.
So, to summarize learning objective 1, we mentioned that the National ITS Architecture is really a framework. It's designed to accommodate a number of entities communicating with each other. It also allows for changes in technology. The architecture doesn't define the technology, but it allows for technology to actually change while the basic structure of the architecture stays the same. And it also allows for institutional arrangements to change. And we spoke a little bit about the layers, the three layers, the institutional layer, and then the two technical layers, we talked about—a little bit about user services, but more importantly about service packages. And we mentioned that the National ITS Architecture can actually be used to develop a regional or even a project architecture. So that's the summary of learning objective 2. Let's move into learning objective—sorry, learning objective one. Let's move into learning objective two, which is to describe the functions of transit management systems. And on these slides we did a little bit of color coding so you can see on this slide if we're speaking about fleet operations and management, the title of the slide is in blue. If we're talking about safety and security systems, it's in red. If we're speaking about maintenance, it's in green. And if we're talking about data management or open data, it's in the purple color.
So let's move right into talking about the first category of technologies, which is fleet operations and management. So we've listed several of them here and I want to give you a very high sort of forty thousand foot overview of these, because we have a slide for each of them. We can go into a little more detail.
So communications technology's really the backbone of everything that we do in transit. It allows all the information to be exchanged between the vehicle and dispatch between the customer and the transit system. So that's just very fundamental. We'll chat about that a little bit.
Next, automatic vehicle location is software and some hardware that allows you to locate the vehicle and then communicate that to dispatch. Computer-aided dispatch provides some tools for the dispatcher to help monitor how vehicles are doing against their schedule. Automatic passenger counters do just what they say, they automatically count passengers getting on and off the vehicle in an unobtrusive way; nobody knows that they're actually being counted, but that's all it is. It's a count of people getting on and off the vehicle.
Scheduling is very important and some of you probably are already familiar with some scheduling systems for fixed-route operations where you have a fixed—the vehicle is on a fixed schedule and then, for para-transit, where you're on-demand potentially, or demand-response system where you're taking reservations ahead of time and then executing those trips throughout the day as they are scheduled by the scheduling software.
Transfer connection protection is a way of saving when someone wants to transfer from one vehicle to another, it's recognizing that someone wants to make a transfer and potentially holding the vehicle that they are transferring to if there are any delays in the system. We'll talk about that in more detail.
Signal priority is another very, very important technology in our fleet operations and management category and there are actually two modules that specifically deal with signal priorities. So I'm only going to very briefly mention it in the slides coming up.
Yard management is a way to automatically account for where vehicles are parked so that when you're in the midst of a pullout, you know exactly where specific vehicles are so that the pullout goes smoothly.
Intelligent vehicle technologies: Primarily here we're talking about the reduction of accidents through the use of some technology, like collision warning assistance and also precision docking, particularly with situations where you might have a platform like a bus rapid transit—you might have a platform and you need to dock in a very specific place so people can get off the vehicle easily.
And then we have lane control technologies that are used and this includes things like riding the shoulder of a highway in a bus, which can be called a—it can be a bus lane in some cases—and we'll talk about that briefly.
So communications technologies are really very fundamental to transit management systems in general and really there's—they're critical to specific applications like vehicle location. How does the vehicle location get communicated to the dispatch office? Through a communications system, and it can be done in a variety of different ways. It can be done with data communication. It can be done over a cellular network. It can be done over other types of networks that are listed here. But I think the most important thing to take away from this particular set of technologies is that this is the critical link among vehicles, operators or drivers, dispatchers, emergency response personnel, customers, and anyone else that's involved in providing transit service. And there are a wide variety of technologies, as I already mentioned. There's basic voice technology, which has been around for years; there's data messaging or texting, similar to texting on a phone, but not texting, especially while the driver is driving; and there's data communication. You can also use some limited amount of video, if you're looking at a particular incident onboard a vehicle; that's also possible to be transmitted. And there are a number of technologies in today's world. There's some newer technologies like Wi-Fi, mesh networks, WiMAX, in addition to the technologies that are already listed on the slide.
So vehicle location is a way to determine where the vehicle is and to communicate that to dispatch, to customers, and so there's software that's used by dispatchers that receives updates on vehicle locations, and that's constantly going on. And the way that happens is there's an onboard computer on the transit vehicle that has the ability to determine its location and then communicate that back to dispatch. Also, AVL and computer-aided dispatch provides some tools for the dispatchers to use to proactively manage how that vehicle is doing against its schedule. So if there's an incident or an accident, they have some tools available to them to potentially re-route the vehicle, if necessary. And that's really the computer-aided dispatch part, is providing that decision—those decision support tools. And then one very important part of this is—year's ago there was no way to integrate all of the pieces of equipment on a bus and drivers had to log onto each piece of equipment separately, but technology today allows you to integrate all of those various pieces of technology on the bus to provide for one login, one point of login. So the driver can log into one device and not have to go around and log into individual devices.
The next group of technologies is automatic passenger counters. And so here what we're doing is we're counting the number of boarding passengers and the number of alighting passengers by location. So part of this technology is a tie to the automatic vehicle location or AVL system. And that's very important. Today, agencies tend to equip twelve to twenty-five percent of their vehicles with passenger counters and then those vehicles can be rotated around the system to obtain counts so that you know for all of your stop locations what the number of boardings and alightings are at various points of time in the day or various days of the week or various weeks within a month. Any of those time frames can be used. So the AVL is used to stamp those boardings and alightings with a location, a time, and a date.
Next is scheduling software. And here you can see that there are a variety of different inputs to scheduling and outputs. So here we're really talking about fixed route software on this particular slide and scheduling for fixed route. So we've got a couple of sort of sub-functions within scheduling and you can see on the left is trip-building, to the right of that is blocking, to the right of that is runcutting, and then we have rostering. And so within each of those sub-functions you can see on the bullets, specifically what the input is to that particular function and then what is happening within that function and what information is being output from that function. So I'm not going to read through all the bullets, but that basically shows you the various functions of fixed-route scheduling.
Moving on to connection protection. Transfer connection protection, or TCP, uses two technologies that we've already discussed. One is that onboard computer or mobile data terminal, MDT, that's operating in conjunction with the AVL system. And what happens is someone may board the vehicle and say, "I'd like to transfer to route number five." So the driver can actually input on the onboard computer or the mobile data terminal, information that someone would like to transfer to route five, and what's the likelihood that that transfer can be made. And the system itself, the AVL system, will actually calculate whether or not the outgoing vehicle, the vehicle that the person is connecting to, needs to be held and if it does need to be held, how long can it be held for? Clearly, you're not going to hold that vehicle to throw off your whole schedule; you're only going to hold it to a certain degree, depending on your parameters for making connections. So the central system is going to notify the vehicle operator who put in the information about a potential transfer and then it's going to communicate to the vehicle of the person it's transferring to; to let them know that they may have to hold for a minute or two for that connection to be made. These systems are also built so that the dispatcher can review pending transfers and they can make changes to that if they need to. And then very recently in the USDOT Connected Vehicle Program there was a discussion about having a specific application that does this in a multimodal environment. So you can imagine it would be a bit more complicated than the example that I just gave you, but it gives you an idea that this could actually be done on a multimodal basis.
Next we have signal priority, and again I don't want to spend a lot of time on it, because it does have its own module with a great amount of detail. What I just briefly want to mention is that there are three overall strategies. There's passive priority, which really does not require a lot of hardware and software investment. It basically operates all the time knowing how the vehicles are operating and it's pretty straightforward and pretty simple. Active priority is where there is a detection of the vehicle where it is and there's a specific request made to actually have signal priorities so that the vehicle can get through the signals. And then there's real-time operating and real-time with adaptive signal controls, which is a little more involved, a little more complex. Adaptive signal priority, it's a strategy that looks at trade-offs between getting the transit vehicle through the intersection, but then what do you cause if you cause any traffic delays? So it's looking at those trade-offs. So I think I'll leave signal priority there. You can get into a lot more detail in the other two modules about that.
Here I want to introduce a concept that I'll actually go back to a little bit. There are four major elements at play here and you actually saw that on the slide about transit vehicle location, that service package. You've got four major elements: the vehicle itself; the suite management center—so the dispatch office, in effect; and then you're looking at a traffic control—so that would be a signal or a piece of the infrastructure; and the traffic control system, which would be a traffic control center. So keep those in mind when you—if you take the signal priority modules, those will come into play.
Let's talk a minute about yard management. So what does yard management do? It helps to manage the vehicles when they're parked. The old way of doing yard management is with a clipboard. Somebody goes out with a clipboard after a pull-in and they make a little map by hand and they put in the vehicle numbers. So this is effectively automating that, so you know where all the vehicles are located in the yard or in the garage. It gives you a visual display just like that map I described but it's on a screen rather than on a piece of paper. And it allows folks that are in the yard potentially moving vehicles around—or they need to find out that they need to move vehicles around for the next pullout—it provides them with a way of doing that automatically. And it gives them an interface to record when the vehicle pulled out, when it pulled back in—those kinds of things.
So the next technology—and we're getting to the end of the fleet management technologies—is intelligent vehicle technologies, which really are a lot of the warning—collision warning systems. And you can see here from the six bullets, there's collision warning and any kind of conflict or changing lanes or pedestrian warnings. This is very, very important in the connected vehicle space. We need to know if we're in danger of colliding with an object or a vehicle or a person and so that's where this comes into play. So, overall, those technologies reduce the probability that there'll be an accident. And it also helps drivers to process a lot of information that's very hard for them to process while they're driving a vehicle.
Next is another one of the technologies that's called vehicle assistant automation. This is primarily where you're talking about—bus rapid transit is mostly what we're talking about here. And you can see the picture on the left has a little guide wheel that allows the vehicle to get as close as it possibly can to the boarding area; so that would be precision docking. And then that little guide will also help guide the vehicle as it's moving along when it's not stopped. There's also vehicle platooning so you can have several vehicles very, very close to each other and there's an automated way to control the space between them. And then automated operations, which you've probably heard the term "automated vehicles", where the vehicle is actually driving itself, but there are some technologies that allow that to happen safely. These pictures, by the way, are from the HealthLine, which is a VRT system in Cleveland, Ohio.
Talk a minute about lane control. So there are situations that you may be aware of where a bus is riding in a shoulder lane on a highway. And so these are the technologies that are used for that. There's also something called intermittent bus lane or moving bus lane and that's where a lane on a highway might be restricted for a specific period of time maybe during rush hour where it can be used by buses to move that bus a little bit more quickly. And one thing to note here is just the connection with vehicle location, which is needed to find the—to establish the bus location and so you know when the driver is moving in and out of restricted space.
So now our next activity is a question about those prior slides that we just talked about in fleet operations. So the question is: Which one of these technologies are included in the fleet operations and management category technologies that we talked about? And the answer choices are: a) onboard automated voice announcements; b) scheduling software; c) data management and reporting; or d) all of the above?
And here are the answers. The correct answer is b) scheduling software. This is the one technology that is included in that group of technologies we just covered and you can see the others: "A", which is the onboard automated voice announcements, that's not included anywhere in what we've discussed so far. Nor is data management, although data is being generated by these fleet management technologies. And then "all of the above" is also incorrect in this particular case.
So let's move on to the second category, which is safety and security. And here we're really talking about technologies that improve safety and security not just for vehicle operators, but for anybody in the transit staff or customers as well and there are—there's onboard safety and security systems as well as facility safety and security. So we're going to briefly talk about four technologies that are listed on this slide.
So let's talk about mobile and fixed video surveillance. And what we're looking at here is probably one of the most common safety and security systems are cameras. Pretty much everybody has cameras on their vehicles today and so what have we really—here they're really a form of crime deterrent is what they are. If someone knows on a vehicle that there are cameras, they might be less likely to do something, because they'll be identified if they do something that they shouldn't be. They're also used to review incidents that may have already taken place on the vehicle. And they also play a role in terms of traffic enforcement and that's because if you have a camera that's reviewing how the driver is operating the vehicle—so, in other words, potentially a camera that's pointed out of the front window of the vehicle, you know how the vehicle is being operated and whether there are any violations, like running a red light or something like that. Some of these systems allow there to be external access to the video that's being generated. You'd be doing that using one of the communications' systems that we talked about in fleet operations and management. And then, after the fact, you can go back to the video recording and actually be able to look at that activity that was going on board the vehicle to identify if there was any issues.
There also is a way to indicate that there's an emergency going on board the vehicle and to monitor the audio on the vehicle. This is a situation where the dispatcher or public safety officials can listen in onto what's happening while there's an incident. And that channel, so to speak, can be opened up without someone who's committing a crime knowing that they're actually being recorded and potentially watched. So there are covert microphones that it's a one-way communication; so it's just the dispatcher or public safety folks listening in so that someone doesn't know that they're being recorded. So you can see here on the left, bullets. The driver might press a switch indicating that there's an emergency. The dispatch office will immediately be informed of that so that they can take the appropriate action.
So we have the onboard DVRs because that's how we're recording what the cameras are seeing. And so DVRs typically have a lot of configurable parameters. You can decide what the resolution should be. You can decide what the recording rate should be and then you may have the capability to upload the video using Wi-Fi once the vehicle is in the garage—you can do that in a number of different ways—but that allows only authorized people on the transit staff to actually look to request a video and actually review it.
So last of the safety and security category technologies is G-force monitoring. And why is that really important? That technology is used primarily for two reasons: One is to provide a collision alert system and the other one is to actually monitor driving behavior. And it can be part of a collision alert system to log information about, you know, accidents, what happened at the point of impact, and those sorts of things. You can warn a vehicle operator about unexpected movements so that they're well aware of something out of the ordinary happening. And then it allows you to tag potentially what's being recorded when there is an incident so you can go back and you can look at—kind of like a black box and what's used in aircraft—where you can look at "So what was the speed of the vehicle before the accident?" "Were the brakes being applied?" That kind of thing.
All right. So, our next activity, which is based on our safety and security slides there, is a question: Which of these technologies are in the safety and security category? Answer A is G-force monitoring; answer B is data management; answer C is geographic information systems; and answer D is traveler information.
So to review the answers, the correct answer is "A"; we just got finished talking about G-force monitoring and that is included in safety and security. Data management is not, even though, again, data is being generated by safety and security systems, but it's being used, and you'll see a little later on, in a data management category. GIS is also incorrect. That's actually a technology within the data management category. And traveler information has its own category and actually has its own module that you will be able to take at some point down the road.
So moving on to our next category, our third category, is maintenance. And that involves three primary technologies that facilitate maintenance activities. So the first one is engine and drive train monitoring. So there are sensors on board the vehicle in the engine, in the transmission; it can be in the fare box; it can be in a number of onboard components that are constantly monitoring the way they're operating. Are they operating within the correct threshold of operation? For example, there may be an oil pressure sensor. Is the vehicle operating within the correct range of oil pressure? If not there's going to be a message that gets sent back to either dispatch or maintenance or maybe both that says, "Oh, this vehicle, the oil pressure is not within the correct range." Also, we have—so that's an out-of-tolerance condition. That's what it's called. Supervisors or maintenance personnel can use that information to do better with their preventative maintenance and potentially if they have to come in and intervene and do an unscheduled maintenance they can do that. This is going to give them information about that. One of the transit properties that we use as an example, several slides down the road in our case studies, actually found this to be one of the most successful technologies, because it allowed them to know that there was a problem with an engine before it became catastrophic and the engine needed to be replaced, which is very costly.
Maintenance software: There's a variety of different sub-functions that the maintenance software can perform and I listed them down below—I'm not going to read them all. But it really facilitates tracking every maintenance action that's taken. And also keeping track of your parts inventory, which is extremely important. So if there's some kind of maintenance activity you'll know who did the work, what vehicle was being worked on, what systems on the vehicle were being touched to perform that maintenance. Were there any parts that were used? If so, do any of those parts need to be replenished in the inventory? Et cetera. You get the idea of how—and that becomes a very, very rich database that can be used to really determine in the future how many of certain types of parts am I going to need? How much time does it actually take to fix a certain component?
Next is fuel management and this makes it a lot easier to record the use of fuel and other consumables, like oil, for example. So here it's going to monitor—and it's going to measure how much fuel is being put into each vehicle and it's going to monitor various things like fuel purchases and what's the fuel inventory? It's going to help you determine what it should be. There's a lot of information that's stored. You get information on how efficiently the vehicle's running and that information.
Okay, so that wraps up the maintenance category. Now we're on to our last category for technology and that's data management. It kind of incorporates several different technologies, some of which work together, some of them are also independent. So we talk—I want to focus a little bit on the second bullet for a minute. We talk about a lot of technologies, but do all these things actually fit together when we talk about fleet management? And we're going to—in the next learning objective—we're going to really tear that apart and really look at which technologies are dependent upon which other technologies. So at this point, we've got five technologies that we're going to talk about a little bit in data management. And I think in today's world, this could actually be one of the most important categories of technology that we'll ever have, because now we're in an age where we're doing a lot with the data that's being generated by the systems and we're able to better manage our transit systems by looking at that data. So a number of the systems that I talked about, or technologies, generate data. Example, vehicle location: You know where that vehicle is every minute it's operating. That's a very, very rich set of data. You know where it was at a specific time on a specific day. You know whether there were any issues with the schedule not being adhered to. You know if there were issues of if the vehicle was detoured or anything else happened. So it's really going to help you in the end to better utilize the vehicles that you have in the systems overall.
So let's talk a little bit about the integrations. We'll go into discussing that a little bit. So, there's a lot of opportunity for the technologies I mentioned before and some of the technologies that are discussed in other modules to be integrated so that they work together as a system and they can provide information to systems actually outside of transit, like the example here in the first bullet of our regional traffic provider. And so when you look at the importance of integration and why do we really care about this, first of all, you really don't want to have a lot of disparate technologies operating on their own, and potentially duplicating the functions of other technology. So you'd really kind of like to have one of each rather than have some technologies duplicate what other technologies are doing. And so one example of that is you could have two different GPS receivers that actually are giving you two different locations, even though that sounds a little ridiculous. It can be true because the location can be, you know, much more accurate in one GPS receiver and not so accurate in another. So we want to get away from that. And that's an example why you would want to have some integration. And then you're really facilitating an overall system that's comprised of these sub-systems that work together.
So the next in our data management category is GIS and probably a number of you are already familiar with that. Really, you're providing the capability to show information from a geographic perspective. And that could be as simple as showing where the bus operated during a typical day. And why would you want to do that? Because you may have had a customer complain that their bus never came to their stop. Well, if you go back and you look at where the vehicle was all day, you're going to be able to determine whether the customer is right or there was an issue with that vehicle actually not being at that stop at that particular time. So it really gives you the ability to map data that's geographically referenced and you can also create seams with the data. So, for example, you could show on a map where all the major employment centers are and then overlay that with your transit operational data to see if you're really best serving those locations as you would expect to do. You can also do things like examine "what-ifs." So what if I remove the stop at 5th and Main? What would the outcome be if I did that? Where would people go to catch the bus? Would there be less people catching the bus? And, again, from a geographic perspective, you're able to look at that. Also, it gives you the capability to do editing of that data and it also is the backbone for something that we call itinerary planning, or trip planning, where someone might go online and say, "I want to go from 505 Main Street to 100 3rd Street," and that actually uses the GIS to determine the best path for that person to take. And if any of you are familiar with Google Transit, for example, you can put it an origin and a destination. You can look at what it would take to walk, drive, to take transit if the transit information is in Google Transit. So that's another sort of GIS application.
And then here's an example that I wanted to show you visually. This is actually from Cape Cod in Massachusetts. And this shows the origins and destinations of para-transit trips in a town called Hyannis, Massachusetts. And the red asterisks show destinations where para-transit travelers are going and the green asterisks show where they're starting their trips. What does this tell you? Those two very fixed blue lines tell you that you could actually operate, maybe, a fixed route service among those three points and carry a lot of the people who are currently riding para-transit, which is a pretty costly service. So a lot of power with GIS.
Next is facilitating service coordination and here I'm really talking about human service agency transportation, Councils on Aging, that kind of an operation, where if you were able to use technology it really might help you schedule the trip a little bit easier and to actually have passengers reserve their trip, and things along those lines. So customers might be able to access scheduling themselves. You may or may not want them to do that, but that technology exists and then the service that's being provided to them could be provided by multiple providers of service—it could be a human service agency, it could be a transit authority, it could be both. And so the partners are connected, the transportation partners are connected with technology as well, and callers into sort of a one call center would be able to get information on all the services available to them. One example is the system that's operating in Kentucky, and it's called the Purchase Area Regional Transit or PART, P-A-R-T and they utilize some technology to allow folks to reserve their trips and it's in a coordinated environment so there are a variety of service providers. And so that's an example of technology being used to do service coordination, to facilitate service coordination.
Another very, very current topic is open data and open data is important because you want to get as much information out to the public as you can but you don't have an unlimited number of staff people to do that. And with all these technologies generating the data about how is the transit vehicle doing versus its schedule there are some automated ways of actually taking that information and putting it out to the public and it's through the use of what's called open data. And what that means is, the transit authority is opening up their operational data to anyone who wants to write an application that uses that data to be able to communicate with the public. So there's several definitions of open data but the primary three components of the definition are: It's accessible at no more than the cost of reproducing it without any limitations based on whoever wants to use it; It's in digital format to make it easier to use and to make it easier to combine with other data about transit operations; and there's no restriction on its use. So if you look around at—you can see here on the slide as of a couple of years ago, you can see how many transit agencies have open data and that number has gone way up since this particular study that this is quoted from has been done.
And there's something called open ITS standards which is different from open data. These are the standards that are made available to the general public and they were developed based on consensus among people who are directly involved in the technology. So one major set of standards in transit actually has two modules that you can take, it's the Transit Communications Interface Profiles. That group of standards was developed on a consensus basis by transit authorities, vendors, consultants, all kinds of entities that would have use for that. So that's what an open standard is. And it really facilitates again, going back to the very beginning of the module, interoperability and data exchange among different services. And so it's intended for widespread adoption. The example I give here is OpenStreetMap, which is currently being used by several properties, one in particular is TriMet, which is in Portland, Oregon. They moved over to the OpenStreetMap platform. And the way OpenStreetMap is defined is OpenStreetMap is built by a community of mappers that contribute and maintain data about roads, trails, cafés, railway stations, and much more all over the world. So you find applications built with OpenStreetMap as their foundation all over the world and that's an open standard.
I want to go back to the beginning of this category just a little bit and talk about data management. There's some information to keep in mind as you are trying to develop data structures or databases to hold your data. There's four elements that I want to speak very briefly about and they're called the four Ds. One is "demand" and what does that mean? The identification and prioritization of stakeholder data needs. What is that? That means that within your agency there's a whole host of people that want to use the data that's being generated. There's planning folks, there's maintenance folks, there's management, there might be financial folks. So they have needs for data. So we have to take that into account when we're building a data structure. In terms of the "dimension", that's really identifying the data elements themselves and their characteristics. What are the specific data elements and what do they look like? So the vehicle location, and then if it's vehicle location, what's the characteristic of that, usually a latitude and longitude. So that would be the dimension. The "data" is identifying the sources of data and determining how the data's going to be processed to be used. And then also there's an abbr that's used, extract, transform, and load procedures, which is ETL, and that's something that you hear as a buzzword these days, talk about procedures that are used to extract data and put it into a reasonable format or databases. And then the final D is "delivering" it, how should it be delivered? Well, it all depends on the user, it depends on, do I need a report for upper management that shows me the performance of all the routes in a certain period of time. That might be a report. So I need to show something like a visualization of some data. What does something look like that I've been trying to figure out for a while? So this is really the development of those tools to be able to deliver a display, the information that's being managed.
So a typical sort of data warehouse, they're also called data marts, you may have heard that term. A potential organization could be barrier individual databases that are archived on a regular basis, the ones in blue, these are things that are changing. For example, passenger counting, that's changing, vehicle locations are changing but it gets archived in the field as it's changing. And then the two red cylinders are really static data and that's for example, a list of all the routes and stops that would be used, the actual schedules of the vehicles. And then all of those are put into a data warehouse so that when the stakeholder makes a request, "I want to look at this particular data over this period of time," making that request, the data warehouse is going to be smart enough to go out to the correct database, grab the data, combine it, and give the result that is going to be useful to the stakeholder. So I think this is a very important part of what we're talking about with technology.
So what's our summary of learning objective 2? We went over the four major categories of technology, we talked about ten different technologies in fleet operations and management, four in safety and security, three in maintenance, and five in data management. We gave a fair amount of detail about what each of those are. And that really leads us into the next learning objective, which is "Well how do they all work together?" Are these things isolated things? And I remember I said, "No they're not because it really wouldn't be cost effective for them to all be out there on their own operating." So that's the summary of learning objective 2.
And that leads us to learning objective three. So now we're going to take the same four categories of information and I've reminded you on this slide, the definition of each of those categories, and what we're going to look at, is we're going to look at dependency, one technology dependent on another, and what are you really looking at by having one be dependent on another. So let's take a look at that. And again I'm not going to run through every row on these tables that show dependencies but I want to highlight some examples for you. So when we look at the first category which was fleet operations and management, you can see that middle column has the actual system and technology and then, what is it actually dependent on. So there are two of these slides because we had so many, we had ten technologies. So let's take a look at passenger counting for example. So that's the fourth row down and what are passenger counters dependent on? Remember I mentioned that they're often linked with an AVL system so that the counts at each stop can be stamped with a location, a time, and a date. So they're really dependent on that AVL system. What else are they dependent on? They need to know how the vehicle is operating, so they really need to know the schedule of the vehicle, so they really have to have the schedule of data, and they have to know where the route goes, like where does it stop because you have to correlate the boarding and alighting counts with where the stops are and again that brings in AVL as well. But there's a dependency that's super important so the question is can I just buy an off-the-shelf vehicle—sorry—passenger counting system without tying it to these things? Well, yeah, you can do that, but then you'll be duplicating those systems that you might already have, AVL, scheduling, and route information. We talked about those already. So that's one example there. And then what for example do we need for connection protection? I explained that at some level of detail. That needs vehicle location, you need to know where the two vehicles are, the vehicle the person is on, and a vehicle that they want to transfer to. But you also need the CAD system because you need to know how long could I conceivably ask for the vehicle that the person is transferring to hold up without ruining my whole schedule of operation? So there's dependencies there. Again, could you do connection protection by itself? In this case I'm not sure you could, I think you really absolutely have to have these elements. But again, it gives you an idea of the dependency.
Now I want to show you a chart, it's fairly complex, it has a lot of information on it, but it shows you the relationships among the transit management functions that we talked about and some of the functions that we actually haven't covered yet because they might be covered in another module. So if you look at the center of this diagram, we have some red boxes, one of them is a database server, one of them is CAD/AVL and vehicle component monitoring, so it's a variety of servers where the data is being stored. And that kind of correlates to our prior data warehouse concept that we had. And then those databases or servers can be accessed by other systems that are looking for information. So down at the bottom in the center, there's one box that says RTIS web server, that means real time information system and that says, well I'm collecting, I'm generating real time information and you can see that there are arrows out to a transit agency website for example, third party developers, they could be developing an app based on that data. So you can see what the relationship is there. And if you look off to the right-hand side of the chart, you can also see that there's access within the authority to a variety of the systems that we've talked about already. So there's a connection to look at electronic payments, look at vehicle components monitoring, and all the software that controls that and generates some of the data.
Then we also have kind of a similar chart but a little bit simpler, although maybe it doesn't look simpler, but a little bit simpler, that shows the relationships amongst the onboard components that we talked about. By the way, the previous slide and this slide, there's a full page of this diagram in case you can't see it very well on the screen. So we have all of our onboard components and typically they're connected to that onboard computer that we call the Mobile Data Terminal and you can see how they're connected and what the dependencies are among them.
All right, so based on talking about the dependencies, we have the next activity that we're going to cover and the question here is what—computer aided dispatch, so we talked a lot about what that does and how it works. Computer aided dispatch is dependent upon which of these technologies? And so that required that you looked at those tables and looked at the various dependencies that we were talking about. So the answer choices are: a) voice and data communications technologies; b) automatic vehicle location system; c) route and vehicle scheduled data; and d) all of the above. So let's look at the answers. The correct answer is all of these and on the table we showed you that computer-aided dispatch was actually dependent on all three of these technologies. So actually all of these are correct but the answer to the question is in fact, "D."
All right, moving on to safety and security. Again, dependencies, let me pick one of them. I'll pick the covert alarm technology and for the covert alarm and actual monitoring of audio, it's dependent on a couple of things, you have to have the capability to transmit audio. So what do you need? You need a voice communication system. You also are looking at data when the driver or the vehicle operator presses that switch to indicate that there's an emergency, there's a piece of information that has to go back to dispatch— that's data. We need the CAD system to look at what our various options are if we have to reroute something or we have to take some action with other vehicles based on what's happening on that vehicle. And then AVL, we need to know where the vehicle is, if we have to dispatch emergency personnel, we have to call police or fire, or something like that. So that's one example of the dependencies. And you can see the other dependencies on the slide.
All right, let's move into maintenance and again, I'll do this by way of examples. And we have three basic technologies that we've talked about before. And what I'm going to point out to you is oftentimes as you can see on this chart, there is no dependence on any other of the other technologies that we've talked about in maintenance. There is on the drive train and vehicle component monitoring but not on the fuel system and not typically on the maintenance software. So with the vehicle component monitoring it's typically those components are connected via an onboard local area network, which is called a vehicle area network, and they all kind of speak together so I can actually monitor what's going on.
So here's another activity based on what we just talked about. Within the maintenance category, is fuel management dependent on another technology? We just talked about that. Answer choices: A is yes; B is no. So the answer is "no", fuel management is not dependent on any other technology. And of course, yes is incorrect, since there's only one of those two that can be answered.
Okay, let's talk about data management. This is a little more complex and again, I'm not going to talk through all the rows, but let's talk a little bit about service coordination because we did talk about that before, that's coordinating services amongst human service agencies and transit authorities. So what facilitates the coordination service? It's really CAD/AVL but it's CAD/AVL for all of the participants because if I don't know where all of my vehicles that could potentially serve that customer are located, it's not going to help me. And then we have voice and data for the same reasons that I just discussed previously, we need to be able to communicate with all the partners that are providing service and one way of doing that and the only way of doing that is with voice and data communication. So that's one example for data management.
So to summarize, and you really can't summarize it all in one place, but I am going to just speak briefly about some of the dependencies. So these are excerpts from each of the individual tables that you had to show dependency and again, not going to repeat them but let's look at data management. We talked a little bit about open data and what is that based on? That's based on using standard formats for data so that people can access that data and potentially develop applications around them. And so that's based on standard formats, for example, and that was included in our table specifically. So that summarizes learning objective 3, so we're starting to get toward the end part here in our module.
So let's move into learning objective 4. And we've got three major things that we want to cover here. One is we need to talk a little bit about the systems engineering process because it's great to talk about all these technologies but how do you put that in perspective of a procurement or a deployment of those technologies? And one kind of easy way of putting it in perspective is using a systems engineering process. So we're going to talk about that a little bit. We're also going to talk about some of the transit management functions that we just spent a lot of time covering and which of those have standards and which don't. And I want you to have an idea of where can I go and look and see if standards exist. And then I want to talk about really the importance of systems engineering because we can't say enough about it, provides you a very nice framework to consider what technologies you need to purchase and then to actually procure them.
So let's move into the slides here. What do standards do for us? We just reviewed a lot of technology dependencies and in order for those to work really well, there's data that's being exchanged between one technology and another and a way to facilitate that is standards and I alluded to that earlier by saying they really govern how I'm going to exchange data and really make it easy. So a few of the first steps of that systems engineering process really ensure that that data exchange is going to be done appropriately and it starts to look at what standards are available to help you but it sets the stage for how you want to consider technology, what you're going to do when you buy it, and what you're going to do when you deploy it. So systems engineering really allows you to do several things, to define the system requirements based on what you know about the technologies. It allows you to identify and minimize risk—and I can't emphasize that more—the risk part has to be addressed, everybody wants to sweep it under the rug but this is where you look at it head on and you say, "What kinds of things could I run into and if I run into them, what do I do about it?" Third, systems engineering allows you to integrate system components primarily because you're identifying standards and you're making it easier to integrate those components like we talked about earlier. It allows you to manage the complexity of the system because you've kind of laid out things in a very logical way. We'll show that. It enhances communication amongst all the people working on the project, actually, everybody's working from the same sheet of music, they're all using the same process, they understand what the process is and so that's a good thing. And then they're also—systems engineering really allows you to look at the products and services that could meet your needs. That's another primary point in systems engineering. All you're doing is building a system to meet needs; you're not building a system to build a system, trying to satisfy somebody's needs.
So we thought the easiest way of showing you that is to give you some examples from transit properties or projects specifically, where they use the systems engineering approach. And so we have three examples here and they're from Chattanooga, Tennessee; Orlando, Florida; and then in California, there were a few systems that were part of this EDAPTS program. So you can see on the right hand column, it gives you a general summary of why are we talking about this in terms of systems engineering and like for the Chattanooga agency, they use the systems engineering approach and they modified it a little bit to suit them better but it gave them what they needed to do it the right way. That's what the systems engineering process did for them, we're going to talk about that. Lynx has used systems engineering extensively in a lot of their technology projects. We're going to talk about one in particular. And then the EDAPTS program, there's one example that also took the basic systems engineering approach and tailored it for a particular project that they did.
So now we're going to talk about how CARTA, the agency in Chattanooga adapted the systems engineering process, the Vee model and you have a copy of that in your student supplement. And you can see, it's still a Vee but they adapted, they tailored it for their own purposes. So the green boxes are activities that they did for the whole agency, so they determined what their needs were, they identified the technologies and the system overview. The blue boxes were done for each individual technology project, so they put together a plan of how they were going to deploy it, they procured that particular system. And then in the purple boxes, it was a combination of the consultant and the vendor providing the technologies that went through those steps for each system. So you can see the shape of the Vee is the same, the general steps and activities are the same, but I think the real key here is, what was the value to them of using this approach, why did they use it, did it help them with anything? And it did. It helped them document their long term vision, by doing those first couple of steps, they really had to look at what they needed and how it was going to work together. It avoided the temptation to do things too fast. One of the elements of systems engineering is that you have various checkpoints along the way, where you have to stop and you have to say, "Did I do everything in the previous step, did I get everything out of it that I needed and expected?" And if the answer is no, you have to go back into that step and potentially do some work. So it avoided the temptation to just rush through it because somebody wanted it done. This goes hand in hand; it also made them willing to expect delays when they needed to manage the risk. And so when one of those decision points came and they weren't happy with what they had just gone through, they were not afraid to go back and do what needed to be done to make it right. And then finally, there was a thorough testing approach that was used well before any of these technologies was introduced either to operations or to customers. So this slide really goes over what I just said and you can see, it helped them have an overall vision, I mentioned that. There was a rigorous testing program that was very important and they had a consultant on board. In their case they needed that just because they didn't have the staff, that's not always necessary at all, but they used the consultant to help them get through the whole process from start to finish.
Now a couple of their keys to success, again, I already spoke to a few of these. They use standards and that really highlights you why are going to use standards. And this brings back the example I gave earlier about the engine component monitoring, in their case was very, very useful. I talked about the long term vision, not doing things too quickly. One that I didn't talk about was using a data warehouse. They actually took the approach that we described so that it would make it very easy for people within CARTA, as well as outside, to be able to analyze the data that was being generated by all of the systems that they put in place.
Okay, let's move to LYNX which is in Orlando, Florida. They worked on a project that was part of the USDOT initiative that was called Mobility Services for All Americans. And they had a project that was called MORE TMCC or as it's spelled out, Model Orlando Regionally Efficient Travel Management Coordination Center. And when they were looking at setting up this coordination center, they said, "Well, if we use systems engineering, we know that we're going to meet the needs of the various users and we're probably going to be smarter about setting it up than we would be if we didn't use that approach. And they've used systems engineering for other projects at Lynx. So they said, "We're going to use the Vee model pretty much as is and that will help us develop the MORE TMCC concept and then eventually build it in the end." So really they asked themselves these questions, which the systems engineering process answers for you. What's the problem you're trying to solve? How do you think you might solve the problem? There's probably multiple approaches and the Vee allows you to look at those alternatives. Who are the stakeholders, who are what we're calling users? What do they need, what do they need the solution to actually do? And how does that solution work so that it meets their needs? And finally, when I'm designing the system, I have to take all these into consideration; all these questions that I just asked, the answers need to be part of that design.
So on this particular chart, they said, "Okay, we have four entities that typically, again, if you think about the architecture and what I mentioned at the beginning of the module, there are several elements, there's the customer, they're going to be using the system, there's the agency and the agency staff, there's vehicles operating within the system and in LYNX's case there's the Center for Strategic Operations. So this is for the whole agency. Within that, we need to make sure that this MORE TMCC operates within all of those realms, the customer can use it, agency staff can use it, it communicates with the vehicles and the operations folks are being able to use it. So through systems engineering, they were able to develop that concept and move from here into the design of that system, design and procurement.
Another example, I mentioned this EDAPTS, or Efficient Deployment of Advanced Public Transportation Systems. It was a project in California where they took several of the smaller transit properties and tried to—maybe standardize is not the right word here in this context but they did in a way—make it easier for them to utilize the best parts of systems engineering to work on their projects. So the example here is that they've simplified the systems engineering process, they've set up guidelines to identify needs, so they made it easier, they've set up tools, automated tools to write specifications, do things like that, and they offered them all of the research that was available on all of the technologies that they were considering. So that simplified systems engineering does a couple of things, it modifies that Vee model a little bit and I'm going to actually show you that. It assumes that I'm going to use as much commercial off-the-shelf software and hardware as I can because that saves me money typically if I don't have to customization. On the other hand, I may have to do customization, so I need to be open to that. But the simplified approach assumes that you're going to buy something off the shelf. It uses TCIP, which I mentioned is a group of transit standards that there are two modules that describe that in detail. It builds on those operations guidelines and some operational scenarios that were developed as well.
In the needs identified guidelines that were developed, there are really a total of five elements of those guidelines. Who could conceivably be stakeholders? What are the outcomes that you're looking for? What kinds of scenarios are you looking at? Are you looking at emergency scenarios? Are you looking at weather-related scenarios? What exactly are you looking for? What's your priority to deploy technology? And what are some of the operational—how would this actually work? So that goes back to in the Vee what we called concept of operation, how would this actually take place. So here's how they adapted the Vee. Again, looks like a Vee, pretty much the same, pretty much the same elements within the Vee. A couple of things are different and they grouped some parts of the Vee into groupings that made sense. So after the feasibility study, rather than call it a concept of operations, they called it operations guidelines. And that's very similar. So they grouped three activities together into operations guidelines, they grouped the system requirements and the high level design into a performance specifications and high-level design. They combined the procurement and installation sort of the bottom of the Vee, detailed design, installation, development, and some of the unit testing. And then going back up the other side of the Vee, all of the verification and validation steps are all grouped together. And then at the end, when you're going to make changes or upgrades, or you're going to do retirement or replacement, they have some service agreement. So this is the process that all of these smaller agencies use and they did it in such a way that it was very understandable. So that was another adaptation of the systems engineering process.
So now we have an activity based on what I just talked about and the question is: Does EDAPTS assume commercial off-the-shelf software or hardware using a simplified systems engineering process? And the answer choices are either "yes" or "no." And now we're going to review the answers and the answer is "yes", it did assume commercial off-the-shelf either software or hardware that uses that simplified systems engineering process.
So now let's talk a little bit about the transit management standards that actually do have—the transit management functions that actually do have standards and they are primarily in the fleet operations category and there are some in data management. So in fleet operations, we have several sets of standards that are used a lot in the industry. That's Society of Automotive Engineers, J1708 and J1939. Those are standards that are used for that vehicle area network that I mentioned is onboard the vehicle, where you plug different components into it so that they can speak to each other. 1708 is an older standard, 1939 is a newer and faster standard. J1587 defines the messages that are being exchanged on the J1708 network. There are a couple of other minor standards like 1944, which defines how a windshield washer system is going to be used, that kind of thing.
To continue, we already mentioned TCIP and I'm going to leave that for the other modules that describe TCIP, there was also a brief introduction in Module 1 that you probably heard. And then in talking about data management, there are a couple of standards, there are actually many more than this but these are the ones that you're going to hear most frequently. GTFS, which defines a common format for public transportation schedules and other information like stock locations and things along those lines. And then to take GTFS to one more level, there's GTFS real time which allows you to provide real time updates to the public based on the data that's being generated by things like the CAD/AVL system. So those are the basic standards and now we have another activity. And the question is: Which one of these standards is used for CAD/AVL? So answer A is GTFS; answer B is SAE or Society of Automotive Engineers J139; C is TransXChange; and D is all of the above. And the answers are B, if you chose B, you're correct, that is a standard for what's called a vehicle bus or a local area network within a vehicle, it's used for communication and diagnostics amongst the various components that are plugged into it. GTFS I just mentioned is a common format for schedules and other information like stop locations. And TransXChange is a UK standard, I didn't really even talk about that so I wouldn't expect you to know too much about it and all of the above is also not a correct answer.
So let's talk about the impact and importance of using systems engineering. So the principles that we talked about without reviewing them again, really support some planning and specification procurement and deployment and we really show on the next slide I'm going to show you a diagram that highlights why this is such a good process and why it has such a significant impact on the success of the deployment of a transit ITS project. And I think what you need to look at is systems engineering is not one discipline, it's many disciplines. You're going to have people on your project team that have different sets of expertise and you're going to want all of them to come to the table even though they have differing opinions about what's important and what's not and that's because you're again looking for user needs and all of them are going to be users. So it's important to take that interdisciplinary approach, which is what the systems engineering does.
So here's the diagram that I was talking about and it gives you—it kind of lays out the Vee from left to right rather than a Vee. And it's maybe not all the Vee but close to it. And it says, "Okay, here are my basic systems engineering steps, but there are different places that I have to stop along the way and I have to check back with myself, I have to check back and see, did I accomplish everything I expected, is it the outcome I expected? If it's not, can I do something about it? If I can, let's do it." So at the beginning of the process you're probably going to hire a consultant, you're going to consider that, so there's a procurement there and that means that that has to be approved. If you need a consultant, you're going to need approval for that and you're also going to need approval to move forward into defining a project. So I've got a couple of things that I got to be concerned about there. Once I explore my options and I think about exactly what it is I want to do, I'm going to have to have funding in place and I'm going to have to get my project approved. So I've got to stop point there that says, "Am I going to get approval? Do I have the money?" Okay, now I got approval, I'm moving ahead and I'm doing a project plan and a concept of operation. Well, somebody's going to look over that project plan and make sure it's doable. So there's another stop sign and that's, "I need approval of my plan." I then move into once I have approval of my plan, defining the system. Once I define the system I need somebody to say, "Yeah, you're allowed to go ahead and have somebody develop that." So that's another stop sign. And then as the development goes on and I do my testing and all that and I go into full operation, someone needs to say, "Yes, I approve that, it's now part of our basic operation, it works the way it's supposed to, it met all of our needs," and that's another stop point is that operational approval. Then I go into regular operations and maintenance and at some point I got to decide what I'm going to replace because it's only going to last a certain number of years and so that's another stop point and then I'm actually doing the replacement or retirement after that.
So I want you to keep asking yourself these three questions. Throughout the systems engineering process in your project, three primary questions. How well did the system satisfy the needs? If it didn't, systems engineering is going to stop you fairly early in the process and make you reconsider that. So hopefully you didn't get all the way to the end and ask yourself, you need to be asking yourself these questions through the whole process. Did the project stay within cost, the budget, and the schedule? That's a hard one because it could be that you had planned to spend more money up front and less money down the road, if that's the case, you would have known that and that's what you're measuring yourself against. But again, you need to be asking that all along the way. What types of challenges occurred during the implementation? Why am I asking that question? Because the next project you do, you need to learn from this one. So that's why that question is there. You could actually say, "What types of challenges occurred during each step of the process?" and you'll be smarter the next time around. "Well, you know, we didn't consider this, next time we do this; we'll remember that we need to do it."
So summary of learning objective four, we talked a lot about the role of systems engineering. I gave you several examples as to how systems engineering was used at CARTA, at LYNX, in the California project, and I think those all lend themselves to show you the impact on the success of those projects. And we also talked about standards. There are standards in fleet operations and management, data management; there are virtually no standards by the way in safety and security, the systems we were talking about and really none to speak of on maintenance, except where you might be using a vehicle area network to plug those vehicle components in to do vehicle component monitoring.
So we talked about the impact, how you're trying to address stakeholder needs, you want to make sure that the design is considering all of the user needs as well as all of the other parameters that you've determined along the way. You may have some constraints by funding, there may be other political constraints and you need to be fully prepared to deal with the risks, which could include technology, if your budget is limited, how are you going to be successful with a limited budget. Same thing with schedules, somebody says, "I wanted it yesterday," but you know that you can't produce it yesterday. You have to take those into consideration. So we have some basic principles that we've covered in this module that we want to go over and give you the opportunity to answer these questions for yourself.
So we went over the four learning objectives just now and main points of what we were talking about. And so our first statement is, "The National ITS Architecture allows for "blank" at the local level." So that "blank" is tailoring. You can use the National Architecture and tailor it however you want, that was something we mentioned at the very beginning. User services represent what the system will do from the perspective of "the" user. And that's why it's called user services and that's one of the primary reasons to do systems engineering and to have even identified these user services.
We spent a lot of time reviewing the functions within the four major categories so I'm hoping by now you can remember those major categories. A is fleet operations and management; B is safety and security; C is maintenance; and D is data management. And now I've picked on one of my examples that I use to fill in the blank, "APCs are dependent on "blank" and "blank."" So the first "blank" is dependent on AVL, we talked about that a little bit. And the second "blank" is route and vehicle schedule data. And finally, to use one of our examples and this one from Chattanooga, "CARTA tailored the "blank" approach to better suit the "blank" of their organization and the "blank" approach used to develop the overall technology program." So CARTA tailored the systems engineering process approach to better suit the scale of their organization and the incremental approach used to develop their overall technology program. So that is in a nutshell what we've learned.
There are some resources here; there is an extensive list of resources in your student supplement. And to give you an idea of what comes next after this is Part 2 of 2, it's Module Five, it's Transit Management Standards Part 2 of 2. And it provides an overview of how to identify, describe it at fairly high level, and apply standards to successfully procure and operate transit management systems. And we talk in more detail about the standards, some of which we've already introduced here in this module. And we have some case studies in Part 2 of 2 that will help you understand how to utilize the standards. And with that I will close the module.
#### End of Module_2_Transit_Management_Standards_Part_1_of_2.mp4 ####