我們現在将描述在IEC61499 中主要的模型和概念，對這個關于功能塊的标準有一個全面的了解。建議在閱讀後面幾章，詳細了解IEC61499 特征之前，首先·了解本章的材料。
本章的主題包括：
- 功能塊特征以及它們的執行
- 功能塊的不同形式
- 提供硬體和作業系統接口的服務接口功能塊
- 獨立于系統配置表示應用的模型
- 分布式系統的系統，裝置和資源的模型
- 将應用賦予不同裝置和資源的分布式模型
- IEC61499 項交換和存儲模型
在我們詳細研究IEC61499的許多模型和概念之前，我們重新思考在引言一章讨論的關于IEC61499 的範圍。IEC61499 的主要目的不是程式設計方法，而是分布式系統的架構和模型。IEC61499 使用功能塊概念提供了一組模型，描述分布式過程測量和控制系統使用功能塊概念的行為和結構。這是必須了解的重要差別。避免引起對IEC61499 産生誤解。
IEC61499 提供了術語，模型和概念，以利于明确，形式化地實作面向分布式控制系統的功能塊。使用形式化的，标準化地描述系統有利于系統的驗證，比較和了解。這是朝向分布式系統标準化程式設計方法學的第一步。IEC61499 标準的編寫者提出的觀點是如果沒有支撐我們編寫程式的一緻性架構，不可能由一緻的程式設計方法。
我們現在來研究IEC61499 引入的各種模型，形成面向分布式工業過程測量和控制系統的功能塊架構。
2.1功能塊模型
該标準的核心是功能塊（function block）模型。它構成了完整的IEC61499 架構。功能塊可以描述成為“軟體的功能子產品“。它具有自己的資料結構，并且由一個或者多個算法來處理它們。功能塊類型（function block type）提供了資料結構和算法的形式化描述。功能塊可以有多個執行個體（instance）。從形式上看，功能塊和C++中的對象非常類似。在工業實踐中，也經常使用功能塊的概念，例如在許多PLC 和工業控制器中就有PID 功能塊。許多廠商提供一個PID 功能塊定義。程式員可以在控制算法中使用多個PID的執行個體，比如稱為“Loop1”和“Loop2”，它們互相之間是獨立的。每個PID 執行個體都有它們自己的參數和内部狀态變量。也共享相同的更新算法。
IEC61499 定義了若幹形式的功能塊。在下面的章節中，我們會來詳細地了解它們。IEC61499 功能塊的主要特征總結如下：
每個功能塊有一個類型名稱和一個執行個體名稱。
該标準的核心是功能塊（function block）模型。它構成了完整的IEC61499 架構。功能塊可以描述成為“軟體的功能子產品“。它具有自己的資料結構，并且由一個或者多個算法來處理它們。功能塊類型（function block type）提供了資料結構和算法的形式化描述。功能塊可以有多個執行個體（instance）。從形式上看，功能塊和C++中的對象非常類似。在工業實踐中，也經常使用功能塊的概念，例如在許多PLC 和工業控制器中就有PID 功能塊。許多廠商提供一個PID 功能塊定義。程式員可以在控制算法中使用多個PID的執行個體，比如稱為“Loop1”和“Loop2”，它們互相之間是獨立的。每個PID 執行個體都有它們自己的參數和内部狀态變量。也共享相同的更新算法。
2.1.1一般特性
IEC61499 定義了若幹形式的功能塊。在下面的章節中，我們會來詳細地了解它們。IEC61499 功能塊的主要特征總結如下：
- 每個功能塊有一個類型名稱和一個執行個體名稱。它們在功能塊圖形化描述時，會顯示出來。
- 每一個功能塊都能有事件輸入。它們能夠接收其它功能塊通過事件連接配接傳遞的事件。
- 每個功能塊都能有事件輸出。它們向其它功能塊傳遞事件。
- 每個功能塊會有資料輸入。傳遞給它其它功能塊内部産生的資料。
- 每個功能塊會有資料輸出。将該功能塊内部産生的資料傳遞該其它功能塊。
- 事件可以使用”WITH“修飾詞與資料關聯。在圖形表示中，将事件和相關聯的資料連接配接線交叉點畫一個小方塊。對于輸入和輸出的含義如下：
-當一個事件發生時，它關聯的資料更新。其它輸入變量保持它們的值（也就是說，沒有變化）
-當輸出事件觸發時，關聯資料輸出有效，而其它資料沒有發生變化。
- IEC61131-3的資料類型用作變量的資料類型（見附錄A 可用資料類型）
- 功能塊封裝功能，它們具有内部變量。功能的形式和類型由功能塊類型決定。
- IEC61499不允許有全局變量。
- 所有功能塊資料（輸入，輸入和内部）在功能塊每次調用之間要加以保留。
在圖2.1中，描繪了IEC61499 功能塊的主要特性。在功能塊的頂部，稱為“執行控制”段，包含了将事件映射到封裝功能的定義。也就是說，它定義了在“執行控制”中，到來的事件觸發哪一個封裝的功能，什麼時候輸出事件被觸發-标準稱之為：“輸入事件，輸出事件，封裝功能執行之間的因果關系”，标準定義意味根據不同的功能塊類型，實作事件輸入端事件到達，封裝功能的執行，輸出事件的觸發的映射關系-它們将在後面的章節按不同功能塊類型分别讨論。
功能塊的低端（Low portion） 包含了封裝的功能以及可能存在的内部資料-兩者都隐藏在功能塊内部。功能塊是一種類型的軟體元件。如果設計完善，使用者不需要詳細了解其内部的設計。
功能塊依賴于包含它的資源，資源提供了排程封裝功能，映射通信和過程接口的機制。
标準指出，作為選項，資源能提供額外能夠通路功能塊内部的性能。比如說，在一個現場總，線裝置的中，如果能夠檢查功能塊内部的變量，對應維護和調試是有用的。是以，有“後門”的方式通路功能塊内部。不過從IEC61499 架構的觀點看，控制變量和事件隻能通過外部暴露接口來通路。
注意：IEC61499 功能塊包含了所有定義它們完整行為二點算法和初始化值。
2.1.2 功能塊的執行模型
執行模型通常将功能塊定義成為“被動元件”。 需要一個輸入事件觸發來調用它封裝的功能，執行順序由圖2.2 描述。在該功能塊中的數值圓圈顯示功能塊不同部分執行順序。該模型假設功能塊所在的執行環境提供一個排程功能，保證功能塊的各個部分按正确的順序和優先級執行。進一步地，标準将功能塊的執行定義為算法。這意味着它将在一定時間内結束。是以，在功能塊中不允許有挂起操作單元。對于實時受限的應用而言，它的執行時間是嚴格受限的（也就是要低于應用指定的門限）。
有一定數量的離散階段。當請求功能塊執行時，它們每個都耗費一段時間。每個階段都依據功能塊和整個排程功能之間定義·的互動決定的。圖2.2 描述功能塊操作的8個最常見的步驟。每個階段的中止都有一個數值編号的步定義
- 其它功能塊提供的資料在資料輸入端有效
- 輸入事件到達，資料被采樣，并且通知執行控制。
- 基于功能塊執行控制的目前狀态，通知排程功能，某一個封裝的功能準備執行。
- 一段時間之後，排程功能開始執行請求的功能塊封裝功能。時間的長短依賴于資源的裝入和性能。
- 分裝的功能完成完成其任務，處理輸入值。在有些場合要處理内部存儲的值，産生寫道功能塊輸出端的新的輸出值
- 封裝的功能完成它的執行，并且通知排程功能更新的輸出值已經穩定就緒。
- 排程功能調用功能塊的執行控制。通知它封裝功能已經完成，并使它産生一個輸出事件。根據輸入事件端到達的事件和執行控制的内部狀态，将産生不同額輸出事件（或者沒有事件輸出）
- 執行控制在功能塊輸出事件接口依次建立相應的輸出事件。并使相關的輸出變量對連接配接的功能塊可用（采樣到連接配接）。輸出事件用來觸發後續功能塊的執行。通知它們現在可
以使用該功能塊産生的輸出值。
注意：在第2步采樣輸入變量以後，輸入變量值在有事件觸發的整個功能塊執行期間不會發生改變。這樣保證在封裝功能執行過程中，保證資料值的穩定和确定性。
這裡表述的執行步驟序列是當輸入事件到達時産生的大多數基本執行序列。根據輸入事件端到達的事件和執行控制内部的狀态。3-8 步可能執行若幹次。在這種場合下，在一個輸入事件的響應中會發送多個輸出事件。
重要的是要注意：在這個執行模型上有一系列的限制。這些事件階段不能夠重疊。必須按照功能塊預定的順序正确地執行，然而，在某些實作中，某些階段可以在周期中很斷，以至于認為它們是同步額。IEC61499 沒有定義任何這些事件的限制。不過它指出，在任何功能功能塊模型中可以定義這些不同階段的周期。以便建立完整功能塊網絡的時間特性的精确模型
标準定義下列周期在建立應用時是有意義的：
Tsetup=T2-T1 輸入事件到達與輸入值可用（由前續功能塊更新）之間的時間
Tstart=T4-T2 接收到一個輸入事件到執行功能塊封裝功能塊之間的時間。這個時間間隔與資源裝入性能有關。也就是，有多少其它隊列排列在排程功能的隊列中。
T algorithm =T6-T4 功能塊封裝功能繁榮開始到完成的時間
T finish=T8-T6 從功能塊封裝功能完成到觸發輸出事件的時間。
這些時間點的互相關系在圖2.3 中描述功能塊改變輸入輸出資料的時間點同樣也顯示了出來。值得注意的是；标準假設事件行為是事件的離散點，沒有循環。在一個實體系統中，事件需要某種形式的狀态轉換。從挂起到一小段短而且有限的期限。
IEC 61499模型假設在一個功能塊的輸入端沒有輸入事件和資料隊列。然而，标準定義了在執行環境需要保證在任何一個時間點隻送出一個事件。執行環境能夠有選擇地使用事件隊列，保證在功能塊執行期間不會丢失事件。當一個功能塊接收到的輸入事件比功能塊能夠處理事件的時間快時，執行環境能夠檢測到是很重要的。進一步地，實作要提供輸入資料隊列。不過這不是IEC61499 顯式模型。然而，這樣的行為可用通過特殊功能快來模組化。模型允許資源利用多任務處理功能塊算法。在排程功能中，使用恰當的優先級。對于大多數事件而言，能夠克服過載的問題。不過，排程功能的内部行為和特性不是标準的範圍。已有功能塊不同實作選項的較長的描述在【20】中給出。
2.1.3 功能塊類型（Function block types）
IEC61499 的一個重要的概念就是能夠定義功能塊類型。功能塊類型定義了功能塊執行個體的行為和接口。功能塊執行個體能夠通過類型來建立。這和面向對象軟體中對象的行為由相應的對象類來定義方式是類似的。
功能塊類型通過類型名稱，功能塊輸入輸出事件的形式化定義，和輸入輸出變量的定義來定義的。類型定義還包括了功能塊的内部行為。對于不同類型功能塊，定義的方式是不同。
基本功能塊類型（Basic function block）
基本功能塊的行為是以相應輸入事件的算法來定義的。當事件執行時，觸發輸出事件，标志功能塊内部的某些狀态發生了改變。算法上的事件的映射是通過狀态轉移來辨別的，它被稱之為執行控制圖（Execution Control Chart （ECC）
複合功能塊類型（Composite function block）
複合功能塊的行為是通過一個功能塊執行個體網絡來定義的。是以，定義包括了内部功能塊執行個體之間的資料和事件連接配接。
服務接口功能塊類型（Service interface function block types）
服務接口功能塊提供了功能塊域和外部服務之間的接口。例如，與遠端裝置中的功能塊進行通信，或者讀取硬體實時時鐘的服務。因為一個服務接口功能塊類型主要涉及資料互動，它使用服務序列圖。服務序列圖在3.3節有更詳細的描述。
2.2應用模型
一個IEC61499 應用定義為一個互聯的功能塊網絡。由事件和資料流連接配接。是以說，一個應用程式包括了若幹個功能塊執行個體和它們之間的互相連結定義。使用功能塊來描述所有的行為是IEC61499的基本原理。于是我們看到，在一個應用中，除了功能塊以外，沒有任何全局變量和本地變量。這是基于IEC61131-3的PLC和IEC61499 應用的根本差別。
IEC61499應用程式的特征如圖2.4所示。事件連接配接通常是點對點的連接配接。從一個事件輸出連接配接到一個事件輸入。資料連接配接标準允許”扇出”連接配接方式（fan-out connection style）。也就是說，一個資料輸出可以連接配接多個資料輸入。扇入（fan-in），也就是多個輸出連接配接到一個資料輸入是不允許的。這樣做的理由是功能塊在IEC61499 中是完全解耦的，沒有資料源的資訊。如果允許扇入，功能塊将無法确定從那個資料連接配接上取資料。最後，輸入的事件和資料不一定源自于同一個功能塊（例如圖2.4中的FB1）。這對于采樣和處理多個源的資料需要同步與一個事件的場合是有用特性。
注意：為了簡潔，事件和資料的輸入輸出名稱在圖2.4 中省略了。
現實中，應用程式是完整的一組功能塊和互相連接配接，解決某個特定的制動控制問題。例如，一組功能塊控制一條生産線，一個塑膠擠出機，或者發酵爐。在這個階段，應用程式模型不需要考慮任何硬體。隻需要重點關注全面的控制功能。是以，相比于IEC611131-3應用程式開發是非常聚焦資源。而IEC61499 應用開發是應用為中心的。
2.3 系統模型
在實體層，分布式系統由若幹裝置通過各種網絡連接配接，支撐一組互相協作操作的應用。諸如生産線控制，容器或者傳輸帶處理等應用通常需要運作在一定數量裝置上的軟體協同操作。直到最近，遠端分布式應用都是運作在遠端裝置上的小百分比軟體。比如環路和溫度控制器。而主要的智能控制都放置在後端的中心處理器上面，比如PLC。随着諸如智能傳感器和執行部件這樣的裝置開始提供更多的處理能力。軟體功能能夠真正分布于多個裝置上。到了這一點，很難辨別出主要的控制裝置
2.3.1 總體系統結構
我們從IEC61499 定義的系統模型的頂端開始研究。這個模型定義了若幹控制裝置和它們之間的通信關系，建構成一個通信裝置的網絡。通信鍊路可以有不同的類型，而裝置可以連接配接到不同的通信網段。這樣能夠形式化通信的分層結構，如同2.5 所示。
2.3.2 裝置模型
在圖2.6 中顯示的裝置模型描述了支撐ICE61499 功能塊網絡執行的實體控制裝置的總體結構。裝置的主要目的是提供一個或者多個資源的基礎架構。IEC61499 的資源類似于PLC 标準IEC61131-3 中資源的概念。資源提供了功能塊網絡的執行環境。然而，相比于IEC611131-3，一個IEC61499 的資源并不限制在一個執行單元中，
一個裝置具有一個“過程接口（process interfance）”，它提供了資源與實體裝置上IO點交換資料的服務。也具有一個通信接口，提供資源和外部裝置中的資源通過網絡交換資料的服務。如同圖2.5 所示，一個裝置能夠連接配接到一個或者多個網絡中。
2.3.3 資源模型
資源是支撐功能塊網絡執行的設施和服務。
資源提供了與通信系統和“裝置特定服務device specific services”的接口。比如裝置的I/O子系統或者顯示。比如，比如每個資源都具有通信系統的接口。讓功能塊能夠與遠端資源中的功能塊交換資料。也有一個接口讀寫裝置I/O。是以，資源通過裝置的通信接口将本地資源的資料和事件流與遠端資源的功能塊實作映射。同樣地，資源将所有的裝置IO讀寫請求映射到過程接口。很清楚，資源定義了IEC61499 模型的範圍和裝置和系統特定功能之間定義了邊界。包括了作業系統設計和通信協定。指定了标準以外的裝置和網絡的類型。
圖2.7 描述了IEC61499資源的主要特性。
在資源中，表明一個網絡互聯功能塊連接配接了資料和事件流，一個由資源提供的排程功能（scheduling function）保證了功能塊中的功能按正确的順序執行。服務接口（Service interface）功能塊是一種特殊形式的功能塊，提供了功能塊和資源接口之間的連接配接。例如，通信服務功能塊能夠讀，發送遠端功能塊的資料，在IEC61499 中定義了一系列的不同類型的服務接口塊，将在第五章描述。
資源的一個重要特性就是它支援獨立的操作。一個資源能夠獨立地裝入，配置，啟動和停止。不會影響相同裝置和網絡中其它資源。然而，值得注意的是，管理分布式應用，需要若幹資源協同控制
2.4 分布式模型
分布式模型使用系統模型連接配接系統獨立應用模型，它涉及到将應用的各個部分映射到裝置和資源，并且完成應用的特殊配置。
2.4.1 映射應用
應用可以是“分布式”的，也就是說，配置和運作在若幹的資源之上。一個分布式應用由若幹段功能塊網絡構成，每一段功能塊網絡運作在指定的資源之上。注意，IEC61499 考慮的分布式涉及将應用的功能塊配置設定到裝置的不同資源上，這些裝置在系統模型中定義。為了實作這樣的配置設定，要使用映射語句（mapping statement）。圖2.8 顯示了将我們在圖2.4 的應用例子映射到圖2.5 的系統模型上。
IEC61499 系統和分布式模型的一個特性是允許裝置執行一個或者多個應用。标準按如下的方式定義裝置模型，可以裝入一個或者多個分布式應用，不會破壞已有的應用。這是通過在裝置中使用管理服務來實作的-這将在後面的章節中介紹。
由于裝置能夠支援多個資源，是以将不同的應用映射到不同的資源（圖2.9），能夠在裝置中區分不同的應用。進一步地，也能夠将應用映射到一個裝置上，也就是在同一個裝置的不同資源（圖2.9的應用2）
應用的事件時間性能取決于它分布的資源和通信網絡，比如兩個相同的傳送帶控制應用，一個運作在1GB 的光纖網上，另一個運作在低成本的1M雙絞線上，由于通信的資料速率如此不同，顯然兩個應用由于網絡延時不同，它們将明顯具有不同的性能和響應事件。盡管它們的内部軟體算法是一緻的。
相比之下，假設功能塊是不可分割的“原子”，它隻能運作在一個單一的資源上。從這個意義上講，功能塊的性能不受到通信網絡性能的影響。然而性能會受到包含該功能塊執行個體的資源和裝置的性能和行為的影響。這些分布式特性總結在表2.1中
2.4.2 平台的特定配置
應用映射的結果有兩個方面，應用的分布式導緻功能塊之間的直接連接配接斷開（例如FB4和FB5之間的連接配接）。第二個方面是系統特定的配置，比如指派實體輸入端口位址，以便提供傳感器的值。這些特定的配置不是應用模型的一部分，它們是平台和系統獨立的。
為了處理這一項，IEC61499 允許增加系統特定配置值和擴充在資源中的應用部分。平台特定的應用擴充典型的是插入通信服務接口功能塊以及它們的配置（比如通信通道的辨別符）。這些通信服務接口維持了裝置和資源之間“斷開”的連接配接。如圖2.10
粗一看，這些系統配置的特定适配是不需要的，然而，它強力地支援了應用的平台獨立性。應用的設計過程的重點放在關注控制的功能。平台特定的配置放在在研發周期的後期，有利于應用和部分應用的重應用性。進一步地，它的優點是以後修改裝置和系統配置不影響應用的開發。
2.5 管理模型
我們已經看到，資源能夠支援功能塊網絡分段。構成分布式應用部分。但是，這些應用如何分段和管理的呢？IEC61499 的設計考慮到了适配可配置自動系統的需要。這需要系統在運作的時候可以遠端改變資源和其中包含的功能塊網絡。而且對控制的過程沒有影響，或者影響極小。是以，IEC61499 定義了一個管理應用（Management Applications）的管理接口和管理項目的通用行為模型（例如資源，功能塊執行個體和它們的互相連接配接）
2.5.1 管理應用（Management Applications）
IEC61499 定義了一個特殊形式的應用，稱為管理應用。它的主要職能就是管理資源的應用生命周期和資源中的功能塊網絡。管理應用相比普通應用而言，具有更高等級的權限。能夠通過建立/删除功能塊和連接配接來建構/結構其它應用的部件。它通常通過連接配接到外部站點（比如 遠端程式設計工作站）的通信接口來提供管理功能的。
管理應用的功能需求包括：
- 在一個資源中建立功能塊執行個體
- 建立功能塊執行個體之間的事件和資料連接配接
- 設定資源和功能塊執行個體的參數
- 初始化功能塊執行個體的執行，作為分布式應用的一部分
- 改變資源和功能塊執行個體的操作狀态
- 提供支援來自通信鍊路的隊列服務
- 功能塊執行個體的狀态，包括操作狀态和輸入輸出值
- 目前功能塊執行個體和它們的連接配接
- 删除功能塊執行個體
- 删除資料和事件連接配接
一個重要的限制是管理應用要能夠裝入不同應用的功能塊網絡段，但是不打攪正在執行的其它應用。
管理應用裝入普通應用，那麼管理應用自身是如何裝入的呢？假設在裝置中需要在管理應用中具有某個層面基本功能來“bootstrap” 裝入主應用的功能塊。部分管理應用将存在裝置的非易失性存儲器中。當裝置上電是總是能夠裝入應用程式
注意： 有些裝置将所有的功能塊網絡存儲在非易失性存儲器中，不能通過外部通信加以修改。在這種情況下，管理應用的大部分功能不再需要。
标準推薦兩種管理應用的方案。圖2.11a 描繪了裝置具有專門的管理資源。其中包含了管理應用，提供在裝置提供的資源中提立和維護功能塊網絡的功能。圖2.11b 是另外一種管理方式，在每個資源中包含一個管理應用，能夠在相同的資源中裝入功能塊網絡
管理應用可以采樣與其它使用功能塊網和服務接口功能塊的應用類似的方式模組化。管理應用需要一定數量的服務接口功能塊來處理與外部通信鍊路的接口。過程需要請求建立功能塊執行個體。更進一步地，服務接口功能塊将提供通路外部執行環境，完成管理任務。一個這樣的功能塊和需要的服務在5.5 節給出。
标準也預計到這樣的情形，某些特權的功能單元将控制其它的功能單元。例如，裝置A中一個“作業裝入”功能塊會用來裝入新的功能塊定義到遠端裝置B和C ，修改用于某種批量處理的應用。在這樣的情形下，需要能夠給定某些功能塊權限，裝入，配置和改變其它功能塊的狀态。在本章導入的管理應用将明确地需要特權裝入和啟動完整的應用。
管理應用功能的完整定義已經超出了IEC61499 的範圍。然而很明顯，以一種一緻的方法裝入和配置IEC61499 相容裝置是非常重要的。IEC61499 相容概述檔案在IEC61499 Part 4 描述，它需要清晰地定義管理功能如何實作。管理應用和管理功能塊的定義提供了需求指南。在8.3 節和附件B 給出更多相容性概況檔案的資訊。
2.5.2管理項的操作狀态模型（Operational state model of managed entities）
是以，在功能塊網絡中，IEC61499提出了操作生命周期的概念施加到功能單元，比如裝置，資源和功能塊。這一操作生命周期可以像公共狀态機的形式修改。它清晰地定義所有管理項何時允許事件處理，處理資料和産生輸出資料和事件，下面是在不同的狀态完成的公共操作。
IDLE：當進入狀态IDLE，管理項初始化，例如，功能塊的變量設定為預設值。
RUNNING：在這個狀态，管理項完成它的正常操作，對于資源而言，這意味着遞交事件，排程功能塊執行。對于功能塊而言，這意味着根據2.1.2小節展示的執行模型處理輸入事件。
STOPPED 當進入這個狀态，結束目前觸發的執行，之後沒有更進一步的執行（功能塊完成有一個輸入事件觸發的動作，不接受更進一步的輸入事件）
KILLED 當進入這個狀态，目前執行被中斷，沒有更進一步的執行完成。這将該管理項停留在非法狀态。是以，KILL ED 管理項隻能被删除和複位到初始狀态，以便更進一步使用。
圖2.12顯示了允許不同狀态之間轉移的狀态機。
2.6 IEC61499 的交換格式
能夠在不同軟體工具和平台上交換所有IEC61499 的模型是IEC61499标準非常重要一部分。在不同産品和系統之間交換功能塊将對最終使用者帶來明顯的好處。這包括在不同的硬體和系統配置中重複使用（reuse）功能塊帶來的成本節約。IEC61499 提供了兩種選擇 （i）形式化文本格式 （ii） 利用web技術的XML。
2.6.1 IEC499的文本文法
IEC61499 的明顯特性是采用富文本文法以文本形式描述模型，比如應用，系統配置，和功能塊。無二義性的文本定義使得自動和明确地産生模型的圖形表示。舉例來講，一個應用有若幹個具有适當參數，并且連結資料和事件的功能塊構成的網絡。該應用的所有設計可以使用IEC61499 的文本格式來表示。
可以想象，通過編譯文本模型，可以檢查模型的正确性。文本文法對于将模型從一個平台移植到另一個平台是有幫助的。它定義了語義，而不是完整詳細的圖形描述。例如功能塊在設計的時候可能放置在某一個位置。在另一個平台上，位置和圖形的細節，比如顔色，字型等可能有所不同。但是功能塊之間的連結是準确的。
應用執行個體
這裡我們用一個簡單的應用來展示文本文法的特性。文法的許多特性我們在後面的章節描述。
考慮一個實作PID 算法來控制一個容器的壓力。一個壓力傳感器提供目前的壓力，容器中的壓力可以通過一個泵來改變。這能夠使用一個有三個功能塊構成的應用來建立模型如圖2.13 所示。Sensor 功能塊提供周期性更新目前壓力值，它觸發PID 控制器計算所需的泵的值，Actuator 功能塊将該值施于泵。該應用執行個體的文本描述如下：
APPLICATION Controller (* Pressure control loop *)
FBS
Pressure : Sensor(
DT := T#100ms);
Controller : PID(
SP := 1.0,
KP := 2.3,
TR := T#1s400ms,
TD := T#25ms);
Pump : Actuator;
END_FBS
EVENT_CONNECTIONS
Pressure.IND TO Controller.REQ;
Controller.CNF TO Pump.REQ;
END_CONNECTIONS
DATA_CONNECTIONS
Controller.U TO Pump.VAL;
Pressure.VAL TO Controller.PV;
END_CONNECTIONS
END_APPLICATION
在該例中，要注意下面幾點：
- 應用由名稱辨別，在本執行個體中是Controller
- 功能塊參數在功能塊執行個體說明時給定
- 事件和資料連結由不同的組分割，它們分别是EVENT_CONNECTIONS 和DATA_CONNECTIONS,
2.6.2 XML-交換格式
在IEC61131-3 PLC 軟體标準中，不同廠商的軟體設計的交換能力受到了一系列的限制。這是因為IEC-61131-3 中失敗地包括檔案交換格式的全定義。在不同的軟體工具之間無法交換IEC61131-3 圖形化PLC 軟體。為了克服這個限制，PLCOpen 組織開發了一個基于XML 的檔案交換格式。盡管這個檔案格式改善了這樣情形。他仍然允許廠商指定擴充，限制了移植。
在IEC61499 發展的早期，這缺點是同樣存在的。為了克服這個缺點，在PLCOpen 之前，就考慮将XML 作為可選項。這就是在IEC61499 的Part 2 中使用了基于DTD （Document Type Definitions）格式的XML結構。
XML 格式除了提供IEC61499 模型的結構化特征以外，還包括圖形布局資訊（比如 功能塊的位置，連結的轉彎點）。這些與廠商中性的（無關）。
應用執行個體
圖2.13 壓力控制器的XML 描述如下：
<Application Name="Controller" Comment="Pressure control loop">
<SubAppNetwork>
<FB Name="Pump" Type="Actuator" x="2358.8235" y="570.5882">
</FB>
<FB Name="Controller" Type="PID" x="1329.4117" y="382.35294">
<Parameter Name="SP" Value="1.0"/>
<Parameter Name="KP" Value="2.3"/>
<Parameter Name="TR" Value="T#1s400ms"/>
<Parameter Name="TD" Value="T#25ms"/>
</FB>
<FB Name="Pressure" Type="Sensor" x="476.47058" y="382.35294">
<Parameter Name="DT" Value="T#100ms"/>
</FB>
<EventConnections>
<Connection Source="Pressure.IND" Destination="Controller.REQ"
dx1="247.05882" dx2="0.0" dy="0.0"/>
<Connection Source="Controller.CNF" Destination="Pump.REQ"
dx1="364.70587" dx2="0.0" dy="0.0"/>
</EventConnections>
<DataConnections>
<Connection Source="Controller.U" Destination="Pump.VAL"
dx1="164.70587" dx2="0.0" dy="0.0"/>
<Connection Source="Pressure.VAL" Destination="Controller.PV"
dx1="364.70587" dx2="0.0" dy="0.0"/>
</DataConnections>
</SubAppNetwork>
</Application>
在這個例中，由下面幾點值得注意：
- XML 描述的總結構和文本文法相同
- 文本文法更加簡約和可讀
- XML 表示增加了圖形布局資訊，在我們的例子中，它提供了功能塊的位置，連結的彎曲點（dx1，dx2和y）。這資訊不影響功能。
2.7 小結
我們現在已經觀察了由IEC61499 導入的主要概念。提供了面向功能塊的分布式系統的模組化架構和架構。小結如下
- IEC61499 的核心元素是功能塊。功能塊以事件觸發的方式執行。這就是說，功能塊的執行是由輸入事件觸發的。
- 基本功能塊和複合功能塊處理不同形式的功能塊結構和功能塊分層結構。
- 服務接口功能塊提供網絡通信和其它通信設施。
- 應用能夠通過執行個體化功能塊，互聯它們的事件和資料的輸入和輸出獨立于控制硬體地開發，
- 系統模型定義了一組互連裝置。能夠通過網絡連接配接互相通信。
- 裝置模型支援支援一個或者多個資源，資源提供對裝入，配置，和執行功能塊網絡。
- 一個應用可以留駐在一個或者多個資源。每個資源支援一部分應用的裝入和配置，每一部分可以是一段分布的功能塊網絡。
- 掌握這些模型，IEC61499 控制系統開發工作流程由下面的步驟執行。
- 通過執行個體化功能塊和連接配接它們為應用模組化
- 通過指定裝置，它們的資源以及裝置之間的通信聯絡為系統模組化
- 将應用分布到控制裝置的資源
- 完成平台特定的參數和插入通信功能塊
- 利用管理接口将分布式應用部署到裝置上。
- IEC61499 提供兩種可移植方式的交換模型
- 文本文法提供形式化規範方法
- XML 交換形式，并包含圖層資訊