Stateflow教程

stateflow教程 Stateflow概述 Stateflow是集成于Simulink中的圖形化設計與開發(fā)工具 主要用于針對控制系統(tǒng)中的復雜控制邏輯進行建模與仿真 Stateflow適用于針對事件響應系統(tǒng) ReactiveSystem 進行建模和仿真 與事件響應系統(tǒng)相對應的就是動態(tài)變換系統(tǒng) DynamicTransformationalSystem 動態(tài)變換系統(tǒng)通?？梢岳脭?shù)學表達式 方程等組成的輸入 輸出關系進行描述 像這樣的系統(tǒng)利用Simulink進行建模是最為方便的 而事件響應系統(tǒng)通常利用一些自然語言或者邏輯表達式進行描述 這樣的系統(tǒng)就需要利用Stateflow來進行建模 Stateflow與Simulink結合起來 可以創(chuàng)建確定性監(jiān)管控制系統(tǒng) 利用Stateflow可視化的模型和直觀的仿真能力 可以清晰 簡潔地反映出復雜動態(tài)邏輯關系 Stateflow的基礎是有限狀態(tài)機理論 它通過對狀態(tài)圖 流程圖的創(chuàng)建 對事件驅(qū)動系統(tǒng)進行建模和仿真 第一章創(chuàng)建狀態(tài)圖 Stateflow編輯器創(chuàng)建和編輯狀態(tài)圖 Stateflow編輯器 創(chuàng)建Simulink模型1 直接在MATLAB命令行窗體中鍵入指令sfnew2 打開Simulink庫瀏覽器 在庫瀏覽器中找到Stateflow的模塊庫 雙擊模型文件或者庫文件中的Stateflow圖塊打開Stateflow編輯器 執(zhí)行Stateflow編輯器File菜單下的ChartProperties命令 打開屬性框 創(chuàng)建和編輯狀態(tài)圖 插入圖形對象1 創(chuàng)建狀態(tài)在圖形對象面板的狀態(tài)圖標上按下鼠標左鍵并保持 將狀態(tài)Stateflow編輯器的空白區(qū)域中 Keyword StateActions就是狀態(tài)動作 為數(shù)據(jù)對象進行賦值或者進行數(shù)據(jù)對象的運算也可以通過狀態(tài)動作進行事件廣播以觸發(fā)其他系統(tǒng)的變化狀態(tài)動作的關鍵字主要有三種 entry 當狀態(tài)被激活時執(zhí)行相應的動作 exit 當狀態(tài)退出活動狀態(tài)時執(zhí)行相應的動作during 當狀態(tài)保持其活動狀態(tài)時執(zhí)行相應的動作 在狀態(tài)上單擊鼠標右鍵 在快捷菜單中選擇Properties命令 可以通過狀態(tài)的屬性對話框進一步定義狀態(tài) 2 創(chuàng)建連接節(jié)點 連接節(jié)點作為轉移通路的判決點或匯合點 也是在狀態(tài)圖中常用的圖形元素之一 特別是在流程圖中 由于流程圖不能包含任何狀態(tài) 因此只有依靠連接節(jié)點完成通路的連接和判斷分支 連接節(jié)點不是記憶元件 在圖形對象面板的連接節(jié)點圖標上按下鼠標左鍵并保持 將狀態(tài)拖放到Stateflow編輯器的空白區(qū)域中 節(jié)點上單擊鼠標右鍵 通過彈出的快捷菜單執(zhí)行Properties命令 進入屬性框 3 創(chuàng)建轉移 轉移是Stateflow框圖中最常見的圖形元素之一 無論是包含狀態(tài)的狀態(tài)圖中還是沒有狀態(tài)的流程圖中 幾乎都存在轉移 轉移描述的是有限狀態(tài)系統(tǒng)內(nèi)的邏輯流 轉移管理了當系統(tǒng)從當前狀態(tài)改變時 這個系統(tǒng)可能發(fā)生的模式改變 當轉移發(fā)生時 源狀態(tài)變?yōu)榉腔顒拥臓顟B(tài) 目標狀態(tài)變?yōu)榛顒拥臓顟B(tài) 轉移是帶有箭頭的線 這就使整個狀態(tài)圖或者流程圖成為了 有向圖 狀態(tài)或者流程之間的轉換 將直接受到轉移方向的約束 創(chuàng)建轉移的具體步驟是 1 當鼠標光標接近狀態(tài)的邊緣時 鼠標光標將變成十字形狀 2 按下鼠標左鍵并保持 將引出的轉移線拖放到目標狀態(tài)的邊緣即可 給轉移添加標簽的方法 1 左鍵單擊選中相應的轉移 此時轉移將顯示問號 2 左鍵單擊出現(xiàn)的問號 則進入文本編輯狀態(tài) 3 在光標處插入文本 4 單擊Stateflow編輯器中任意一處 結束標簽的插入 組成轉移標簽的四個部分不一定完整地出現(xiàn) 但是不論出現(xiàn)哪幾個部分 標簽的內(nèi)容必須按照上面指定的順序書寫 條件動作與轉移動作兩者之間的區(qū)別 條件動作在條件滿足的情況下就能夠執(zhí)行 而轉移動作需要在整個轉移通路都有效的情況下 在執(zhí)行轉移的時候才執(zhí)行 Stateflow中都可以使用三類語法元素作為動作 1 數(shù)學運算表達式或者邏輯運算表達式 2 調(diào)用函數(shù) 3 事件廣播 4 默認轉移 默認轉移是一類特殊的轉移 可以把它看做是狀態(tài)轉移的特例 默認轉移確定當有限狀態(tài)機或者父層次狀態(tài)處于活動狀態(tài)的時候 在其所有的子狀態(tài)中第一個被激活的狀態(tài) 根據(jù)有限狀態(tài)機的要求 當有限狀態(tài)系統(tǒng)被激活時 必有相應的確定的某個狀態(tài)被激活 而默認轉移就定義了當狀態(tài)機被激活或者層次模型中父層次狀態(tài)被激活時 具體哪個子狀態(tài)被激活 創(chuàng)建默認轉移的方法如下 鼠標單擊圖形對象面板中的默認轉移圖標 然后將默認的轉移 注意鼠標光標的變化 放置在狀態(tài)或者連接節(jié)點的邊緣 就可以完成默認轉移的創(chuàng)建了說明 Stateflow的狀態(tài)圖中 同一層次上的狀態(tài)只有兩種工作模式 一種叫做異或 OR 模式 另一種叫做并行 AND 模式 在異或模式下 同一層次上的子狀態(tài)必須有一個子狀態(tài)具有默認的轉移 同時該子狀態(tài)被稱為默認狀態(tài) 由于Stateflow是一種事件驅(qū)動模型建模環(huán)境 不允許出現(xiàn)模型運行的二義性 因此 正確的使用默認轉移就非常重要 因為默認轉移就是用來改變狀態(tài)機或者父層次狀態(tài)被激活時 相應的子狀態(tài)二義性的圖形元素在默認轉移上添加標簽的方法和在一般的轉移上添加標簽的方法是一樣的 可以在默認轉移的標簽上加上事件和條件來進行限制 也可以將動作和默認轉移相關聯(lián) 不過 一個有限狀態(tài)系統(tǒng)必須確保能夠正確地被激活 這一點在使用默認轉移時非常重要 因為狀態(tài)機的默認轉移只有一次執(zhí)行的機會 如果沒有明確的子狀態(tài)能夠被激活 系統(tǒng)會報告二義性錯誤 5 添加注釋 如果需要在Stateflow的框圖中使用LaTex字符集 則需要按照下列步驟完成 1 在已經(jīng)添加的文本上單擊鼠標右鍵 這時將顯示快捷菜單 2 選擇快捷菜單中TextFormat子菜單中的LaTexInstructions復選項 3 用鼠標單擊已經(jīng)添加的文本注釋 重新進入文本編輯模式 4 添加LaTex字符 例如鍵入y itAe alphax sin beta itt 5 在文本編輯區(qū)外單擊鼠標完成注釋的添加 此時的注釋內(nèi)容將變?yōu)閥 Aeaxsin bt 如圖所示 編輯圖形對象外觀 改變尺寸和位置 單擊右鍵 單擊右鍵 在注釋上單擊鼠標右鍵而出現(xiàn)的快捷菜單 在菜單中 共計有三個子菜單可以用來修改注釋文本的外觀 分別為 FontSize 設置注釋文本的尺寸 TextFormat 設置注釋文本的基本格式 包括粗體 斜體和LaTex字符支持 TextAlignment 設置注釋文本的對齊方式 包括左對齊 居中和右對齊 第二章狀態(tài)圖的仿真 狀態(tài)圖的基本概念事件數(shù)據(jù)對象狀態(tài)圖的更新模式stateflow模型查看器 狀態(tài)圖的基本概念 狀態(tài)圖管理和維護著當前模型中活動的狀態(tài) 一旦包含了狀態(tài)轉移的狀態(tài)圖處于活動的狀態(tài) 則狀態(tài)圖將一直處于這種活動狀態(tài) 直到整個模型仿真計算結束 并且 只要狀態(tài)圖處于活動狀態(tài) 則必定至少有一個狀態(tài)處于激活狀態(tài) 狀態(tài)圖從非活動狀態(tài)到活動狀態(tài)以及狀態(tài)之間的切換 都要由事件觸發(fā) 即在事件的驅(qū)動之下 狀態(tài)圖才能仿真運行 所謂Stateflow的事件觸發(fā) 就是事件驅(qū)動的發(fā)生 觸發(fā)可以由系統(tǒng)隱含發(fā)生 也可以按照要求顯性地定義 在Simulink中 顯性定義的事件就是某些過零信號的發(fā)生 也就是說 只有過零信號才能夠觸發(fā)狀態(tài)轉移的發(fā)生或者狀態(tài)機的激活 由這種觸發(fā)而引起的相應的動作執(zhí)行 被稱為事件驅(qū)動 事件 添加事件 執(zhí)行Stateflow圖形編輯器Add菜單下Event子菜單中的任何一個命令 例如執(zhí)行Local命令 則Stateflow將彈出如圖所示的對話框 Scope屬性 該屬性定義事件的作用類型 在Add菜單下的Event子菜單中具有三個菜單命令 分別為Local InputfromSimulink和OutputtoSimulink 通過這三個菜單命令定義事件 得到的Scope屬性不一致 具有Local屬性的事件是在狀態(tài)圖內(nèi)部發(fā)揮作用 具有InputfromSimulink屬性的事件是從Simulink框圖輸入到Stateflow中的 也就是Stateflow框圖的外部觸發(fā)事件 具有OutputtoSimulink屬性的事件是從Stateflow框圖輸出到Simulink中的 即利用Stateflow定義的事件驅(qū)動或者觸發(fā)其他Stateflow框圖或者子系統(tǒng)動作 如果用戶設置事件的Scope屬性為InputfromSimulink或者OutputtoSimulink 則添加事件的對話框會發(fā)生變化 Trigger屬性 Trigger屬性總共有四個可能值 分別為Either Falling Rising和FunctionCall 在Simulink條件執(zhí)行子系統(tǒng)中 特別是在使能或者觸發(fā)子系統(tǒng)中 觸發(fā)子系統(tǒng)工作的觸發(fā)源就具有不同屬性 觸發(fā)子系統(tǒng)的觸發(fā)源與這里的Trigger屬性的意義完全一樣 分別為雙邊沿觸發(fā) 下降沿觸發(fā) 上升沿觸發(fā) FunctionCall 函數(shù)調(diào)用 是一類比較特殊的觸發(fā)屬性 創(chuàng)建事件實例 運行過程中 單擊ManualSwitch模塊向Stateflow框圖發(fā)出事件 使用多個輸入事件 同一個Stateflow的圖塊可以使用多個輸入事件 但是 不論用戶為Stateflow的圖塊定義了多少個輸入事件 每個Stateflow的圖塊都只能具有一個事件輸入端口 因此 在向Stateflow的圖塊增加不止一個輸入事件時 需要將不同的事件通過Mux塊組合成為輸入事件向量 然后將組合后的輸入事件向量連接到Stateflow圖塊上 數(shù)據(jù)對象 Stateflow使用數(shù)據(jù)對象來管理維護Stateflow框圖內(nèi)部的數(shù)據(jù)信息 在Stateflow中 數(shù)據(jù)對象主要用于動作或者條件中 用戶既可以限制數(shù)據(jù)對象在相應的圖形對象內(nèi)部使用 也可以將數(shù)據(jù)對象作為Stateflow與Simulink模型之間的接口來使用 執(zhí)行Stateflow圖形編輯器的Add菜單中Data子菜單下的任何一個命令 例如Local 則Stateflow會打開如圖所示的對話框 Scope屬性 Local Input Output與事件相同Constant 所定義的數(shù)據(jù)對象在Stateflow模型中為常量即保持靜態(tài) 數(shù)據(jù)對象在Simulink Stateflow模型運行過程中其數(shù)值一般不發(fā)生變化 并且數(shù)據(jù)在模型中為只讀 不可寫的狀態(tài) Parameter 所定義的數(shù)據(jù)對象將通過Stateflow框圖的上層Simulink子系統(tǒng)封裝之后的參數(shù)獲取初值 也就是說當Stateflow的框圖位于某個封裝子系統(tǒng)內(nèi)部時 Stateflow的Parameter類型數(shù)據(jù)對象可以直接獲取封裝子系統(tǒng)設定的參數(shù) 具有Parameter屬性的數(shù)據(jù)對象與具有Constant屬性的數(shù)據(jù)對象類似 在整個仿真過程中 Stateflow不能修改其數(shù)值 DataStoreMemory 所定義的數(shù)據(jù)對象與Simulink數(shù)據(jù)空間共享 也就是說 該數(shù)據(jù)對象與Simulink工作空間中的某個數(shù)據(jù)對象相互綁定 此時該數(shù)據(jù)對象的名稱必須與Simulink工作空間中數(shù)據(jù)對象的名稱一致 數(shù)據(jù)類型模式 DataTypeMode Inherited類型的數(shù)據(jù)對象一般為Stateflow的輸入或者輸出數(shù)據(jù)對象 它能夠通過與Simulink模塊相連接的信號線來判斷具體的數(shù)據(jù)類型對象 Built in類型是Stateflow數(shù)據(jù)對象默認的數(shù)據(jù)類型 通常情況下 都使用Simulink內(nèi)建的數(shù)據(jù)類型作為數(shù)據(jù)對象的數(shù)據(jù)類型 Expression類型是指可以通過一個表達式來表示數(shù)據(jù)類型Fixedpoint類型用于模型的定點數(shù)據(jù)設置 若選擇了該類型 則可以完成Stateflow模型數(shù)據(jù)的量化處理 狀態(tài)圖的更新模式 不是所有的有限狀態(tài)系統(tǒng)都具有外部事件的定義 有些模型就沒有針對Stateflow模型定義任何輸入事件 可是Stateflow的模型依然能夠正常地運行 那么對于這種沒有定義任何輸入事件的系統(tǒng) 它是如何運行的呢 這就是狀態(tài)圖的更新模式所發(fā)揮的作用 Stateflow的框圖有三種更新模式 分別為Inherited Discrete和Continuous 系統(tǒng)默認使用Inherited更新模式 在這種更新模式下可能存在以下三種情況 1 有輸入事件定義 如果Stateflow框圖定義了輸入事件 并且Simulink提供了相應輸入事件 則整個框圖就按照所定義的事件觸發(fā)來更新 也就是說 在相應類型的事件發(fā)生時 Stateflow框圖進行相應的工作 例如狀態(tài)的轉移 動作的執(zhí)行等 2 未定義輸入事件但定義了輸入數(shù)據(jù) 如果Stateflow框圖沒有定義事件而定義了輸入數(shù)據(jù) 則Stateflow框圖按照其連接的Simulink輸入信號中更新頻率最高的信號更新周期來更新框圖 這相當于輸入數(shù)據(jù)的采樣更新觸發(fā)了Stateflow框圖的執(zhí)行 3 既未定義輸入事件又未定義輸入數(shù)據(jù) 如果Stateflow框圖既沒有定義輸入事件 又沒有定義輸入數(shù)據(jù) 則Stateflow框圖繼承其父層次模型的更新周期 如果Stateflow框圖位于系統(tǒng)模型的頂層 則Stateflow框圖繼承模型的仿真周期作為自己的更新周期 Discrete更新模式 是將Stateflow框圖看做有固定周期的離散塊 在設置該更新模式時 Stateflow框圖屬性對話框中的SampleTime屬性需要設置具體的更新周期 單位為秒 Continuous更新模式 則Stateflow框圖好比Simulink模型中的一個連續(xù)系統(tǒng)模塊 此時Stateflow的框圖將按照系統(tǒng)仿真步長完成更新 注意 如果為框圖定義了輸入事件 則框圖的更新模式就只能設置為Inherited 此時Stateflow框圖將嚴格按照事件的發(fā)生來驅(qū)動有限狀態(tài)系統(tǒng)的運行 當使用外部事件進行觸發(fā)更新狀態(tài)圖時 默認地 第一個事件的發(fā)生用來喚醒狀態(tài)圖 激活狀態(tài)圖 而不是進行狀態(tài)轉移的執(zhí)行 如果需要改變此模式 則需要設置Stateflow框圖屬性中的Execute enter ChartAtInitialization選項 選擇了該選項 則意味著當前的Stateflow框圖將在模型初始化階段就被激活 這樣 在后續(xù)的事件觸發(fā)過程中 就直接進行狀態(tài)的轉換了 第三章流程圖 轉移沖突流程圖的創(chuàng)建圖形函數(shù)stateflow模型調(diào)試器 概述 在Stateflow框圖中 流程圖是比較特殊的一種 流程圖中不包含任何狀態(tài) 它僅僅由連接節(jié)點和轉移組成 由于流程圖沒有任何狀態(tài) 因此流程圖就不包含任何記憶元件 Stateflow中只有狀態(tài)是記憶元件 所以 在一次更新之中 流程圖從檢測其默認轉移開始 到檢測完每一條有效的通路且到達不具備有效出口的轉移為止 在連續(xù)的兩次觸發(fā)之間 一直處于非活動的狀態(tài) 轉移沖突 所謂轉移沖突 就是在Stateflow框圖運行的過程中可能在某一時刻同時存在幾個有效的轉移 那么此時Stateflow將根據(jù)一些原則來處理這些沖突 這就是轉移沖突的處理原則 假設當前事件E發(fā)生并且條件C也滿足 則四個轉移通路都是有效的 即形成了轉移沖突 那么Stateflow是如何處理這種情況呢 原則 當事件發(fā)生需要進行轉移檢測時 Stateflow總是首先檢測具有最多限制的轉移 如果能夠滿足則執(zhí)行這個轉移 其他的有效轉移就統(tǒng)統(tǒng)忽略 1 如果此時發(fā)生的事件是E且條件C也滿足 即該轉移有效 則執(zhí)行這個轉移 其余的轉移就不再進行檢測和執(zhí)行了 2 條件不滿足則檢測只有事件限制的轉移 條件C不滿足 此時發(fā)生的事件是E 即該轉移有效 則執(zhí)行這個轉移 其余的轉移就不再進行檢測和執(zhí)行了 3 此時發(fā)生的事件不滿足 則接著檢測具有條件的轉移 如果此時條件C能夠滿足 即該轉移有效 則執(zhí)行這個轉移 其余的轉移就不再進行檢測和執(zhí)行了 4 如果條件和事件都不匹配 最后檢測的轉移就是那條無條件的轉移 由于無條件的轉移是肯定可以執(zhí)行的總結 轉移的檢測次序就是由上至下分別檢測 當系統(tǒng)發(fā)現(xiàn)一條有效的轉移時 就立即執(zhí)行 其他的轉移即使有效 也都被忽略了 同限制級別的若干條轉移同時有效 狀態(tài)Standby向High狀態(tài) Medium狀態(tài)和Low狀態(tài)的轉移都對使用條件進行了限制 根據(jù)前面的介紹 這三個轉移由于都僅僅使用條件進行了限制 因此它們具有相同的轉移檢測優(yōu)先級別 所以這個框圖在進行仿真的時候 就會報告轉移沖突錯誤 如果轉移從狀態(tài)出發(fā) 則從狀態(tài)的左上角開始 按順時針的方向決定轉移的優(yōu)先權 如果轉移從連接節(jié)點出發(fā) 則從連接節(jié)點的12點方向開始 按順時針的方向決定轉移的優(yōu)先權 幾何原則 用戶自定義檢測次序 兩個步驟 1 在Stateflow圖形編輯器中單擊右鍵 在彈出的菜單中選擇ExecutionOrder子菜單下的Enable Userspecifiedexecutionorder forthischart 命令 2 用鼠標右鍵單擊需要改變檢測次序的轉移 例如要修改上圖所示模型的第一個轉移檢測次序 則用右鍵單擊該轉移 在出現(xiàn)的快捷菜單的ExecutionOrder子菜單下選擇檢測次序 由于這里從狀態(tài)A到狀態(tài)B具有四個轉移 因此轉移執(zhí)行次序的選項為1 4 默認地 該轉移檢測次序為1 可以將其修改為其他數(shù)值 修改某一條轉移的檢測次序后 其他的轉移可以根據(jù)用戶指定的次序以及Stateflow默認的檢測次序原則進行重新排序 常用邏輯結構模型 if 條件 動作 if 條件 動作A else 動作B if 條件1 動作A elseif 條件2 動作B else 動作C if 條件1 動作Aif 條件2 動作B switch case for循環(huán)for index 0 index nloops index Action while循環(huán) while Condition Action do while循環(huán) do Action while Condition 流程圖回溯現(xiàn)象 if c1 act1 if c2 act2 elseif c3 act3 else act4 分析 假設 條件c1為真 條件c2和條件c3為假 注意 在流程圖中 僅存在轉移的檢測 而不存在轉移真正的執(zhí)行 所以 在流程圖中 所有的動作都需要在條件動作中完成 即使定義了轉移動作 在執(zhí)行流程圖的時候 轉移動作也不會發(fā)揮任何作用 在流程圖中 存在且僅存在一個終止節(jié)點 流程圖的更新執(zhí)行最終終止在流程圖的終止節(jié)點上 所有轉移通路都必須最終匯合到終止節(jié)點 為每一個分支節(jié)點提供無條件的轉移通路 用于控制一些異常情況或者未預料到的情況 流程圖不能出現(xiàn)回溯現(xiàn)象 如果流程圖位于Stateflow的Chart層次 則在連續(xù)兩次更新之間 整個Stateflow框圖處于非活動的狀態(tài) 狀態(tài)中的流程圖 該Stateflow框圖具有兩個狀態(tài) 狀態(tài)Normal和狀態(tài)Inverse 在這兩個狀態(tài)中都包含了流程圖 它們包含的流程圖十分簡單 就是根據(jù)輸入數(shù)據(jù)進行相應的邏輯判斷 然后決定具體的輸出 從框圖上看 這兩個流程圖的體系結構完全一致 有所區(qū)別的就是參數(shù) 即處理的數(shù)據(jù)不同 這里可以通過圖形函數(shù)的形式來完成模型的創(chuàng)建 創(chuàng)建圖形函數(shù) stateflow調(diào)試器 狀態(tài)面板 StatusPane 控制面板 ControlPane 選項面板 ControlPane 顯示面板 DisplayPane 狀態(tài)斷點 StateDuring 在執(zhí)行狀態(tài)的During動作之前進入調(diào)試模式StateEntry 在執(zhí)行狀態(tài)的Entry動作之前進入調(diào)試模式 StateExit 在執(zhí)行狀態(tài)的Exit動作之前進入調(diào)試模式轉移斷點 WhenTested 在轉移被檢測之前進入調(diào)試模式 WhenValid 轉移經(jīng)過檢測是有效的 在執(zhí)行前進入調(diào)試模式 事件的斷點 StartofBroadcast 在事件被廣播之前進入調(diào)試模式EndofBroadcast 在事件廣播結束后進入調(diào)試模式圖形函數(shù)的斷點 FunctionCall 在函數(shù)被調(diào)用之前進入調(diào)試模式 第四章有限狀態(tài)系統(tǒng) 層次化建模 狀態(tài)動作層次化建模歷史節(jié)點內(nèi)部轉移子狀態(tài)圖stateflow的查詢工具 狀態(tài)動作 entry 當事件發(fā)生 狀態(tài)被激活時執(zhí)行相應的動作exit 當事件發(fā)生 狀態(tài)退出活動狀態(tài)時執(zhí)行相應的動作during 當事件發(fā)生 狀態(tài)保持其活動狀態(tài)時執(zhí)行相應的動作onevent動作是指當狀態(tài)處于活動狀態(tài) 事件event發(fā)生 而狀態(tài)并不退出活動狀態(tài)時所執(zhí)行的動作 bind動作是指將事件或者數(shù)據(jù)對象與狀態(tài)綁定的動作 被綁定的事件只能由狀態(tài)以及狀態(tài)的子狀態(tài)進行廣播 而被綁定的數(shù)據(jù)對象只能由狀態(tài)以及狀態(tài)的子狀態(tài)中相應的動作進行修改 綁定的數(shù)據(jù)對象可以在其他狀態(tài)中被訪問 但是不能修改 綁定的事件可以被所有狀態(tài)監(jiān)聽 但是不能由其他狀態(tài)廣播 注意 在進行狀態(tài)動作的定義時 可以使用狀態(tài)動作關鍵字的簡寫方式 也就是說 在定義狀態(tài)動作時只要寫關鍵字的前兩個字符即可 例如定義狀態(tài)的entry動作 只要在狀態(tài)中定義 en data 即可 onevent動作是during動作的特例 兩者的區(qū)別就是 onevent動作需要有特定事件觸發(fā)才可能執(zhí)行 而during動作在有事件發(fā)生 但又沒有使狀態(tài)退出活動狀態(tài)時就可以執(zhí)行 討論車載播放器 onevent事件相當于during事件的子集 即當STEP UP事件發(fā)生時 首先執(zhí)行during動作 然后再來執(zhí)行onSTEP UP動作 這樣 在發(fā)生STEP UP事件時 track數(shù)據(jù)對象每次累加了兩次 數(shù)據(jù)對象data與狀態(tài)A進行了綁定 這樣在其他的地方就只能讀取data 而不能修改數(shù)據(jù)對象data 在動作中使用事件 輸出事件廣播所謂事件廣播 其實就是在動作中調(diào)用事件 事件廣播主要用來在Stateflow中影響其他狀態(tài)圖或者條件執(zhí)行子系統(tǒng)的運行 Simulink的條件執(zhí)行子系統(tǒng)有使能子系統(tǒng) 觸發(fā)子系統(tǒng)和函數(shù)調(diào)用子系統(tǒng) 利用事件廣播以及數(shù)據(jù)的輸出就可以在Stateflow中調(diào)用這些不同類型的子系統(tǒng) 完成復雜的工作 類型為InputfromSimulink的事件是不能夠通過狀態(tài)動作 轉移動作或者條件動作進行廣播的 此外 類型為Local的事件也可以進行廣播 這就是在第6章將要介紹的本地事件廣播 輸出狀態(tài)的活動情況Stateflow還可以將Stateflow狀態(tài)的活動情況輸出到Simulink 利用Stateflow框圖的活動情況可以觸發(fā) 使能其他子系統(tǒng)或者Stateflow框圖運行 從而實現(xiàn)系統(tǒng)的同步協(xié)調(diào)工作 函數(shù)調(diào)用子系統(tǒng)在Stateflow的事件類型中 存在類型為函數(shù)調(diào)用 FunctionCall 的事件 此類事件能夠觸發(fā)函數(shù)調(diào)用子系統(tǒng) 函數(shù)調(diào)用子系統(tǒng)是一類比較特殊的子系統(tǒng) 該類子系統(tǒng)在整個Simulink模型內(nèi)部運行起來就好比函數(shù)一樣 需要通過其他的系統(tǒng)來調(diào)用才能夠執(zhí)行 當Stateflow框圖中的轉移動作發(fā)出函數(shù)調(diào)用事件之后 系統(tǒng)首先執(zhí)行Simulink模型中的函數(shù)調(diào)用子系統(tǒng) 當函數(shù)調(diào)用子系統(tǒng)全部運行完畢 并將新的計算結果提供給Stateflow的輸入數(shù)據(jù)對象后 Stateflow才繼續(xù)激活相應的目標狀態(tài) 因此 在很多Simulink和Stateflow混合的系統(tǒng)模型中 都充分利用了這一 函數(shù)調(diào)用 特性 利用Stateflow模型來控制Simulink子系統(tǒng)的運行 合理完成數(shù)據(jù)的交互任務 綁定事件如果將事件與狀態(tài)綁定 則只有狀態(tài)內(nèi)的動作 狀態(tài)動作 或者子狀態(tài)的動作 子狀態(tài)之間的轉移動作和條件動作 能夠調(diào)用該事件 實現(xiàn)事件的廣播 事件廣播可以是輸出事件的廣播 也可以是本地事件的廣播 層次化建模 層次化模型的構成 層次化狀態(tài)圖的轉移轉移原則 1 子狀態(tài)的各種對象僅僅在父狀態(tài)活動時才有可能執(zhí)行或者有效 2 當存在直接從父狀態(tài)發(fā)出的轉移時 可以不用考慮具體哪一個子狀態(tài)處于活動狀態(tài) 3 超轉移優(yōu)先于子狀態(tài)之間的轉移而被檢測 case1 假設 當前Super1狀態(tài)處于活動狀態(tài)同時其子狀態(tài)Sub2也處于活動狀態(tài) 當事件E發(fā)生時 case2 如果Super2狀態(tài)處于活動狀態(tài) 同時其子狀態(tài)Sub4處于活動狀態(tài) 當事件E發(fā)生時 歷史節(jié)點 車載音響系統(tǒng)為例 每次打開車載音響時 音響總是恢復前一次關閉音響時的狀態(tài) 如果前一次關閉音響時正在收聽激光唱機 則再次打開音響時 音響總是會恢復打開激光唱機 甚至從關閉音響時正在播放的音軌處繼續(xù)播放歌曲 那么像這樣的系統(tǒng)用Stateflow來進行建模就需要使用Stateflow中的歷史節(jié)點 歷史節(jié)點是一種特殊的Stateflow圖形對象 它只能夠用于具有層次的狀態(tài)內(nèi)部 在層次化的框圖子狀態(tài)之間如果存在超轉移 則歷史節(jié)點也無法發(fā)揮作用 歷史節(jié)點能夠影響默認轉移的工作 使默認轉移僅在首次激活系統(tǒng)時發(fā)揮作用 其余的時間就依賴于歷史節(jié)點記錄的狀態(tài)來恢復子狀態(tài)的活動情況 內(nèi)部轉移 內(nèi)部轉移是一種特殊的轉移 就是指在狀態(tài)內(nèi)部的轉移 它從父狀態(tài)內(nèi)邊緣出發(fā) 終止于父狀態(tài)內(nèi)的子狀態(tài)或者連接節(jié)點邊緣上 也可以終止于狀態(tài)的內(nèi)邊緣 內(nèi)部轉移能夠適當?shù)販p小模型復雜度 提高模型的執(zhí)行效率 示例 討論關于自循環(huán)轉移的執(zhí)行 1 當前狀態(tài)A處于活動狀態(tài) 事件E發(fā)生 但是條件C1不滿足 2 事件E再次發(fā)生了 而且此時條件C1滿足 3 事件E第三次發(fā)生 此時條件C2不滿足 1 當前父狀態(tài)A處于活動狀態(tài) 同時子狀態(tài)A1處于活動狀態(tài) 當事件R發(fā)生時 2 如果當前父狀態(tài)A處于活動狀態(tài) 同時子狀態(tài)A2處于活動狀態(tài) 當事件R發(fā)生 層次化模型的轉移檢測優(yōu)先權 轉移檢測的基本原則 1 轉移測試首先從最高層次的活動狀態(tài)開始 然后逐級向內(nèi)檢測 2 外部轉移優(yōu)先于內(nèi)部轉移被檢測 3 在同樣的層次上 超轉移首先被檢測 根據(jù)這些基本原則 有以下的檢測順序 1 轉移的測試總是從活動的父狀態(tài)開始 向外的轉移 即從父層次狀態(tài)外邊緣出發(fā)的轉移首先被測試 這些轉移能夠使父狀態(tài)退出活動轉移 所以它們首先被檢測 2 接著被檢測的是內(nèi)部轉移 即從父層次狀態(tài)內(nèi)邊緣出發(fā)的轉移 3 從活動的子狀態(tài)開始檢測轉移 從子狀態(tài)外邊緣出發(fā)穿越父狀態(tài)邊緣的轉移 超轉移 首先被檢測 4 然后是父狀態(tài)內(nèi)部子狀態(tài)之間的轉移被檢測 假設此時父狀態(tài)A處于活動狀態(tài)并且子狀態(tài)A1處于活動狀態(tài) 當觸發(fā)發(fā)生時 根據(jù)前面介紹的層次化狀態(tài)圖轉移檢測優(yōu)先權和轉移沖突檢測優(yōu)先權 求系統(tǒng)處理的次序 狀態(tài)動作與狀態(tài)執(zhí)行的次序 1 當Super父狀態(tài)被首次激活時 2 當父狀態(tài)處于活動狀態(tài)而此時發(fā)生了某個事件觸發(fā)時 示例 討論 轉移檢測 子狀態(tài)圖 在創(chuàng)建層次化模型時 盡管使某個狀態(tài)包含了其他的狀態(tài) 轉移以及連接節(jié)點等圖形對象而構成了層次 但是在用鼠標移動父狀態(tài)時 子狀態(tài)并不跟隨父狀態(tài)移動 這對于編輯層次化的狀態(tài)圖很不方便 而且 當子層次內(nèi)部的狀態(tài)變得復雜時 框圖的編輯區(qū)域是有限的 為了解決這些問題 就引出了子狀態(tài)圖的方式 使用組合的狀態(tài) 1 在需要組合的狀態(tài)上單擊鼠標右鍵 例如這里就需要右鍵單擊PowerON狀態(tài) 2 在彈出的快捷菜單中執(zhí)行MakeContents子菜單下的Grouped命令最便捷的方法是通過鼠標雙擊來完成 利用鼠標左鍵雙擊需要組合的狀態(tài) 則狀態(tài)會變成組合模式 再次雙擊 則取消組合模式 創(chuàng)建子狀態(tài)圖ex11 第五章有限狀態(tài)系統(tǒng) 并行機制 并行機制本地事件廣播隱含事件時間邏輯 并行機制 概述在有限狀態(tài)系統(tǒng)中 狀態(tài)的行為可以按照其解析方式分為兩大類 互斥狀態(tài) exclusive或者OR 和并行狀態(tài) parallel或者AND 如果在層次化的狀態(tài)圖中包含了互斥的狀態(tài) 也就意味著同一時刻在同一層次的狀態(tài)中僅有一個狀態(tài)處于活動狀態(tài) 若狀態(tài)被設置為并行狀態(tài) 則位于同一層次下的所有狀態(tài)都在同一時刻處于活動狀態(tài) 在同一層次下 狀態(tài)要么是互斥的 要么是并行的 不可能在同一層次下存在兩種模式共存的情況 狀態(tài)Slot和狀態(tài)Player的邊框是虛線 因此這兩個狀態(tài)就是處于并行狀態(tài)的Stateflow狀態(tài) 其內(nèi)部包含的子狀態(tài)NoDisk和HasDisk以及Stop和Play狀態(tài)邊框是實線 因此子狀態(tài)之間是互斥的狀態(tài) 子狀態(tài)在相應的層次同一時刻只能有一個處于活動狀態(tài) 當狀態(tài)處于并行時 并行的狀態(tài)并不是嚴格地同時被激活 它們的執(zhí)行和激活也有一定的次序基本原則就是 在圖形編輯器中 位置較高的狀態(tài)具有較高的執(zhí)行次序編號 處于同一水平線上的并行狀態(tài) 左邊的狀態(tài)具有較高的執(zhí)行次序編號 當?shù)谝粋€事件發(fā)生時 求系統(tǒng)首先激活整個狀態(tài)圖 依次激活相應的狀態(tài)并執(zhí)行動作 當再次發(fā)生事件E時 求系統(tǒng)依次執(zhí)行相應的轉移并執(zhí)行相應的動作 圖形盒的應用 圖形盒 Box 是一種比較特別的Stateflow圖形對象 它并不參與Stateflow的實際運行 也不能看做是狀態(tài) 從圖形盒上引出轉移或者將轉移的終點放置在圖形盒的邊緣上都是非法的 不過 圖形盒能夠影響并行狀態(tài)的執(zhí)行次序 在某些情況下可以將圖形盒作為框圖的組織形式 圖形盒 Box 功能 層次化建模應用數(shù)據(jù)對象 創(chuàng)建在圖形盒內(nèi)部的本地數(shù)據(jù)對象只能夠被圖形盒內(nèi)部包含的對象使用影響并行狀態(tài)的執(zhí)行次序 圖形盒對象是所有圖形對象中位置最高的對象 本地事件廣播 定義本地事件 本地事件主要用于包含并行狀態(tài)的有限狀態(tài)系統(tǒng) 使不同的并行狀態(tài)之間進行交互 廣播本地事件進行本地事件廣播就是將事件的名稱寫在相應的動作中就可以了 那么監(jiān)聽這個事件的相應動作 狀態(tài)轉移 動作等就會在事件廣播的時刻完成工作 直接事件廣播直接事件廣播 就是將特定的事件發(fā)送給指定的狀態(tài) 而不是出現(xiàn)一呼百應的情況 直接事件廣播需要通過函數(shù)send來實現(xiàn) 它的語法如下 send event name state name 受限事件廣播將定義在狀態(tài)內(nèi)部的事件叫做受限事件 QualifiedEvent 在動作中實現(xiàn)受限事件廣播的方法是通過以下語法實現(xiàn)的 state name event name 廣播的事件僅僅被定義該事件的狀態(tài)接收 因為這個事件是定義在指定的狀態(tài)中的本地事件 在其他狀態(tài)中 這個事件是沒有意義的 事件廣播的執(zhí)行次序 事件廣播很類似函數(shù)的調(diào)用 可以將廣播事件看做在動作執(zhí)行的過程中調(diào)用了一個函數(shù) 在函數(shù)執(zhí)行完畢退出之后 系統(tǒng)才繼續(xù)后面的工作 也就是說 當事件被廣播后 系統(tǒng)將與事件廣播相關的所有動作都執(zhí)行完畢之后 才會繼續(xù)執(zhí)行廣播事件動作之后需要執(zhí)行的其他動作 一般事件廣播的執(zhí)行 假設當前處于活動的子狀態(tài)為A1a和A2a 當事件E1發(fā)生時 如果此時活動的子狀態(tài)同樣為A1a和A2a 那么當事件E1發(fā)生時 直接事件廣播的執(zhí)行狀態(tài)圖的本地事件廣播能夠影響狀態(tài)圖內(nèi)部所有相關的對象 為了避免事件廣播引起一些不必要的動作執(zhí)行 需要使用直接事件廣播 將事件直接發(fā)送給狀態(tài) 假設當前處于活動的子狀態(tài)為A1a和A2a 當事件E1發(fā)生時 受限事件廣播的執(zhí)行 假設當前處于活動的子狀態(tài)為A1a和A2a 當事件E1發(fā)生時 早期返回邏輯 Stateflow在處理狀態(tài)機工作時實際上是一種單線程的工作方式 事件廣播會打斷當前的工作流程 而且只有在廣播事件相關的工作全部結束之后 才繼續(xù)處理原來的后續(xù)工作 在這種處理方式下 事件廣播對原有的工作流程有時可能會造成一些影響 并且產(chǎn)