一種基于dll的軟件架構(gòu)的制作方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及軟件技術(shù)領(lǐng)域，具體涉及一種基于DLL的軟件架構(gòu)。
【背景技術(shù)】
[0002]軟件架構(gòu)(software architecture)用于指導(dǎo)大型軟件系統(tǒng)各個(gè)方面的設(shè)計(jì)。一般的軟件架構(gòu)都是固定的，如果需要升級(jí)和改動(dòng)，就需要升級(jí)整個(gè)框架；且普通的軟件框架結(jié)構(gòu)在引用的時(shí)候，必須整體完全引用才能發(fā)揮作用，如圖1所示，或者對(duì)一些小型項(xiàng)目，例如像WinCE這種小型系統(tǒng)，則無(wú)法引用；再者，一般的軟件架構(gòu)兼容性差，無(wú)法和CANoe、MATLAB等這些工業(yè)界常用的軟件對(duì)接，已有的文件和數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)接口都無(wú)法直接使用，需要定制開(kāi)發(fā)對(duì)應(yīng)的數(shù)據(jù)轉(zhuǎn)化工具，或者就只能重新修改已有軟件系統(tǒng)適應(yīng)新數(shù)據(jù)類型。
[0003]DLL的英文全稱是Dynamic Link Library,中文含義為動(dòng)態(tài)鏈接庫(kù),很多應(yīng)用程序往往被分割成一些相互獨(dú)立的動(dòng)態(tài)鏈接庫(kù)，即DLL文件，當(dāng)要執(zhí)行某個(gè)程序時(shí)，相應(yīng)的DLL就會(huì)被調(diào)用。一個(gè)應(yīng)用程序可有多個(gè)DLL文件，一個(gè)DLL文件也可能被幾個(gè)應(yīng)用程序所共用，DLL文件是完全獨(dú)立于其上位應(yīng)用程序的?，F(xiàn)有的DLL應(yīng)用最多只是通過(guò)DLL來(lái)實(shí)現(xiàn)某個(gè)單一的功能需求，完全談不上架構(gòu)級(jí)別的設(shè)計(jì)。例如，對(duì)于電動(dòng)車上的電源管理系統(tǒng)BMS來(lái)說(shuō)，用于讀取歷史故障數(shù)據(jù)的EHCL.dll，其只能提供對(duì)主板中數(shù)據(jù)的讀取、解析和刪除功能，而其他數(shù)據(jù)讀取和解析是無(wú)法做到的。且，現(xiàn)有的DLL功能都是完全獨(dú)立于應(yīng)用程序的，也就是說(shuō)，一個(gè)DLL文件中既包括對(duì)底層硬件的操作，也包括對(duì)上層的數(shù)據(jù)邏輯操作。

【發(fā)明內(nèi)容】

[0004]本發(fā)明所要解決的技術(shù)問(wèn)題是通過(guò)DLL技術(shù)來(lái)規(guī)劃和設(shè)計(jì)應(yīng)用程序的整體軟件體系結(jié)構(gòu)，如圖2所示，將一個(gè)大的軟件體系從底層硬件層開(kāi)始，由下往上分解成多個(gè)DLL層次結(jié)構(gòu)，每個(gè)DLL組份只負(fù)責(zé)本層的操作，以使得開(kāi)發(fā)出的應(yīng)用程序具有更好的效率、靈活性和兼容性。
[0005]本發(fā)明的技術(shù)方案為:一種基于DLL的軟件架構(gòu)，其包括均以動(dòng)態(tài)鏈接庫(kù)形式實(shí)現(xiàn)的硬件設(shè)備驅(qū)動(dòng)層、硬件設(shè)備接口層、打包層、解析層、策略層、輸出層和應(yīng)用層，所述硬件設(shè)備驅(qū)動(dòng)層為各不同硬件設(shè)備的擴(kuò)展的API經(jīng)編譯、鏈接后形成的動(dòng)態(tài)鏈接庫(kù)DLL，用于驅(qū)動(dòng)不同的硬件設(shè)備；所述硬件設(shè)備接口層用于針對(duì)不同的硬件設(shè)備對(duì)外層提供統(tǒng)一的接口，所述打包層用于對(duì)各不同類型數(shù)據(jù)進(jìn)行統(tǒng)一封裝，所述解析層用于提供DBC文件的讀取接口，所述策略層用于提供策略配置文件接口，所述輸出層用于提供輸出隊(duì)列，所述應(yīng)用層用于提供各種成型的應(yīng)用函數(shù)接口。
[0006]優(yōu)選地，所述打包層對(duì)各不同類型數(shù)據(jù)進(jìn)行統(tǒng)一封裝后的數(shù)據(jù)格式為EPCAN結(jié)構(gòu)，所述EPCAN結(jié)構(gòu)包括CANicUCANdata和CANattribute三大部分，所述CANid為數(shù)據(jù)ID部分，所述CANdata為數(shù)據(jù)體部分，所述CANattribute為數(shù)據(jù)屬性部分。
[0007]優(yōu)選地，所述策略層還用于提供用戶個(gè)性化需求的接口，所述輸出層還用于對(duì)外層提供報(bào)警消息。
[0008]本發(fā)明具有如下優(yōu)點(diǎn)和有益效果:
1、如果需要升級(jí)或改動(dòng)時(shí)，基于DLL的軟件架構(gòu)只需要升級(jí)相應(yīng)的單獨(dú)的DLL文件即可，整個(gè)框架不需要大的變動(dòng)，既通過(guò)框架保證了整體軟件的統(tǒng)一性，又沒(méi)有犧牲靈活性；
2、基于DLL的軟件架構(gòu)是通過(guò)多個(gè)DLL文件組合而成的，可以對(duì)某個(gè)DLL文件進(jìn)行單獨(dú)引用，比普通的體系架構(gòu)具有更廣泛的使用空間；
3、由于采取DLL的形式，擺脫了對(duì)使用的語(yǔ)言和軟件的環(huán)境限制，只要是支持DLL接口的語(yǔ)言和軟件，都可以使用該體系結(jié)構(gòu)；
4、通過(guò)策略層的設(shè)計(jì)滿足用戶的個(gè)性化需求。
【附圖說(shuō)明】
[0009]為了更清楚地說(shuō)明本發(fā)明實(shí)施例的技術(shù)方案，下面將對(duì)實(shí)施例描述中所需要的附圖做簡(jiǎn)單的介紹，顯而易見(jiàn)地，下面描述的附圖僅僅是本發(fā)明的一些實(shí)施例，對(duì)于本領(lǐng)域普通技術(shù)人員來(lái)講，在不付出創(chuàng)造性勞動(dòng)的前提下，還可以根據(jù)這些附圖獲得其他的附圖。
[0010]圖1為本現(xiàn)有技術(shù)中的DLL整體框架及調(diào)用示意圖；
圖2為本發(fā)明的DLL各層次框架及調(diào)用示意圖；
圖3為本發(fā)明的基于DLL的軟件體系結(jié)構(gòu)的各層次示意圖；
圖4本發(fā)明實(shí)施例的函數(shù)類的初始化方法示意圖；
圖5為本發(fā)明實(shí)施例的CAN數(shù)據(jù)幀結(jié)構(gòu)示意圖。
【具體實(shí)施方式】
[0011]下面結(jié)合說(shuō)明書(shū)附圖對(duì)本發(fā)明實(shí)施例的【具體實(shí)施方式】作詳細(xì)說(shuō)明。
[0012]本實(shí)施例以電動(dòng)車的電池管理系統(tǒng)BMS為例，由于BMS內(nèi)部一般基于CAN總線設(shè)備進(jìn)行通信，所以以CAN卡作為底層硬件設(shè)備、以完成數(shù)據(jù)讀取功能為例進(jìn)行具體說(shuō)明。本實(shí)施例中的基于DLL的軟件架構(gòu)如圖3所示，包括硬件設(shè)備驅(qū)動(dòng)層110、硬件設(shè)備接口層120、打包層130、解析層140、策略層150、輸出層160和應(yīng)用層170，上述各層的軟件程序均以DLL (動(dòng)態(tài)鏈接庫(kù))的形式實(shí)現(xiàn)。
[0013]所述硬件設(shè)備驅(qū)動(dòng)層110對(duì)CAN卡進(jìn)行識(shí)別，即由所述硬件設(shè)備驅(qū)動(dòng)層110中的APKApplicat1n Processs Interface,應(yīng)用程序接口)對(duì)CAN卡進(jìn)行型號(hào)讀取,如果讀取成功，則表明當(dāng)前的API可以驅(qū)動(dòng)該型號(hào)的CAN卡，例如識(shí)別目前系統(tǒng)使用的CAN卡是周立功CAN卡2UE型號(hào)、2A型號(hào)還是其他的型號(hào)，比如CANoe等，API對(duì)硬件信息的識(shí)別操作都非?？欤幢闶嵌鄠€(gè)不同的API依次詢問(wèn)讀取，時(shí)間也非常短，總時(shí)間不超過(guò)I秒，如果增加了其他的硬件設(shè)備，則只需擴(kuò)展不同的API即可增加硬件識(shí)別的類型。在上述CAN卡識(shí)別的過(guò)程中，上位機(jī)應(yīng)用程序不需做出相應(yīng)的選擇，只要提供CAN卡的通道數(shù)和波特率即可。將所述各不同硬件設(shè)備的擴(kuò)展的API經(jīng)編譯、鏈接后存儲(chǔ)于一個(gè)動(dòng)態(tài)鏈接庫(kù)DLL中，即構(gòu)成了基于DLL的硬件設(shè)備驅(qū)動(dòng)層110，所述基于DLL的硬件設(shè)備驅(qū)動(dòng)層110能夠被單獨(dú)引用或單獨(dú)進(jìn)行升級(jí)。
[0014]所述硬件設(shè)備接口層120用于針對(duì)不同的硬件設(shè)備對(duì)外層提供統(tǒng)一的接口。對(duì)于不同的廠家的CAN卡設(shè)備，其函數(shù)名稱和參數(shù)列表是不同的，但是如果從驅(qū)動(dòng)CAN的主要功能來(lái)分，都提供硬件連接、初始化、接收信息、發(fā)送信息等幾個(gè)主要功能，硬件接口層對(duì)其他層開(kāi)放的函數(shù)接口就是功能開(kāi)放的固定的接口，對(duì)于硬件接口層內(nèi)部，則更具硬件驅(qū)動(dòng)層，識(shí)別的硬件結(jié)果，用邏輯關(guān)系，自動(dòng)調(diào)用不同廠家的API，組合和調(diào)整為API的調(diào)用順序，并重寫參數(shù)列表，以保證調(diào)整后，可以對(duì)外統(tǒng)一函數(shù)名稱和參數(shù)列表，從而實(shí)現(xiàn)對(duì)外接口不變。如果上位機(jī)自己通過(guò)代碼驅(qū)動(dòng)，則需要在代碼中知道用的是哪種設(shè)備，然后再對(duì)應(yīng)去調(diào)用該設(shè)備的API接口。而硬件設(shè)備接口層120提供各不同廠家的CAN卡設(shè)備所對(duì)應(yīng)的不同的API，并針對(duì)該不同的API生產(chǎn)統(tǒng)一的函數(shù)接口，這樣對(duì)于硬件設(shè)備接口層120而言，就只有一種CAN卡設(shè)備存在。所以不管硬件設(shè)備驅(qū)動(dòng)層110自動(dòng)識(shí)別出了哪種CAN卡設(shè)備，硬件設(shè)備接口層120都可以用單一的方法去驅(qū)動(dòng)。所以對(duì)上位機(jī)而言，既不需要去識(shí)別具體的CAN卡設(shè)備，也不許要關(guān)心該如何驅(qū)動(dòng)該設(shè)備。例如周立功的API，2A型號(hào)的API中，對(duì)于CAN的波特率的設(shè)置、CAN卡接收碼屏蔽碼設(shè)置，都是一個(gè)函數(shù)，只需要先賦值VCI_INIT_CONFI
結(jié)構(gòu)體，然后再調(diào)用VCI_InitCAN函數(shù)即可，而2EU型號(hào)的API中，除了要賦值VCI_INIT_C0NFIG 結(jié)構(gòu)體外，還需要使用 VCI_FILTER_RECORD 結(jié)構(gòu)體和 VCI_SetReference 函數(shù)波特率和濾波進(jìn)行設(shè)置，而且過(guò)程中還使用到了新數(shù)據(jù)結(jié)構(gòu)VCI_FILTER_RECORD，最后才去調(diào)VCI_InitCAN函數(shù)。所以即使是同一廠家，其對(duì)不同類型的CAN卡API的調(diào)用方法和順序也都不一樣。而對(duì)此，本發(fā)明中的軟件框架采取了使用EPCANFunct1n類作為硬件設(shè)備接口層120的基類，其他的API的調(diào)用類，都是從此類派生出來(lái)的，而EPCANFunct1n類的方法都是虛方法，具體的實(shí)現(xiàn)是由其繼承類實(shí)現(xiàn)重寫的。在重寫的過(guò)程中，不同的類使用不API函數(shù)和調(diào)用順序，但是當(dāng)EPCANFunct1n類實(shí)現(xiàn)時(shí)，它的實(shí)例對(duì)象會(huì)根據(jù)C#語(yǔ)言的面相對(duì)象特性，當(dāng)確認(rèn)硬件類型后，由EPCANFunct1n的派生類自動(dòng)的調(diào)用相應(yīng)的API函數(shù)。這是由面向?qū)ο笳Z(yǔ)言的多態(tài)屬性來(lái)完成的。所以對(duì)硬件接口層120的上層，打包層130而言，并不知道有有多種硬件API，對(duì)它而言只有EPCANFunct1n類提供的方法。這樣在打包層的代碼中，對(duì)硬件調(diào)用的代碼就是唯一的。參見(jiàn)圖4，EPCANFunct1n類的EPCAN_InitFunct1n方法提供CAN卡的初始化，API_A、API_B和AP1-C是不同廠家的API，但是都是由EPCANFunct1n類派生出來(lái)的，它們各自的InitO發(fā)方法都是去重寫EPCAN_InitFunct1n,所以當(dāng)上層調(diào)用 EPCANFunct1n 類的 EPCAN_InitFunct1n 方法時(shí)，本質(zhì)上是有下面的具體的API類實(shí)現(xiàn)的，但對(duì)上層代碼而言，就算是添加新的硬件和API，對(duì)EPCANFunct1n類的EPCAN_InitFunct1n方法是不變的,這樣就做出了隔離。不管硬件如何變化，上層的代碼都不會(huì)產(chǎn)生影響。
[0015]所述打包層130用于對(duì)各不同類型數(shù)據(jù)進(jìn)行統(tǒng)一封裝。和硬件驅(qū)動(dòng)一樣，各廠家對(duì)CAN數(shù)據(jù)的封裝和定義也是不同的，為了應(yīng)對(duì)不同硬件廠家的各不同CAN數(shù)據(jù)類型，DLL