幾乎沒有人討論IEC61499 功能塊的執行性能，它的執行時間是多少？外部事件的回應時間是多少？E_CYCLE的最小周期設定為多少比較合適？的確，一個與設備無關的標準不可能討論執行的性能，但是，作為一臺控制設備，我們就需要關心一些功能塊的執行效率了，到目前為止，功能塊都是由軟體來實作的，采用JAVA 或者C/C++ 實作，功能塊本質上是一個軟體組件，既然是軟體，執行的效率就依賴于處理器，和外圍電路性能，
我們知道，IEC61499 功能塊是基于事件執行的，事件就像硬體電路中的脈沖，事件由下面幾種形式
實時周期性事件（periodic）
周期性事件就相當于是一個脈沖信號，比如采用E_CYCLE 能夠周期性地產生事件，周期性事件會引發一系列功能塊的周期性執行，顯然，在一個周期性事件產生時，要在下一個周期事件到來之前，完成所有的功能塊的執行，在傳統的PLC中，程式是基于掃描周期執行的，CPU的速度保證在一個掃描周期內要完成所有程式的執行，
周期性事件要求具有實時性，
實時性隨機事件（sporadic）
具有最小到達時間要求的事件（minimum inter-arrival time），這種事件類似于數字電路中CPU的中斷信號，當外部事件產生時，引發一系列功能塊的執行，要求以最短的方式回應偶爾發生的事件，
自由運行事件（aperiodic）
這類事件沒有最小到達時間要求，但是具有底線事件要求（dead line time），處理器要盡快執行，
我們知道，在IEC61499 功能塊應用中，功能塊是基本的執行單元， 復雜的數字邏輯功能是可以使用基本功能塊（AND，OR,NOT）來構建的，而功能塊又是軟體實作的，因此，IEC61499 功能塊網路的執行速度沒有硬體電路速度塊，甚至沒有C++撰寫的程式快， 如果軟體實作功能塊來代替傳統的數字電路的話，將會占用大量處理器時間，即便如此，產生的各種信號的頻率也不會太高，
同樣地，IEC61499 標準中提供了一些IO標準功能塊庫，它們只是簡單地讀/寫操作，例如IX 是讀取埠的布林值，QX 是輸出一個布林值，在實際應用中，IO介面的功能更加復雜，對實時性和精度要求更高，比如需要產生高頻率時鐘信號，脈沖計數，PWM 輸出等等，這些功能理論上可以使用IEC61499 IO功能塊和基本功能塊來實作，但是它們并不十分好用，一是非常復雜，一個簡單的功能需要多個基本功能塊來實作，過于“低級”編程，帶來了學習的陡峭，另一方面，由于完全是軟體實作，會導致應用程式速度慢，實時性差，無法滿足某些實時性要求高的應用場合，就像我們在嵌入式處理器編程中，軟體產生一個方波那樣，當頻率超過1K 時，晃動的就很厲害了，筆者認為，IEC61499 標準要真正在工業控制領域實際應用的話，需要借助于處理器提供的高級IO硬體介面電路，或者FPGA來實作某些對精度要求高，速度快的功能塊，比如產生脈沖信號，PWM，模擬量的DMA 采集，運動控制等等，當然這也帶來了一些問題，硬體實作的功能塊難以保持與設備無關，不同設備上實作的功能塊，雖然型別一致，但是性能也會存在很大的差異性，
無論如何 ,功能塊的硬體實作是值得研究的課題，
當你開發一臺IEC61499 設備時，IEC61499 功能塊運行的性能也需要考量的重要一部分，
一個例子
這里我們通過一個例子來演示功能塊硬體實作的重要性，這個例子產生一個占空比為25% 的PWM 信號，
使用基本的功能塊實作：
E_CYCLE 的周期為1ms，由于是軟體實作這五個功能塊，顯然占用CPU的時間已經比較多了，但是PWM 的頻率可能只有64Hz 而已，如果解析度要求高的話，PWM 頻率會更慢，而且軟體產生的PWM波形晃動非常厲害，嚴重的失真，
相比之下，如果使用STM32F 這樣cortex-M 的單片機來實作PWM的話，可以采用硬體TIM的PWM 輸出功能，基本上不需要軟體干預，而且至少可以達到幾十K，
從程式設計的角度看，我們只需要實作一個功能塊PWM，直接啟動就可以了，
因此，在具體實作時，我們要利用處理器芯片的外圍電路來提高IO功能塊的運行效率，比如這個PWM功能塊在STM32MP157C 處理器中可以通過TIM 定時器來實作PWM 信號輸出，IEC61499運行時（runtime）程式通過一小段程式就能實作TIM 時鐘的PWM 輸出，可以產生很高的PWM 頻率（，如果使用示波器看的話，它是一個十分漂亮的脈沖波形，沒有任何晃動，
下圖是STM32系列STM 產生PWM的頻率，解析度和時鐘頻率之間的關系，
由此可見，IEC61499 功能塊實作時要充分利用CPU 的硬體IO 特性，能夠提升功能塊應用程式的運行效率和實時性，可惜的是目前能夠看到的IEC61499 運行時并沒有提及這方面的努力，
弊端
純軟體實作的功能塊只是一個“玩具”，其性能無法滿足實際應用的需求，充分利用處理器的IO硬體來實作IEC61499 的介面和“底層”功能塊是該標準走向實用化的關鍵，當然這也帶來了一些問題：
無法做到與設備無關
使用MCU 的硬體資源來實作IO 功能塊也帶來了一些弊端，主要的問題是它將依賴設備處理器，無法實作與設備無關，
同類功能塊的性能差異
另一方面，功能塊在不同設備中的性能將會有差別，比如同樣是一個PWM 功能塊，在高性能的設備中，能夠產生幾百K的頻率，而在低性能的設備中可能只能幾十Hz，
對設備硬體提出了更高的要求
高性能IEC61499 的運行時（runtime）需要具有記憶體管理（MMU）的OS ，比如Linux，處理器一般會采取X86 或者Arm Cortex-A 單核或者多核處理器，在Linux OS 中，對硬體介面的驅動一般是比較古板的，控制底層硬體不方便，且效率不高，所以通常需要外擴協處理器，或者采用近年來開始流行的異構多處理器芯片，比如NXP 具有類似的產品，而ST公司2019年也推出了STM32MP 系列產品，
無論如何，部分功能塊的硬體化實作是一個十分有趣的課題，如果能做到像NI 的lab view 那樣的性能就更了不起了，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/209707.html
標籤：java
上一篇：5G知識之0G-5G的技術發展