謝海嘯，邱 建，余暉良，馬慶賀

（北京奧特維科技有限公司，北京 100010）

1 引言

城市運(yùn)管指揮中心是一個(gè)整合交通、公安、水利、環(huán)保、城管以及氣象等委辦局業(yè)務(wù)和信息，通過(guò)大數(shù)據(jù)分析、云計(jì)算等技術(shù)，建立城市統(tǒng)一運(yùn)行監(jiān)控體系，統(tǒng)一事件綜合協(xié)調(diào)平臺(tái)，全面提升城市綜合管理水平和應(yīng)急處置效率的治理一體化解決方案。中心需要接入多個(gè)不同保密等級(jí)的網(wǎng)絡(luò)，融合多個(gè)不同部門的各類數(shù)據(jù)，承載入駐的多個(gè)不同部門業(yè)務(wù)的值班人員，具備視頻顯示、圖像傳輸、音頻擴(kuò)聲、融合通信及安防、照明等多個(gè)信息化系統(tǒng)，提供7×24 h 不間斷運(yùn)行服務(wù)，為領(lǐng)導(dǎo)及時(shí)、高效地指揮決策提供保障。

如此龐大、復(fù)雜的系統(tǒng)，它的管理和運(yùn)維將極其煩瑣。傳統(tǒng)做法是為每個(gè)子系統(tǒng)部署獨(dú)立的管理軟件，每個(gè)子系統(tǒng)由專人負(fù)責(zé)，各子系統(tǒng)的數(shù)據(jù)相互獨(dú)立?；蛘卟捎眉锌刂葡到y(tǒng)實(shí)現(xiàn)對(duì)多媒體設(shè)備的集中管理，但無(wú)法實(shí)現(xiàn)設(shè)備運(yùn)行狀態(tài)監(jiān)測(cè)和故障定位功能，定位故障和解決故障時(shí)間長(zhǎng)，且對(duì)運(yùn)維人員要求較高，無(wú)法滿足7×24 h 不間斷運(yùn)行的要求。因此，為指揮大廳部署一套可視一體化運(yùn)維管控平臺(tái)尤為重要。

隨著云計(jì)算、人工智能和物聯(lián)網(wǎng)的快速發(fā)展，人臉識(shí)別技術(shù)、語(yǔ)音識(shí)別技術(shù)和物聯(lián)網(wǎng)技術(shù)已經(jīng)相對(duì)成熟，同時(shí)通過(guò)云計(jì)算對(duì)傳統(tǒng)行業(yè)的賦能，能夠?qū)芏鄠鹘y(tǒng)產(chǎn)業(yè)的提升提供較大的推動(dòng)力。

對(duì)于指揮大廳而言，一方面物聯(lián)網(wǎng)技術(shù)將傳統(tǒng)音視頻設(shè)備接入物聯(lián)網(wǎng)，實(shí)現(xiàn)設(shè)備互聯(lián)，增強(qiáng)感知能力，提高系統(tǒng)可用性和可維護(hù)性，使得集中管理成千上萬(wàn)的音視頻設(shè)備成為可能；另一方面，通過(guò)人工智能和云計(jì)算技術(shù)對(duì)指揮大廳進(jìn)行賦能，使得其成為具備AI 能力、能感知以及可通過(guò)語(yǔ)言交流的智慧系統(tǒng)。

因此，需要部署一套能夠解決上述問(wèn)題的可視一體化管控平臺(tái)，不僅能統(tǒng)一管理整個(gè)指揮大廳各子系統(tǒng)，還能發(fā)現(xiàn)問(wèn)題并輔助解決問(wèn)題，提高指揮大廳長(zhǎng)期運(yùn)行的穩(wěn)定性。

可視一體化管控平臺(tái)通過(guò)物聯(lián)網(wǎng)監(jiān)測(cè)所有子系統(tǒng)設(shè)備的運(yùn)行狀態(tài)（如圖1 所示），并采集存儲(chǔ)形成大數(shù)據(jù)。通過(guò)大數(shù)據(jù)可視化技術(shù)可生成直觀的用戶界面，同時(shí)結(jié)合人臉識(shí)別、語(yǔ)音識(shí)別、云計(jì)算等人工智能技術(shù)，為指揮大廳提供更加人性化的功能。例如：通過(guò)人臉識(shí)別實(shí)現(xiàn)登錄KVM 坐席調(diào)度系統(tǒng)、自動(dòng)會(huì)議簽到、門禁和考勤系統(tǒng)；通過(guò)語(yǔ)音指令實(shí)現(xiàn)燈光空調(diào)控制、圖像調(diào)度以及語(yǔ)音轉(zhuǎn)寫等；通過(guò)數(shù)據(jù)分析實(shí)現(xiàn)故障預(yù)警和故障快速定位等功能。

2 系統(tǒng)架構(gòu)

系統(tǒng)架構(gòu)包括基礎(chǔ)設(shè)施層、數(shù)據(jù)層、云計(jì)算支撐層、業(yè)務(wù)層和用戶層，如圖2 所示。

基礎(chǔ)設(shè)施層是指揮大廳信息化的各種基礎(chǔ)設(shè)施，是可視一體化管控平臺(tái)管理和運(yùn)維的主要設(shè)備和設(shè)施，包括音頻擴(kuò)聲、大屏顯示、視頻會(huì)議、KVM分布式高清坐席、融合通信、機(jī)電、照明、坐席計(jì)算、安防、網(wǎng)絡(luò)工程以及機(jī)房工程等子系統(tǒng)。

數(shù)據(jù)層是采集、存儲(chǔ)、計(jì)算和管理數(shù)據(jù)的邏輯層，包括物聯(lián)網(wǎng)平臺(tái)和大數(shù)據(jù)平臺(tái)。其中：物聯(lián)網(wǎng)平臺(tái)主要負(fù)責(zé)采集數(shù)據(jù)和下發(fā)指令，主要支持包括Modbus TCP、Modbus RTU、Backnet、SNMP、Dante音頻以及各種基于TCP/IP 或RS232 的私有協(xié)議；大數(shù)據(jù)平臺(tái)主要負(fù)責(zé)存儲(chǔ)、計(jì)算和管理數(shù)據(jù)。

云計(jì)算支撐層是為可視一體化管控平臺(tái)提供賦能的邏輯層，包括語(yǔ)音識(shí)別引擎、人臉識(shí)別引擎、聲紋識(shí)別引擎、文本翻譯引擎以及業(yè)務(wù)模型庫(kù)等模塊。

業(yè)務(wù)層是可視一體化管控平臺(tái)的主要業(yè)務(wù)邏輯層，包括WEB 服務(wù)器、業(yè)務(wù)處理、數(shù)據(jù)管理、用戶管理以及日志管理等模塊，主要功能包括運(yùn)行狀態(tài)監(jiān)測(cè)、數(shù)據(jù)接入、智能分析研判、快速故障定位、設(shè)備控制和管理功能等。

用戶層是用戶交互層，包括瀏覽器端、APP 端和語(yǔ)音指令端。為了簡(jiǎn)化業(yè)務(wù)層架構(gòu)，用戶層的各種應(yīng)用均通過(guò)HTTP 協(xié)議與業(yè)務(wù)層通信。

3 技術(shù)路線

技術(shù)路線主要從用戶層、業(yè)務(wù)層、云計(jì)算支撐層和數(shù)據(jù)層等方面進(jìn)行闡述。

3.1 用戶層

用戶層包括瀏覽器端、APP 端和語(yǔ)音指令端。為了簡(jiǎn)化業(yè)務(wù)層架構(gòu)，用戶層的各種應(yīng)用均通過(guò)HTTP 協(xié)議與業(yè)務(wù)層通信。

瀏覽器端（也稱前端）開發(fā)框架技術(shù)路線選擇較多。由于開發(fā)團(tuán)隊(duì)專注于JavaScript（以下簡(jiǎn)稱JS）腳本語(yǔ)言，本文主要選擇基于JS 前端框架技術(shù)路線?；贘S 的主流前端框架包括VUE、Angular以及React 等。表1 主要針對(duì)這3 套框架進(jìn)行比較。

表1 瀏覽器前端框架對(duì)比

由于可視一體化運(yùn)維管控平臺(tái)屬于中小型項(xiàng)目，對(duì)比上述3 種框架，根據(jù)團(tuán)隊(duì)實(shí)際情況選擇VUE 作為瀏覽器端的開發(fā)框架。

對(duì)于語(yǔ)音指令前端，由于Python 語(yǔ)音在AI 領(lǐng)域的重要地位，選擇Python 作為主要開發(fā)語(yǔ)言，并針對(duì)部分性能敏感模塊選擇Golang 語(yǔ)言和C++語(yǔ)言編寫。

對(duì)于APP 端，針對(duì)移動(dòng)端平臺(tái)選擇相應(yīng)的開發(fā)語(yǔ)言和相關(guān)框架，不再贅述。

3.2 業(yè)務(wù)層

業(yè)務(wù)層（也稱后端）是可視一體化運(yùn)維管控平臺(tái)的核心層，主要包括Web 服務(wù)器和業(yè)務(wù)邏輯兩大部分，其中業(yè)務(wù)邏輯包括業(yè)務(wù)處理、數(shù)據(jù)管理、用戶管理以及日志管理等模塊。它的主要功能包括運(yùn)行狀態(tài)監(jiān)測(cè)、數(shù)據(jù)接入、智能分析研判、快速故障定位、管理控制和資產(chǎn)管理等。

3.2.1 后端框架選擇

后端開發(fā)框架技術(shù)路線選擇較多。由于開發(fā)團(tuán)隊(duì)專注于JavaScript（以下簡(jiǎn)稱JS）腳本語(yǔ)言，本文主要選擇基于Node.js 后端框架技術(shù)路線。相關(guān)的主流后框架包括Express、Sails 以及Egg 等。表2 主要針對(duì)這3 套框架進(jìn)行比較。

表2 后端框架對(duì)比

由于可視一體化運(yùn)維管控平臺(tái)屬于中小型項(xiàng)目，對(duì)比上述3 種框架，根據(jù)團(tuán)隊(duì)實(shí)際情況，選擇Egg 作為后端的開發(fā)框架。

3.2.2 Web 服務(wù)器選擇

由于后端選擇了Egg 作為開發(fā)框架，因此不使用Web 服務(wù)器系統(tǒng)也能正常工作。只是為了高并發(fā)性能，需要選擇一個(gè)Web 服務(wù)器。針對(duì)這個(gè)需求，選擇Nginx 作為Web 服務(wù)器。Nginx 是一個(gè)高性能的HTTP 和反向代理服務(wù)器，性能穩(wěn)定，系統(tǒng)資源消耗低，能夠支持高達(dá)50 000 個(gè)并發(fā)連接數(shù)。

3.3 云計(jì)算支撐層

云計(jì)算支撐層包括語(yǔ)音識(shí)別引擎、人臉識(shí)別引擎和文本翻譯引擎等。由于主流語(yǔ)音識(shí)別引擎在普通話識(shí)別率均能達(dá)到95%以上，因此選擇中電慧聲語(yǔ)音識(shí)別引擎（它在項(xiàng)目實(shí)際應(yīng)用中表現(xiàn)良好）。此外，基于同樣的原因，人臉識(shí)別引擎和文本翻譯引擎均選擇市場(chǎng)主流產(chǎn)品。

3.4 數(shù)據(jù)層

數(shù)據(jù)層包括物聯(lián)網(wǎng)平臺(tái)和大數(shù)據(jù)平臺(tái)。其中，大數(shù)據(jù)平臺(tái)選擇市場(chǎng)主流產(chǎn)品。由于物聯(lián)網(wǎng)平臺(tái)是可視一體化運(yùn)維管控平臺(tái)的關(guān)鍵模塊，且運(yùn)維對(duì)象主要是音視頻系統(tǒng)設(shè)備，很多設(shè)備不能提供標(biāo)準(zhǔn)的協(xié)議和接口，與很多流行的物聯(lián)網(wǎng)平臺(tái)兼容性不佳，所以選擇自主開發(fā)物聯(lián)網(wǎng)平臺(tái)。

物聯(lián)網(wǎng)平臺(tái)功能包括數(shù)據(jù)采集和指令下發(fā)等功能，需要支持的接口、協(xié)議見表3。

由于需要和底層設(shè)備交互且對(duì)性能要求較高，物聯(lián)網(wǎng)平臺(tái)選擇C/C++作為主要的開發(fā)語(yǔ)言。

4 重點(diǎn)難點(diǎn)分析

重點(diǎn)難點(diǎn)分析將從快速故障追蹤和定位、故障預(yù)警分析、坐席計(jì)算機(jī)運(yùn)維、提高語(yǔ)音指令識(shí)別率和人臉識(shí)別應(yīng)用等方面進(jìn)行闡述。

表3 物聯(lián)網(wǎng)平臺(tái)支持的協(xié)議一覽表

4.1 快速故障追蹤和定位

快速故障追蹤和定位主要由一套故障報(bào)警處理流程和相關(guān)支撐能力實(shí)現(xiàn)。故障報(bào)警處理流程如圖3 所示。

它為設(shè)備坐標(biāo)信息、電子地圖以及完善故障模型庫(kù)提供支持。其中，故障模型包括故障類型、故障描述、故障影響指數(shù)以及故障處理建議等。下面舉例說(shuō)明快速故障處理流程。

4.1.1 生成告警信息

發(fā)生故障后，系統(tǒng)監(jiān)測(cè)到該故障并自動(dòng)生成告警信息，通知運(yùn)維人員。告警信息列表界面，如圖4 所示。

4.1.2 電子地圖定位

運(yùn)維人員打開告警信息的定位功能，系統(tǒng)會(huì)在電子地圖上顯示故障點(diǎn)位置，從而引導(dǎo)運(yùn)維人員迅速處理故障，界面如圖5 所示。

4.1.3 完成故障處理

故障處理完成后，運(yùn)維人員需要根據(jù)實(shí)際情況填寫故障處理報(bào)告，并關(guān)閉該工單，界面如圖6 所示。

4.2 故障預(yù)警分析

設(shè)備故障預(yù)警和狀態(tài)監(jiān)測(cè)根據(jù)設(shè)備運(yùn)行規(guī)律或觀測(cè)得到的可能性前兆，在設(shè)備真正發(fā)生故障前及時(shí)預(yù)報(bào)設(shè)備的異常狀況，并采取相應(yīng)的措施，從而最大程度地降低設(shè)備故障造成的損失。隨著指揮大廳系統(tǒng)的規(guī)模和復(fù)雜性日益增大，為保證系統(tǒng)安全平穩(wěn)，通過(guò)可靠的狀態(tài)監(jiān)控技術(shù)及時(shí)有效地監(jiān)測(cè)和診斷過(guò)程異常顯得尤為迫切和重要。現(xiàn)有的故障預(yù)警技術(shù)主要分為基于機(jī)理模型的方法、基于知識(shí)的方法和基于數(shù)據(jù)驅(qū)動(dòng)的方法3 大類。

基于機(jī)理模型的方法是發(fā)展最早也最深入的故障預(yù)警和狀態(tài)監(jiān)測(cè)方法，主要包括兩個(gè)階段。第一階段是殘差產(chǎn)生階段，即通過(guò)設(shè)備運(yùn)行機(jī)理建立精確的數(shù)學(xué)模型來(lái)估計(jì)系統(tǒng)輸出，并將之與實(shí)際測(cè)量值比較獲得殘差，這個(gè)階段構(gòu)建的模型又叫殘差產(chǎn)生器。第二階段是殘差評(píng)價(jià)階段，即對(duì)殘差進(jìn)行分析，以確定過(guò)程是否發(fā)生故障，并進(jìn)一步辨識(shí)故障類型。

基于知識(shí)的方法主要以相關(guān)專家和操作人員的啟發(fā)性經(jīng)驗(yàn)知識(shí)為基礎(chǔ)，定性或定量描述過(guò)程中各單元之間的連接關(guān)系、故障傳播模式等，并在設(shè)備出現(xiàn)異常征兆后通過(guò)推理、演繹等方式模擬過(guò)程專家在監(jiān)測(cè)上的推理能力，從而自動(dòng)完成設(shè)備故障預(yù)警和設(shè)備監(jiān)測(cè)。

基于數(shù)據(jù)驅(qū)動(dòng)的方法通過(guò)挖掘過(guò)程數(shù)據(jù)中的內(nèi)在信息建立數(shù)學(xué)模型和表達(dá)過(guò)程狀態(tài)，從而根據(jù)模型實(shí)施過(guò)程的有效監(jiān)測(cè)。隨著智能化儀表和計(jì)算機(jī)存儲(chǔ)技術(shù)的廣泛應(yīng)用，海量的過(guò)程數(shù)據(jù)得以有效監(jiān)測(cè)、收集和存儲(chǔ)，而該類方法正是基于這樣的海量數(shù)據(jù)。

可視一體化運(yùn)維管控平臺(tái)采用基于數(shù)據(jù)驅(qū)動(dòng)的方法和基于知識(shí)的方法相結(jié)合的方式實(shí)現(xiàn)，并將每個(gè)成功預(yù)測(cè)的模型保存在系統(tǒng)業(yè)務(wù)模型庫(kù)中。

4.3 坐席計(jì)算機(jī)運(yùn)維

指揮大廳通常需要配置大量的高性能席位計(jì)算機(jī)，用于GIS 地圖展示、數(shù)據(jù)可視化、指揮調(diào)度及業(yè)務(wù)流轉(zhuǎn)等業(yè)務(wù)。這些坐席計(jì)算機(jī)通過(guò)KVM 分布式坐席系統(tǒng)實(shí)現(xiàn)調(diào)度。由于席位計(jì)算機(jī)接入不同安全等級(jí)網(wǎng)絡(luò)，其自身的安全等級(jí)和操作系統(tǒng)不盡相同，因此如何實(shí)現(xiàn)對(duì)其統(tǒng)一運(yùn)維管理而不會(huì)引起安全問(wèn)題，是亟需解決的難點(diǎn)問(wèn)題。

運(yùn)維需求包括遠(yuǎn)程開關(guān)機(jī)控制，讀取運(yùn)行狀態(tài)、報(bào)警狀態(tài)以及資源負(fù)載等信息，數(shù)據(jù)量較小。由于安全策略，不能選擇網(wǎng)絡(luò)和USB 傳輸。經(jīng)過(guò)權(quán)衡，選擇通過(guò)串口實(shí)現(xiàn)上述功能，此時(shí)只要能夠?qū)崿F(xiàn)串口遠(yuǎn)程開機(jī)功能即可。經(jīng)過(guò)查閱資料和廠家調(diào)研，準(zhǔn)備了兩套實(shí)現(xiàn)方案。

方案一：定制一塊串口開關(guān)機(jī)電路板和后臺(tái)服務(wù)程序。該電路板一端連接計(jì)算機(jī)主板內(nèi)置串口，一端對(duì)外提供串口連接器，并提供一個(gè)干接點(diǎn)輸出接口連接計(jì)算機(jī)Power on 開關(guān)。電路板供電通過(guò)計(jì)算機(jī)電源的＋5 V SB（+5 V 待機(jī)電源）引腳提供。這樣即使計(jì)算機(jī)處于關(guān)機(jī)狀態(tài)，電路板也能夠正常運(yùn)行。同時(shí)，需要在操作系統(tǒng)中安裝上述后臺(tái)服務(wù)程序，用于提供運(yùn)行狀態(tài)等信息。

方案二：選擇服務(wù)器平臺(tái)計(jì)算機(jī)。服務(wù)器平臺(tái)通常會(huì)配置基板管理控制器（Baseboard Management Controller，BMC），只要該BMC 支持串口開關(guān)機(jī)即可。

方案一能夠支持多數(shù)計(jì)算機(jī)，但是實(shí)現(xiàn)相對(duì)復(fù)雜，且需要安裝后臺(tái)軟件；方案二支持的計(jì)算機(jī)較少，實(shí)現(xiàn)更容易，但是成本較高。在本項(xiàng)目中選擇方案二。

4.4 提高語(yǔ)音指令識(shí)別率

近幾年，隨著語(yǔ)音識(shí)別引擎的進(jìn)步，應(yīng)用語(yǔ)音識(shí)別實(shí)現(xiàn)語(yǔ)音轉(zhuǎn)寫和語(yǔ)音指令的應(yīng)用越來(lái)越多。本項(xiàng)目充分應(yīng)用語(yǔ)音指令功能，與運(yùn)維平臺(tái)深度結(jié)合，不僅能夠?qū)崿F(xiàn)燈光控制、空調(diào)控制以及模式調(diào)用等功能，還能夠直接透過(guò)運(yùn)維平臺(tái)查詢系統(tǒng)設(shè)備狀態(tài)等信息。但是，由于使用人發(fā)音差異，經(jīng)常出現(xiàn)語(yǔ)音指令不能被正確識(shí)別等問(wèn)題，如“關(guān)電視”有可能被識(shí)別成“關(guān)鍵是”。針對(duì)這類問(wèn)題，提出能否通過(guò)模糊拼音算法進(jìn)行糾正。

4.4.1 模糊拼音算法

提取語(yǔ)音指令的漢語(yǔ)拼音作為字符串s1，如“關(guān)電視”的漢語(yǔ)拼音“guan1 dian4 shi4”；提取識(shí)別的漢字的漢語(yǔ)拼音作為字符串s2，如“關(guān)鍵是”的漢語(yǔ)拼音“guan1 jian4 shi4”。將字符串s1和字符串s2進(jìn)行相似度計(jì)算，本項(xiàng)目采用Jaro similarity 算法，相關(guān)公式如下：

其中：|s1|和|s2|表示字符串s1和s2的長(zhǎng)度；m表示兩字符串的匹配字符數(shù)；t表示換位數(shù)目的一半；simj表示相似度。上述計(jì)算結(jié)果simj=0.937 5。

可以定義相似度大于0.85 即可認(rèn)為語(yǔ)音指令符合。上述算法需要結(jié)合模糊拼音，才能實(shí)現(xiàn)更好的效果，如圖7 所示。

4.4.2 模糊拼音改進(jìn)1

上述算法能夠大幅提高語(yǔ)音指令的識(shí)別率，但是也會(huì)提高錯(cuò)誤識(shí)別率。例如，在較短的語(yǔ)音指令集上，語(yǔ)音指令“關(guān)燈”和詞語(yǔ)“咣當(dāng)”的相似度約為0.869 5。如果按照相似度大于0.85 的標(biāo)準(zhǔn)，會(huì)導(dǎo)致錯(cuò)誤指令。改進(jìn)方案是針對(duì)語(yǔ)音指令集的每個(gè)指令分別設(shè)置適當(dāng)?shù)南嗨贫乳y值，對(duì)較短的指令閥值設(shè)置大一些，對(duì)較長(zhǎng)的指令閥值設(shè)置小一些。

4.4.3 模糊拼音改進(jìn)2

改進(jìn)后的算法不僅提高了語(yǔ)音指令的識(shí)別率，又抑制了錯(cuò)誤識(shí)別率，在實(shí)踐中效果較好，對(duì)比未采用該算法的識(shí)別率提高了15%～20%。但是，應(yīng)用在指揮大廳這種語(yǔ)言指令集比較龐大，且語(yǔ)音指令系統(tǒng)24 h 待機(jī)的情況下，當(dāng)用戶處于連續(xù)發(fā)言的情況下會(huì)導(dǎo)致大量的轉(zhuǎn)寫文本進(jìn)入算法核心，導(dǎo)致CPU 單核過(guò)載，處理結(jié)果延遲多大于2 s，用戶體驗(yàn)較差。為了解決該問(wèn)題，提出充分利用CPU 的多核處理能力，用Golang 重寫算法，利用Golang 協(xié)程充分調(diào)度CPU 多核處理能力，將原先大負(fù)載下2 s 以上的延遲縮短到8 個(gè)邏輯核心CPU 的0.5 s以內(nèi)，實(shí)現(xiàn)了較好的用戶體驗(yàn)效果。

4.4.4 應(yīng)用AEC 算法消除干擾

當(dāng)通過(guò)語(yǔ)音指令與系統(tǒng)交互時(shí)，通常是一問(wèn)一答的形式。例如，語(yǔ)音指令“今天幾號(hào)”，系統(tǒng)以語(yǔ)音答復(fù)“2020 年7 月22 日”。這樣系統(tǒng)答復(fù)的語(yǔ)音又會(huì)被拾取到，造成語(yǔ)音指令干擾。如何消除這樣的干擾，解決方案有多種，這里選擇應(yīng)用AEC 算法。從根本上看，效果類似干擾。AEC 算法有軟件實(shí)現(xiàn)和硬件實(shí)現(xiàn)之分。軟件實(shí)現(xiàn)是在語(yǔ)音指令處理器上用軟件實(shí)現(xiàn)，硬件實(shí)現(xiàn)是將進(jìn)入語(yǔ)音指令處理器的音頻和語(yǔ)音指令處理器輸出的音頻均引入數(shù)字音頻處理器，用后者的AEC 模塊消除進(jìn)入語(yǔ)音指令處理器的音頻中的干擾部分，保留干凈音頻輸入。這在實(shí)際項(xiàng)目中效果較好。

4.5 人臉識(shí)別應(yīng)用

人臉識(shí)別是基于人的臉部特征信息進(jìn)行身份識(shí)別的一種生物識(shí)別技術(shù)。用攝像機(jī)或攝像頭采集含有人臉的圖像或視頻流，并自動(dòng)在圖像中檢測(cè)和跟蹤人臉，進(jìn)而對(duì)檢測(cè)到的人臉進(jìn)行臉部識(shí)別。人臉識(shí)別技術(shù)在安防領(lǐng)域的應(yīng)用已經(jīng)比較成熟，如人臉識(shí)別門禁等。在指揮大廳場(chǎng)景中如何應(yīng)用人臉識(shí)別并提高工作效率，是本系統(tǒng)重點(diǎn)考慮的主要問(wèn)題之一。調(diào)研發(fā)現(xiàn)，指揮大廳的坐席值班人員經(jīng)常會(huì)隨著任務(wù)調(diào)整位置，而每次更換位置需要重新登錄KVM 系統(tǒng)，如圖8 所示。應(yīng)用人臉識(shí)別可以解決這個(gè)問(wèn)題，即值班人員可以通過(guò)人臉識(shí)別自動(dòng)登錄系統(tǒng)，還能夠自動(dòng)關(guān)聯(lián)上次登錄的席位計(jì)算機(jī)，且當(dāng)值班人員離開一定時(shí)間后會(huì)自動(dòng)退出登錄，消除了因值班人員忘記退出登錄導(dǎo)致信息泄露等問(wèn)題。

此外，基于人臉識(shí)別實(shí)現(xiàn)了會(huì)議簽到、考勤等應(yīng)用，且所有這些應(yīng)用均共享一套人臉識(shí)別引擎。

5 特色功能

5.1 系統(tǒng)健康指數(shù)分析及聯(lián)動(dòng)

故障模型包含故障影響指數(shù)，而不同的故障指數(shù)也不盡相同。影響范圍大、核心設(shè)備故障的指數(shù)高，相反影響范圍小、非核心設(shè)備的故障指數(shù)低?？梢曇惑w化運(yùn)維管控平臺(tái)能夠根據(jù)告警信息列表，實(shí)時(shí)自動(dòng)計(jì)算故障指數(shù)統(tǒng)計(jì)值。數(shù)值越高，系統(tǒng)健康指數(shù)越低；反之，健康指數(shù)越高。根據(jù)系統(tǒng)健康指數(shù)，采用綠、黃、橙、紅共4 種顏色來(lái)直觀標(biāo)識(shí)，其中綠色表示系統(tǒng)健康，紅色表示系統(tǒng)不健康。

表4 系統(tǒng)健康程度一覽表

聯(lián)動(dòng)功能是指在指揮大廳控制室和大廳內(nèi)部安裝一些氛圍燈光和氛圍顯示屏，系統(tǒng)根據(jù)健康指數(shù)自動(dòng)調(diào)節(jié)氛圍燈光和氛圍顯示屏的顏色，以最直觀的方式展示系統(tǒng)的健康狀態(tài)。

5.2 語(yǔ)音指令的應(yīng)用

為了提高用戶體驗(yàn)，除了瀏覽器端和APP 端，可視一體化運(yùn)維管控平臺(tái)還為用戶提供了語(yǔ)音指令交互功能，并與運(yùn)維平臺(tái)深度結(jié)合，不僅能夠?qū)崿F(xiàn)燈光控制、空調(diào)控制以及模式調(diào)用等功能，還能夠直接通過(guò)運(yùn)維平臺(tái)查詢系統(tǒng)設(shè)備狀態(tài)等信息。

6 結(jié)語(yǔ)

可視一體化運(yùn)維管控平臺(tái)應(yīng)用了大量成熟的架構(gòu)和AI 新技術(shù)，為指揮大廳賦予了自我感知和自主學(xué)習(xí)能力，能聽，會(huì)說(shuō)，能看，具備一定的思維、判斷和決策能力，從而保障指揮大廳7×24 h 穩(wěn)定、高效運(yùn)行。目前，本項(xiàng)目開發(fā)完成后已經(jīng)應(yīng)用在海南社會(huì)管理信息化指揮中心3 個(gè)月。從實(shí)際使用效果來(lái)看，它較好地完成了立項(xiàng)目標(biāo)，但是還有一些功能具備一定的提升空間，用于滿足更大的市場(chǎng)需求，如由于網(wǎng)絡(luò)延時(shí)和帶寬等原因，APP 端尚未開發(fā)。隨著5G 的普及應(yīng)用，APP 端也將提上日程。