一种基于DLL的软件架构.pdf

本发明提供一种基于DLL的软件架构，包括：硬件设备驱动层、硬件设备接口层、打包层、解析层、策略层、输出层和应用层，所述硬件设备驱动层用于驱动不同的硬件设备，所述硬件设备接口层用于针对不同的硬件设备对外层提供统一的接口，所述打包层用于对各不同类型数据进行统一封装，所述解析层用于提供DBC文件的读取接口，所述策略层用于提供策略配置文件接口，所述输出层用于提供输出队列，所述应用层用于提供各种成型的应用函数接口。本发明使用DLL技术对软件体系结构进行多层次划分，灵活的向用户提供不同需求组合、及各种新需求的上位机方案，方便各种用户权限的控制和管理。

权利要求书
1.  一种基于DLL的软件架构，其特征在于，包括均以动态链接库形式实现的硬件设备驱动层、硬件设备接口层、打包层、解析层、策略层、输出层和应用层，所述硬件设备驱动层用于驱动不同的硬件设备，所述硬件设备接口层为各不同硬件设备的扩展的API 经编译、链接后形成的动态链接库DLL，用于针对不同的硬件设备对外层提供统一的接口；所述打包层用于对各不同类型数据进行统一封装；所述解析层用于提供DBC文件的读取接口，所述策略层用于提供策略配置文件接口；所述输出层用于提供输出队列；所述应用层用于提供各种成型的应用函数接口。

2.  根据权利要求1所述的一种基于DLL的软件架构，其特征在于，所述打包层对各不同类型数据进行统一封装后的数据格式为EPCAN结构，所述EPCAN结构包括CANid、CANdata和CANattribute 三大部分，所述CANid为数据ID部分，所述CANdata为数据体部分，所述CANattribute为数据属性部分。

3.  如权利要求1所述的一种基于DLL的软件架构，其特征在于，所述策略层还用于提供用户个性化需求的接口，所述输出层还用于对外层提供报警消息。

说明书一种基于DLL的软件架构
技术领域
本发明涉及软件技术领域，具体涉及一种基于DLL的软件架构。
背景技术
软件架构（software architecture）用于指导大型软件系统各个方面的设计。一般的软件架构都是固定的，如果需要升级和改动，就需要升级整个框架；且普通的软件框架结构在引用的时候，必须整体完全引用才能发挥作用，如图1所示，或者对一些小型项目，例如像WinCE这种小型系统，则无法引用；再者，一般的软件架构兼容性差，无法和CANoe、MATLAB等这些工业界常用的软件对接，已有的文件和数据结构、数据接口都无法直接使用，需要定制开发对应的数据转化工具，或者就只能重新修改已有软件系统适应新数据类型。
DLL的英文全称是Dynamic Link Library，中文含义为动态链接库，很多应用程序往往被分割成一些相互独立的动态链接库，即DLL文件，当要执行某个程序时，相应的DLL就会被调用。一个应用程序可有多个DLL文件，一个DLL文件也可能被几个应用程序所共用，DLL文件是完全独立于其上位应用程序的。现有的DLL应用最多只是通过DLL来实现某个单一的功能需求，完全谈不上架构级别的设计。例如，对于电动车上的电源管理系统BMS来说，用于读取历史故障数据的EHCL.dll，其只能提供对主板中数据的读取、解析和删除功能，而其他数据读取和解析是无法做到的。且，现有的DLL功能都是完全独立于应用程序的，也就是说，一个DLL文件中既包括对底层硬件的操作，也包括对上层的数据逻辑操作。
发明内容
本发明所要解决的技术问题是通过DLL技术来规划和设计应用程序的整体软件体系结构，如图2所示，将一个大的软件体系从底层硬件层开始，由下往上分解成多个DLL层次结构，每个DLL组份只负责本层的操作，以使得开发出的应用程序具有更好的效率、灵活性和兼容性。
本发明的技术方案为：一种基于DLL的软件架构，其包括均以动态链接库形式实现的硬件设备驱动层、硬件设备接口层、打包层、解析层、策略层、输出层和应用层，所述硬件设备驱动层为各不同硬件设备的扩展的API 经编译、链接后形成的动态链接库DLL，用于驱动不同的硬件设备；所述硬件设备接口层用于针对不同的硬件设备对外层提供统一的接口，所述打包层用于对各不同类型数据进行统一封装，所述解析层用于提供DBC文件的读取接口，所述策略层用于提供策略配置文件接口，所述输出层用于提供输出队列，所述应用层用于提供各种成型的应用函数接口。
优选地，所述打包层对各不同类型数据进行统一封装后的数据格式为EPCAN结构，所述EPCAN结构包括CANid、CANdata和CANattribute 三大部分，所述CANid为数据ID部分，所述CANdata为数据体部分，所述CANattribute为数据属性部分。
优选地，所述策略层还用于提供用户个性化需求的接口，所述输出层还用于对外层提供报警消息。
本发明具有如下优点和有益效果：
1、如果需要升级或改动时，基于DLL的软件架构只需要升级相应的单独的DLL文件即可，整个框架不需要大的变动，既通过框架保证了整体软件的统一性，又没有牺牲灵活性；
2、基于DLL的软件架构是通过多个DLL文件组合而成的，可以对某个DLL文件进行单独引用，比普通的体系架构具有更广泛的使用空间；
3、由于采取DLL的形式，摆脱了对使用的语言和软件的环境限制，只要是支持DLL接口的语言和软件，都可以使用该体系结构；
4、通过策略层的设计满足用户的个性化需求。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要的附图做简单的介绍，显而易见地，下面描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本现有技术中的DLL整体框架及调用示意图；
图2为本发明的DLL各层次框架及调用示意图；
图3为本发明的基于DLL的软件体系结构的各层次示意图；
图4本发明实施例的函数类的初始化方法示意图；
图5为本发明实施例的CAN数据帧结构示意图。
具体实施方式
下面结合说明书附图对本发明实施例的具体实施方式作详细说明。
本实施例以电动车的电池管理系统BMS为例，由于BMS内部一般基于CAN总线设备进行通信，所以以CAN卡作为底层硬件设备、以完成数据读取功能为例进行具体说明。本实施例中的基于DLL的软件架构如图3所示，包括硬件设备驱动层110、硬件设备接口层120、打包层130、解析层140、策略层150、输出层160和应用层170，上述各层的软件程序均以DLL（动态链接库）的形式实现。
所述硬件设备驱动层110对CAN卡进行识别，即由所述硬件设备驱动层110中的API（Application Processs Interface,应用程序接口）对CAN卡进行型号读取，如果读取成功，则表明当前的API可以驱动该型号的CAN卡，例如识别目前系统使用的CAN卡是周立功CAN卡2UE型号、2A型号还是其他的型号，比如CANoe等，API对硬件信息的识别操作都非常快，即便是多个不同的API依次询问读取，时间也非常短，总时间不超过1秒，如果增加了其他的硬件设备，则只需扩展不同的API即可增加硬件识别的类型。在上述CAN卡识别的过程中，上位机应用程序不需做出相应的选择，只要提供CAN卡的通道数和波特率即可。将所述各不同硬件设备的扩展的API 经编译、链接后存储于一个动态链接库DLL中，即构成了基于DLL的硬件设备驱动层110，所述基于DLL的硬件设备驱动层110能够被单独引用或单独进行升级。
     所述硬件设备接口层120用于针对不同的硬件设备对外层提供统一的接口。对于不同的厂家的CAN卡设备，其函数名称和参数列表是不同的，但是如果从驱动CAN的主要功能来分，都提供硬件连接、初始化、接收信息、发送信息等几个主要功能，硬件接口层对其他层开放的函数接口就是功能开放的固定的接口，对于硬件接口层内部，则更具硬件驱动层，识别的硬件结果，用逻辑关系，自动调用不同厂家的API，组合和调整为 API的调用顺序，并重写参数列表，以保证调整后，可以对外统一函数名称和参数列表，从而实现对外接口不变。如果上位机自己通过代码驱动，则需要在代码中知道用的是哪种设备，然后再对应去调用该设备的API接口。而硬件设备接口层120提供各不同厂家的CAN卡设备所对应的不同的API，并针对该不同的API生产统一的函数接口，这样对于硬件设备接口层120而言，就只有一种CAN卡设备存在。所以不管硬件设备驱动层110自动识别出了哪种CAN卡设备，硬件设备接口层120都可以用单一的方法去驱动。所以对上位机而言，既不需要去识别具体的CAN卡设备，也不许要关心该如何驱动该设备。例如周立功的API，2A型号的API中，对于CAN的波特率的设置、CAN卡接收码屏蔽码设置，都是一个函数，只需要先赋值VCI_INIT_CONFI
结构体，然后再调用VCI_InitCAN函数即可，而2EU型号的API中，除了要赋值VCI_INIT_CONFIG结构体外，还需要使用VCI_FILTER_RECORD 结构体和VCI_SetReference函数波特率和滤波进行设置，而且过程中还使用到了新数据结构VCI_FILTER_RECORD，最后才去调VCI_InitCAN函数。 所以即使是同一厂家，其对不同类型的CAN卡API的调用方法和顺序也都不一样。而对此，本发明中的软件框架采取了使用EPCANFunction类作为硬件设备接口层120 的基类，其他的API的调用类，都是从此类派生出来的，而EPCANFunction类的方法都是虚方法，具体的实现是由其继承类实现重写的。在重写的过程中，不同的类使用不API函数和调用顺序，但是当EPCANFunction类实现时，它的实例对象会根据C#语言的面相对象特性，当确认硬件类型后，由EPCANFunction的派生类自动的调用相应的API函数。这是由面向对象语言的多态属性来完成的。所以对硬件接口层120的上层，打包层130而言，并不知道有有多种硬件API，对它而言只有EPCANFunction类提供的方法。这样在打包层的代码中，对硬件调用的代码就是唯一的。参见图4，EPCANFunction类的EPCAN_InitFunction方法提供CAN卡的初始化，API-A、API-B和API-C是不同厂家的API，但是都是由EPCANFunction类派生出来的，它们各自的Init()发方法都是去重写EPCAN_InitFunction，所以当上层调用EPCANFunction类的EPCAN_InitFunction方法时，本质上是有下面的具体的API类实现的，但对上层代码而言，就算是添加新的硬件和API，对EPCANFunction类的EPCAN_InitFunction 方法是不变的，这样就做出了隔离。不管硬件如何变化，上层的代码都不会产生影响。
所述打包层130用于对各不同类型数据进行统一封装。和硬件驱动一样，各厂家对CAN数据的封装和定义也是不同的，为了应对不同硬件厂家的各不同CAN数据类型，DLL框架自定义一套完整的EPCAN数据结构，EPCAN的包括CANid、CANdata、CANattribute 三大部分，对打包层之上的各层而言只要对 EPCAN进行解读就可以，对其他层而言也是对不同厂家数据的一种隔离机制。现有的CAN数据按照国际标准分为带有11bit标识符CAN2.0A和带有29bit标识符的CAN2.0B扩展CAN消息，参见图5。而各CAN设备厂家也会对这两种数据结构进行不同的描述，本发明的基于DLL的软件体系结构需要满足多个厂家的对两种格式的解析则必须采取兼容的数据结构。究其本质，CAN数据的数据部分都是8字节，而CAN数据的ID都是唯一的，所以在本发明自定义的EPCAN数据结构中，单独提起了最大0xFFFF FFFF 的CANid和最大8字节的CANdata这两部分，而其他的部分，则统称CANattribute部分，所述CANattribute包括CANtime和CANature，CANtime 是时间标识，最大为0xFFFF FFFF，CANature是一个字节，用8个bit来表示CAN数据中的属性，本实施例中只用前4个bit，后4个bit作为扩展， 前4个bit从左到右每一比特位的意义分别为：第一比特位表示是否为扩展帧，当为1时是扩展帧，当为0时表示不是扩展帧，第二比特位表示帧类型，当为1时表示数据帧，当为0时表示为远程帧，第三比特位表示传输方向，当为0时表示接收，当为1时表示发送，第四比特位表示编码格式，当为1时为Intel格式编码，当为0时为Motorola格式编码。在使用CAN数据之前，打包层会把不同的数据结构统一打包成DLL自定义的EPCAN数据结构。这样对打包层之上的其他各层而言，在处理CAN报文的时候，就不用关心各厂家的不同定义，而只需对 EPCAN进行解读就可以。
所述解析层140用于提供DBC（数据库容器）文件的读取接口，使用代码反射，自动解析收到的数据包，而不是写死固定的解析代码。代码反射主要是指程序可以访问、检测和修改它本身状态或行为的一种能力。C#语言通过 .Net Framework 中提供了反射机制，可以在加载程序运行时，动态获取和加载程序集，并且可以获取到程序集的信息。在程序集中，包含模块（Module），模块包含类型，类型包含成员。提供代码反射就可以查看到一个程序集的路径、命名空间和类，并且还可以对其进行操作。本申请中的应用是由于DBC文件内容不同，利用代码反射自动的动态的生产代码来进行解析，而不是针对某一份文件去写很多判断逻辑，是代码自动生产的范畴。为了实现根据不同的需求，使用不同的代码去解析，从C# 的语法上来说有两种解决方式，一种是采取虚函数的方法，让各种方法都继承于某一虚函数，这样实际编码中，就没有制定具体的方法，而是在函数初始化的时候再决定使用哪种方法； 另一种方法，就是代码反射，预先把要生成的某种逻辑，通过配置文件的形式写好，当需要的时候，通过代码反射，直接从配置文件中，得到相应的数据类型、代码逻辑、动态的生成新的代码。 CAN数据解析的需求，在提供了.dbc 文件，实际上就是提供了如何去解析CAN数据的详细的配置文件，所以使用代码反射，在本申请中更符合实际需求。相反，本申请无法使用虚函数的方法，因为 .dbc文件的格式虽然确定，但是内容多少并不确定，也许是解析10帧CAN数据，也许是解析100帧CAN数据，虚函数并无法应对这种动态的需求。.dbc文件可以作为一种配置文件来看待，其详细描述了每帧数据，每个字节每个bit 的含义，所以根据此描述，可以对每一帧数据，出对应的解析代码。但是这个代码是动态的，因为现在加载的.dbc 文件，并不代表你下一次解析的时候还是这个规则，很有可能下次就要加载不同的.dbc文件了。所以根据.dbc文件写的解析代码一定是动态的。而代码反射，是根据业务逻辑，和事先写好的部分代码，从配置文件中，反射出动态的数据类型，和数据逻辑，从而实现动态自动生产代码的功能。换言之，通过代码反射，可以根据不同.dbc文件，动态的生成了不同的解析代码。当数据解析时，只要给解析层指定.DBC文件的路径，解析层就会按照.DBC文件的格式自动解析变量。正是由于打包层已经统一了CAN报文的格式，所以解析层才能够不用关心报文格式，而只需对照.DBC文件的格式进行解析即可。
所述策略层150具有两个基本功能，一个是完成应用层170的基本功能，如数据接收或数据发送时，用于确定是对每帧报文都进行解析还是只针对特定帧进行解析；另一个是给上位机提供灵活实现用户个性化需求的函数接口，比如上位机要实现握手通信，此时应该是边发数据边收数据，那么两个进程切换的时间、等待的时间、如果出现超时是否应该重复发送、或者重复发几次等，这些控制性的需求，策略层都给上位机提供接口。
所述输出层160输出层则是DLL体系结构向外界提供消息队列和数据队列的地方。当数据接收，并自动解析后，上位机就是通过输出层提供的变量队列输出的，上位机可以从变量队列中读取某一变量的具体数值。另外消息队列还提供DLL体系结构对外界的消息和报警，比如CAN硬件连接失败，CAN线断开等。此外，所述输出层160还有详细的日志文档功能。
所述应用层170向上位机提供成型功能的函数接口。比如主从板的历史故障数据读取，实现这个功能的时候需要主动向下位机发出命令先暂停普通BMS信号，再接收历史故障信号。而解析这部分信号的方法与BMS工作时的信号解析也不同，是单独的历史故障信息的通信协议。所以应用层把这部分业务，直接打包成固定的函数接口。上位机要完成此业务，只需要调用此函数接口，就可以由应用层独立的完成读取、解析和存储历史故障数据的业务了。直接通过人机界面即可，不用关心内部业务是如何具体实现的。值得注意的是，此处的应用层170不是单一提供某一功能函数的接口，而是向上位机提供整业务的接口，如硬件程序烧写业务接口，历史故障数据业务接口等。
值得注意的是，本发明中的各层，即硬件设备驱动层110、硬件设备接口层120、打包层130、解析层140、策略层150、输出层160和应用层170就是以dll 的形式存在的。传统的软件架构，如图1所示，都是把各层都以代码文件形存在，架构搭好之后，用一个dll来封装，对外开放接口。而本申请中的软件架构，其各层本身就是以.dll 的形式存在的，如图2所示，所以各层可以直接调用。API 在使用时需要开发方提供详细的dll函数列表、各个函数功能以及参数列表，所以就算是直接提供各层的.dll而没有提供各项说明的话，对外部用户来说也是安全的。为了慎重考虑，在开放外部用户时，只需要在最外部加一层用户调用.dll 进行封装，就可以完全避免任何安全问题。这样使用dll的框架的好处是对于内部研发部门和工程师而言，既提供了灵活方便的调用条件，又可以保证代码的安全性，因为就算是直接调用基础的dll ，这一整套的dll 也是经过严格检查的，所以对代码质量和效率都是非常大的提升。
以上所述实施例仅表达了本发明的优选的实施方式，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。