 Hello everyone and welcome to this Edge Your Serve webinar. We're going to get started because we haven't got a great deal of time. We've got quite a lot to get through. My name is Andy Powell, I'm CTO at Edge Your Serve. We're really pleased so many of you could join us today. We had over 50 people registered, not quite sure how many have actually joined the call, so the webinar so far, but really good to see so many of you here. For those of you that don't know us, Edge Your Serve is a not-for-profit based in Bristol. We actually have three parts to our business, but the pertinent part today is to serve cloud solutions. We exist to help our customers exploit technology and in particular to exploit public cloud and clearly smart city activity, use of data and so on forms a key part of one of the things people are turning to public cloud vendors like Microsoft, Amazon Web Services and so on to help them with. So very much on target for us today. Just in terms of housekeeping, we will take questions. We're going to do that at the end of Apollo's talk. I'll introduce Apollo in a moment. So use the question tab in the go to webinar interface. If you want to ask a question, we'll run through those at the end. The other thing is, if you have any problems with sound quality or any other issues during the webinar, feel free to press the hand button. So raise your hand and we'll get flagged of that and we can take some action. So let's get started. I wanted to start by just talking about smart cities a little bit and I've done what everyone does, I suppose, when they're thinking about smart cities and that's turned to Wikipedia and see what's Wikipedia has to say. So they define, I've slightly modified this, but broadly speaking, they define a smart city. We actually prefer the term smart place, I must say, but smart city is an urban area that uses data to manage assets and resources efficiently and to help citizens go about their business more effectively. So this includes data collected from citizens, from devices, and it includes assets that are processed and analyzed and monitored to manage traffic and transportation systems, power plants, water supply, waste management, law enforcement, information systems, schools, libraries, hospitals, fire services, pertinent to today, and basically any other community services. So that's really how we think of the smart cities space. I think the important thing there is the critical role of data in smart cities and clearly data plays a fundamental role in our ability to deliver smart services. So you can't really do smarter services without building on a coherent and well-managed data resource. And so in any smart city or smart place activity, you're really relying on the collection and management of data coupled with the ability to learn from that data to draw inferences from it in order to make better decisions. And that really brings me to the meat of today's session, how London Fire are using data to be smarter. And it gives me great pleasure to introduce Apollo Gerald Limbus, who is head of data analytics at London Fire Brigade. And Apollo is going to speak to us about the ways in which London Fire are attempting to exploit data to improve the services that they deliver. So with that, I'll hand over to Apollo. Thank you very much, Andy. Good afternoon, everyone. I'd just like to start off with a brief background about London Fire Brigade and the role that the kind of data analytics team play in it. As Andy mentioned, any questions, happy to take them at the end. Otherwise, you feel free to get in touch with me, my details are up and I'll put them up again at the end. So London is a obviously a very large place. The area it covers is around about, sorry, around about 1500 square kilometres and around about eight, almost nine million people. Three and a half million homes, almost a million businesses spread over 32 boroughs plus the city of London. And we cover this area with a resource pool of about 102 fire stations, 142 frontline fire engines, and around 5,000 operational staff, around 800 office staff. And broadly speaking, we go to around 110,000 incidents a year. Now, these incidents are sort of, again, a ballpark breakdown of these incidents is that around half of them are false alarms, but we don't spend that much time at each of these false alarms. 30% or 30,000 incidents of special services, so things we attend like floodings, road traffic collisions, animal rescues, and so on. And the remaining 20,000 incidents, broadly speaking, are fires. And of those, around 5,000 of those are the most serious incidents we attend, which are, of course, fires in dwellings, fires where people live and sleep. We kind of offer up home fire safety visits. We do almost 90,000 home fire safety visits a year. About 80% of those are targeted at what we call a priority dwelling, priority one dwelling. And we also do lots of regulatory inspections in businesses and places where people work. So, London Fire Brigade have essentially have come a long way in their history. Gone are the days when we've been seeing kind of moving around on horses and carts or pinning bits of information to cork boards in the control centre. We now have very modern fire appliances. This is our series three Mercedes up on the screen and also quite complicated integrated systems that collect a lot of data. And that, of course, leaves a lot of data to be analysed, which brings me kind of to the key topic of today's webinars. What about analytics in London Fire Brigade? Are we still using old methods or are we kind of a modern service ourselves? So, brief overview of the team. We are an interdisciplinary team. We've got 12 people, a mix of skills which I'll cover in a bit. And we work with pretty much all the stakeholders internally and externally who have an interest in fire service and the fire service operations. That includes fire investigation, our community safety teams, the operational tactics departments, special operations group that look at things like counter terrorism, local authorities, so external stakeholders. Also, the borough commanders and station managers who are our frontline kind of management team, our communications and press team, and all the kind of freedom of information requests that come through essentially get processed by our department. And also we work with the 999 centre, the mobilising centre. And that's probably where we'll focus most of our webinar on today is around the use of data to improve attendance times and data that looks at, kind of traffic and GPS mobilisations. So, as I mentioned, we provide business intelligence to the organisation. We do all their day to day analytics. We look at incidents and the demand of incidents. We have a sort of spatial mapping function within the department where we can display kind of the spatial analysis of our demographic analysis. And we also look at kind of hot topics that come up like electronic cigarettes and driverless cars and whatever it might be that's the sort of flavour of the month in terms of analysis. Just moving on. Example of some of the tools we use and some of the types of analysis, as I mentioned, we rely quite heavily on mapping and spatial analytics simply because displaying some of these large data sets in a visual way to an operational borough commander, let's say, in Islington or Richmond, it's really helpful for them to see things on a map, especially if we're looking at patterns in deliberate fires or any such risk profiles of local residents by postcode or something like that. And we use the traditional tools. We're quite Microsoft heavy in those, but we also have opened up recently to some of the more open source tools like QGIS, Python and R programming to do some of our analysis. I mentioned GPS mobilisations. We've developed some internal dashboards where managers can look at the routes that the fire appliances took to a particular incident and analyse those routes, looking at how much time a fire plant spent on each road, for example. They might want to analyse the impact of a local road closure perhaps or the impact of some street festival bridge closure, whatever it might be. This will allow them to do that. And essentially, all the data is kind of ingested overnight and pre-populated, snapped to the road network and served up in the form of a relatively easy to use front end dashboard for managers. At this point, it's probably worth mentioning a really interesting project that happened recently. The EENA, which is the European Emergency Number Association, did a project in partnership with Waze, which is a sort of community, let's say, crowdfunded platform that integrates live data onto a map and displays traffic data. Essentially, they trialled whether Waze would be able to integrate with emergency services in three areas. One being around more intelligent routing and avoiding traffic to improve attendance times. Another would be whether users of Waze could use the platform to report incidents effectively to the emergency services. The final one would be a data quality assurance, essentially, against the calls that they're receiving through the traditional methods to verify the location or, in fact, the significance of an incident. Using the appliance availability information and the resource status change messages that come out of our mobilizing system, we're able to answer the question we get asked quite a lot, which is how busy are you at a very accurate time frame. Essentially, traditionally, we would say x% of the time we are busy, x% of the time we are not responding to emergencies, and so on. Now, using the status change information, which is essentially big data because it produces tables with hundreds and hundreds of million rows of data, essentially at any minute of the day, we're able to say exactly how many fire appliances were available, occupied at an emergency incident, or unavailable for any reason. This is an example on screen that you have now from the recent once dead flats grass fire, which was a 40-pump grass fire in London. You can see the development of that incident when we reached peak activity for that incident, keeping in mind we were attending other things at the same time. And then how long it took to return to a sort of normal, let's say, baseline level of utilization where we're doing our business as usual, et cetera. And there's no sort of large incident ongoing. And these tools kind of do a lot in the background. There's a lot of data processing, a lot of information kind of quality checks and stuff that we've automated that happens in this case overnight. And then in the morning, essentially managers are able to open up these tools in a central portal and essentially just ask the questions that they need answered and get responses quite quickly. To give some context, this used to take probably about half an hour to do in Excel. And like I say, now it's something that you can very simply just pick a day or a month and the data gets displayed for you. The final point I want to make around emergency mobilizations. And while I talk about it, I'm just going to try and play a video for you. And this is some work we've been doing with essentially the external consultants called ORH based in Reading. And the work that I'm showing you now is work that essentially enables our control officers to make more data driven decisions, better informed decisions around how to move fire engines across London to cover areas when there is a significant incident going on or a series of smaller incidents that mean a certain area of London doesn't have the cover that it would usually have. So what you're seeing on this map is essentially the fifth of November, which is traditionally quite a busy day for us. We're about just after 10 in the morning now. And you can see as the fire engines, which are the small gray dots moving around London and areas of cover, which is displayed on the red to blue scale, are essentially becoming better or worse. Control officers have these tools available to them to make decisions around should I move a fire engine from this area to another area to improve the predicted attendance time. Or in fact, if they know the incidents that are going on are not that significant, as I mentioned earlier, false alarms, for example, don't last very long, then they might make the decision not to. But if a large incident occurs, and that area of London has a lot of occupied fire engines in it, then they might choose to move a fire engine from a different area in London over to that area as a standby. And what that would essentially mean is the mean response time would decrease, which is a good thing. And we've done a few projects with external organisations like UCL. We had a master's student from their space time lab of data analytics who did his whole master's project on precisely this. Comparing the predicted attendance times to the actual attendance times we were achieving and using the data around the street speeds, the actual speeds fire engines can achieve on different categories of roads. And looking at the route choices that drivers were making. Essentially built a model to say if we were to have a live, a live quotient of, let's say the speed of every single road in London, based on what fire engines can achieve on that road historically, then essentially the attendance time would decrease. Another change we've made recently is we mobilise fire engines based on their geographic location, not their station ground or patch as it's called. What that means is that it kind of works like Uber. The closest fire engine to you that is available will be the one mobilised to you. And that is when I say closest, I mean in terms of the time it will take to arrive and that takes into account the speed of the roads that it will have to travel down. So if there are two fire engines equidistant essentially to your incident, the one with the faster roads between it and the incident will be the one to attend. And that in itself has created quite significant decreases in our attendance times. But as you can see now on the map we're around getting approaching half past 8pm. There's quite a lot of incidents going on. It's bonfire night. You are seeing in the north London, let's say, just then a large incident developing and pumps from areas that are not that busy could be sent into areas that are busy in order to reduce that kind of that average response time. Sort of wrapping up here, I mean, we have a lot of data. We collect a lot of data about a lot of different things. We collect data around the incidents we attend about London and Londoners, daytime population estimates for different areas of the city. We collect information about, of course, the properties and types of property that London is made up of. And we've done quite a lot of work recently moving into the sort of data science space trying to make better use of free text information that we gather using sort of natural language processing. But also trying to understand the built environment, be that trying to identify high rise buildings or trying to identify domestic premises that we believe are at a greater risk of fire. Because ultimately what we're trying to achieve here is reduce the number of fires and when they do occur, attend as quickly as possible. That leaves me with the final slide essentially, which kind of wraps up my side of the webinar, which is if you have any questions. Can I speak? Yes. Great. Thanks very much, Apollo. That was really interesting when I appreciate within, you know, a sort of 30 minute slot like this is it's difficult. There's an awful lot of material there you you could be covering while we wait and see if any questions come in from listeners out there. I'd like to ask you a quick question, which is really what I call an interview question. What your biggest challenges were in moving to much greater use of data. So was it with the technology? Was it around funding? Was it getting buy-in from senior management? Was it quality of data kinds of issues? Was it something else? I'm just interested in what you found hardest and maybe what you would have done differently knowing what you know now. Sure. So when I first started here, the team was three or four people and it was very traditional kind of reporting on data that we had, you know, using reporting services, Microsoft reporting services, and moving away from that kind of just producing performance statistics into trying to do something a little bit more insightful, more fun, you know, something using the data better. I think the first hurdle was skills, right? So learning the spatial analytics tools, Python, our programming language, some of the interactive dashboards. It's a skills gap and luckily we were building the team anyway and the people who were here had an appetite to learn about these new methods, let's say new skills. And so that was the first hurdle was kind of getting the training, getting the tools because obviously some of these open source tools were not installed previously. And in order to get open source tools installed on kind of, you know, government machines, you need to go through a few hurdles there. But, you know, we're in a very good place now where we have, like I said, a team of 12, a mix of skills. Some people are better at the programming, others are better at, you know, the mapping or going to a meeting and talking to stakeholders. And also we have access to sort of virtual machines where we can do whatever we want, install whatever tools we need. And so we're in a much better place. But I think, yeah, access to the tools and skills, I mean, kind of speaks itself, but those were the two main things. The data was actually really good. So we have a lot of data quality checks that have been historically happened after every incident. And in terms of the mobilisation, you know, data, the GPS data, those have been quite good. I mean, obviously you still need to do some data cleaning in any exercise. But the biggest hurdle wasn't actually the data. It was probably getting people trained up to use the tools that we're now using. But like I said, the appetite was there. So it didn't take a lot of convincing. It just took some training sessions and some planning, et cetera. Cool. OK, thanks. My second question is around geography, I suppose. Not so much just geography within London, but it seems to me any smart city slash data based exercise. Inevitably, you have a geographic boundary between the things you're responsible for and the things that are going on around that space. But I assume in practice, if there's a big fire just outside your geographic boundaries, you may well get pulled in and join forces with another fire service. Is that true? So I suppose my question is, if that is the case, have you made any progress in sort of sharing standards with other fire services, I suppose? Yes, so we do go across the border and cross border brigades do come into London. Obviously, we have to adhere to our specifics, what we call safe systems of work and policies and procedures around, let's say, firefighting in a built environment or a compartment firefighting. So we would treat it as if we were attending on our own, but they would also join forces. That's absolutely true. We share a lot of data with neighbouring brigades, and that could be data from the NHS around the location of vulnerable people, or it could be information around premises that we know have domestic oxygen cylinders, which is obviously a risk to firefighters, or premises that have car workshops and risks that are present inside buildings that we might end up attending. So we do share a lot of data, and also in terms of planning London fire cover, we take into account that some of the neighbouring, the closest fire stations on our border are retained fire stations, so they might take a little bit longer to be activated in the tendon incident. But we obviously know which those are, and our mobilising systems take that into account when sending a fire engine to an incident. So, yes, we work well together. There are obviously more opportunities now and in the future to share data and get more insights around the vehicle deployments or the road speeds, et cetera, and that really is an area that is growing and we will be looking into. It's worth noting that we have a project called the Zero Emissions Pumping Appliance Project. Essentially, it's like a clean slate of design a new fire engine with zero emissions, and you can have any kind of telemetry or anything you want on there. And that project is kind of starting now, but it's going to be a really good opportunity for us to get data about things like when did the water first start pumping, what was the flow rate of the pump, the precise location, I suppose, in the centre of London using 5G technology and things that I don't really know that much about, but there will definitely be opportunities to take this one step further using those technologies. OK, cool. So, there's a quick question coming from Chris Frye. How much of a strategic commitment of London Fire Brigade made to data collection and data quality? OK. So, as part of our integrated risk management plan, which is the kind of what the government sets out every fire service has to have, we need to have a clear understanding of all the foreseeable risks within our area. So, firefighters go out and do lots of safety inspections. They do lots of home fire safety messaging and community safety work. We visit schools. We collect essentially as many data sets as possible that are available or people want to share with us. Some of those are open data, things like, you know, even from the census around locations of people who don't have central heating, who might be at more risk, let's say, of using an unsafe means of warming their home right through to data sets around, you know, like heritage buildings. Essentially, whatever it is, we've sort of taken into account. We've delivered some tools to the public where they can put their postcode in and see exactly what their local ward area or borough area looks like in terms of the risks that they've told us that they're worried about, right? So, we're not just assuming what people are worried about. We've gone out and asked what people are worried about. And all those data sets have been built in. I assume we can share some links when we make this webinar available afterwards. I'm happy to share those. And so, yeah, there's a growing department. Data quality is obviously very important. We also go out and engage with the crew managers, station managers, borough commanders, or the operational side, the people that are actually entering the data following an incident. We show them tools that we've created using data that they've entered to try and kind of increase their understanding of what we're doing with the data, but also reduce any resistance that they might have to filling in a form or filling in some data collection template that we've supplied. And I think that's a really important point is, you know, if you want your end users to take ownership of data quality as well, then you need to share the end results of what you're doing with their entry back to them. So that's kind of the key point of us delivering this central portal on our internet where people can go and via Active Directory will recognise who they are and essentially serve up data that is relevant to their role and things that they should know about or should care about to do their job. Yeah, cool. Right, we've got about a minute left, so you have to make this quite quick. Question come in from Alessandro Chester. You mentioned moving from traditional reporting. What for you is the main difference between performance reporting and insight reporting? I think you need to give people at the end of them looking at the report, they need to go away feeling that they've taken something useful to go and do their job. So a traditional report might list a series of fire hydrants that need service, that essentially a more insightful report should leave the user with the impression that they've got something useful that they can go away and do their job more effectively with that piece of information, be it serving up an insight that is using two combined data sources that they may not have seen before, or some sort of prioritisation or something that is more useful than just looking at a list or a table. Cool. Shall I ask that one last question? Okay, so we've got one last in from Cynthia Derby's. Does London Fire plan to make use of drones in the next two to three years for traffic management, crowd management and or fire monitoring? Yes, so actually drone trial started two weeks ago, the first drone trial. I happen to see the first operational deployment of the drone and the pictures and video that it took. It's extremely useful for monitoring fires from above and also giving an operational oversight where there might not be a line of sight view to whatever risk they're targeting. So yes, there is a drone trial ongoing currently, and I'll wait and see the feedback, but I'm sure it's going to be positive because even after just one or two operational deployments, people are seeing its praises. Cool, and presumably it's going to be yet another source of data for you. Okay, I think we'll wind up at that point. I just want to say a massive thank you to Apollo. Really interesting webinar. I hope you all found it interesting and thanks to everyone for joining us today. Over and out.