應急指揮排程的應用場景有許多，如：消防指揮排程、交通指揮排程、應急救援等等。每個場景對功能的需求也略不相同，但是平臺設計都有一個參照標準《根據國家應急平臺體系技術要求》，以應急通訊、應急處置為核心，預案數字化和應急分析為依據；系統設計遵循“平急結合，講求實效”、“統籌規劃，統一標準”、“分級實施，資源共享”、“技術先進，智慧靈活”四大原則理念；

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/c6ed6058da71417bbb4ff86b1cd5c4ad.png#pic_center)

應急指揮排程平臺大多包含了以下的**系統功能**：

- **靈活分組管理**。根據內部組織架構或事件關聯人，可在排程臺上對成員進行快速分組，建立固定頻道和臨時會話，隨時選擇對應頻道/會話發起音影片呼叫、影片監看、地圖位置查詢等操作；
- **無線叢集**。實現無線電臺、網路電話、PSTN網路、智慧手機、影片監控平臺等音影片系統的**語音排程、音影片群呼、廣播排程、實時語音排程**。
- **支援多級協同排程**。提供上下級排程平臺的許可權分配及管理，可動態分配人員許可權，滿足分等級、分許可權、多級指揮排程的需求。
- **GIS 基礎模組**。具有檢視終端使用者的地圖位置、設定自定義地圖示註、地圖基礎工具包。
- **GIS 排程模組**。具有畫圈成組，對圈中的終端使用者進行呼叫、強插、強拆、影片監看、群呼等操作。
- **實時語音對講**。實時公網對講，支援低延時、高併發、AI 降噪能力，支援群組/點對點。
- **實時影片**。影片加密傳輸、支援檢視終端使用者上報的實時影片、實時監看終端使用者影片、具有大屏呈現能力。
- **事件備案**。支援影片監看、音影片錄製、抓拍、支援影片分享、呼叫、群呼入會等操作。
- **裝置繫結**。實現帳號與裝置繫結，後臺支援裝置搖斃、搖停等操作。
- **多媒體/實時影片上報**。檢視終端實時上傳的多媒體資訊，根據上報事件的類別，排程員協調處理事件。
- **IM 模組**。支援文字、影片、語音、圖片、地圖位置等訊息型別。
- **等等**

具體平臺需要哪些功能取決於平臺的需求了，下面我們就以排程平臺的**實時對講**、**實時影片**、**IM/信令**核心功能模組為例，講解一下核心功能需要哪些技術支援？

##  **實時語音對講**

首先，我們講講指揮排程中必不可少的對講，再過去對講幾乎都是使用的無線訊號的對講機，由於訊號不穩定、使用有距離限制等等，慢慢的由**公網對講**技術所取代。儘管如此，在選擇公網對講時我們需要考慮的因素也有許多：

- **語音是否支援加密傳輸**。語音內容是否易截獲。
- **實時性是否有保障**。是否支援 WebRTC。
- **是否支援弱網通訊**。在網路訊號不好時，抗丟包能力強不強。
  這些都是選擇**語音對講方案**的效能指標。

在有了技術選擇的效能指標、我們還需要支援：**強插**，**強拆**，這也就意味這，對講還需要有**對講等級**，等級高的可以打斷等級低的使用者。

同時，我們還需要對對講語音進行**錄音備案**，將錄製的語音上傳伺服器，也可以將其作為一條語音訊息傳送到指定的群組，以便記錄、防止訊息丟失。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/7c77c576189e413984fbc919767df9fe.png#pic_center)

## 音影片呼叫

在應急指揮排程中，面對突發事件，我們可以選擇事件關聯人或者選擇行動分隊等前線人員，同時也可以邀請技術專家快速發起的音影片呼叫、對技術難題進行專項討論分析並制定處理方案，從而大幅提高了應對突發事件的處理效率。

也就是說，在選擇音影片呼叫解決方案時，我們需要從這幾個方面考慮：

- 是否支援**點對點**發起音影片呼叫
- 是否支援**一對多**發起音影片呼叫
- 是否支援**影片錄製**
- 是否支援**音/影片開關**
- 是否支援**檢視遠端使用者的音影片狀態**
- 支援**影片轉音訊**。（這裡作為加分項）

上面介紹的這些需求包含了大多數應用場景，從平臺的角度看，放佛沒有任何問題，但是從程式的角度來看，耦合度太高，那麼站在程式的角度，我們可以將以上方案拆分成兩個方案：

### 一套呼叫邀請流程（非音影片呼叫）
我們可以使用 IM 或者信令封裝一套呼叫流程，用於協助音影片通訊，在邀請發起到對方應答或者超時視為一次完整的生命週期，每次呼叫邀請只能使用一次，對方響應或者超時既毀。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/4e5f46d1c51840d08870820872234942.png#pic_center)

### 一套音影片通訊方案

在應急指揮排程平臺中，音影片通訊能力必須具備實時能力，在直播時代還未崛起之時，RTMP 作為主流的實時通訊協議，熱度居高不下，直到 WebRTC 技術的崛起與應用，已然成為了實時通訊的首選。由於 WebRTC 只支援 P2P 通訊，為了讓 WebRTC 支援多人通訊，WebRTC 也衍生出了三種：**MCU**、**SFU**、**Mesh**技術架構，其中 **SFU** 對網路頻寬的限制以及對機器效能的要求最低，因此大受追捧。（至於這三大架構的利弊，本處不做過多闡述，感興趣的同學可以自行查詢。）

在選擇音影片通訊方案的時候，我們需要考慮：

- **低延時**。對比實時效果是否達到預期
- **影片解析度是否可以調整**。根據不同對應用場景，對實時影片的解析度要求各不相同，比如在看人員時，可以檢視該使用者小流，大屏顯示時檢視使用者大流。
- **音影片開關**。在特殊負責的環境下，考慮到音影片是否要停止傳輸等。
- **硬體要求**。軟體或者服務對硬體的要求是否在預算之內。
- **房間人數是否滿足需求**。一個會議中可以多少人進行互動、允許多少人參與？
- **服務叢集是否滿足需求**。服務是否地域覆蓋，是否支援動態擴容等等？

## IM / 信令服務

IM 想必大家都很熟悉了，除了支援文字、圖片、影片、音訊等型別以外，我們還可以自定義一些訊息型別，大多時候我們自定義訊息型別時都是方便業務的串聯，因此上面我們提到的呼叫要求流程，也可以封裝在其中。

在選擇通訊方案的時候，我們需要考慮：

- **低延時**
- 是否支援**點對點訊息**、**頻道訊息**
- **服務叢集是否滿足需求**。服務是否地域覆蓋，是否支援動態擴容等等？
- **呼叫邀請流程**。是否內建呼叫邀請流程？或者是否支援封裝一套呼叫邀請流程?

## GIS 地圖

關於地圖可以做的事情有很多了，常見的有：

- **實時定位**。檢視線上終端使用者的地理位置，或者離線使用者最後一次的地理位置。
- **自定義標註**。在地圖上新增一下自定義標註，例如：醫院、學校、消防栓等等。
- **自定義工具**：測距、面積
- **自定義圖層**：衛星地圖、路網、3D、地圖的主題等

進階的有：

- **電子圍欄**。使用圓圈或者自定義形狀繪製一塊區域，該地區人員進出會發出警報。
- **軌跡回放**。客戶端定時上報地理逆編碼位置以及經緯度，排程臺按規矩還原出來。
- **畫圈成組**。使用圓圈或者自定義形狀繪製一塊區域，然後將該區域的人員選中並建立臨時群組，或者進行群呼。

這裡常用的有高德、百度地圖、特定需求的還可以選擇北斗。

## 總結

除了上面介紹的技術支撐，我們還需要提供一個強有力、安全可靠的服務，它基本需要具備：

- **叢集部署、動態擴容**
- **服務可靠**，服務需要具備**熱備、容災**能力，以保證平臺穩定性
- **實效性**（實時），《根據國家應急平臺體系技術要求》參照標準，發揮排程平臺實效性，及時響應複雜突發急事件
- **靈活性**，各個模組相互獨立，方便業務擴充，要求程式碼耦合度低
- **事件存檔**，需要對突發事件或日常事件進行備案記錄，保證排程臺事件可溯性，方便後期工作分析

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/32d8d97cf2fc493cbc65f413607cd1bd.jpeg#pic_center)

技術分享| 應急指揮排程平臺需要這些技術支撐

相關文章