Paul F.Smith,Sameer M.Prabhu,Jonathan H.Friedman
The MathWorks
摘要
需謹慎管理向基于模型設計的過渡,不僅要展示其短期效益 ,還需建立能夠完全實現此方法理論優點的文化。本文引入了基于模型設計的概念,突出了其中的一些優點,詳細討論了組織中采用基于模型設計文化的10個最佳策略。這些最佳策略從不同工業領域的公司中收集,包括向基于模型設計的成功或者不成功的過渡。
引言
嵌入式系統的深入應用不斷改變著汽車工業。在復雜的,板載的,和基于軟件的電控使用中需對系統的性能,安全性,和維護的改進,從而引起汽車工業的變化。這種變化不僅僅在客車領域發生,在商務車領域也開始應用嵌入式系統。這里應用的嵌入式系統可用于液壓系統的控制,而之前液壓系統都是由機械系統控制,嵌入式系統的使得改進了機器的生產率,安全性以及維護等性能。這以上兩個領域中,系統復雜度的增加給傳統系統開發過程提出了很大的挑戰,如滿足程序時序,成本和質量等性能的度量上。為了應對以上挑戰,主要汽車制造商的工程師跳過了手寫代碼進行系統設計的開發過程,直接過渡至利用圖示化模型設計,分析及執行決定機器性能和行為的軟件。
使用模型可以保證最終產品滿足系統的需求。這些模型幫助不同專業的工程師一起高效工作,并可在設計過程的不同階段進行交流;在設計的早期階段發現并校正錯誤;自動生成實用,高效,及高質量的軟件。軟件工具賣家的獨特視角可看出:基本原則的提煉可能保證基于模型設計的成功應用。這些基本原則的范圍從與自動代碼生成相關的特定策略到一些組織性的問題。我們需要對每個策略進行細節的檢查。以上建議的“正確”綜合以及基于模型設計需要依托的公司環境,在過渡時需由工程部經理進行仔細的選擇。
什么是基于模型的設計?
在基于模型的設計中,開發的過程圍繞著系統的模型—從需求的獲取到設計的執行及測試。
圖1:基于模型的設計
系統模型是可執行規范的核心部分。可執行規范需在設計流程中使用及精心開發。可執行規范還包括輸入,期望輸出或可接受標準,應用的環境,以及同需求之間的連接或相關[1]。可執行規范的目標是明確的傳達設計目標,同時通過仿真對需求進行可行性和兼容性分析。
當包括軟件和硬件的執行需求時:如定點,或定時的行為,可以為嵌入式部署自動生成代碼,同時創建測試臺對系統進行檢驗,節省時間同時避免引入手寫代碼的錯誤。
使用基于模型的設計,工程師可以通過下列方法提高效率:
- 在不同的項目組之間使用通用的設計環境
- 設計直接同需求相連
- 將設計同測試集成,用于連續識別和校正錯誤
- 在多領域仿真中重新定義算法
- 自動生成嵌入式軟件代碼和合成的HDL代碼
- 開發和重新利用測試用例
- 自動編制文檔
- 在多處理器和硬件目標中重復使用設計來部署系統
采用基于模型的設計
為什么公司都采用基于模型的設計?有時候通過戰略計劃驅動的自上而下的委托管理來部署一套常用的工具和進程,其他則是基層自主的方式,在大學中的工程師使用建模的方法并在現在工作中尋找工具來滿足需求。在
其它情況下,基于模型的設計能夠將技術擴展至更積極的如6sigma或者系統工程中。無論向基于模型設計的過渡的推動力是什么,由于公司所見的回報,仍然在進行努力。回報以以下幾種形式體現:
- 獲得的效率,如減少完成指定項目所需的工作時間[1][2]
- 節約時間進行市場交易[3]
- 提高質量[4]
- 減少對物理原型的依賴[5]
另外,工程師通常在選用正確的工具時,工作的會更有樂趣。
向基于模型設計過渡的10個最佳策略:
過渡—需要考慮的重要問題
智慧是數年學習的積累
聰明的組織從自己犯的錯誤中吸取教訓,而智慧的組織則是從他人犯的錯誤中學習新的東西。多年來同很多公司和政府機構一起工作,當這些組織向基于模型設計的過渡中,我們看到了很多成功之處,也有少量的挫折。我們收集了下列最有代表性的最優策略,這樣我們的讀者可從其它人身上學習很多東西,避免向基于模型設計文化過渡時遇到的一些常見的錯誤。
考慮到向基于模型設計過作為一種開發嵌入式計算系統的方法時,需要著重考慮文化,工具,處理器,組織以及戰略等方面。
首先,組織必須建立起衡量模型和仿真開發和使用的文化,將其作為一個核心的工程活動。
需要易于獲取工具,同時使得基于模型的設計可以改進生產效率。
需要易于獲得工具,同時能夠廣泛運行,從而獲得基于模型設計的生產率的提高。
在定義的進程的界限內使用工具。每個公司或者政府部門在設計過程中有不同等級的形式,這些形式是由文化,規定,最優策略,最新的趨勢以及在其中工作的人決定的。但采用基于模型的設計時,同其他技術一樣,需要建立有效一致環境處理過程。
可能需要改變或者棄用傳統的組織模型,從而支持基于模型設計的工作流程。在內部小組之間傳遞工作成果,同時設計者和執行者由于基于模型的設計界限變得模糊。一個有著愿竟式領導的有效組織機構是成功的必要條件。
向基于模型設計的過渡需有一個明確定義的目標和支持的戰略。過渡需要邏輯順序,這根據組織的不同而不同。這種戰略需要建立在現有的優勢上,同時支持設計過程中的弱點。高層管理者需要深刻理解這些戰略,同時針對計劃對工程師進行管理。
最佳策略#1:識別需要解決的問題
在發生任何進程的改進前,需要更深一步理解現有的組織機構和進程中相關的優勢和弱點。需要有支持這些理解內容的衡量方法。對于沒有合適的衡量標準項目的組織,使用最佳策略#0建立這樣一個項目。一個醫生在弄明白病的實質和病人用藥史前不能開出精確的治病處方。這同樣適用于基于模型設計的采用。在現代嵌入式系統開發過程中有很多子元素不能有效運行,舉例如下:
- 日程表的可預測性—組織可以預測和發布日程表嗎?
- 軟件的質量---現有的開發過程是否產生了過量的缺陷?在開發的哪個階段引入了缺陷?代碼或算法的這些部分是否會產生更多的缺陷?
- 市場營銷的時間---及時生產的產品是否滿足如今消費者快速的需求變化?
- 生產率—LOC,個人和時間間隔(或其他測量)可以跟上工業的標準?
- 缺點跟蹤和配置管理---有何種等級的成熟的方法管理和跟蹤開發組織的工作成果?
- 重新使用---是否所有的工作都可以重復使用?
- 產品文檔—是否存在一個系統可以發布開發組織工作成果的文檔?
- 快速原型---是否存在進程可以對新的功能進行快速原型?
- 驗證和校驗---是否知道所有的BUG,以及在發行前是否已經進行了修正?付出的代價如何?
每個采用基于模型設計的組織需要發現現有過程中存在的弱點,為了解決該弱點需要付出的代價,以及首先要解決的問題。
在解決首先解決什么問題時,同樣需要知道解決該問題所需花費的時間。總經理需要對該工具投資以及授權技術的回報有自己的見解,從中選出一部分向贊助商說明投資的回報。
最佳策略#2:“規則2”
為了過渡至基于模型的設計,我們需要對工具,培訓以及組織性等方面進行變革從而適應該過渡過程。為了獲取以上投資的最少可接受的回報,生成的模型需要可用于至少兩種以上的應用中。舉例來說,模型需要用于在仿真中驗證需求,同時生成文檔資料。同時可選擇的應用:定義和開發在快速原型時的控制算法,及為產品控制器自動生成代碼。
兩個過程元素的選擇需要使用最佳策略#1進行慎重考慮。這樣做的目的為獲得投資的最大回報。不同設計階段的模型重復使用功能是獲取最大回報的必要條件。
追求一次性模型的組織可能獲得成功,但易于發現采用新技術的負擔,他們很難獲得時間和資金投資的收益。
最佳策略#3:使用模型生成產品代碼
組織不斷通過軟件來實現硬件的共用,也就是說,為了保證同樣的基礎硬件能夠實現不同的功能,可以通過改變控制該硬件的嵌入式軟件。這樣節省了制造商在硬件上的規模,同時使得產品僅僅通過改變嵌入式軟件就可以滿足顧客自定義的需求,滿足了產品自定義同大批量生產兩個看上去相互矛盾的目標。毫無疑問,嵌入式系統軟件正快速取代著機械硬件的使用,成為決定產品性能特性的關鍵因素。同時,嵌入式系統軟件控制著汽車的主要系統,因此從實際來說,汽車的“行駛”需要依靠軟件。討論了嵌入式軟件的重要性之后,則可以很自然的將之前所提到的“規則2”擴展至模型的一個使用:自動生成嵌入式軟件,
使用模型保證設計能夠滿足相關系統的需求,同時在設計的早期發現設計錯誤,從而使得糾正錯誤付出的代價最小化。代碼生成技術的最新發展可以從模型中自動生成產品級嵌入式軟件[11]。當模型能夠自動生成軟件時,整個測試基礎可重用于測試模型,因此可以檢驗生成的軟件及可能發現的錯誤,同時及早糾正。同時,如果需要改變需求及設計,則需將他們做成模型,這樣可以重新高效的從模型中生成軟件,大大縮短了軟件跟上需求或者設計的改變所需的反應時間。
從模型中自動生成嵌入式軟件需要組織文化的轉變。在過去,控制設計師為他們的設計創建模型,軟件工程師則基于這些模型的規范手動開發嵌入式系統。有了嵌入式軟件的自動生成,軟件工程師的關注點發生著變化,從每次設計或者需求改變時重新花費時間寫算法代碼到花費更多的時間將算法代碼同嵌入式系統的其他部分集成,同時也適用于說明和設置基礎結構。這是一個重要的轉變,使得衡量軟件工程師工作效率的指標也隨之改變。另外,模型使得控制工程師和設計工程師之間的關系更為緊密,消除了工作之間傳統的障礙。組織的領導者需要鼓勵和支持這種做法,從而得到基于模型設計的所有優點。
最佳策略#4:模型是真理的唯一來源
除了遵從“規則2”和在開發過程中使用模型實現多重目的得到的優點外,基于模型設計的一個很重要的優點即建立的模型可在多個項目中重復利用。模型屬于組織的知識產權(IP),可以在很多項目中重復使用,因此IP可以發揮協調作用使得項目在質量和時間上大大提高。但是,這種優勢只有在模型中包含真正的IP才能獲得。
本最佳策略和最佳策略#3的邏輯擴展即模型是同嵌入式系統相關的真理的唯一來源。模型中自動生成的嵌入式軟件只能讓汽車“行駛”。如果在試生產汽車的最后檢驗和測試中發現算法錯誤或者針對需求進行最后微小的改變,則傾向于“修正”嵌入式軟件本身來避免對自動的嵌入式軟件生成和一體化進程重新檢查。但若軟件工程師使用了這種試探性的方法,會停止模型軟件的同步,模型也不包括真正的IP。因此,如果在不同的項目中重復使用該模型,則需要在項目中重復面對及處理算法錯誤或需求的不一致。
該部分同最佳策略#3討論的一樣加強了組織的含義。控制和軟件工程師需要合作從而保證任何最終很小的改變都確實融入至模型中。組織的領導者需要支持和鼓勵這種做法,同時強調這樣做的需要及好處。如果不是這樣,控制和軟件工程師很容易發生分歧,從而防礙了基于模型設計的所有優點。實際上,組織者需要有嚴格的紀律來使用和促進模型,使其成為嵌入式系統唯一的設計語言。
最佳策略#5:將過渡視為學習的機會
有時候,從傳統的開發過程過渡至基于模型的設計會有些徘徊。但是,組織者遵從最佳策略#1,同時通過過渡的過程進行自我學習,這對他們長期的成功非常有益。這種自我反省可對現有的過程,以及自己的優點和弱點有清楚根本地認識,同時對組織的核心競爭力有更深的理解。有了這些深入的信息,組織可以更好的完成向基于模型設計過渡的任務。
在向基于模型設計過渡的過程中,一種常見的試探性的做法既“外包”至第三方。雖然外包本身不是壞主意,但仍然需要正確的判斷,同時目標領域是組織的非核心競爭力部分。如果將現有的IP至基于模型的環境的過渡進行外包,則組織也失去了重新檢查這些IP的機會,同時也無法質疑IP的哪一部分需要真的變化,或者修正可能存在IP內的錯誤和BUG等等。因此,效率不高的外包很容易浪費改進產品質量的很重要的機會。組織需要確認能從第三方得到幫助,這些幫助需要集中在創建工具和效用上,簡化向基于模型設計的過渡,同時提出基于模型設計的更好的過程等等。
另外一種試探性的做法即“快速轉變”,徹底地向基于模型設計過渡從而獲得所有的優點。這種做法也有很多缺點。首先,現有的開發過程或產品的某些組成部分效率較高,或者構造完善,在第一道關時不需要改變。丟棄這樣優勢會導致向基于模型的設計調整時不必要的重復性工作。一種更聰明的方法即批判性的選擇開發過程和產品的組成部分,取其精華,去其糟粕。舉例來說,識別當前開發過程或產品中的問題區域,在第一次循環中將基于模型的設計集中于該區域。第二步,了解當前開發過程或產品中包含哪些不需要向基于模型的設計過渡的部分,如低等級的設備驅動器,或者在未來產品中需要淘汰的性能等,這些都不需要過渡至基于模型的設計。對當前的開發過程進行深入的觀察,識別其中最適合使用基于模型設計的區域,最小的中斷開發過程,同時獲得最大的收益。
當決定產品IP的哪一部分需要建模后,首先需要解決一些全新的控制特性。其次,著手解決設計中的問題部分,那些不斷發生變化或者引起問題的部分。最后,如果時間允許,將更為穩定的
控制系統的端口慢慢移植入該背景中。
最佳策略#6:集中在設計,而不是代碼編寫中
有時候,引入基于模型的設計時,軟件工程師會立即關注他們的職位是否受到威脅。然而,這種擔心在設計小組發現軟件工程師仍是基于模型設計中的一部分后消失了。但是軟件工程師的角色也隨之改變,從運行時代碼編寫的綜合能動性過渡至在開發過程的初始階段構建軟件,同時不斷完善可執行規范從而使得生成的代碼更接近執行階段。
舉例來說,軟件工程師需要開發一個靈活的機制,使得使用基于模型設計開發的新特性能夠同原有代碼集成。另外,軟件工程師需要對生成的模型進行完善,保證其生成的代碼能夠在目標處理器中運行,如當算法模型作為浮點值創建時,目標處理器即為浮點的。
最佳策略#7:集成開發過程
若有可支持的基礎設施增強本文所提出的最佳策略,則基于模型的設計的應用會更流行。換句話說,要想取得成功,基于模型的設計需要是主流產品開發過程的一部分,而不是覆蓋。
通常,需對現有的開發過程和衡量方法進行修改從而同基于模型的設計結合。舉例來說,我們需要開發風格向導,并在合適的項目里程碑中回顧該風格向導以進行支持。我們需要涉及基于模型設計的加工品的配置管理。在以代碼為中心的過程中,代碼通常是主要的或者唯一人工可控的部分。在基于模型的設計中,控制的人工部分包括測試向量,期望成果,模型組成以及使用的建模環境的版本[6]等等。同樣,需求管理和驗證過程及工具需同基于模型設計工具相集成。傳統方式中,軟件需求一般不進行校驗,除非有可用的可執行硬件。但是,引入基于模型的設計后,仿真驗證可在硬件驗證之前進行。
必須建立細節的,不間斷的培訓以及能力開發計劃。這些計劃包括一般的產品培訓和自定義的特定過程的指導和規定。
最后,可能也是最重要的,需要更新評估項目狀態的衡量方法,從而完成向基于模型設計的過渡[8]。舉例來說,在傳統的開發過程中,一個人可能對每天生成的代碼行數進行計數從而評估項目的“健康度”。但當所有行的代碼在“一個按鈕按下時”可全部生成,這種衡量方式失去了意義。
最佳策略#8:誰有影響力,同時能有效控制預算,誰就是贏家
成功過渡至基于模型設計的大部分的組織通常選擇了一個有力的,有經驗的同時受尊敬的領導者。有時候這個領導者需要是善于促成共識的人,有時候也是仁慈的獨裁者。
這個人通常很有資歷,有著證明其曾經協調過體系變革的歷史紀錄。這種空降兵被某些人所懼怕,同時被其他人擁戴。
勝利者需要鼓勵那些希望用新方法做事的人,同時也要安慰(或者消除)那些不希望用新的方法做事的人的恐懼。
勝利者需要同是被同級,上級以及下級的人所尊重。如果勝利者所處的政治前景明顯或不明顯的破壞著過渡過程,則整個的過渡過程面臨風險,而同技術或開發過程無關。
這個人需要進行直接的預算控制,或者有著高級贊助商的支持。人力,資本或者培訓的投資是整個基于模型設計的部署和投資期望回報(ROI)的函數。這些投資對于組織來說非常重要,同時預算的處理也是勝利者的一個重要特質。
最佳策略#9:有一個長遠的眼光
向基于模型設計過渡需要一定的時間。對于交通業,建筑設備,或者空防等從零開始的工業組織中,中等大小的嵌入式系統的設計和開發需使用年來衡量過渡的時間,而不是用月。ROI可在第一個模型建立,仿真及消除設計缺陷后,同時在變成代碼或硬件之前取得。獲得全部的優點則需花費一定的時間。
很多組織試圖跟上潮流是常見的事情,他們希望在3到6個月內將他們的開發機構過渡至基于模型設計的概念或者技術的機構,這是非常不現實的。可能有著少量生產線的小型全套裝備以及5-20個開發者可以在一段較短的時間內完成過渡。進行基礎研究的小組進行得更快些,這是因為他們不易被原有代碼所累(但是相應的ROI較低)。較大的組織更容易被原有開發過程的組成部分所累,同時“粘合”任何商業工具至開發過程也占用了相當多的時間。需要考慮包括如何結合基于模型的設計同原有的系統和開發過程在內的一些因素,這樣做為了:
- 缺陷跟蹤
- 配置管理
- 文檔編制和出版
- 調整,整理,校準
- 項目管理
- 內部準備的嵌入式運行系統或者自定義的硬件目標
- 衡量標準的項目(改變你測量生產效率的方法[8])
(注:這不是一個詳盡的列表)
長期的工作需要耐心和深思熟慮。擁有一個管理計劃,不停的完善。慶祝過程中小的勝利,同時如果環境變化也需考慮適當改變計劃。使用上面列出的其他最佳策略,慎重選擇使用策略的順序,用于將基于模型設計概念應用于說明價值提升的一系列命令(以及承諾提供保持過渡所需的資源)
大部分工程師都會在過渡的開始立即發現一個優點:工作中有了更多的樂趣。大部分人,尤其是工程師-喜歡使用強大的工具,這樣可以保持較高的速率以及提升工作的滿意度。
最佳策略#10:同工具供應商合作
如本文開始部分所述,聰明的組織從自己的錯誤中吸取教訓,而明智的組織則是從其它人的錯誤中學習新的東西。由于工具供應商在組織向基于模型設計的過渡中扮演了重要的角色,需緊密的加入支持過渡的過程中,因此,他們積累了關于大量組織在管理成功的(或不成功的)過渡時需要處理的情況和方面等重要經驗,。在自己組織的過渡過程中使用工具供應商積累的經驗可以很大程度上降低著名的學習曲線的陡度。這樣組織能夠更快體會到基于模型設計的好處,因此也使得投資回報率(ROI)盈虧平衡點更為提前,不僅僅降低了學習曲線初始加速的坡度,同時及早在組織中使用工具供應商收集的經驗可以減少保持基于模型設計所需的努力。因此,同工具供應商密切聯系,將他們包括至過渡計劃,有效利用他們的經驗,避免常見的錯誤,同時合作獲得一個成功的過渡。
結論
基于模型設計的應用為開發嵌入式控制系統,如應用于汽車動力傳動或者經典控制中的系統,提供了一個健全,成熟以及高度精煉的策略。通過多年觀察及參與不同組織的過渡過程,這些過渡包括大的小的,商業的或者政府的,交通,通信,以及其它嵌入式控制開發等,從中提煉了上述最佳策略,同時和大家分享。這些策略不是固定的準則,不能在每個仿真中應用。每個組織在向基于模型設計的過渡階段需要退一步來省視自我。只有明智的選用這些最佳策略才會給使用中的嵌入式控制開發過程現代化所需要的人力和技術投資帶來最大的回報。