DIY编程器网

标题: OSEK/VDX直接网络管理一致测试方法设计 [打印本页]

---

作者: admin    时间: 2015-4-27 19:57
标题: OSEK/VDX直接网络管理一致测试方法设计
随着近年汽车产业的快速发展，电子产品广泛应用于汽车控制，如发动机控制系统、转向系统、制动系统等装置中都采用电子控制单元ECU(Electronic Control Unit)[1]。一些高档的轿车大约有70个ECU，ECU之间传递的信息超过2500条[2]。为了使ECU之间实现信息共享，诞生了在汽车控制系统中应用的互联网络，即车载网络。随着汽车中电子单元的增加，网络越来越复杂，ECU在通信时，可能由于其他节点未上线或出现故障而造成信息丢失，所以需要专门的网络管理组件对车载网络进行管理，以达到车载网络信息传输准确性、安全性的目的。

OSEK/VDX (Open Systems and the Corresponding Interfaces for Automotive Electronics/Vehicle Distributed eXecutive) 是欧洲主要的汽车厂商和研究机构联合提出的一种基于汽车电子开放式系统及其接口的软件标准。鉴于汽车网络的安全性和可靠性，OSEK/VDX中的网络管理NM(Network Management)规范提供了标准的管理策略，通过接口和服务来实现汽车网络中ECU节点的监控和管理[3]。OSEK/VDX规范对网络管理提出直接网络管理和间接网络管理两种实现机制。

OSEK/VDX规范是通过自然语言和图表形式进行描述的，程序开发人员在根据规范编写应用程序时，可能因为对规范的不同理解、编写代码时的失误等原因，导致应用程序与规范的不一致。对于安全性有极高要求的汽车电子系统而言，这种现象是不允许的。因此，有必要通过一致性测试来判断开发的应用程序是否符合预定规范。近年来，学术界对OSEK OS（OSEK Operation System）的一致性测试方法提出了一些解决方案。参考文献[4]提出了一种OSEK OS服务调用规范的一致性测试方法，参考文献[5]设计了一种OSEK OS一致性测试用例生成的方法，但是很少对OSEK NM的一致性测试做相应研究。

本文在深入研究OSEK网络管理规范的基础上提出了一种OSEK NM一致性测试方法，设计出一种基于直接网络管理功能的测试架构，并定义了测试方案、测试报文的数据结构和测试流程。

1 OSEK直接网络管理基本原理

在OSEK NM规范中，直接网络管理是一种自组织形式网络管理。网络中节点之间没有主从之分，每个节点都被网络中其他的节点监控，同时该节点也监控网络中的其他节点。直接网络管理通过逻辑环对车载网络进行管理与监控，如图1所示为直接网络管理逻辑环的体系结构。连接在总线上的A、B、C 3个节点都拥有自己唯一的网络管理身份标识ID,且IDA<IDB<IDC，根据ID的大小，以A→B→C→A的顺序传输特定的网络管理报文，形成一个虚拟逻辑环。在逻辑环中连接的所有节点按照逻辑环规定的方向发送特定的网络管理报文，实现直接网络管理功能。

图2所示为直接网络管理的状态模型。通过网络管理服务的调用和网络通信状况的改变，引起网络管理状态的迁移，如调用StartNM()服务可启动网络管理功能，使节点的状态从NMOff转为NMOn。

在直接网络管理中，为了满足通信和网络管理的需要，网络管理协议数据单元NMPDU(NM Protocol Data Unit)包括地址域、控制域和数据域。图3是网络管理协议数据单元的基本格式。其中，Source ID表示网络管理报文的源地址，即发送该网络管理报文的节点地址；

Destination ID表示网络管理报文的目标地址，即接收该网络管理报文的节点地址；Option Code表示操作码，用来设置网络管理报文的类型,其有Ring、Alive、LimpHome三种。    Data表示数据场，用于定义网络管理报文中的附加信息。
直接网络管理中各类型报文的作用：

(1)Ring报文：一个基本的监视报文，当网络状态为正常状态时，网络节点在定时器的触发下，根据节点ID的大小顺序地传送Ring报文。

(2)Alive报文：一个在非正常状态下的特殊报文，当一个新的节点要加入网络时，节点向网络中发送Alive报文。

(3)LimpHome报文：当接收/发送错误计数器超过其阈值或总线出现严重错误时，节点进入NMLimpHome状态，并周期地发送LimpHome报文。

2 OSEK NM的一致性测试方法

OSEK NM的一致性测试是一种功能性测试，在一致性测试中，测试者不必关心被测IUT（Implementation Under Test）内部的具体实现，只需关心其表现出来的外部行为[6-7]。

2.1 测试的体系结构

根据OSEK NM规范，将网络管理的测试体系结构分为两个部分，即被测系统及测试系统。

(1)被测系统，是IUT的载体，在测试系统中实现网络管理功能。

(2)测试系统，用来执行测试案例程序，该设备通过网络跟被测设备相互通信。

整个网络管理测试方案分为两个子块，即测试管理模块和辅助测试模块。测试管理模块由测试案例组成，在测试系统中运行；辅助测试模块作为被测系统的应用程序在被测设备中运行，用来配合测试管理模块完成网络管理功能的测试。在网络管理功能测试中，辅助测试模块起到两方面的作用，一方面用来响应测试系统的发来的请求，另一方面作为被测系统的应用程序，通过调用NM API函数，控制IUT的运行模式，并收集被测系统中IUT当前的状态信息，返回给测试系统。

测试管理模块和辅助测试模块之间的数据信息交换通过应用报文完成，该报文为测试管理协议数据单元（TM_PDU）。该方式下，2个测试模块之间的通信独立于底层网络管理通信协议，不影响网络管理功能。

在OSEK 直接网络管理中，网络出错处理机制是很重要的一部分。根据OSEK NM规范，OSEK NM可以处理一些常见的网络错误，如通信超时、BusOff等，所以本文在网络管理功能测试系统中增加了模拟和制造网络错误的模块。

综上所述，在直接网络管理的测试架构中，测试系统必须具备以下功能：

(1)测试系统必须具备网络管理功能，发送网络管理报文,并能模拟一个或多个网络管理节点的网络关系行为。

(2)测试系统能接受并分析NMPDU，判断被测系统中的IUT是否符合网络管理规范，即带有OSEK 直接网络管理功能。

(3)测试系统能够通过测试设备中一种特定的测试软件编程来控制相应的硬件设备，使总线出现特定的网络故障(如Vector公司的CAN总线干扰仪CANstress)。

2.2 测试方案和测试管理报文的定义

在直接网络管理模块正常工作时，ECU应用程序通过调用NM API接口函数来控制OSEK NM的相关动作，如功能开启、关闭及睡眠等。而在直接网络管理的测试过程中，整个测试系统必须能够模拟这一过程。为了实现这一功能，在测试系统与被测系统之间有两种类型的报文，即直接网络管理报文和测试管理报文。测试管理报文是测试管理模块和辅助测试模块之间的数据通道，使测试管理模块能够间接控制IUT，从而实现测试功能。图4所示为测试管理模块和辅助测试模块之间的两种通信模式。

测试系统用图4(a)所示的通信模式获取被测系统中NM模块当前的状态以及配置信息，用图4(b)所示的通信模式控制辅助测试模块调用NM服务函数，图中虚线箭头表示根据需求服务的返回值可以选择性的传回测试系统。
  
  
测试管理报文的格式有apiCall和apiStatus两种：

(1)apiCall：用来请求辅助测试模块调用NM API，控制OSEK NM实现特定的动作。报文名定义形式为CallXXX（其中“XXX”表示NM API名称，如：StartNM）；
(2)apiStatus：将调用NM API函数的返回值和当前NM的状态信息返回给测试系统，相应的报文有APIStatus，NetStatusMsg等。

测试管理报文两种格式的数据单元映射到CAN报文的数据帧上,如表1所示。其中，报文名编号为不同功能测试管理报文的编号;服务编号为NM API编号，用以标识该报文是控制某个API的调用或对某个API的响应;目的ID为标识该测试管理报文要发送到的目标网络管理节点；报文数据单元为apiStatus报文专有数据单元，用来存储API函数调用的返回值或当前网络管理单元的配置和状态信息。


2.3 测试的流程

OSEK NM测试可分为以下步骤：
(1)根据OSEK NM规范，抽象出需要测试的内容。如从NMNormal→NMBusSleep转换过程中,网络管理内部状态的变化。
(2)根据测试内容和测试方法，将直接网络管理功能分为一个或多个功能模块，针对各个功能模块设计相应的测试用例。
(3)在测试系统中执行测试用例，并记录执行过程中测试系统获取的网络管理状态数据。
(4)将测试结果数据与OSEK NM管理协议做对比，分析被测功能模块是否与协议一致，并分析不一致的可能原因。

3 测试方法验证

3.1 测试用例设计

本文以网络管理状态从NMNormal转向NMBusSleep为例进行测试。测试用例分为三个部分，即初始状态、测试步骤和期望结果。下面给出测试用例的详细内容：

(1)初始状态

①操作模式为主动模式（NMActive）;
②本地NM设置networkstatus.bussleep=0;
③网络管理状态为NMNormal;
④测试系统状态与被测节点一致，在整个网络中已建立逻辑环，并正常工作。

(2)测试步骤

①测试设备发送CallGotoMode(Sleep)报文；
②当接收接下来IUT发来的第一条报文后使测试系统中其他的虚拟节点调用GotoMode(Sleep)服务；
③当接收到IUT发来的第二条报文后，测试设备发送CallGetStatus报文，等待NetStatusMsg报文的响应，读取被测节点中IUT当前的状态；
④等待TwaitBusSleep时间段后，再次发送CallGetStatus报文，等待NetStatusMsg报文的响应，读取被测节点中IUT当前的状态。

(3)期望结果

①IUT发送的第一条网络管理报文中，sleep.ind位被置位；
②IUT发送的第二条网络管理报文中，sleep.ack位被置位，且当前IUT的网络状态为NMTwbsNormal；
③接收到sleep.ack=1的报文TwaitBusSleep后节点进入NMBusSleep状态；
④整个运行过程中，IUT都处于NMActive状态。

3.2 测试平台搭建与测试

测试设备由装有CANoe软件的PC机、CANcaseXL和CANstress组成。CANoe是由Vector公司开发的网络分析、设计和测试的专用工具，支持多种总线系统。CANcaseXL为Vector提供的新一代CAN和LIN的USB 2.0接口卡，与CANoe软件组合使用。CANstress是CAN总线干扰仪，它可以直接串连到CAN网络中，实现各种触发条件与逻辑的干扰。被测设备为带有OSEK NM功能的汽车仪表，外接12 V直流电源为汽车仪表供电。

基于上述测试平台进行网络管理功能测试。首先在CANoe软件平台上实现3个CAN节点，并用CAPL语言对每个节点编程，实现基于OSEK 规范的直接网络管理功能，在其中一个节点中添加测试管理功能模块，运行测试用例，实现总体测试管理控制。汽车仪表ECU软件中添加辅助测试程序模块，作为仪表的应用软件。最后，根据预先设计好的测试用例对NMNormal到NMBusSleep的状态转换进行一致性测试，并记录测试结果。

3.3 测试结果

图5所示为直接网络管理测试在CANoe的Trace窗口上的显示结果。图中对报文和数据的含义做了相应的说明。在测试系统的控制下，整个网络进入睡眠状态，并根据测试案例成功读取到直接网络管理的状态信息。

通过对Trace窗口中的数据进行分析可见,测试结果跟测试案例中的预期结果一致，这说明仪表节点中直接网络管理睡眠流程符合OSEK NM规范。同时也验证了该测试方法的正确性。
  
本文提出了一种基于OSEK NM管理的一致性测试方法，并详细叙述了测试系统的体系结构、测试方案、测试管理报文的定义，以及测试流程。最后通过对仪表节点的直接网络管理睡眠过程的测试，说明了该方法的有效性。通过对基于OSEK规范的直接网络管理的测试，能够发现OSEK NM在正常工作中很难出现的错误，并能有效地验证OSEK NM的正确性,对提高基于OSEK规范的直接网络管理可靠性和稳定性有重要的作用。

---

欢迎光临 DIY编程器网 (http://diybcq.com/)

Powered by Discuz! X3.2