描述

安全是我們的首要任務。在美國，每座商業(yè)寫字樓都配備了煙霧探測器、火災報警器和灑水裝置。當火警響起時，大樓租戶應立即撤離大樓；如果出現(xiàn)龍卷風等惡劣天氣，火警系統(tǒng)會指示大樓租戶前往地下室“就地避難”。

時不時地，有些人會無法撤離建筑物或無法前往就地避難地點。原因包括：

• 行動不便人員的輪椅發(fā)生故障。
• 醫(yī)療緊急情況會導致人失去知覺。
• 有人認為警報“只是另一次演習”，并留在辦公室完成那個電話。

消防員接受過“清理”建筑物的培訓。他們將進入每個房間并確認沒有人在里面。然而，這個過程通常需要5~10分鐘，期間困在里面的人情況可能會惡化。

技術可以提供幫助。在我的設計中，每個房間都有一個傳感器報告里面是否有人，消防員可以使用這些信息來確定進入這些房間的優(yōu)先順序。

消防員視角模型

?

此屏幕說明了消防員可能從系統(tǒng)中看到的內容。共有三個房間，但傳感器讀數(shù)顯示房間 1 更有可能有人，因此消防員應首先進入房間 1。

介紹 D6T

安裝在燈下的 D6T 傳感器

?

我的設計使用 D6T 傳感器來檢測人的存在。D6T 是一款 MEMS 熱傳感器。D6T 可以將它前面的區(qū)域“看”為 16 個像素的 4x4 網格，并測量每個像素的溫度。D6T 在傳感器內部還有一個參考溫度傳感器。由于人體的溫度高于環(huán)境溫度，當某些像素點的溫度讀數(shù)高于參考溫度時，表明可能存在人體。

許多現(xiàn)有應用程序（例如防盜警報器）使用 PIR 傳感器來檢測人員的存在。與PIR相比，D6T有一個獨特的優(yōu)勢：D6T能夠檢測靜止的人員，而PIR只能檢測運動。此屬性在建筑物疏散應用中很重要，因為那些未能疏散建筑物的人可能不會移動。

設備

連接到 Azure Sphere 板的 D6T 傳感器

?

該設備由 Azure Sphere MT3620 板和 D6T 傳感器組成。D6T是一個使用5V供電和邏輯電平的I2C傳感器設備；正如我測試的那樣，它在 3.3V 電壓下無法正常工作。因此，需要一個電平轉換器來連接 Azure Sphere 的 mikro BUS 1 和 D6T 傳感器之間的 SDA 和 SCL 線。

為了便于測試，我還將加載了“WiFiTelnetToSerial”示例固件的 ESP8266 連接到 Azure Sphere 的 mikro BUS 2 上的串行線路，以便我能夠通過 telnet 無線讀取調試消息。

在軟件方面，我嘗試了 Visual Studio 一段時間，但認為PlatformIO是更好的選擇，因為它提供了更高級別的 API，使我能夠更多地關注業(yè)務邏輯而不是低級別的細節(jié)。程序邏輯很簡單：

• 連接到 Azure IoT Central。
• 讀取 D6T 傳感器，計算有多少像素“熱”（溫度高于參考溫度），并將其報告給 Azure IoT Central。

在軟件開發(fā)期間，我必須為 Azure IoT Central 連接和讀取 D6T 傳感器構建 Arduino 庫。

云端

Azure Sphere 可以連接到 Azure IoT HUB 或 Azure IoT Central。我擲硬幣決定使用 Azure IoT Central。

Azure IoT Central，設備模板設置

?

Azure IoT Central 上的設置過程包括：

• 啟用“現(xiàn)收現(xiàn)付”計劃計費，并創(chuàng)建 Azure IoT Central。
• 創(chuàng)建一個名為“疏散”的設備模板。
• 創(chuàng)建一個名為“hot”的 Telemetry，最小值為 0，最大值為 16，小數(shù)位數(shù)為 0。
• 使用模板創(chuàng)建設備“room 1”。
• 為設備生成連接字符串，并將其編程到設備中。
• 創(chuàng)建一個儀表板，使用 Last Known Value 元素顯示每個傳感器的熱點數(shù)。

Azure IoT Central，儀表板設置

?

在完成這些設置并連接傳感器后，我們可以在儀表板上看到傳感器讀數(shù)：

?

當需要疏散建筑物時，消防員可以打開儀表板查看哪些房間的讀數(shù)非零。非零讀數(shù)表示有人可能在該房間內，因此他們可以優(yōu)先訪問該房間。

運營成本

使用一個傳感器一個月時我的 Azure 發(fā)票

?

Azure IoT Central 每臺設備收費 2 美元，每百萬條消息收費 5 美元，免費套餐包含 5 臺設備和每臺設備 50000 條消息。為了保持在免費套餐內，傳感器每 52 秒只能發(fā)送一個讀數(shù)，這對于分秒必爭的安全應用來說是不夠的。目前，我的程序每秒發(fā)送一個讀數(shù)。一棟擁有 100 個房間的大樓的運營成本為每月 1461 美元，如果它可以挽救一條生命并避免訴訟，那么這個成本并不高。

可以通過兩種方式降低成本：

• 稍微減少發(fā)送間隔。每 5 秒發(fā)送一次讀數(shù)可將 100 個房間的運營成本降低至每月 449 美元。
• 按需報告。傳感器可以保持連接狀態(tài)，而不是定期發(fā)送傳感器讀數(shù)，但僅在收到指示疏散正在進行的信號后才開始發(fā)送 D6T 讀數(shù)。這會將成本進一步降低至每月 190 美元（連接 100 臺設備的基本成本）。然而，這種方法需要與火災報警系統(tǒng)集成，這可能存在監(jiān)管障礙。

操作測試

我在我的公寓里測試了這個系統(tǒng)。我發(fā)現(xiàn) D6T 可以有效地檢測到我的存在，但前提是燈亮著。如果房間完全黑暗，D6T 就看不到我。因此，該方案對于商業(yè)樓宇，在房間有人時開著辦公燈是有用的，但對于居民睡覺時可能會關燈的住宅樓宇來說是無效的。

如果我將一杯熱茶放在 D6T 傳感器前面，就會出現(xiàn)誤報。然而，這在實際部署中并不是主要問題：當傳感器安裝在墻上時，熱茶杯只能觸發(fā)一個像素。消防員可以首先對熱像素數(shù)量較多的房間作出反應，因為較高的數(shù)字表明那里很可能有人。

出于安全原因，我無法在建筑物實際著火時測試系統(tǒng)的有效性。

結論

我開發(fā)了一種傳感器設備來協(xié)助建筑物疏散。它可以告訴消防員哪些房間內可能還有人，讓他們在清理建筑物時優(yōu)先進入這些房間。