 Thank you very much for the kind of introduction. So once again, I'm Anthony. I work for the Connected Corridors Project, and we're trying to build a decision support system to help transportation agencies to respond to traffic congestion caused by incidents. I'm going to explain a little bit about what that means, and then I'm going to turn it over to Brian, and he's going to talk about the systems engineering required to actually build a decision support system. So our subject area is the I-210 corridor in Southern California. This is one of the busiest corridors in Southern California, and it's also a very exciting corridor. There's an incident almost every day, and about once or twice a year, there's a substantial incident that blocks the freeway, you know, the entire freeway. Here's one from maybe two years ago. I have some pictures of it. What was really interesting about this incident is that a big rig ended up in the middle of the median and just blocked the gold line, which is kind of a metro rail that runs through there for an entire day, and that was kind of a mess. I have a couple more pictures here. Very bad day for commuters, very good day for traffic scientists. This was interesting that there are people trying to use the on-ramp as an off-ramp, and if you saw the blog post, something similar to this happened just last month. Okay, so we imagine a future where these different cities, county, state, department of transportation, other stakeholders can work together to respond to an incident in a holistic and organized way, and part of this might involve warning folks about what's going on. It might also involve changing your ramp metering and changing the signal plans that you have on your arterial so you can quickly flush out the queues and maybe get people back on the freeway and on to where they're trying to go. And so I imagine the system looks something like this. Brian's gonna show you some different pictures, but in this picture, I imagine from the bottom, you bring in all kinds of data. You estimate your traffic state, so that's a yellow box, I don't know if you can read it, but you estimate your current conditions as best as you can. Hopefully you've studied the corridor, you know something about demand, and then you have a model to predict what might happen if you reroute this way, reroute some other way, or if you do nothing. And maybe a human in a loop selects a response and deploys it. So I'm just gonna talk a little bit about some of the ingredients that go into this. One is we're building a model, we're building a model of this entire corridor that includes the freeway, arterials, and transit. It has about 450 intersections and contains about 1,000 lane miles of roadway in glorious detail. We use this to simulate the effect of incidents and try to put together the elements of the response plans that will be needed to address these. I talked a little bit about estimation. What I mean is on the left there, I have a picture of, it's a time-space diagram, which is basically showing space on the vertical axis time on the horizontal. Black is where you have no data, and what you would like to do, and green and red is faster, slow, and you would like to fill in the gaps so that when you kick off your model, you're starting it with the current state of your transportation network. So we have algorithms to do that on the freeway. We have other algorithms for taking in data on arterials, whether they're stop bar detectors or advanced detectors, and estimating the cues, the average cues. And then I talked a little bit about demand. Demand means developing a table that defines the trips that people make within a network or between zones in a network. And we're in this process now where we're figuring out how many matrices do we need, how many days, what periods of the day, what types of vehicles, what really needs to go into this to be able to perform accurate simulations. Okay, this is my last slide. We have a lot of research themes, have a lot to do with data, estimation and probe data and machine learning. But we also, on the bottom there, part of it involves studying people's behavior. How do people select their routes? How might they respond to guidance or incentives? With that, I'm gonna turn it over to Brian who's gonna talk about some of the details of how we're trying to build this thing. Thank you, Anthony. So I say Anthony's a science part of this which I know very little about. I'm not a traffic engineer. I'm a systems developer so I'll talk a little bit about the systems development but I'm also gonna talk about Anthony described a lot of different data that's coming in here and I know that's of interest to the people who are here at BID. So I'm gonna talk a little bit about the data itself as well. So this is a diagram put together years ago by my boss. It's still quite interesting. For this group here, that outer green bar is a set of data that we're going to be collecting. So if you just work your way around it, there are travel time sensors. A lot of those are like Bluetooth. So they'll pick up the different Bluetooth MAC addresses and they'll see where individual elements are and then try to estimate travel times for those. There are sensors on board vehicles or sitting in your pocket. So there are providers of information that will give us cell phone data or GPS data from GPS units. There are the ramp meters themselves providing the flow of traffic through the ramps as well as what the ramp meters are actually scheduled to meter at. There are the traffic signals and I make sure the traffic signals aren't just the state of the signal itself there's also how much traffic's flowing through there and how large the queues are getting. We plan on getting information from parking lots. So the park and ride lots, how many commuters are essentially carpooling, there's some sense of that, but also where is parking available if you want to reroute people onto transit and change the mode, you have to know is there parking available for those travelers. So we're hoping to get parking data, transit data, that's key, the message signs, what those are currently saying and how you get information out. The different information providers, 511, those sorts of services will be in contact with those. Different communication devices, the highway activity radios, those sorts of things. And the traffic detectors, not only the arterial, but also the freeway sensing is there as well. So there's a lot of data that's gonna get collected and brought into the system. So this is another little more detailed drawing of the same sort of thing. So the interesting thing here is a lot of that data, if you look at intersection signals and you look at the blue, those are all entities that are sending as intersection data. So a lot of that data, it's not standardized in a perfect sense. So there's a lot of transformations that'll be going on in the system to clean it up. There's also a lot of data quality checks because with that many systems, you often get a lot of chunk. So you have to go through and clean all that up. You can see the green, there are several different transit agencies, different modes of transit you'll be taking a look at. So you'll have that sort of information. You can see in the red, the different law enforcement agencies where you get your incident information. There are the information providers for radio and weather and that sort of thing. And the other data suppliers are those sorts of folks, a lot of them that are giving us the probe vehicle data, the cell phone data, that sort of thing. So that's position and velocity and time for where they're seeing. And it's all anonymized, okay. So how do you process all that different sets of information? This is what we're building, okay? So the green is still all the different entities that are providing us information and are consuming the information we're creating, okay? The red is what we're calling our data hub. So in there is where we bring in all this different data, depending on how they want to send it to us, different modes of getting that information. We essentially are gonna take all the information, put it on one big central data bus. It's a messaging bus or a rest service bus, one of the two. And we'll just hook up processes onto those buses that'll essentially do the processing for us, all right? So anyone can pick up onto any one of those streams they want where they want the raw, the processed data, pick that off and use it as they need to. You can see Anthony mentioned the models and doing the estimation and the prediction, those are in that big blue box. So that's where the modeling is running and what it's doing is it's just gonna pick up all those data streams off those messaging buses and do the work it's supposed to do. Which means you have to update the models for the intersection signals that are in the models, the ramp meters, all that sort of control information has to go to the models, but also for the estimation, you have to give it all the sensing. So it knows, it can give you an estimate about the traffic as you fill in all those holes. That purple box is essentially a commercial traffic management system. That's an off the shelf sort of box that'll actually, I mean, we don't want to write software that's sending the signals out to different field elements, you can buy that. So that will be listening to that stream of information and that also will be listening to the stream of information from that decision support system on the predictions and the response plans it generates so that it can go ahead and execute those response plans for us. You can also see down at the bottom, their PEMS is the state system for freeway sensing. They're also looking to put a lot of this data in essentially as a large EDW and business intelligence type of system for longer term analysis. The other thing I'll point out here is there are three boundaries I've put in there. The idea is this is a pilot, but that pilot is done for a purpose to put it on other corridors. So the way we're seeing it right now is you see the inner boundary is the corridor system boundary, that's a local boundary. That's sort of like the 210 freeway that we're doing. There'll be one of those for every corridor. The regional system boundary is more of a regional area that's gonna handle multiple corridors. So that data hub is more of a multiple corridor idea after we get past the prototype stage. And then the state system boundary is where you're starting to essentially aggregate all that data at a state level and let people look at the big picture. So that data hub essentially what we're doing is categorizing into three different types of pipelines. There's a streaming or a sensing pipeline for that's the stuff that's coming in hot and heavy. Lots of volume of data has to be handled in real time. That's the sensing information and the probe data, that sort of thing. What we call heterogeneous data sources, those are the intersection signals. If you remember, there are multiple jurisdictions sending as intersection signals, not all exactly the same. They have a common standard format, but their implementation may be a little different. So we have a stream to handle those. And homogenous data sources, Caltrans only has, I mean they handle all the ramp meters, so they're all gonna look the same. I don't need quite as much transformation. So we're breaking the data into three different types. And I'll show you what the streaming looks like. This is one that may have some interest in that this is where sort of a lot of the machine learning and that sort of stuff will happen. Okay, so you can see freeway sensing, the GPS data, arterial sensing. That's the type of information that will go in here. We'll essentially write a stream reader for each one of the data sources that we get. And then each one of those stream readers, our only job is to stick that onto a real time queue system. We're using Kafka. So it'll put it on the Kafka topic and then we're gonna put Spark at the end of that. And Spark is where all the transformations occurs and the standardization, that's where all the data quality checks will go. That's also where if we get to the demand prediction and those sorts of things, that's where those algorithms will live to run the demand predictions, the route selection predictions, those sorts of things. And then the only thing that that does is it goes ahead and tips that information back onto a set of Kafka topics for all the downstream system for decision support and that purple box, the quarter control box to actually go ahead and act on that information. So at no time do we really persist the information. This is a real time production stream for large volumes of traffic data. That's what we're building. Any persistence is essentially pulled off those same topics and then we persist on the side. And then we can replay it if someone wants by just taking it and putting it back on a topic. That little bit of Postgres there, we use that. So if Spark needed some of the information like road network configuration, if we're doing flow balancing of traffic between say three points, two inputs and an output, we'll need the road network information so that's available to our Spark processing engine as well. So some of the opportunities is starts to open up for people who are interested in data. Looking at traffic and travel and mobility impacts and control and how these things interact over a large urban area. This is a unique data set, I think. There are a few places that have one similar to this. San Diego has done some of this sort of thing. But I think this is gonna be the most comprehensive probably around. You can start to, once you have this data, start to look at how, as transportation is evolving, how is the data changing and what does that growth of data you're going to get? You're gonna start to look at connected vehicles, vehicle to infrastructure communications, the autonomous vehicles, all that data starts to become available and this becomes a platform for that sort of data. Looking at human decision making, Anthony mentioned what routes do people take? You can also look at when they choose to travel, what mode choices they make under different situations. The impacts of different incentives that you give people to travel can now be looked at at this sort of scale. You can do the predictive studies we mentioned. The idea is to put the platform in place to allow this sort of thing to happen. This is going to be a production system. So everything goes through here. All that data is gonna go through. So there's a lot of challenges of how much the scale that we have to put in place and the real time of this much information. And really, we're actually looking for people right now that'll help, who want to help build this platform and eventually start to look at the data. So it's an opportunity to get a whole lot of nuts and bolts experience of how do you put something in a production scale, running real time analytics on what is potentially a lot of data and a lot of interaction between a lot of different types of data. So that's my last slide. So I don't know, I've never been to one of these. I don't know if you wanna open it up for questions or where do we go from here? Okay. And I'll direct.