Where was technology helpful and where did it fail in this scenario?
Helpful:
- The fire alarm was technology that worked and did what it should have when it properly detected combustion by byproducts. It was loud enough we all knew about it and it did its job well.
- The Fire Department was automatically dispatched and building management knew where the fire was from the fire detection system. That's technology doing what it needs to.
- The Fire Department arrives in a timely manner. That's partly about conditions outside, but it also includes their ability to operate all weather, to route dynamically around traffic issues, and staffing levels. One way or another, as a system, they arrive pretty quickly to situations and technology plays many roles in enabling that.
Less Helpful:
- 28 floors down on foot in a cramped staircase. A bit of exercise for me which I need, but for many older occupants, risky, slow and even damaging if they have compromised immunity or mobility. Technology isn't solving this problem at my apartment today.
- The fire cause: Stoves have no automated shut-off on the burners or the oven, no timers, and don't have any ability to detect smoke and burning. In these respects, the stove seems largely mired in the last century.
- Apartment buildings keep lists of those who need evacuation help. They are paper lists. They do give the Firefighters something to work with, but they aren't terribly efficient.
Ways In Which Technology Could Improve Similar Situations:
- Stove Heat/Smoke/Fire Detection and Alerting
Stoves could integrate thermal sensors and smoke sensors. They could also detect persons nearby. If something is on fire on the stove, it might be a flambe, but if so there should be somebody in front of the stove and managing it.
If a pot on the stove reaches a particular temperature, that could cause an alarm. Limiting the destructive melting of pots and de-laminating of unhealthy non-stick surfacing would be a benefit of that as well as its safety benefits. - Connect the Stove!
The stove, as part of the Internet of Things, could also become a first line of notification for emergency response, for owners, cooks and house occupants (even if they'd left and were outside in the yard or just leaving the parking lot). The stove could broadcast its alerts. - Thermal Limiting, Timers And Shutoffs
Stoves could be modified to limit how hot and how long stove-top elements may operate (and, before you cooks get all up in arms, that could be configurable or at least over-ridden but perhaps only in conjunction with the person-detection I had suggested above.
If you could configure the limits, you could perhaps set one element never to exceed 325 F so as to protect some non-stick pots you have with limited ability to withstand heat before the coating is damaged and/or emits some nasty byproducts.
There could be maximum on-time timers for the stove-top burners (an oven has a timer - why not a stove?). They could be over-ridden or extended but make it manual so somebody has to be aware and thus likely will monitor the situation.
We could probably evolve models of fast-heating and other sorts of cooking that would allow us to establish profiles and some would come with true limits and others with advisory warnings (sounds, broadcast alerts) when certain times or temperatures or time-at-temperatures were being exceeded.
This would serve as both a cooking aid (save your fragile pans, save your food from burning) and as a protective technology to prevent fires with all they entail. - Electronic, Mobile Data For Assisted Evacuation
Image if the list was administered via a website and a printout of the result could be kept by the building management. Thus you end up with the same amount of work for the superintendent (add new record, remove old record) but the data is then available to the FD ahead of time when they arrive.
This has implications because if it is coupled with alarm systems that could notify the FD of where the fire is (ideally integrated with one another), the FD could arrive with a list of the most immediately threatened occupants that need help evacuating.
Taking it one step further, FDs have evacuation plans for some buildings (most key large buildings they'd like to have this info for). PDs maintain this in the form of tactical plans. If all large building had to work with all 3 services (police, fire, ambulance) and maintain updated plans as details change, this would mean police, firefighters and EMS techs could could arrive with a floor plan (ideally) and good data visualization on portable devices and at scene command.
Add to this the possibility to integrate that with real-time location of your emergency responders to assist in coordination and enhance safety and you'd have a powerful tool for all 3 emergency services.
In the worst case, you could share this data with other agencies (medical or NBCR contamination containment units or even counter-terrorism specialists).
Technology Deployment And Adoption Notes
The lowest and easiest level here is an online place where these evacuation lists are kept and where the local FD gets an updated record that they can have available to them when they dispatch. That's likely not too onerous, could be piloted on a small scale for reasonable $$$, and could show the possible benefits of broader use.
You have to let people absorb systemic change and enhancement in smaller chunks. It makes the change less of a shock and limits defensive resistance. People might not love a small change, but they rarely polarize around opposing it. A whole pile of small changes or a bunch of big and small changes in a massive package at once can trigger a lasting intransigence to change that can be hard to uproot.
Technology Development Maxim 1: It is easier to convince people to adapt to and adopt a small change than a big one. Incremental change is good.
It also happens that if people see the benefit of the change, they'll be more receptive to the next incremental step. It also means they may start, in the best case, to become advocates and champions for future changes.
From a development perspective, it also shows us dead-ends earlier and things which are not meeting users' needs. That lets us not spend time and money building things that aren't optimally useful. MANY software system developers have ignored this truth to their product's detriment and to the users' collective misery.
No comments:
Post a Comment