CN101901148A - 基于autosar标准的ecu参数配置界面生成方法 - Google Patents

Abstract

基于AUTOSAR标准的ECU参数配置界面生成方法，包括以下步骤：生成与AUTOSAR标准中的ECU配置参数项一一对应的类模型，设置界面控件属性，使界面控件与类模型一一对应；生成界面时，获取当前的配置参数项，确定与当前的配置参数项对应的类模型；解析所述的类模型，获取类模型信息；根据类模型信息，生成相应的界面控件。本发明具有开发效率高，可扩展性好，可维护性好，用户操作方便的优点。

Description

基于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属性来表示模型成员的类型；

若数据成员类型为Container的，则判断该Container是否CHOICECONTAINERDEF、且子容器是多选一；若是，则在生成的类模型添中加一个整型的数据成员index，表示配置的时候选择了哪个子容器；若否，则用其SHORT-NAME属性来表示模型成员的类型；

1.2.4)，若数据成员类型不是基本数据类型，则调用与数据成员对应的类模型。

本发明的技术构思是：生成模块的类别与AUTOSAR标准中的ECU非基本数据类型的参数类别一一对应，每一种类的生成模块负责生成与之对应类别的参数项的类模型。如在AUTOSAR 3.0.1标准中，参数项在层次关系上分为3种(不包括基本数据类型)，从上到下分别是：Package，Module和Container。生成模块也相应地也分为3种：Package生成模块，Module生成模块和Container生成模块。

通过解析获取配置参数项所对应的类模型，再解析出其类模型信息，最后根据类模型信息调用相应的界面控件生成器，生成参数配置界面。

本发明根据AUTOSAR标准种的ECU参数定义的类别来分类和设计界面控件，界面控件的生成方式与数据类型对应。

本发明有以下优点：

1.开发效率高，不管有多少个配置界面，只需写一遍代码。

2.可扩展性好，如果添加了新配置参数项或修改了现有配置参数项，只需把该类模型重新生成一遍即可，无需重新编写代码。

3.可维护性好，界面代码有bug或需要改进，只要统一改几处代码即可，而不像手工生成方法，每个界面都要去改。

4.由于界面是用同一方法自动生成，容易做到风格一致，便于用户操作。

5、用类模型保存参数定义，类模型被编译入配置工具，无需在参数配置过程中读取参数定义文件，提高了配置工具的运行速度。

附图说明

图1ECU参数定义结构图

图2ECU配置工具系统结构图

图3生成Package类模型的流程图

图4生成Module类模型流程图

图5生成Container类模型流程图

图6生成界面控件基类的流程图

图7生成Parameter控件的流程图

图8生成Container控件的流程图

图9生成Module控件的流程图

图10生成SubContainer控件流程图

图11生成ChoiceContainer控件的流程图

图12生成Reference控件流程图

图13ECU参数配置界面截图

具体实施方式

参照附图，进一步说明本发明：

基于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属性来表示模型成员的类型；

若数据成员类型为Container的，则判断该Container是否CHOICECONTAINERDEF、且子容器是多选一；若是，则在生成的类模型添中加一个整型的数据成员index，表示配置的时候选择了哪个子容器；若否，则用其SHORT-NAME属性来表示模型成员的类型；

1.2.4)，若数据成员类型不是基本数据类型，则调用与数据成员对应的类模型。

本发明的技术构思是：生成模块的类别与AUTOSAR标准中的ECU非基本数据类型的参数类别一一对应，每一种类的生成模块负责生成与之对应类别的参数项的类模型。如在AUTOSAR 3.0.1标准中，参数项在层次关系上分为3种(不包括基本数据类型)，从上到下分别是：Package，Module和Container。生成模块也相应地也分为3种：Package生成模块，Module生成模块和Container生成模块。

通过解析获取配置参数项所对应的类模型，再解析出其类模型信息，最后根据类模型信息调用相应的界面控件生成器，生成参数配置界面。

本发明根据AUTOSAR标准种的ECU参数定义的类别来分类和设计界面控件，界面控件的生成方式与数据类型对应。

本发明采用Java语言编写，一个类模型就是一个Java类，通过Java语言的反射机制确定当前配置参数项所对应的类模型，运用Java语言的注释机制解析类模型信息。

AUTOSAR 3.0.1的ECU参数非基本数据类型包括Package(包)，Module(模块)，Container(容器)，需转换成对应的类模型；基本数据类型则转换成相应Java语言基本数据类型如整型，浮点型，布尔型等。Package和Module的定义只有一种，Container的定义有两种PARAMCONFCONTAINERDEF和CHOICECONTAINERDEF，基本数据类型的定义分为两类共17种具体的数据类型：

第一类为一般的基本数据类型定义：

INTEGERPARAMDEF

DERIVEDINTEGERPARAMDEF

ENUMERATIONPARAMDEF

DERIVEDENUMERATIONPARAMDEF

FLOATPARAMDEF，DERIVEDFLOATPARAMDEF

BOOLEANPARAMDEF

DERIVEDBOOLEANPARAMDEF

FUNCTIONNAMEDEF

STRINGPARAMDEF

DERIVEDSTRINGPARAMDEF

LINKERSYMBOLDEF

，共12种。

第二类为引用型的基本数据类型定义，包括：

REFERENCEPARAMDEF

CHOICEREFERENCEPARAMDEF

INSTANCEREFERENCEPARAMDEF

FOREIGNREFERENCEPARAMDEF

SYMBOLICNAMEREFERENCEPARAMDEF

，共5种。

图7是对一个Boolean参数生成控件的流程。创建Boolean控件先进行初始化Boolean控件参数，初始化失败则直接退出。成功则开始创建Boolean控件。创建一个label用来显示参数名，创建一个表示Button按钮，用来标识Boolean控件，创建一个default按钮，用来恢复标记Button按钮为默认值。为标记Button按钮创建监听事件，当标记Button按钮被选中时，表示Boolean值为true；未选中时，表示Boolean值为false，同时进行相应的参数赋值处理。其他基本数据类型控件生成过程类似。

图8是生成Container控件的过程：首先是Container控件的初始化。初始化失败，则退出。初始化成功则进入具体的Container控件的创建。在AUTOSAR的ECU配置参数定义文件中，对于一个Module内部的某个Container的个数上限定义为1或大于1。因此，具体Container控件在创建的时候需要考虑到该Container的上限。在这里我们进行了不同处理：当上限为1的时候，先创建一个CTabItem，然后创建一个composite容器，最后返回该composite容器。Composite容器用于显示Container内部的参数定义、SubContainer和引用定义等。当Container的上限大于1时，先创建一个CTabItem，然后创建一个composite，用于整体布局，创建一个ViewForm，用于内部布局。创建一个label用于显示该Container的名字，创建一个TableViewer，通过该TableViewer可以创建多个该Container的实例。

图9是生成Module控件的过程：首先要初始化Module控件信息，若初始化失败，则直接退出。初始化成功则进入下一步。然后获取FormToolkit，通过FormToolkit取得form，从form取得一个容器。然后就是对容器进行布局，插入分隔符，创建两个label。最后是创建一个CTabFolder，并把创建的CTabFolder返回。CTabFolder主要用于包含Module的若干个Container。

图10是生成SubContainer子容器界面控件的过程。子容器和容器是相对而言的，当一个容器以其他容器的子成员出现在界面上时，它表现为子容器。其流程与Container控件生成相似，不同的是：当其个数上限为1时，不创建CTabItem，而是创建Section，然后创建composite容器，并调用基类检查该SubContainer的个数下限是否为0，最后解析SubContainer的元素并显示在该composite容器中。当个数上限大于1的时候，创建CTabItem、创建composite、创建TableViewer，然后TableViewer相应的内容器、标签器、修改器和ActionGroup对象，由于SubContainer就是一个Container，因此SubContainer的内容器、标签器、修改器和ActionGroup可以直接复用Container的，这里就不在重复介绍。最后SubContainer需要创建HyperLink控件，因为SubContainer是作为Container的内部元素出现的，为了显示出Container和SubContainer的嵌套关系，故需要在Container内部把SubContainer作为元素标记出来。通过点击该元素可以Link到该SubContainer的CTabItem显示该SubContainer的配置界面。

图11是生成ChoiceContainer控件的过程，ChoiceContainer是一种选择性的Container，即需要对Container的类型进行选择。ChoiceContainer控件生成过程与SubContainer控件的不同之处在于，需要额外创建一个Combo控件来进行容器类型的选择。

图12是生成Reference控件的过程：其与生成ChoiceContainer控件的不同之处在于：Reference配置不需要编辑按钮，因为只是对其他Container的引用。

图13是完成的配置界面截图。如需测试该界面是否正常，只需在Os模块中添加一个任务，使该任务能被每秒一次的周期执行。把配置好的结果输入到Os配置代码生成工具，输出os_cfg.h，app_cfg.h，app_cfg.c三个C代码文件。在app_cfg.c文件中添加使HCS12板块1号LED灯亮灭交替变换的代码。把SmartOSEK OS 3.5的内核代码和这三个C代码文件导入CodeWarrior 3.1进行编译并烧写入HCS12板，运行后1号LED灯每隔1秒钟由亮变灭或由灭变亮，则认为界面控件正常。

本说明书实施例所述的内容仅仅是对发明构思的实现形式的列举，本发明的保护范围不应当被视为仅限于实施例所陈述的具体形式，本发明的保护范围也及于本领域技术人员根据本发明构思所能够想到的等同技术手段。

Claims (3)

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

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

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

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

2.如权利要求1所述的基于AUTOSAR标准的ECU参数配置界面生成方法，其特征在于：步骤1)中，生成类模型和界面控件包括以下步骤：

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

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

3.如权利要求2所述的基于AUTOSAR标准的ECU参数配置界面生成方法，其特征在于：步骤1)中，生成类模型包括以下步骤：

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

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

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

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

若数据成员类型为Container的，则判断该Container是否CHOICECONTAINERDEF、且子容器是多选一；若是，则在生成的类模型添中加一个整型的数据成员index，表示配置的时候选择了哪个子容器；若否，则用其SHORT-NAME属性来表示模型成员的类型；

2.4)，若数据成员类型不是基本数据类型，则调用与数据成员对应的类模型。

Images