珠江隧道總長1200多米，屬于中長V型隧道，整個隧道包括：中央計算機系統、交通檢測系統、火災報警系統、通風及環境檢測系統、照明系統、交通誘導系統等等。本次改造OMRON的CS1D系統一共有6個站分別安裝在隧道夾層管廊里面，負責整合交通檢測、通風及環境、照明、誘導等控制系統，按照控制對象，我們將它分成3個大系統：照明系統、交通檢測及控制系統、通風系統。

一． 照明系統

1、          控制對象

隧道內照明系統由遮光棚段、過渡段、基本段照明組成，相應地主要控制內容分三種：

（1）過渡段控制：根據隧道兩出入口的視野亮度對過渡段加強照明燈組按天氣晴、陰分四級進行位式控制，使白天進洞前、后的亮度變化容易讓司機適宜；

（2）根據日時鐘對基本照明段的照明燈組分白天和深夜兩級進行位式控制；

（3）根據日時鐘和口部亮度對遮光棚的照明燈進行“全開/半開/停止”的位式控制。

2、照明級別劃分

6個照明級別：1.烈日、2.晴天、3.云天、4陰天、5夜間、6深夜。

1 ~ 4四種照明級別主要針對加強段的照明控制。

2 烈日                    開全部加強照明、開基本段照明

2 晴天                    關小部分加強段照明、開基本段照明

2 云天                    關一半加強段照明、開基本段照明

2 陰天                    關大半加強段照明、開基本段照明

2 夜間                    關加強段照明、開基本段照明、開遮光棚段照明

2 深夜                    關加強段照明、基本段和遮光棚段照明減半

（基本段和遮光棚段照明減半時，兩組回路按單雙日交替使用）

注：亮度值與照明級別對照關系請看附錄1.

3、          控制方式：光控制、時序控制、模式手動控制、完全手動控制；

說明：左孔、中孔可分別單獨設置控制方式。

   4、  光控制：

光亮度值由隧道洞口處的8個亮度計檢測所得，輸出信號為4～20mA，量程為0～6500cd/，根據亮度檢測裝置檢測到的光亮度值，實時開啟或關閉相應的照明燈具，從而形成一個閉環控制。

說明：光控只針對白天照明系統的控制。

   5、  時序控制：

主要分為以下幾種時間段：清晨、上午、中午、下午、旁晚、夜間、深夜。

6、          模式手動：

中心監控人員根據室外天氣情況，人工判斷、選擇當前的“照明級別”。

   7、  完全手動：

在控制中心，手動獨立控制所有回路的開關。

各個燈組以及亮度計在隧道中的位置，如下圖

橙色框里面的是出入口的加強段照明，紅色框里面的是出入口的遮光棚段照明，其余的是基本照明。

照明的控制流程圖如下：

2、交通狀態設置

在隧道出入口8個車道安裝了兩臺超聲波道路交通信息檢測器，以RS485方式，每分鐘向PLC1和PLC6發送一次長度為226個字節的車輛信息，此信息包括：各種車的流量、平均車速、占有時間、堵車時間。

根據道路交通信息的數據得到的車輛運行信息，又將隧道分成三中狀態：

2    正常；

2    擁擠；

2    阻塞；

說明：

1）每種交通狀態對應的交通量數據可以在中心軟件設置；如判斷堵車的速度，持續時間等；

2）對于關閉的車道，不予判斷；

3）擁擠和阻塞也包括輕微交通事故造成的情況，如拋錨、追尾等；

（1）交通擁擠時，控制方案

隧道入口交通信號燈黃色閃爍（閃爍頻率：1Hz，即1次/秒），提示駕駛人員減速慢行，關閉的車道保持紅燈常亮；

（2）交通阻塞時，控制方案

隧道暫時關閉，相應入口交通信號燈：綠色——綠色閃爍（1Hz/5s）——黃色閃爍（1Hz/5s）——紅色，等待洞內車輛全部通過隧道時，隧道重新開啟，入口信號燈變為綠色。  由出口交通量檢測器判斷洞內車輛是否全部駛離隧道，可以預算一定時間T內，在該時間段內若沒用檢測到車輛表示全部車輛已經通過隧道，預算時間可在中心軟件設置，如：T可取15秒。

3、交通系統控制方式

控制方式：模式手動控制、完全手動控制。

（1）模式手動控制

每個孔洞按以上7種模式進行控制，通過中心計算機機人工選擇所需交通模式；

（2）完全手動控制

可以控制每個車道指示燈的狀態，包括：綠箭、紅叉、黑屏。

可以控制每個入口交通信號燈的狀態，包括：紅、黃、綠。

注：無論在哪一種模式，一旦發生擁擠、阻塞、事故、火災時，自動執行相應程序，其中阻塞、事故和火災需要人工確認后才能執行。

下圖為交通誘導燈分布圖：

三．通風系統

1、         控制原則

（1）     保持隧道內環境指標在標準范圍內。主要指一氧化碳CO、能見度VI、風速；

（2）     隧道內某一段的CO或VI值含量達到門限值時，本段或最靠近此段的風機應首先啟動，然后追加的風機按照運行時間最短優先啟動的原則，以平衡各風機的勞逸度，延長風機使用壽命。另外，風機的啟閉次數不應過頻，紡織風機出現震蕩現象。

（3）     若一條隧道因事故關閉，另一條隧道改為雙向運行時，因交通量增長很多，若全部風機啟動而環境指標達不到正常值，則應和洞口交通信號燈配合，利用信號燈空內控制進入隧道的車輛，以達到正常的環境指標。

（4）     正常運行時，風機為正向運轉（即沿行車方向吹風），當火災或雙向行駛正向交通量小于逆向交通量時，風機才可能逆向吹風。如有需要逆向吹風時，應先停風機，再啟動逆向運轉。

2、         控制模式：自動控制、手動控制

自動控制

隧道采用縱向通風方式，通風控制的任務是通過檢測隧道內的CO濃度、VI濃度以及風速、風向來控制隧道內13組（每組兩臺）風機的啟停和正反轉。

其中CO、VI環境檢測器：CO的輸出形式是4～20mA，量程為0～300ppm；VI的輸出形式是4～20mA，量程為0～15（1/Km）。

風速風向檢測器：風速的輸出形式是4～20mA，量程為0～15m/s；風向輸出形式是4～20mA，量程為0～360度。

系統控制方式為位式控制，在兩個控制點間設置一段不靈敏區，控制點可在線修改。

控制點設置（預設）

正?？刂颇Ｊ剑A設）

注：CO/VI與最近一組風機對應關系可以在中心計算機設置；控制點可在線修改，在隧道運營過程中不斷優化；

手動控制

根據現場CO/VI值、交通量數據和CCTV的圖像資料，人工控制風機的啟停及運轉方向，所有風機可以獨立控制。

下圖為風機以及CV檢測器的布局圖：

四、系統預案

1、         系統預案分類

系統預案分以下幾類：

1）        阻塞

2）        事故

3）        檢修

4）        火災

以上預案模式左孔和右孔可以獨立設置。

其中阻塞預案的處理方式上面已經說過了。

2、         系統預案觸發方式

系統預案觸發方式分為兩種：

1）自動觸發

2 自動觸發的預案主要指“阻塞”和“火災”；

2 阻塞預案由隧道孔交通量觸發，火災預案由現場報警按鈕觸發；

2）人工觸發

2 阻塞、事故、檢修、火災都可以人工觸發；

2 阻塞預案可以人工觸發，觸發后系統會自動恢復，并提示值班人員；

2 阻塞、事故、檢修、火災的預案處理完畢后，系統恢復到正常狀態；

3、         檢修預案處理方式

檢修模式主要用在深夜隧道的清洗、夜間及深夜隧道孔的維護、維修。

處理步驟如下：

1）   雙孔“夜間”照明級別開啟，即開啟基本照明段和遮光棚段的照明，關閉所有加強段照明；

2）   需檢修的隧道孔開啟“模式6”交通模式，封閉該隧道孔；

3）   另外一個隧道孔開啟“模式4”，雙向通行；

4）   對照明以及交通模式進行處理后，將照明和交通模式切換到完全手動控制，方面監控人員針對現場情況實時對照明燈和交通燈進行狀態修改；被關閉的隧道孔風機仍由計算機進行自動控制；

5）   檢修完畢后，系統恢復原先狀態。

4、         火災與事故預案處理

為了便于對隧道的交通進行組織，也方便監控人員操作，把隧道內部按照車道指示燈的位置分為以下幾個區域，左孔和右孔各5個控制區域。

大型事故預案

大型交通事故需要控制中心值班人員通過CCTV系統判斷，一般是指該事故造成兩個車道完全堵塞，車輛無法通行，一旦確認大型交通事故發生，啟動大型交通事故預案，“事故”預案只能人工觸發。

處理步驟如下：

1）   人工點擊“事故預案”按鈕，觸發事故預案；

2）   點擊發生交通事故點的區域（Q1～Q10）；

3）   判斷隧道孔交通模式，如果是順行或則是逆行，車輛行進方向區域及其上游的車道信號燈變為紅叉“×”，禁止車輛通行；車輛行進方向區域下游的車道信號燈繼續為綠箭“↓”，允許車輛繼續前行；如果隧道孔是雙向運行則關閉發生事故的隧道孔；

4）        發生事故的隧道孔入口紅綠燈：黃閃（1Hz/5s）——紅，禁止車輛進入隧道；

5）        執行完上述處理后，PLC自動將交通控制模式切換到完全手動，方面監控人員針對現場情況實時的修改交通燈狀態。

6）        交通事故處理完畢后，系統恢復原先交通模式；

火災預案

火災處理分為幾個步驟：

1）    報警階段

通過現場緊急按鈕、緊急電話或則CCTV系統發現火災，監控人員進行確認。

2）    逃生階段

報警確認完畢后，自動執行以下程序。

交通系統：

A.      值班人員通過中心計算機用鼠標點擊發生火災點的區域（Q1～Q10）；

B.      PLC根根據隧道孔交通模式，不管是順行還是逆行，車流方向火災區域及其上游的車道信號燈變為紅叉“×”，禁止車輛通行；車流方向火災區域下游的車道信號燈繼續為綠箭“↓”，允許車輛繼續前行；如果隧道孔雙向行駛則雙向紅叉“×”。

C.               隧道兩孔的入口紅綠燈：黃閃（1Hz/5s）——紅，禁止車輛進入隧道；

D.               執行完上述處理，交通控制模式切換到完全手動。

照明系統：

E.                雙孔開啟“烈日”照明級別，即除遮光棚段以外，所有照明燈開啟，方便駕乘人員撤離。

通風系統：

F.      火災隧道孔的所有風機關閉；

G.      經過一段時間Tff（時間預設8分鐘）后，根據隧道交通模式，開啟火災區域車流方向下游的所有風機；風機運轉方向與車流方向相同；如果隧道孔雙向通行，風機停止。

H.      執行完上述操作以后，將風機控制模式切換到手動控制，方便監控人員按需要增開會停開風機。

3）    滅火階段

I．開啟火災隧道孔所有風機，增大風量，以利于滅火降溫

4）    恢復階段

J．人工恢復另外一個孔的正常運行

K．滅火結束后，發生火災的隧道孔CO/VI值達到設定標準后，恢復隧道孔正常運行，風機按照設定時間間隔先啟先停。

五、系統配置及網絡

隧道控制系統的網絡拓撲圖如下：

隧道共有6個PLC控制分站，每個站都是OMRON的CS1D雙電源和雙CPU系統，選型時并沒有選擇雙以太網卡，而是在網絡搭建中，利用6個MOXA EDS308的交換機組成100M光纖以太網環網，6個PLC使用普通網線連接到就近的交換機上，IP地址分別為192.168.59.11～16。在1＃和2＃交換機上各有一條光纖通到監控中心機房的交換機上。這個在一定程度上實現網絡的冗余。

網絡處理：

1.數據交換

因為6個PLC在預設的時候不知道要交換什么數據，在程序開發的過程發現要交換的數據越來越多，而且地址也不連貫，為了后面的開發更容易簡單，PLC的網絡接通以后，預先做了一段通信程序，每個PLC都拿出100個字來作數據交換。

例如人工PLC2發現有數據需要交換其它的PLC的話，就將此數據發送到CIO4100～CIO4199的區域里面，有需要用到PLC2的數據的PLC就讀取PLC2相應的區域就行。

使用指令CMND

意思是每天凌晨2點與IP地址為192.168.59.22上的Time Sever進行時間校準。

交通流量處理：

原選型時，是希望通過SCU31的485通信，使用協議宏或者是無協議方式來訪問交通檢測器的數據。但實際隧道中使用的交通檢測器，只有232通信口或者是2線制RS485通信，而且是主動發送數據的，而不是接收PLC發送的指令來反饋信息的。也就是PLC只有接收無發送，而且接收的時刻完全由交通檢測器決定。

CS1W-SCU31模塊的485口，如果使用協議宏必須是主動發送讀取命令，如果使用無協議方式，必須使用4線制。最后只能不使用SCU模塊，而是使用CPU上自帶的232口與檢測器上的232口連接來解決。

交通檢測器的數據包原始設計是沒有頭代碼和結束碼的，為了保證接收數據長度和數據塊的完整，我要求他們對數據包作修改，增加頭代碼＃AA，結束碼＃EF，每分鐘向PLC發送一次數據。除了頭代碼結束碼數據總長為232個字節，每個車道信息占56個字節，一共4個車道，其余字節為公共信息。

那位檢測器發送數據是高字節PLC接收到檢測器發送的數據后，要將高低字節互換才是我們需要的數據，這里使用SWAP指令，當數據接收并保存完成后執行一次SWAP指令。經過2個多月的使用，上位機車道信息報表中發現，一天中會有不規律的幾個小時會出現平均車速或者車流量數據大得很不合理。經過多次改善數據處理程序依然會出現這種情況。為了找出原因，我使用DR，IR指針將每次發送過來的原始數據保存到了E0里面，將出現不合理數據時候的原始數據另存到E1里面，并將出現不合數據時的時間一并存儲起來，結合上位機報表數據，比較正常時和不正常時候的數據，經過分析，原來是檢測器發送過來的數據會不定期的出現部分信息為低字節先發；例如某車道一分鐘的小客車流量是20臺，那么正常的檢測器發過來的數據應該是＃1400，程序處理時將數據高低字節互換之后就是＃0014了，但是如果檢測器發送過來的時候就是＃0014，程序再進行互換的話，流量就變成5120臺了，而這種現象出現的機率幾乎每個小時都有1次，出現在數據塊的位置也不固定，但也有一個規律，就是當在數據塊某個位置出現這種情況，這一塊數據在這個位置后面的每個字都會出現同樣的情況。鑒于這種現象廠家也處理不了，最后只能在做數據處理的時候，不對整塊數據使用SWAP指令，而是對每一個字的信息都做一下判斷，例如車流量，每分鐘肯定不會超過60臺，如果使用SWAP指令轉后車流量數值超過了60臺，那么就使用原始數據，而不使用經過SWAP指令處理后的數據。經過調整，這種現象就不再出現了。

 風機控制處理：

首先介紹一下每臺風機所在的PLC以及每個環境檢測器的信號接入到那臺PLC。

1.  風機如何聯合控制

風機的自動控制左右孔是獨立的，同一個洞的風機相互之間是有著先后順序的關系的。按照控制的要求，那個CV檢測到CO/VI超標就啟動就近的風機，看似很簡單；但這里就有個問題了，因為風機不在一個PLC上，如果CV1超標了，PLC2控制優先啟動F1，如果沒過多久CV3也超標了，PLC3控制優先啟動F3，而在經過一點時間Ton，如果CO/VI還是沒有回到正常水平，那么PLC2自身控制會增開1臺風機，PLC3也會，那樣就滿足不了勞逸結合的控制原則，以及節能的目的。如果把PLC2作為主控，所有風機都由PLC2來發號施令，所有CO/VI的數據都通過通信給到PLC2，讓PLC2來統籌控制，這樣看似控制起來就很簡單，但有個問題就是當PLC2出現故障或者PLC2通信出現異常，那么所有的風機都不能啟動了，這樣的話，這種控制方式看起來就很脆弱。

這里我使用的控制方法，總結為風險平分、輪流做莊。以左孔為例，CV1、3、5、7，那個檢測到超標，那么就由它所在的PLC做主控（如果是CV8超標PLC5做主控），進入CV超標控制流程，首先算出風機啟動順序來，然后按順序按時間間隔Ton逐臺啟動，在這時候如果其它CV再出現超標會被屏蔽不作處理。這樣就可以減低集中故障率，也使得控制更合理。在實際程序中，還要考慮以下情況：當自動開啟風機后，如果監控人員發現特殊情況需要手動增開風機，然后又切換回自動，這過程中手自動切換時風機狀態要保持；還有就是手動開啟的風機切換到自動狀態CV值回到正常后，能夠把手動開啟的風機也關停。

2.  風機如果按照勞逸結合來起停。

每個CV點超標后，都有一臺就近優先啟動風機，然后增開的風機都按照運行時間短的先啟動。說起來很簡單，但實際程序寫起來相當復雜，沒有什么技巧可言。風機的運行時間都是分鐘為單位，而且都是雙字，那么MAX、MIN指令都不合用，按照概率算法，左孔每個CV就近風機都有6種情況，第一臺增開風機是5種情況，那么要確定一組啟動順序需要比較次數為6×5×4×3×2＝5760。這樣寫起來程序量就相當大。會了簡化程序，根據實際情況，風機開啟4臺或以上的情況比較少，所以只判斷出現前3臺需要啟動的風機號，剩余3臺按照那個風機號小的優先啟動，那樣比較次數就減少到120次。在寫程序的時候還需要考慮以下情況：

某臺風機檢測到壞了，要自動跳到啟動下一臺；當出現CV正常后，風機關閉過程中CV值再次超標的現象，已經關閉了的風機要放到最后啟動，也就是在關閉過程中要對啟動序列進行修改，將第一臺關閉的風機號放到啟動序列的最后一位，然后將即將關閉的風機放到頭位。

照明、交通、風機三種對象，每1個輸出控制點，都需要經過很多判斷條件，例如照明的加強燈，首先要判斷手自動、光控時的各個照明級別、時序控制時的各個時段以及各種預案的情況；如果每個輸出點都單獨作判斷，就需要并聯串聯很多條件，這樣會導致每個輸出點過于復雜。為了清晰控制思路，把控制過程分為以下的步驟：

1.      首先建立多個任務組：光控任務、時序控制任務、其它控制模式任務等；

2.      將工況相同的燈組組組合起來，預先將可能出現的動作狀態保存到某些通道里面；

3.      在控制任務里面就只需要判斷出各種照明級別標志位，根據判斷出來標志位把預存的動作狀態發送到執行通道；

4.      最后執行通道直接控制輸出點。改變控制方式的時候，我們只TKON、TKOF來啟用或關閉相應的控制任務就可以了。

使用多任務控制，照明為例，光控任務和時間控制任務的輸出點都是一樣的，都是輸出烈日、晴天等標志位間接控制照明輸出，但任務之間切換的時候，沒OFF的任務的輸出在主程序里面還是會為ON的。

不管是照明、交通、風機，手自動互相切換時狀態都要保持，新的控制命令來到之后才能改變狀態

模擬量問題，模擬量模塊同時接有源和無源的4～20mA輸入，會出現所有通道的值都變成4000多的現象，只要將所有通道的－極都接到0V上，模擬量轉換值就恢復正常了。