基于AUTOSAR标准的网络管理栈-SmartSAR_NM的设计与实现_第1页
基于AUTOSAR标准的网络管理栈-SmartSAR_NM的设计与实现_第2页
基于AUTOSAR标准的网络管理栈-SmartSAR_NM的设计与实现_第3页
基于AUTOSAR标准的网络管理栈-SmartSAR_NM的设计与实现_第4页
基于AUTOSAR标准的网络管理栈-SmartSAR_NM的设计与实现_第5页
已阅读5页,还剩42页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

浙江大学硕士学位论文删减版 基于AUTOSAR标准的网络管理栈SmartSAR NM的设计 与实现 (删减版) 浙江大学 ESE 工程中心 周霖 support 密级: 硕 士 学 位 论 文 论文题目 基于 AUTOSAR 标准的网络管理栈 SmartSAR NM 的设计与实现 作者姓名 周霖 指导教师 姚敏 教授 杨国青 博士 学科(专业) 计算机应用技术 所在学院 计算机学院 A Dissertation Submitted to Zhejiang University for the Degree of Master of Engineering TITLE: Design 其次,又深入了解了车载网络常见结构。最后,在理解了车载总线的特点及布线 需求之后,本文又深入介绍了两个车载网络管理标准,OSEK NM 和 AUTOSAR NM, 同时还介绍了这两个网络管理标准所推荐的管理策略。 浙江大学硕士学位论文 第 3 章 网络管理栈总体设计 18 第第3 3章章 网络管理栈网络管理栈总体总体设计设计 汽车上的功能部件往往由对应的软件组件进行功能控制,不同的功能控制模 块(通常也称为软件组件)往往是由不同的供应商提供。由于成本以及车身空间 的限制,在实际设计整车网络时,多个独立的软件组件将会被安置到同一个 ECU 上, 共享一套硬件资源。 这些软件组件的独立执行是通过任务切换的方式共享 ECU 的计算资源来达到的;而这些软件组件的独立通信,则通过复用通信端口来实现 的。 在软件组件开发的过程中,软件组件开发者不知道该软件组件能使用到多少 网络资源,只会指定使用一个或多个抽象的软件信道进行通信,然后通过提供配 置接口,让整车厂在整车开发时,将这些抽象的软件信道映射到实际的通信控制 器和收发器之上。所以,从每一个软件组件的编程观点来说,它能够完全占有一 个通信信道,而不需要关心其它软件组件对信道的使用情况。 软件组件对与信道的使用有两个方面的内容,一个是信息的发送和接收,另 一个便是信道资源的申请与释放。信息的发送和接收,是通过通信栈的抽象来实 现的,如图 3.1 子图 A 所示。其中通信栈接收各个 SWC 发送的消息,利用队列将 这些信息串行化,再通过同一套控制器和收发器发送出去;接收的时候也根据所 接收到的帧的头部信息,通过相应的信道映射,提交到不同的 SWC 中。信道资源 的申请与释放, 则是通过网络管理栈的协调功能来完成的,如图 3.1 子图 B 所示。 其中 SWC1 和 SWC3 都申请使用该信道,而 SWC2 却释放了该信道,为了保证整个 ECU 上的 SWC 都能正常工作,最终网络管理栈将确定开启网络控制器和收发器作 为该信道硬件的实际操作。通过通信栈和网络管理栈对底层通信部件的抽象和管 理,简化了 SWC 开发过程中对通信部分功能的设计复杂度。 浙江大学硕士学位论文 第 3 章 网络管理栈总体设计 19 SWC1SWC2SWC3 Msg1 控制器和收发器 信道3信道2 Msg2Msg3 SWC1SWC2SWC3 信道1 控制器和收发器 信道3信道2 RequestRequestRelease A)通信栈提供的多SWC使用机制B)网络管理栈提供的多SWC使用机制 Request 信道1 使 用 者 通 信 栈 网 络 管 理 栈 使 用 者 总 线 总 线 图 3.1 通信栈与网络管理栈提供的多 SWC 信道复用与管理 总的来说,网络管理栈是通信栈的一个重要组成部分,它和通信栈的联系非 常紧密。网络管理栈有自己的通信机制和对应的网络管理帧,这些管理帧是直接 通过通信栈的接口进行发送和接收的,而且这些管理帧是和 SWC 所发送的数据帧 共享信道的,夹杂在其它的通信数据一起发送。网络管理栈还需要协调不同 SWC 对于通信信道的申请和释放操作,通过其内置的协调算法操作通信栈的接口,设 置通信寄存器和收发器的实际工作状态;对于某些由整车厂开发的特权级 SWC, 通信管理栈更是需要提供给其网络信道通信管理的功能,例如禁止某个通信信道 的发送功能,整个 ECU 停止网络通信等等,这些功能也是需要通过调用通信栈提 供的接口来完成相应的控制。 本章从数据流和控制流的观点来进行整个网络管理栈的功能划分与模块设 计,如图 3.2 所示。其中的通信管理层(图 3.2 中的 ComM 层) ,主要职责就是协 调不同使用者对通信资源的申请与释放,以及简化用户对系统资源的申请与释放。 其中的网络管理适配层(图 3.2 中的 Generic Network Management Interface 层) ,为上层模块屏蔽了底层的与总线相关的管理细节,并提供了统一的调用接 口。其中的与总线相关的网络管理层(图 3.2 中的 CanNm 和 FrNm 层,分别对应 于 Can 总线和 FlexRay 总线) ,主要负责维护对应的网络状态的逻辑管理以及对 浙江大学硕士学位论文 第 3 章 网络管理栈总体设计 20 应状态下网络管理帧的发送。由于这部分网络管理功能与底层总线相关,所以, 对于不同的总线,都需要开发相应的网络管理模块,集成进整个通信管理栈,在 本文的实现中, 该模块的实现是基于 Can 总线的。 图中的总线状态管理层 (图 3.2 中的 State management 层),也是和总线相关的一个模块,对应于不同的网络管 理模块,例如 CanSm 对应于 CanNm,FrNm 对应于 FrSm 等等。总线状态管理的主 要操作是和网络管理模块的网络逻辑状态相对应的,例如某个网络管理模块管理 下的通信信道转换状态时,会将这个状态变化通知给 ComM 层,再由 ComM 层调用 对应的总线管理接口,将该信道对应的硬件设备设置为合适的工作模式。图中的 特权级使用者(图 3.2 中的 Privilege SWC),实际上是由各个整车厂自己开发的 网络管理SWC (通常预先在该SWC中存储了不同工作情况下期望的正常网络状况, 这样在汽车运行过程中通过实际数据的比对,就可以判断是否有故障节点产生) , 由于是整车厂开发的软件组件,所以在开发的过程中是可以知道整个底层网络拓 扑结构和实际 ECU 使用情况,因此可以对具体的信道直接进行通信管理。同时, 在这个 SWC 中,可以通过调用相应的网络管理栈接口对网络管理帧添加额外的状 态信息,根据不同的应用需求扩展合适的网络管理算法。 Privilege SWC (e.g. Vechicle Mode Manager) SWCSWC ComM Generic NM Interface CanSM/FrSM Network Handle Network Handle User Identifier User Identifier Service Layer ECU Abstraction Layer Microcontroller Abstraction Layer Communication Stack Send/Receive NM Messages Comtrols Communication Stacks CAN NMFR NM 图 3.2 网络管理栈结构 浙江大学硕士学位论文 第 3 章 网络管理栈总体设计 21 在本章剩余部分,我们依次描述了网络管理栈各个模块的功能需求和设计方 案,包括:通信管理模块 ComM,网络适配层模块 Nm,基于 Can 总线的网络管理模 块 CanNm 以及基于 Can 的总线状态管理模块 CanSm。 (此处省略) 浙江大学硕士学位论文 第 4 章 网络管理栈的实现 22 第第4 4章章 网络网络管理管理栈的实现栈的实现 本章根据第三章网络管理栈的总体设计方案,详细地描述了各个模块的具体 实现方法。 (此处省略) 浙江大学硕士学位论文 第 5 章 车身网络中的应用 23 第第5 5章章 车身网络中的车身网络中的应用应用 在对各个模块进行过完整的功能测试,自动机的规格测试 35之后,本章通过 将网络管理栈集成入车门控制网络,同时通过设计相应的场景来验证网络管理栈 最核心的功能。 5.1 网络管理应用环境 5.1.1 车门网络结构设计 在本文 2.2.2 节中已经介绍过,目前车身网络的组网方式,通常是根据各个 部件的逻辑功能和速度要求,划分为功能相对独立的二级网络,这些网络之间则 是通过处理功能强大的网关来实现。为了验证网络管理栈对网络内节点的同步功 能,我们只从图 2.7 中抽出门控节点网络,其拓扑结构如图 5.1 所示。 中 控 E C U 右前门ECU 右后视镜玻璃升降器门锁 LIN BusLIN Bus 右后门ECU 玻璃升降器门锁 CAN BusCAN Bus 左前门ECU 左后视镜玻璃升降器门锁 左后门ECU 玻璃升降器门锁 LIN BusLIN Bus 故障诊断仪 K K 线线 图 5.1 车门控制网络拓扑图 每个车门的设备都有一个对应的 ECU 来专门负责控制,车门设备与车门控制 ECU 之间用成本更低的 LIN 总线进行连接,组成一个局部的 LIN 网络。由于 LIN 总线的通讯都是由主节点来进行发起和协调的,所以,只需要控制主节点就可以 统一整个网络中各个节点对总线的使用,无需通过发送网络管理帧进行节点间的 浙江大学硕士学位论文 第 5 章 车身网络中的应用 24 同步,也就是说,LIN 网络不需要使用网络管理模块提供的节点间同步功能。因 此,为了更好地体现网络管理栈的总线同步功能,在这里我们只将重点放在 CAN 总线连接的 ECU 门控节点网络上。其中,该网络含有 1 个中控节点,负责网络情 况的监控及车门相关数据的收集。其余的 4 个 ECU 各自负责对应的车门设备。其 中负责驾驶室车门的 ECU,具有控制其它车门设备的功能。 5.1.2 车门网络硬件平台搭建 根据 5.1.1 节中的车门网络拓扑,搭建出如图 5.2 所示的车身网络。其中, 车门 ECU 硬件平台我们使用我们使用 4 块 Freescale HCS12 36开发板(图 5.2 中 的右侧一摞开发板)来模拟,而中控节点 ECU,我们则采用具有更多 Flash 空间 的 Freescale HCS12X 开发板(图 5.2 中左侧单块开发板) 。因为该门控节点除了 需要进行整体控制之外,还需要进行网络状况的检测,一旦网络节点连接出现异 常,则需要将异常信息写入到对应的 Flash 空间中,用于诊断模块的读取。所有 ECU 都使用 MSCAN12 模块进行 CAN 帧的收发,其中 MSCAN 是 Motorola Scaleable CAN 的缩写,而 MSCAN12 模块则是 MSCAN 在 M68HC12 系列 MCU 上的具体实现。它服从 CAN2.0A/B 协议,集成了除收发器外 CAN 总线控制器的 所有功能37。各个 ECU 的连接情况如下,硬件连接图如图 5.2 所示: 图 5.2 车门控制网络硬件图 1) 各个门控 ECU 均使用 CAN0 进行输出,且使用 RJ45 接口进行 CAN 信 浙江大学硕士学位论文 第 5 章 车身网络中的应用 25 号输出。 2) 中控 ECU 使用 CAN0 进行通信, 该开发板的 CAN 通过 RS232 接口进行 输出。我们通过 RS232 转 RJ45 来使得中控 ECU 与其它门节点连接到同 一条 CAN 总线上。 3) 为了实时监控网络上控制帧的发送情况,我们又使用周立功公司的 USB CANII 设备进行总线上帧的监测(图 5.2 中的白色设备) 。 对于这些节点的网络配置,如表 5.1 所示。 表 5.1 各 ECU 节点配置 模块名 模块描述 节点 ID CAN 帧 ID ECU A 驾驶室车门 1 0x101 ECU B 副驾驶车门 2 0x102 ECU C 左后车门 3 0x103 ECU D 右后车门 4 0x104 ECU Center 中控节点 0 0x100 表 5.1 中的节点 ID 对应于一个唯一的物理信道。对于一个 ECU 来说,可能 有多个信道接入到同一个网络中,则这两个信道也拥有不同的节点 ID 值。在这 里, 由于我们只使用到了 CAN0, 所以, 可以将这个值作为区别各个 ECU 的标识符。 CAN 帧 ID 用于和一般的总线通信信息相区别,当底层通信栈接收到数据帧时,通 过 CAN ID 就可以判断该帧的类型,提交到对应的网络管理模块进行处理。同一 个物理信道可以发送具有不同 CAN ID 的帧。节点 ID 和 CAN ID 都由 AUTOSAR 提 供的配置工具进行全局静态配置,保证同一网络中各个节点信息的一致性。 5.2 总线节点同步试验 网络管理栈的一个重要功能便是同步各个节点收发器的工作状态,即当各个 节点陆续释放总线之后,使得各个节点同步进入到睡眠状态。我们设计如下场景 来验证网络管理栈的管理功能: 1) ECU A,ECU B,ECU C,ECU D 和 ECU Center 在一开始时均处于 Bus Sleep 状态。 2) ECU Center 通过传感器网络汇报的信息,得知车速到达一定阈值之后, 浙江大学硕士学位论文 第 5 章 车身网络中的应用 26 启动本地车门管理模块的通信功能,发送管理帧将通知各个车门自动上 锁。 3) 上锁之后,中控模块不需要车门管理功能,释放总线。 在上述操作场景中,体现了一个典型的网络管理的应用。即在车载网络模块 中,并不是每一个 ECU 时时刻刻都需要处于全功率工作状态,正如同这里的车 门管理模块,在汽车行驶的过程中,其通信的频率非常低。所以,在两次通信过 程之间,就可以让车门的网络模块处于睡眠状态,以节约电能的消耗。 结合这个应用场景,其对应的流程如下,各个 ECU 模块的状态转换时序图 如图 5.3 所示: 1) 中 控 模 块 调 用ComM_RequestComMode() 请 求 对 应 信 道 的Full Communication 通信功能。 该请求将通过网络管理栈转换为对网络管理层 的 Nm_NetworkRequest()调用, 相应的 Can 控制器也被总线状态模块置为 工作状态。 2) 该信道网络管理层的状态机将进入 RepeatMessage 状态, 开始发送对应的 管理帧,通知其它节点其进入工作状态。 3) 由中控ECU发送的网络管理帧将触发各个车门管理ECU的wakeup中断, 使得各个车门管理模块启动相应的通信功能与网络管理栈。各个车门管 理模块的通信管理模块都从 Bus-Sleep 状态进入到 RepeatMessage 状态, 同时开始发送管理帧。 4) 中控节点在等待所有车门 ECU 启动完毕之后,发送数据帧,命令各个车 门进行上锁操作。此时各个 ECU 中的网络管理模块都处于 Normal Operation 状态,并进行周期性的网络管理帧发送。 5) 中控节点数据发送完毕,释放总线。各个车门控制节点在进行完操作之 后,同样也释放总线。 6) 经过一段时间之后,网络上的节点相继进入到睡眠状态。这里收发器睡 眠状态的设置,是通过将 MSCAN12 寄存器 0 中的 SLPRQ 置为 1,向 MSCAN12 发出休眠请求之后, 等待 MSCAN12 将发送缓存中的所有帧发 浙江大学硕士学位论文 第 5 章 车身网络中的应用 27 送完毕,通过设置寄存器 0 中的 SLPAK=1 确认休眠才真正完成的。 图 5.3 车门控制网络 ECU 状态转换图 在该应用场景中, 我们使用开发板中的 LED 灯来指示对应网络管理模块所处 的状态,通过 USBCANII 来观测网络上帧的发送情况,如图 5.4 所示。各个定时 器的设置如表 5.2 所示,这些定时器的值在所有节点中保持一致。同时,为了减 少因为同时发送而产生的竞争现象,我们对于各个节点设置不同的发送其实偏移 时间,其中 Center ECU 发送起始偏移为 400ms,ECU A ECU D 分别为 500ms、 浙江大学硕士学位论文 第 5 章 车身网络中的应用 28 550ms、600ms 和 650ms。 表 5.2 各 ECU 定时器设置 NmTimeout Timer NmMsgTransmit Timer Nm_RepeatMessageTimer Nm_BusSleepTimer_Cycle 1500ms 1000ms 5000ms 15000ms 图 5.4 网络帧发送情况 在图 5.4 中,我们可以清楚的看到,当中控节点处于 RepeatMessage 状态发 送第一个网络管理帧之后,各个门控节点也相继启动了网络管理模块,同时进入 了 RepeatMessage 状态。其中,Can 帧的数据域若为 1,则表明该帧是在由于网络 管理模块启动时发送的网络管理帧,且处于 RepeatMessage 状态。根据表 5.2 中 的定时器设置,各个节点将在 RepeatMessage 状态下停留 5000ms,而网络管理帧 的发送周期为 1000ms, 所以每个节点启动后将在 RepeatMessage 状态下发送 5 个 数据第二字节为 1 的网络管理帧,从图 5.4 中可以清楚的观察到,即从第 0 条至 浙江大学硕士学位论文 第 5 章 车身网络中的应用 29 第 24 条 Can 帧;此后,各个节点相继进入到 Normal Operation 状态,并进行周期 性地发送网络管理帧, 图 5.4 中第 25 条至第 44 条 Can 帧。 最后一条帧为命令帧, 而非管理帧,在此之后,各个节点都释放总线,不在发送管理帧。在等待一段时 间之后,相继进入到 Bus Sleep 状态,可以观察到相应的 LED 变化。 5.3 网络状况检测与故障诊断 网络管理栈的另一个重要功能便是对于总线中节点连接状态的检测,如图 5.1 中所示,中控节点的另外一个功能就是监控网络节点的状况,进行简单的网 络诊断,这种诊断功能通常是由在线诊断模块实现的,在线诊断模块能显著提高 汽车网络的安全性26。但由于车载 ECU 硬件资源的限制,在线诊断的功能并不 能做的太复杂,只能处理比较一般的故障。所以当网络中有节点异常,还应该记 录下相应的诊断码,供之后的离线诊断使用。 在网络管理栈中,并不提供具体的节点连接状态检测功能,相对应的,只提 供给用户相应的接口来进行二次开发。我们在这里也基于网络管理栈,结合之前 的车门控制网络,提供一个简单的节点状态检测模块,以此来验证网络管理栈相 应节点管理机制。 在网络管理模块中,若 SWC 对某个信道调用 RepeatMessageRequest()函数, 则该信道进入 RepeatMessage 状态,且发送 RepeatMessageBit 置为 1 的网络管理 帧。 其它网络管理模块若接收到这种类型的帧, 则也会转入 RepeatMessage 状态, 进行帧的发送。这样,这个机制就使得我们能够实现一个简单的节点检测模块。 我们使用一个周期性定时器来启动这个节点检测任务 TaskVMM,在该节点 中,预先存储了预期需要通信的网络节点表。当 TaskVMM 启动之后,就会使所 在节点的信道进入 RepeatMessage 状态,同时发送相应的管理帧,让总线上的其 它节点也进入到 RepeatMessage 状态,并向总线发送对应的管理帧信息。此时 TaskVMM 在中控节点处于 RepeatMessage 的状态下监听总线上的帧信息, 当中控 节点退出 RepeatMessage 状态之后,通过比较预期的网络状态和实际得到的网络 状态,来获知网络节点的连接是否正常。若 TaskVMM 没有监听到预期的某个节 浙江大学硕士学位论文 第 5 章 车身网络中的应用 30 点的信息,则通过在 Flash 中存入对应的故障码,等待诊断程序的读取。 我们设置如下的使用场景来验证 TaskVMM 的节点诊断能力: 1) 将中控 ECU,各车门控制 ECU 均处在正常网络连接状态。 2) 将左后车门 ECU C 拔离 CAN 总线。 3) 将右后车门 ECU D 拔离 CAN 总线。 在中控ECU中, 我们认为ECU A ECU D都应该正常参与到总线通信中来。 对于实时的网络情况,我们通过串口进行输出;对于诊断信息,我们则通过诊断 程序 SmartSAR Scanner 进行读出。实时网络监控情况如图 5.5 所示。 图 5.5 节点状态检测 在检测到对应的 ECU C 和 ECU D 出现异常之后, 我们参照 ISO15031-6:2005 所定义的故障码标准,将对应的故障码存储到对应的 Flash 中。车门管理模块所 对应的通信故障码38如表 5.3 所示: 表 5.3 车门管理模块故障码 DTC number DTC naming U0199 Lost Communication With “Door Control Module A” U0200 Lost Communication With “Door Control Module B” U0201 Lost Communication With “Door Control Module C” U0202 Lost Communication With “Door Control Module D” 我们使用浙江大学 ESE 嵌入式工程中心所开发的符合 OBD-II39标准的汽车 诊断系统 SmartSAR Scanner,对应的诊断信息输出如图 5.6 所示。 浙江大学硕士学位论文 第 5 章 车身网络中的应用 31 图 5.6 网络诊断信息 5.4 本章小结 本章内容通过介绍两个典型的应用场景,验证了网络管理栈的核心功能。本 章首先介绍了网络管理栈的应用场景车门管理网络,介绍了其网络 ECU 的功 能设计以及相应的硬件平台。然后通过一个中控 ECU 操作四个车门进行上锁的 场景,验证了网络管理栈同步各个节点发送功能开启和关闭的过程。最后又通过 实现一个简单的网络节点检测模块,验证了网络管理栈对于节点在线状态检测与 网络故障诊断的支持。 浙江大学硕士学位论文 第 6 章 工作总结与展望 32 第第6 6章章 工作工作总结与展望总结与展望 6.1 工作总结 汽车工业正在经历着电子化的革命,而汽车嵌入式软件技术与汽车总线技术 更是为这场革命注入了强劲的动力,不仅提高了汽车性能,降低了生产成本,同 时更极大地改变了传统汽车的设计理念。 目前国外的整车制造商、 零部件供应商, 都积极地应对这场信息技术所带来的革命,OSEK、AUTOSAR 等汽车软件开发标准 的建立, 更为大规模应用车载网络技术和电子控制技术铺平了道路。 国外整车厂、 汽车零部件供应商目前都积极地将已有的解决方案迁移到 AUTOSAR 体系中,以其 更好地复用解决方案,同时降低汽车软件整合的困难,减少开发周期。而国内汽 车电子起步较晚,汽车总线应用、汽车软件开发水平都处在起步阶段,对于国外 先进的汽车软件开发方法和技术,国内相关的研究较少。 本文在深入研究 AUTOSAR 网络标准规范及其开发技术的基础上,结合本实验 室 AUTOSAR 研究的现状,基于目前车载网络领域中应用最广泛的 CAN 总线,设计 并实现了符合 AUTOSAR 标准的网络管理功能模块,具体包括: 1) 对 AUTOSAR 体系架构进行了深入的调研,特别是对于网络管理相关模 块的进行了深入地理解,并结合当前车载网络中 ECU 节点设计特点、总 线技术特点,明确了所需要提供的网络管理功能和应用场合,为设计和 实现网络管理栈奠定了基础。 2) 设计并实现了符合 AUTOSAR 标准的网络管理栈。特别是车载网络中广 泛应用的 CAN 总线, 为其实现了与总线相关的发送与操作功能,其开发 流程可作为将来扩充其它总线时的标准。为用户预留了相应的网络管理 接口,支持二次开发。 3) 在进行详尽的功能测试之后,通过模拟汽车的车门管理网络,将网络管 理栈应用在相应的 ECU 之上,并结合应用场景,验证了网络管理栈的两 个主要功能:总线节点同步与节点状态检测功能。同时针对网络故障, 浙江大学硕士学位论文 第 6 章 工作总结与展望 33 依照 ISO-15031-6 标准,为诊断工具提供了相应的网络故障码。 6.2 工作展望 未来汽车电子与软件技术的发展趋势,就是愈发将汽车作为一个整体来进行 控制,整车各部件信息共享成为整车控制的基本需求。伴随着这种信息整合的需 求,结合汽车成本的考虑,在未来的发展中,车载网络必然是由多种成本各异, 速度各异的总线共存;同时随着汽车对于性能、安全、操控等方面需求与法规的 不断发展,车载网络管理也需要不断地完善以适应这种发展趋势: 1) 在下一阶段中,需要提供对更多总线的支持,例如低速总线 LIN,高速总 线 FlexRay 等常见车载总线的网络管理功能。 2) 在网络管理模块中,一个影响网络管理实时性的最主要因素便是定时器 参数设置的问题,定时器值的大小,直接影响到各个节点对于网络事件 的判断和响应。下阶段对于定时器值设置的问题,应该为应用程序的配 置提供更为合理的建议。 3) 在车载网络管理中,还需要尽可能减少管理帧对于总线负载的影响。在 保证正常响应的前提下,如何减少冗余管理信息,成为下一阶段的一个 重要任务。 4) 虽然 AUTOSAR 网络管理标准为整车厂开发网络管理策略提供了接口和机 制上的支持。但是在将来仍然需要提供一个较为成熟的网络管理策略算 法库,帮助用户提高开发效率。 浙江大学硕士学位论文 参考文献 34 参考文献参考文献 1 秦贵和, 葛安林, 李柱张, 等. 汽车网络技术J. 汽车工程, 2003, 25(2): 152-157. 2 G LEEN, D HEFFERNAN, A DUNNE. Digital networks in the automotive vehicleJ. Computing & Control Engineering Journal 1999, 10(6): 257-267. 3 BROY MANFRED. Challenges in automotive software engineeringC. ICSE 06 Proceedings of the 28th international conference on Software engineering, 2006. 4 BOSCH. CAN Specification Version 2.0S. Bosch GmbH. 1991. 5 CHEN XI. Requirements and concepts for future automotive electronic architectures from the view of integrated safetyD. Karlsruhe: faculty of electronic and Informatik, Karlsruhe University, 2008. 6 AUTOSAR GBR. AUTOSAR homepageEB/OL. 2010-12-10. 7 AUTOSAR GROUP. AUTOSAR on the Way to Becoming a Global StandardR. Tokyo: AUTOSAR, 2010. 8 唐楚峰, 李仕元. 汽车网络技术应用现状与展望J. 邵阳学院报(自然科学 版), 2010, 7(2): 30-32. 9 ISO-11898. Road Vehicle Interchange of Digital Information Controller Area Network(CAN) for High-Speed CommunicationS. 1993. 10 POLEDNA STEFAN. The Time-Triggered Communication Protocol TTp/CM. 1998. 11 MOST CORPERATION. MOST High Protocol SpecificationS. 2001. 12 HANSEN PAUL. X-by-Wire Communication Protocol: Possible FlexRay and TTP MergerR: Hansen Report, 2001. 13 GABRIEL LEEN, HEFFERNAN, DONAL. Expanding automotive electronic systemsJ. IEEE Computer and Control, 2002, 35(1): 88-94. 14 VECTOR GROUP. Serial Bus Systems in the AutomobileR. Munich: Vector Informatik, 2006. 浙江大学硕士学位论文 参考文献 35 15 MAYER EUGEN. Status quo and future of ECU communication in automobilesR. Stuttgart: Vector Informatik, 2006. 16 FENG LUO, ZHIQI CHEN, JUEXIAO CHEN, et al. Research on FlexRay communication systemC. Vehicle Power and Propulsion Conference, 2008 VPPC 08 IEEE, 3-5 Sept., 2008. 17 MAKOWITZ R., TEMPLE C. Flexray - A communication network for automotive control systemsC. Factory Communication Systems, 2006 IEEE International Workshop, 2006. 18 FLEXRAY CONSORTIUM. FlexRay Communications System Protocol Specification Version 2.1S. 2005. 19 GUO HUAQUN. Automotive Informatics and Communicative Systems:Principles in Vehicular Networks and Data ExchangeM. New York: Information Science Reference(an imprint of IGI Global), 2009: 283-295. 20 VECTOR GROUP. Current Challenges in Automotive NetworkingR. Munich: Vector Infomatik, 2006. 21 SUWATTHIKUL J., MCMURRAN R., JONES R. P. Adaptive OSEK Network Management for in-vehicle network fault detectionC. Vehicular Electronics and Safety, 2007 ICVES IEEE International Conference on, 13-15 Dec, 2007. 22 OSEK/VDX. OSEK homepageEB/OL. 2010-10-23/. 23 OSEK/VDX. Network Management: Concept and Application Programming Interface Version 2.5.3S. 2010. 24 HOFFMANN C., JOHN D., KRAMMER J., et al. OSEK/VDX network managementC. OSEK/VDX Open Systems in Automotive Networks (Ref No 1998/523), IEE Seminar, 13 Nov, 1998. 25 SMYTHE C. ISO 8802/5 token ring local-area networksJ. Electronics & Communication Engineering Journal, 1999, 11(4): 195-207. 26 CHANG-WAN SON, JIN-HO KIM, TAE-YOON MOON, et al. Timing analysis of worst case with direct NM of OSEK NMC. Control, Automation and Systems, 2008 ICCAS 2008 International Conference on, 14-17 Oct, 2008. 27 BELENKI STANISLAV, TAFVELIN SVEN. Analysis of errors in network load 浙江大学硕士学位论文 参考文献 36 measurementsJ. SIGCOMM Comput Commun Rev, 2000, 30(1): 5-14. 28 AUTOSAR GBR. Specification of Generic Network Management Interface V1.0.2S. AUTOSAR GbR. 2008. 29 AUTOSAR GBR. Specification of CAN State Manager V1.1.0S. AUTOSAR GbR. 2010. 30 AUTOSAR GBR. Specification of CAN Transceiver Driver V1.2.2S. AUTOSAR GbR. 2008. 31 AUTOSAR GBR. Specification of CAN driver V2.3.0S. AUTOSAR GbR. 2010. 32 AUTOSAR GBR. Specification of CAN Interface V3.1.0S. AUTOSAR GbR. 2010. 33 AUTOSAR GBR. Specification of Communication V3.1.0S. AUTOSAR GbR. 2010. 34 AUTOSAR GBR. Specification of CAN Network Management V3.0.1S. AUTOSAR GbR. 2008. 35 LIN ZHOU, MIN YAO, YONGJUN LI, et al. A New Specification-based Test Data Generation Strategy for OSEK OSC. Computer and Information Technology (CIT), 2010 IEEE 10th International Conference on, June 29- July 1, 2010. 36 MOTOROLA. MC68000 Programmers Reference ManualS. Motorola Inc. 1992. 37 杨国田, 白焰. Motorola 68HC12 系列微控制器原理、应用与开发技术M. 北 京: 中国电力出版社, 2003: 282-298. 38 15031-6 BS ISO. Road vehicles Communication between vehicle and external equipment for emissions-related diagnosticsS. British Standards Institution. 2005. 39 OBD GROUP. O

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论