Presentation: St. Lawrence Seaway’s journey into PI System with advanced analytics for vessel ETA forecasting at bridges and locks

2024 - AVEVA World - Paris - Infrastructure (Water, Facilities, Transport, Marine, DC)

St. Lawrence Seaway’s journey into PI System with advanced analytics for vessel ETA forecasting at bridges and locks

And, just a quick intro. So my name is Rami Duquette. I'm the vice president of our industrial AI at my HCT. We were the, system integrator on the PI side, with Jamie. So, Jamie. So my name is, Jamie Andrews. I've, the information, systems manager at the Saint Lawrence Seaway. I was responsible for bringing the PI System into the Seaway. As you can see, I've been working with the PI System since the year two thousand, so quite a while. And yesterday, we heard some interesting stories, at dinner. So if, if you if if you want some pie, you know, interesting stories, ask Jamie later. So, you know, very quickly, I'll introduce the agenda, and then Jamie will walk you through the presentation on the Saint Lawrence Seaway. Throughout the the, the presentation, you'll see some of these little videos that show segments of the Saint Lawrence Seaway. If if you don't know about that body of water, it it is really outstanding and and amazing, when you go through that journey on how how they move those ships across and move these, ships upwards. Jamie will will go through that. But we'll just introduce the Seaway, with Jamie, a little bit of of the history there, what their focus is on, what the project was on the forecasting, and the ETA for the the bridge conditions and and the lock conditions. So this is where, we did a lot of good work together jointly with, the Saint Lawrence Seaway. So up to you. So up in the screen, you see a, a map of, of our region. So this is the Great Lakes Seaway system. It's really a thirty seven hundred kilometer marine highway that goes from the Atlantic Ocean up into the Great Lakes. We specifically, operate, thirteen locks that, eight of them are in the Welland Canal and five of them are in the Montreal to, Lake Ontario region. We also operate fifteen bridges, eight of them in the Welland Canal and seven of them in the, Montreal to, to Lake Ontario region. So a side profile of what it looks like to go through the Seaway. So the Seaway was, initiated in nineteen fifteen, nineteen fifty four. It was completed in nineteen fifty nine. So it's about sixty five years old, and it's considered to be one of the, engineering marvels of the twentieth century. So and you can see from the the picture there just how far, vessel that's coming in from the ocean moves up to get into the inner Great Lakes. So there was a recent, study that was completed, that showed that the there's about two hundred, million tons of cargo that, transits the Seaway, every year. It's about sixty six billion, Canadian dollars in economic activity, and it supports three hundred and fifty seven jobs within the, the Seaway, domain. And, as you heard earlier, shipping is, is one of the is shipping gives you the, the lowest or the smallest carbon footprint, has the best fuel efficiency. And just to put it in perspective, the seawaste sized vessels, replace about three hundred railcars or about a thousand, transport trucks. And just a quick note there, if earlier you missed the presentation from, Jean Frederic from CSL, Please go and and vote for them on the sustainability. This is, you know, they go one notch above, on the sustainability side. But, when I I told my daughter I was presenting with Jamie in the Saint Louis Zoo, and I showed her the slide to kind of give her a little bit of a a history lesson and, you know, why, marine transport is so amazing. She was super excited to see the, you know, the amount of of rare cars that, you know, or or trucks that are essentially being equivalent for a in savings for for for shipping. And now she has a new, you know, found appreciation for the marine sector and and how amazing, you know, these ships are. So votes for CSL for this sustainability award. So what I put up here, is our mission statement and our commitment to communities. And really, what I wanna point out in these two, paragraphs is, you know, our, social responsibility and our commitment to the, communities in terms of open communication. Why that's important is, you know, historically speaking, when we first, start offering, we were called the Seaweed Authority. It was a government organization, and the ships really have the right way on the on the waterway. So anytime you have a bridge, the traffic will be stopped, the bridge raises so that the vessels can pass, unimpeded through the waterway. And this was done with no regard for, you know, the communities, the traffic, and things like that. When we commercialized in nineteen ninety eight, we started, taking on, you know, really putting forward our external relations, started, reaching out to the communities and our partners. So we really kinda turn that around. And so now, you know, we're we're having open communications. We created this bridge information system, which is what we're gonna be, going into more detail. And but one of the things that was driving that is the growth around the seaway infrastructure significantly increased, especially in the last ten years. A lot more traffic is crossing those bridges. There's more delays, and so we really wanna kinda give people the idea of, well, which road should I take? And it really applies to emergency vehicles as well. That was, why we started this in the first place. So a bit of history on, our bridge information systems. So the first application was created back in two thousand seven. It was created for our well in canal, only. It was done in visual basic, which was, you know, still popular at that time. It, we really looked at what we call the standard transit time, which is, you know, to go from point a to point b. It should take this long. So that's what we based our, our predictions on. And, so over the next few years, we, we started to, we added the Montreal region bridges, and we started making some minor tweaks. In two thousand thirteen, mostly due to, you know, our our numbers not being that accurate, we started making some minor improvements. We, we shrunk the forecast down because we we originally were forecasting eight hours. And, you know, beyond an hour, we were completely, missing the mark. So we really brought it down to an hour and later on in, in in twenty between twenty thirteen and eighteen in the Welland Canal, we even brought it down further to, to fifteen minutes because we realized that, with the complexity that's in the Welland Canal, the structures that are really close to each other, it was really impossible for us to, you know, go beyond fifteen minutes in that area. So so again, in twenty eighteen to twenty twenty one, we underwent some major, changes to the application, change in look and feel, providing more information. One of the things we weren't capturing was maintenance. Somebody would go and do maintenance. They would shut the bridge down. Well, people, you know, we're saying the bridge is available, but we shut it down for maintenance. So we had to make some changes to the application there. On the bottom, you'll see in twenty twenty is, the at the end of twenty twenty is when we installed our our first PI system. That's when we got it up and running. At that point, we didn't have any view on using it for the bridge information system. In twenty twenty one, we had a major escalation in our Montreal region. It kinda caught us off guard because up until that point, all of our issues were always around the Welland Canal, trying to get the accuracy around Welland Canal. So for us, this kinda came at us, with a bit of surprise. It was, like I said, a major escalation. There was a new found push on improving the accuracy. And so we created a new algorithm in twenty twenty one between twenty twenty one, twenty two. What that set us up for was we ended up having multiple algorithms all doing different bridges. So some were still using standard transit time, some were looking at velocity. And all in all, we had four algorithms all going to, you know, different outputs, different inputs. It was kind of a mess, but it was, you know, we had to get something quick. And that's when we, reached out to Maya in twenty twenty two to come in and help us and say, look, we need some help with this. Can you look at, you know, what we're doing? This is what we're thinking. And, so they performed, initially, a gap analysis. And, from there, we, we started on the journey of standardizing that whole back end, instead of using because all these algorithms were using hard, you know, application software, code that was hard coded. We brought it all into the PI System. We created the all the algorithms as templates, and which now allows us to be able to replicate, if something's working for one bridge, we can replicate it if we we have the same. And it makes it easier for us to update the model. And so that solution, we are started rolling it out this year. We're still in the process of rolling it out, but, at this point, we now have, full PI integration. And one one quick note on the, my HTT side as a system integrator. So initially, we perform, you know, a gap analysis for understanding, you know, all the back end components and the inputs and outputs that were needed, for, you know, enhancing the the the the the forecasting, but also making it future proof. Right? We know that they they had, very good goals short term, but they had bigger goals for long term. So we wanted to make sure that the infrastructure that we would put in place on the back end would serve them for the long journey of getting to and enhancing over time their their forecasting capability. So, Maya, you know, twelve plus years of of experience with as a PI System integrator, we're at over six million, tags deployed on the PI side with various clients, a hundred and fifty, projects total roughly over the last fifteen years. So, yeah, if, if you have any, PI System integration or machine learning forecasting work that you'd like done after the presentation, come come see me, and you'll have, you know, Fred on CSL and and, in the same on CSA with Jamie, good people to discuss and see how they interacted with with us. So a quick view of, the PI System at the Seaway. So we migrated from, I Historian prophecy in the summer of twenty twenty. The old system we had was, you know, we had two separate systems in each region. They weren't talking to each other. They weren't really kept up, like, nobody was really using it. So what we did is we installed a hundred thousand tag, high availability, corporate wide Aviva PI system. Ninety percent of those tags are being used. We have unlimited connectors, to connect to different SCADA systems, to our AIS signal, to your RDBMS. We also have, fifty PI vision licenses, thirty data link licenses, and and growing. From PI data access, we're using PI SQL as well as the asset framework SDK and the OPC. So and I would say our pie culture is on the rise. It wasn't, easy at the start to, to convince our automation people, but, I would say in the last year with the, work of the bridge of the emission system and some of the other things that we're doing, the pie culture is, definitely on the rise of the seaweed. And as you can see on that little video, right, it's, it's really awesome to see. Of course, it's fast tracked. They don't go that fast. But it's it's an interesting journey there. Maybe just a word on what we've accomplished, with the last two years, with Jamie's team, on on the pie side. So really, the focus was on enhancing the the the bridge condition ETA. So the, you know, estimated time of arrival and and change of those conditions. And what we've accomplished over a two year period is about twenty percent, on especially the the specific bridges that we were targeting initially, to prove out, you know, the back end, the new concept, and everything. But you'll see there's a lot more room now to improvement for the other bridges that we are, hopefully, gonna tackle moving forward. But that's that's really what the, the the future proofing was about. And then even with the future proofing and all the back end work that we needed to to do, twenty percent is, I think, a significant. So now we'll tell you how we got to a twenty percent, improvement there on the forecasting. Quick slide on the the design strategy. So as we went through the the gap analysis and look at all the different, AIS based bridge condition where you you do have the AIS information that coming in, you can then, you know, pipe that information into the PI system and then leverage those for for better ETA and messaging calculated all in in the PI system. So there was no reason to have multiple other database, and you'll see the original architecture where we start from, and Jamie will will comment on that, and how we move to, you know, centralizing the SCADA information and the AIIS information and and, you know, other information in a central, position to do the forecasting directly, attached to the PI system. Jamie? So a quick look at our initial architecture that's on the you're right. You you could really see that it was a bit of a spaghetti factory. We had multiple, you know, applications calculating, going to multiple, outputs. And sometimes these outputs conflicted with each other. So somebody would be looking at an app on the phone, and it would say fifteen minutes, and then on the radio, it was saying it was gonna be five minutes. And so we really it was a bit of a mess. So over on the, on the right side, we have our new infrastructure where everything, you know, whether it's a database, the s signal, the SCADA system, it all comes into pi, and it all the outputs go or come from pi. And maybe just a a comment. You know, if if you recognize yourself on the left side, right, it's it's always a journey to get to the right side. With Jamie's help, we were able to to do that within the, you know, two year periods. So step by step, you know, one one component at a time being brought back in in a systematic fashion. But that was a very interesting puzzle to move and make sure that these, you know, bridge condition continue to operate in the meantime. Right? So you need to make that back end shift, while you're operating twenty four seven with with those those bridges. So quick, overview on what the architecture looks like. So, we have our different point sources that are coming into our PI data archive. That spits out information into an ass, asset framework SDK application. That's, really looking at the positioning of where the vessels are. That's feeding that into our, asset framework where we have our different templates. From there, we're using asset analytics to do the calculations on the predictions on one of, and when a ship is gonna reach the bridge. We use PI Event Frames to capture, what's actually happening, to compare actuals against our estimates, and help us do further analysis. All of that gets outputted. So at the top, we have our external, bridge information system on the phones. It's, it's on the website. We use PI DataLink to do our, analytics. The the bottom two, our radio app is still using our old mechanism, so we're gonna move that over. That'll happen later this year. And we're also looking at Waze, so we're talking with Waze and Google at the moment to try to figure out how we can get our forecast into those apps, because it's, you know, widely used, in around our infrastructure. And the Waze aspect is kind of an an interesting output to the public, right, to enhance the public in, perception and and and, you know, not waiting, for fifteen minutes, at a bridge when you can, you know, take the next bridge over and and pass through. Yeah. So maybe a little bit of, you know, the vessel of interest, VIS application, and how it was built. So, you know, from a and we use the the PI AF SDK as as a way to scale up with a hundred thousand tags, on their PI system. You know, we as a PI system integrator, of course, we we could have used PI Web APIs, but in their case, because of scalability, we use the PI FSDKs as the entry, point for the app to make sure that it would scale up in the future. For the the first, you know, last, year, that might not have been, you know, needed really, but in for moving forward and make sure that you're, you know, again, safeguarding infrastructure and scaling up easily. That that was a a key, a foundation element that we deployed. For the the real time data flow, you can see on the picture, the the the zones. And you have a a blue zone, a yellow zone, and a red zone there. So and and and a green zone around. So what we have there, forecasting you may think is is relatively simple for, you know, slow moving vessels. But you've seen in some of the videos, there will be overtaking and there will be some some movement. So you could have a, a a slightly smaller and faster vessel in the in the back that you have not seen, at least that's not in the in the first line of sight. So so these kinds of calculations and enhancement to the forecasting, you know, the more information you get, right, and the further you get, the more precise you can be at fifteen minutes and an hour. Otherwise, you get caught by, you know, a ship either overtaking or one slowing down for whatever other reason. So there there's many, many different things and and scenarios there. But that that's kind of the the basic was geofencing around these different bridges to make sure we can improve, over time those kinds of conditions that will show up in the data. So, of course, the asset framework, we did a a bit of of work on the standardization of all the templates and, again, to make sure that it can scale up and and be, faster to deploy in in the future. Very traditional way of, you know, moving from a a first deployment fast and furious, and then you stabilize. You look at your templates. It was the the right time at this time to refactor some of the templates, make sure, again, on the Saint Lawrence, see where they can deploy fast after. Some of the AF analytics and outputs that we use, you can see some of the, the bridge conditions, you know, available, raising soon. So these are the the the kind of the public tags, values that, you know, would be broadcasted to, external systems, and on the website to to, you know, alert the public of the bridge conditions, and the ETAs. So that's kind of a, the time stamp and the analytics that goes in the back. Again, by centralizing everything in pie, you can do this in real time and make sure that they are as accurate as as the information the real time information is flowing into it. So what are we doing in the future? So you could see back in twenty twenty two, our accuracy. Now this is over the all of the bridges. Our accuracy was around thirty two and a half percent, and that's given an ETA plus or minus, fifteen minutes at a sixty minute window. Today, we're up at thirty nine percent. That may not seem like a big jump. It's a it's about a twenty percent increase from twenty twenty two, but, really, what we've done is we were targeting specific bridges that were our problem bridges where there is much more traffic. Those ones, you won't see it in that number, but we've gone from thirty, forty percent accuracy to eighty to ninety five percent accuracy. That's all we're doing with, to do with the modeling. So now what we're doing, this year is we're starting to model the rest of the canal, the locks, the different bridges, the points where there's, only one vessel could pass. We're look gonna be looking at key identifier. So just to put in perspective, you know, we talk about small vessels, large vessels. A small vessel can approach, slow down faster, can get into the lock a lot faster than a bigger vessel. When both vessels are out in open water, they're both going the same speed. Velocity is all that matters, but when you get in around the the infrastructure, the size starts to play a factor, and there's other things that, that we know play a factor as well. So we wanna model that physical world, start to put that in a template, and seeing how we can use that to, get us from thirty nine percent up to ninety five percent. That's our goal, to be plus or minus, five minutes at sixty minutes, out. Yeah. That's important to note on the percentage side, you know, the, you know, thirty two point five to thirty nine, again, doesn't looks, but it's looking at all the bridges combined. Whereas if you were to look at the ones where we've applied the new, forecasting methods, they're at the upwards of eighty percent. So we're getting close to the ninety five percent end goal, and that's the next step. And once it the the the same forecasting algorithms and data is deployed at all the bridges, you'll see that needle move really rapidly towards the eighty percent range. So there's lots, of course, to be done still, but it's it's in the in in good standing already. And you can see the how many locks you go into sequentially aft one after the the next on the the little videos there. Of course, it's in, again, fast track motion, but the the amount of steps you go through and this, you know, six to ten inches on each side of these very large vessels, it it's impressive that body of water and how you move those ships up is our outstanding engineering work. So maybe just a a quick, way on the journey. So as Saint Louis Seaway, we, you know, we looked at their in their case, it was easy. It was the forecasting, right, as a business, issue. They wanted to increase the forecasting capability and and and potential. Then we looked at, you know, the kinds of data that they have, the kinds of geofencing that we could add, and, you know, the centralization of removing all the complexity of the architecture so that you can scale up. So that once you get to that, you know, that level here, now you can accelerate and get really good, results and, you know, update your machine learning, algorithms over time, directly. So same, you know, process for many different clients, but we always start with, you know, what what's what's the biggest business hurdle that you wanna tackle? In their case, it was the forecasting. Others will be, you know, predictive maintenance, energy, savings, inventory problems, supply chain problems. So start always to the left before you reach to the magic wand at the end of the the the food chain there. Just, one case on the, you know, the journey, that we follow a lot of our clients. You've probably seen this failure curve. You know, a lot of people are asking machine learning and AI, what what does it really do? Well, those two things, it actually picks out the patterns very early on. So whenever there is a, a failure that's initiated at this point here in the curve, you can get that detected much earlier than than, without machine learning. So that's one of the thing you detected early. The other thing it does, which is not shown in this curve, is then it allows you to understand the the when the failure will happen. And that means you can either push out, you know, that lifing, as as you you get down the curve. So two ways of of improving, that that, true machine learning. We've looked at a lot of the data, and Jamie and anybody is all the same. We always, should take and assume that data will get dirty at some point. Right? It's it's operational data. It's industrial data. It's it's ship data. It's it's bridge data. Things will happen. Right? And so the the issue, and the challenge is is if you don't put the safeguards around your data, by the time you get to machine learning, right, you may have beautiful, pristine data initially, but at some point, things will happen. As we say in beautiful English, shit will happen. And you can see how, you know, dirty data gets, and that's normal. Right? So the the principle we apply, from a machine learning perspective is we assume your data, you know, will get dirty, but we make sure we put the data pipeline, right, in between your BICE system and your machine learning algorithm that's running to make sure that it can reliably run over time. So that that's really key when you apply any machine learning. If you're gonna use, your PI data, make sure you put your data pipelines to safeguard the model, from running. That that that's really key for success on the AI side. So Maya can help you, of course. We, we're there to, help, Jamie and and his team to move forward and get to that ninety five percent. And, hopefully, you've seen some some of the nice work that's been done here.

St. Lawrence Seaway operates the bridges and locks along the St. Lawrence Seaway system. Our original ETAs where based on historic standard transit time as a way to have an idea (rough estimate) of when vessels would reach bridges and locks. These times where not very accurate due to a number of reasons, however, they were meant only for internal use. As cities have grown around the system the volume of traffic crossing the movable bridges has significantly increased and there became a need to provide this information to the public. In the next generation, the bridge status estimated times were being calculated by a few different systems using different calculation methods depending on the bridge location and surrounding environment. Some bridges are located along a stretch of the Seaway unencumbered by locks or other physical impediments, while others are situated right next to locks. Depending on a vessel’s approach to a bridge, the estimated times need to be calculated differently. It became clear that these methods were not good enough. There were many elements in which the St. Lawrence Seaway did not have control over and they realized more advance analysis and AI was needed to help get better ETA. As a Premier Partner of AVEVA, Maya HTT has over 12 years of experience implementing and integrating the PI System at customers across various industries from Transportation and Marine to Datacenters and Manufacturing and Oil&Gas; St-Lawrence Seaway selected Maya HTT to accelerate their journey into advanced analytics leveraging the PI System data and external data sources. This topic details our journey evolving from the early days of using historic standards to today using AIS, SCADA, and historical data to build models in PI Asset Framework using PI Asset Analyitcs and machine learning to come up with better predictions.

Download Presentation

Industry

Marine

Company

St. Lawrence Seaway Management Corporation

Speaker

Jamie Andrews

Jamie has 25+ years of experience working in both the Pulp and Paper and the Marine Transportation industries. Through his career in Information Technology and Systems he has touch almost every facet of business, improving processes and implementing new systems. In his current role at the St. Lawrence Seaway Jamie is leading the Information Systems team to bring change in how we capture and manage data, to modernize our systems and to how we can use AI for improving our business outcomes.

Company

May aHTT

Speaker

Remi Duquette

With 20+ years of experience building practical, effective solutions, Remi now plays a key role in heading Maya HTT's industrial IoT, edge, and AI business. He is a sought-after guest speaker with dozens of successful industrial AI/ML/simulation projects to his credit. From his achievement as a young short-track speed skating champion, to his instrumental contributions to successful industrial AI-operations deployments, to the structural design and analysis of five spacecraft currently in orbit, when it comes to "mission-critical", Remi is an asset to all Maya HTT clients.

Session Code

AW24-INF-D2-SESS-168

Transcript

And, just a quick intro. So my name is Rami Duquette. I'm the vice president of our industrial AI at my HCT. We were the, system integrator on the PI side, with Jamie. So, Jamie.

So my name is, Jamie Andrews.

I've, the information, systems manager at the Saint Lawrence Seaway. I was responsible for bringing the PI System into the Seaway.

As you can see, I've been working with the PI System since the year two thousand, so quite a while.

And yesterday, we heard some interesting stories, at dinner. So if, if you if if you want some pie, you know, interesting stories, ask Jamie later.

So, you know, very quickly, I'll introduce the agenda, and then Jamie will walk you through the presentation on the Saint Lawrence Seaway.

Throughout the the, the presentation, you'll see some of these little videos that show segments of the Saint Lawrence Seaway.

If if you don't know about that body of water, it it is really outstanding and and amazing, when you go through that journey on how how they move those ships across and move these, ships upwards. Jamie will will go through that. But we'll just introduce the Seaway, with Jamie, a little bit of of the history there, what their focus is on, what the project was on the forecasting, and the ETA for the the bridge conditions and and the lock conditions. So this is where, we did a lot of good work together jointly with, the Saint Lawrence Seaway. So up to you.

So up in the screen, you see a, a map of, of our region. So this is the Great Lakes Seaway system. It's really a thirty seven hundred kilometer marine highway that goes from the Atlantic Ocean up into the Great Lakes.

We specifically, operate, thirteen locks that, eight of them are in the Welland Canal and five of them are in the Montreal to, Lake Ontario region. We also operate fifteen bridges, eight of them in the Welland Canal and seven of them in the, Montreal to, to Lake Ontario region.

So a side profile of what it looks like to go through the Seaway. So the Seaway was, initiated in nineteen fifteen, nineteen fifty four. It was completed in nineteen fifty nine. So it's about sixty five years old, and it's considered to be one of the, engineering marvels of the twentieth century. So and you can see from the the picture there just how far, vessel that's coming in from the ocean moves up to get into the inner Great Lakes.

So there was a recent, study that was completed, that showed that the there's about two hundred, million tons of cargo that, transits the Seaway, every year.

It's about sixty six billion, Canadian dollars in economic activity, and it supports three hundred and fifty seven jobs within the, the Seaway, domain.

And, as you heard earlier, shipping is, is one of the is shipping gives you the, the lowest or the smallest carbon footprint, has the best fuel efficiency. And just to put it in perspective, the seawaste sized vessels, replace about three hundred railcars or about a thousand, transport trucks.

And just a quick note there, if earlier you missed the presentation from, Jean Frederic from CSL, Please go and and vote for them on the sustainability.

This is, you know, they go one notch above, on the sustainability side. But, when I I told my daughter I was presenting with Jamie in the Saint Louis Zoo, and I showed her the slide to kind of give her a little bit of a a history lesson and, you know, why, marine transport is so amazing.

She was super excited to see the, you know, the amount of of rare cars that, you know, or or trucks that are essentially being equivalent for a in savings for for for shipping. And now she has a new, you know, found appreciation for the marine sector and and how amazing, you know, these ships are. So votes for CSL for this sustainability award.

So what I put up here, is our mission statement and our commitment to communities. And really, what I wanna point out in these two, paragraphs is, you know, our, social responsibility and our commitment to the, communities in terms of open communication.

Why that's important is, you know, historically speaking, when we first, start offering, we were called the Seaweed Authority. It was a government organization, and the ships really have the right way on the on the waterway. So anytime you have a bridge, the traffic will be stopped, the bridge raises so that the vessels can pass, unimpeded through the waterway.

And this was done with no regard for, you know, the communities, the traffic, and things like that. When we commercialized in nineteen ninety eight, we started, taking on, you know, really putting forward our external relations, started, reaching out to the communities and our partners.

So we really kinda turn that around. And so now, you know, we're we're having open communications. We created this bridge information system, which is what we're gonna be, going into more detail.

And but one of the things that was driving that is the growth around the seaway infrastructure significantly increased, especially in the last ten years.

A lot more traffic is crossing those bridges. There's more delays, and so we really wanna kinda give people the idea of, well, which road should I take?

And it really applies to emergency vehicles as well. That was, why we started this in the first place.

So a bit of history on, our bridge information systems. So the first application was created back in two thousand seven. It was created for our well in canal, only. It was done in visual basic, which was, you know, still popular at that time.

It, we really looked at what we call the standard transit time, which is, you know, to go from point a to point b. It should take this long. So that's what we based our, our predictions on.

And, so over the next few years, we, we started to, we added the Montreal region bridges, and we started making some minor tweaks. In two thousand thirteen, mostly due to, you know, our our numbers not being that accurate, we started making some minor improvements. We, we shrunk the forecast down because we we originally were forecasting eight hours. And, you know, beyond an hour, we were completely, missing the mark. So we really brought it down to an hour and later on in, in in twenty between twenty thirteen and eighteen in the Welland Canal, we even brought it down further to, to fifteen minutes because we realized that, with the complexity that's in the Welland Canal, the structures that are really close to each other, it was really impossible for us to, you know, go beyond fifteen minutes in that area. So so again, in twenty eighteen to twenty twenty one, we underwent some major, changes to the application, change in look and feel, providing more information.

One of the things we weren't capturing was maintenance.

Somebody would go and do maintenance. They would shut the bridge down. Well, people, you know, we're saying the bridge is available, but we shut it down for maintenance. So we had to make some changes to the application there. On the bottom, you'll see in twenty twenty is, the at the end of twenty twenty is when we installed our our first PI system. That's when we got it up and running. At that point, we didn't have any view on using it for the bridge information system.

In twenty twenty one, we had a major escalation in our Montreal region.

It kinda caught us off guard because up until that point, all of our issues were always around the Welland Canal, trying to get the accuracy around Welland Canal. So for us, this kinda came at us, with a bit of surprise.

It was, like I said, a major escalation. There was a new found push on improving the accuracy. And so we created a new algorithm in twenty twenty one between twenty twenty one, twenty two.

What that set us up for was we ended up having multiple algorithms all doing different bridges. So some were still using standard transit time, some were looking at velocity.

And all in all, we had four algorithms all going to, you know, different outputs, different inputs. It was kind of a mess, but it was, you know, we had to get something quick. And that's when we, reached out to Maya in twenty twenty two to come in and help us and say, look, we need some help with this. Can you look at, you know, what we're doing? This is what we're thinking. And, so they performed, initially, a gap analysis.

And, from there, we, we started on the journey of standardizing that whole back end, instead of using because all these algorithms were using hard, you know, application software, code that was hard coded. We brought it all into the PI System.

We created the all the algorithms as templates, and which now allows us to be able to replicate, if something's working for one bridge, we can replicate it if we we have the same. And it makes it easier for us to update the model.

And so that solution, we are started rolling it out this year. We're still in the process of rolling it out, but, at this point, we now have, full PI integration.

And one one quick note on the, my HTT side as a system integrator. So initially, we perform, you know, a gap analysis for understanding, you know, all the back end components and the inputs and outputs that were needed, for, you know, enhancing the the the the the forecasting, but also making it future proof. Right? We know that they they had, very good goals short term, but they had bigger goals for long term. So we wanted to make sure that the infrastructure that we would put in place on the back end would serve them for the long journey of getting to and enhancing over time their their forecasting capability. So, Maya, you know, twelve plus years of of experience with as a PI System integrator, we're at over six million, tags deployed on the PI side with various clients, a hundred and fifty, projects total roughly over the last fifteen years.

So, yeah, if, if you have any, PI System integration or machine learning forecasting work that you'd like done after the presentation, come come see me, and you'll have, you know, Fred on CSL and and, in the same on CSA with Jamie, good people to discuss and see how they interacted with with us.

So a quick view of, the PI System at the Seaway. So we migrated from, I Historian prophecy in the summer of twenty twenty.

The old system we had was, you know, we had two separate systems in each region. They weren't talking to each other. They weren't really kept up, like, nobody was really using it. So what we did is we installed a hundred thousand tag, high availability, corporate wide Aviva PI system. Ninety percent of those tags are being used.

We have unlimited connectors, to connect to different SCADA systems, to our AIS signal, to your RDBMS.

We also have, fifty PI vision licenses, thirty data link licenses, and and growing.

From PI data access, we're using PI SQL as well as the asset framework SDK and the OPC.

So and I would say our pie culture is on the rise. It wasn't, easy at the start to, to convince our automation people, but, I would say in the last year with the, work of the bridge of the emission system and some of the other things that we're doing, the pie culture is, definitely on the rise of the seaweed.

And as you can see on that little video, right, it's, it's really awesome to see. Of course, it's fast tracked. They don't go that fast.

But it's it's an interesting journey there.

Maybe just a word on what we've accomplished, with the last two years, with Jamie's team, on on the pie side.

So really, the focus was on enhancing the the the bridge condition ETA. So the, you know, estimated time of arrival and and change of those conditions.

And what we've accomplished over a two year period is about twenty percent, on especially the the specific bridges that we were targeting initially, to prove out, you know, the back end, the new concept, and everything.

But you'll see there's a lot more room now to improvement for the other bridges that we are, hopefully, gonna tackle moving forward.

But that's that's really what the, the the future proofing was about. And then even with the future proofing and all the back end work that we needed to to do, twenty percent is, I think, a significant. So now we'll tell you how we got to a twenty percent, improvement there on the forecasting.

Quick slide on the the design strategy. So as we went through the the gap analysis and look at all the different, AIS based bridge condition where you you do have the AIS information that coming in, you can then, you know, pipe that information into the PI system and then leverage those for for better ETA and messaging calculated all in in the PI system. So there was no reason to have multiple other database, and you'll see the original architecture where we start from, and Jamie will will comment on that, and how we move to, you know, centralizing the SCADA information and the AIIS information and and, you know, other information in a central, position to do the forecasting directly, attached to the PI system.

Jamie?

So a quick look at our initial architecture that's on the you're right.

You you could really see that it was a bit of a spaghetti factory. We had multiple, you know, applications calculating, going to multiple, outputs.

And sometimes these outputs conflicted with each other. So somebody would be looking at an app on the phone, and it would say fifteen minutes, and then on the radio, it was saying it was gonna be five minutes. And so we really it was a bit of a mess.

So over on the, on the right side, we have our new infrastructure where everything, you know, whether it's a database, the s signal, the SCADA system, it all comes into pi, and it all the outputs go or come from pi.

And maybe just a a comment. You know, if if you recognize yourself on the left side, right, it's it's always a journey to get to the right side.

With Jamie's help, we were able to to do that within the, you know, two year periods. So step by step, you know, one one component at a time being brought back in in a systematic fashion. But that was a very interesting puzzle to move and make sure that these, you know, bridge condition continue to operate in the meantime. Right? So you need to make that back end shift, while you're operating twenty four seven with with those those bridges.

So quick, overview on what the architecture looks like. So, we have our different point sources that are coming into our PI data archive.

That spits out information into an ass, asset framework SDK application. That's, really looking at the positioning of where the vessels are. That's feeding that into our, asset framework where we have our different templates.

From there, we're using asset analytics to do the calculations on the predictions on one of, and when a ship is gonna reach the bridge. We use PI Event Frames to capture, what's actually happening, to compare actuals against our estimates, and help us do further analysis.

All of that gets outputted. So at the top, we have our external, bridge information system on the phones. It's, it's on the website. We use PI DataLink to do our, analytics. The the bottom two, our radio app is still using our old mechanism, so we're gonna move that over. That'll happen later this year. And we're also looking at Waze, so we're talking with Waze and Google at the moment to try to figure out how we can get our forecast into those apps, because it's, you know, widely used, in around our infrastructure.

And the Waze aspect is kind of an an interesting output to the public, right, to enhance the public in, perception and and and, you know, not waiting, for fifteen minutes, at a bridge when you can, you know, take the next bridge over and and pass through. Yeah.

So maybe a little bit of, you know, the vessel of interest, VIS application, and how it was built. So, you know, from a and we use the the PI AF SDK as as a way to scale up with a hundred thousand tags, on their PI system.

You know, we as a PI system integrator, of course, we we could have used PI Web APIs, but in their case, because of scalability, we use the PI FSDKs as the entry, point for the app to make sure that it would scale up in the future. For the the first, you know, last, year, that might not have been, you know, needed really, but in for moving forward and make sure that you're, you know, again, safeguarding infrastructure and scaling up easily. That that was a a key, a foundation element that we deployed.

For the the real time data flow, you can see on the picture, the the the zones. And you have a a blue zone, a yellow zone, and a red zone there. So and and and a green zone around. So what we have there, forecasting you may think is is relatively simple for, you know, slow moving vessels. But you've seen in some of the videos, there will be overtaking and there will be some some movement. So you could have a, a a slightly smaller and faster vessel in the in the back that you have not seen, at least that's not in the in the first line of sight.

So so these kinds of calculations and enhancement to the forecasting, you know, the more information you get, right, and the further you get, the more precise you can be at fifteen minutes and an hour. Otherwise, you get caught by, you know, a ship either overtaking or one slowing down for whatever other reason.

So there there's many, many different things and and scenarios there. But that that's kind of the the basic was geofencing around these different bridges to make sure we can improve, over time those kinds of conditions that will show up in the data.

So, of course, the asset framework, we did a a bit of of work on the standardization of all the templates and, again, to make sure that it can scale up and and be, faster to deploy in in the future.

Very traditional way of, you know, moving from a a first deployment fast and furious, and then you stabilize. You look at your templates. It was the the right time at this time to refactor some of the templates, make sure, again, on the Saint Lawrence, see where they can deploy fast after.

Some of the AF analytics and outputs that we use, you can see some of the, the bridge conditions, you know, available, raising soon. So these are the the the kind of the public tags, values that, you know, would be broadcasted to, external systems, and on the website to to, you know, alert the public of the bridge conditions, and the ETAs. So that's kind of a, the time stamp and the analytics that goes in the back. Again, by centralizing everything in pie, you can do this in real time and make sure that they are as accurate as as the information the real time information is flowing into it.

So what are we doing in the future? So you could see back in twenty twenty two, our accuracy. Now this is over the all of the bridges. Our accuracy was around thirty two and a half percent, and that's given an ETA plus or minus, fifteen minutes at a sixty minute window.

Today, we're up at thirty nine percent. That may not seem like a big jump. It's a it's about a twenty percent increase from twenty twenty two, but, really, what we've done is we were targeting specific bridges that were our problem bridges where there is much more traffic.

Those ones, you won't see it in that number, but we've gone from thirty, forty percent accuracy to eighty to ninety five percent accuracy.

That's all we're doing with, to do with the modeling. So now what we're doing, this year is we're starting to model the rest of the canal, the locks, the different bridges, the points where there's, only one vessel could pass.

We're look gonna be looking at key identifier. So just to put in perspective, you know, we talk about small vessels, large vessels. A small vessel can approach, slow down faster, can get into the lock a lot faster than a bigger vessel. When both vessels are out in open water, they're both going the same speed. Velocity is all that matters, but when you get in around the the infrastructure, the size starts to play a factor, and there's other things that, that we know play a factor as well. So we wanna model that physical world, start to put that in a template, and seeing how we can use that to, get us from thirty nine percent up to ninety five percent. That's our goal, to be plus or minus, five minutes at sixty minutes, out.

Yeah. That's important to note on the percentage side, you know, the, you know, thirty two point five to thirty nine, again, doesn't looks, but it's looking at all the bridges combined. Whereas if you were to look at the ones where we've applied the new, forecasting methods, they're at the upwards of eighty percent. So we're getting close to the ninety five percent end goal, and that's the next step. And once it the the the same forecasting algorithms and data is deployed at all the bridges, you'll see that needle move really rapidly towards the eighty percent range. So there's lots, of course, to be done still, but it's it's in the in in good standing already.

And you can see the how many locks you go into sequentially aft one after the the next on the the little videos there.

Of course, it's in, again, fast track motion, but the the amount of steps you go through and this, you know, six to ten inches on each side of these very large vessels, it it's impressive that body of water and how you move those ships up is our outstanding engineering work. So maybe just a a quick, way on the journey. So as Saint Louis Seaway, we, you know, we looked at their in their case, it was easy. It was the forecasting, right, as a business, issue. They wanted to increase the forecasting capability and and and potential.

Then we looked at, you know, the kinds of data that they have, the kinds of geofencing that we could add, and, you know, the centralization of removing all the complexity of the architecture so that you can scale up. So that once you get to that, you know, that level here, now you can accelerate and get really good, results and, you know, update your machine learning, algorithms over time, directly. So same, you know, process for many different clients, but we always start with, you know, what what's what's the biggest business hurdle that you wanna tackle? In their case, it was the forecasting. Others will be, you know, predictive maintenance, energy, savings, inventory problems, supply chain problems. So start always to the left before you reach to the magic wand at the end of the the the food chain there.

Just, one case on the, you know, the journey, that we follow a lot of our clients. You've probably seen this failure curve. You know, a lot of people are asking machine learning and AI, what what does it really do? Well, those two things, it actually picks out the patterns very early on.

So whenever there is a, a failure that's initiated at this point here in the curve, you can get that detected much earlier than than, without machine learning. So that's one of the thing you detected early. The other thing it does, which is not shown in this curve, is then it allows you to understand the the when the failure will happen. And that means you can either push out, you know, that lifing, as as you you get down the curve.

So two ways of of improving, that that, true machine learning.

We've looked at a lot of the data, and Jamie and anybody is all the same.

We always, should take and assume that data will get dirty at some point. Right? It's it's operational data. It's industrial data.

It's it's ship data. It's it's bridge data. Things will happen. Right? And so the the issue, and the challenge is is if you don't put the safeguards around your data, by the time you get to machine learning, right, you may have beautiful, pristine data initially, but at some point, things will happen.

As we say in beautiful English, shit will happen. And you can see how, you know, dirty data gets, and that's normal. Right? So the the principle we apply, from a machine learning perspective is we assume your data, you know, will get dirty, but we make sure we put the data pipeline, right, in between your BICE system and your machine learning algorithm that's running to make sure that it can reliably run over time.

So that that's really key when you apply any machine learning. If you're gonna use, your PI data, make sure you put your data pipelines to safeguard the model, from running.

That that that's really key for success on the AI side.

So Maya can help you, of course. We, we're there to, help, Jamie and and his team to move forward and get to that ninety five percent. And, hopefully, you've seen some some of the nice work that's been done here.