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

圖5 冗余流程

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

圖6 can故障判斷流程圖

　　5 實(shí)驗結果分析

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

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

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

6 結束語(yǔ)

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