Automotive

从上一篇文章（SomeIP学习笔记：基础知识）的介绍可看出SOME/IP标准预先定义了很多很实用的数据类型，可在实际项目中可能处于兼容性的需求，不完全依照上边数据类型原始定义使用，可能会结合着信号矩阵有进一步的定义，比如说有Offset和Scale的设置等。 接下来记录一下用CANoe怎样调试或者模拟AUTOSAR环境下的SOME/IP通信，在这里我使用的是CANoe SP5的一个SOME/IP例程：Basic AUTOSAR SOME/IP Event，如下图。 这个样例是使用Simulation Setup模式结合了一个ARXML创建的，已经有了很好的Pannel，对于我们学习Simulation消息订阅很方便。在下边两个框CAMF和ADAS，我们可以点击Enable Service或者Subscribe Service， 从上边的Trace窗口可以看到对应的服务端、客户端相应的Offer Service、Find Service、Subscribe Event group以及Stop Subscribe Event group的报文。 这个报文其实现原理主要依赖了三大块：CANoe的SOME/IP协议栈、示例ARXML数据库以及几个节点的CAPL代码。 其中示例ARXML数据库定义了一个服务端（Provider: CAMF）和一个客户端（Consumer: ADAS）,规定了其支持的服务类型：即一个名叫ADASDisplayInfo的Event 事件通知，然后这个事件传输的变量叫做DetectedTrafficSign，类似于一个结构体，里边有SignType、DistanceToSign以及Realiabiliy变量，以及每个变量的更加细致的定义。 然后CAPL代码一方面实现了对于变量的填充，另一方面调用CANoe的SOME/IP协议栈进行Event Notification的发送以及SD服务发现事件订阅的过程。 最后SOME/IP协议栈提供了底层的交互支持，以及对CAPL的API调用的支持，从而非常简单实现服务发现订阅以及发送接收。 在这个例程默认的界面下，可以尝试点击那些按钮来从trace看服务端怎样发送报文Offer一个Service，以及客户端怎样发送报文Find 一个Service，以及服务订阅上后ACK是什么样，还有到了真正Event Notification的报文是什么样。这对于基础的SOME/IP报文熟悉还是非常有帮助的。 而截至目前所能模拟的通信都很依赖ARXML对于Service的定义，我想记录的更多的是对于自定义SOME/IP的学习以及调试方法。以这个ARXML中的服务为例，首先我们需要将其转换成CANoe可编辑的模式，使用CANoe自带的小工具将其转换成可编辑的数据库格式vCODM。 接下来就用不到这个例程了，我们把刚刚转换号的vCODM数据库存到某个文件夹，然后以此为例记录一下怎样使用CANoe的SOME/IP协议栈来自定义数据库模拟一个服务。 我们新建一个空的工程，使用Communication Setup模式，然后在红框1 和红框2处倒入刚才我们转换完成的数据。红框3我们下一步再点击，接下来将两个节点设置成仿真模式，以及将Real Bus换成Simulated Bus模式，现在运行一下看看效果。 点击运行后到Trace窗口看到，并没有像Simulation Setup 的例程那样有Service Offer、Service Find 以及Subscribe信息。 这个区别的主要原因是例程中数据库并没有开启服务发现SD协议，而例程中通过CAPL命令实现了Service Offer以及Service Subscribe。由于我们新建的没有这些脚本，所以从Trace来看并没有任何SOME/IP相关的数据。 在一开始我们了解到SOME/IP有一个SD服务发现的协议，在这儿没有起作用，是因为在数据库中，示例数据库这个设置处于关闭状态。我们在刚才按钮3的地方进入数据库编辑页面，然后将Discovery Technology协议从None 改成SOME/IP Service Discovery，这样子协议栈就会自动执行服务发现过程，保存运行然后我们再观察Trace窗口，有时候需要重新加载一下数据库才能生效。 现在看到已经有了Service Offer、Service Find、Subscribe Event group

在整车功能开发以及调试过程中，ECU与ECU之间使用车载以太网的比例越来越多，所以区别于之前的CAN总线报文的，对于以太网数据包的抓取和分析越来越普及了，而其中又绕不开SOME/IP，每一个搞过车载功能开发都或多或少接触过或者使用过SOME/IP。我在了解这个协议过程中走了不少弯路，后来发现并没那么复杂，于是打算把自己的心得记录下来。 主要从3个角度记录我所学习的SOME/IP，首先是一些基本的知识，其次是怎样用Vector CANoe来调试一个结合了AUTOSAR通信，包括怎样在CANoe里边调整数据库实现自定义调试；最后做一个实践，使用开源的SOME/IP协议栈vsomeip，来和我们CANoe的SOME/IP协议栈做一个真实的通信。 SOME/IP基础知识 SOME/IP是基于TCP/UDP/IP协议之上的应用层协议，很像网络开发中前后端交互的HTTP的方式。如果之前做过前后端的开发，对于客户端和服务器的连接有一定的知识储备，那么在了解SOME/IP的过程中会觉得很简单的。SOME/IP依托于TCP或UDP，所有的数据都是作为TCP/UDP的Payload通过IP协议进行传输。可以理解成在Payload中又做了进一步的切分，并且比特位以及长度做了事先约定，例如下图中的前16个Bit固定为Service ID，紧接着的16个Bit为Method ID或者Event ID。 目前网络中常见的SOME/IP学习路径和学习资料，包括我之前看的一些，大多是在CAN总线技术路线以及实现方式的基础上介绍SOME/IP的特点以及技术细节的，很多从以太网IP以及UDP和TCP开始讲起，然后再说到SOME/IP的各种Header头部还有服务订阅等等内容，这样的一个学习路径，非常容易把很多的类似的概念参合到一起，比如IP层、UDP、TCP以及SOME/IP都有Header头部，IPv4和IPv6头部又不一样，TCP的三次握手四次挥手和SOME/IP的Subscribe订阅以及UDP和Notification，太太太容易混淆了。可能看了好久还觉得云里雾里，觉得这个太高深了，其实真的SOME/IP没啥，将其理解成ECU之间的HTTP类似协议，下层依赖的TCP/UDP和电脑手机服务器用的没有任何区别，明白这个就已经学会了一大半。关于车载以太网和普通以太网的区别，我在另外一个学习记录贴中有记录，一句话总结就是物理层数据链路有区别，到了IP层以上就完全一样了。 不过从另外一个角度也可以理解，很多汽车软件的开发人员是从传统技术栈比如CAN总线时代过来的，对于以太网的了解不像互联网人那样深入，所以有一定的需求再详细了解一些IP/TCP/UDP的知识。我的建议是将这两部分分开学习，先回顾一下计算机网络，七层协议啥的，再了解一个应用层协议比如HTTP，最后再详细学习SOME/IP，绝对会事半功倍，发现真的好简单，半天时间SOME/IP入门足够。 另外在车载应用开发中，SOME/IP的Payload部分填充，考虑到和其他ECU以及功能的兼容性问题，会使用AUTOSAR的规则定义方式，这和CAN总线的Frame帧非常的像。在CAN总线Data Field数据场一次最多传输8字节，通常会把这对应的64个比特拆分成传输数据的最小量，比如一个布尔型只分配1个比特，然后一个0-255的Uint8只分配8个比特，总共8字节64比特能拆分成很多个Signal信号，从而有限的资源传输更多数据，各个Bit对应的Signal信号长度以及数据类型的记录成一个表格，即得到了CAN总线数据库DBC。在车载SOME/IP开发中Payload部分多数情况下也沿用了类似的思路，所以在Payload部分解析也需要一些额外的信号矩阵，结合了SOME/IP支持的数据结构和AUTOSAR数据结构，就能组合出很多复杂的结构体，实现更多上层应用间的数据传输。 这样的实现方式也可以很好的复用迁移传统汽车行业稳定成熟的软件解决方案，在必要的情况下，只需要在传输层做一些技术更新，核心逻辑不需要任何变动，从而降低潜在的风险。但是这一块是互联网人来做汽车软件的话，可能就不是很熟悉了，尤其对于不常见的Bit位的数据拆分，再结合这大端小端数据类型，还有信号矩阵有Scale放大缩小以及Offset偏移，八成互联网人转过来的开发第一次会搞错。建议之前对于汽车总线了解较少的开发人员可以系统学习一下CAN总线以及结合项目了解一下AUTOSAR信号矩阵，可以避免很多低级的错误。 传统车载网络CAN总线在面向信号的数据传输中，发送方会根据自身需求（如数值更新或变更时）主动发送信息，而无需考虑网络中是否有接收方当下需要这些数据。与之不同的是面向服务的数据传输模式即发送方仅当网络中至少存在一个接收方需要该数据时才会进行传输。这种方式的优势在于避免了不必要的数据对网络及所有连接节点造成的负载。因此，面向服务的数据传输要求服务器必须通过某种方式获知哪些接收方正在等待其数据。在SOA架构中，服务是构成系统的基本单元，它代表了系统中的某个功能或操作。服务通过明确的接口与外界进行交互，实现了功能的封装和重用。SOA架构的核心就是服务，它通过将应用程序划分为一系列的服务来降低系统的复杂度，提高系统的灵活性和可维护性。在SOA中，服务是通过其接口被定义和访问。接口是服务与外界交互的桥梁，它定义了服务的输入、输出和行为规范。在SOA架构中，以太网通信作为服务的传输载体，负责在不同的ECU或服务之间传递数据和信息，根据AUTOSAR平台的规范与推荐，一般选择以太网应用层协议SOME/IP协议或者DDS协议作为跨域通信协议。 在SOME/IP协议中，服务接口被明确划分为三种类型： Event、Field、Method，每种类型都服务于不同的通信需求。 Event and Field Notification 服务器基于活跃订阅发送的内容可呈现两种格式：事件通知（Event Notification）和字段通知（Field Notification）。这两种格式的共同特性是事件驱动生成机制，但其数据结构存在本质差异: 事件通知Event：采用自包含的静态快照形式，其字段填充的属性仅反映事件触发时的瞬时状态，与历史事件无任何关联 字段通知Field：包含具有时序关联性的动态值，除当前值外还隐含历史状态。因此字段可扩展为包含Getter/Setter方法，允许客户端对目标内容进行读写操作。 需要特别说明的是，在SOME/IP协议中，事件总是以事件组（Event group）的形式进行组织，客户端仅能订阅整个事件组，而无法单独订阅组内某个特定事件。Field的Setter/Getter 方法遵循请求/响应（REQUEST/RESPONSE）模式，变更通知则通过事件机制实现，所有订阅操作都需通过SOME/IP服务发现（SOME/IP Service Discovery）协议完成。 Method 另一种数据交换方式是通过方法调用（Method Call）实现信息传递。客户端通过发起远程过程调用（Remote Procedure Call, RPC），触发目标服务器上的函数执行。具体流程如下： 调用过程：客户端通过网络发送请求来调用服务器函数，该请求可包含作为参数传递至被调用方法的数据； 响应机制：服务器执行函数后，可能通过响应消息向客户端返回执行结果。 需注意，当客户端主动调用函数时，通常意味着需要获取返回数据，通常被称作RR模式（Method Request with Response），但服务器方法也可能不返回任何值（Void类型），常被称作FF模式（Method Fire & Forget），此时客户端在确认方法被成功调用后即完成整个流程。 Service Discovery 为了让客户端能够获知当前可用的服务，SOME/IP-SD（服务发现协议）提供了两种动态服务发现机制： 服务提供(Offer Service)： 服务器通过该机制向网络宣告其提供的所有可用服务 每个设备通过组播（multicast）方式广播消息 消息内容包含该设备提供的所有服务列表 传输层采用UDP协议 服务查找(Find

V2X是什么 参与V2X量产相关的项目于有一段时间了，终于终于现在对这个领域有了一个轮廓性的了解，真是不容易，功能虽小，但是将其用到量产，涉及到的知识却非常的广泛，趁着现在还没忘掉，打算沉淀成一篇笔记。 V2X，全称Vehicle-to-Everything，中文意思是“车对一切”。它是一种让车辆能够与周围环境中的各种实体进行数据交换的通信技术，是万物互联在汽车出行领域的拓展。这些实体包括： 其他车辆（V2V）：车辆之间可以互相通信，共享速度、位置、转向等信息，提前预警潜在的碰撞风险，提前做行驶规划，让车与车有了直接的交互。 行人（V2P）：车辆可以通过感知到附近的行人，尤其是盲区的行人非机动车，并采取相应的避让措施。 道路设施（V2I）：车辆可以直接与周边交通信号灯、路标等基础设施进行通信，获取实时准确的交通信息。 网络（V2N）：车辆可以连接到互联网，获取天气、路况以及更远处交通事故等信息等信息。 形象地说，常规的ADAS是给车辆装上了眼睛，让车辆自己可以观察周边环境进行一定程度的自动驾驶。而V2X就像给车辆装上了一张嘴巴和一对耳朵，可以说出自己的情况，以及听到周边车辆他们遇到的事情，这让更高级级别的自动驾驶成为可能。 V2X技术路线 目前，V2X主要有两大技术路线：DSRC和C-V2X： DSRC(IEEE 802.11p)技术：由IEEE主导标准制定，提供短距离无线传输技术，以车车和车路通信为主要方式。 C-V2X技术：包括LTE-V2X和NR-V2X，由3GPP主导标准制定。C-V2X是将蜂窝通信技术和直通通信技术有机结合得车联网无线通信技术，同时支持车-车直通通信和蜂窝通信两种方式，支持车车、车路、车人以及车网等各类应用。 简单的说，对于车联网这个新的需求，尤其直通技术上，DSRC是将WiFi协议魔改过来得技术，而C-V2X是将无线通信LTE以及4G魔改来的技术。虽技术严谨路线有所区别，但是要解决的遇到的问题是大致一致的，IEEE 802.11p和C-V2X以及NR-V2X主要体现在无线接入技术的不同上。在协议其中C-V2X尽量重用蜂窝系统已有的上层协议，将研究重点聚焦于接入层的物理层和媒体接入技术。DSRC包括两类，用于ETC的DSRC和基于802.11pde DSRC，两者是不同的技术。两种技术路线相似的网络层可支持IP协议栈，同时考虑IP协议栈的开销以及低时延传输要求，，也可采用非IP传输支持上层应用。在《蜂窝车联网（C-V2X）》一书中有一个图表，很清晰对比出DSRC、LTE-V2X以及NR-V2X协议层的区别和联系。 适用范围和趋势 DSRC仅在部分早期部署国家（如日本、欧洲）保留残余应用，而LTE-V2X在中、美、韩等国已成主导技术。C-V2X（尤其是LTE/NR-V2X）凭借技术演进、政策支持和商业成熟度，将在不久的将来全面取代DSRC，成为智能交通和自动驾驶的核心通信标准。 关键技术标准 对于LTE-V2X有一个标准对其做出了总体技术要求：《YD_T 3400-2018 基于LTE的车联网无线通信技术 总体技术要求》，从很大范围的对其总体业务、系统架构以及功能需求做了一些规范性要求。比如说：有效通信距离、移动速度、通信时延、传输可靠性、覆盖要求、消息发送频率要求、消息大小要求、架构模型、接口、功能实体、高层功能、无线功能、标识以及功能描述和消息流等。 附录还有基于LTE车联网应用场景及需求部分，对于一些常见场景，可以了解其场景描述、预期效果和需求分析等内容。主要包含这些场景： 安全应用： 前方静止车辆告警 前方慢速车辆告警 紧急电子刹车灯告警 逆向超车提示 逆向行驶告警 换道决策辅助提示 交叉口防撞提示 异常车辆提示 道路危险状况提示 道路施工告警指示 协作式自动巡航控制 协作式高速公路车辆自动系统（直线） 前向碰撞预警 汇入主路辅助/碰撞告警 紧急车辆提示 非机动车横穿预警/行人横穿预警 道路湿滑/危险路段提醒 左转辅助/告警 闯红灯（/黄灯）告警 交通效率提升 道路限速提示 交通信号灯提醒 交通信息及路线推荐 增强得路线指引和导航 专用道路管理 限行管理 车载标识 车速引导 信息娱乐服务 服务信息公告

学习笔记系列之CAN FD总线。 之前一篇笔记记录了CAN总线基础：https://blog.shuspieler.com/3649/ , 在这继续记录CAN FD的知识。 如果用一句话总结CAN FD和CAN的区别的话，就是为了加大数据吞吐率，在Payload使用了不同的传输频率，头部尾部保持不变，从而在相同的时间长度，传输了更多的数据，就像下图所示。 CAN FD协议需要新的控制器，而新的控制器是兼容老的CAN协议的，也就是说CAN FD控制器可以向下兼容与CAN控制器通信。有时候车身CAN控制器可以混杂部署，比如通过将一部分CAN控制器设置成休眠模式，就可以在CAN FD控制器之间进行高速传输，比如刷新ECU的时候。通常通过CAN需要传输几小时，通过CAN FD就可以大大减少这个时间。 下边是CAN FD和CAN 帧的对比图： 首先是CAN FD没有remote frame这个帧了。也不难想到，首先是这个用的确实不多，其次remote frame没有Data Field，而CAN FD 和CAN区别就在这里，所以remote frame就失去了其意义。在数据帧中，RTR也被换成RRS(Remote Request Substitution)，并且保持显性电位。在帧头的SOF，IDE，以及帧尾的ACK，DEL，EOF以及ITM(Intermission Field)都与CAN总线一致。 CAN FD和CAN的帧主要区别位于IDE和ACK之间。如下图所示，两者的区分是那个r保留位，当r是显性电平逻辑0时候，代表这是一个传统的CAN帧，当r是隐性电平逻辑1时候，说明这是一个CAN FD帧，同时这个保留位r有了一个名字FDF: Flexible Data Rate Format。 CAN FD控制器可以发送和接收传统CAN帧以及CAN FD帧，传统CAN控制器在接收CAN FD帧由于显性电平r是不符合规则从而会报错，然后将通过错误帧应答，也就是说，传统CAN并不能解析CAN FD数据，按照错误帧处理。 CAN FD中有一个新的帧叫做BRS(Bit Rate Switch)，当这一位是显性时，中间部分数据传输速率baud rate 2 和帧头帧尾传输速率baud rate 1 是相同的，这种情况下CAN FD并不能起到加速速率传输的效果。当这一位是隐性时候，中间部分数据传输速率变为 5Mbit/s，这是一个在实验室大量验证证实在绝大多数车身网络这是比较可靠的值。BRS的值决定了中间部分从BRS起到ACK之前的速率。 ESI全称Error State Indicator，这一位是显性代表这个节点是Error Active状态，如果这一位是隐性，代表这个节点是Error

学习笔记系列之CAN总线。 基础知识已经学习过很多次了，可是时间久了对于一些细节的记忆就会模糊不清，每次资料看别人的总结还不如自己也总结一下，之后看自己的笔记就好了。 CAN (Controller Area Network) 在1980年由Bosch提出并于1994年进行了标准化（ISO 11891-1）。时至今日，CAN依旧在汽车动力总成，底盘等领域有着广泛的应用。CAN可以提供非常可靠的数据传输，以及满足很多情况下对于实时性的要求。 CAN标准可以再细分为高速和低速两种不同的子协议，主要区别在于物理层的电压不同从而最大传输速率有区别，低速CAN（CAN Low Speed）遵循 ISO 11891-3 标准，最高传输速率为 125 kbit/s. 高速CAN（CAN High Speed）遵循 ISO 11898-2 标准，最高传输速率为 1Mbit/s。通常我们汽车领域用高速CAN并且设置速率为 500 kbit/s，同时低速CAN也有特有的优势，比如说抗干扰能力强。 下边这张图对比了我们熟知的OSI七层模型和CAN 模型的对比。 通常情况下，CAN协议通过硬件控制器（CAN controller）的形式实现，物理信号的收发通过CAN收发器（CAN Transceiver）进行。通常选择非屏蔽双绞线来连接CAN收发器，传输距离不超过40米，并且在两端需要连接两个120 欧姆的电阻（仅高速CAN，低速CAN不做要求），以防止信号反射造成干扰。协议还规定了，一条CAN总线最多连接32个节点。 由于不同信号有着不同的传输频率的需求比如有的传输周期是10毫秒有的是100毫秒，所以也就催生了CAN控制器（CAN Controller）分为带储存（缓存）型和不带缓存型两种。不过对于上层控制器来说，一致都是将CAN控制器当作一个“储存芯片”对待，从中读出和写入数据。 双绞线可以有效地降低电磁干扰，在CAN总线（CAN Bus）中这两条线分别被称作 CAN high line (CANH) 和 CAN low line (CANL). 在网络物理层基于差分电压传输，这种模式可以有效消除电机，点火系统等开关造成干扰电压冲击带来的影响。 对于高速CAN，协议定义差分电压0伏代表逻辑1，并被称为隐性； 差分电压2伏代表逻辑0，被称为显性。有点绕，但是一定要记清楚！ 关于高速CAN和低速CAN差分电压的规定如下图：   以高速CAN为例子，理解为何差分为2逻辑为1，是显性；而差分为0逻辑为0，是隐性，可以结合下午CAN收发器(CAN Transceiver) 物理实现来理解： 同时显性会覆盖隐性，也就是说，当同一时刻不同的节点有发送显性也有发送隐性，那么在总线上会展示成为显性，只有当所有的节点都发送隐性的时候，总线才会展示成隐性。我是这样记忆的，假设我们有多个TxD，只有所有的Driver都发送逻辑1：隐性，也就是所有上边和下边的三极管都是断开状态（Driver输出0），那么对于Receiver才能测出差分电压为0，单反有一个TxD发送了逻辑0，就是有一对上下三极管是接通状态（Driver输出1），那么CANH和CANL就分别接到了VCC和GND，那么Receiver检测的差分电压就是2V。当然现实情况会有一定的误差，CAN协议规定当差分电压大于0.9伏才能被认为是显性（逻辑1），差分电压小于0.5V才能被认为是隐形（逻辑0）。 对于低速CAN，协议规定差分信号是5V代表逻辑1，差分信号是2V代表逻辑0。根据CAN协议逻辑，可以看出显性和隐性是AND逻辑。就是说有一个发逻辑0（显性），结果就是逻辑0（显性）。 在CAN通信中，节点是以广播的形式发出信息的，所有节点都可以接收，然后根据其中的ID号过滤来确定是否试自己需要的信息。在数据格式上，CAN的Frame共有三种形式：Data

Manifesto for Agile Software Development   We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That