T3 Webinar Question and Answer Transcript

Kingsley Azubike: Well, now this is a question that either myself, Susan, or even a member of the panel can answer. Let me start off by saying that this is a great question. The way I'm looking at this, it's not a matter of whether you have a single architecture, or multiple architecture. The emphasis should be if you had a single architecture, you know, did you identify all the—comparatively—identify all the stakeholders? I think that is one of the first things you need to be sure of. You know, that you have identified all your stakeholders that need to be in that single statewide architecture. That is, to me, a prerequisite, because at the institutional level, you need to know all the people that would be affected by that architecture. And make sure they have, you coordinate with them, and they have input into the architecture. And that would now allow you to identify the rest of the elements—the layout, the communication, and the transportation layout of your architecture. So, and if you chose to have a multiple architecture, that's fine. But again, it boils down to the same thing. You know you need to make sure that you identify all the stakeholders, whatever stakeholders, for those multiple architectures. Again, you should think about championing. Who are the champions of the architecture? Who is going to be maintaining it? You know, how is it going to be updated, and all of that? Doing that is more important to me than whether they have a single statewide or have multiple architectures. So I'll let Susan and any other person that wants to chime in here, you know, try answering this question.

Susan S. Walker: I think you're exactly right, Kingsley. I mean, it basically comes down to a question of architecture maintenance. And whether, you know, one huge, well, I guess maintenance and use. Whether one huge architecture can be used effectively and maintained. I mean, if it's not a complicated state, or if there are ways to reflect the ITS in that state concisely, then there is no harm in having one architecture that covers an entire state. And I actually think there is at least one state that has done that. I think Minnesota is the case, and possibly others. And Minnesota has a great statewide architecture that covers the entire state, including the MPO areas. But typically, it's not done, just because it's harder to get all the information and to allow access to all the people who need it. But then you're talking about multiple architectures and it becomes harder on the maintenance side, and keeping those architectures consistent and up-to-date.

Kingsley Azubike: But yeah, like as Susan said, you know, we saw examples of that in terms of you need to maintain. We saw Form 2560, for example, that MDOT uses to continue to maintain their architecture. So it's about how we can manage it.

Kingsley Azubike: Again, this is a question that the architecture team can address. And as a matter of fact, any of our other panelists or presenters can chime if this is something that they have thought about in the past. But let me, again, start by saying that it's a great question. And especially where you have a bigger major region that encompasses many states, it becomes very valuable that they know what each other will be doing. But as far as having a discussion at a national level, since I took over this position, we have not talked about this informally, but we do have websites that do reference links to several regions—several regional and state architectures. But yes, it would be a good idea to have them in one—on one platform—which I don't think we have at the moment. But we do have links, you know, from some of our national websites that you can follow to access some regional and state architectures? Susan, any thoughts on this?

Susan S. Walker: It is a great idea. I personally haven't been involved in any of the discussions on such a thing, but it is a good idea, and something that maybe, you know, we should think about. You know, of course, Turbo Architecture, the tool that is typically used to create regional architectures, was set up and has features in it that allow you to integrate architectures. So you can have two levels within a database. And if there's three levels or more, then you can actually import and export between files, between databases. So the tool was set up with that, but it's not an online tool, of course.

Kingsley Azubike: Great. Okay, I hope that addresses that question. But if not, you know, again, you can contact me, and I'll get you additional answer for that if you are not satisfied.

Kingsley Azubike: Again, this is a great question. The only thing I was wondering, on the part when you say—“Do you have a mechanism for addressing maintenance?”—whether you're referring to addressing funding allocation for maintenance at the planning level, or were you referring to the operations maintenance requirements? If you're referring to the latter, I would say that if you used, or if you have been using systems engineering process, or some aspect of systems engineering in your project implementation, that is part of the things you need to be addressing, you know, your maintenance requirements, when you're looking at your system, you know, at the con-ops and also at the design requirements level. You need to be able to address that, you know, how you plan to maintain your devices. And that's one of the reasons why we encourage you to use this systems engineering tool.

Charles Remkes: Yeah, this is Charles Remkes with the DOT in New Mexico. And I'd like to just add a couple of comments to that. It is a challenge for us, even though we do work with the systems engineering. It's just having one level of capacity that exists both internally within the department, or within the private sector. And within the department, the issue more than anything else is attrition, turnaround, and being able to fill positions effectively. The other issue associated with that is the capabilities of some of the contractors as it relates to very specific level of ITS functions. We've tried to go out, for example, on some of the systems design work to some areas that have outside expertise. But the biggest problem that we're having with our maintenance related to our devices has to deal with copper theft. And it's constantly—within the last week, we've had over seven incidents of copper theft, and we're now retrofitting or replacing them with aluminum wiring at a higher gauge.

Elise Kapphahn: And this is Elise from the Michigan Department of Transportation. We recently had kind of a reflection internally about how do we best quantify the maintenance required of our ITS devices, because our system has grown quite significantly over the past few years. And what we did is that our ITS five-year planning meeting that we do annually—we determined—we sat down and calculated how much we expected this to affect both the device maintenance as far as cost goes, the operations, because we have three transportation operation centers, so how much would it affect that? Do we need a new employee to come in and work there? And then another thing that we found that was very important was how much were these new projects going to be taxing our internal IT department. We outsource our maintenance of all of our ITS devices through a single contractor, and that's worked wonderfully. But really, where we've found it to be lacking is our internal IT allocation. So, something also to keep in the back of your mind.

Kingsley Azubike: That's great. The other thing that I wanted to add here is that in some states, like Pennsylvania, one of the things they have done to address maintenance is have a streamlined approach, whereby they, maintenance requirements are elevated to the state level, whereby they have maybe certified single contractors that maintain all the ITS devices within the state. Because you have different districts that used to do their own things, and some of these things became overwhelming for individual districts, so they decided to streamline their approach, and bring it up to a way of maintaining a lot of the devices within the ITS—devices within the state. So, I think if they can come up with some creative way of trying to, a way to handle the maintenance requirements. Does anyone else have anything to chime in on this? Their experience, individual experiences, about maintenance? Okay. Well, let's move on to the next question then.

Kingsley Azubike: Okay, the way I understand that question is whether the CVRIA will be integrated into the regional ITS architecture. And I think the answer is yes, ultimately. And Susan, you can chime in on this based on your understanding. But yes, the CVRIA that is being evolved—that's evolving right now—the idea is for it to become a part of the National ITS Architecture, which eventually will trickle down to the Regional ITS Architecture. So yes, the quick answer to that is, yes, that is the goal. Susan?

Susan S. Walker: Yeah, that's absolutely correct. Unfortunately, it's not going to be a quick process. So there is CVRIA, which is the Connected Vehicle Regional ITS Architecture. And so that will be used until it is merged into the National ITS Architecture.

Charles Remkes: This is Charles Remkes with New Mexico. It kind of depends upon the complexity. Whenever we were updating then from the 2000 AMPA architecture to the 2007, it was in the six-digit figures. Whenever the smaller MPOs was a little bit less, probably around the 50 to 60 range.

Elise Kapphahn: And this is Elise from MDOT. We addressed seven of our regional architectures with an administrative update this past year, and it cost less than $100,000. However, keep in mind this was an administrative update, so it was more just addressing the changes and modifications to the architecture that have been identified since our previous update. So it wasn't doing a full-blown architectural update. This was more of just an interim update.

Nathan Masek: Well, this is Nathan from MRCOG in Albuquerque, New Mexico. Well, what we have is our ITS Subcommittee is essentially on-call for maintaining the architecture. So if we have project level architectures that need to be accommodated for whatever reason, we can handle that and make appropriate changes to either the addendum or the baseline architecture as appropriate.

Kingsley Azubike: Anyone else on this? Okay, it looks like—hopefully—that addresses your question, Chris. Do we have anything else coming up? Okay, thank you. Looks like we don't have any more questions on the chat pod at this time.

Kingsley Azubike: Yes. I just want to thank all of the participants again, and like I said, let this be a beginning for you to follow up. And you can always go back to the T3 Archives to get additional, like the slides, and let that, like I said before, provoke some thoughts in you if you need it, to get additional resources from us. And we're here to help. So thank you all for participating. Over to you, Volpe.

Volpe: Thank you, Kingsley. And as a reminder, typically we have the entire presentation up within about three weeks of the presentation, so we just remind you to slide on over to www.pcb.its.dot.gov and you can find all the other T3 Archives there. Just also as a reminder to you, as you exit the webinar today, you'll get a feedback form emailed to you. Please take a few minutes to fill out the feedback form. It's how we know how well we're doing. But also how we understand, what we understand you want from us in the future. Don't forget to join us tomorrow for our next webinar. And with that, I want to just list a couple of resources, give you a chance to contact us if you need to. You can reach out to us at T3@dot.gov with any question. We mentioned the web address, and just a fun reminder for you to check out the CITE Consortium, because they have a ton of information as well. Finally, thank everybody for joining us today, and a reminder to the panelists to stay on the line as we will be moved into a private room. Thank you everybody! And have a wonderful afternoon, or good morning, depending on your time zone.