CN111833470A

CN111833470A - 车载单元的软件架构设计方法及系统

Info

Publication number: CN111833470A
Application number: CN202010530673.3A
Authority: CN
Inventors: 罗胜金
Original assignee: Shenzhen Genvict Technology Co Ltd
Current assignee: Shenzhen Genvict Technology Co Ltd
Priority date: 2020-06-11
Filing date: 2020-06-11
Publication date: 2020-10-27

Abstract

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

Description

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

技术领域

本发明涉及ETC领域，尤其涉及一种车载单元的软件架构设计方法及系统。

背景技术

在ETC行业，车载单元(OBU)的硬件平台种类较多，各厂家在开发车载单元产品的过程中，硬件平台频繁变更。

车载单元属于嵌入式系统，它的软件部分和硬件部分有很强的耦合关系，如图1所示，箭头的方向表示车载单元的软件系统的各个子系统的依赖方向，即“应用软件”子系统依赖于“硬件SDK”子系统，而“硬件SDK”子系统依赖于“硬件平台”。当硬件平台变更时，硬件SDK的接口必然变化，从而导致研发人员需要对应用软件进行全面修改，因此，产品开发和测试的工作量大、进度慢，容易产生产品故障等问题。另外，对于研发管理者来说，车载单元的产品业务功能并没有任何变化，但是仍需要研发人员把软件代码全面修改一遍，导致产品开发进度和产品质量同时受到不良影响。

发明内容

本发明要解决的技术问题在于，针对现有技术存在产品开发和测试的工作量大、进度慢的缺陷，提供一种车载单元的软件架构设计方法及系统。

本发明解决其技术问题所采用的技术方案是：构造一种车载单元的软件架构设计方法，包括：

在车载单元的应用软件和硬件SDK之间增加至少一个抽象接口及至少一个接口驱动，其中，所述抽象接口用于声明与相应应用场景相关的接口；所述接口驱动用于根据所述硬件SDK定义所述抽象接口；

当所述车载单元的硬件平台变更时，对所述接口驱动进行修改。

优选地，在车载单元的应用软件和硬件SDK之间增加至少一个抽象接口，包括：

根据所述应用软件的至少一个应用业务，在车载单元的应用软件和硬件SDK之间增加与每个应用业务一一对应的抽象接口。

优选地，所述应用软件的应用业务包括下列中的至少一个：ETC交易应用业务、OBU插卡应用业务、OBU防拆应用业务、OBU休眠应用业务、OBU生产测试应用业务、OBU蓝牙应用业务、OBU人机交互应用业务。

根据所述车载单元的至少一个硬件单元，在车载单元的应用软件和硬件SDK之间增加与每个硬件单元一一对应的抽象接口。

优选地，所述车载单元的硬件单元包括下列中的至少一个：5.8G ETC芯片、13.56M近场通信芯片、板级支持包、蓝牙芯片。

本发明还构造一种车载单元的软件系统，包括应用软件和硬件SDK，还包括：设置在所述应用软件和所述硬件SDK之间的至少一个抽象接口及至少一个接口驱动，其中，

所述抽象接口，用于声明与相应应用场景相关的接口；

所述接口驱动，用于根据所述硬件SDK定义所述抽象接口，而且，当所述车载单元的硬件平台变更时，允许根据变更后的硬件平台所对应的硬件SDK重新定义所述抽象接口。

优选地，所述抽象接口，具体用于声明所述应用软件的相应应用业务的接口。

优选地，所述抽象接口，具体用于声明所述车载单元的至少一个硬件单元的接口。

本发明所提供的技术方案，在车载单元硬件平台频繁变更的现实场景下，通过在车载单元的应用软件与硬件SDK之间增加抽象接口及接口驱动来实现应用软件与硬件平台的解耦。而且，由于应用软件和抽象接口都是稳定的、基本不变的，所以，在硬件平台变更时，只要将硬件SDK(通常由芯片厂商提供)整体更换，并对只依赖于硬件SDK的接口驱动进行重新开发即可。因此，降低了软件研发和测试的工作量，加快产品开发进度，提高产品软件质量，从而降低车载单元的产品研发成本，从而达到快速适配不同硬件平台的目的。

附图说明

为了更清楚地说明本发明实施例，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。附图中：

图1是现有的车载单元的软件系统的逻辑结构图；

图2是本发明车载单元的软件架构设计方法实施例一的流程图；

图3是本发明车载单元的软件系统实施例一的逻辑结构图；

图4是本发明车载单元的软件系统实施例二的逻辑结构图；

图5是本发明车载单元的软件系统实施例三的逻辑结构图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

为了解决当车载单元的硬件平台变更时产品开发和测试的工作量大、进度慢等问题，本发明在车载单元的应用软件与硬件SDK之间增加隔离层(抽象接口及接口驱动)，并且将应用软件与硬件SDK之间的依赖关系反转过来，即，避免应用软件对硬件SDK的依赖造成应用软件跟着硬件SDK修改。

图2是本发明车载单元的软件架构设计方法实施例一的流程图，该实施例的车载单元的软件架构设计方法包括以下步骤：

步骤S10.在车载单元的应用软件和硬件SDK之间增加至少一个抽象接口及至少一个接口驱动，其中，所述抽象接口用于声明与相应应用场景相关的接口；所述接口驱动用于根据所述硬件SDK定义所述抽象接口；

在该步骤中，结合图3所示的在车载单元的软件系统，在应用软件10与硬件SDK 40之间增加了两个组件：抽象接口20、接口驱动30，以作为应用软件10与硬件SDK 40之间的隔离层。

抽象接口20是一个与应用场景相关的接口的声明，例如，抽象接口etc_intf_rf_tx()，表示声明了一个抽象的“ETC射频发送接口”，而且，抽象接口是稳定的、基本不变的。另外，抽象接口可根据不同的应用场景来设计，在实际应用中，抽象接口20的数量可为多个。例如，可根据车载单元应用软件的应用业务处理流程需求而设计，也可根据车载单元的硬件单元划分而设计。

接口驱动30是抽象接口20的真正实现，它是抽象接口20的具体定义，例如，dsrc_intf_tx(){sl1102_tx()；}，表示定义了“ETC射频发送接口”的具体实现，它是使用(依赖)sl1102这款ETC芯片的硬件SDK实现的。在实际应用中，接口驱动30的数量与抽象接口20的数量相同，且两者一一对应。

步骤S20.当所述车载单元的硬件平台变更时，对所述接口驱动进行修改。

在该步骤中，结合图3，由于接口驱动30依赖于车载单元的硬件SDK 40，所以，当车载单元的硬件平台50变更时，只需根据变更后的硬件平台所对应的硬件SDK 40来修改接口驱动30即可。

该实施例的技术方案，通过在车载单元的应用软件与硬件SDK之间增加抽象接口及接口驱动，来实现应用软件与硬件平台的解耦。而且，由于应用软件和抽象接口都是稳定的、基本不变的，所以，在硬件平台变更时，只要将硬件SDK(通常由芯片厂商提供)整体更换，并对只依赖于硬件SDK的接口驱动进行重新开发即可。通过这种软件架构，把由车载单元生产商负责提供的软件系统分成了“基本不变的部分(应用软件和抽象接口)”和“可变的部分(接口驱动)”两部分，把软件修改的范围压缩到了“可变的部分”那一小部分中，因此，软件研发和测试的工作量变小了，进度快了，质量也更容易控制，从而达到快速适配不同硬件平台的目的。

在一个可选实施例中，当车载单元应用软件的应用业务数量较少时，可按以下方式来增加抽象接口：根据所述应用软件的至少一个应用业务，在车载单元的应用软件和硬件SDK之间增加与每个应用业务一一对应的抽象接口。

在此需说明的是，“应用业务数量较少”没有具体定义，实际应用中，一般认为：应用业务的数量少于或等于5个为较少。例如，对于简化的车载单元，结合图4，应用软件的应用业务包括：ETC交易应用业务11、OBU插卡应用业务12、OBU防拆应用业务13、OBU休眠应用业务14，当然，还可进一步包括OBU生产测试应用业务、OBU蓝牙应用业务和OBU人机应用业务。由于简化的车载单元的应用业务数量较少，所以，可根据应用软件的各个应用业务的需要来声明相应的抽象接口，即，一个应用业务对应一个抽象接口，因此，增加的抽象接口包括：ETC交易抽象接口21、OBU插卡抽象接口22、OBU防拆抽象接口23、OBU休眠抽象接口24。而且，每一个抽象接口都相应定义了一个接口驱动来实现它，因此，增加的接口驱动包括：ETC交易接口驱动31、OBU插卡接口驱动32、OBU防拆接口驱动33、OBU休眠接口驱动34。虽然多个应用业务之间的抽象接口可能有重复，例如，“ETC交易应用业务11”和“OBU插卡应用业务12”都需要实现“LED灯闪烁”的“抽象接口”，但由于应用业务的总体数量少，因此这种重复是可以接受的。在该实施例中，在硬件平台变更时，只需要修改各个“接口驱动”即可，它是一个相对较薄的软件层，修改的工作量较小。

在一个可选实施例中，当车载单元应用软件的应用业务数量较多时，如果抽象接口根据应用业务的需要而声明，则导致各个抽象接口之间的重复过多，此时，可以根据数量相对较少的硬件(芯片)单元划分来声明抽象接口，具体地，可按以下方式来增加抽象接口：根据所述车载单元的至少一个硬件单元，在车载单元的应用软件和硬件SDK之间增加与每个硬件单元一一对应的抽象接口。

在此需说明的是，“应用业务数量较多”也没有具体定义，在实际应用中，一般认为：应用业务数量大于“5个”为较多。例如，在某些车载单元的软件系统中，结合图5，应用软件的应用业务除了包括：ETC交易应用业务11、OBU插卡应用业务12、OBU防拆应用业务13、OBU休眠应用业务14，还可包括：OBU生产测试应用业务15、OBU蓝牙应用业务16和OBU人机应用业务17，其中，OBU生产测试应用业务15用于产品检验，蓝牙应用业务16实现圈存功能。在车载单元设备中，主要的硬件单元包括5.8G ETC芯片、13.56M近场通信芯片、板级支持包(BSP)、蓝牙芯片等，因此，增加的抽象接口包括：5.8G芯片抽象接口25、13.56M芯片抽象接口26、板级支持包抽象接口27、蓝牙芯片抽象接口28。而且，每一个抽象接口都相应定义了一个接口驱动来实现它，因此，所增加的接口驱动包括：5.8G芯片接口驱动35、13.56M芯片接口驱动36、板级支持包接口驱动37、蓝牙芯片接口驱动38。而每个应用业务，根据其业务需要，都可能调用一个或多个抽象接口。在该实施例中，在硬件平台变更时，只需要修改接口驱动即可，它也是一个相对较薄的软件层，修改的工作量较小。

本发明还构造一种车载单元的软件系统，车载单元可包括：双片式OBU、单片式OBU、前装OBU，甚至CPC卡。结合图3所示的车载单元的软件系统，其包括有：应用软件10、抽象接口20、接口驱动30、硬件SDK 40。其中，抽象接口20用于声明与相应应用场景相关的接口；接口驱动30用于根据所述硬件SDK 40定义所述抽象接口，而且，当所述车载单元的硬件平台50变更时，允许根据变更后的硬件平台所对应的硬件SDK 40重新定义所述抽象接口10。应理解，在实际应用中，抽象接口20、接口驱动30的数量可分别为多个，且一一对应。

在一个可选实施例中，抽象接口20具体用于声明所述应用软件10的相应应用业务的接口。具体地，结合图4，对于简化的车载单元，应用软件的应用业务包括：ETC交易应用业务11、OBU插卡应用业务12、OBU防拆应用业务13、OBU休眠应用业务14，当然，对于其它的车载单元，应用业务还可包括OBU生产测试应用业务、OBU蓝牙应用业务、OBU人机交互应用业务等。当车载单元的应用业务数量较少时，可根据应用软件的各个应用业务的需要来声明相应的抽象接口，即，一个应用业务对应一个抽象接口，因此，增加的抽象接口包括：ETC交易抽象接口21、OBU插卡抽象接口22、OBU防拆抽象接口23、OBU休眠抽象接口24。而且，每一个抽象接口都相应定义了一个接口驱动来实现它，因此，增加的接口驱动包括：ETC交易接口驱动31、OBU插卡接口驱动32、OBU防拆接口驱动33、OBU休眠接口驱动34。虽然多个应用业务之间的抽象接口可能有重复，例如，“ETC交易应用业务11”和“OBU插卡应用业务12”都需要实现“LED灯闪烁”的“抽象接口”，但由于应用业务的总体数量少，因此这种重复是可以接受的。在该实施例中，在硬件平台变更时，只需要修改各个“接口驱动”即可，它是一个相对较薄的软件层，修改的工作量较小。

在一个可选实施例中，抽象接口20具体用于声明所述车载单元的至少一个硬件单元的接口。结合图5，在某些车载单元的软件系统中，应用软件的应用业务除了包括：ETC交易应用业务11、OBU插卡应用业务12、OBU防拆应用业务13、OBU休眠应用业务14，还可包括：OBU生产测试应用业务15、OBU蓝牙应用业务16和OBU人机应用业务17。当车载单元应用软件的应用业务数量较多时，如果抽象接口根据应用业务的需要而声明，则导致各个抽象接口之间的重复过多，此时，可以根据数量相对较少的硬件(芯片)单元划分来声明抽象接口。在车载单元设备中，主要的硬件单元包括5.8G ETC芯片、13.56M近场通信芯片、板级支持包(BSP)、蓝牙芯片等，因此，增加的抽象接口包括：5.8G芯片抽象接口25、13.56M芯片抽象接口26、板级支持包抽象接口27、蓝牙芯片抽象接口28。而且，每一个抽象接口都相应定义了一个接口驱动来实现它，因此，所增加的接口驱动包括：5.8G芯片接口驱动35、13.56M芯片接口驱动36、板级支持包接口驱动37、蓝牙芯片接口驱动38。而每个应用业务，根据其业务需要，都可能调用一个或多个抽象接口。在该实施例中，在硬件平台变更时，只需要修改接口驱动即可，它也是一个相对较薄的软件层，修改的工作量较小。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何纂改、等同替换、改进等，均应包含在本发明的权利要求范围之内。

Claims

1.一种车载单元的软件架构设计方法，其特征在于，包括：

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

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

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

5.根据权利要求4所述的车载单元的软件架构设计方法，其特征在于，所述车载单元的硬件单元包括下列中的至少一个：5.8G ETC芯片、13.56M近场通信芯片、板级支持包、蓝牙芯片。

6.一种车载单元的软件系统，包括应用软件和硬件SDK，其特征在于，还包括：设置在所述应用软件和所述硬件SDK之间的至少一个抽象接口及至少一个接口驱动，其中，

所述抽象接口，用于声明与相应应用场景相关的接口；

7.根据权利要求6所述的车载单元的软件系统，其特征在于，所述抽象接口，具体用于声明所述应用软件的相应应用业务的接口。

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

9.根据权利要求6所述的车载单元的软件系统，其特征在于，所述抽象接口，具体用于声明所述车载单元的至少一个硬件单元的接口。

10.根据权利要求9所述的车载单元的软件系统，其特征在于，所述车载单元的硬件单元包括下列中的至少一个：5.8G ETC芯片、13.56M近场通信芯片、板级支持包、蓝牙芯片。