车载以太网学习笔记

由IEEE组织,OPEN Aliance SIG组织, AVNU组织,AUTOSAR组织的共同发展与合作,进而规范了车载以太网符合OSI模型的整体架构如下图:

图 车载以太网OSI总体架构

  AVNU 致力于推进AVB/TSN时间敏感网络在汽车领域的应用,使以太网成为一种时间确定性的实时网络;

  IEEE 电气与电子工程师协会,其中802.3工作小组致力于推进以太网相关标准的制定与完善;

  AUTOSAR: 汽车开放式系统架构组织,致力于实现汽车软硬之间解耦的标准同时也为车载以太网软件层级作出了相关规范说明;

  OPEN Aliance SIG: 为非盈利性的汽车行业和技术联盟,旨在鼓励大规模使用以太网作为车联网标准;

标记为“IT”则为传统以太网技术协议规范,而标记为“Automotive”则为车载以太网技术协议规范。除了物理层、UDP-NM、DOIP、SOME/IP、SD这五个模块为车载以太网技术协议规范之外,其余均为传统以太网技术

车载以太网与传统以太网相比,车载以太网仅需要使用1对双绞线,且车载以太网并未指定特定的连接器,连接方式更为灵活小巧,能够大大减轻线束重量。除此以外,车载以太网物理层需满足车载环境下更为严格的EMC要求,对于非屏蔽双绞线的传输距离可达15m(屏蔽双绞线可达40m)。

虽然车载以太网只采用单对差分电压传输的双绞线,但是100M/s以太网可以通过回音消除技术来实现全双工通信。

当下主流的车载以太网协议主要为IEEE 100BASE-T1以及IEEE 1000BASE-T1,常规使用可采用100BASE-T1,如果需要更高带宽,可选择1000BASE-T1。

不过因为速率越高,对车载以太网物理层一致性测试就更为严格。

物理层

其中以太网所有物理层的功能全部集中在一个称为“PHY”的模块中,它将以太网控制器以及物理介质连接在一起,并且通过一个标准化接口MII连接,同时PHY模块与底层介质通过MDI接口连接,以100BSASE-T1所示,如下图所示:

数据链路层

可细分为LLC(Logic Link Control)以及MAC(Media Access Control)两个层级。此两层级定义与作用如下:

  • LLC:负责向上层提供服务,管理数据链路通信,链接寻址定义等,与所用物理介质没有关系;
  • MAC:负责数据帧的封装,总线访问方式,寻址方式以及差错控制等,MAC层的存在则可以使得上层软件与所用物理链路完全隔离,保证了MAC层的统一性;

网络层

网络层就是IP协议所在的层级,IP协议可以分为IPV4以及IPV6,常用的主要是IPV4,IP协议的主要作用就是基于IP地址转发分包数据。

  • 同时IP也是一种分组交换协议,但是IP却不具备自动重发机制,即使数据没有达到目的地也不会进行重发,所以IP协议属于非可靠性协议。
  • 车载以太网主要使用IPV4协议,同时由于该协议也属于传统以太网范畴

传输层

传输层的协议就是TCP/UDP,这两者协议彼此独立,也可以同时存在,看具体使用场景需求。TCP/UDP也是传统以太网的标准协议。不在详述

TCP协议特点

从上述的TCP建立连接以及断开连接的过程,不难得出TCP是一种面向连接可靠的传输层协议。具体总结有以下一些特点:

  • 面向无连接,即不需要建立连接便可以直接进行通信;
  • 存在单播,多播,广播的功能;
  • UDP是面向报文的,UDP的报文报经过IP层不会进行任何拆分或重组;
  • 不可靠性:由于没有像TCP的拥塞控制以及出错自动重传等机制,则会导致发送的报文无法保证接收方是否收到,因为网络本身就存在诸多的不确定性;

  UDP协议特点

对比TCP协议,UDP具备以下一些特点:

  • 面向无连接,即不需要建立连接便可以直接进行通信;
  • 存在单播,多播,广播的功能;
  • UDP是面向报文的,UDP的报文报经过IP层不会进行任何拆分或重组
  • 不可靠性:由于没有像TCP的拥塞控制以及出错自动重传等机制,则会导致发送的报文无法保证接收方是否收到,因为网络本身就存在诸多的不确定性;

应用层

在车载以太网领域,目前主流涉及到的应用协议主要有UDP-NM,DOIP,Some/IP,SD以及传统以太网需配合支持的ICMP,ARP,DHCP等协议。

<think>好的,我现在需要处理用户关于车载测试实战经验、笔记、开发文档和经验分享的查询。首先,用户明确提到他们之前看到的引用内容,其中引用[1]提到有同事从手机测试转到车载测试,这可能意味着用户对转型经验或两者差异感兴趣。用户可能需要了解车载测试的具体实战技巧,或者如何将手机测试经验迁移过来。 接下来,我需要检查现有的引用内容是否有相关的信息。引用[1]确实提到了同事的经验,但其他引用如[2]、[3]、[4]更多涉及面试资料、职业发展和Android开发,可能与车载测试关联不大。不过,用户的问题集中在车载测试的实战资源上,所以可能需要依赖引用[1]的信息,并补充其他相关知识。 用户可能需要的内容包括车载测试的流程、工具使用(如CANoe、诊断工具)、测试用例设计、法规标准(如ISO 26262)、实际案例等。此外,开发文档可能涉及测试计划、报告模板,自动化测试框架等。经验分享部分可能需要包括转型经验、常见问题解决、性能与安全测试要点等。 需要注意的是,用户可能缺乏特定资源链接,因此应建议可靠的信息来源,如专业论坛、书籍、在线课程和行业社区。同时,结合引用[1]提到的同事经验,强调从手机测试转向车载测试的可行性和注意事项,如学习汽车协议、适应更严格的测试标准等。 最后,生成相关问题时要围绕车载测试的深入话题,例如工具学习、协议掌握、自动化测试搭建、与手机测试的差异等,帮助用户进一步探索该领域。</think>### 车载测试实战经验与资源整理 结合引用[1]中提到的“手机测试转到车载测试”经验,以下是车载测试的核心实战要点及资源方向: --- #### **1. 车载测试与手机测试的关键差异** - **测试环境**:车载系统需模拟极端温度(如$-40^\circ C$至$85^\circ C$)、振动、电磁干扰等场景[^1]。 - **协议与标准**:需掌握CAN/LIN总线、AutoSAR架构、ISO 26262功能安全标准,而手机测试更关注3G/4G/5G协议与APP兼容性。 - **测试工具**:常用工具如CANoe(总线仿真)、INCA(标定)、VectorCAST(嵌入式测试),与手机测试的Appium/Monkey差异较大。 --- #### **2. 实战经验与文档资源** **开发文档与测试用例设计** - **需求分析**:明确功能需求(如ADAS车道保持)与非功能需求(如响应时间≤100ms)。 - **测试用例模板**:覆盖正向、负向场景,例如: ```python # 示例:车载娱乐系统响应时间测试 def test_response_time(): start_time = time.time() send_can_message("NAV_Start") assert get_response("NAV_MapLoaded") - start_time < 2.0 ``` - **自动化测试框架**:Robot Framework+CANoe插件实现总线信号自动化校验。 **经验分享重点** - **问题定位**:如CAN总线丢帧问题,需用示波器抓取物理层信号,分析错误帧率(公式:$错误帧率 = \frac{错误帧数}{总帧数} \times 100\%$)。 - **性能优化**:通过$$ T_{响应} = T_{传输} + T_{处理} + T_{队列} $$拆解系统延迟来源。 --- #### **3. 推荐学习资源** - **书籍**:《汽车电子硬件设计》《车载以太网权威指南》 - **在线课程**:Udemy的“Automotive Embedded Systems”专项课 - **社区**:SAE International(国际自动机工程师学会)、CSDN车载测试专栏 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

不懂汽车的胖子

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值