November 8, 2016 | Written by: Karen Lewis
Share this post:
Watson IoT Platform & Node-RED hit the ground running with an emergency first responder solution
IBM Watson IoT Platform hits the ground running with a first responder on-scene application using Node-RED. Saving lives requires information at your fingertips – and fast. A micro-service architecture application using Watson IoT Platform and Node-RED to calculate an ETA for a full complement of first responders to arrive “ON-SCENE” gives authorities vital information in real time. Using IBM design thinking and access to local emergency teams, gaps were identified in current systems and technologies. This process quickly defined use cases that aligned with Watson IoT capabilities. The article outlines the development of a working MEAN (Mongo, Express, Angular, Node) app running on IBM Bluemix, integrating with Watson IoT Platform, Node-RED, Bluemix Services and external APIs.
Figure 1: Dramatic bank holiday weekend rescue of three people by Galway RNLI Lifeboat in Galway Bay, photo credit: RNLI
It’s 3.20 am and a beeper has just gone off in the dark. A message reads: Launch ILB. The volunteer springs into action, gets kitted up, jumps in the car, drives through the darkened medieval streets of Galway, headed for the lifeboat station.
One of the volunteers, Mike Swan, is the operation manager for the Galway lifeboat station. Mike is already at the station, checking his watch. It’s been three minutes since receiving the Coast Guard call. Three minutes since he authorised the pagers to ring. In a matter of seconds more than 30 volunteers will have been notified. Thirty messages. The first responders are making their way to the station. But how many are available now and on their way in? Who are they and when will they arrive?
Six minutes in Declan Killilea, the helmsman, arrives at the station. The helmsman’s responsibility is to look after the crew, the boat, the launch, the service, and the casualties. Declan flips through his mental list of possible volunteers. He knows each volunteer well enough to consider their skills, as well as their personal situations.
While waiting to see who arrives, Declan continues to factor a myriad of conditions in his head – do they have young children, are they a first aider, are they a fireman or a sailor, are they experienced crew or new, what are the weather conditions, and is it a bad night? He uses all of this knowledge to determine who will remain at the station and who will be in the boat. But until people walk through the door, it’s all hypothetical. Neither the operation manager, nor the helmsman have any visibility into who has responded to the shout, or what the mix of skills will be before they arrive. Another minute passes.
Eight minutes into the shout, several volunteers have appeared at the station, enough for Declan to assemble a three man crew. Now he’s at a critical juncture. The call out is ‘boat on rocks.’ It’s dark, the tide is high, and rain pelts against the window. His gut tells him he needs a first aider in the boat, but none of the first aid trained crew have arrived. Are any of them available, and if so, what’s their ETA? Should he go now with the existing crew, or delay the launch, waiting for a first aider? The clock is ticking.
12 critical minutes
From the second the beeper goes off to the moment the boat hits the water, the average launch time for a volunteer crew is 12 minutes. Anyone who has ever worked or been associated with first response emergency teams knows seconds count in a crisis. Having visibility into the exact whereabouts and estimated time of arrival for each responder could make the difference between life and death. Every volunteer helmsman faces the same situation: Should they launch? Or wait another 60 seconds for a critical resource to arrive?
An opportunity waiting to be addressed
Across the UK there are 236 lifeboat stations that run 320 lifeboats. The stations are manned by about 5000 volunteers. The Galway Lifeboat station, which is just one of those stations, launches between 25 – 30 times in a year. With more than 14 years of experience as a lifeboat volunteer, Declan knows the pitfalls and gaps in the process. Fortunately, he also works at the IBM Galway Lab where water-cooler conversations and canteen meetings are a way of life in the tight-knit community of approximately 100 staff. Being a small site enables cross-pollination of ideas and projects, creating situations where people can easily share and collaborate. That’s exactly how Brian Campion, Eoin Jordan, and Shane Lynch hooked up with Declan Killilea to solve the helmsman’s dilemma.
Figure 2: The IBM Galway team responsible for creating emergency first responder solution: from left to right, Brian Campion, Eoin Jordan, Declan Killilea (The Helmsman), and Shane Lynch.
Figure 3: An RNLI ILB pictured with the IBM Galway Team with RNLI Lifeboat Volunteers from the Galway Station.
Rallying the IBM team
It is Shane Lynch who first kicks off the idea. Shane is a techie software engineer with a background in electronics and computers. After reading an article about the increasing number of call-outs the RNLI experiences around Halloween caused by Chinese lanterns mistaken for flares at sea, Shane wonders if an IoT solution could be used to address the false alarms. Shane knows Declan is a lifeboat volunteer and reaches out to him to discuss whether an IoT solution could help.
Declan replies immediately in his matter of fact manner: “That’s not what I need. While that might be an interesting use of IoT, it’s a once a year occurrence. I’ve got a bigger issue that happens all year, at every call out. What I need is a scheduling app, a way to track people on their way to the station, notification that the right people are on their way, inclusive of their estimated time of arrival.”
The ultimate KPI is saving lives
Brian Campion then joined in to volunteer and assist with this initiative. Brian is an Information Development manager – very engaged in visualization techniques for IT projects. Brian puts IT projects in perspective – and for this use case, the primary KPI for a lifeboat IoT application is that it could save lives. If even one life is saved as a result of their efforts, it would be a success story. Naturally, he jumps at the opportunity to help explore how IoT could be used to address Declan’s challenge.
After kicking around some initial ideas, the team decides a mobile app is needed. That’s when they tap Eoin Jordan’s shoulder. Eoin, a Java developer with cross platform mobile development skills, has been exploring Watson IoT Platform, IBM Bluemix and Node-RED. The idea sparks his interest, taking him back to his roots as a mobile developer, while testing his skills using the Watson APIs and Node-RED. He is definitely in.
The helmsman takes the lead
Declan’s expertise around boats is more than a hobby, it’s a passion. Although he started out as an electrician, Declan has lived his entire life around boats and the sea. Software development is his second love. The opportunity to combine his passion for the sea with his skills as a software developer means he can make a huge impact on something not only central to him, but vital to the whole Galway community.
Earlier in 2016, Declan spotted an opportunity for improved risk management, information and efficiency for the RNLI Galway lifeboats during an emergency. The Galway station is never manned; every volunteer wears a pager. Galway is unique in that it is a city-based station, rather than coastal. As an urban station, during peak periods or weekends, finding the way to the station can be a challenge.
As Declan explains: “In the Galway Lifeboat Station, we have a lot of new parents. With kids, situations can change – with the volunteer being available one minute, and not available the next. The whole schedule is based on availability – who is around, who is not around, and who can make it. To add to it, Galway is a small, medieval city with roads which are quite tight in certain spots. There’s a river that cuts the city into the east and west side – with crew living on both the east and west side. One time it could take 5 minutes to arrive; the next call out, it’s gridlock. At times, it can take a lot of maneuvering to get to the station.”
The crew are civilians who are not covered by specialised insurance. While driving to the station they have to adhere to traffic regulations and speed restrictions – there are no emergency lights or sirens on the dashboard. As a team of volunteers, the Galway volunteer lifeboat crew work as fireman, nurses, public and private sector workers, many of whom have young families and responsibilities which could take them out of the area or make them unavailable unexpectedly. It’s very fluid, with things changing at the drop of a hat. The current process is too unpredictable.
Tracking crew and skills availability
Every station has a lifeboat operation manager who acts as the launch manager or authority. The sequence of events is, first: he or she is contacted by the Coast Guard requesting the boat launch. Then the operation manager authorizes the setting off of the pagers. Once the pagers go off, the available volunteers will head to the station. For a boat to go out to sea, it needs three crew and a helm. In a pinch, a boat can be launched with only two crew, but a helmsman is always required. In addition to the boat crew, there are shore crew to be considered.
The current system of managing volunteer availability is email based, where every Friday each volunteer makes a note of their availability. The process is clunky and unreliable. Declan recognizes an opportunity – he has access to the right tools and resources within IBM to solve his station’s scheduling issue. To address the peak-period and weekend scheduling issue, Declan initially starts to develop an application within Java, then changes to Node-RED, Angular, and IBM Bluemix. But, after only a few discussions with the newly rallied team, they identify another big issue with the station, specifically the lack of visibility into which volunteers are responding, where they are located, and what their ETA is.
Augmenting a fail-safe system to achieve a better outcome
The existing alert method using the universal pager system sends out a basic text message with minimal information. In some instances, a further message might be sent to provide clarity about the call, saying ‘Boat on rocks near Ballyvaughan’ or, ‘Person in water’ or, ‘Kayaker over.’ The messaging system is designed as the Shout – it’s not designed to relay any additional information back to the operation manager. In between the time the pagers are activated and when the volunteers arrive at the station, the operation manager has no visibility into who is coming or what the estimated time of arrival will be for any of the volunteers. In turn, this means the helmsman has no insight into who is responding, and what skill set is going to be on hand. Using a mobile phone to call the volunteers, or for volunteers to call the station is not a viable solution – people are driving, it’s dark, adrenaline levels are elevated.
Addressing the knowledge black hole
The time between the activation and the arrival is a black hole of knowledge and information. It is here where the second part of the application drops in place to radically improve the efficiency of the call of service. With the new mobile app, each alerted volunteer now has the ability to respond Yes or No – it’s a simple two button choice – either ‘Yes I’m on the way,’ or, ‘No, I’m not available.’ As soon as the button is clicked to say a volunteer is on the way, that individual’s location shows up on a map on the operation manager’s phone, providing visibility into who is en route, and, more importantly, what skills they can offer. For the helmsman, this means the conformations of the crew can be assessed during what might previously have been dead time.
Estimating crew skills and ETA
The primary benefit of having first responder visibility is understanding exactly what skills are on their way, and when the individual with those skills will arrive. Within the Galway crew only a percentage of crew are first aid trained. In some instances, a call might require a stronger crew with a first aid trained volunteer on board. In other instances, if it’s a motorized boat broken down, the helmsman needs someone with skills to repair a diesel engine; or, in the case of a disabled sailor, a helmsman may want a competent sailor on board to assist bringing the vessel into port.
For the operation manager and helmsman, having the information about the potential crew in advance is the key to delivering a better service, faster. If a helmsman knows an essential resource is on the way with an ETA of 60 seconds, the launch can be delayed the extra minute, rather than letting the first four-person crew go out without that critical skill. By delaying the boat, the helmsman puts the best crew in the best position to execute the service. For the casualty, it’s probably going to lead to a better outcome.
A simple, fit for purpose solution
From the crew’s perspective, the most important criteria for a useful solution is keep it simple. True to form, the team is sticking to a simple phone app which includes a set of basic notifications that feed into what the team is calling a Node-RED cognitive engine. The dash collects the data from all the crew’s phones, determines who is available while receiving their location. The information is fed into a cloud-based database, and back to a dash where a number different metrics are calculated and used by the launch authority. There’s also a visual queue which highlights the skills that each crew member possesses. The visual queue helps the helmsman because as the crew arrives at the station, he or she can already be making informed decisions about who’s on the boat based on the data on the map. All of this of course is in real-time using the cloud. The new solution augments a tried and true pager system which the RNLI already has in place; the mobile app offers the visibility and insight into crew availability, skills and ETA.
Speed, scale, security are essential
Originally, the first prototypes of the app just sent hasty, message-based requests back and forth from the phones, updating the database directly. However, because there was a large amount of data being sent insecurely, the teams opted to use Watson IoT Platform. Watson IoT Platform can send smaller, to the point messages with very little information – for example the volunteers’ location, availability and the corresponding RNLI crew ID. In addition, the Node-RED visual programming environment makes it easy to add new functionality quickly.
One handy feature of the mobile app is the ability to alert everyone when the boat has launched. What this means is that everyone who received and responded ‘yes’ to the shout is subsequently sent an audible notification via their phone that lets them know the boat has actually launched. For anyone driving in, this trigger alert relieves the pressure of having to rush – most of the team will come into the station anyway, but it reduces the stress on the volunteers so they can relax a bit.
Paring down a vital application so it’s fit for purpose
Developers are often asked, or tempted, to include cool features and attributes which may never be used in practice. While working on developing the emergency first responder application, the team debated the inclusion of different features – things like the best route to the station. The proximity to Declan as the ‘user’ of the app was critical to getting a fit for purpose prototype in place quickly. When a volunteer gets up in the middle of the night – all they can do is read the phone quickly, press a button and go. Declan challenged the team to constantly return to one simple question: Are you available or not? While other features might appear worthwhile, the development team needs to be ruthless when considering how any suggested feature will contribute to solving the problem on the table.
Settling on the use cases and personas was made all the easier with Brian’s artistic nature. Channelling IBM’s design thinking, the team iterated through many different storyboards describing the core issues during a first responder call out. Brian captured the final storyboard as an animation which was used to drive the generation of wireframes for each of the applications.
However, being circumspect about which features to include in the first phase doesn’t mean that as the application is refined there won’t be additional functionality, which would assist the lifeboat volunteers at the local level; or, enable the aggregation of data and information at a macro level for the broader RNLI organization to use. In future, the team intend to leverage more of the Watson IoT APIs and services – including the aggregation of multiple service call ETAs, and time to launch. As an example, in phase 2 of the project, the team will bring historical analysis into the application, as well as an algorithm that calculates skills, weighing them up against time, while triangulating against the newer Watson APIs for geolocation and geo-fencing. Another area of potential collaboration might incorporate real time data about weather, tide and wind patterns. The inclusion of this kind of contextual information might then be used to help predict where a person or vessel in the water ends up.
Peeling back the onion: How does the solution work?
There are four primary applications the team created which include,
- Crew Phone Application
- Crew Availability
- RNLI Shout Engine
- Launch Authority Dashboard
Each of the applications are hosted on IBM Bluemix as individual applications but are connected in a micro-services eco-system. Node-RED is the glue that holds the applications together. Node-RED is a tool for wiring together hardware devices, APIs and online services in new and interesting ways. For the guys it was ideal to read data from the crew phone app, process it using IBM Watson services and pass it through to the launch authority dashboard.
The architecture is designed so that as more lifeboat stations decide to adopt the tool, these instances can be quickly modified and scaled per station.
PhoneGap (or Cordova) gives the team native hooks into the hardware for each mobile platforms such as GPS, Notifications and Phone ringer.
When the crew gets a notification on their phone and marks themselves as available, the phone app quickly starts sending MQTT to the Watson IoT Platform. From here the RNLI Shout engine on Node-RED takes over and starts doing the backend work.
Figure 4: Emergency first responder solution architecture diagram
To notify the crew of a boat launch, there’s IBM Push Notifications: a service developers can use to send notifications to iOS and Android mobile devices, Google Chrome and Mozilla Firefox web browsers, as well as Google Chrome Apps and Extensions. The notification that ‘boat is launched’ can be targeted to all application users or to a specific set of users and devices using meta tags associated with each station.
The team plans to make the source code available as templates or repositories allowing anyone with a Bluemix account to deploy a similar suite of applications for first responders. Please stay tuned for more information about when the source code will be available.
Please contact the development team about the first responder emergency services application if you have questions.
Declan Killilea, Software Developer, IBM Security
Shane Lynch, Software Engineer, IBM Cloud
Eoin Jordan, Software Engineer, IBM Cloud
Brian Campion, ID Manager
IBM Watson IoT Platform hits the ground running with a first responder on-scene application using Node-RED.
Need identified for improved risk management, information and efficiency for RNLI Galway lifeboats during an emergency.
Problem 1: Launch Authority
RNLI Launch Authority makes a “shout” to notify volunteer crew members to get to Station to launch boat. Launch Authority lacks the information needed to efficiently identify:
1. Crew and Skills Availability
- A minimum number of crew are needed
- Specialised skills are required to launch e.g. Helmsman, Crew, First Aid
- Crew Experience plays a factor
2. Crew Location
- What is the current position of the crew
- Are the crew within range of the station and typical launch time
3. ETA to Boat Launch
Current option: Launch authority is to phone the individual members to confirm availability and to guess an ETA.
Problem 2: Crew
- RNLI Crew have no capability to indicate they are responding to the Shout
- RNLI Crew are focused on getting to the station but have no way to know if the boat has already launched
Current option: Crew is to phone the Launch Authority with Availability and guess ETA
How Watson IoT Platform and Node-RED solve these problems
Location tracking and actual availability using Watson IoT Platform:
- Cross-platform Mobile first application that shows crew location and skill profile
- Travel boundary polygon calculated showing crew ETA to station
ETA information calculated via Node-RED Business flow:
- Delivers information to launch authority that the minimum crew requirements for boat launch
- Configurable as each station/boat has different requirements
IBM push notification when boat launched for crew:
- Audible notification for RNLI crew (still making way to station) to know successful boat launch
Scheduling of availability during peak hours:
- For peak periods crew can indicate their availability so Launch Authority can see gaps in cover
Predictive Routing for Crew members:
- Historical Analytics and Weather Channel API can feed into predictive model for routing to station
Search Area Prediction:
- Utilising SmartBay in conjunction with Watson Predictive data from sensors already deployed in Galway Bay to reduce search times
- Increased accuracy for Search and Rescue (SAR)
First Aid Check Cards:
- Potential to use Watson Health to aid in casualty symptom analysis while at sea
- Automated report service based on shout
- Needs weather, search area, launch times, crew response times