[发明专利]基于AUTOSAR标准的ECU参数配置界面生成方法

说明书

技术领域

本发明涉及一种基于AUTOSAR标准的ECU参数配置界面生成方法。

技术背景

AUTOSAR(AUTomotive Open System Architecture)是一个标准化的开放式汽车软件架构。本发明所参照的AUTOSAR标准为3.0.1版本。

ECU配置是AUTOSAR系统开发流程中重要的一个环节，AUTOSAR标准提供了一个名为AUTOSAR EcucParamDef.arxml的文件，详细地定义了ECU配置参数项。ECU配置工具根据这些参数的定义，提供对应的配置界面，由用户在界面上进行相关ECU参数的配置，配置信息通过xml文件再提供给后续的可执行代码生成阶段，生成相应的C代码。

ECU参数定义结构见图1，各数据项的隶属关系呈树状结构，树中的子节点为父节点的数据成员。ECU参数定义中顶层为包，下一层是模块，如Os，Rte，Com等。模块下一层是容器，容器包含了基本数据类型和子容器，容器定义是可以嵌套的。以Os模块定义为例，它包含了OsAlarm，OsApplication，OsAppMode，OsCounter，OsEvent，OsIsr，OsOs，OsResource，OschduleTable，OsTask等10个容器的定义。这10个容器定义又可以展开，如OsCounter容器的定义，它包含OsCounterMaxAllower，OsCounterMinCycle，OsCounterTicksPerBase等6项基本类型和OsDriver，OsTimeConstant两个子容器。

AUTOSAR标准对于ECU参数的详细定义，大大方便了配置信息的表示和处理，在开发ECU配置工具的时候，可以根据其参数定义生成工具的参数配置界面。但是，AUTOSAR标准中要配置的ECU参数量很大，包括了50个模块，449个容器和1465个基本类型的数据项，至少要生成200个以上的配置界面和3000个以上的界面控件才能完成配置工作。如果采用传统的方法用手工写这些配置界面代码的话，其弊端是显而易见的：

1.开发效率低，几百个界面和数以千计的控件生成需要大量的时间去完成。

2.可扩展性差，如果添加了新配置项或配置项修改了，原代码就无法正常运行，要重写。

3.可维护性差，界面代码有bug或需要改进，往往要把所有的界面都要修改一遍。

4.手工代码往往有差异，界面风格不容易统一，给用户操作带来不便，视觉效果也受影响。

发明内容

为克服现有技术的开发效率低，可扩展性差，可维护性差，用户操作不便的缺点，本发明提供了一种开发效率高，可扩展性好，可维护性好，用户操作方便的基于AUTOSAR标准的ECU参数配置界面生成方法。

基于AUTOSAR标准的ECU参数配置界面生成方法，包括以下步骤：

1)、生成与AUTOSAR标准中的ECU配置参数项一一对应的类模型，设置界面控件属性，使界面控件与类模型一一对应；

2)、生成界面时，获取当前的配置参数项，确定与当前的配置参数项对应的类模型；解析所述的类模型，获取类模型信息；

3)、根据类模型信息，生成相应的界面控件。

进一步，步骤1)中，生成类模型和界面控件包括以下步骤：

1.1)、建立与AUTOSAR标准中的ECU非基本数据类型的参数类别一一对应、能通过解析各ECU配置参数项生成与所述的配置参数项对应的类模型的生成模块；

1.2)、读取AUTOSAR的ECU参数定义文件，通过生成模块解析各ECU配置参数项、生成对应的类模型，所述的类模型作为配置工具源代码的一部分被编译入配置工具中；所述的类模型将与其对应的参数项的属性、所述的参数项的数据成员和所述的数据成员的属性信息作为类模型信息，所述的类模型信息与界面控件对应。

进一步，步骤1.2)中，生成类模型包括以下步骤：

1.2.1)、每个参数项均对应生成一个类模型，类模型名称为对应参数项的SHORT-NAME属性，参数项的数据成员作为该类模型的模型成员；

1.2.2)、分别标明类模型的类型和属性；

1.2.3)、判断数据成员类型是否基本数据类型：若数据成员类型是引用型的基本数据类型，或者UPPER_MULTIPLICITY＞1或者，MULTIPLE_CONFIGURATION_CONTAINER为true时，则用List＜成员类型＞来表示对应的模型成员的类型；

若数据成员类型为Module，则用其定义中的SHORT-NAME属性来表示模型成员的类型；