ITS Transit Standards Professional Capacity Building Program

Module 19: On-Board Transit Management Systems

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.)

Vincent Valdes: ITS Standards can facilitate the deployment of interoperable ITS systems, and make it easier to develop and deploy regionally integrated transportation systems. Transit standards have been developed by transit professionals like you at a national level to encourage competition and limit costs within our industry. However, these benefits can only be realized if you know how to write them into your specifications and test them. There are now a series of modules for public transportation providers that cover practical applications for promoting multi-modalism and interoperability in acquiring and testing standards-based ITS Transit systems.

Carol Schweiger: Welcome to Module 19, which is about onboard transit management systems, and the diagram that you see on the opening slide is something that actually is in our presentation, and I will explain it at some level of detail as we go through the presentation.

Carol Schweiger: My name is Carol Schweiger and I’m the president of Schweiger Consulting, and just very briefly, I have about 37 years of experience working in transportation technology consulting, and I’ve been very fortunate to work with probably over about 50 different transit agencies in their planning, design and deployment of technology. So I’ll try to interject some of that experience into our course today.

Carol Schweiger: So let’s get right into it. The module today has three learning objectives, and you can see the three displayed here in different colors, and we have the slides somewhat color-coded to go with each of the learning objectives. First, we’ll be reviewing some key concepts from a prior module, which was Module 5, which was called Transit Management Standards, Part 2 of 2. So that’s our first learning objective is to just give you a review of that. The second learning objective is to describe how to use the standards that you find most frequently in the transit industry for onboard systems, particularly for buses. So we’ll talk about how you utilize those standards. And then the third learning objective is to give you a series of examples of how these standards are used, particularly when you are procuring these types of systems.

Carol Schweiger: So we’ll move right into Learning Objective 1 where we’re reviewing some of the concepts from Module 5.

Carol Schweiger: So first, we’re taking a look at how standards really facilitate meeting user needs, and here let’s start by defining a user need, just so we’re all on the same page. A user need is defined as a user requirement for a system that a user believes would solve a problem that is experienced by the user. So keep that in the back of your mind as we’re going along. And really, by establishing the needs, the users are saying, "Here is what I really would like to have from this system that you’re building," and then you will use that eventually to make sure that the vendor that is supplying the system satisfies those user needs. So that’s why the needs are so important. Also, identify user needs as part of the systems engineering process. So if you’ve taken some of the earlier modules about systems engineering, you’ll find that that’s a distinct step. So, we’re talking about standards really helping to meet user needs, and why do we really care about standards in this case is because standards really facilitate the exchange of data and information among applications and among different entities. So, for example, a transit authority may be exchanging data with a traffic management center. So using a standard is going to facilitate that exchange of information. And also, if you’re using common standards that others are using, it’s going to typically reduce the cost of what you’re doing.

Carol Schweiger: Moving forward a little bit, what are the benefits of doing this? It sounds great, and we know that most transit operators are not typically interested in the detail about the standards, but what are the benefits of the standards, and here the standards are really a tool to help you reduce the complexity of a system and, as I mentioned earlier, to really reduce the cost of that system throughout the lifecycle of the system. So when you’re planning it, when you’re designing it, when you’re procuring it, and when you’re implementing it. It also gives you typically the widest variety of vendors who will be interested in providing that system for you. So that’s very good competition in the industry and very helpful to you to get the greatest number of vendors. And also standards are really strategic in a sense to the performance of the system in the end. Those are things to just keep in mind.

Carol Schweiger: So, really how do standards facilitate meeting user needs? And here we really talk about three different areas which we covered in Module 5. Standards help you protect your investment; they help you with interoperability if you’re going to be exchanging information with another system; and they also help you improve the quality of the system as well as the value that that system is providing. So if we take a minute and we look at how are you really protecting your investment, there are three sort of subtopics there. One is that a standard really allows you to build a system in modules. So that has some real advantages where you can use an incremental approach to implement a system. Maybe you implement some of the modules first and then you add more later. It also, as I mentioned, gives you a great choice of suppliers. We’ve talked about that already. And it also allows you to reuse some specifications that you may have already developed that use those same standards. So it saves you some time there. In terms of interoperability there are two major benefits here. One is that standards really give you sort of a clear path for implementation and allow you to use the standards to help you test the system as you go down the road, and the other benefit is really in data management. Using standards really helps you reduce the cost for managing the data and it gives you a little more in terms of tools that you can use to help manage that data. And then our third point, which is the quality and value, we have six different benefits here. One is reducing risk, which we will be talking about throughout the module. It gives you where you have very well or mature standards, well evolved standards. Generally that gives you a better product than something that’s just a one-off, that doesn’t have any standards, and you can’t really reuse any part of it. We talked a little bit about allowing you to test and making that testing a little bit easier to do when you use the standards. Some standards are actually accompanied by some conformance criteria which you can use in your testing program. We talked about the modularization already, and we also talked about reuse already.

Carol Schweiger: So let’s move on to one of the major concepts that I want you to also be thinking about, and this was introduced in Module 5 as well. It’s called the Open System Interconnected, or OSI, model, and what that is, it’s a standard. It’s an international standard based for communications that defines a framework of networking, and it implements protocols at different layers, and you can see the layers in the bullets toward the bottom of the slide. I listed out the seven layers in OSI, and I’m going to talk about them in the next couple of slides.

Carol Schweiger: So we start from Layer 7 and work our way down. This is typically when you’re discussing things from Layer 7 down to Layer 1, it’s because Layer 7 really brings everything that you’ve discussed previously together and Layer 1 is the most basic layer of the communications. So let’s talk about that a little bit. So Layer 7. This layer supports application and end-user processes. So this is really the endgame when you’re using a standard. Layer 6 is the Presentation layer, and this particular layer gives you the independence from differences in data representation. So some data might be encrypted, for example, some data might not be, but this layer translates from the application to a network format. So it transforms the data into a format that Layer 7, which we just talked about, can actually use. If we move down to Layer 5, also on this slide, that’s called the Session layer, and what that does is it establishes, it manages, it concludes conversations that are taking place like data exchanges, for example, and dialogs between the different applications. So that’s what the session layer is.

Carol Schweiger: And then moving on to Layer 4, that’s called the transport layer, and this really gives you the transfer of data between systems, or they may also be called hosts, and this layer is responsible for the error recovery and the control of the flow of data that’s taking place. The network layer, which is Layer 3, provides switching and routing technologies and it creates the path for the data. That may also be called a virtual surrogate, if you’ve ever heard that terminology. The data link, which is Layer 2, here packets of data are encoded and then decoded into bits. So this is really where you have the transmission protocol, knowledge and management. And then the most basic layer is Layer 1, or the physical layer, and this is the layer that conveys the bit stream of data. So it’s right at the very basic level. It’s either an electrical impulse or it’s a light or it’s a radio signal, and here the bit stream is being conveyed through a network. So that’s the very, very basic layer.

Carol Schweiger: So keeping that OSI structure in mind, let’s talk a little bit about our first set of standards that we talked about in Module 5, but just by way of reminder I want to talk to you a little bit about it. So the Society of Automotive Engineers, which is what SAE stands for, J1708, it’s a specification that was developed specifically for heavy duty vehicles, and this was buses and trucks when it was originally developed, and it was considered to be the first standard of an onboard network, which is typically called a vehicle area network, and it’s also analogous to a local area network, which is something that you might have in your office that connects all of the computers together into a server as well. So it provides serial communication between modules or components that are onboard the vehicle. So for example, an automatic passenger counting system may be communicating with a mobile data terminal or a mobile data computer. So it would be using the J1708 standard. So a couple of advantages to using this standard, and again, it minimizing the cost of the hardware if you’re using that standard. It gives you some flexibility to expand your systems onboard the vehicle, and it uses standard electronics, which makes it a lot easier when the system is being developed. One thing I want to mention here about J1708 is that it only describes the very lower layers, Layer 1 and 2, which are the physical and the data link layers-- it only defines those, and so you really need another standard for it to work with to bring in the other layers that we’ve discussed prior. So here you can see that it’s always used in conjunction with another standard called J1587, which provides several of the other layers that you’re really looking at. It’s used for the data exchanges themselves. So that’s something that we’re actually going to come back to. J1587 describes the message formats when the data is being exchanged. It’s the format, and it defines the parameters of that message, and you’ll see an example in a couple of slides what that actually looks like. It also defines the format of the J1708 messages that are sent between the components. The J1587 message, it has a couple of components to it. It has a message ID, which you’ll see what that is; it has some parameter identification; and it has something called a checksum, which is a count of the number of bits in the transmission that are included so that when the message is received you can actually check and make sure that all those bits of data arrived. So that’s also important. And the transmission rate-- this is going to come up a little bit later-- is 9600 bits per second.

Carol Schweiger: So let’s move into another standard that we’re going to be talking about pretty frequently. This is SAE J1939. This is a high-speed version of the J1708 standard, and it came a little bit layer and has almost replaced J1708 and J1587, not entirely, but it has replaced a lot of the J1708 networks. So it’s a high-speed network that is defined by something called a controller area network, and what that is, is a form of serial communication that was developed in the ’80s for in-vehicle networks. It’s used pretty extensively in automobiles, so it’s a pretty common way of communicating. And so here you see that, again, it’s higher speed; it’s a communications network that supports real-time what is called closed loop control functions; and it greater simplifies the exchange of data and information, and that’s partially why it’s higher speed. And then you can see-- and we’ll look a little bit more closely at the structure of this-- but the 1939 message uses an identifier that defines the priority of the message, from where the message was sent, and the data that’s in the message. So that’s primarily what we’re doing with 1939.

Carol Schweiger: So what I want to talk about is which layers does J1939 use based on the OSI model that we talked about previously, and you can see in this little graphic on the right-hand side are seven layers, which we described previously, and then there are multiple documents that describe that layer of the J1939 standard. So let’s talk a little bit about that. So if you go down to the bottom of that diagram, we have our physical layer which is the electric interface with the particular component. That’s at the bottom layer. Then the data link layer is the data communication, which is based on that controller area network that I mentioned previously. Then we have Layer 3, which is the network layer, and that’s really where you’re transmitting the messages between two parts of the network.

Carol Schweiger: And then we have, on the next slide, Layer 4, which is the transport layer, and that describes the various kinds of services for message exchange. So it’ll describe the request mode for the data, whether the transmission was acknowledged or not, and then if there are large blocks of data, it’s making sure that it’s being transmitted in smaller pieces which, again, allows the faster transmission than the J1708 standard. And then we have-- we’ve skipped over Layer 5 and 6, which are not included in J1939, and we go to Layer 7, which is our top layer, and here this describes the actual data. So the data itself, the parameters that talk about maybe the range of data and the resolution of that data, and then we have the actual management of the network, and this allows you to plug in additional components that are going to be exchanging data with other components on the network.

Carol Schweiger: Another thing that I want to very briefly talk about by way of review of Module 5-- and I’m not going to go into any detail here-- but I wanted to remind you that ITS standards are also classified in terms of application areas, there are just a couple to keep in the back of your mind. One of them is center-to-field applications, and this area really covers the interface between like a dispatch center or a transit management center and other equipment that may be operating in the field. So a good example of that is dynamic message signs, which could be located, for example, at bus stops or subway stations, and so there’s information from the dispatch center being sent to the field to a dynamic message sign. Another good example is signal priority, which is listed here. So that just gives you an idea of center-to-field applications.

Carol Schweiger: And then we have center-to-vehicle and center-to-traveler applications, and here let’s talk first about our center-to-vehicle applications, and this is where you’re really talking about the dispatch center communicating with systems onboard the vehicle. So that covers the interfaces between a dispatch center and various components on the vehicle, and you can see here on the slide the variety of different types of information that are either being collected or being transmitted in both directions to the dispatch center and to the vehicle. So this gives you an idea of the scope of that application area.

Carol Schweiger: And then we have the center-to-traveler application area, which is probably fairly straightforward here. This covers the interfaces between the traveler information providers-- that could be a variety of providers, including the transit authority-- and the devices that people who are actually traveling are using. So they could be using a smartphone or something along those lines. So these are the types of data that are actually being used with the center-to-traveler information. These are pretty straightforward.

Carol Schweiger: And then we have center-to-center application area, and this is what I alluded to previously, where you’re interfacing between a transit dispatch center or a transit management center and then other centers like traffic management or something along those lines. So here we’re really talking about multimodal coordination. If anyone has taken the integrated corridor management module, there’s a lot of discussion about this particular application area, because there’s a lot of information being exchanged among the various centers in your corridor that you’re using ICM with. So this gives you an idea of the types of data exchanges that are actually taking place.

Carol Schweiger: So let’s kind of wrap this review up by looking at a case study, which we did also look at to some degree in Module 5.

Carol Schweiger: This is a case study at the Chattanooga, Tennessee, Area Regional Transportation Authority, or CARTA, as we talk about it, and back ten years in 2006 CARTA defined there to be a vehicle area network in all of their buses, and so they defined a J1939 network, and one of the things that they were most concerned about was tracking the health of various systems onboard their buses. So they were primarily looking at engine, transmission and braking issues that were taking place, and they wanted to log the problems with these so they could take a look at them and potentially prevent an issue in the field where a bus might die and they have to replace it with another bus while they’re transporting people. So here, they eventually put a system together using J1939 that integrated with other onboard systems but provided them with this very important information about the health of the engine, the transmission, and the braking system.

Carol Schweiger: So what they were looking at was, if we sort of think about our application areas, here was center-to-vehicle, and it was communication of the health of those systems that I mentioned. So when they wrote their specifications to purchase a system to capture this health information, they included requirements that specifically talked about J1939. So how did they do that, and why did they come up with J1939 specifically? They reviewed these standards that were available in the field and decided that J1939 was the correct one. So after they made that specific selection, they incorporated information about using that standard in several places in the specification. So here’s an example of some of the places within that specification that they specifically called out the use of J1939. So you may recall that case study from Module 5.

Carol Schweiger: And then the other review that we want to do is, how do you actually read a standard? A lot of people have had that question, specifically if they’re not involved at the detail level of the standard. So one thing to keep in mind is different standards are structured different ways. Already I mentioned that J1708 has different elements in it than J1939, and that there are some other de facto standards that you may have heard about-- the general transit feed specification. That’s a completely different-- has a completely different format and is structured very differently from the onboard standards we’re talking about here. And so people often ask, "Well, how much of this standard do I really need to understand? Do I need to know the bits and bytes, or can I understand something at a higher level?" So you need enough understanding to know which standard to select for your project, and that is based on a lot of the things that we’ve already talked about in this review module. You have to be able to define the use of the standard when you’re writing a specification, and you need to define how you’re going to specify compliance with that standard that the vendor will need to meet.

Carol Schweiger: And here’s an example that I wanted to give. The J1939 standard actually has a series of documents that talk about basically what is in each of the layers—the OSI layers—that it uses. So you will have different documents, and here you can see the series of documents and their various numbers. And so, for example, if you wanted to learn more about the data link layer, which is Document 21-- it’s sort of in the middle of that chart-- that describes the rules for constructing a message, accessing the network, and detecting any errors in transmission. So if you wanted to know more about that, you would go to that particular document and read more about it.

Carol Schweiger: And then there’s a little more that goes with it besides just reading the documentation, and that’s an understanding, for example, for J1939 specifically, is most of the messages within that network are intended to be broadcast. And what does that mean? It means the data that’s transmitted on the network doesn’t have a specific destination. The data is in the network; it’s being broadcast generally; it doesn’t have a specific destination. So most messages are actually intended to be broadcast and that’s an important thing to understand. So without having that specific destination, what does that mean? It means that any device can use that data that’s on the network and it allows-- when you add modules to that system, it means that those modules can also use that data very easily because it’s on the network. When you do have a situation where specific data has to go to a particular device, then you’re going to have an address for that, and we’ll talk about that when we talk about how the standard is formatted.

Carol Schweiger: And then there are often questions about how to incorporate a standard in a specification and we reviewed this in Module 5 as well. You’re going to have a concept of operations. This is where you talk generally about how the system is going to work. You then talk about the components of the system that you expect to have. When you start talking about those devices or components and then what functions they are going to perform, this is really where you start talking about standards, about ranges of data that is valid, and we’ll see that in the next learning objective. You talk about requirements for those components, what are the functions that they’re going to perform, talk about the standards that you’ll use there, and then how you’re going to test them.

Carol Schweiger: So in a flowchart, if you like flowcharts a little bit better, this shows you exactly what I just described. You start with the concept of operations, then you document your requirements. You select the functions that are going to be standardized. You talk about which standards they are. You talk about the ranges of data values, and then you’re going to select those specific objects and the values of the data that have to meet the requirements, and then you put together your test procedures.

Carol Schweiger: All right. So that completes our review of Module 5, and I have a little quiz question here for you.

Carol Schweiger: And the question is: Which one of these is not a layer within the Open System Interconnection, or OSI, model? And the answer choices are, A, the application layer; B, the data layer; C, the service layer; and D, the physical layer. So which one of these is not a layer within the OSI model?

Carol Schweiger: And here are the answers. The correct answer is C. Service layer is not a layer within the OSI model. A is indeed a layer. The application layer is Layer 7. The data layer is Layer 2. And the physical layer is Layer 1. So that concludes our review of Module 5.

Carol Schweiger: So let’s now move into Learning Objective 2, which really talks about the details of these standards for onboard systems.

Carol Schweiger: Let’s start by defining the J1587 standard. So you may recall that J1587 is a specification that defines the messages that are transmitted on a J1708 network, and the J1708 part of it specifies the data link and the physical layers, while the 1587 standard specifies the transport, the network, and the application layers. This is somewhat outdated. It is still in use by some transit agencies, but it is being replaced by 1939, so keep that in the back of your mind. And we had mentioned before about J1587 is that it defines the format of the messages and the data that’s being communicated among components onboard a transit vehicle. And we spoke about this before-- the use of the standard promotes the compatibility, and then it’s used with J1708, which we mentioned earlier in our review.

Carol Schweiger: So let’s take a look at what the format of J1587 is. So all the 1587 messages have a message identifier, one or more parameters to define the data that’s being transmitted, and the checksum, which I had mentioned previously, and you can see at the bottom of the slide there’s a little graphic there that shows you what the message looks like. So the message starts with a message identifier, which indicates the source address of the component that’s actually transmitting the information. So we start with that.

Carol Schweiger: And just to give you an example of what one of these messages looks like, here we have a battery voltage that we’re looking at and the message identifier is actually 128, which means it’s part of Engine #1. So we’re looking at the battery voltage for Engine #1, and battery voltage is a parameter, and it has an identifier of 158. Now, here I’m not going to go into the mathematics of the other numbers that are actually shown on the slide, but the description of the mathematics is in your Student Supplement, so you’ll have the full description of why those numbers are specifically in that message. But that’s what the message looks like.

Carol Schweiger: So how is this actually used? We already know it’s outdated, but it’s used for these three types of data: for information about the health of some of the systems onboard the vehicle and some of the components, like a fare collection system. It’s also used for routing and scheduling information, which is typically sent to a mobile data terminal or mobile data computer onboard the vehicle so that the driver has some information. And then there’s driver information that may be transmitted back to the dispatch center for the dispatcher to look at, whether the driver is running their route on time and things along those lines. SAE J1708 is providing the hardware and the data exchange information, as we talked about previously, and so we know that they work together in concert. We talked about that before. And so typically they are described together in a specification, not separate.

Carol Schweiger: So now let’s talk in a little more detail about J1708 and what it looks like. And so J1708 supports, again, the communication among devices that are onboard a transit vehicle, and here we’re really talking about information being exchanged among different components, and I had given you an example earlier about a passenger counting system communicating with a mobile data computer, for example. That would use J1708. So J1708 gives you a message for determining which device onboard the vehicle or component onboard the vehicle is actually communicating the data. What’s the length of time that each of those devices or components is allowed to communicate that data? Which device has priority in accessing the 1708 network when two components are trying to communicate at the same time? And it also determines that the message was received correctly, or it wasn’t received correctly. So it does some error-checking as well. So that’s sort of the detail of the J1708, and remember, it describes those two layers within the OSI model, the physical and the data link layer.

Carol Schweiger: And to continue, we know that we use it in concert with J1587. And then we talked a little bit about this in Learning Objective 1, why would we use this. Again, minimizing cost, allowing expandability that’s pretty straightforward and easy, and then you’re also using the standard electronics. We talked about the transmission rate earlier. It’s 9600 bits per second. And the message can be up to 21 bytes long, and that’ll actually come up a little bit later when we compare it with SAE J1939, which allows a longer message.

Carol Schweiger: So, let’s take a look at a J1708 message, what it actually looks like, and we can see at the bottom of the screen that it has a message identifier, it has some data within the message, and then a checksum at the end to determine that it was send properly. So our message identifier here basically is a predefined value from 0 to 255, and you can see here on the slide that different values of message identifiers belong to specific devices and they’re used sometimes for future applications; if they’re new onboard components that may be defined, they would use those in the future. And there are other message identifiers that are specifically designated for a specific purpose. So for example, message identifier 111 is actually designated for factory tests of onboard devices and it can’t be used by any onboard device. It’s just for factory testing specifically. So that gives you a little bit of idea about the message identifiers. And, again, in the Student Supplement what we did was talk about the math that defines this message example at the bottom with these specific data, where it says Data 1, Data 2, and Data 3.

Carol Schweiger: Now, in the same way that we talked about J1587, we want to talk about the use of J1708, and specifically here, again, we’re exchanging information between what we sometimes refer to as a VLU, or a vehicle logic unit, which can also be called, again, a mobile data computer or mobile data terminal-- there are different terms for it-- and potentially a vehicle location system, a fare collection system with a fare box, the radio. We may have onboard signage that shows you what the name of the next stop is going to be. So those are some examples of its use, and here are a few more examples. I didn’t talk previously about onboard cameras but you could certainly exchange information between the camera and the AVL system that stores the video images but gives you the location of the vehicle at any point in time. And then we’ve talked about-- this is our example about health monitoring, the capabilities of health monitoring, of onboard components.

Carol Schweiger: And this is a diagram of a J1708 network, which is that thick, dark line on this picture of the bus, and then off of that dark line, which is the network, are the devices that are communicating data. So you can see the automated fare collection system, the passenger counting system, etc.

Carol Schweiger: Let’s move into our final discussion of the details of J1939, which is our more recent standard, and let’s talk a little bit about that. It really defines how the information is transferred across the network and it allows components and devices to communicate information. There are 17 documents that describe the various layers of J1939 and go into some level of detail in each of those documents. It’s capable of handling everything that was handled previously by J1708 or 1587 as well. It spans all seven of the layers. It uses all seven, and it has a data rate of 250 thousand bits per second, making it much faster than J1708, which as you recall was 9600 bits per second. So it’s quite a bit faster than J1708.

Carol Schweiger: So continuing to look into it, there’s another difference with J1708. It permits the connection of 30 components or devices onboard the vehicle as compared to only 20 devices if you use a J1708 network. So you’re allowed to connect a lot more. Again, I’m going to remind you that most of the messages that use a 1939 network are just intended to be broadcast, which means they’re not going to a specific destination, and that means that the data doesn’t really need to know where it’s going; it’s already on the network. So that’s very important, and it allows this expansion in the future where you can add more devices or components, and it uses this controller area network protocol which we talked a little bit about earlier.

Carol Schweiger: So continuing on a little bit, when we look at J1939 and we look at the various layers, J1939 is really used as an application layer, which is Layer 7, because it provides the communication between various devices onboard the vehicle. So think back to the example of CARTA in Tennessee using a 1939 network to look at the health of the engine, the transmission, and communicating that back to the dispatch center. And J1939 also defines message timeouts, how the larger data messages are actually fragmented into smaller data messages, which is what provides some of the speed that 1939 has, and it also speaks to how the various applications address the network itself. So we’ve talked about most of this previously. It uses the controller area network protocol, so any device can transmit a message on the network. And then we talked about this before too: Every message has an identifier that gives the message a certain priority. If two devices are trying to communicate data at the same time, it defines which of those has priority. It also identifies which device is sending the data and then it actually has the data included, and then there is a way of resolving any kind of data collision that might take place, and that really uses the message priority that we spoke about earlier.

Carol Schweiger: And we have a little more about J1939. The way 1939 looks-- and I’m going to show you a diagram on the next slide-- the first three bits of the message are the priority field. The next bit is reserved for future use and is typically zero. The next is what’s called the data page field, which is-- it’s used to really expand the maximum number of messages that you can send. And then there’s something called the protocol data unit format, and I’m going to actually show you on this next slide how it works. And then you have, finally, the end of the 1939 message contained bits that are called protocol data unit specific, which is based on the values in the previous field, which is the protocol data unit format field.

Carol Schweiger: So let’s actually take a look at what this looks like. I think it’s a little bit easier for you to understand. So that first PDU F that we talked about, it’s intended for a specific device. The PDU S is an address of the specific device. So when we look at this, here we have-- we just circled the destination address that we’re utilizing, and if you’re intending all the devices to receive the message, then the PDU F is a group extension field that can say the number of messages that are actually being broadcast, and I circled that in PDU 2. So that’s called the group extension, and it has the same length as the destination address. And then the last eight bits which I talked about before identify the address of the device that’s actually transmitting the data. So you can see that circled on the first look at what J1939 looks like. And this is also incorporated in the Student Supplement if you want to look at it a little more closely.

Carol Schweiger: So, some of the characteristics. Again, it sits on top of a controller area network identifier. The bit rate we talked about is 250 thousand bits per second. It uses either peer-to-peer or broadcast communication and the broadcast is where one device is just broadcasting its data to all the other devices. Just a couple of the other-- it defines parameter groups for-- it can be transit vehicles or other heavy duty vehicles, like trucks, commercial vehicles, for example, and it does support manufacturer-specific parameters that may be defined by vendors that have provided various systems onboard the vehicle.

Carol Schweiger: This gives you an example of-- on the left-hand side we have a series of sub-bullets that define a parameter group definition, where we’re looking at engine temperature for a particular engine; and then on the right-hand side we have an example of what the actual data bytes are. So here, we’re looking at engine cooling temperature, engine fuel temperature, engine oil temperature, etcetera. Those are all the various data that we can be looking at to tell us what the actual temperature of the engine is.

Carol Schweiger: Let’s talk about a couple of other commonly used standards in today’s transit vehicles. One of them is IEEE 802.11x, and you may be familiar with that because we typically talk about wireless local area networks as having an 802.11 standard, and why do we really care about these particular standards in this environment is that wireless access points are typically used to facilitate the exchange of information from vehicles to a central database when they’re either in a garage facility or they’re near a garage. So, for example, an automatic passenger counting system may be collecting the passenger counts onboard, but at some point they are going to be transmitted to a database, and so if that’s the case, then these wireless access points are going to use an 802.11x standard for that data communication within the garage, for example. Pretty much currently agencies use 802.11AC, but there may be some other 802.11 standards being used, and really the use of the 802.11 really started about ten years. Also it is used for onboard internet, which some transit properties provide for their customers when there is onboard Wi-Fi. So that’s another use of that particular standard.

Carol Schweiger: There’s another concept that we feel is very important when you’re discussing onboard standards in transit vehicles, and that’s the single-point logon. So I mentioned earlier that there are a number of devices communicating information whether you’re using a J1708 standard or a 1939 standard. When transit agencies started to add devices and components onboard their vehicles, drivers would have to log into each of these devices separately, and it became a very lengthy process, and if the driver made a mistake logging into one device, it would kind of force the logon to take place again and to take even more time than it was already taking for the driver to log on. So the idea is that if you had a computer-aided dispatch system, you’d have one device that you would use for the driver to log on, and the logon information would be sent to all the other devices so the driver would not have to log on separately to all of those. So this is something that is commonly used on most computer-aided dispatch systems. We do have single-point logon, and you can imagine what the benefits of this are, which we’re showing on the slide. The driver just logs on once. It reduces the potential for error. Also where you might have multiple devices with multiple GPS units within them, there you have one location that is used as well as one time and date stamp that’s used for all the systems that are collecting information. So it keeps all of that data synchronized. You don’t have to worry about synchronizing it separately.

Carol Schweiger: So in looking at an example-- I wanted to give you an example of a single-point logon, and this is actually a very, very current example because the Capital District Transportation Authority, which is the transit authority in Albany, New York, recently had a procurement to replace their old CAD/AVL system with a new one, and in their definition, their specifications, they wanted a single-point logon, and so they defined that there be a bidirectional interface between the fare box and their onboard computer with a single-point logon because they recently received new fare boxes and in the not too distant future they are going to have a new CAD/AVL system, which is called the Intelligent Transportation Management System. So this slide shows you what some of the parameters are that defines that single-point login between the fare box and the onboard computer.

Carol Schweiger: Let’s talk about another example, and this slide might look familiar. This was actually the same diagram that we used for our opening slide for the module, and this is an example from King County Metro, and this is their onboard architecture for connecting their new fare boxes to their vehicle logic unit or onboard computer using a mobile router. So this was part of a project that they called their Onboard Systems Project, where they were using a mobile router to help with communicating information among devices. And then the next two slides will show you the details of how this Ongoing Systems Project was actually being used.

Carol Schweiger: So this first slide talks about what was included in the Onboard Systems Project. So it was their smart bus or CAD/AVL system, which had a GPS device as well as a gyroscope, and their system also uses odometer readings. It had next stop announcements, or what we call an automated voice enunciator system. It also displayed that next stop information. It integrated with the destination signs on the outside of the vehicle. It had a passenger counting system, vehicle monitoring or vehicle component monitoring system, and that was what defined the onboard systems. So, again, you wouldn’t want a driver having to log into all of these various devices--

Carol Schweiger: So on this slide you see really the key thing of this project was to provide a single logon for the operators. So the operators would be able to log on once and the system would automatically determine the fare zones and various other requirements that had to do with the health of the vehicle and you could actually deploy those various systems that we showed on the prior slide in a phased implementation rather than deploying them all at once, and this single-point logon would be used.

Carol Schweiger: The third and final example is at the Washington Metropolitan Area Transit Authority. They went through a similar project to consolidate all of their onboard equipment so that they would have a single-point logon. So, as you can see on this diagram, their onboard computer is called the Intelligent Vehicle Network, or IVN, and it is connected to a mobile router similar to King County Metro, and then all of the various onboard devices are also connected to that, and so the single-point logon was being used because they were adding some systems to the vehicles, like new fare boxes, signal priority. They had a new yard management system. So again, they were doing a similar thing to what King County Metro did to make sure the driver only had to log in once and that all of the various devices would be logged in.

Carol Schweiger: So, now let’s give you a little quiz based on what we’ve talked about in this module.

Carol Schweiger: The question is: Which one of these differences between SAE J1939 and J1708 is not true? So the answer choices are: A, J1939 is much faster than J1708. Answer B, J1939 permits a connection of more devices than J1708. Answer C, J1939 is based on the controller area network. And D, J1939 covers the same number of OSI layers as J1708 does.

Carol Schweiger: So now let’s take a look at the answers. The correct is D. J1939 covers all seven layers of the OSI model, while J1708 only covers two of them, the physical and the data link layers. Answer A is incorrect because J1939 is much faster than J1708. It’s 250 thousand bits per second versus the 9600 bits per second for 1708. B is incorrect because it does indeed permit a connection of 30 devices versus 20 for J1708. And C is also incorrect because J1708 is not based on the controller area network; only J1939 is.

Carol Schweiger: So now we’re going to go through a series of case studies to give you an example of how the standards are actually used in procurement of the kinds of systems that we’re talking about, and we have several different examples for you.

Carol Schweiger: And we’re going to start with a smaller transit property in Connecticut, which is the Norwalk Transit District, and it is located in Norwalk, Connecticut, and they operate fixed route and paratransit services. Very recently, within the last year, they actually deployed a CAD/AVL system and in doing so, when they were planning the system, they knew that they wanted a vehicle area network that would connect their onboard computer with various devices that would be installed as part of the CAD/AVL system. It also included the fare box as well. So here you can see the list of devices that were going to be added to the Norwalk Transit District buses, and they required a single-point logon. So that was part of their specification. And just to give you an idea of the size of the property, they operate approximately 63 fixed route vehicles and about-- the paratransit service is operated with 54 vehicles. So that gives you an idea of the size. So single-point logon was a key component of their system.

Carol Schweiger: I want to show you in a fairly detailed diagram here what the CAD/AVL system really looks like from a sort of dispatch center or central system perspective. And if you look right in the center of the diagram you see all of the various servers and components at the dispatch center that are actually operating. And so you have a database server, you have the CAD/AVL server, you have a passenger counting server, etcetera, scheduling server, and the various colors on the diagram-- the orange boxes indicate where Norwalk Transit had an existing system. The purple boxes indicate the core systems that were being required in their procurement of a CAD/AVL system, and the red boxes indicate systems that might be added in the future. So the vehicle component monitoring, they might add that in the future. They might add yard management. This gives you an overall picture of that.

Carol Schweiger: And then I wanted to give you an idea of the onboard systems, which is really where the single-point login comes in, and again, the orange, purple and red colors mean the same thing, and you can see that the central point of this diagram is the mobile data terminal or onboard computer. So this is where the logon would take place, and then because it is connected to the other devices that require a login, the login information is sent to those other devices. These two diagrams are also included in your Student Supplement so you can see them a little bit larger.

Carol Schweiger: So, we mentioned this already. These were the devices that were being procured by Norwalk Transit. And so in the actual specifications, the vehicle area network was defined, was required.

Carol Schweiger: Let’s move to an example that I already sort of started with here, and that’s the Capital District-- the Albany, New York, Transit Authority, which has just started to embark on replacing their old CAD/AVL system. I had mentioned before they require a single-point logon, and they are requiring a J1708/1587 network to connect their onboard computer with pretty much the same devices and components as are being used in Norwalk. The only difference is they were be utilizing new radios, which are the P25 radios. You can see on the right-hand column of sub-bullets that that will be something new. And then the support, supporting the data transfer to their central database is also included in Albany’s specification.

Carol Schweiger: The other thing that I wanted to mention, because it is a term that comes up fairly frequently, is the use of what’s called an interface control document. The purpose of an interface control document is really to document and to monitor information that’s required to define an interface between one system or one component and another. It’s also used to describe any of the rules for communicating the data between those systems. So it’s a very, very important document and vendors typically write these documents so that they can be used to build those actual interfaces. So the example I wanted to give you was the system in Albany, CDTA, required as part of their procurement an interface control document that integrates their new fare boxes with their new CAD/AVL system. So it’s not only a single-point logon, but it’s also sharing the synchronized GPS data that’s being used by not only the fare box but all of the other systems onboard. So the vendor must produce this interface control document.

Carol Schweiger: And so what is contained in that interface control document is a number of sections, which you see here in the bullets. So what’s the purpose of the interface control document? You need to describe the physical interface between the components. In this case, for the Albany system, they wanted a definition of the J1587 protocol. So you would actually show, like the diagram that I showed you of what a 1587 message looks like, that it has a message ID, parameter ID, and the actual protocol itself-- that must be contained in the interface control document. And then the other part of the document is how the driver will log in and any of the other systems that are involved in that, like when the vehicle is powered up, what happens; what happens to the onboard computer if the power is interrupted, there’s a power failure onboard the vehicle, or some systems have to be rebooted. That kind of information.

Carol Schweiger: And then continuing on-- I’m not going to read all of these to you-- but that interface control document speaks to if the driver logs on the mobile data terminal, how does it get transferred to the fare box, or if the driver logs onto the fare box, how does that information get transmitted to the mobile data computer, etcetera. So that shows you what is contained in the interface control document.

Carol Schweiger: The other thing that I wanted to mention for this particular example in Albany is in their specification they talk pretty extensively about testing requirements, and they actually go beyond the typical testing phases that we see in a CAD/AVL system, and they’ve added two additional testing phases. One is called a factory integration test, and part of the reason for this testing is when you’re using a single-point logon you want to make sure that all the devices can actually be integrated and the data can be communicated between two devices or among devices. So they added that step after the factory acceptance test. And the other step that they added is something called the onsite system integration test, which they’re using after devices have been installed but before they go to their pilot test, which is typically a certain number of vehicles that have been installed with the components; you’re going to be trying to run in a test mode and then potentially run them in revenue service. So CDTA went one step further in making sure that the use of these standards would produce what they wanted, specifically with the single-point logon.

Carol Schweiger: Our last example is in Ann Arbor, Michigan. The transit authority there also within the last year just deployed a new CAD/AVL system as well, and they required a vehicle area network to have all of these components speak to each other, and you can see fare box, the head sign, and you can read the other components.

Carol Schweiger: And then their onboard systems, as you can see in this diagram, are similar to what we saw in the Norwalk case, but, again, the colors are similar and where the single-point logon would happen would be that purple box in the middle that says MDT, mobile data terminal, and all of the other devices are connected to the network so they can receive the login information from that onboard computer.

Carol Schweiger: Let’s see. Are there other pieces of information? I think I’ve discussed all of the various information that would be integrated in Ann Arbor on that one slide.

Carol Schweiger: So let’s start wrapping up, and we’ll wrap up this third learning objective with a quiz question here.

Carol Schweiger: And what we’re asking is: What is an interface control document? We talked about the Albany system requiring that that document be developed. Your answer choices are, A, it documents and tracks necessary information to define systems’ interface; B, it communicates inputs and outputs for all potential actions whether they’re internal to the system or transparent. Item C, it helps ensure compatibility between system segments and components; and item D, all of the above. So let’s look at the actual correct answer.

Carol Schweiger: The correct answer is D. All of those answers are correct. So item A, yes, it documents and monitors necessary information to define system interfaces. It communicates the inputs and outputs, and it helps ensure compatibility between components.

Carol Schweiger: So, we have just a couple of slides to wrap up here, and it’s kind of hard to summarize a lot of this very, very detailed information, but here’s an overall sort of 40-thousand-foot summary that we have, which says: What have we really learned? We’ve reviewed what the standards look like and why they’re used. We’ve identified the contents, the 1587 and 1708 standards that are used together, and the 1939 standard. We talked a little bit about the 802.11x standards, and we gave you some examples of single-point logon. We gave you some case studies of where the standards are defined within the procurement documents, and identified what is included in specifications, and you have additional information with item four in your Student Supplement, so I would urge you to take a close look at that. There’s actually some language from specifications in there, so you get an idea of what’s actually being written.

Carol Schweiger: And I wanted to give you just a little more food for thought about what did we really learn from this, and some of it is really implicit and some of it was explicit, but first-- and I think one of the more important discussions about standards-- is the fact that you want to use data exchange standards to really allow you to purchase components from different vendors. You don’t want to be forced to go back to the same vendor if there are similar products on the market that might be less expensive but might have the same functionality. If you don’t use standards, it’s very hard for you to actually do that. We talked extensively about the fact that J1708 really does not incorporate all of the OSI model and it needs to have J1587, which actually moves the data around. So those two are used together. This is something that I didn’t spend a lot of time on, but how you actually select a standard-- and it’s really based on the standards maturity, are vendors actually using that standard in the field, is it available to everyone, and is it really applicable to my situation. So that’s really what you want to be looking at when you’re selecting a standard. We talked a little bit about J1708 is outdated. It’s also a much slower network, so you may want to consider migrating to a J1939 network.

Carol Schweiger: And just several more lessons learned here before we wrap up. So, it really has been shown that agencies have experienced cost savings through using standards, and the best example is the CARTA example, where they actually saved two engines on buses by knowing about their health before something catastrophic happened, and engines are very expensive components, so that was something very important to them. Also, where you may be replacing components onboard a vehicle, the use of standards really makes that much easier as well, where you’re really going to be sort of unplugging one component and plugging another one in. An interface control document is very, very important to actually document the interface between two components or systems, and typically vendors write these documents so their systems may work with other vendors’ systems as well, and you can require that, as Albany did, in their specifications. And then really, if you want a single-point login, you’re really going to have to utilize one of the standards that we talked about in order to do that.

Carol Schweiger: So that wraps up Module 19. I would urge you to go to the Student Supplement to get a little more information about some of the aspects of the standards that we talked about, and also using the feedback link, because we really want to know whether there is anything in this module that you feel should be changed or anything that was exceptionally good. We’d really like to get the feedback. Thanks very much for taking Module 19.