车载单元的软件架构设计方法及系统技术方案

本发明专利技术涉及了一种车载单元的软件架构设计方法和系统，该软件架构设计方法包括：在车载单元的应用软件和硬件SDK之间增加至少一个抽象接口及至少一个接口驱动，其中，所述抽象接口用于声明与相应应用场景相关的接口；所述接口驱动用于根据所述硬件SDK定义所述抽象接口；当所述车载单元的硬件平台变更时，对所述接口驱动进行修改。实施本发明专利技术的技术方案，降低车载单元的产品研发成本，从而达到快速适配不同硬件平台的目的。

【技术实现步骤摘要】
车载单元的软件架构设计方法及系统
本专利技术涉及ETC领域，尤其涉及一种车载单元的软件架构设计方法及系统。
技术介绍
在ETC行业，车载单元(OBU)的硬件平台种类较多，各厂家在开发车载单元产品的过程中，硬件平台频繁变更。车载单元属于嵌入式系统，它的软件部分和硬件部分有很强的耦合关系，如图1所示，箭头的方向表示车载单元的软件系统的各个子系统的依赖方向，即“应用软件”子系统依赖于“硬件SDK”子系统，而“硬件SDK”子系统依赖于“硬件平台”。当硬件平台变更时，硬件SDK的接口必然变化，从而导致研发人员需要对应用软件进行全面修改，因此，产品开发和测试的工作量大、进度慢，容易产生产品故障等问题。另外，对于研发管理者来说，车载单元的产品业务功能并没有任何变化，但是仍需要研发人员把软件代码全面修改一遍，导致产品开发进度和产品质量同时受到不良影响。
技术实现思路
本专利技术要解决的技术问题在于，针对现有技术存在产品开发和测试的工作量大、进度慢的缺陷，提供一种车载单元的软件架构设计方法及系统。本专利技术解决其技术问题所采用的技术方案是：构造一种车载单元的软件架构设计方法，包括：在车载单元的应用软件和硬件SDK之间增加至少一个抽象接口及至少一个接口驱动，其中，所述抽象接口用于声明与相应应用场景相关的接口；所述接口驱动用于根据所述硬件SDK定义所述抽象接口；当所述车载单元的硬件平台变更时，对所述接口驱动进行修改。优选地，在车载单元的应用软件和硬件SDK之间增加至少一个抽象接口，包括：根据所述应用软件的至少一个应用业务，在车载单元的应用软件和硬件SDK之间增加与每个应用业务一一对应的抽象接口。优选地，所述应用软件的应用业务包括下列中的至少一个：ETC交易应用业务、OBU插卡应用业务、OBU防拆应用业务、OBU休眠应用业务、OBU生产测试应用业务、OBU蓝牙应用业务、OBU人机交互应用业务。优选地，在车载单元的应用软件和硬件SDK之间增加至少一个抽象接口，包括：根据所述车载单元的至少一个硬件单元，在车载单元的应用软件和硬件SDK之间增加与每个硬件单元一一对应的抽象接口。优选地，所述车载单元的硬件单元包括下列中的至少一个：5.8GETC芯片、13.56M近场通信芯片、板级支持包、蓝牙芯片。本专利技术还构造一种车载单元的软件系统，包括应用软件和硬件SDK，还包括：设置在所述应用软件和所述硬件SDK之间的至少一个抽象接口及至少一个接口驱动，其中，所述抽象接口，用于声明与相应应用场景相关的接口；所述接口驱动，用于根据所述硬件SDK定义所述抽象接口，而且，当所述车载单元的硬件平台变更时，允许根据变更后的硬件平台所对应的硬件SDK重新定义所述抽象接口。优选地，所述抽象接口，具体用于声明所述应用软件的相应应用业务的接口。优选地，所述应用软件的应用业务包括下列中的至少一个：ETC交易应用业务、OBU插卡应用业务、OBU防拆应用业务、OBU休眠应用业务、OBU生产测试应用业务、OBU蓝牙应用业务、OBU人机交互应用业务。优选地，所述抽象接口，具体用于声明所述车载单元的至少一个硬件单元的接口。优选地，所述车载单元的硬件单元包括下列中的至少一个：5.8GETC芯片、13.56M近场通信芯片、板级支持包、蓝牙芯片。本专利技术所提供的技术方案，在车载单元硬件平台频繁变更的现实场景下，通过在车载单元的应用软件与硬件SDK之间增加抽象接口及接口驱动来实现应用软件与硬件平台的解耦。而且，由于应用软件和抽象接口都是稳定的、基本不变的，所以，在硬件平台变更时，只要将硬件SDK(通常由芯片厂商提供)整体更换，并对只依赖于硬件SDK的接口驱动进行重新开发即可。因此，降低了软件研发和测试的工作量，加快产品开发进度，提高产品软件质量，从而降低车载单元的产品研发成本，从而达到快速适配不同硬件平台的目的。附图说明为了更清楚地说明本专利技术实施例，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本专利技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。附图中：图1是现有的车载单元的软件系统的逻辑结构图；图2是本专利技术车载单元的软件架构设计方法实施例一的流程图；图3是本专利技术车载单元的软件系统实施例一的逻辑结构图；图4是本专利技术车载单元的软件系统实施例二的逻辑结构图；图5是本专利技术车载单元的软件系统实施例三的逻辑结构图。具体实施方式下面将结合本专利技术实施例中的附图，对本专利技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本专利技术一部分实施例，而不是全部的实施例。基于本专利技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本专利技术保护的范围。为了解决当车载单元的硬件平台变更时产品开发和测试的工作量大、进度慢等问题，本专利技术在车载单元的应用软件与硬件SDK之间增加隔离层(抽象接口及接口驱动)，并且将应用软件与硬件SDK之间的依赖关系反转过来，即，避免应用软件对硬件SDK的依赖造成应用软件跟着硬件SDK修改。图2是本专利技术车载单元的软件架构设计方法实施例一的流程图，该实施例的车载单元的软件架构设计方法包括以下步骤：步骤S10.在车载单元的应用软件和硬件SDK之间增加至少一个抽象接口及至少一个接口驱动，其中，所述抽象接口用于声明与相应应用场景相关的接口；所述接口驱动用于根据所述硬件SDK定义所述抽象接口；在该步骤中，结合图3所示的在车载单元的软件系统，在应用软件10与硬件SDK40之间增加了两个组件：抽象接口20、接口驱动30，以作为应用软件10与硬件SDK40之间的隔离层。抽象接口20是一个与应用场景相关的接口的声明，例如，抽象接口etc_intf_rf_tx()，表示声明了一个抽象的“ETC射频发送接口”，而且，抽象接口是稳定的、基本不变的。另外，抽象接口可根据不同的应用场景来设计，在实际应用中，抽象接口20的数量可为多个。例如，可根据车载单元应用软件的应用业务处理流程需求而设计，也可根据车载单元的硬件单元划分而设计。接口驱动30是抽象接口20的真正实现，它是抽象接口20的具体定义，例如，dsrc_intf_tx(){sl1102_tx()；}，表示定义了“ETC射频发送接口”的具体实现，它是使用(依赖)sl1102这款ETC芯片的硬件SDK实现的。在实际应用中，接口驱动30的数量与抽象接口20的数量相同，且两者一一对应。步骤S20.当所述车载单元的硬件平台变更时，对所述接口驱动进行修改。在该步骤中，结合图3，由于接口驱动30依赖于车载单元的硬件SDK40，所以，当车载单元的硬件平台50变更时，只需根据变更后的硬件平台所对应的硬件SDK40来修改接口驱动30即可。该实施例的技术方案，通过在车载单元的应用软件与本文档来自技高网...

【技术保护点】
1.一种车载单元的软件架构设计方法，其特征在于，包括：/n在车载单元的应用软件和硬件SDK之间增加至少一个抽象接口及至少一个接口驱动，其中，所述抽象接口用于声明与相应应用场景相关的接口；所述接口驱动用于根据所述硬件SDK定义所述抽象接口；/n当所述车载单元的硬件平台变更时，对所述接口驱动进行修改。/n

【技术特征摘要】
1.一种车载单元的软件架构设计方法，其特征在于，包括：
在车载单元的应用软件和硬件SDK之间增加至少一个抽象接口及至少一个接口驱动，其中，所述抽象接口用于声明与相应应用场景相关的接口；所述接口驱动用于根据所述硬件SDK定义所述抽象接口；
当所述车载单元的硬件平台变更时，对所述接口驱动进行修改。


2.根据权利要求1所述的车载单元的软件架构设计方法，其特征在于，在车载单元的应用软件和硬件SDK之间增加至少一个抽象接口，包括：
根据所述应用软件的至少一个应用业务，在车载单元的应用软件和硬件SDK之间增加与每个应用业务一一对应的抽象接口。


3.根据权利要求2所述的车载单元的软件架构设计方法，其特征在于，所述应用软件的应用业务包括下列中的至少一个：ETC交易应用业务、OBU插卡应用业务、OBU防拆应用业务、OBU休眠应用业务、OBU生产测试应用业务、OBU蓝牙应用业务、OBU人机交互应用业务。


4.根据权利要求1所述的车载单元的软件架构设计方法，其特征在于，在车载单元的应用软件和硬件SDK之间增加至少一个抽象接口，包括：
根据所述车载单元的至少一个硬件单元，在车载单元的应用软件和硬件SDK之间增加与每个硬件单元一一对应的抽象接口。


5.根据权利要求4所述的车载单元的软件架构设计方法，其特征在于，所述车载单元的硬件单元包...

【专利技术属性】
技术研发人员：罗胜金，
申请(专利权)人：深圳市金溢科技股份有限公司，
类型：发明
国别省市：广东;44