如果對大型系統的控制管理方式進行分類的話，個人認為無外乎兩類，其中一類是我們在各種中小型系統中比較常見的“本地控制”方式。而另一類則是“遠程控制”。
一、本地控制
在音頻系統的控制方式中，這種方式一直是比較常見的，操作人員通過設備間的調音臺，直接將現場傳輸過來的音頻信號進行處理、混合，將經過處理的音頻通過功放輸出給揚聲器，從而實現對現場擴聲的控制。雖然音頻系統中很多時候我們都是采用這種方式來進行控制操作，但無法第一時間得知現場音質狀況卻是這種控制方式長久以來所存在的一個弊端，并且操作方式往往非常的繁瑣，一般人員需要很長的學習掌握時間。
二、遠程控制
音頻系統遠程控制的方式雖然早在模擬設備時代就已經存在，比如消防信號與音頻擴聲系統結合，但各個廠家所使用控制技術并不統一，并且操作調試過程異常繁瑣、施工難度較高、需要廠商提供技術支持等等的缺點，一直無法受到廣泛的重視。隨著網絡技術日益普及，數字音頻產品與網絡技術有了一個很好的結合點，通過網絡的方式來實現對整個區域或是大樓的音頻系統控制方式也出現在了越來越的工程案例中。
RATC-1、-2
RATC：全稱（Remote Access Terminal Control），遠程終端訪問控制，在媒體矩陣Mware和Nware軟件中都能看到它的身影。RATC也是我們在日?？刂浦薪洺Ｊ褂玫囊环N控制方式。
RATC是基于命令行的控制協議，遠程客戶程序是通過TCP網絡連接來與媒體矩陣進行通訊的，因此，既可以通過本地局域網，也可以通過Internet進行RATC遠程控制。因為RATC是在Telnet的基礎上開發而來。熟悉網絡的朋友都知道，Telnet是一款非常老的TCP/IP網絡遠程終端訪問協議。就是因為它的語言結構簡單，運行穩定，響應速度快等眾多優點，所以至今仍然在很多場合大展身手，而在它基礎上開發而來的RATC自然也是我們日常工程項目中最常使用的一種遠程控制方式。
當我們在一個使用了NION主機的工程項目中對系統進行軟件編程時（這里僅考慮局域網狀態），打開軟件，拖出一個nionode之后，首先要做的就是在Network control port這一選項欄中選出我們需要用的RATC版本，到目前為止在Nware軟件中，RATC的協議版本已經分為RATC1、RATC2和RATC RAW。當我們在項目里沒有使用到中控設備時，在這一步時選擇RATC的那個版本是沒有太大區別的，因為當我們一旦將軟件編譯完成之后，對于客戶來說，操作時僅需要使用Nware的Kiosk軟件進行控制就可以了。由于Kiosk軟件不具備軟件編寫功能，僅僅保留了一個客戶化的界面，所以在任何能與NION主機通訊的PC機上都可以安裝。直接在現場打開已經安裝有Kiosk軟件的筆記本電腦，通過定制的客戶化界面，我們就能對現場的音質狀況進行調整。（圖1）
當然，往往很多時候業主還需要配置中控設備，用來將視頻系統、擴聲系統、燈光系統等等集中在一起。現在大多數的中控設備都可以通過網絡的方式來對受控設備進行發碼，所以在設備的連接上并不復雜。那么這種時候，我們在選擇RATC1和RATC2時就需要注意，雖然RATC1和2所能實現的功能是一樣的，但是在語言結構上有很大的區別。RATC1不支持代碼簡寫，所以當我們通過中控主機與NION進行通訊時，我們需要將命令輸入完整，并且區分大小寫。這對于中控編程人員來說無疑是非常費力的一件事情，并且RATC1在網絡安全性方面低于RATC2。而RATC2無論是在代碼長度以及網絡安全方面均要高于RATC1。所以現在很多工程項目中我們都是采用RATC2的方式來同中控設備通訊。
RATC RAW是RATC協議中比較特殊的一種，相對其他兩個版本的RATC，RATC RAW是功能最為全面的。我們之前的RATC1和2如果要使用外部控制設備來對NION主機進行控制的話，那么在Nware軟件編程的時候，就需要將受控的器件分別標上“控制別名”如果受控模塊非常多的話，那么光是標上別名的工作量就是非常巨大的，如果2個受控器件的“別名”起得非常相識，很有可能在編程時出現不必要的差錯。但是如果我們一開始選擇RATC RAW版本時，給受控器件標名的工作就可以省略了。這是因為在Nware軟件中所有的器件都有一個設備編號，以及一個控制編號，這在軟件開發初期就已經設置好了，當我們需要對某一器件模塊進行控制時直接將編號輸入，并對模塊進行賦值。所有器件的設備編號都可以在Nware中找到，而且絕對不會重復，這樣出錯的概率就大大降低了。
[Page]
當所有的軟件編程工作完成之后，就可以利用中控觸摸屏直接在現場對聲音狀況進行調節，非常的直觀。
PASHA PASHA可以解釋為媒體矩陣處理適配器，從Mware時代開始PASHA就一直是媒體矩陣作為外部控制的一種方式。不同于之前的RATC，PASHA是百威早期專為串口控制設備而開發的一款遠程控制軟件，并且已被集成在了Nware控制軟件中。RATC是網絡的一種控制方式，那么PASHA呢？
早期網絡遠沒有像今天這樣普及，人們在設備與設備之間的通訊多數時候還是停留在串口，也就是我們長說的RS232“數據終端設備(DTE)和數據通訊設備(DCE)”。而PASHA就是為RS232串行通訊標準而開發的。由于RS232采用的也是類似于Telnet點對點的通訊方式，所以在穩定性方面非常好，并且它對于線纜的要求不高，采用普通的三芯屏蔽線纜就能實現點對點的互通。因此到今天依舊在很多設備上能看到它。
PASHA使用的也是ASCII(文本)字符串，但是PASHA除了對外部命令的響應之外，不會主動發送任何信息。所以一旦我們利用NION主機背部的串口來對系統進行控制的時候，我們在編碼上需要進行更改。在對Nware系統軟件編程時我們同樣需要給受控器件標上“控制別名”。比如我們需要對“sss”這個名稱的推桿進行控制，采用RATC的方式話，那么我們首先想查看下當前“sss”是處于什么狀態，可以通過“controlGet sss /r”。而PASHA則是“Gsss.”這樣的字符串來獲得，并且對于控制數值的設定，PASHA采用的是十六進制的方式從“00”一直到“FF”。
今天當我們通過RS232，RS485等串行接口來對媒體矩陣設備進行控制時，Nware軟件已經可以采用RATC的編碼方式來進行收發碼了，這就是說可以在串口命令行發送RATC命令代碼。這樣即使無法通過網絡接口來對設備進行控制，編程人員也不用重新改寫代碼，僅僅只需要將接口調整一下就可以了。當然在某些特殊情況下，一些外部控制設備對于RATC代碼是無法識別的，那么我們只能采用PASHA的方式來進行了，就好比媒體矩陣外部控制設備中的X Control系列和Pagematrix系列。
SNMP SNMP是“Simple Network Management Protocol”的縮寫，意思是“簡單網絡管理協議”從控制的角度來看SNMP和之前的RATC與PASHA相比，相對來說是比較復雜的一種外部控制技術。SNMP并不是百威發明的，它是由互聯網工程任務組IETF定義的一套網絡管理協議，早期SNMP僅僅只是針對某些單一的網絡設備管理，比如大型路由器、交換機等。隨著技術的推廣，越來越多的廠家加入到了這一協議團隊中。今天一家大型公司的網絡管理員，可以只坐在電腦前，通過SNMP服務器將連接入公司局域網設備目前的運行狀態在電腦上顯示出來，并且進行相應的管理，前提是只要該設備支持SNMP管理協議。目前很多類型的設備都支持SNMP管理，媒體矩陣NION主機自然也不例外。
SNMP是一款協議，協議就需要有一個標準，那么如此多的廠商之間是通過什么來進行協調的呢？這就需要通過MIB文件來進行分配了，MIB就好比是某一硬件的身份證，標明了它在SNMP隊伍里面所處于的位置。一般MIB都是由IETF來進行分配的，通過記事本打開MIB文件的話就可以看到一長串的數字編號，(1.3.1.4.1.24603.1.1.5.)這些數字分別代表了不同的含義。其中1.3.1.4.1是由ISO國際標準組織頒布的，而“24603”則是ISO組織頒發給百威的企業編號，在“24603”之后則是由企業自己來決定了。NION主機的編號在MIB文件中是1。對于SNMP所能實現的功能定義完全是由各家廠商自己制定的。SNMP的實現方式需要我們增加一臺SNMP服務器來對NION進行管理，一般我們將SNMP服務器稱作SNMP管理站，而將受控一方稱作SNMP代理端。在管理時，我們需要額外的第三方軟件，通過軟件SET和GET不同的OID來進行。所以如果需要在工程項目中使用到SNMP來對設備進行管理，那么SNMP管理站是必不可少的。SNMP在我們日常項目的運用并不多。到目前為止只有在一些超大型的場館中得以運用，譬如北京T3航站樓。T3航站樓公共廣播系統由于使用的主機、網絡功放等設備非常的多，而樓宇之間的距離又非常遙遠，如果工作人員需要對設備進行例行監測，那么樓宇之間動則上百，上千米的距離，監測人員每天在樓宇之間來回的穿梭將耗費大量時間。而這時通過SNMP來對設備進行管理就大大簡化了這一過程。工作人員只需要在電腦前調用出預先配置好的SNMP管理站，通過服務器端就能詳細了解當前某一設備的運行狀態，主機溫度、風扇轉速、當前主機背板接口狀態等等各類參數。這樣一旦主機運行狀態出現問題我們就能立刻知道，并做出調整，事后再對問題設備進行更加詳細的檢測。[Page]
以上是媒體矩陣主機在控制中所使用到的幾種外部控制方式，比較下來，似乎RATC是目前運用最多的一種遠程控制方式。但是在實際運作中，還是應當根據實際情況來加以判斷。靈活運用，才能將媒體矩陣的功能發揮到最大。
【參考文獻】
解析媒體矩陣(MediaMatrix)(三十五)DEVICE(RATC外部控制協議)的原理和使用 作者：兆翦