國內(nèi)主機廠車身控制器功能開發(fā)通常使用文字來描述系統(tǒng)設(shè)計,各個功能之間的依賴關(guān)系不清晰,功能復(fù)用率不高。隨著功能需求數(shù)量的增多,為提高各個功能的復(fù)用率,行業(yè)內(nèi)提出面向服務(wù)的汽車架構(gòu)(SOA)解決方案。挖掘SOA 架構(gòu)設(shè)計方法論,總結(jié)嵐圖汽車SOA 平臺車身控制域中氛圍燈子系統(tǒng)設(shè)計開發(fā)實踐經(jīng)驗,闡述使用企業(yè)構(gòu)架(EA)軟件完成汽車車身控制域系統(tǒng)設(shè)計,交付開發(fā)需求文檔以及系統(tǒng)功能規(guī)范的方法,以達到提升設(shè)計效率,改善設(shè)計質(zhì)量的目的。
0 引言
在國內(nèi)主流整車企業(yè)完成車身控制系統(tǒng)或其相關(guān)子系統(tǒng)的設(shè)計工作時,通常采用Micro soft Visio 軟件完成流程圖的繪制并開展設(shè)計工作,使用Microsoft Word 進行人工編寫功能規(guī)范或者子系統(tǒng)規(guī)范的文字說明,使用Auto CAD 工具輔助完成系統(tǒng)框圖的設(shè)計。隨著“域”概念的引入,相較于早期的汽車車身控制器產(chǎn)品功能的開發(fā),車身域控制器不僅新的功能層出不窮[1],而且功能與功能之間還存在交叉復(fù)用的情況。例如2010 年生產(chǎn)的一臺豪華轎車具備800 個整車功能[2],而在2007年整車功能只有270個[3]。例如中控屏控制車窗、語音控制車窗2個功能需求中,執(zhí)行端(控制器驅(qū)動玻璃升降電機的部分)處理邏輯是一樣的,這部分的邏輯就可以在不同車窗控制方式中復(fù)用。隨著各個功能之間交叉復(fù)用的情況增多,在進行系統(tǒng)設(shè)計時,使用文字進行描述和輔助一些插圖的方式,越來越難以梳理功能的鏈路以及功能之間的交互關(guān)系。
在當下軟件定義汽車的時代[4],汽車生產(chǎn)廠商依托架構(gòu)方案進行造車,以控制成本,提高產(chǎn)品競爭力[5],加快軟件產(chǎn)品的迭代。例如大眾汽車集團的電動車模塊化平臺(Modular Electrification Toolkit,MEB)構(gòu)架,豐田汽車新全球架構(gòu)平臺(Toyota New Global Architecture,TGNA)和吉利汽車的浩瀚智能體驗(Sustainable Experience Architecture,SEA)架構(gòu),都是當前國際上先進的面向服務(wù)化的汽車架構(gòu)(Service-Oriented Architecture,SOA)。這些汽車構(gòu)架具有粗粒度、松耦合的特征,服務(wù)之間通過定義簡單、精確的接口進行通訊,其設(shè)計的基本原則主要有:
(1)標準化的服務(wù)契約;
(2)服務(wù)松耦合;
(3)服務(wù)的可重用性;
(4)服務(wù)自治[6]。
由此可以看出,在設(shè)計、輸出車身控制系統(tǒng)或子系統(tǒng)對應(yīng)的功能規(guī)范時,在新的架構(gòu)方案下,系統(tǒng)設(shè)計人員還需要對服務(wù)接口進行標準化定義。
在新架構(gòu)下,汽車車身域系統(tǒng)開發(fā)人員利用企業(yè)構(gòu)架(Enterprise Architect,EA)軟件完成車身域[7]的子系統(tǒng)設(shè)計、完成功能規(guī)范的編寫和開發(fā)交付物,同時根據(jù)EA提供的應(yīng)用程序接口(Application Program Interface,API)進行拓展功能開發(fā)的研究。EA是一款企業(yè)架構(gòu)軟件[8],覆蓋了系統(tǒng)開發(fā)的整個周期,除了開發(fā)類模型之外,還包括事務(wù)進程分析、使用案例需求、動態(tài)模型、組件和布局、系統(tǒng)管理、非功能需求、用戶界面設(shè)計、測試和維護。EA使用者還可以利用EA中的基礎(chǔ)元素,封裝出一套滿足使用需求的元素插件,所以選擇使用EA進行車身控制域子系統(tǒng)的設(shè)計與開發(fā)研究,具有很高的靈活度和契合度。
1 模塊化層級框架搭建
利用EA開展SOA架構(gòu)下車身控制域子系統(tǒng)的設(shè)計工作,首先需使用EA 搭建子系統(tǒng)框架。為了避免相關(guān)的元素依賴關(guān)系不清晰,框架的搭建通常有2種方案。
(1)方案1 以某一車型平臺為單位搭建服務(wù)器。服務(wù)器內(nèi)使用唯一編號對功能進行標識,新增的功能需求按新的順序進行編號,固化的功能需求不再改變編號,把此車型平臺上所有功能需求匯集在一個服務(wù)器上,當開發(fā)不同車型時,根據(jù)功能需求進行拆分重組,完成車身域子系統(tǒng)的功能設(shè)計,輸出功能規(guī)范和開發(fā)交付物。
(2)方案2 以項目為單位搭建服務(wù)器。每個服務(wù)器單獨開發(fā)維護,此方案更適合有相同功能的不同車型,按不同用例需求進行定制開發(fā)。EA 架構(gòu)開發(fā)環(huán)境的搭建可根據(jù)公司戰(zhàn)略需求進行工程方案選擇。
在工程內(nèi)部需要對文檔進行分層搭建,軟件層級的劃分是SOA架構(gòu)中松耦合的實現(xiàn)方式,所以在搭建文檔時,不僅要橫向考慮開發(fā)流程的先后順序,還需要縱向考慮軟件的分層實現(xiàn)[9]。
使用EA 搭建模塊化層級的框架,首先需建立功能需求文檔,這是開展車身控制域子系統(tǒng)設(shè)計的基礎(chǔ),主要用于存放設(shè)計中的功能描述和功能用例流程圖。在功能需求文檔的子文檔中,需要對功能進行模塊化的劃分,車身控制域就屬于其中一個模塊,整車的其他控制系統(tǒng)均可根據(jù)功能類別劃分成不同的模塊,功能需求文檔建立后,將此文檔派發(fā)給系統(tǒng)工程師進行處理和維護。
其次是建立其他需求文檔。比如功能安全需求文檔、系統(tǒng)性能需求文檔,這部分內(nèi)容可以派發(fā)給功能安全工程師和系統(tǒng)工程師進行搭建和維護。由功能安全工程師根據(jù)功能安全目標,指導(dǎo)軟件開發(fā);系統(tǒng)工程師根據(jù)性能需求,提出可量化、可實現(xiàn)的性能指標,比如系統(tǒng)的資源占用情況、響應(yīng)時間要求。
最后,建立邏輯實現(xiàn)文檔。邏輯實現(xiàn)文檔包括縱向軟件分層,每個域模塊的層級分類會有不同,車身控制域從軟件控制層、協(xié)調(diào)層、信號轉(zhuǎn)換層、傳感器與執(zhí)行層以及物理層進行劃分,此項可以先由系統(tǒng)工程師設(shè)計出相應(yīng)的外部通信接口,再由軟件開發(fā)人員根據(jù)開發(fā)需求定義內(nèi)部接口。
基于上述描述,使用EA 搭建出了車身控制域系統(tǒng)設(shè)計框架,如圖1所示。
圖1 車身控制域系統(tǒng)設(shè)計框架
2 車身控制域子系統(tǒng)設(shè)計
在EA中按照以下流程開展車身控制域子系統(tǒng)的設(shè)計工作,系統(tǒng)的功能邏輯思路就能非常清晰地呈現(xiàn)出來,進行功能設(shè)計時就不會造成邏輯混亂和接口依賴不清晰、不明確的問題,客觀上保證了設(shè)計開發(fā)的質(zhì)量。
2.1 功能需求文檔內(nèi)容設(shè)計
功能需求文檔的內(nèi)容包括功能描述和功能用例流程。
2.1.1 分解功能需求完成功能描述
在獲得車身控制域的系統(tǒng)功能需求后,應(yīng)對其進行分解。把一項功能拆解成多條功能用例,在EA 中用案例(Use Case)元素進行表示,考慮支持實現(xiàn)這些功能用例的需求,每一條功能用例的前置條件、觸發(fā)條件、執(zhí)行方法或步驟,在執(zhí)行動作過程中,有其他異常情況發(fā)生時所期望的執(zhí)行結(jié)果,以及信息沖突的仲裁情況。這些設(shè)計中的信息均可用文字描述的形式放入Use Case 屬性的不同條目下,以完成功能需求分解和定義。
2.1.2 繪制功能用例流程圖
在此階段,首先應(yīng)根據(jù)整車的電子電器架構(gòu)了解系統(tǒng)中各個單元的分布情況。以物理單元為基礎(chǔ),軟件組件為載體,抽象出軟件組件的產(chǎn)品能力(Product Capability,PC)。
在每一條功能用例流程圖中拽入功能實現(xiàn)所需要的PC,并在其“特征”選項卡的“操作”(Operation)中建立具體的關(guān)聯(lián)方法,此時就可繪制功能流程的傳遞過程,在此基礎(chǔ)上加入功能定義中的判斷條件,可完成功能用例流程圖設(shè)計。
功能用例流程圖的主要作用是梳理功能邏輯,分配功能任務(wù)。通過功能用例流程圖,系統(tǒng)設(shè)計人員可以明確系統(tǒng)的依賴關(guān)系以及系統(tǒng)的邏輯、時序和步驟,各軟件組件也能明確自身需要完成的工作內(nèi)容。狀態(tài)機和活動圖在EA中均有對應(yīng)的元素可以直接使用,相比于流程圖更加方便。
2.2 邏輯實現(xiàn)文檔內(nèi)容設(shè)計與銜接
邏輯實現(xiàn)文檔的設(shè)計分為縱向設(shè)計和橫向設(shè)計。縱向設(shè)計是把一個系統(tǒng)功能從需求到最終實現(xiàn)的流程設(shè)計,橫向設(shè)計則是把每個系統(tǒng)的縱向設(shè)計內(nèi)容進行組合設(shè)計。在搭建模塊化層級框架時,需要根據(jù)實際分層情況把縱向設(shè)計內(nèi)容進行分類管理。下文重點闡述利用EA完成縱向設(shè)計內(nèi)容。
2.2.1 建立軟件組件并繼承產(chǎn)品能力
前文主要描述的是功能層面的設(shè)計,下文的設(shè)計屬于軟件設(shè)計范疇。根據(jù)PC需求能力進行分類組合,建立EA 中的軟件組件(Software Component,SWC)[10],該組件可通過EA 中的關(guān)系圖,對PC 操作進行繼承,防止設(shè)計人員在需求編制時出現(xiàn)漏項。
2.2.2 打包并部署軟件組件
每個SWC 都需要部署在系統(tǒng)芯片(System on Chip,SOC)里,部署時可把一類或一個系統(tǒng)的SWC一起打包部署。在部署之前,應(yīng)先根據(jù)整車電氣架構(gòu)圖,建立所有的ECU元素,再通過部署圖實現(xiàn)SWC與ECU的部署關(guān)系。
2.2.3 設(shè)計軟件組件接口
在SOA 的架構(gòu)中,主要原則是定義標準化的接口。車身控制域系統(tǒng)的設(shè)計,不僅有基于單一(Single)信號的接收與發(fā)送,還有基于以太服務(wù)的消費接口[11]。利用EA對基礎(chǔ)元素的封裝能力,把EA的基礎(chǔ)接口封裝出不同類型的接口。以SOC為基礎(chǔ)單元,根據(jù)架構(gòu)的層級關(guān)系,每個層級之間建立的標準接口為內(nèi)部接口,與其他SOC 之間的交互稱為外部接口;若以SWC 為基礎(chǔ)單元,其外部接口和需求接口,分別代表著SWC能提供的服務(wù)和消費依賴;每個外部接口元素可以在“操作”(Operation)選項卡里添加具體的接口名稱,并將添加的外部接口名稱提供給其他SWC進行消費;需求接口則是其余SWC 的外部接口,不能自行建立,需依賴方的SWC 建立外部接口,通過消費依賴方的外部接口建立關(guān)系。
在接口中,如果是Single 類型(汽車CAN、CANFD通信協(xié)議數(shù)據(jù)類型)接口,會描繪出信號的收發(fā)情況和數(shù)據(jù)值。如果是以太服務(wù)類型的消費接口,則根據(jù)設(shè)計需要定義服務(wù)接口所傳的參數(shù)信息。數(shù)據(jù)類型與程序開發(fā)高級語言中的數(shù)據(jù)類型相似,有結(jié)構(gòu)體、枚舉、數(shù)組和價值(Value)數(shù)據(jù)類型,如在結(jié)構(gòu)體數(shù)據(jù)類型中添加成員,可以選擇特征(Feature)[12]里的屬性(Attribute)以區(qū)別接口使用的操作內(nèi)容。
2.2.4 繪制信號流程圖
當有了服務(wù)接口和信號接口后,為了更清晰的表達出數(shù)據(jù)的流向鏈路,可以繪制信號流程圖。信號流程圖應(yīng)與功能用例流程圖對應(yīng),是以每個SWC 為單元,接口消費關(guān)系為鏈路的示意圖,能更詳細表達出數(shù)據(jù)在軟件組件之間的流轉(zhuǎn)關(guān)系,對后期系統(tǒng)問題故障診斷起到非常有用的幫助。
2.3 其它需求文檔建立與關(guān)聯(lián)
在進行一些涉及行車安全的系統(tǒng)設(shè)計時,如雨刮系統(tǒng)、大燈系統(tǒng)[13],功能安全專業(yè)會對某些場景提出需求,通過ASIL等級進行約束和規(guī)范,這些特殊的需求可以使用需求(Requirement)元素進行描述,并在圖中與Use Case進行關(guān)聯(lián),形成對Use Case約束和要求。還有某些響應(yīng)時效、性能需求,在與Use Case關(guān)聯(lián)后把這些特殊的需求橫向分類到功能安全需求、系統(tǒng)性能需求文檔中。這樣不僅把這些特殊需求進行了歸類管理,還清晰地表示出了哪個Use Case承接了需求。
3 基于EA的功能拓展
在完成EA 的系統(tǒng)設(shè)計和接口設(shè)計[14]后,可以通過共享服務(wù)器的方式,為有需求的使用人員開辟賬號查看或編輯內(nèi)容。但在實際開發(fā)過程中,為了追求更好的設(shè)計質(zhì)量,不同的系統(tǒng)大多是分配給不同的軟件供應(yīng)商完成,為了項目全盤設(shè)計內(nèi)容的安全性、保密性,往往是單獨提供供應(yīng)商承接的開發(fā)內(nèi)容部分,所以設(shè)計的產(chǎn)出只保留在系統(tǒng)或者服務(wù)器中是遠遠不夠的,還需要把系統(tǒng)中設(shè)計的內(nèi)容導(dǎo)出來使用。
EA具有強大的拓展功能,不僅在發(fā)布(Publish)中可以進行設(shè)計導(dǎo)出和導(dǎo)入,還提供相應(yīng)的API接口,可以供第三方開發(fā)人員訪問數(shù)據(jù)庫。因此,在系統(tǒng)設(shè)計人員完成相應(yīng)設(shè)計后,可依托第三方提供的工具,把設(shè)計數(shù)據(jù)按需求格式進行導(dǎo)出,供開發(fā)者使用。
系統(tǒng)開發(fā)過程中常用到的開發(fā)文檔就是功能規(guī)范。功能規(guī)范的導(dǎo)出通常有2種方法:一種方法是在EA“資源”(Resource)選項卡中創(chuàng)建元素的引用方法,再創(chuàng)建一份具有統(tǒng)一模板的文件(Document),把設(shè)計中用到的元素拖入模板文檔中,在LINK 時選擇引用方法。此時拖入的元素則會按照設(shè)計方法導(dǎo)入功能對應(yīng)的需求內(nèi)容、前置條件、觸發(fā)條件、執(zhí)行方法或步驟,形成文檔后進行導(dǎo)出保存。此方法的好處在于文檔是一個動態(tài)鏈接的狀態(tài),如果元素中有更新,刷新文檔后,對應(yīng)的內(nèi)容也會更新,保證了設(shè)計與文檔同步。另一種方法則是利用第三方的腳本進行導(dǎo)出,此方法的缺點是若文檔有更新,則需要重新導(dǎo)出,無法像在線設(shè)計一樣同步更新。
另外用到的開發(fā)文檔是在AUTOSAR[15]標準下,采用可擴展標記語言(Automotive Open System Architecture Extensible Markup Language,ARXML)來傳遞具有層次結(jié)構(gòu)的接口數(shù)據(jù)。主要就是導(dǎo)出EA里的SWC及其接口部分信息、消費的依賴關(guān)系內(nèi)容。因為第三方工具可以通過API 直接訪問數(shù)據(jù)庫,導(dǎo)出的數(shù)據(jù)比使用系統(tǒng)工具更快,通常利用第三方工具導(dǎo)出,然后利用MATLAB生成ARXML文檔。
基于EA 提供的API,可以直接進行數(shù)據(jù)庫訪問,具有強大的拓展功能,可以滿足設(shè)計內(nèi)容的輸出需求。
4 設(shè)計方法實踐
在嵐圖汽車SOA平臺項目上利用EA進行了系統(tǒng)設(shè)計實踐,本文以車身控制域氛圍燈子系統(tǒng)為設(shè)計實例,闡述利用EA完成系統(tǒng)設(shè)計工作。
需要說明的是圖2~圖6所涉及的內(nèi)容僅作為示例展示,相對于實際開發(fā)做了處理,實際開發(fā)時接口命名規(guī)則應(yīng)滿足集成編譯環(huán)境所需的命名規(guī)則。
圖2 部分氛圍燈功能需求用例設(shè)計
嵐圖汽車公司將氛圍燈系統(tǒng)規(guī)劃在車身控制域的功能中,但部署在座艙域的SOC中,利用EA完成氛圍燈系統(tǒng)設(shè)計,就打破了傳統(tǒng)產(chǎn)品責(zé)任方法,車身控制域系統(tǒng)工程師可以在其他人負責(zé)的ECU 上進行系統(tǒng)設(shè)計,這也體現(xiàn)了SOA松耦合的優(yōu)點。
4.1 氛圍燈功能設(shè)計
在EA 中對氛圍燈功能進行拆分,氛圍燈首先具有中控屏與語音打開和關(guān)閉的Use Case。往下層級拆分,有通過中控屏與語音選擇的靜態(tài)、動態(tài)氛圍燈控制的Use Case。再往下一個層級,靜態(tài)氛圍燈具有中控屏與語音調(diào)節(jié)顏色、亮度的Use Case,動態(tài)氛圍燈具有音樂律動模式與隨駕駛模式兩種選擇的Use Case,其中音樂律動模式下面又拆分有3 種色域(冷色、暖色、中色)的選擇Use Case,讓音樂律動的值在色域中進行律動。
在Use Case 設(shè)計時,有許多需求不能通過Use Case 表述出來,比如氛圍燈的初始化狀態(tài)、顏色的色譜、亮度等級分配和仲裁關(guān)系,以及一些非功能性需求,無法直接放入Use Case 中,可以使用Requirement元素進行描述,并與Use Case建立需求關(guān)系,見圖2中的需求關(guān)系。
功能定義的詳細描述,需要在Use Case 元素的“性能”(Property)選項卡中的“約束”(Constraint)欄目添加用例前置條件,在“場景”(Scenario)欄目中填寫具體的方案,包括觸發(fā)方式、基本執(zhí)行方式、異常執(zhí)行方式和備選執(zhí)行方式。
根據(jù)架構(gòu)拓撲情況,梳理出關(guān)聯(lián)單元,在EA中建立相應(yīng)的ECU單元元素,開展功能分配工作。功能的分配同樣可以應(yīng)用Requirement 元素進行描述,根據(jù)功能描述提煉每個ECU 單元能給氛圍燈系統(tǒng)貢獻的能力PC,然后建立氛圍燈系統(tǒng)內(nèi)的PC,而關(guān)聯(lián)方的PC 需要和關(guān)聯(lián)方討論后,由對方承接并建立相應(yīng)的PC。PC 建立完整后就可以針對每個Use Case 繪制相應(yīng)的流程圖,見圖3。
圖3 部分氛圍燈功能用例流程
4.2 氛圍燈接口模塊設(shè)計
根據(jù)PC能力進行整合與分配,建立對應(yīng)的SWC,氛圍燈系統(tǒng)主要分音樂律動算法部分SWC、邏輯控制部分SWC、燈頭驅(qū)動SWC 以及中間件信號路由能力。建立SWC后需對其進行部署,其中音樂律動算法的SWC 部署在安卓系統(tǒng)內(nèi)部,這樣可以直接獲得到PCM源碼音頻數(shù)據(jù),利用算法提取到用于控制氛圍燈的音頻、振幅等音樂特征;邏輯控制部分的SWC(圖4)針對氛圍燈的控制邏輯進行處理,并把處理結(jié)果轉(zhuǎn)換成信號進行輸出;燈頭SWC則根據(jù)信號協(xié)議內(nèi)容驅(qū)動氛圍燈點亮。
圖4 氛圍燈邏輯控制部分SWC
每個SWC之間根據(jù)通信方式建立通信接口,比如算法部分SWC 與邏輯控制的SWC 采用信息中心(Message Center)的方式通信,建立服務(wù)接口及數(shù)據(jù)類型。邏輯控制SWC到燈頭SWC是先采用以太網(wǎng)的方式與網(wǎng)關(guān)通信,再由網(wǎng)關(guān)采用串行通信總線(Local Interconnect Network,LIN)方式通過路由傳給燈頭,按照同樣的方式建立服務(wù)接口、數(shù)據(jù)類型與信號。按照SOA架構(gòu)方案,氛圍燈應(yīng)暴露出服務(wù)能力給其他系統(tǒng)使用,所以邏輯控制部分SWC還需承接在以太網(wǎng)提供服務(wù)的接口工作。標準化的接口建立以后,需要使用圖表元素進行消費關(guān)系的建立,同時也可以進行氛圍燈信號流程圖的繪制,見圖5。
圖5 部分信號流程
4.3 氛圍燈系統(tǒng)框圖搭建與文檔輸出
氛圍燈設(shè)計完成后,搭建系統(tǒng)框圖時只需要在圖表元素中拖入關(guān)聯(lián)的ECU,在ECU 中放入軟件的SWC,這樣SWC 的依賴關(guān)系就自動建立,很輕松地完成了系統(tǒng)框圖的繪制(圖6)。利用第三方腳本插件,可以對元素中的信息進行選擇性導(dǎo)出生成Word 文檔,利用此腳本可以按照模板生成氛圍燈的功能規(guī)范。如果軟件開發(fā)方需要ARXML 作為軟件開發(fā)輸入[15]文檔時,可以把EA 中氛圍燈接口模塊設(shè)計的內(nèi)容導(dǎo)出生成Word 文檔,利用文檔轉(zhuǎn)換腳本把Word 文檔轉(zhuǎn)換成Excel 表格,再使用MATLAB 工具生成ARXML 文檔[16]。
圖6 氛圍燈系統(tǒng)
5 結(jié)論
利用EA 開展車身域系統(tǒng)設(shè)計工作,通過圖表的方式能很好地理清系統(tǒng)設(shè)計人員的邏輯思路,梳理數(shù)據(jù)流向,完成需要的系統(tǒng)設(shè)計輸出物和交付物,比如系統(tǒng)框圖、系統(tǒng)流程圖、系統(tǒng)規(guī)范以及標準化的接口。EA 還具有解耦性,設(shè)計工作不與特定的硬件信息耦合,適用于一種系統(tǒng)方案匹配多種產(chǎn)品方案。
目前SOA架構(gòu)已在國內(nèi)汽車行業(yè)逐漸流行,傳統(tǒng)手寫功能規(guī)范的方式在車身域場景化的開發(fā)中效率低下,需要一些信息化的工具輔助完成系統(tǒng)設(shè)計工作,經(jīng)實踐EA 符合目前汽車行業(yè)車身域系統(tǒng)設(shè)計需求。
應(yīng)用EA 開展系統(tǒng)設(shè)計,有利于設(shè)計協(xié)同性和信息查詢的便利性。應(yīng)用EA 進行設(shè)計的人員,可以分模塊化同步開展工作,相互之間不干擾,有依賴需求時通過圖表元素建立關(guān)系,各個系統(tǒng)的設(shè)計人員之間從圖表元素中獲得對方的需求,進行協(xié)同設(shè)計。在設(shè)計中及設(shè)計完成后,有信息需要查詢和確認時,利用關(guān)鍵字符可以在EA 中檢索出元素的所有依賴關(guān)系,方便查詢。
EA 不僅適用于企業(yè)架構(gòu)設(shè)計,EA 也可以成一款汽車車身控制域系統(tǒng)設(shè)計的輔助軟件,提升設(shè)計效率,改善設(shè)計質(zhì)量。
編輯:黃飛
?
評論
查看更多