TTCAN在風(fēng)力發(fā)電控制系統(tǒng)中的應(yīng)用

圖5 冗余流程

而要實現(xiàn)冗余，can通道的故障判斷尤為重要。由于風(fēng)力發(fā)電控制系統(tǒng)中，cpu模塊充當(dāng)著控制器的核心，系統(tǒng)所有的采集輸入都在這里匯集，經(jīng)過控制流程后又由它產(chǎn)生控制輸出。于是在can網(wǎng)絡(luò)中，cpu模塊同時充當(dāng)著主節(jié)點的角色。所以系統(tǒng)設(shè)計在cpu模塊中進行can總線故障判斷處理。具體判斷流程如下：cpu模塊中預(yù)設(shè)定時器中斷(暫設(shè)1ms)，對每個從節(jié)點都做時間計數(shù)，當(dāng)每次收到從節(jié)點傳來的數(shù)據(jù)幀時，對相應(yīng)節(jié)點的計數(shù)清零。也就是說，這個計數(shù)就是距上次正確收到該從節(jié)點傳來數(shù)據(jù)的延時(單位為ms)。當(dāng)程序判斷這個計數(shù)超過一定值(暫定100ms)，認為通信超時，該從節(jié)點的can通訊已經(jīng)出錯或中斷，此時整個控制系統(tǒng)需要切換總線通道，激活canb，重新建立通訊，并進行報警。如下面流程圖6所示。

圖6 can故障判斷流程圖

　　5 實驗結(jié)果分析

　　基于本方案所設(shè)計的這種通訊方式，當(dāng)can節(jié)點發(fā)送數(shù)據(jù)時，在其待發(fā)送的數(shù)據(jù)幀最后補加上兩個字節(jié)的crc校驗碼，區(qū)別于twincan模塊自身所帶的crc容錯機制，補加的crc校驗是為了防止can傳輸多幀數(shù)據(jù)過程中出現(xiàn)數(shù)據(jù)丟幀的現(xiàn)象。于是，cpu模塊每次都將接收完成的數(shù)據(jù)進行crc判斷，以此驗證收到的該幀數(shù)據(jù)是否出錯。cpu模塊程序設(shè)計使其對它收到的每個從節(jié)點傳來的數(shù)據(jù)幀進行一個計數(shù)，每正確收到1幀，計數(shù)加1。設(shè)查詢時刻為t，can通訊周期為t，則t時刻計數(shù)值cnt=t/t。以通訊周期20ms為例，每隔1秒鐘，cpu模塊應(yīng)收到的每個從節(jié)點所傳來的數(shù)據(jù)幀數(shù)cnt=50，即為32h，于是，我們每隔1秒鐘將這些計數(shù)通過串口發(fā)出來，就可以監(jiān)視這些計數(shù)，以此驗證ttcan通訊周期長度，以及can總線切換機制。具體數(shù)據(jù)參見附表。
　　附表 監(jiān)視結(jié)果表

　　附表中為20ms通訊周期下，系統(tǒng)上電運行10min的一個情況，據(jù)表分析，系統(tǒng)上電時，延時1秒鐘開始can通訊，正常情況下，每秒鐘包含50個通訊周期，故應(yīng)正常收發(fā)數(shù)據(jù)50幀，t時刻計數(shù)值則剛好滿足cnt=(t-1)*50，相鄰兩秒之間計數(shù)基本相差32h。但偶爾會出現(xiàn)前后兩秒相差31h的情況，這種情況出現(xiàn)的原因則是因為在該發(fā)送時刻，該節(jié)點該次數(shù)據(jù)暫未接收完成所致。

　　系統(tǒng)上電1min后，嘗試切斷總線上id號為1的節(jié)點，會發(fā)現(xiàn)該節(jié)點計數(shù)相對其他正常節(jié)點少5，則分析推斷該節(jié)點can通訊停頓了100ms后又重新建立，而此刻，系統(tǒng)已經(jīng)完成can通道切換，轉(zhuǎn)用canb運行。

6 結(jié)束語

　　實驗效果表明，基于冗余ttcan的模塊化風(fēng)力發(fā)電控制系統(tǒng)各模塊間的通信總線，相對于過去常用的查詢返回can通信方式，更具效率且更為可靠。它的應(yīng)用，對于提高整個控制系統(tǒng)的可靠性和實時性極具意義。