├── AUTOSAR_SWS_CANTransportLayer.pdf ├── DoIP_faltblatt_softing.pdf ├── ISO 15765-2 2016(E)_Third edition.pdf ├── ISO 15765-2(2004).pdf ├── ISO14229 UDS中文翻译版.pdf ├── ISO14229中文.pdf ├── ISO_14229-1_2013.en.PDF.pdf ├── autosar ├── AUTOSAR_EXP_AIUserGuide.pdf ├── AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf ├── CAN_XL_IP_Concepts_Hanser_automotive_202008_PressArticle_EN.pdf ├── CP │ ├── AUTOSAR BswM（BSW模式管理器）.md │ ├── AUTOSAR CAN Driver（CAN驱动程序）.md │ ├── AUTOSAR CAN NM.md │ ├── AUTOSAR CAN Transceiver Driver.md │ ├── AUTOSAR EcuM（ECU状态管理器）.md │ ├── AUTOSAR Ethernet Driver（以太网驱动程序）.md │ ├── AUTOSAR FEE（闪存EEPROM仿真）.md │ ├── AUTOSAR FLS（闪存驱动程序）.md │ ├── AUTOSAR IoHwAb（IO 硬件抽象模块）.md │ ├── AUTOSAR Mirror （总线镜像）.md │ ├── AUTOSAR SecOC (安全板载通信).md │ ├── AUTOSAR Transformer（转换器）.md │ ├── AUTOSAR UdpNm (UDP网络管理).md │ ├── AUTOSAR 模式管理-EcuM模块功能概述.md │ ├── AUTOSAR 通信服务 - NM概念详解.md │ ├── AUTOSAR 通信服务-CanSM概念详解.md │ ├── AUTOSAR 通信服务-ComM概念详解.md │ ├── AUTOSAR 通信服务-Dcm子模块DSD详解.md │ ├── AUTOSAR 通信服务-Dcm子模块DSP详解.md │ ├── AUTOSAR 通信服务-Dcm实例应用.md │ ├── AUTOSAR 通信服务-Dcm概念及DSL详解.md │ ├── AUTOSAR 通信服务-Dcm配置分析.md │ ├── AUTOSAR架构下RH850芯片深度休眠配置实践-Conifig EcuM and BswM.md │ ├── AUTOSAR模式管理-EcuM Sleep and UP详解.md │ ├── AUTOSAR模式管理-EcuM Startup and Shutdown详解.md │ ├── AUTOSAR模式管理-EcuM多核处理及其他概念.md │ ├── AUTOSAR诊断服务－DEM事件Event.md │ ├── AUTOSAR诊断服务－DEM诊断故障码DTC.md │ ├── Full-CAN vs. Basic-CAN.md │ ├── UTOSAR 诊断服务-DEM功能概述.md │ ├── 基于RH850芯片的MCAL详解--MCAL简介及PWM模块详解.md │ ├── 组件 Det未分配给操作系统应用程序.md │ ├── 达芬奇配置器专业版中的 BSW 模块导入.md │ ├── 达芬奇配置器专业版中的 EcuC 文件参考.md │ └── 项目标准配置 （PSC） 在达芬奇配置器专业版.md ├── NM │ ├── AUTOSAR网络管理与TransceiverController关系.md │ ├── Aurix初识Cached和Non-Cached.md │ ├── Autosar以太网：Ethernet Transceiver基础（一）.md │ ├── Autosar开发：CanSM模块如何处理Busoff？.md │ ├── Autosar网络管理优化ECU启动时间切入点.md │ ├── Autosar网络管理，你不能不清楚节点的唤醒方式.md │ ├── Autosar网络管理：Bus Load Reduction Mechanism干啥的？.md │ ├── Autosar网络管理：CAN FD帧能否唤醒网络？.md │ ├── Autosar网络管理：ERAEIRA问题QA.md │ ├── Autosar网络管理：RepeatMessageRequestBit作用，你清楚吗？.md │ ├── Autosar网络管理：一帧有效的网络管理报文是如何唤醒网络的？.md │ ├── Autosar网络管理：你知道ECU如何被供电的吗？.md │ ├── Autosar网络管理：唤醒源的Check和Set.md │ ├── Autosar网络管理：基础问题知多少.md │ ├── Autosar网络管理：确保第一帧是网络管理报文方法.md │ ├── Autosar网络管理：网络管理报文的收发与网络管理时间配置参数解析.md │ ├── Autosar网络管理：网络管理报文真的能保持节点网络状态，不休眠吗？.md │ ├── Autosar网络管理：网络问题QA.md │ ├── Autosar网络管理：节点外发第一帧网络管理报文处理策略，再说一次.md │ ├── Autosar网络管理：诊断报文能否唤醒网络？.md │ ├── Autosar网络管理：问题纠错篇.md │ ├── Autosar通信栈：FullCAN和BasicCAN基础.md │ ├── Autosar通信栈：I-PDU、N-PDU、L-PDU，要掰扯清楚.md │ ├── Autosar通信栈：发送返回OK和发送确认是一回事吗.md │ ├── Autosar通信栈：基础问题知多少(二).md │ ├── Autosar通信栈：基础问题知多少.md │ ├── Autosar通信：网络管理报文和应用报文，谁先发？.md │ ├── CAN总线指定帧唤醒的硬件实现方式.md │ ├── CAN通信基础：Tx Comfirmation、Rx Indication以及Ack.md │ ├── Can Wakeup时序，简单点说（一）.md │ ├── Flexray总线：Frame结构，几张图就能看明白.md │ ├── PN │ │ ├── 1.Autosar网络管理：CanNM PN功能.md │ │ ├── 10.Autosar PN网络管理：PNC信息的收发流程.md │ │ ├── 2.Autosar网络管理PN：路由超时大Bug.md │ │ ├── 3.Autosar网络管理：网管节点路由时间解读.md │ │ ├── 4.Autosar网络管理：没说清楚的PN功能，再说一遍.md │ │ ├── 5.Autosar网络管理：Partial Network基础.md │ │ ├── 6.Autosar网络管理：从CanNM模块看Partial Networking.md │ │ ├── 7.Autosar网络管理：从ComM模块看Partial Networking.md │ │ ├── 8.Autosar网络管理：为什么要网络管理.md │ │ └── 9.Autosar网络管理：PNC = 0，为何不能路由？.md │ ├── PNC │ │ ├── Autosar网络管理：CanNM网络状态机真的全看懂了？.md │ │ ├── Autosar网络管理：CanNmPnResetTime对关联Tx PDU的发送影响.md │ │ ├── Autosar网络管理：Partial Network基础 之 ERAEIRA、PNC Gateway.md │ │ ├── Autosar网络管理：主动唤醒源被动唤醒源与网络主动唤醒被动唤醒的关系.md │ │ └── Autosar网络管理：被动唤醒和Passive Channel QA.md │ ├── 一文讲透AUTOSAR PNC数据流.md │ ├── 从EcuM角度看唤醒源状态切换.md │ ├── 吐血推荐之AUTOSAR网络管理.md │ ├── 网络管理中，这几个概念你清楚吗.md │ ├── 网络管理为什么需要ECU保持激活一段时间.md │ ├── 英飞凌TriCore中断向量表的深度剖析.md │ └── （节点唤醒==网络唤醒）？FALSETRUE.md ├── Security_HSM_Automobil-Elektronik_201808_PressArticle_EN.pdf ├── Vector Davinci官方帮助配置手册（AutoSAR）.pdf ├── rumen │ ├── AUTOSAR入门-汽车电子构架演进（三）通向未来.md │ ├── AUTOSAR入门-汽车电子架构演进（一）ECU和域控制器.md │ └── 汽车电子构架演进（二）AUTOSAR的组成和演进.md └── vector_autosar │ ├── AUTOSAR中的vLinkGen可以干嘛.md │ ├── AUTOSAR初学者最想搞懂的东西.md │ ├── AUTOSAR开发工具DaVinci Configurator里的Modules.md │ ├── AUTOSAR折磨，从新建工程开始.md │ ├── AUTOSAR架构之通信服务.md │ ├── AUTOSAR架构的 Pdu Router.md │ ├── AUTOSAR架构的故事.md │ ├── AUTOSAR的BswM模块详解.md │ ├── AUTOSAR的基本概念.md │ ├── Autosar概念：Callout与Callback，请不要混肴.md │ ├── [Classic AUTOSAR学习] SecOC通信安全模块（入门篇）.md │ ├── 内存管理（Memory）：NVM基础.md │ ├── 解析AUTOSAR Startup.md │ └── 通过Interface来贯穿整个AUTOSAR架构.md ├── canoe ├── CANape_CASL_Manual_EN.pdf └── VN5000_Manual_EN.pdf ├── doip ├── 4. AVB TSN协议介绍.pdf4. AVB TSN协议介绍.pdf ├── AN-IND-1-026_DoIP_in_CANoe.pdf ├── AUTOSAR_SWS_DiagnosticOverIP.pdf ├── DoIP_faltblatt_softing.pdf ├── DoIP协议介绍.pdfDoIP协议介绍.pdf ├── SOA在汽车上怎么用-外发版.pdfSOA在汽车上怎么用-外发版.pdf ├── SOME IP协议介绍.pdfSOME IP协议介绍.pdf ├── 学习模块 AUTOSAR.md ├── 车载TSN设计与实践.pdf车载TSN设计与实践.pdf ├── 车载以太网DoIP协议介绍.pdf ├── 车载以太网（Automotive Ethernet）.md └── 车载诊断标准ISO+13400-3中文.pdf ├── misra-c ├── MISRA C_2012 Guidelines for the use of the C language in critical systems.pdf ├── MISRA C_2012浅析_恒润.pdf ├── MISRA Compliance 2020.pdf ├── MISRA_C_2004中文版.pdf └── MISRA_C_2004英文版.pdf └── 中华人民共和国国家标准_道路车辆 统一诊断服务(UDS).pdf /AUTOSAR_SWS_CANTransportLayer.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/AUTOSAR_SWS_CANTransportLayer.pdf -------------------------------------------------------------------------------- /DoIP_faltblatt_softing.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/DoIP_faltblatt_softing.pdf -------------------------------------------------------------------------------- /ISO 15765-2 2016(E)_Third edition.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/ISO 15765-2 2016(E)_Third edition.pdf -------------------------------------------------------------------------------- /ISO 15765-2(2004).pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/ISO 15765-2(2004).pdf -------------------------------------------------------------------------------- /ISO14229 UDS中文翻译版.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/ISO14229 UDS中文翻译版.pdf -------------------------------------------------------------------------------- /ISO14229中文.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/ISO14229中文.pdf -------------------------------------------------------------------------------- /ISO_14229-1_2013.en.PDF.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/ISO_14229-1_2013.en.PDF.pdf -------------------------------------------------------------------------------- /autosar/AUTOSAR_EXP_AIUserGuide.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/autosar/AUTOSAR_EXP_AIUserGuide.pdf -------------------------------------------------------------------------------- /autosar/AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/autosar/AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf -------------------------------------------------------------------------------- /autosar/CAN_XL_IP_Concepts_Hanser_automotive_202008_PressArticle_EN.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/autosar/CAN_XL_IP_Concepts_Hanser_automotive_202008_PressArticle_EN.pdf -------------------------------------------------------------------------------- /autosar/CP/AUTOSAR 通信服务 - NM概念详解.md: -------------------------------------------------------------------------------- 1 | # AUTOSAR 通信服务 - NM概念详解 2 | 3 | **1.NM简介** 4 | 5 | NM是NetWork Management的简称，是对具体总线网络管理的抽象管理，统管所有总线网络管理。在AUTOSAR BSW 层中，其上层是通信管理模块（ComM）,下层是具体总线网络管理模块（如Can网络管理CanNm，J1939Nm，FrNm，LinNm，UdpNm等） 6 | 7 | 8 | 9 | **2.为什么需要网络管理呢？** 10 | 11 | 网络管理的目的是使ECU中的节点有序的睡眠和唤醒，也就是说休眠唤醒在本质上就是为了节约汽车的电量，特别是在车主下车后断掉高压电后，小电瓶失去高压动力电池充电后，车内所有ECU都需要依赖小电瓶供电，如果所有的ECU同时都在唤醒状态的情况下，那么小电瓶很快就会没电，所以需要将没有通信需求的ECU睡眠，在需要通信的时候才唤醒，可以节约汽车电池的电量。 12 | 13 | 14 | 15 | **3.NM模块与其他模块联系** 16 | 17 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/CJj2CPh6RczdQ18BeT4hLicgCn6584cCXyEAtDWAiakALnasVkLqA2H1bD2VD9eDZxEe3XFqsZwgvqlCzZfG6v8Q/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 18 | 19 | 20 | 21 | BswM:NM可以通过BswM_Nm_CarWakeUpIndication()函数给BswM模块传递模式通知，在BswM中可以自定义模式规则以及模式控制。 22 | 23 | EcuM:在EcuM模块初始化过程中，可以将Nm_Init初始化。 24 | 25 | ComM, CanNm, J1939Nm, FrNm, LinNm, UdpNm :通用网络管理接口模块 (Nm) 为通信管理器 (ComM) 并使用总线特定网络管理模块的服务： 26 | 27 | 包括： 28 | 29 | • CAN Network Management ([3, CanNm]) 30 | 31 | • FlexRay Network Management ([4, FrNm]) 32 | 33 | • LIN Network Management ([5, LinNm]) 34 | 35 | • Ethernet Network Management ([6, UdpNm]). 36 | 37 | • J1939 Network Management ([7, J1939Nm]) 38 | 39 | 40 | 41 | 因为NM和COMM模块关系最为紧密，因此特别说明下NM与COMM的关系。 42 | 43 | | NM variant | 是否能唤醒整车网络 | 下电方式 | 44 | | ----------- | ------------------------ | -------------------------------------------------------- | 45 | | NONE | | 不能通过ComM模块请求休眠，只能通过下电通信总线才能休眠。 | 46 | | LIGHT | | ComM经过请求后，经过一段时间后休眠 | 47 | | PASSIVE | 控制器不允许唤醒总线网络 | 通过请求NM休眠 | 48 | | FULL | 控制器允许唤醒总线网络 | 通过请求NM休眠 | 49 | 50 | 51 | 52 | NM variant是在ComM模块中配置的，表示ComM模块对NM模块的控制方式。 53 | 54 | 1）当NM Variant为Passive或者FULL时，ComM的通道状态改变时，会去同步调用NM的函数请求对应通道的NM状态。 55 | 56 | 2）当NM Variant为FUll时，只有下电时总线通信才会休眠。 57 | 58 | 3）当NM Variant为Light时，ComM模块在接收到NO COMMUNICATION时，经过一个timeout时间后，进入休眠。 59 | 60 | 61 | 62 | **4.NM在网络管理中的作用：** 63 | 64 | 1）网络管理模块作为具体总线管理网络管理模块的公共接口，统管CAN与以太网的网络管理，与ComM模块进行交互。 65 | 66 | 2）协同功能：网络管理模块具有集群协同功能，可以协同同一集群的多条通道进行休眠。 67 | 68 | 69 | 70 | **4.1如何理解NM具有总线管理网络管理公共接口的作用呢？** 71 | 72 | NM模块统管网络管理状态，因此应用层需要控制具体总线的网络管理的状态时，不需要直接调用具体总线网络管理模块的接口（CanNm，J1939Nm，FrNm，LinNm，UdpNm）,只需要调用NM模块提供的公共接口便可控制。在AUTOSAR架构中，NM模块对上将网络管理控制接口暴露给COMM模块进行调用从而控制通信网络管理状态；对下提供接口控制CanNm，J1939Nm，FrNm，LinNm，UdpNm。并且对于回调，Nm 向总线特定的网络管理模块提供通知回调，也就是说，NM模块将提供相应的回调函数给CAN,LIN等网络栈来获取响应网络状态，并调用 ComM 提供的通知回调。 73 | 74 | 75 | 76 | **4.2.如何理解NM模块提供的协同功能呢？** 77 | 78 | 通过配置多条通道（比如can通道）属于一个集群中，网络管理NM模块提供协同一个集群通道所有通道的休眠。 79 | 80 | 在开启协同休眠场景下，只要集群中至少有一条通道仍然属于网络请求状态，协同功能就会让集群中所有的通道都处于工作状态，不会单独休眠。只有集群中所有网络都没有网络请求需求，且没有被请求的需求时，协同算法会协同集群中所有的通道释放网络，开始休眠。 81 | 82 | 83 | 84 | **协同休眠的基本流程为：** 85 | 86 | 1.应用层在通道没有网络请求时，主动释放网络。这一步NM不会真正释放网络，而是进行记录。 87 | 88 | 2.通道在超时时间内没有收到网络请求，具体总线类型网络管理模块（CANNM）会上报NM. 89 | 90 | 3.NM根据协同算法规则，检查到协同休眠唤醒条件满足时，会主动释放网络。 91 | 92 | 4.具体总线类型网络管理模块上报具体总线网络状态。 93 | 94 | 5.NM根据协同算法，判断协同是否完成。同时会将网络状态上报上层管理模块。 95 | 96 | 97 | 98 | **5.协同算法中的唤醒网络与关闭网络** 99 | 100 | 对于某个ECU节点，节点网络的唤醒与关闭不需要NM模块决定，而是依赖于COMM模块决定。 101 | 102 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/CJj2CPh6RczdQ18BeT4hLicgCn6584cCXo4rqt8CA5004UXX3U4NSjXibN4TibvicvUrnlXcktMhxrnOXuvaicQ4diaA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 103 | 104 | **5.1被动唤醒** 105 | 106 | **被动唤醒**：来自总线上其他模块对该模块的网络请求。被动唤醒的节点，发送网络管理报文和应用报文的先后顺序无特别要求。 107 | 108 | ECU上电或唤醒后，如果检测到为远程唤醒或其他添加需要ECU进行passive唤醒时，调用 ComM_EcuM_WakeUpIndication()（如果ECUM中的wakeup source绑定了ComM通道，则在调用EcuM_CheckWakeup()时自动调用），如果通道的NMVariant为FULL或PASSIVE，ComM调用 Nm_PassiveStartUp()请求NM进行passive唤醒，并调用 CanSM_RequestComMode()请求CanSM将相应的Can通道状态切换为FULLCOM。 109 | 110 | 111 | 112 | **5.2 主动唤醒** 113 | 114 | **主动唤醒**：来自模块内部对网络的请求，比如KL15唤醒。主动唤醒节点的网络管理报文必须先于应用报文发送。 115 | 116 | 117 | 118 | ECU上电或唤醒后，如果检测到为本地唤醒或其他条件需要ECU进行主动唤醒时，用户调用ComM接口ComM_RequestComMode（）请求ComM COMM_FULL_COMMUNICATION以使能通信，ComM在接收到请求后，调用 CanSM_RequestComMode()请求CanSM将相应的Can通道状态切换为FULLCOM，CanSM再通过CanIf切换控制器和收发器状态，调用如果该通道的NMVariant为FULL，调用NM接口 Nm_NetworkRequest()，NM再调用CanNM接口 CanNm_NetworkRequest()请求进入主动唤醒。ComM进入COMM_FULL_COMMUNICATION后，可通过BSWM或手动方式，启动相应通道的Com IPdu Groups，通信开始 119 | 120 | 121 | 122 | **5.3 网络休眠** 123 | 124 | 当某个网络通道需要休眠时，调用ComM接口ComM_RequestComMode（）请求COMM_NO_COMMUNICATION以释放通信请求，COMM在接收到请求后，调用 CanSM_RequestComMode()请求CanSM将相应的Can通道状态切换为NOCOM，如果该通道的NMVariant为FULL，调用NM接口Nm_NetworkRelease()请求NM进入sleep，NM在等待总线同步休眠后（其他节点都停发了网络管理报文准备休眠），进入Bus-Sleep状态，反馈给ComM，ComM进入NOCOM状态，如果BswM中配置了ComM模块状态为NO COMMUNICATION就执行ECUM下电动作时，此时ECUM就可以启动下电流程。 125 | 126 | 127 | 128 | **6.API参考** 129 | 130 | | Nm_Init | 初始化Nm模块 | 131 | | ------------------------- | ------------------------------------------------------------ | 132 | | Nm_PassiveStartUp | 被动模式唤醒网络 | 133 | | Nm_NetworkRequest | 主动模式唤醒网络 | 134 | | Nm_NetworkRelease | 释放网络 | 135 | | Nm_DisableCommunication | 关闭Nm PDU传输功能 | 136 | | Nm_EnableCommunication | 打开Nm PDU传输功能 | 137 | | Nm_SetUserData | 设置下一个要发送的Nm PDU中User Data数据 | 138 | | Nm_GetUserData | 获取最近一次接收Nm PDU中的User Data数据 | 139 | | Nm_RepeatMessageRequest | 请求网络状态状态重新进入NM_STATE_REPEAT_MESSAGE | 140 | | Nm_GetState | 获取当前网络状态信息 | 141 | | Nm_NetworkStartIndication | 在睡眠模式下，如果具体总线类型网络管理模块收到Nm PDU，会回调该接口通知Nm模块 | 142 | | Nm_NetworkMode | 具体总线类型网络模块进入Network Mode ，会回调该接口通知Nm模块 | 143 | | Nm_PrepareBusSleepMode | 具体总线类型网络管理模块进入Prepare Bus Sleep Mode，会回调该接口通知Nm模块 | 144 | | Nm_BusSleepMode | 具体总线类型网络模块进入Bus Sleep Mode，会回调该接口通知Nm模块 | 145 | | Nm_PduRxIndication | 具体总线收到Nm PDU的报文，回调该接口通知Nm模块 | 146 | 147 | 148 | 149 | 参考文档：Specification of CAN Network Management 4.3.1 150 | 151 | https://www.autosar.org/nc/document-search/ -------------------------------------------------------------------------------- /autosar/CP/AUTOSAR 通信服务-Dcm子模块DSD详解.md: -------------------------------------------------------------------------------- 1 | # AUTOSAR 通信服务-Dcm子模块DSD详解 2 | 3 | **前言** 4 | 5 | AUTOSAR Dcm模块的分享分为Dcm模块概念详解和Dcm模块配置及代码分析，具体的项目实战请关注本号的后续文章，**本篇为Dcm模块下的DSD子模块概念详解篇**。 6 | 7 | [AUTOSAR 通信服务-Dcm概念及DSL详解](http://mp.weixin.qq.com/s?__biz=Mzg2NTYxOTcxMw==&mid=2247484725&idx=1&sn=37d3cfb72f0567970f89e1a4a43a6c8c&chksm=ce561f5bf921964d1acc9035cb4a1c2a037461da4afd330c2622c8b3fad9b5f7dbc29567cc67&scene=21#wechat_redirect) 8 | 9 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/CJj2CPh6RczjKKkME1spjFy4nYeyiafqQyBYIkKZzu6mqHBVeS7DzGA0WSNh4YvKeOpRNSG6FMlalvgFuC6ZBFA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 10 | 11 | **正文** 12 | 13 | ## **3.3 诊断服务调度层(DSD)** 14 | 15 | ### **3.3.1 DSD功能概述** 16 | 17 | DSD模块主要用于诊断服务的分配、服务执行环境及条件，会从接收的数据识别请求的服务类型(0x10、0x27、0x22)，主要功能： 18 | 19 | **1）检查诊断服务**：用于检查诊断服务执行的条件，如当前会话模式、诊断服务是否支持、安全访问等级。当判断条件不支持是会相应0x7F和具体的NRC否定响应码，通过后会由上一层处理服务(具体处理也可以给出否定响应) 20 | 21 | **2）汇总响应数据**：将判断得到的响应数据或者由DSP发送的响应数据发送给DSL，由DSL向外发送数据 22 | 23 | 24 | 25 | ### **3.3.2 使用场景** 26 | 27 | **1）接收诊断请求信息传输积极响应信息** 28 | 29 | DSD模块接收到诊断请求信息后会校验其有效性（session, security）。这种场景下，数据都是有效的，同时会反馈积极响应。DSD模块会将数据传递给DSP子模块下对于的服务处理器。当DSP子模块下的服务处理器完成了数据处理后会触发DSD模块传输积极响应信息。 30 | 31 | 32 | 33 | 如果数据处理器将服务作为请求指示函数的一部分立即处理，则数据处理器可以在此指示函数(“同步”)中触发传输。如果处理需要较长的时间(例如等待EEPROM驱动程序)，则数据处理器将延迟某些处理(“异步”)。DSL子模块包含响应挂起机制。数据处理器显式地触发传输，但是从数据处理器的上下文中触发的。 34 | 35 | 36 | 37 | 一旦接收到请求消息，相应的DcmPduId就会被DSL子模块阻塞。在此请求的处理过程中，不能再接收其他相同协议类型的请求(例如，增强的会话可以通过OBD会话结束)，直到发送相应的响应消息，并再次释放DcmPduId。 38 | 39 | 40 | 41 | **2）接收诊断请求信息抑制积极响应** 42 | 43 | 这是前一个用例的子用例。在UDS协议中，可以通过在请求消息中设置一个特殊的位来抑制正响应。这种特殊的抑制处理完全在DSD子模块中执行。 44 | 45 | 46 | 47 | **3）接收诊断请求信息抑制否定响应** 48 | 49 | 功能寻址的场景下，DSD模块将抑制否定响应码为0x11,0x12,0x31,0x7E的否定响应。 50 | 51 | 52 | 53 | **4）接收诊断请求信息传输否定响应信息** 54 | 55 | 拒绝请求消息并发送否定响应有许多不同的原因。如果诊断请求无效，或者请求在当前会话中不能执行，DSD子模块将拒绝处理，并返回一个否定响应。 56 | 57 | 58 | 59 | 有许多理由拒绝执行一个格式符合的请求message，例如，如果ECU或系统状态不允许执行。在这种情况下，DSP子模块将触发一个消极的响应，包括NRC提供额外的信息，也就是否定响应的原因。 60 | 61 | 62 | 63 | 对于由多个参数组成的请求(例如，一个UDS Service ReadDataByIdentifier (0x22)请求有多个需要读取的标识符)，每个参数被单独处理。每个参数都可能返回一个错误。如果至少一个参数被成功处理，这种请求将返回一个正响应。 64 | 65 | 66 | 67 | **5）没有接收诊断请求发送积极响应** 68 | 69 | UDS协议中包含两个服务，一个请求发送多个响应。通常，一个服务用于启用(和禁用)另一个服务的事件或时间触发传输，ECU在没有相应请求的情况下再次发送该服务。这些服务包括: 70 | 71 | . 0x2A服务，周期传输诊断响应服务。 72 | 73 | . 0x86服务，基于事件触发的响应服务。 74 | 75 | 76 | 77 | **6）分段响应** 78 | 79 | 在诊断协议中，一些服务允许交换大量的数据，例如UDS Service ReadDTCInformation (0x19)和UDS Service TransferData (0x36)。 80 | 81 | 82 | 83 | 在传统的方法中，ECU内部缓冲区必须足够大，以保存最长的数据消息要交换(最坏的情况)，并在传输开始之前填充完整的缓冲区。 84 | 85 | 86 | 87 | ECU中的RAM内存通常是一个关键的资源，特别是在较小的微型计算机中。在一种更节省内存的方法中，只填充部分缓冲区，传输部分缓冲区，然后再填充部分缓冲区，以此类推。这种分页机制只需要大幅减少的内存量，但需要定义良好的缓冲填充反应时间。 88 | 89 | 用户可以决定是否使用“线性缓冲区”或页面缓冲区进行诊断。 90 | 91 | 92 | 93 | ### **3.3.3 DSD模块和其他模块的交互** 94 | 95 | DSL模块接收到诊断数据后，DSD模块的服务就会被调用，DSD模块将会执行以下的操作： 96 | 97 | 1）委托DSP子模块或Dcm 外的外部模块处理请求。 98 | 99 | 2）跟踪请求处理。 100 | 101 | 3）将应用程序的响应发送给DSL子模块。 102 | 103 | 104 | 105 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/CJj2CPh6RczjKKkME1spjFy4nYeyiafqQYycYASKLK1alahkJYG28cDnEvtLWib9huWahhnxT8nI7rkPhzml6nZw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 106 | 107 | 108 | 109 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/CJj2CPh6RczjKKkME1spjFy4nYeyiafqQxgfF3U2Yn0LoAOlxtCtAJUjGaAhJdN8iacDsFTwXcS67opCOaIXS2ZA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 110 | 111 | 112 | 113 | ### **3.3.4 DSD模块功能描述** 114 | 115 | #### **3.3.4.1 检查诊断服务标识符** 116 | 117 | DSL接收到诊断信息后触发DSD模块去校验诊断信息ID的有效性。DCM模块可以配置当前ECU支持多个诊断ID，不过一般情况下，一个ECU仅支持一个物理寻址ID和一个功能寻址ID，如果收到的诊断信息中的ID信息不是ECU配置好的物理/功能寻址ID，则DCM返回否定响应码NRC:0x11。 118 | 119 | 120 | 121 | #### **3.3.4.2 处理正响应抑制响应位** 122 | 123 | 诊断报文的第二个字节的bit7如果置位1（suppressPosRspMsgIndicationBit = TRUE），DSD模块不用发送积极正响应（抑制正响应）。 124 | 125 | 126 | 127 | #### **3.3.4.3 校验功能** 128 | 129 | DSD模块将会对一个诊断请求做一下6个方面的校验，如果全都通过了才会继续处理诊断请求，否则返回对应的否定响应码。 130 | 131 | **1）制造商许可的校验。**实际项目中基本没有这个校验。 132 | 133 | **2）SID的校验。**服务ID的校验，也就是是否支持当前接收到的诊断ID。 134 | 135 | **3）诊断会话校验。**在诊断配置阶段，会预先定义每个诊断请求在什么会话下才支持。测试时，只有在支持的诊断会话下才会积极响应对应的诊断请求，否则返回NRC:0x7E的否定响应码。所以在诊断请求前，可以先通过0x10服务将诊断会话切换到需要的会话状态，同时通过0x3E服务维持诊断会话。 136 | 137 | **4）安全访问等级的校验。**在诊断配置阶段，会预先定义每个诊断请求在安全等级下才支持。测试时，只有在支持的安全等级下才会积极响应对应的诊断请求，否则返回NRC:0x33的否定响应码。所以在诊断请求前，可以先通过0x27服务将安全等级切换到需要的安全等级。 138 | 139 | **5）供应商许可的校验。**实际项目中基本没有这个校验。 140 | 141 | **6）服务ID的模式规则状态校验。**如果DcmDSD模块引用的DcmDsdSidTabModeRuleRef模式规则不支持当前诊断ID服务或其子服务，则返回否定响应码。 142 | 143 | 144 | 145 | #### **3.3.4.4 检查格式及是否支持子服务** 146 | 147 | DSD模块将会检查接收到的诊断信息的长度是否大于配置的最小长度，不满足则返回否定响应码NRC:0x13。DSD模块将会检查诊断信息的子服务是否支持，如果不支持则返回否定响应码NRC:0x12。 148 | 149 | 150 | 151 | #### **3.3.4.5 将诊断消息分发到DSP子模块** 152 | 153 | DSD子模块应为新接收的诊断服务标识符搜索DSP子模块的可执行功能，并调用相应的DSP服务解释器。 154 | 155 | 156 | 157 | #### **3.3.4.6 组装积极或者消极响应** 158 | 159 | 当DSP子模块完成了重新请求的诊断服务的执行时，DSD子模块将组装响应消息。 160 | 161 | #### **3.3.4.7 开始传输诊断响应** 162 | 163 | DCM模块完成诊断操作后，DSD模块通过调用PduR模块的信息发送接口将诊断响应（积极响应或者否定响应）发送出去。 164 | 165 | 166 | 167 | DSL子模块应将收到的来自PduR模块的确认转发给DSD子模块。 168 | 169 | 170 | 171 | DSD子模块应通过内部函数DspInternal_DcmConfirmation()将确认转发给DSP子模块。 172 | 173 | 174 | 175 | 在没有发送诊断(响应)消息(抑制响应)的情况下，DSL子模块不发送任何响应。在这种情况下，没有数据确认从DSL子模块发送到DSD子模块，但DSD子模块仍将调用内部函数DspInternal_DcmConfirmation()。 176 | 177 | 178 | 179 | 如果Dcm已经完全处理了请求，DSD子模块应该通过调用DspInternal_DcmConfirmation()来完成诊断tic服务调度程序的一条诊断消息的处理。 180 | 181 | 182 | 183 | DSP子模块正在等待DspInternal_DcmConfirmation()功能的执行。所以它必须被发送，也是在没有数据确认提供。总之，这意味着在下列任何情况下: 184 | 185 | .积极响应 186 | 187 | .否定响应 188 | 189 | .抑制积极响应 190 | 191 | .抑制否定响应 192 | 193 | DSD子模块将通过调用DspInternal_DcmConfirmation()来完成。 -------------------------------------------------------------------------------- /autosar/CP/AUTOSAR 通信服务-Dcm实例应用.md: -------------------------------------------------------------------------------- 1 | # AUTOSAR 通信服务-Dcm实例应用 2 | 3 | **正文** 4 | 5 | ## **7.1** **DCM诊断处理流程示例** 6 | 7 | 为了获得安全访问，DSD子模块必须调用DSP子模块来从应用程序获得种子值。如果没有检测到错误，则以积极响应的方式发送种子值。 8 | 9 | 10 | 11 | 在第二步中，DSP子模块得到测试器计算的密钥，并请求应用程序将该密钥与内部计算的密钥进行比较。如果没有发生错误，则在DSL子模块中设置新的访问类型，并发送一个正响应。 12 | 13 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/CJj2CPh6RcxOZM64icq4bytGDE7Y8olVlbtQDbPiaibpG794YZp8n4Q6ibE3BR4LzYqg45HrsRgE2W6DNyHtDRaCjA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 14 | 15 | 从上诉过程可以看出，我们在实际开发过程中需要做的是根据实际需求配置DCM模块（DSL, DSD, DSP），同时还需要设计一个Dcm_User模块来真正处理（processor）诊断请求。 16 | 17 | 18 | 19 | 下面我们就以最常用的诊断服务--**读取软件版本号**为例来说过整个开发流程。 20 | 21 | 22 | 23 | ## **7.2 开发案例分析** 24 | 25 | ### **7.2.1 需求** 26 | 27 | 服务：0x22 28 | 29 | DID：0xF189读取ECU软件版本号 30 | 31 | 数据长度：17个字节 32 | 33 | DID服务只有读的功能 34 | 35 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/CJj2CPh6RcxOZM64icq4bytGDE7Y8olVledAwFTFiaxGb4fa5KHusVGBSGYxmCz6ynpVXM13wricNWDH6gib8YWiarA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 36 | 37 | 也就是上位机机发送：22 F1 89（省略诊断ID和长度信息） 38 | 39 | ECU需要回：52 F1 89 +17字节的软件版本号（14字节的零件号 + 3字节的软件版本号） 40 | 41 | 42 | 43 | ### **7.2.2** **模块接口设计** 44 | 45 | **Dcm模块**：AUTOSAR静态模块，需要配置支持0x22服务下的0xF189服务 46 | 47 | **Dcm_User模块**：所有Dcm服务的一个中转模块，Dcm模块通过Dcm_User模块提供的服务来完成诊断响应，Dcm_User模块和其他各个应用模块连接，使用各个APP模块提供的服务。 48 | 49 | **Vers模块**：提供读取软件版本号的服务，Vers里面需要实现真正的软件版本记录。 50 | 51 | **Interfaces和R/P-Port设计**：如下图所示。 52 | 53 | 54 | 55 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/CJj2CPh6RcxOZM64icq4bytGDE7Y8olVladOnTHibOVHNK1nz1b4WoYmGepXV1icAiaFFCgwwPCbceTS3CSItsHZnw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 56 | 57 | ### **7.2.3配置DCM模块** 58 | 59 | 配置0x22服务 60 | 61 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/CJj2CPh6RcxOZM64icq4bytGDE7Y8olVlVC04bWbf2P8JAia57vmSRkC3qW9HYoqPVhibpThFAkTzqYgvcIOiautWw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 62 | 63 | 配置0xF189服务的数据信息 64 | 65 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/CJj2CPh6RcxOZM64icq4bytGDE7Y8olVlKeO2x0wQfgTU9Uiaqw2ILkktEJicia6aQ0ibfP9U2m4HrG3QsiboXwzPOIQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 66 | 67 | 配置DidInfo，配置完之后，有这种读写属性的DID都可以引用这个DidInfo 68 | 69 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/CJj2CPh6RcxOZM64icq4bytGDE7Y8olVlVTaykYSpv2D00XeJ7ZobkxBw5iaW8pq98MLVGLE2WIQhnQibCFhsfV1g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 70 | 71 | 配F189这个DID的信息 72 | 73 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/CJj2CPh6RcxOZM64icq4bytGDE7Y8olVlWZl0vK8UrdJ2ibYLtxbkibefz4VV1swzGYPASzyKficUUhmrzDfAp8SmQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 74 | 75 | ### **7.2.4配置Interface** 76 | 77 | 配置Dcm和Dcm_User之间数据访问的Interface 78 | 79 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/CJj2CPh6RcxOZM64icq4bytGDE7Y8olVlIl4pgBiaUlrTZ0VQHvX0wjYqweDkibhnas7cqrBN87wQu3BDkLicpKLxA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 80 | 81 | 配置Dcm_User和Ver模块之间的Interface 82 | 83 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/CJj2CPh6RcxOZM64icq4bytGDE7Y8olVl58eHVjtb7pZRKdJKrtmsEWeLwQSehJmJm1WP8B0qcLicXjh7JMuqkUQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 84 | 85 | ### **7.2.5配置Dcm模块的Port信息** 86 | 87 | Dcm模块相对Dcm_User模块是Client端，需要使用Dcm_User提供的服务（Server端），所以需要给Dcm配置数据访问的R-Port。 88 | 89 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/CJj2CPh6RcxOZM64icq4bytGDE7Y8olVlricCuofibhribeMaGicQFEVye6diaicMB3lxYMTZlVyjPlk9icEUEdq2IHWLQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 90 | 91 | ### **7.2.6配置Dcm_User模块的Port信息** 92 | 93 | Dcm_User模块相对Dcm模块是Server端，需要提供服务（Server端），所以需要给Dcm_User配置数据访问的P-Port。 94 | 95 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/CJj2CPh6RcxOZM64icq4bytGDE7Y8olVlwGAXcribCH9WL7QD1P9dpbhxOFhibkT457ic7nTd7G0rmBU2bPwZ7EH8w/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 96 | 97 | Dcm_User模块相对Vers模块是Client端，需要使用Ver模块提供服务（Server端），所以需要给Dcm_User配置数据访问的R-Port。 98 | 99 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/CJj2CPh6RcxOZM64icq4bytGDE7Y8olVlSCoNLUP2oxxNviaCDP6omZ1iaYbuicFTLJ3JqwBIBQAKMfNrleZj8Uz5Q/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 100 | 101 | ### **7.2.7配置Vers模块的Port信息** 102 | 103 | Vers模块相对Dcm_User模块是Server端，需要提供服务（Server端），所以需要给Dcm_User配置数据访问的P-Port。 104 | 105 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/CJj2CPh6RcxOZM64icq4bytGDE7Y8olVlbPgIfEnwWgJWZziaXDVluhJFfWQvONQRz0GHh5Rk03ssbQ44QBkZJnQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 106 | 107 | 108 | 109 | ### **7.2.8生成的代码分析** 110 | 111 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/CJj2CPh6RcxOZM64icq4bytGDE7Y8olVlXYAjXDUmq3GesYptnrn85qMDwArDTcxx4TrKoBJOV4uQfib7Ba6MTVQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 112 | 113 | 114 | 115 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/CJj2CPh6RcxOZM64icq4bytGDE7Y8olVl2dDzXtyIxwxaBgr4LE5dGziaibXuJfn82j9B5VAGVwpicNSQMxXT9MW9g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 116 | 117 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/CJj2CPh6RcxOZM64icq4bytGDE7Y8olVlUC3Ew0rz4H442edn6eEmARx1Qbxoyvv0cXWhxcibiazc8MYrJM6GUWIQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 118 | 119 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/CJj2CPh6RcxOZM64icq4bytGDE7Y8olVlBzPUqlRkyaVDOHthbeDajUp2BB24suiasNszQXmZkV6fMtPVkeCUXnA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 120 | 121 | ### **7.2.9 小结** 122 | 123 | 实际应用中，对DCM模块内部的机制不会太关注，一般是根据实际需求配置DCM模块，然后设计DCM_User等实现模块。而DCM_User等实现模块的设计包括端口Port设计，端口接口Interface的设计，已经具体功能的算法逻辑实现。 -------------------------------------------------------------------------------- /autosar/CP/Full-CAN vs. Basic-CAN.md: -------------------------------------------------------------------------------- 1 | # Full-CAN vs. Basic-CAN 2 | 3 | # 1. 历史 4 | 5 | **Basic CAN**和**Full CAN**这两个词起源于CAN网络的早期。 6 | 7 | 曾几何时**Intel 82526**的CAN控制器为开发人员提供了5个消息缓冲区的**DPRAM**样式的接口。紧随其后的**Intel 82527**具有15个消息缓冲区。 8 | 9 | 然后飞利浦试图降低成本，生产更便宜的版本，从而推出了**82C200**，它由两个接收缓冲区和一个发送缓冲区，当然还有部分掩码匹配过滤。它使用了面向**FIFO**（队列）的编程模型和有限的过滤能力。 10 | 11 | 为了区分这两种CAN控制器，有些人开始将原始的**Intel**的版本称为**Full CAN**，将低成本的**Philips**的版本称为**Basic CAN**。 12 | 13 | # 2. 定义 14 | 15 | 其实在标准规范中并没有关于**Full CAN**和**Basic CAN**的真正定义，只有制造商才有。**Full CAN**实际上应该称为**DPRAM 模式**，因为它底层范例是DPRAM。而**Basic CAN**应该真正称为**FIFO 模式**。同时请注意，**Full CAN**也绝不是比**Basic CAN**更完整的实现了CAN协议。 16 | 17 | 新的CAN控制器扩展了基本功能，例如：它们具有多达32个对象缓冲区作为**Full CAN**的实现，或者它们具有用于多个消息的大型**FIFO**，如:飞利浦**SJA1000**，称为**PeliCAN**，作为**Basic CAN**的实现。 18 | 19 | 使用多个控制器，您可以混合使用这些控制器。它们基本上是作为**Full CAN**实现的，但您可以使用一些对象缓冲区来构建**FIFO**并将它们用作**Baisc CAN**。 20 | 21 | # 3. 哪个CAN控制器最好用 22 | 23 | **Full CAN**和**Basic CAN**其实是CAN控制器架构中的两个不同设计策略。 24 | 25 | **Full CAN**控制器通常具有多个所谓的消息对象缓冲区。接受寄存器可以这样编程，只有一个特定的消息（或一组）被传递到这个对象缓冲区。大多数实现不会在接收队列中缓冲同类的对象消息，这意味着通过接受过滤器的后续消息将替换前一个消息，并且旧消息将丢失。如果两条**ID**相同但数据不同的消息，发送速度非常快（考虑：11位ID，2个数据字节，1Mbit/s, 大概时间为**70us**），CPU必须在第二条消息到达之前，传递消息缓冲区的已接收的内容，否则前一个消息就会被覆盖。 26 | 27 | 典型的**Basic CAN**控制器（飞利浦 **SJA1000**）只有一个接收队列，本身没有消息缓冲区的概念，采用FIFO先入先出的机制。 28 | 29 | 哪个策略更好主要取决于应用程序。如果应用程序使用的不同消息数量比硬件中的消息对象数量缓冲区少，那么**Full CAN**可能是更好些的。如集成了两个CAN控制器，同时这两个CAN控制器可以共享相同的**RX/TX**引脚，那就有32个消息对象缓冲区。但另一方面，如果您想接收到系统中的**所有**消息，不需要相同ID数据被覆盖，您应该使用**FIFO**样式**Basic CAN**的控制器。 30 | 31 | CAN的最大定义速度为**1Mbit/s**，您可能会每隔大约**55 us**（没有数据的帧）获得一次中断。这取决于系统负载（以太网、串行、 PID-loop等）。同时这些设备的所带来的中断延迟和不同的优先级都会造成CAN总线接收影响。 32 | 33 | 新型CAN控制器支持两种方式同时使用，像英飞凌**SAK82C900**这样，使用每个可用的（82C900 上为 32 个）消息对象缓冲区作为类似于**Full CAN**的缓冲区，也可以配置2、4、8、16 或32个消息缓冲区，来构建一个 FIFO 缓冲区。因此它能够同时兼具了两个方案的优点。 34 | 35 | # 4. 总结 36 | 37 | 今天，大多数CAN控制器都允许这两种编程模型，因此没啥理由需要继续使用术语**Full CAN**和**Basic CAN**。事实上，这些术语可能会引起混淆，应该避免使用。 38 | 39 | 当然，**Full CAN**控制器可以与**Basic CAN**控制器通信，反之亦然。不存任何兼容性的问题。 40 | 41 | # 5. 参考信息 42 | 43 | [1] http://www.port.de/cgi-bin/CAN/CanFaqBasicFullCAN 44 | 45 | [2] Difference between Full CAN and Basic CAN Mailbox - KBA86565 -------------------------------------------------------------------------------- /autosar/CP/组件 Det未分配给操作系统应用程序.md: -------------------------------------------------------------------------------- 1 | ## 组件 未分配给操作系统应用程序 2 | 3 | ### 题： 4 | 5 | RTE 生成失败，因为 RTE 生成器引发错误 6 | *RTE13009 - 组件未分配给操作系统应用程序*。 7 | 8 | ### 问题： 9 | 10 | RTE 生成失败，因为 RTE 生成器引发错误 11 | *RTE13009 - 组件未分配给操作系统应用程序*。 12 | 13 | ![img](https://support.vector.com/sys_attachment.do?sys_id=e3ee76f01bf710908e9a535c2e4bcbe9) 14 | 15 | ### 溶液： 16 | 17 | 有两种方法可以解决此问题： 18 | 19 | 1. 为 **BSW 定义一个电子分区** 20 | 1. 打开基本编辑器并创建 **Ecuc 分区收集**子容器（如果不存在） 21 | ![img](https://support.vector.com/sys_attachment.do?sys_id=d00f36f01bf710908e9a535c2e4bcbba) 22 | 2. 至少创建一个**“生态分区” 23 | ![img](https://support.vector.com/sys_attachment.do?sys_id=651ffeb01bf710908e9a535c2e4bcbf4) 24 | ** 25 | 3. 配置所需的 **ASIL** 并选择此分区以执行 BSW 模块 26 | ![img](https://support.vector.com/sys_attachment.do?sys_id=a32f32f01bf710908e9a535c2e4bcb16) 27 | 4. 将 SWC 指定给此分区 28 | ![img](https://support.vector.com/sys_attachment.do?sys_id=e84ffe701bf710908e9a535c2e4bcba6) 29 | 5. 将**“弹性分区”**分配给 BSW 操作系统应用程序 30 | ![img](https://support.vector.com/sys_attachment.do?sys_id=aa5f32f01bf710908e9a535c2e4bcb1b) 31 | 2. 将可运行的虚拟应用程序映射到操作系统应用程序 32 | 1. 创建一个**“设置”容器（**如果该容器不存在） 33 | ![img](https://support.vector.com/sys_attachment.do?sys_id=687f76f01bf710908e9a535c2e4bcbfa) 34 | 2. 创建虚拟 **DetModule** 容器 35 | ![img](https://support.vector.com/sys_attachment.do?sys_id=4e8f7a341bf710908e9a535c2e4bcbe1) 36 | 3. 同步系统或 SWC 描述 37 | ![img](https://support.vector.com/sys_attachment.do?sys_id=e79f76f01bf710908e9a535c2e4bcbf5) 38 | 4. 将可运行的虚拟**报告错误**映射到您的 BSW 任务 39 | ![img](https://support.vector.com/sys_attachment.do?sys_id=44bf7a341bf710908e9a535c2e4bcbe7) 40 | 41 | 42 | 43 | 44 | ### 背景： 45 | 46 | 将 SWC 分配给操作系统应用程序通常基于相关可运行项的映射来确定。默认情况下，Det SWC 不会定义任何可运行的。要克服这种情况，您需要定义一个可映射到操作系统应用程序的虚拟可运行项，或者您需要使用 **Ecuc 分区**将 Det SWC 显式分配给操作系统应用程序。 47 | 48 | 49 | 50 | *** 51 | 52 | 53 | 54 | ## Component Is Not Assigned to an OS Application 55 | 56 | ### Issue: 57 | 58 | The RTE generation fails because the RTE generator raises error 59 | *RTE13009 - Component is not assigned to an OS Application*. 60 | 61 | ![img](https://support.vector.com/sys_attachment.do?sys_id=e3ee76f01bf710908e9a535c2e4bcbe9) 62 | 63 | ### Solution: 64 | 65 | There are two ways to solve this issue: 66 | 67 | 1. Define an 68 | 69 | 70 | 71 | EcucPartition 72 | 73 | for the BSW 74 | 75 | 1. Open the Basic Editor and create the **EcucPartitionCollection** Sub Container if it does not exist 76 | ![img](https://support.vector.com/sys_attachment.do?sys_id=d00f36f01bf710908e9a535c2e4bcbba) 77 | 2. Create at least one **EcucPartition 78 | ![img](https://support.vector.com/sys_attachment.do?sys_id=651ffeb01bf710908e9a535c2e4bcbf4) 79 | ** 80 | 3. Configure the required **ASIL** and choose this partition for the BSW module execution 81 | ![img](https://support.vector.com/sys_attachment.do?sys_id=a32f32f01bf710908e9a535c2e4bcb16) 82 | 4. Assign the Det SWC to this partition 83 | ![img](https://support.vector.com/sys_attachment.do?sys_id=e84ffe701bf710908e9a535c2e4bcba6) 84 | 5. Assign the **EcucPartition** to the BSW Os Application 85 | ![img](https://support.vector.com/sys_attachment.do?sys_id=aa5f32f01bf710908e9a535c2e4bcb1b) 86 | 87 | 2. Map a dummy runnable to an Os Application 88 | 89 | 1. Create a **DetConfigSet** container if it does not exist 90 | ![img](https://support.vector.com/sys_attachment.do?sys_id=687f76f01bf710908e9a535c2e4bcbfa) 91 | 2. Create a dummy **DetModule** container 92 | ![img](https://support.vector.com/sys_attachment.do?sys_id=4e8f7a341bf710908e9a535c2e4bcbe1) 93 | 3. Synchronize the System or SWC description 94 | ![img](https://support.vector.com/sys_attachment.do?sys_id=e79f76f01bf710908e9a535c2e4bcbf5) 95 | 4. Map the dummy **ReportError** runnable to your BSW Task 96 | ![img](https://support.vector.com/sys_attachment.do?sys_id=44bf7a341bf710908e9a535c2e4bcbe7) 97 | 98 | 99 | 100 | 101 | ### Background: 102 | 103 | The assignment of a SWC to an OS Application is usually determined based on the mapping of the related runnables. The Det SWC does not define any runnable by default. To overcome this situation, you either need to define a dummy runnable that can be mapped to an Os Application or you need to assign the Det SWC explicitly to an Os Application using an **EcucPartition**. -------------------------------------------------------------------------------- /autosar/CP/达芬奇配置器专业版中的 BSW 模块导入.md: -------------------------------------------------------------------------------- 1 | ## 达芬奇配置器专业版中的 BSW 模块导入 2 | 3 | ### 问题： 4 | 5 | **BSW 模块**导入有什么好处？ 6 | 7 | ### 答： 8 | 9 | **BSW 模块**导入机制允许从 **DPA 项目或达芬奇配置器专业**版 **DPA** 项目中的其他第三方工具导入基本软件模块的 **ECU 配置** **（****EcuC**） 文件或**基本软件模块**的 ECU 配置。**BSW 模块**作为读写导入一次，并成为配置的一部分。 10 | 11 | 这些文件的导入通过选项**“文件|进口** 12 | 13 | ### 例： 14 | 15 | 导入 **DPA** 项目的 **BSW 模块配置**： 16 | 17 | - **单击导入**或**按住 Ctrl+I**， 18 | ![img](https://support.vector.com/sys_attachment.do?sys_id=4a094f07dbe5a41c4896115e68961957) 19 | 20 | - 选择 **DPA** 项目， 21 | ![img](https://support.vector.com/sys_attachment.do?sys_id=5a09cb07dbe5a41c4896115e6896193c) 22 | 23 | - 选择一个现有的 **DPA** 文件， 24 | ![img](https://support.vector.com/sys_attachment.do?sys_id=1a094f07dbe5a41c4896115e689619fc) 25 | 26 | - 在**“文件选择**”中，选择要导入的 **EcuC 模块配置**。 27 | ![img](https://support.vector.com/sys_attachment.do?sys_id=d6094f07dbe5a41c4896115e689619e7) 28 | 29 | 30 | 31 | 如果**BSW**模块已经存在，则可以使用**替换**<>**合并**机制（通过**比较和合并助手）**) 32 | 33 | ![img](https://support.vector.com/sys_attachment.do?sys_id=d2098f07dbe5a41c4896115e6896192f) 34 | 35 | 36 | 37 | 有关**差异&合并助手**的更多信息，请参阅位于SIP的“`\外部\文档\用户手册`”文件夹中的**DaVinci团队和平台支持**。 38 | 39 | ### 注意： 40 | 41 | 通过此机制导入 **EcuC** 模块，ARXML 文件的内容将成为配置的一部分。因此，如果需要，可以修改导入的内容。如果通过输入文件助手将**EcuC**模块作为**输入文件**导入，**DaVinci配置器**将作为**项目标准配置**（**PSC**）而不是模块导入进行处理。 42 | 43 | 有关 **PSC**的更多信息，请参阅知识库条目[项目标准配置](https://support.vector.com/kb/?id=kb_article_view&sysparm_article=KB0012875)。 44 | 45 | 请注意，模块导入无法通过更新工作流替换从输入文件派生的实际内容。特别是对于通信或诊断数据，请先通过更新工作流导入文件，然后再通过**BSW**模块导入传输手动配置。 46 | 47 | 有关 **DaVinci** 项目配置的更新工作流程的更多信息，请参阅 SIP 文件夹中的技术参考**工作流程概述**。`\external\Doc\TechincalReferences` 48 | 49 | 50 | 51 | *** 52 | 53 | 54 | 55 | ## BSW Module Import in DaVinci Configurator Pro 56 | 57 | ### Question: 58 | 59 | What is the **BSW Module** import good for? 60 | 61 | ### Answer: 62 | 63 | The **BSW Module** import mechanism allows to import an **Ecu Configuration** (**EcuC**) file of a **Basic Software Module** or the **Ecu Configuration** of the **Basic Software Modules** from a **DPA** project or another third party tool in a **DPA** project of **DaVinci Configurator Pro**. The **BSW Modules** are imported once as read-write and become part of the configuration. 64 | 65 | The import of these files takes place via the option **File | Import** 66 | 67 | ### Example: 68 | 69 | Import **BSW Module Configurations** of a **DPA** project: 70 | 71 | - Click **Import** or **Ctrl+I**, 72 | ![img](https://support.vector.com/sys_attachment.do?sys_id=4a094f07dbe5a41c4896115e68961957) 73 | 74 | - select the **DPA** project, 75 | ![img](https://support.vector.com/sys_attachment.do?sys_id=5a09cb07dbe5a41c4896115e6896193c) 76 | 77 | - select an existent **DPA** file, 78 | ![img](https://support.vector.com/sys_attachment.do?sys_id=1a094f07dbe5a41c4896115e689619fc) 79 | 80 | - in **File Selection** select the **EcuC Module Configuration** to import. 81 | ![img](https://support.vector.com/sys_attachment.do?sys_id=d6094f07dbe5a41c4896115e689619e7) 82 | 83 | 84 | 85 | In case that the **BSW** module already exists it is possible to use a **Replace** <-> **Merge** mechanism (via the **Diff & Merge Assistant**) 86 | 87 | ![img](https://support.vector.com/sys_attachment.do?sys_id=d2098f07dbe5a41c4896115e6896192f) 88 | 89 | 90 | 91 | For further information regarding the **Diff& Merge Assistant**, please refer to the User Manual **DaVinci Team and Platform Support** located in the folder “`\external\Doc\UserManuals`” of your SIP. 92 | 93 | ### Note: 94 | 95 | By importing an **EcuC** module via this mechanism the content of the ARXML file becomes a part of the configuration. Therefore, the imported content can be modified if required. If an **EcuC** module is imported as input file via the **Input File Assistant**, **DaVinci Configurator** handles it as a **Project Standard Configuration** (**PSC**) and not as a module import. 96 | 97 | For further information regarding **PSC**s please refer to the KnowledgeBase entry [Project Standard Configuration](https://support.vector.com/kb/?id=kb_article_view&sysparm_article=KB0012875). 98 | 99 | Please be aware that a module import cannot replace the actual derived from input files via the update workflow. Especially for communication or diagnostic data use the file import via update workflow first, before transferring the manual configuration via **BSW** module import. 100 | 101 | For further information regarding the update workflow of a **DaVinci** project configuration, please refer to the technical reference **Workflow Overview** located in the folder `\external\Doc\TechincalReferences` of your SIP. -------------------------------------------------------------------------------- /autosar/CP/达芬奇配置器专业版中的 EcuC 文件参考.md: -------------------------------------------------------------------------------- 1 | ## 达芬奇配置器专业版中的 EcuC 文件参考 2 | 3 | ### 问题： 4 | 5 | 如何在**达芬奇配置器专业**版中使用**EcuC文件参考**？ 6 | 7 | ### 答： 8 | 9 | 假设**我们有用例来**重新利用其他 **DPA** 项目的特定 **MCAL 配置**。 10 | 11 | ![img](https://support.vector.com/sys_attachment.do?sys_id=cf3a0fcbdbe5a41c4896115e6896198f) 12 | 13 | **截流**器文件引用是一个 ARXML 文件，其中包含 **BSW 模块**的**截断器配置**。此机制的目的是允许在**达芬奇配置器专业**版中的**DPA**项目之间共享数据。**EcuC** 文件引用以只读方式加载到现有的 **DPA** 项目中。 14 | 15 | 文件引用只能由其源修改，并且修改由加载 ARXML 文件的 **DPA** 项目自动同步。无法通过**输入文件助手**导入这些文件。这只能通过菜单**添加ECUC文件参考...**或删除**ECUC文件参考...来完成**。 16 | 17 | 18 | 19 | ![img](https://support.vector.com/sys_attachment.do?sys_id=df3acbcbdbe5a41c4896115e68961922) 20 | 21 | 22 | 23 | ### **计算机与计算机辅助控制文件参考** 24 | 25 | **PSC** 和外部 ECU 文件之间的区别在于，**PSC** 允许 **OEM 在** **EcuC 级别提供特定于项目的 EcuC** 元素和**诊断数据**预配置，而文件引用允许在 DPA 项目中重用 EcuC 元素。 26 | 27 | 有关文件参考的更多信息，请参阅《用户手册》第 5.2 章 **DaVinci 团队和平台支持**，该章节位于 **DaVinci 开发人员**安装路径或 SIP 文件夹中。`/Docs/``\external\Doc\UserManuals` -------------------------------------------------------------------------------- /autosar/CP/项目标准配置 （PSC） 在达芬奇配置器专业版.md: -------------------------------------------------------------------------------- 1 | ## 项目标准配置 （PSC） 在达芬奇配置器专业版 2 | 3 | ### 问题： 4 | 5 | 什么是**项目标准配置** （**PSC**）？ 6 | 7 | ### 答： 8 | 9 | **项目标准配置**（**PSC**）是一个ARXML文件，主要由OEM提供，其中包含**基本软件模块**的**ECU配置**（**EcuC**）工件，可以作为输入文件导入**到达芬奇配置器专业版****DPA**项目的**输入文件助手**中。该格式允许 **OEM 在** **EcuC 级别提供特定于项目的 EcuC** 元素和诊断数据预配置。 10 | 11 | 12 | 13 | ![img](https://support.vector.com/sys_attachment.do?sys_id=ebe28f87db65a41c4896115e68961994) 14 | 15 | 16 | 17 | 导入的参数将以只读方式处理。请注意，在导入 **PSC** 文件之前，**PSC** 文件会覆盖用户配置的基本**软件模块**的已存在数据或从输入文件派生的数据。 18 | 19 | 20 | 21 | **合并 PSC** 文件： 22 | 23 | **PSC** 文件是“可拆分的”，这意味着如果格式符合 AUTOSAR 拆分规则，则可以与其他 **PSC** 文件合并。 24 | 25 | ### 注意： 26 | 27 | 不允许在多个 ARXML 文件中导入一个 **BSW 模块**的 **PSC**。**DaVinci配置器**将在**输入文件助手**中显示以下错误： 28 | 29 | 30 | 31 | ![img](https://support.vector.com/sys_attachment.do?sys_id=3be2cf87db65a41c4896115e68961970) 32 | 33 | 34 | 35 | **PSC** 文件中的**电子控制**模块 CAN（“可以”）示例： 36 | 37 | ![img](https://support.vector.com/sys_attachment.do?sys_id=3ad3074fdb65a41c4896115e68961936) 38 | 39 | 40 | 41 | ### 限制： 42 | 43 | SIP 必须提供与 **PSC** 文件模型匹配的 **BSW** 定义 [数据结构]。 44 | 45 | 在**达芬奇配置器专业版**中，可以导出一个或多个**BSW模块的****EcuC**。导出的文件可以作为**PSC**文件导入**到达芬奇配置器专业版**中。 46 | 47 | 在现有的 **DPA** 项目中 48 | 49 | - 转到**文件|出口**， 50 | ![img](https://support.vector.com/sys_attachment.do?sys_id=a3e203c7db65a41c4896115e689619d6) 51 | - 选择要导出的**模块配置**。 52 | ![img](https://support.vector.com/sys_attachment.do?sys_id=ebe203c7db65a41c4896115e6896198b) 53 | 54 | **PSC** 可以作为输入文件导入到另一个 **DPA** 项目中： 55 | 56 | ![img](https://support.vector.com/sys_attachment.do?sys_id=7fe2cf87db65a41c4896115e68961997) -------------------------------------------------------------------------------- /autosar/NM/AUTOSAR网络管理与TransceiverController关系.md: -------------------------------------------------------------------------------- 1 | # AUTOSAR网络管理与Transceiver/Controller关系 2 | 3 | ## **前言** 4 | 5 | 6 | 7 | 在汽车行业CAN总线是应用场景最多的情况，本文也基于CAN总线进行网络管理与Transceiver/Controller关系梳理。 8 | 9 | AUTOSAR NM涉及到的模块包括Transceiver、CAN Driver、CANIf、CANSM、CANNM、PDUR、Com、ComM、EcuM、BswM等。由于模块众多，小编会分多篇梳理。 10 | 11 | 本篇就网络管理和Transceiver、Controler关系理一理。 12 | 13 | ### **网络管理和**Transceiver 14 | 15 | 为什么要谈Transceiver？因为任何上层意图的执行实际都是对底层硬件模块的操作，网络管理也不例外。 16 | 17 | 在讨论网络管理之前，问一个问题，ECU如何供电的？因为只有ECU上电并且程序运行以后才有网络管理。所以**不要混淆ECU****上电和网络管理激活**，ECU上电并不等于网络管理激活。本例以Transceiver1145(1)为例说一下ECU如何上电。 18 | 19 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vycon6gNX1jA16oR4rrevdZRWTIAvfDJtiaB3T9zku1iaQRicB066PkiaDOfnNibO3gmjurVhSYhSibZ83w/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 20 | 21 | 22 | 23 | 如上图，当BAT（等价于KL30，本例不用KL15）给Transceiver1145供电后，Transceiver1145的INH引脚激活3V电源管理模块，进而给主芯片供电，当主芯片供电以后，程序开始运行，但此时网络处于BSM（Bus Sleep Mode），ECU并不能立马外发报文，需要对唤醒事件进行有效性验证，避免因总线抖动或者其他干扰造成的ECU无效唤醒。 24 | 25 | 如果程序（上层模块，如CANNM）想要识别当前是否收到网络管理报文应该具备什么条件？ 26 | 27 | 如果ECU想正常的收发报文需要Transceiver1145和Controller进入各自的工作状态。先说Transceiver1145，对于Transceiver1145需要切换到Normal Mode（通过SPI发送Normal指令），此时Transceiver1145才能将模拟信号和数字信号进行转换；虽然Transceiver1145可以将模拟信号和数字信号进行转换，但是此时ECU还不能将报文传输给上层模块，即此时还不能正常的收发报文，因为Controller没有正常工作，只有当Controller也正常工作以后，ECU才能正常的收发报文。 28 | 29 | ### **网络管理和**Controller 30 | 31 | Controller如何进入正常的工作模式呢？Controller进入到正常的工作模式就需要了解ECU的唤醒过程。本例以Transceiver唤醒检查为例分析ECU唤醒流程。 32 | 33 | 34 | 35 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vycon6gNX1jA16oR4rrevdZ9ztiahcibffSgBtUIEsVib2wE5TyVfCAudJ9rbKjPUibicweC9mAOuibkhKA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 36 | 37 | 38 | 39 | 如上图，Transceiver1145在初始化或者handler程序中检查唤醒源，判断到上电或者CAN总线干扰事件时会通知EcuM有唤醒事件，之后EcuM通过CanIf模块调用CanTrcv_CheckWakeup检查唤醒源。如果EcuM使能了唤醒源的检查，则EcuM调用EcuM_StartWakeupSources接口，该操作的实质是使得Controller进入Start状态，至此Transceiver1145和Controller均进入了对应的工作状态，ECU具备了收发报文的能力。注意，Controller需要从STOPPED状态切换到STARTED状态。 40 | 41 | ## **参考资料** 42 | 43 | （1）IC NXP TJA1145A REV1 23AUG2019.pdf -------------------------------------------------------------------------------- /autosar/NM/Autosar以太网：Ethernet Transceiver基础（一）.md: -------------------------------------------------------------------------------- 1 | # Autosar以太网：Ethernet Transceiver基础（一） 2 | 3 | Transceiver是数字信号与模拟信号转化的物理硬件，如果对使用的Transceiver没有一定的认识，那么在Bug的排查中，往往会有种似懂非懂的感觉，来，认识以太网，从认识Ethernet Transceiver开始。 4 | 5 | **重要提示**，Vector的E-Learning，对总线的入门学习很有帮助，链接： 6 | 7 | https://elearning.vector.com/ 8 | 9 | **名词解释** 10 | 11 | | **Name** | **Description** | 12 | | ----------- | ------------------------------------------------ | 13 | | EC | Ethernet controller | 14 | | ET | Ethernet transceiver | 15 | | **Eth** | Ethernet Controller Driver (AUTOSAR BSW module) | 16 | | **EthTrcv** | Ethernet Transceiver Driver (AUTOSAR BSW module) | 17 | 18 | **以太网基础概念** 19 | 20 | 在连接网口的时候，MDI和MDI-X两种模式要清楚。 21 | 22 | **MDI**(medium dependent interface - II mode):平行模式 23 | 24 | **MDI-X**(medium dependent interface - x mode):交错模式（crossover mode），即发送端的**发送Pin脚**与接收端的**接收Pin脚**连接，一般同种设备（比如：设备都是网卡）使用该方式。 25 | 26 | **回波消除法**：以太网中，两个节点采用**双绞线**传输**对称差分电压**。作为发送节点时，将自己的差分电压施加到双绞线上；作为接收方时，将总线上的差分电压减去自己施加的电压，得到对方节点发送的电压，这就是回波消除法。 27 | 28 | **PHY**：实际嵌入式开发中常说的PHY（Port Physical Layer，端口物理层），即下图中深灰色小块，可以理解为：**连接网线水晶头的接口+Transceiver**。 29 | 30 | **Link**：连接两个节点的PHY。 31 | 32 | 以太网的拓扑结构是点对点结构（Point-To-Point），如果要构成局域网（LAN），则需要用到交换机（Switch），交换机可以有多个PHY，可以连接多个Node，即二层交换。 33 | 34 | 以太网是全双工通信，所以两个PHY之间可以同时发送，不会产生冲突。 35 | 36 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzBNHb6thTTmvftAe71Iq3WBKasoeDTz2ibBe0MZ411bsl9OLRuS8u6x9kLMm5GobUbOwOC6ZmVWUg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 37 | 38 | **Ethernet BSW栈** 39 | 40 | 在Autosar中，Ethernet Transceiver所在的层级如下所示。这里我们要区分硬件层和软件层的概念，比如：ET是指硬件Transceiver，Eth是软件驱动，属于Autosar BSW模块。 41 | 42 | 类似CanIf，EthIf是所有以太网**上层模块获取数据/发送数据**的"必经之路"，很多难解的Bug，可以从这个层级动动脑筋。 43 | 44 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzBNHb6thTTmvftAe71Iq3WxO6bKL1qf6aQKmCGCyHwMLIONe4ibyyvGw3g4ZuGRckFRDawt4oguvw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 45 | 46 | 在Autosar中，不同类型的Ethernet Transceiver索引均从0开始索引，如下所示： 47 | 48 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzBNHb6thTTmvftAe71Iq3WdNRI0vAEUJ5gicTMzcIAhdcPvfNliaBSOFc3eeXqWSkysEp503t4KgWw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 49 | 50 | 在CAN/CANFD、FlexRay等总线中，我们常说Transceiver，而在Ethernet开发中，我们常说PHY。PHY在物理介质和控制器之间，如下所示。 51 | 52 | **MII**:Medium Independent Interface 53 | 54 | **MDI**:Medium Dependent Interface 55 | 56 | **uC**:Host，包含MAC，可以理解为ECU 57 | 58 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vx93YCxWu3SDD9ibLptEKicuU5bqwK6ZZIjgDWL7JFiaJ2FYlLHLscvcL90RW9DrUicwtnJI66DX4tdVQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 59 | 60 | PHY可以集成在uC中，也可以独立在uC之外，实际常用的方式是独立于uC之外，即上图所示集成方式。 61 | 62 | 当通信速率不同时，MDI外接的双绞线数量也将不同，比如1000Mbps，会使用4对双绞线，100Mbps时使用两对双绞线，每对双绞线都是双向传输数据。 63 | 64 | **RTL8211FD(I)** 65 | 66 | Autosar的协议比较简单，我们来了解一下汽车嵌入式使用的一款Ethernet Transceiver:RTL8211FD(I)，这款千兆以太网Transceiver由瑞昱[yù]开发。RTL8211FD(I)对应Datsheet下载链接： 67 | 68 | https://files.pine64.org/doc/datasheet/rock64/RTL8211F-CG-Realtek.pdf 69 | 70 | ## 1、Pin描述/MDI 71 | 72 | 阅读Transceiver Datasheet，先搞清名词： 73 | 74 | | **Name** | **Description** | 75 | | -------- | -------------------------------------------- | 76 | | I | Input | 77 | | O | Output | 78 | | P | Power | 79 | | G | Ground | 80 | | PU | Internal Pull Up During Power **On Reset** | 81 | | PD | Internal Pull Down During Power **On Reset** | 82 | | LI | Latched Input During Power up or Reset | 83 | | IO | **Bi-Directional** Input and Output | 84 | | OD | Open Drain | 85 | 86 | 87 | 88 | ## 2、RTL8211FD(I)结构图 89 | 90 | 91 | 92 | 解读下图信息： 93 | 94 | - MAC的时钟由Transceiver提供，一般MAC集成在主芯片中； 95 | - Transceiver和MAC由外部Vreg供电； 96 | - 外部时钟给Transceiver提供"心跳"。 97 | 98 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzBNHb6thTTmvftAe71Iq3WP5mIsKzv5CWPPcsRz7WdhgHlXoiciclq9DVg5VY90HgR2zqo0XvcTRcA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 99 | 100 | RTL8211FD(I)内部原理图如下所示： 101 | 102 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzBNHb6thTTmvftAe71Iq3WcpneqUV9LkunJ8zb3KcgVLbh4cnMylArUXkRFIgMDZWTt2Olhpw8hw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 103 | 104 | 好了，不能再多说了，吃多嚼不烂，下期更精彩... 105 | 106 | -------------------------------------------------------------------------------- /autosar/NM/Autosar开发：CanSM模块如何处理Busoff？.md: -------------------------------------------------------------------------------- 1 | # Autosar开发：CanSM模块如何处理Busoff？ 2 | 3 | CAN总线中，相对其他通信类问题，Busoff问题比较难搞。本文从CanSM模块出发，就Busoff产生、Busoff信息交互、Busoff快/慢恢复等问题展开聊一聊。 4 | 5 | 这个话题前面有聊过，可以参考前文[Autosar网络管理：说说Busoff那点事](http://mp.weixin.qq.com/s?__biz=MzUyNDU4NTc1NQ==&mid=2247485790&idx=1&sn=edb25567e52d9f4c3f31788033d90b1e&chksm=fa2a572acd5dde3ca104329bda62db64b0b946b3332fe59e137598caf0829a7520479f075a8f&scene=21#wechat_redirect)。 6 | 7 | 1 8 | 9 | Busoff产生 10 | 11 | 这里再说一次Busoff产生的条件：**TEC > 255**。也就是说ECU自身发出的报文错误，导致TEC(Transmit Error Counter)不断累加，直到TEC超过255产生Busoff，如下所示： 12 | 13 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxYWsIOI8qsGYGFJhIM0SRnrOunxs1vsVHtLOZkWIhzT1ZBicnFG4SWxbCQJt5Bw3od4PYO707vrzw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 14 | 15 | **举例**：ECU1::CAN1发送的错误帧只能使ECU1::CAN1进入Busoff状态，而不能使ECU2::CAN1进入Busoff，如下所示： 16 | 17 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxYWsIOI8qsGYGFJhIM0SRnp3N1icZJlrME9dUiatBdSOP5Eib3AvlvKcJ9lJaMFicSJBW9YnSricLSd8g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 18 | 19 | 因为错误由ECU1::CAN1自己产生，ECU1::CAN1有问题，自己脱离CAN总线即可，不要影响ECU2::CAN1继续使用CAN总线。 20 | 21 | 2 22 | 23 | Busoff信息交互及Busoff恢复机制 24 | 25 | 节点产生Busoff以后，ControllerMode状态自动切换到CANIF_CS_STOPED模式，停止发送错误帧，避免影响总线其他节点的通信。既然Busoff已经发生，对应的信息就需要传递给上层，让上层决策后续的通信行为。怎样通知上层呢？ 26 | 27 | Can Controller通知到上层有两种方式：**Interrupt**或者**Polling**。 28 | 29 | ## Step1、Busoff事件信息如何通知到CanSM 30 | 31 | **Interrupt方式：**Busoff中断发生->**CanInterruptStatus()**->CanHL_ErrorHandling()-> 32 | 33 | CanIf_ControllerBusOff()->CanSM_ControllerBusOff()->CanSM_BusOffIndicated()，CanSM_BusOffFlag = TRUE ...CanSM_MainFunction()周期性检查CanSM_BusOffFlag置位情况。 34 | 35 | **Polling方式：****Can_MainFunction_BusOff()**->CanHL_ErrorHandling()-> 36 | 37 | CanIf_ControllerBusOff()->CanSM_ControllerBusOff()->CanSM_BusOffIndicated()，CanSM_BusOffFlag = TRUE ...CanSM_MainFunction()周期性检查CanSM_BusOffFlag置位情况。 38 | 39 | **提示：**上述函数关联关系，除Autosar标准接口以外，其他接口，不同软件供应商，实现上可能存在不同。 40 | 41 | ## Step2、CanSM请求重启Can Controller，通知ComM、BswM模式切换 42 | 43 | Busoff发生以后，CanSM调用CanIf_SetControllerMode()接口，请求将ControllerMode切到CANIF_CS_STARTED模式，以便于后续尝试恢复通信。同时关闭Tx PDU的发送，只能接收Rx PDU。所以这也是为什么在恢复期内可以收到报文的原因。CanSM调用BswM_CanSM_CurrentState()接口通知BswM进入CANSM_BSWM_BUS_OFF状态，调用ComM_BusSM_ModeIndication()接口通知ComM进入COMM_SILENT_COMMUNICATION状态。 44 | 45 | Busoff发生以后，CanSM先告知ComM，ComM在请求CanSM对应Channel由FULL COMMUNICATION进入SILENT COMMUNICATION。进入CANSM_BSM_S_SILENTCOM_BOR状态，如下所示： 46 | 47 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyxvZkHlWF3Z4AysMQuAPiafpiasgcp0tXwmMqaerTUPGkpqricEbAkx80icE7O45OJjFsTXibKTK9icH0A/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 48 | 49 | 50 | 51 | Busoff发生以后，CanSM会启动一个Busoff Timer，Busoff Timer分为两种： 52 | 53 | - **快恢复**时间参数：**CanSMBorTimeL1；** 54 | - **慢恢复**时间参数：**CanSMBorTimeL2**。 55 | 56 | 具体Busoff Timer应该等于CanSMBorTimeL1还是CanSMBorTimeL2，取决于配置参数**CanSMBorCounterL1ToL2**。 57 | 58 | - 如果Busoff连续发生次数 ＜ CanSMBorCounterL1ToL2，Busoff Timer = CanSMBorTimeL1； 59 | - 如果Busoff连续发生次数≥ CanSMBorCounterL1ToL2，Busoff Timer = CanSMBorTimeL2； 60 | 61 | **注意**：CanSMBorTimeL1、CanSMBorTimeL2、CanSMBorCounterL1ToL2三个参数均在CanSM模块配置，具体数值根据OEM需求配置。 62 | 63 | 测试中，busoff的快/慢恢复行为如下所示： 64 | 65 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyxvZkHlWF3Z4AysMQuAPiafWJBuPaoQ58EVELczesibnhXoOlPuqsKtwAh1BxOFKeiaKppfcqmJfCibw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 66 | 67 | 在快/慢恢复时间内，可以接收报文。 68 | 69 | ## Step3、CanSMBorTimeL1或者CanSMBorTimeL2耗尽 70 | 71 | CanSMBorTimeL1或者CanSMBorTimeL2耗尽(elapse)，重新发送Tx PDU，让故障节点再次尝试向CAN总线发送报文。同时，CanSM通知BswM进入CANSM_BSWM_FULL_COMMUNICATION状态，通知ComM进入COMM_FULL_COMMUNICATION状态。可以启动CanSMBorTimeTxEnsured，确认Busoff是否恢复，也可以使用Confirm方式确认Busoff恢复。 72 | 73 | ## Step4、CanSMBorTimeTxEnsured耗尽 74 | 75 | 在CanSMBorTimeTxEnsured时间内，Busoff再次发生，则进行下一次的Busoff恢复机制，如果CanSMBorTimeTxEnsured耗尽，则说明成功从Busoff状态恢复。如果在CanSMBorTimeTxEnsured时间内，再次发生Busoff，则Busoff次数累加。 76 | 77 | 3 78 | 79 | Busoff发生时的网络状态 80 | 81 | 这里主要讨论Busoff进入慢恢复期，节点在NOS(Normal Operation State)和RSS(Ready Sleep State)下是否会进行网络状态切换。 82 | 83 | **NOS**：Busoff进入慢恢复期，如果**上层不主动请求释放网络**，网络状态无法进入RSS，所以，节点会一直在NOS状态下，一直处于慢恢复状态，如下所示： 84 | 85 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vw1H2htERegqYaeZuLibKd8g72J2PjfH9kVlYJdG9QLQjgaAaP9e8vsn21Rdv1Db8PzZCfqOlicrWeQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 86 | 87 | **RSS**：Busoff进入慢恢复期，如果在恢复期收不到有效的网络管理报文，NM-Timeout时间超时以后，进入PBSM(Pre Bus Sleep Mode)；如果可以收到有效的网络管理报文，则网络处于RSS状态，如下所示： 88 | 89 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vw1H2htERegqYaeZuLibKd8g71zGosKDy0lgkGdfRSzcIpTZUn5ib8feWw9Bnwn8ibv8R0lU0mNykZUw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 90 | 91 | 如果节点在NOS状态下，一直处于慢恢复，会带来什么问题呢？节点一直在慢恢复期，意味着该节点不会外报文(应用报文和网络管理报文均不会外发)，其他节点会上报对应的节点丢失故障。 92 | 93 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/quuOyCqONwdD16hI11wAQWxGp4ajJ4DMnbsHGb4ViandFryeibcQb1Idxb3MHmrh20988OSES3OU1wPTicQbAr94g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 94 | 95 | 96 | 97 | 参考资料 98 | 99 | SIMPLE TITLE 100 | 101 | AUTOSAR_SWS_CANStateManager.pdf 102 | 103 | 104 | 105 | -------------------------------------------------------------------------------- /autosar/NM/Autosar网络管理优化ECU启动时间切入点.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理:优化ECU启动时间切入点 2 | 3 | 网络管理测试中会测试第一帧网络管理报文的外发时间，即网络的启动时间。一般需求会明确外发第一帧网络管理报文的阈值时间（TPowerWakeUp），比如：150ms，容差10%，即最大165ms。 4 | 5 | 1 6 | 7 | ECU启动流程 8 | 9 | 10 | 11 | 我们先明确这150ms要耗费在哪里，ECU从被供电到程序稳定运行会经过硬件启动->Boot启动->Boot运行->App启动->App运行这几个阶段，如下所示： 12 | 13 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxlibbiaKP6OTU9xGy5Z5zibk0oPHLoBydMWrZWMVKTyDnfl73YicXROiaFu1ESMMOcGXGKiczUwZnicfGhg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 14 | 15 | **HW Startup**:此阶段完全由硬件特性决定，软件层面没有优化余地。此阶段包括VCC供电（比如：KL15上电），之后ECU对应的5V、3.3V及1.25V电源管理模块上电。5V一般给IO使用，3.3V一般给Flash使用，1.25V一般给CPU内核使用。 16 | 17 | **Bootloader Startup**：此阶段一般是Bootloader使用外设资源的初始化，比如IO、System Timer、CAN等模块的初始化。 18 | 19 | **Bootloader running**：此阶段，会判断程序是否需要更新，如果没有程序需要更新，Boot程序会停留一段时间，比如：20ms，这就是前面聊的Stay In Boot功能，可以回顾[UDS之刷写：你真清楚Application和Bootloader如何沟通？](http://mp.weixin.qq.com/s?__biz=MzUyNDU4NTc1NQ==&mid=2247485129&idx=1&sn=fa7581856d36a274aebcf664cbc7cfa8&chksm=fa2a58bdcd5dd1aba9ffafebd62dd754ee851f9d839c3c986d746f00493828bc1b16a271e5ae&scene=21#wechat_redirect)，因此Stay In Boot耗费的时间无法避免。 20 | 21 | **HW,OS,Application Startup**：此阶段包含应用所需外设资源的初始化，OS的初始化以及各软件模块初始化。 22 | 23 | **提示**：如果Boot程序是security boot，可能耗费的时间更长，当然需求也会明确security boot的启动时间。 24 | 25 | 26 | 27 | 2 28 | 29 | TPowerWakeUp测试步骤 30 | 31 | 1. 关闭网络仿真（上位机不模拟网络管理报文发送），关闭供电电源； 32 | 2. 开启供电电源（一般指KL15上电），触发DUT在该网段上通信（硬线唤醒或者网络唤醒）。当KL15电压达到6V时作为起始时间，MCU通常为5V供电，将此刻记为T1； 33 | 3. 等待DUT在该网段发送第一帧报文，将此刻记为T2； 34 | 4. 检查是否(T2-T1) < TPowerWakeUp。 35 | 36 | 3 37 | 38 | 工程实例 39 | 40 | 在这里分享一个工程Bug实例：测试 TPowerWakeUp时，在没有security boot情况下，TPowerWakeUp高达200ms，远大于150ms。实际测试TPowerWakeUp＜165ms即可，要考虑10%偏差。 41 | 42 | **问题解决切入点**： 43 | 44 | ## 1、SPI速率使用不当带来的延时 45 | 46 | CAN模块对应的收发器使用的是NXP TJA1145，该收发器需要通过SPI控制其模式切换。问题出现前使用的波特率是100Kbps，通过提高通信速率，**优化了＞30ms时间**。NXP TJA1145速率提升到4Mbps，查阅其用户手册可以看出，NXP TJA1145在Normal/Standby模式下，其时钟周期可以配置为4Mbps(1/250ns = 4000000Hz)。如果考虑Sleep Mode，至少也可以配置1Mbps，这样也能提升10倍通信速率。 47 | 48 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxlibbiaKP6OTU9xGy5Z5zibk03dyiaKibXpmqMeu4JagCvAnz7IK1Tc2Sd1jktpSm8Nia0UWWjplyEzTpg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 49 | 50 | ## 2、PORST Pin配置参数修改 51 | 52 | 一般来说，ECU从被供电那一刻，即VCC（12V）供电，VCC会瞬间拉到稳定，几乎不耗费时间。而5V、3.3V、1.25V一般在同一时间点，电压开始爬升，耗费的时间相差不大，一般会在几个ms量级，即T1时刻，比如3ms左右。这几个电压耗费的时间是物理特性，没有优化余地。但是PowerOnPin这个电压值可能由配置决定，通过修改外围供电芯片可修改该Pin的供电时间。我在项目实际中确实碰到了这样的设计，通过配置外围芯片配置，PowerOnPin的供电时间由十几ms降低到3ms左右，又优化了近10ms的启动时间，即优化T2时间。 53 | 54 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxlibbiaKP6OTU9xGy5Z5zibk0es1x7ZT03ysxGEYmaUMtvCzpQ3b8oLnBictZqGgHAtyVibFia07avbc4Q/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 55 | 56 | 综上所述，带来的思考点有： 57 | 58 | 1. 使用了SPI的外围器件，先确定其最大支持的通信速率，横向对比，使用UART的地方是否也可以提高通信速率； 59 | 2. 特定器件的配置是否设计时间配置。 60 | 61 | 最后说一下，这些时间是如何测量的，本文在目标代码位置反转IO电平状态，使用示波器测量，这样即可知道代码，函数耗费时间情况，进而针对性的优化。 -------------------------------------------------------------------------------- /autosar/NM/Autosar网络管理，你不能不清楚节点的唤醒方式.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理，你不能不清楚节点的唤醒方式 2 | 3 | 我想玩Autosar嵌入式开发的朋友都知道，Autosar中有NM模块，也知道为什么要有网络管理，但是大家未必都能说清楚节点（Node）的唤醒方式，本文通过分析节点供电方式、网络唤醒源来聊聊节点的唤醒方式。 4 | 5 | 6 | 7 | 唤醒源 8 | 9 | 10 | 11 | 开发的过程中，提到网络管理，我们首先就得明确唤醒源有哪些，如果搞不清，查bug可能有的折腾。一般来说，唤醒源会分为本地唤醒源和远程唤醒源。前面已经说过，唤醒源能唤醒ECU，而未必能唤醒网络，**唤醒ECU是唤醒网络的必要不充分条件，**可以参考前文：**[（节点唤醒==网络唤醒）？FALSE:TRUE；](http://mp.weixin.qq.com/s?__biz=MzUyNDU4NTc1NQ==&mid=2247483765&idx=1&sn=eddd18684737ed67aff7da4b7b6bd501&chksm=fa2a5f01cd5dd61735d991cf0e4a34a14d8fbb6f81274e5f8c96a6cf93ad5c80b363c6d06c25&scene=21#wechat_redirect)**。如下说一下个人对两种类型唤醒源的理解。 12 | 13 | - **本地唤醒源：**和硬线相关的唤醒方式一般称为本地唤醒源。如：KL15硬线，硬件传感器信号（如：脚踢门，后备箱打开）。 14 | - **远程唤醒源：**简单说就是和总线信号相关的唤醒方式。比如收到网络管理报文或者指定诊断报文，或者包含KL15信号的应用报文（有些节点没有KL15硬线，而是网关转发包含KL15信号的应用报文唤醒）。 15 | 16 | 遇到过一种不常见的唤醒方式（确切说我遇到的少），这里和大家聊一聊。比如节点A所在uC是ECU1，有一个外围芯片ECU2控制Vreg，进而控制ECU1的供电。这里使用ECU2主要是想在**ECU1休眠时，定时唤醒ECU1，比如ECU1休眠5h后，自动唤醒ECU1**。这里可以将此种方式理解为本地唤醒源。这里会利用ECU2的定时功能，该功能一般会在ECU1进入休眠前通过SPI设置唤醒时间，定时时间到，触发Vreg给ECU1供电，进而ECU1上电，主程序启动（Application Program）。 17 | 18 | 该唤醒方式的示意如下所示： 19 | 20 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vw6CYLS0fo1ib3icoa8yHibMdnKW1XJbwbJuh3Fth4D4H10S144libliaeTIuOndrTrdRXiazqvzo7HErsg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 21 | 22 | 在实际的Autosar NM开发中，大家一定要和系统沟通清楚本地唤醒源和远程唤醒源的定义，以及这些唤醒源有哪些，因为这些在问题排查时是大有裨益的。 23 | 24 | 25 | 26 | 节点类型 27 | 28 | 29 | 30 | 一个ECU中包含多个节点（Node），这个大家要清楚，不要将ECU和节点混为一谈。举例来说：一个ECU有3路CAN，2路Flexray，1路Ethernet，应该说该ECU有6个节点。也可以具体说，该ECU有3个CAN节点，2个Flexray节点，1个Ethernet节点。总之，在表述的时候要尽可能准确，他人在表达不到位的情况下，我们也要知道ta表达的真实意图。 31 | 32 | 一般来说，可以根据节点的**启动方式**、**静态电流的消耗**以及**启动时间**分为4种唤醒方式，这里分为A、B、C、D四种类型。**提示：图片可以放大看**。 33 | 34 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzAbPgJQM0LoibPicVwEUCrKcjicc9NJ0pzAX2pHbHuWh95jhRJW01ScIj4eTlQJ5un8TaGR8ZN8298g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 35 | 36 | 也有按照唤醒源组合方式分类的说法，即**本地唤醒源和远程唤醒源组合成四种唤醒方式**。如下说说这四种类型节点网络唤醒的方式。 37 | 38 | **Node TypeA：** 39 | 40 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzAbPgJQM0LoibPicVwEUCrKcY5zGfOBDGCAfhn2F0IoErAPFjKpltunTthWnZA0dDpicG1WYiaAIibcwA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 41 | 42 | 这种类型的节点常连KL30（俗称小电瓶，即长电），即使车辆停车和点火钥匙关闭时，该种类型的节点也有唤醒网络的能力。一般这样的节点在不通信的时候会进入低功耗模式，不是说完全的掉电，而是将电流限制在一定阈值下，如100uA，同时支持通信网络唤醒和重新启动应用程序的能力。主要是关闭掉不必要的外设使得电流降低。但是应用程序在保持周期性运行（这个轮询的周期不必太大），以便有网络请求时能快速唤醒ECU和网络。如果收到远程唤醒源的唤醒请求，Transceiver会使能Vreg给uC供电，进而使得ECU唤醒，**ECU唤醒以后再进一步判断收到的远程唤醒源是否是有效的网络唤醒源**（比如：网络管理报文），如果不是则ECU走下电流程，网络没有唤醒；如果是有效网络唤醒源，则唤醒网络。 43 | 44 | 需要注意的是，有些节点如果有PNC功能，即使收到NM报文，也未必唤醒该节点网络，必须是该节点指定的NM报文。 45 | 46 | **Node TypeB：** 47 | 48 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzAbPgJQM0LoibPicVwEUCrKcRDOibqc71QUKJwMv4364YH4qR8Efib4Q900qK8iaerx0M3Xic1JPRW2Z1Q/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 49 | 50 | 这种类型的节点常连KL30，可以通过硬线和网络总线唤醒，即这两种方式均可以使得uC供电，即ECU唤醒。如果是硬线唤醒，如KL15硬线，网络直接唤醒；如果是网络总线唤醒，则需要进一步判断唤醒源的有效性，即网络不一定唤醒。一般来说，该节点休眠时会将transceiver的工作模式设置为Sleep Mode，当然，这需要看transceiver是否有Sleep Mode。以CAN Transceiver为例，NXP TJA1145有Sleep Mode，可以通过SPI设置其进入该模式。而NXP TJA1143则没有，一般会进入Standby Mode，即伪Sleep Mode。 51 | 52 | **Node TypeC：** 53 | 54 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzAbPgJQM0LoibPicVwEUCrKck8IJo80GxhTw6kOfUawBJccBgmDhGia9bMr9auQYDD6nKJicFeqfbyog/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 55 | 56 | 这种类型的节点常连KL30，可以通过硬线唤醒。相对于Node TypeB，Node TypeC在网络休眠时更节能，因为可以完全将Transceiver供电切断。 57 | 58 | **Node TypeD：** 59 | 60 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzAbPgJQM0LoibPicVwEUCrKcgiayxxgTROWtgYSQOibhHN29ZuGv7GlF61FTThJYEqlqN7v1H6AWedpg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 61 | 62 | 这种类型的节点不常连KL30，受控于KL15硬线，如果KL15断开则整个主芯片以及Transceiver均断电，而无法工作。相对其它唤醒方式，这种节点的网络启动时间要更长，因为uC和Transceiver均是冷启动。 63 | 64 | 65 | 66 | 写在最后 67 | 68 | 69 | 70 | 嵌入式Autosar开发中，如果是作为供应商的角色，在拿到OEM或者甲方需求时，要清楚自家产品的唤醒方式，而这需要看一下自家产品的原理图和使用的uC、Transceiver类型才能更好的开发符合需求的Code。 -------------------------------------------------------------------------------- /autosar/NM/Autosar网络管理：Bus Load Reduction Mechanism干啥的？.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：Bus Load Reduction Mechanism干啥的？ 2 | 3 | 是不是觉得：Bus Load Reduction Mechanism有点眼熟，又一时想不起是干啥的？确实，该功能在实际的网络管理开发中，使用较少。但是，我不能揣着糊涂装明白，该功能的idea还是值得一学。 4 | 5 | 1 6 | 7 | Bus Load Reduction Mechanism应用背景 8 | 9 | 为什么要有Bus Load Reduction Mechanism呢？我们先看这样一种情况：假设总线有3个节点，Node1、Node2、Node3，三个节点的发送周期均为70ms。不使用Reduced Bus Load功能，在NOS状态下，总线上NM Msg的发送行为如下所示： 10 | 11 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vw9ibXRHBCeuBNFlINNI7iatKgMvxgrl9C3F6mfUgm5pY05h72PaGwlMUiappr0spuxLgh12OGxNuC5g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 12 | 13 | 上图可以看出：总线上的NM Msg发送密度大，会占用一定时间的总线使用权。如果一个网段内的主动网络节点过多，且在NOS状态均发送各自的NM Msg（主动唤醒网络），势必会加大总线的负担。为了确保功能算法的可靠性，App Msg及时被接收和处理，所以，应尽可能地将总线使用权让给App Msg，在网络可以保持的前提下，尽可能地减少NM Msg的发送密度，进而避免过多的抢占App Msg使用总线，这就是Bus Load Reduction Mechanism出现的背景。 14 | 15 | 2 16 | 17 | Bus Load Reduction功能 18 | 19 | 假设：总线有3个节点，Node1、Node2、Node3，三个节点的发送周期均为70ms。Node1 CANNM_MSG_REDUCED_TIME = 40ms，Node2 CANNM_MSG_REDUCED_TIME = 50ms，Node3 CANNM_MSG_REDUCED_TIME = 60ms。使用Reduced Bus Load功能时，总线上NM Msg的发送行为如下所示： 20 | 21 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vz61MSGh783RU11ykwlXC0lA2yelgBTTYZxkN0fhqBWPtRdjeQuyreW0emP63XrPK31DAanJUDMsQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 22 | 23 | 对比不使用Bus Load Reduction Mechanism，使用Bus Load Reduction Mechanism时，总线上的NM Msg发送密度极大的降低，让出了一定时间的总线使用权。 24 | 25 | 3 26 | 27 | Bus Load Reduction功能特点 28 | 29 | 使用Bus Load Reduction Mechanism需要注意什么呢？ 30 | 31 | - Bus Load Reduction Mechanism在**NOS状态下使用**。在RMS状态下，为了快速唤醒网络，某些节点存在快发行为，所以，RMS状态不使用Bus Load Reduction Mechanism； 32 | - 同一网段内，每个节点CANNM_MSG_REDUCED_TIME应**不同**，否则不能达到降低NM Msg发送密度的目的； 33 | - 同一网段内，主动外发NM Msg节点的数量大于2个时，只有CANNM_MSG_REDUCED_TIME最小的两个节点外发NM Msg，比如：上例中，最小的两个CANNM_MSG_REDUCED_TIME，分别对应Node1和Node2，所以进入NOS状态时，Node1和Node2先发送各自的NM Msg，当Node1停发以后，Node2和Node3再交替发送各自的NM Msg； 34 | - 节点每次**接收到**其他节点的NM Msg时，下一次NM Msg的发送时间Timer重载CANNM_MSG_REDUCED_TIME（本例：Node1为40ms，Node2为50ms，node3为60ms）。如果节点**每发送**一次NM Msg，下一次的发送时间Timer重载CANNM_MSG_CYCLE_TIME（本例：70ms）。 35 | 36 | 使用Bus Load Reduction Mechanism，**节点NM Msg的发送周期≥ CANNM_MSG_CYCLE_TIME**，这也是总线NM Msg密度会降低的原因。所以，CANNM_MSG_REDUCED_TIME需要满足一定的约束条件，即：1/2CANNM_MSG_CYCLE_TIME＜CANNM_MSG_REDUCED_TIME＜CANNM_MSG_CYCLE_TIME。如果该约束条件满足不了则达不到降低总线NM Msg发送密度的目的。 37 | 38 | ## 1、CANNM_MSG_REDUCED_TIME＜1/2CANNM_MSG_CYCLE_TIME 39 | 40 | 假设：Node1 CANNM_MSG_REDUCED_TIME = 20ms，Node2 CANNM_MSG_REDUCED_TIME = 30ms，Node3 CANNM_MSG_REDUCED_TIME = 40ms。三个节点的外发周期均为70ms，Node1和Node2的CANNM_MSG_REDUCED_TIME不满足约束条件。总线上NM Msg的发送行为如下所示： 41 | 42 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vw9ibXRHBCeuBNFlINNI7iatKLRmsKDNQ6hf024OfVjUafDb9RTLhDl3PN1ePZWibJmuAWGeiaOVDxJDA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 43 | 44 | 由上可以看出，Node1和Node2的NM Msg发送周期为50ms，比正常发送周期CANNM_MSG_CYCLE_TIME（70ms）小，总线上NM Msg的发送密度不是最优的工况。 45 | 46 | ## 2、CANNM_MSG_REDUCED_TIME＞CANNM_MSG_CYCLE_TIME 47 | 48 | **假设1**：Node1 CANNM_MSG_REDUCED_TIME = 40ms，Node2 CANNM_MSG_REDUCED_TIME = 80ms，Node3 CANNM_MSG_REDUCED_TIME = 90ms。三个节点的外发周期均为70ms，Node2和Node3的CANNM_MSG_REDUCED_TIME不满足约束条件。总线上NM Msg的发送行为如下所示： 49 | 50 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vw9ibXRHBCeuBNFlINNI7iatK5P4fdDu5U9v6XK6BR0Kf7axOXapNponUKd6sWc8bKib5FZ5DEYOcgYQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 51 | 52 | 如上，总线上NM Msg的发送行为也起到了降低NM Msg发送密度的目的，且节点各个状态也能保持通信状态，这只能说此配置恰巧合适，没有引发问题。 53 | 54 | **假设2**：Node1 CANNM_MSG_REDUCED_TIME = 40ms，Node2 CANNM_MSG_REDUCED_TIME = 80ms，Node3 CANNM_MSG_REDUCED_TIME = 10s。三个节点的外发周期均为70ms，Node2和Node3的CANNM_MSG_REDUCED_TIME不满足约束条件。总线上NM Msg的发送行为如下所示： 55 | 56 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vw9ibXRHBCeuBNFlINNI7iatKSgonfIk81B21RSjtQWWhVTAYdm2wJ8cTpxTicEqeg4GzoMz9dibS3Viag/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 57 | 58 | 如上，t0时刻，Node1、Node2已停发NM Msg。10s以后，在t1时刻，Node3外发NM Msg。如果NM-TIME OUT = 3000ms，在t1时刻，Node1和Node2因接收不到NM Msg，早已经休眠，而Node3此时发送NM Msg，不仅会引起总线上节点网络状态紊乱（Node3在NOS状态，Node1、Node2进入RMS状态），还可能导致Node3节点误报Node1和Node2通信故障（没有收到Node1、Node2的应用报文）等。 59 | 60 | 4 61 | 62 | 实际工程应用 63 | 64 | Bus Load Reduction Mechanism功能可能在实际的工程上使用不多，不过，还是建议大家了解一下。一般来说，EE在设计整车拓扑架构时，一个网段内的节点不会过多（比如：不超过16个），还有就是一些节点可以设计成Passive网络类型，也可以减少网段内NM Msg的发送密度。 65 | 66 | 随着域控和中央大脑的兴起，部分节点功能会被移植到域控制器或者中央大脑控制器中，节点的数量可能会有所减少，Bus Load Reduction Mechanism或可不用。 -------------------------------------------------------------------------------- /autosar/NM/Autosar网络管理：CAN FD帧能否唤醒网络？.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：CAN FD帧能否唤醒网络？ 2 | 3 | 如标题问题，你能给出具体答案吗？这个问题源于Autosar群内小伙伴的讨论，先说一下我的答案：不能。这有点打脸我之前的说法，先给读者说声抱歉。本文就这个问题，深入讨论一下。 4 | 5 | 1 6 | 7 | 11898-2中的WUF(wake-up frame)定义 8 | 9 | 11898-2规定：Transceiver识别有效WUF(wake-up frame)时，**首先要识别该CAN Frame是否是Classical CAN Frame**，也就是说：Transceiver接收到CAN FD Frame，不能作为有效的WUF。有效WUF检查的condition如下所示： 10 | 11 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyJLz1icZMHMXQ3ZudfEU5k4EicIsYy2OxKB4AttHFeVdics4UxHLwDKJUANNSCeDtLwiaQiaw2Ezyswsg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 12 | 13 | 2 14 | 15 | TJA1145手册中的WUF(wake-up frame)定义 16 | 17 | TJA1145手册中，在描述CAN FD的部分也明确说明CAN FD帧不能作为有效的唤醒帧。意思就是说：即使收到CAN FD类型的网络管理报文也不能唤醒网络，会被忽略，如下所示： 18 | 19 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyJLz1icZMHMXQ3ZudfEU5k4X3NyUT1MXN6tpc0IeP0OuT1YpPGYMSuxgTeOSVfov8X37PibVwpYibeg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 20 | 21 | 一般来说，uC的供电受控于Transceiver。而Transceiver控制对应的电源模块时，首先要收到Wakeup Pattern，之后才能触发唤醒事件，进而使能供电模块，uC被供电。对于1145 Transceiver的Wakeup Pattern分两种情况讨论： 22 | 23 | ## 1、Standard Wake-up Pattern 24 | 25 | Standard Wake-up Pattern唤醒时序如下所示： 26 | 27 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyJLz1icZMHMXQ3ZudfEU5k4sXbgqS8IlWco611uwZ3k6gzlHFRESb7SEDJxd57hIgsC89h3fJzicmA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 28 | 29 | 怎么理解呢？只要满足上图的电压时序变化就能触发Transceiver的唤醒事件，进而供电模块工作，uC供电，这也是为什么**任意一帧报文都能唤醒ECU的原因**，注意：网络此时未必唤醒，软件需要进一步识别是否收到有效唤醒源。同理，对普通的Transceiver（比如：1045），也是任意一帧报文（CAN/CAN FD均可）均能唤醒ECU。 30 | 31 | 再进一步分析，如果能模拟出Standard Wake-up Pattern，不用发送报文也能触发唤醒，比如：极端天气情况，Transceiver的抗电磁干扰能力又不行，也可能触发唤醒。 32 | 33 | ## 2、WUF，Partial Networking使能 34 | 35 | 此种方式需要Transceiver支持partial networking功能，即：只能特定的报文触发唤醒，比如：目前使用率比较高的1145。 36 | 37 | 这需要ECU在断电前，设置好1145的PN唤醒功能，即：设定可以唤醒的网络管理报文。这也是目前使用1145常用的做法，不然买1145干啥呢？ 38 | 39 | 能否将CAN FD类型的网络管理报文作为有效的WUF呢？我的理解：软/硬件都可以实现。但是为什么硬件不支持呢？这个可能需要从商业化的视角看，做工程，需要产出和效益，不可能顶着亏损为某种特殊功能而做产品。不管何种工业产品，都会遵循标准和规范。既然11898-2这种国际规范都没有说CAN FD帧可以作为有效的WUF，至少Transceiver的生产商不会将其作为一种附加功能生产。如果增加CAN FD帧作为有效的WUF，那么产品的成本会增加，产品成本增加，会转嫁到客户身上，而客户又不需要这样的功能（或者一小部分客户需要），为什么要买这样的产品呢？如果某个客户的需求量大，而且会有持续的需求，可以和Transceiver的生产商谈，为这样的客户单独供货。 40 | 41 | 所以，短期内，硬件实现CAN FD帧唤醒网络还不现实，或许随着技术的迭代，支持CAN FD的Transceiver成本和普通Transceiver成本相差无，支持CAN FD的Transceiver淘汰普通Transceiver时，CAN FD帧作为有效WUF会提到日程上，并且对应的规范也将其补充进来。这也许不会太远，因为CAN XL规范都已悄然到来，CAN XL的吞吐量(最高2048 bytes)和速率(10Mbps+)值得期待。 42 | 43 | 3 44 | 45 | 工程问题思考 46 | 47 | 网络管理部分，在实际的项目中，大家是否遇到过网络管理报文是CAN FD类型的？目前，我没有碰到过网络管理报文类型要求是CAN FD类型。即使网段内有的节点使用普通Transceiver（比如：1043），有的节点使用支持CAN FD的Transceiver（比如：1145），但是，**唤醒网络的报文类型还是会要求是Classical CAN帧**。因为支持CAN FD类型的Transceiver向后兼容，所以混用没有太大问题。 48 | 49 | 任何总线速率的提升都会带来抗干扰能力差的风险，所以，抗电磁干扰测试必不可少。尤其汽车，作为一个移动的交通工具，会在多种天气情况下使用。 50 | 51 | **提醒**：CAN FD的项目中，会配置SSP(Secondary Sample Point)，而且会测试该采样点。开发时，不要配置错误，严格按照需求走。 52 | 53 | ## CAN FD速率切换位置 54 | 55 | 这里给大家补充一点细节：CAN FD报文中，速率切换位置和各个域（field）对应位置。假设：项目中使用CAN FD的速率是500Kbps~2Mbps。真正2M速率开始切换的位置是**从BRS Bit到CRC Delimiter Bit**。由下图可以看出，2Mbps的速率不仅仅在Data field，CRC filed和Control field也有2Mbps的bit。 56 | 57 | 下图中标识**Arbitration Phase**的位置使用500Kbps，标识**Data Phase**的位置使用2Mbps。所以，**不要混淆Data Phase和Data Field**。 58 | 59 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyJLz1icZMHMXQ3ZudfEU5k4f1wz2PkJ46ttyqO7zHskibRKKYlBfq0Wqz0ibnKNtEySjz8O0CFJ0zDA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 60 | 61 | 采样点的测试中，对于CAN FD报文，BRS、CRC Delimiter 位是没有必要测试的，这两个位置速率在切换，测试准确性不高。 62 | 63 | 64 | 65 | 写在最后 66 | 67 | 写公众号的日子，遇到很多技术很棒的读者，他们给我指正、交流，受益颇多，感谢！有需要的朋友，可以进群聊，群里有很多专业的小伙伴可以答你所惑！ 68 | 69 | 70 | 71 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/quuOyCqONwdD16hI11wAQWxGp4ajJ4DMnbsHGb4ViandFryeibcQb1Idxb3MHmrh20988OSES3OU1wPTicQbAr94g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 72 | 73 | 74 | 75 | 参考资料 76 | 77 | SIMPLE TITLE 78 | 79 | ISO 11898-1-2015.pdf 80 | 81 | TJA1145 High-speed CAN transceiver for partial networking.pdf -------------------------------------------------------------------------------- /autosar/NM/Autosar网络管理：ERAEIRA问题QA.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：ERA/EIRA问题QA 2 | 3 | **Q1：****ERA****、EIRA谁针对****网关节点？** 4 | 5 | **A1**：Autosar网络管理中，使能PN(Partial Network)功能以后，会有ERA和EIRA配置项。两者有什么区别呢？搞清楚两者的区别，需要先清楚开发的节点（ECU）是否是网关（Gateway）节点。 6 | 7 | - **对于网关节点**，则会涉及到ERA的配置，为什么这样说呢？充当网关节点的ECU，意味着此ECU包含多个物理通道，eg:2路CAN、1路Flexray等。当网关节点的某一路（eg:CAN1）收到PNC #n和其他路关联时（eg:CAN2），网关节点需要承担主动唤醒CAN2的责任，因此需要PNC信息路由，此时需要ERA将CAN1收到的PNC #n信息给到CAN2。更多细节可以参考前文[Autosar网络管理：主动唤醒源/被动唤醒源与网络主动唤醒/被动唤醒的关系](http://mp.weixin.qq.com/s?__biz=MzUyNDU4NTc1NQ==&mid=2247489138&idx=1&sn=6975890311fad819099b92c96df00c77&chksm=fa2a4806cd5dc11017a8c3bd833a596005101c028d55467134baaff978653e7bb31c12493956&scene=21#wechat_redirect)。 8 | - **对于非网关节点**，没有路由PNC信息的任务，使能EIRA功能即可。 9 | 10 | ## Q2：对于ERA，为什么6个通道8个PN，需要48 个计时器？ 11 | 12 | **A2**：对于ERA，Q1中已经提到，涉及不同物理通道之间的路由，或者说，不同网段之间PNC信息路由。8个PN需要每个网段分别处理，即：PNC #n需要在每个网段独立处理其PN状态，以此协调各网段内的PN状态，因此需要6 * 8个ERA Timer分别计时。 13 | 14 | **注意**：EIRA信号，每类总线共用一个，比如：3路CAN，均参考一个EIRA接收信号的PNC信息即可，而ERA需要每路总线，各自处理自己的ERA接收信号，以便于路由给其他网段。 15 | 16 | ## Q3： 外部PN请求被镜像回请求总线，并提供给中央网关（必需的）物理通道。在子网关情况下，请求位不得镜像回请求的物理通道，以避免中央网关和子网关间的静态唤醒。如何理解这里的"镜像"？ 17 | 18 | **A3**：如上这段话的出处先了解一下，如下所示： 19 | 20 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxGyJCka2Mj7QwXnZLWq8GC7aNJumrmL1iaZVrcgRGSfulicN52071zItQP5Szyy8WiccTHicsaDwI5vg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 21 | 22 | **解释：** 23 | 24 | 子网关收到PNC #n信息，发送网络管理报文时，不要将PNC #n发送到接收的物理通道。比如：ECU4::E节点收到ECU2::C节点的PNC #n，ECU4::E在发送网络管理报文的时候就不要置位PNC #n（=1）。而中央网关，如：ECU1::D需要将收到的PNC #n发送回CAN2 Bus。为什么子网关不能将PNC #n发送回对应的总线呢？ 25 | 26 | 按照规范要求，一个网段内有一个Active PNC Gateway，其余的为Passive PNC Gateway，ECU1是中央网关（节点D为Active PNC Gateway）、ECU4是子网关（节点E设计为Passive PNC Gateway），5个ECU的关联关系如下所示： 27 | 28 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwcicEfbUDIqmzJBqzgcFtIRNkicLwBib9KeTxcpcAwk2iaYBhV2Q5vIt8Cn8GdPbTdSWGUwbujFevWSg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 29 | 30 | **假设:** 31 | 32 | **不按照****规范要求****，一个网段内有两个Active PNC Gateway，其余的为Passive PNC Gateway，ECU1是中央网关（节点B、D为Active PNC Gateway，分别对应Can1 Bus和Can2 Bus）、ECU4是子网关（节点E、F也为Active PNC Gateway，分别对应Can2 Bus和Can3 Bus），5个ECU的关联关系如下所示：** 33 | 34 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwcicEfbUDIqmzJBqzgcFtIRa0VdAO3ggdFM4wPib3ANQUrmMRicInWCHs5hVu7HUpw1vSu47icLAjMuQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 35 | 36 | 这样会出现什么问题呢？规范要求：Active PNC Gateway节点是网段内最后一个释放PN网络的节点，如果在一个网段内存在两个Active PNC Gateway节点，会使得两个Active PNC Gateway一直不释放网络，导致网络锁死（谁都不释放，都要最后一个释放PNC）。Autosar规范解释如下： 37 | 38 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxGyJCka2Mj7QwXnZLWq8GCdyrMaFt6lAMZSPNMRL1gplgIqlEyoYAQ1eaYLLtia5mSaUPrfDc2Egw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 39 | 40 | 先消化一下Autosar的这个解释，如下所示： 41 | 42 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxGyJCka2Mj7QwXnZLWq8GCCefTPL3yTCvW7vdicAhu2RKWVN232LyPr9y6rmpXeAiaicvz64CVHf3vg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 43 | 44 | **解释：** 45 | 46 | 一个ComM通道如果映射到了两种不同的PNC Gateways，只能有一个主动协调此通道的网络状态，其他的被动协调（或者说不协调）。说白了就是一个ComM Channel有一个Active PNC Gateway节点协调即可。所以，在设计网关节点的PNC Gateway类型时，需要小心。 47 | 48 | 因此，中央网关和子网关的节点均关联到同一个网段，需要将子网关的节点设置为Passive PNC Gateway，以此避免网络状态锁死。 49 | 50 | “镜像”就是将从总线收到的PNC #n信息再发送到总线。 51 | 52 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/quuOyCqONwdD16hI11wAQWxGp4ajJ4DMnbsHGb4ViandFryeibcQb1Idxb3MHmrh20988OSES3OU1wPTicQbAr94g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 53 | 54 | 55 | 56 | 参考资料 57 | 58 | SIMPLE TITLE 59 | 60 | AUTOSAR_SWS_COMManager.pdf 61 | 62 | AUTOSAR_SWS_CANNetworkManagement.pdf -------------------------------------------------------------------------------- /autosar/NM/Autosar网络管理：RepeatMessageRequestBit作用，你清楚吗？.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：RepeatMessageRequestBit作用，你清楚吗？ 2 | 3 | 如标题：RPB(Repeat Message Request Bit）干啥用的？此问题源于群内小伙伴的讨论，本文将该问题带来的思考分享给大家。 4 | 5 | **提示**：基于Can总线讨论 6 | 7 | 1 8 | 9 | RPB的作用 10 | 11 | 首先，确定一下RPB的位置，RPB在CBV字节的Bit0，如下所示： 12 | 13 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwmD9AoLAY2fve0fdd7hlyViaLI4icbBVGS0icyjQJruMydAA1xN6d8nwQicGB4aQ0fmwGUriaDNqiahy5Q/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 14 | 15 | RPB的作用是什么呢？看一下Autosar的官方解释，如下所示： 16 | 17 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwmD9AoLAY2fve0fdd7hlyVMQ51VacqxFdgdAmHzxrEGfXWF8dp6PwQplVLrB3Tibk47r9yF3gXEyw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 18 | 19 | 意思就是：RPB = 1，有RMS(Repeat Message State)请求，否则没有RMS请求。这里我们需要从收/发两个层面理解： 20 | 21 | - **接收**：如果接收到的网络管理报文中，RPB = 1，请求当前的节点进入RMS状态。 22 | - **发送**：如果本节点的**上层逻辑主动**请求进入RMS，则会主动调用接口CanNm_RepeatMessageRequest()，之后本节点外发的网络管理报文中RPB = 1。提示：RPB置位与否的操作需要静态配置**CANNM_NODE_DETECTION_ENABLED**参数。 23 | 24 | CanNm_RepeatMessageRequest()接口声明如下所示： 25 | 26 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwmD9AoLAY2fve0fdd7hlyV9iaYOsHOYyIE6B0WHqDvtQrC9EDRib36ibGmypPVg6SefmcST7LCvZZibg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 27 | 28 | 2 29 | 30 | RPB的使用场景 31 | 32 | 这里我们假设一种工况：某个网段存在3个ECU：ECU1、ECU2、ECU3，且ECU3具有PN功能，ECU1对应的网络管理报文0x501，ECU2对应的网络管理报文0x502，ECU3对应的网络管理报文0x503。三个ECU在总线上的拓扑关系如下所示： 33 | 34 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwmD9AoLAY2fve0fdd7hlyVFwJBjqVR9lywYqnItkwZGO08dETdibLdicqbGsgVdwQlWic7gxBfCVyBA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 35 | 36 | 具体解释3个节点的网络状态切换时序： 37 | 38 | **t0时刻**：ECU1和ECU2正常通信，两者均处于NOS(Normal Operation State)状态，发送的网络管理报文中，RPB未置位(RPB = 0)。ECU3处于BSM(Bus-Sleep Mode)状态（ECU3具有PN功能，因为收到的网络管理报文中，对应的PNC未置位，所以此时ECU3处于休眠状态）。 39 | 40 | **t1时刻**：**ECU1主动调用**接口CanNm_RepeatMessageRequest()请求进入RMS(Repeat Message State)状态，此时： 41 | 42 | 1. ECU1进入RMS状态，ECU1发送的网络管理报文中，**PNI(Partial Network Information Bit)置位（PNI = 1）**，且**关联ECU3的****PNC_ECU3 = 1**，ECU3网络被唤醒； 43 | 2. 且RPB = 1，随即ECU2和ECU3进入RMS状态； 44 | 3. ECU2和ECU3发送的网络管理报文中，RPB = 1，且稍微晚于ECU1。 45 | 46 | **t2时刻：**ECU1、ECU2、ECU3依次进入NOS状态，且三者的RPB = 0。 47 | 48 | 如下所示： 49 | 50 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwmD9AoLAY2fve0fdd7hlyVg6HB3Gcxc0JFC3WHn0ibVypib1NLFYXxibiaCtuviar5wGicMjRPtwqv7Xjg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 51 | 52 | **注意**：同一网段内的所有节点，对应的CANNM_MSG_CYCLE_TIME、CANNM_REPEAT_MESSAGE_TIME、CANNM_WAIT_BUS_SLEEP_TIME、NM-TIME_OUT时间参数需要保持一致，以便于网段内所有节点在**近似相等的时间**内进入相同的网络状态。 53 | 54 | 综上述：RPB具有协调不同ECU节点状态切换的作用，以便于网段内所有节点在近似相等的时间内进入相同的网络状态。 55 | 56 | RPB是否还有其他使用场景？期待你不同的看法。 57 | 58 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/quuOyCqONwdD16hI11wAQWxGp4ajJ4DMnbsHGb4ViandFryeibcQb1Idxb3MHmrh20988OSES3OU1wPTicQbAr94g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 59 | 60 | 61 | 62 | 参考资料 63 | 64 | SIMPLE TITLE 65 | 66 | AUTOSAR_SWS_CANNetworkManagement.pdf -------------------------------------------------------------------------------- /autosar/NM/Autosar网络管理：你知道ECU如何被供电的吗？.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：你知道ECU如何被供电的吗？ 2 | 3 | 为什么要聊这个话题呢？在实际的项目开发中，很多问题会牵扯到ECU的上下电流程，尤其时间相关的问题。如果不能清楚自家产品的供电时序，想必在解决类似问题时，会很伤脑壳。本文咱们聊聊ECU如何被供电的，希望能给读者拓展一些解决问题的思路。 4 | 5 | 如果你的单位是Tier1，相对比较有优势，因为做产品，找硬件组可以拿到产品对应的PCB原理图；如果你的单位只做纯软件服务或者没有PCB原理图，对软件工程师来说，解决问题就少了一把利器。本文从Transceiver出发，聊一下我们关切的ECU供电问题。 6 | 7 | 其实前面讨论过Transceiver与ECU连接关系，可以参考前文[Autosar网络管理，你不能不清楚节点的唤醒方式](http://mp.weixin.qq.com/s?__biz=MzUyNDU4NTc1NQ==&mid=2247484642&idx=1&sn=caab0c96dfcdc40909015becb48e66ca&chksm=fa2a5a96cd5dd380b9bd345cd282073d0969b665b53661fce84e1954169acde2986f9068c727&scene=21#wechat_redirect)。 8 | 9 | **提示：**本文以TJA1145为例 10 | 11 | 1 12 | 13 | TJA1145特性 14 | 15 | 在聊ECU如何被供电之前，先了解一下TJA1145的特性。TJA1145这款Transceiver的应用目前普及率很高，之所以普及率高是有它的道理的，先看一下它的特性： 16 | 17 | - **支持经典CAN唤醒模式的检测;** 18 | - **唤醒的最高检测速率可达1Mbit/s;** 19 | - .... 20 | 21 | 如上两点是我比较关注的，因为这两点影响实际的开发设计。解读一下这两点的特性：**说白了就是TJA1145的唤醒功能适用于经典CAN**。TJA1145也支持CANFD，如果是CANFD类型，又想让特定的Frame唤醒ECU，进而唤醒网络，那么TJA1145接收的Frame最高速率不能超过1Mbit/s。 22 | 23 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwCcwjxaf6EUmPT52ibr9lYWLs47tS7zicxMx67wVDicBZFIcibWe3zkbPlMs94kbGtNicZHPl8YX5B8tA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 24 | 25 | 我们知道，对于CAN和CANFD，其头部和尾部的速率相同(为了兼容)，项目中多数使用500Kbit/s，而CANFD的数据段速率是可变的，从稳定性上来说，数据段一般会使用2Mbit/s，虽然CANFD可以达到5M，甚至8M，但是在实际的应用中，其稳定性还不行，主要是充放电容速率导致。所以目前，项目多数还是使用2Mbit/s的通信速率。其实，这一点看Transceiver的Data sheet是可以获知的，比如TJA1145的Data Sheet中就已经描述的很清楚了，**可靠的通信速率最高2Mbit/s**。 26 | 27 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwCcwjxaf6EUmPT52ibr9lYWicZP0zmS4d08rSdZIMovoN9aFKr6ZPpM6ZAn5J6V4fRH8mnZ3hBia77A/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 28 | 29 | 刚才说到数据段的速率是可变的，通常项目使用CANFD时，也会将数据段的速率提高到2Mbit/s，不然岂不是浪费资源。如果使用CANFD，数据段速率提升到2Mbit/s，那么TJA1145的唤醒过滤功能就不能使用，所以这一点在设计时就需要留意。看一下需求中，CANFD数据段速率是要求500Kbit/s还是2Mbit/s，当然，对于500Kbit/s的经典CAN，指定报文的唤醒功能在TJA1145上就可以做到，对于CANFD Frame，数据段速率如果是500Kbit/s（实际项目中，确实会有这种大马拉小车的情况），TJA1145也能做到指定报文唤醒的功能。 30 | 31 | 开发中，如果能用硬件做到的功能就尽量不要用软件实现，比如本文聊的ECU唤醒，进而网络唤醒的功能。TJA1145可以实现的功能，就没必要软件再去识别唤醒的报文是否是有效的网络管理报文，徒增资源的开销和维护成本。尤其涉及到PN功能的网络唤醒时，使用TJA1145的过滤功能，可以使得开发工作简化很多。 32 | 33 | 2 34 | 35 | TJA1145系统控制器状态机 36 | 37 | 38 | 39 | TJA1145系统控制器的状态跳转如下所示： 40 | 41 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwCcwjxaf6EUmPT52ibr9lYW4TLBVvMRWCg5W0mOWhMllHu8ucD8WWMOh8f4A47wzaVGIMmTlZgTpQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 42 | 43 | TJA1145系统控制器的状态跳转由SPI指令/特定事件控制，这里不再细说，这是为了聊下面的供电做铺垫。 44 | 45 | 2 46 | 47 | TJA1145供电时序 48 | 49 | 50 | 51 | 如下图，信息很多，我们分析几个重要的点。 52 | 53 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vybJtGHuicAhMXkzOW8O7ffYCUaRfAEibMiaiaDQN9wvnXAhgb28s049e3spMIDQCnbsSyXQMMpTWVDwA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 54 | 55 | 1. BAT（Vbat）就是蓄电池，即KL30电，也就是说TJA1145是被常供电的，一般KL30电压为12V，而Data Sheet中给出的典型电压值为13V，如下所示。既然TJA1145在整车中是被常供电的，意味着：只要KL30供电稳定（保持在12V），TJA1145就不会进入OFF Mode，除非蓄电池亏电，导致Vbat电压低于其阈值2.8V。 56 | 57 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwCcwjxaf6EUmPT52ibr9lYWODCWibnlghntkFYaxCRrem1GwIjcLkpRuqDBor6XHcTiajYoDtYftlAQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 58 | 59 | 2. Vbat既然给TJA1145稳定供电，那么ECU是如何下电的呢？当ECU需要下电的时候，即切断Vcc时，会通过SPI给TJA1145发送进入Sleep Mode的指令，如果TJA1145在Sleep Mode，**INH Pin脚会处于高阻状态，此时与TJA1145连接的3V和5V电源管理模块禁能**，即无法给主芯片提供Vcc电，也无法给TJA1145提供Vcc和Vio电。所以主芯片会完全的断电，实现了最大程度的节能； 60 | 61 | 3. 当TJA1145进入Sleep Mode模式时，如果检测到总线的wake-up event（可以是特定的网络管理报文，因为TJA1145支持过滤功能），TJA1145切换到Standby Mode，在此模式下，**INH Pin脚被拉低**，**3V和5V电源管理模块使能**，**从而主芯片/TJA1145被供电**，芯片中的软件得以运行， 之后主芯片通过SPI给TJA1145发送进入Normal Mode指令，到此，通信可以真正的建立，报文的收/发成为可能，之所以说可能，是因为要等ECU识别收到的报文是否是网络管理报文，且有效，只有是有效的唤醒源，ComM才允许通信栈打开，之后的应用报文得以外发。到这里，回答了本文关切的问题，即ECU如何被供电的？ 62 | 63 | 4. 注意：Vbat与INH Pin的连接关系如下图所示，这里大家是不是有这样的疑问：INH与Vbat连接，而Vbat = 12V，那INH Pin是不是一直保持12V？不是的，INH的状态与所连接的设备相关，感兴趣可以查阅，我不太清楚，不在这误导大家。我们只需要清楚，TJA1145处于不同的Mode时，INH的状态会在高阻与非高阻之间切换即可。 64 | 65 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwCcwjxaf6EUmPT52ibr9lYW0rome7JqLEWKfSYiaxD96HxkO8YWFOHuQ0e39corOXBQRhmOOH00R0Q/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 66 | 67 | 如上聊的这些，并没有讨论KL15供电的情况，这个可以找时间再和大家侃侃。主要想以TJA1145为例，让大家对ECU的供电有一个认识，当然，也希望和更多的朋友一起讨论更多的技术。 68 | 69 | **参考资料** 70 | 71 | TJA1145 High-speed CAN transceiver for partial networking.pdf -------------------------------------------------------------------------------- /autosar/NM/Autosar网络管理：唤醒源的Check和Set.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：唤醒源的Check和Set 2 | 3 | 我们知道，在谈论Autosar网络管理之前，需要检查唤醒源，并且确保其有效。对唤醒源的操作，一般需要经过Check、Set、Valid三步曲。这三步都是必须的吗？本文聊聊Check和Set。 4 | 5 | **提示**：基于CAN总线讨论 6 | 7 | 1 8 | 9 | 如何Check唤醒事件 10 | 11 | 对于CAN ，CC(communication controller)或Trcv(Transceiver)可以使用中断或轮询来检测唤醒事件。而CC和Trcv的关系自不必细说，谁离了谁也干不成事(报文无法收/发)，为什么这么说呢？看一下下图，你就清楚CC和Trcv的关系了： 12 | 13 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vz8QIXjbHYYJQkeWKyJOahg3WsmiaqqAcTR53HsohQNvuic1QvO2GkPvaEp4tJRbu0gibZMB5aln6fRw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 14 | 15 | 也正是因为CC和Trcv关系如此，所以当有Can Bus的唤醒事件时，EcuM分不清楚Can Bus唤醒是CC发现的还是Trcv发现的，如果EcuM想知道谁发现的，就需要问问CC和Trcv，你俩谁发现的？EcuM怎么问呢？不怕CC和Trcv不说，EcuM通过EcuM_CheckWakeup()一查，是CC还是Trcv，EcuM就清楚了。EcuM要彻查到底谁发现的唤醒事件，它自己只会传“圣旨”，即调用EcuM_CheckWakeup()，实际调查，还是依靠地方官员（CanIf、CC or Trcv）。 16 | 17 | ## 1、中断方式Check唤醒事件 18 | 19 | 当外部中断唤醒事件到来时，可以是Can Controller中断，也可以是CAN Transceiver中断。如下展示了EcuM"圣旨"的传递过程（Check），此过程中，中断例程中主动调用EcuM的EcuM_CheckWakeup()，让EcuM检查，此方式不拖泥带水，响应迅速。 20 | 21 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vz8QIXjbHYYJQkeWKyJOahgZwcicMl11adibZkBuBtAdiciaLQRRcq1odrpD2XTZo0LdpM6u7JEOpibyRg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 22 | 23 | 24 | 25 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vz8QIXjbHYYJQkeWKyJOahgY9Jiaktmbg84wP2Yvpd5RAB5fc9DaVCfcTHdOtwuuBvBHiba8ibF9KiasQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 26 | 27 | ## 2、轮询方式Check唤醒事件 28 | 29 | 相比于中断方式，Polling方式就“磨叽”了，CC和Trcv都不主动告诉EcuM，等EcuM检查，就像小学生考试成绩，考不好不会主动告诉家长，都是家长想起来，主动问自己家熊孩子考的咋样一样一样的道理。EcuM于是就在自己的Task（比如：10ms）中一个一个检查CC和Trcv，如下所示： 30 | 31 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vz8QIXjbHYYJQkeWKyJOahgrDwyZWvFSW56BpDgbFYezBHDsmUs10PFRZttyeflaaRzQic2GBSsA6w/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 32 | 33 | 不管轮询还是中断方式，唤醒事件都是“谁发现谁举报”的原则，即谁发现了唤醒事件，谁有责任告诉EcuM(即调用EcuM_CheckWakeup())，这就是Set部分。 34 | 35 | **提示**：Check时，会对应一个CheckWakeupTimer，这个参数可配 36 | 37 | 2 38 | 39 | 硬件可以Check 40 | 41 | 实际，EcuM并不关心到底谁发现的，**它只关心是哪个网络需要唤醒**，**并将其传递给ComM**。 42 | 43 | 那我们思考一个问题：“如果Trcv可以Filter，确保了特定帧唤醒，EcuM是不是可以不用Check?”答：个人赞同（注：此问题是一个读者给出的思考）。 44 | 45 | 比如目前使用率比较高的NXP TJA1145，这款Transceiver具有PN过滤功能，如果我们的项目中，要求指定Range内的网络管理报文唤醒网络，NXP TJA1145即可将此Range范围的网络管理报文识别出来，而不必让Ecu起来（被供电），进行软件过滤。 46 | 47 | 细心的读者已经发现了，EcuM_CheckWakeup()这个接口放在Integration Code中，这什么意思呢？此部分属于Autosar的Callout函数，此函数的实现由User定义，从这个角度讲，如果Trcv可以过滤（即Check）,即可直接调用EcuM的EcuM_SetWakeupEvent(EcuM_WakeupSourceType)接口，告诉EcuM有唤醒事件。 48 | 49 | **参考资料** 50 | 51 | AUTOSAR_SWS_CANDriver.pdf 52 | 53 | AUTOSAR_SWS_ECUStateManager.pdf -------------------------------------------------------------------------------- /autosar/NM/Autosar网络管理：基础问题知多少.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：基础问题知多少 2 | 3 | Autosar网络管理看似内容不多，真正开始做这一块才意识到：需要串联的知识，真的不少。本文与大家聊几个网络管理的问题，看看这几个问题，能否助力大家打开思路。 4 | 5 | **提示**：基于CanNM讨论。 6 | 7 | ## 1、Passive Node会发网络管理报文吗？ 8 | 9 | **答**：TBD。为什么是待定呢？如果按照Autosar框架去开发，当前ECU的网络类型配置为Passive，那么此ECU是不能外发网络管理报文的，只能接收网络管理报文。Autosar规范给出的解释如下所示： 10 | 11 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyEG4zEs11iaNwXxZWWpAYJicPhtO3rJITGZShfNq5BMI10gD5KAkwylB0p3DHgKFXQLZm7OsLjw9eg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 12 | 13 | 大家也意识到了，ECU的网络类型是否是Passive的，可以提前通过**静态配置参数CANNM_PASSIVE_MODE_ENABLED配置**，而这个需求来源于OEM，OEM的EE部门会考虑哪些ECU的网络类型是Passive类型，哪些不是。 14 | 15 | 但是，有的项目开发中，ECU的网络类型要求配置为Passive，但是又要求网络状态进入Repeat Message State时，发送网络管理报文，离开Repeat Message State时停发网络管理报文，如下所示： 16 | 17 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyEG4zEs11iaNwXxZWWpAYJicQUEA2XIDh6mozRCsjhXxnia5c8riakBdOOFh2eWORJd2Jiad2iaAZuUfqw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 18 | 19 | 可以将这样的场景理解为OEM Specification和Autosar Specification。最终项目的实现以满足客户的需求为目的，规范是参考，项目的本意是根本，解释权归客户，开发人员需要做到的是：理解需求。 20 | 21 | **提示**：Autosar规范中，CanNM状态机进入Repeat Message State时，如果网络类型是Passive的，不能外发网络管理报文，如下所示： 22 | 23 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyEG4zEs11iaNwXxZWWpAYJicBIzwWibIwtjLhLeqdZUtPs3MBW7IXAC2UVXDeZToyzPzeibficr9k0FPw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 24 | 25 | ## 2、同一个ECU，不同Node的网络类型可以不同吗？ 26 | 27 | **答**：不能。Autosar给出的规范解释如下所示： 28 | 29 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyEG4zEs11iaNwXxZWWpAYJicMmc6aduTQuOh9b016kDDFwRGavINDHhxOVDKlia8lbNNrHxwEbw1gLg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 30 | 31 | 什么意思呢？举例：某个ECU有3路CAN：CAN Node1、CAN Node2、CAN Node3。要么这3路CAN Node网络类型全部是Passive，要么全部不是。 32 | 33 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyEG4zEs11iaNwXxZWWpAYJicENcuC9HcpLzBpMZW5jd0VdRzMk20zibLkicPsNRjSullJxLMADCz8VVQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 34 | 35 | 能不能做到CAN Node1不发网络管理报文，CAN Node2、CAN Node3发送网络管理报文。从软件实现的角度：可以。但是，不符合Autosar规范。 36 | 37 | ## 3、如何理解网络状态requested/released和CanNM状态？ 38 | 39 | **答**：这里我说一下自己对这一部分Autosar规范的理解。如果某个Node想要主动请求网络通信，**该Node需要有主动外发网络管理报文的能力**，只有Node具备了外发网络管理报文的能力，才有唤醒当前网段其他节点的可能。这也意味着**此Node对应ECU的网络类型不能是Passive的**。 40 | 41 | 网络状态的**requested/****released**，需要调用接口CanNm_NetworkRequest()/CanNm_NetworkRelease()进行切换。 42 | 43 | ECU被加电，CanNM完成初始化以后，CanNM处于Bus-Sleep Mode，网络状态切换成默认状态的**released**。**如果CanNM状态机想要进入Network Mode::Repeat Message State，意味着CanNm_NetworkRequest()或者CanNm_PassiveStartup()被调用，而Node网络的状态只能由CanNm_NetworkRequest()的请求决定**。 44 | 45 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyEG4zEs11iaNwXxZWWpAYJicLf0qkL7eicaCkBt3uIDNOfBypPr2LFyooPBYm6xcKMTp1KqdsbPic1zQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 46 | 47 | 所以，CanNM状态机进入Network Mode::Repeat Message State的方式有两种：调用CanNm_PassiveStartup()或者CanNm_NetworkRequest()。 48 | 49 | 而网络进入**requested**状态只能由CanNm_NetworkRequest()决定。如果**网络类型是Passive的**，不会外发网络管理报文，调用CanNm_PassiveStartup()，使得CanNM状态机进入Repeat Message State，此时可以发送应用报文，由于网络状态依然是**released**，所以之后进入Ready Sleep State；如果**网络类型不是Passive的**，通过调用CanNm_NetworkRequest()进入Repeat Message State，即可以发送网络管理报文，也可以发送应用报文，之后进入Normal Operation State。 50 | 51 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyEG4zEs11iaNwXxZWWpAYJicsPfJ0mOLPEM2ASPfkC5VSIWnS1ThZ9YcBiaZEd20Ep5pR35Lyh0H2og/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 52 | 53 | ## 4、PN功能设计，需要网段内所有ECU都必须包含PN功能吗？ 54 | 55 | **答**：不需要。 56 | 57 | 这里举一个例子：ECU1、ECU2没有PN功能，ECU3具有PN功能。ECU3收到的网络管理报文必须满足PNI Bit= 1 And PNC1 Bit = 1时唤醒。所以，ECU1、ECU2的网络管理报文内容不满足ECU3的过滤条件，比如：PNC = 0，如下所示。ECU3可以不被0x500~0x502的网络管理唤醒。所以，未必要网段内的所有ECU均实现PN功能。而ECU3发送的网络管理报文，却能唤醒ECU1和ECU2的网络。 58 | 59 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyEG4zEs11iaNwXxZWWpAYJic5W6DVev7SScdrdRIHnWm63fS9lVaFPHtskQITsBsp5umLzudBJg7Bg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 60 | 61 | 62 | 63 | ## 5、CanNm_PassiveStartUp()与CanNm_NetworkRequest()功能 64 | 65 | **答**：通过第3点，大家应该认识到两个接口功能是不一样的，这里再细化一下： 66 | 67 | CanNm_PassiveStartUp()：只负责CanNM状态机的切换，即：由Bus-Sleep Mode / Prepare Bus-Sleep Mode切换到Network Mode::Repeat Message State。 68 | 69 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyEG4zEs11iaNwXxZWWpAYJic8D6hpa7joNQibpcmF9pN7Ts21CRRF3QmK3lzwUX4rPia4oHsCxKbibtsQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 70 | 71 | CanNm_NetworkRequest()：不仅**负责CanNM状态机的切换**，即：由Bus-Sleep Mode / Prepare Bus-Sleep Mode切换到Network Mode::Repeat Message State。而且**负责节点网络状态的切换**，即：节点的网络状态切换到**requested**。 72 | 73 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyEG4zEs11iaNwXxZWWpAYJicGG0gUicIZx1TsqmLJsk6jK0jTswsemmW88yUREtySRwbicoc5ymTF9RQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 74 | 75 | **注意**：接口CanNm_NetworkRequest()的调用，意味着当前ECU不能使用Passive网络类型，如下所示： 76 | 77 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyEG4zEs11iaNwXxZWWpAYJicXOKXSB46ur345ajfNXKicz8jq4icNMV71or5a4uThrVI2dqrj4G06Rkg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 78 | 79 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/quuOyCqONwdD16hI11wAQWxGp4ajJ4DMnbsHGb4ViandFryeibcQb1Idxb3MHmrh20988OSES3OU1wPTicQbAr94g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 80 | 81 | 82 | 83 | 参考资料 84 | 85 | SIMPLE TITLE 86 | 87 | AUTOSAR_SWS_CANNetworkManagement.pdf -------------------------------------------------------------------------------- /autosar/NM/Autosar网络管理：确保第一帧是网络管理报文方法.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：确保第一帧是网络管理报文方法 2 | 3 | 项目中，如果上Autosar网络管理，多数需求都会要求网络唤醒后的第一帧必须是网络管理报文。为什么要求是网络管理报文呢？为了使得同一网段的相关Node快速进入Normal模式，使车机功能正常。 4 | 5 | 那如何确保Node网络唤醒以后，第一帧报文是网络管理报文呢？本文讨论一下常规做法和“无奈”做法。 6 | 7 | 提示：本文基于CAN总线讨论 8 | 9 | **常规做法** 10 | 11 | 其实这种常规做法在前面就讲过，主要是基于工具的配置，不管使用的是哪家工具，只要遵循Autosar规范开发，对应的工具都会有对应的配置，可以参考前文[Autosar网络管理PN：路由超时大Bug](http://mp.weixin.qq.com/s?__biz=MzUyNDU4NTc1NQ==&mid=2247484944&idx=1&sn=796eb70b20d845359f5e019656773d1a&chksm=fa2a5864cd5dd17285e66df13316d623d54c04647e9a19bd697311df110883dbf8cb7a91a0ea&scene=21#wechat_redirect)，在问题点1修复策略部分给出了配置注意事项，这里不再赘述。 12 | 13 | **"无奈"做法** 14 | 15 | 之所以说是无奈做法，是因为要修改静态代码，如果不是项目要求时间紧或者实在排查不出来问题点，大家不要考虑修改静态代码的下下策。修改静态代码会带来如下几点风险： 16 | 17 | 1. 如果项目使用的代码包是购买的，修改静态代码，代码供应商不负责； 18 | 2. 修改静态代码，我们未必考虑的周全，Autosar模块交错联系，稍不慎可能引起其他问题。比如controller的状态切换，你可以手动调用xxIf模块去切换，但是这可能引起网络或者通信时序问题，因为controller本身也需要结合transceiver状态协调管理，由xxSM模块协调管控比你擅自修改要安全的多； 19 | 3. 修改静态代码需要修改者对自己修改部分充分验证和测试。 20 | 21 | 说了如上的警示，这里给出“无奈”策略。 22 | 23 | 上层模块数据的发送最终都会调用底层的驱动接口，不管是标定栈、通信栈、诊断栈、网络管理，发送的报文都会调用Can_Write()接口，在Can_Write()接口中需要传入const Can_PduType* PduInfo参数，PduInfo这个指针包含CANID，如果知道了CANID就可以区分出这个报文是不是当前Node的网络管理报文，一个Node对应一个网络管理报文，比如：0x509。此时我们可以怎么做呢？node网络一旦唤醒，上层所有模块均可发送报文，尤其周期性应用报文，一般应用报文的优先级要高于网络管理报文，如果不限制，网络管理报文不会被优先发送。我们可以通过参数PduInfo里的CANID判断当前发送的报文是不是网络管理报文，即判断PduInfo->Canid == 0x509与否，如果是则发送，之后发送不在拦截（因为第一帧网络管理报文已经发送），如果不是则发给上层一个假的消息，告知上层发送成功，实际没有发送出去。 24 | 25 | 这里又有另一个问题，何时开始拦截？在Repeat Message State判断合理。因为在Bus Sleep Mode或者Pre-Bus Sleep Mode下均不会发送报文。 26 | 27 | 伪代码示例如下所示： 28 | 29 | ``` 30 | 31 | retLocal_can = CanNm_GetState( CANNM_HANDLE_CAN, &nmStatePtr, &nmModePtr); 32 | 33 | if(retLocal_can == E_OK) 34 | { 35 | if(nmModePtr == NM_MODE_NETWORK) 36 | { 37 | if(nmStatePtr == NM_STATE_REPEAT_MESSAGE) 38 | { 39 | if (0x509 == CanPdu.id) 40 | { 41 | do{ 42 | CanRet = CanWrite(); 43 | }while(CanRet != CAN_OK); 44 | sendFlag = TRUE; 45 | } 46 | else if(sendFlag == TRUE) 47 | { 48 | CanRet = CanWrite(); 49 | } 50 | else 51 | { 52 | CanRet = CAN_OK; 53 | } 54 | } 55 | else 56 | { 57 | CanWrite(); 58 | } 59 | } 60 | elses 61 | { 62 | sendFlag = FALSE; 63 | CanRet = CAN_OK; 64 | } 65 | }s 66 | ``` 67 | 68 | 通过CanNM_GetState()接口获取当前CAN网络的状态。上述伪代码的if else太多了，大家可以在这个策略上优化。 69 | 70 | **切记：**优先使用工具配置，不要轻易修改静态代码！ -------------------------------------------------------------------------------- /autosar/NM/Autosar网络管理：网络管理报文的收发与网络管理时间配置参数解析.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：网络管理报文的收/发与网络管理时间配置参数解析 2 | 3 | 如本文标题，本文主要讨论的问题：网络管理报文的收/发与网络管理时间配置参数解析。 4 | 5 | **提示**：以CAN总线为例 6 | 7 | ## 1、主动唤醒和被动唤醒 8 | 9 | **主动唤醒**：上层（比如：ASWC，通俗讲就是算法层）主动请求网络，主动唤醒会使得上层主动调用CanNm_NetworkRequest()接口唤醒网络。常见的主动唤醒源有：KL15信号，定时器、传感器等。 10 | 11 | - 定时器：节点休眠前设定时间，比如：每2h节点主动醒来。 12 | - 传感器：比如：脚踢门功能。脚踢后备箱，后备箱对应控制器主动唤醒网络，进而执行后备箱开启功能。 13 | 14 | 某些节点没有KL15硬线连接，可以通过接收特定的信号（KL15信号等），主动请求网络（调用CanNm_NetworkRequest()接口）进入NOS(Normal Operation State)状态。 15 | 16 | **被动唤醒**：由其他节点的特定行为触发本节点的唤醒，比如：**收到其他节点的有效网络管理报文**被动唤醒，调用CanNm_PassiveStartup()接口唤醒网络。 17 | 18 | 注意：不要和网络被动模式混淆，**不管节点的网络类型是被动的还是主动的，****均可以被动唤醒**。**被动网络节点被动唤醒不会外发网络管理报文，主动网络节点被动唤醒会外发网络管理报文。** 19 | 20 | ## 2、网络被动节点 21 | 22 | 网络被动节点的网络管理报文收/发行为及时间参数如下所示： 23 | 24 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vw9ibXRHBCeuBNFlINNI7iatK5dqiaAbZ6XpX23qiaBakKbNTXnibYrtiat4no5aynkhfBHRiaZOcpxy57wg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 25 | 26 | 网络被动节点**不会进入NOS**(Normal Operation State)**状态**。 27 | 28 | - **网络管理报文的接收（Rx）**：在RMS(Repeat Message State)、RSS(Ready Sleep State)、PBM(Pre Bus-Sleep Mode)状态下均可以接收网络管理报文。BSM(Bus Sleep Mode)无法接收网络管理报文。 29 | - **网络管理报文的发送（Tx）**:在任何状态下**均不会**发送网络管理报文。 30 | - **应用报文的发送**：在RMS、RSS状态下可以发送应用报文，PBM下停发应用报文（已放入底层硬件缓存区的报文可以发送）。如果不理解底层硬件缓存区，可以参考前文[Autosar通信栈：基础问题知多少](http://mp.weixin.qq.com/s?__biz=MzUyNDU4NTc1NQ==&mid=2247487659&idx=1&sn=67ae5b10fe05f8184ea9729722e52af3&chksm=fa2a4edfcd5dc7c9e652fa08c5b9a337806859cdb77552034e9a12026f1a95d9f33b9a2c08fc&scene=21#wechat_redirect)。 31 | - **Repeat Message Timer**：进入RMS状态时，启动该时间，比如：1500ms，当该时间走完，由RMS进入RSS状态。 32 | - **NM-Timeout Timer**：进入RMS时，启动该时间，比如：3000ms，在此期间接收到网络管理报文或者超时，重置该时间。进入RSS状态，收到网络管理报文，重置该时间，如果收不到网络管理报文，超时后，进入PBM状态。 33 | - **Wait Bus Sleep Timer**：在PBM状态，收不到网络管理报文，该时间超时后进入BSM，比如：4000ms。PBM状态下，如果收到网络管理报文或者网络请求，则重新进入RMS。 34 | 35 | ## 3、网络主动节点 36 | 37 | 网络主动节点的网络管理报文收/发行为及时间参数如下所示： 38 | 39 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vw9ibXRHBCeuBNFlINNI7iatKibJOA91GTKsxdMYYkwsYzLTZszsBGtqibMSQZQvhQ1MwBx4VYLzVXVPg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 40 | 41 | - **网络管理报文的接收（Rx）**：在RMS(Repeat Message State)、NOS(Normal Operation State)、RSS(Ready Sleep State)、PBM(Pre Bus-Sleep Mode)状态下均可以接收网络管理报文。BSM(Bus Sleep Mode)无法接收网络管理报文。 42 | - **网络管理报文的发送（Tx）**:网络主动节点的NM Msg发送行为有多种情况： 43 | 44 | 1.正常发送模式（没有快速发送功能，网络被动唤醒）：在RMS以相同的周期发送网络管理报文，eg:500ms，如下所示： 45 | 46 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vw9ibXRHBCeuBNFlINNI7iatKx3KiancVjhEpVly6ibsZKq5fa842dhRiavWzmCPZibOK5LBBoTlvOjsLoA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 47 | 48 | **注意**：由于网络是被动唤醒（比如：接收到其他节点网络管理报文唤醒），上层没有主动请求网络，网络状态由RMS进入RSS。 49 | 50 | 2.正常发送模式（没有快速发送功能，网络主动唤醒）：在RMS和NOS以相同的周期发送网络管理报文，eg:500ms，如下所示： 51 | 52 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vz61MSGh783RU11ykwlXC0lNe1pmpMSyqXxMtUnXjb8xjj0DjR2NuDNuvpTy7NX7zrVOIfdO5NicEA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 53 | 54 | 3.有快速发送功能（网络被动唤醒）：在RMS状态下，先以快发周期发送一定次数的网络管理报文，eg：20ms发送10次，之后以正常周期发送网络管理报文，eg：500ms。如下所示： 55 | 56 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vw9ibXRHBCeuBNFlINNI7iatKicce3MwDxWWWNj7CiaibmmQ1mUD5sfbeldd2TmmvfF5ONQwscWHicjficzg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 57 | 58 | **注意**：由于网络是被动唤醒（比如：接收到其他节点网络管理报文唤醒），上层没有主动请求网络，网络状态由RMS进入RSS。 59 | 60 | 4.有快速发送功能（网络主动唤醒）：在RMS状态下，先以快发周期发送一定次数的网络管理报文，eg：20ms发送10次，之后以正常周期发送网络管理报文，eg：500ms。上层主动请求网络，进入NOS状态，以正常周期发送网络管理报文，eg：500ms。如下所示： 61 | 62 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vw9ibXRHBCeuBNFlINNI7iatKWZ7hpo3TS3quTL9RLAG4dNJbzVEFjQHA2B01BrVyoMJC2zCT9kEARA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 63 | 64 | **注意**：由于网络主动唤醒，则由RMS进入NOS。 65 | 66 | - **应****用报文的发送**：在RMS、NOS、RSS状态下可以发送应用报文，PBM下停发应用报文。 67 | 68 | - **Repeat Message Timer**：进入RMS状态时，启动该时间，比如：1500ms，当该时间走完，由RMS进入NOS/RSS状态(取决于上层是否主动请求网络)。 69 | 70 | - **NM-Timeout Timer**：进入RMS时，启动该时间，比如：3000ms，在此期间接收/发送网络管理报文或者超时，重置该时间。进入RSS状态，接收/发送网络管理报文，重置该时间，如果收不到网络管理报文，超时后进入PBM状态。进入NOS状态，接收/发送网络管理报文或者超时，重置该时间。 71 | 72 | - **Wait Bus Sleep Timer**：在PBM状态，收不到网络管理报文，且没有网络请求，该时间超时以后进入BSM；如果收到网络管理报文或者网络请求则重新进入RMS。 73 | 74 | -------------------------------------------------------------------------------- /autosar/NM/Autosar网络管理：网络管理报文真的能保持节点网络状态，不休眠吗？.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：网络管理报文真的能保持节点网络状态，不休眠吗？ 2 | 3 | 进一步细化问题:"如果总线上某个节点进入了**RSS(Ready Sleep State)状态**，周期性地接收到其他节点发送的网络管理报文，此节点会进入PBSM（Prepare Bus-Sleep Mode），进而休眠吗?" 4 | 5 | **提示：**基于CAN总线讨论 6 | 7 | 1 8 | 9 | 节点进入RSS状态路径 10 | 11 | 节点如果想进入RSS状态，有两条路径： 12 | 13 | - 第一、由RMS（Repeat Message State）进入RSS状态 14 | - 第二、由NOS（Normal Operation State）进入RSS状态 15 | 16 | 如下所示： 17 | 18 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyP3p9jEnk3vRzHtwD1qv7QOZ7RWiaOBmmRoQpICylSQPDA9qoIACzfgEBDFnwQia2OQryziczSjXKJw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 19 | 20 | 对于上述两种进入RSS状态的方式，实质由节点的网络类型决定： 21 | 22 | 1. 节点网络类型**是Passive Mode**：节点只能由RMS进入RSS 23 | 2. 节点网络类型**非Passive Mode(Active Mode)**：如果节点是**被动唤醒**（比如：收到网络管理报文唤醒），节点只能由RMS进入RSS；如果节点是**主动唤醒**（比如：KL15硬线唤醒，外部定时器主动触发唤醒等），则节点由RMS进入NOS状态（主动请求网络），在NOS状态下，收到上层进入RSS的主动请求（主动调用接口CanNm_NetworkRelease()），进入RSS状态。 24 | 25 | 2 26 | 27 | 网络管理报文能让节点不休眠吗 28 | 29 | 回答这个问题，我们需要先确定当前节点是否使用PN（Partial Network）功能。 30 | 31 | ## 1、节点没有PN功能 32 | 33 | - **对于没有使用PN功能的节点**，在RSS状态下收到其他节点发送的NM Msg，会重置NM-Timeout Timer，让节点保持在RSS状态，也就是说：网络管理报文可以让节点保持在RSS状态，维持正常通信，节点不休眠； 34 | 35 | ## 2、节点具有PN功能 36 | 37 | **如果节点有PN功能**，还需要关注配置参数CanNmAllNmMessagesKeepAwake的使能情况。 38 | 39 | - **如果PNI = 1，且****CanNmAllNmMessagesKeepAwake = TRUE**，在RSS状态下收到NM Msg，**当前节点需要重置****NM-Timeout Time****r，节点的网络状态保持在RSS。**如果与节点相关的所有PNC = 0，不关联PNC的发送报文保持发送。如果与节点相关的PNC = 1，关联此PNC的发送报文和不关联PNC的发送报文保持发送； 40 | - ***\*如果PNI = 1，\******CanNmAllNmMessagesKeepAwake = FALSE**，在RSS状态下收到NM Msg，与节点相关的PNC均为0，当前节点不重置NM-Timeout Timer，当NM-Timeout Timer = 0时，节点进入PBSM状态，如果CANNM_WAIT_BUS_SLEEP_TIME超时，节点进入BSM(Bus-Sleep Mode)，节点休眠。 41 | 42 | Autosar解释如下所示： 43 | 44 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzQ3rO64LJiaG2FqRKrlLyWibbWicIJfMsZib65qIKMcSc6aCAicG4yKk3YPC8MQ9b393ceSaRA0nHYdnA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 45 | 46 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyP3p9jEnk3vRzHtwD1qv7QnyRDbYr9ibE8Mss5oBboz1hwxmvuFRicvOEG71SEY0YqQw0Kn9jZqrzg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 47 | 48 | - **如果PNI = 0，且****CanNmAllNmMessagesKeepAwake = TRUE**，在RSS状态下收到NM Msg，**当前节点需要重置****NM-Timeout Time****r，节点的网络状态保持在RSS，Autosar解释如下所示：** 49 | 50 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyP3p9jEnk3vRzHtwD1qv7QRGUyTFicbE3qup79omLicw4bMXyPKvDvRv3xxOtET9dUDOwuUnaeMB1w/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 51 | 52 | - ***\*如果PNI = 0，且\******CanNmAllNmMessagesKeepAwake = FALSE**，在RSS状态下收到NM Msg，当前节点不需要重置NM-Timeout Timer，当NM-Timeout Timer = 0，节点进入PBSM，如果CANNM_WAIT_BUS_SLEEP_TIME超时，节点进入BSM(Bus-Sleep Mode)，节点休眠，Autosar解释如下所示： 53 | 54 | 55 | 56 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyP3p9jEnk3vRzHtwD1qv7QVVfqN2O0oSo65ibXuNZ7XMO9axkrvYy89WP8iadxIEPJqcE0mvBicYdaQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)也就是说，**在RSS状态下，节点即使周期性接收到其他节点发送的网络管理报文，节点也可能休眠**。如上，就是本文的答案。 57 | 58 | **提示：**某些OEM中会要求：CanNmAllNmMessagesKeepAwake的设置与CAN transceiver的选型有关。比如：如果选择**具有**wakeup CAN的transceiver，CanNmAllNmMessagesKeepAwake = FALSE；如果选择**没有**wakeup CAN的transceiver，CanNmAllNmMessagesKeepAwake = TRUE。 59 | 60 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/quuOyCqONwdD16hI11wAQWxGp4ajJ4DMnbsHGb4ViandFryeibcQb1Idxb3MHmrh20988OSES3OU1wPTicQbAr94g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 61 | 62 | 63 | 64 | 参考资料 65 | 66 | SIMPLE TITLE 67 | 68 | AUTOSAR_SWS_CANNetworkManagement.pdf 69 | 70 | -------------------------------------------------------------------------------- /autosar/NM/Autosar网络管理：网络问题QA.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：网络问题QA 2 | 3 | 最近和一些读者讨论了一些Autosar网络管理相关问题，有几个问题做了一下梳理，再此和大家分享一下。 4 | 5 | ## Q1：CanNmImmediateRestartEnabled使能，NM PDU的外发行为？ 6 | 7 | **A1**：先说CanNmImmediateRestartEnabled的作用，在PBSM(Prepare-Bus-Sleep mode)模式下，收到总线的通信请求(比如：KL15硬线唤醒)，使能NM-PDU的发送，即：进入RMS状态。NM-PDU的发送行为如下所示： 8 | 9 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzkqL2nJHwQmInOymXvLRy6F1PAEmh66DP9BQHly6C2vyLcialLjHboI4gbSxjr2lThXays8KjFfow/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 10 | 11 | 上图可以看出，进入RMS模式以后，以正常的发送周期发送NM-PDU。 12 | 13 | 对于此问题，Autosar要求： 14 | 15 | - “CanNmImmediateRestartEnabled = true then CanNmImmediateNmTransmissions = 0”，意思是说，使能CanNmImmediateRestartEnabled，就没有快发模式； 16 | - “CanNmPnHandleMultipleNetworkRequests == True" then "CanNmImmediateNmTransmissions > 0”，意思是说，使能PN功能以后，需要快发模式。 17 | 18 | 可以看出，上述两点在实现时，只能使能其中一个。 19 | 20 | ## Q2：NM-Timeout何时重置？ 21 | 22 | **A2**：不讨论PN功能时。当节点收到/发送NM-PDU时，NM-Timeout重置，假设，某CAN网段内存在三个节点：ECU1、ECU2、ECU3，各个节点的NM-Timeout重置时机和网络状态如下所示： 23 | 24 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzkqL2nJHwQmInOymXvLRy6FMugqnO7DnP7OZSYlqaLic1CQRBT8whqQBU1Iag3ukLhQMiaKZcjRZUA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 25 | 26 | 提示：NO（Normal Operation）、RS（Ready Sleep）、PBSM（Prepare-Bus-Sleep mode）。黑色实心表示发送NM-PDU，黑色空心表示接收NM-PDU。 27 | 28 | 上图可以看出：每个节点释放网络的时机不确定，每个节点的网络释放时机，取决于节点的上层实现。注意，不是进入RS状态重置NM-Timeout。节点释放网络的时候，NM-Timeout继续递减，不会重置。当网段内没有节点发送网络管理报文，且NM-Timeout走完，所有节点一起进入PBSM模式。 29 | 30 | ## Q3：如何理解CAN通信的串行通信？**** 31 | 32 | **A3**：串行通信，就是用一个Pin发送/接收Bit位流信息。如下图：对于发送节点(uC1)，通过Controller的Tx Pin发送Bit位流信息，即：uC1发送报文。同时，uC1通过Controller的Rx Pin，回读自身发送的信息是否正确。对于同网段内的其他节点(uC2)，通过Rx Pin接收uC1的发送信息，即：接收报文。 33 | 34 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyczfibHN9PKEcPMz0JOY9fX2XASJk5BDiaNlPb8ZpAguPT88ib2YxFoC6GxYfWY38l5ealZEebLnkqA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) -------------------------------------------------------------------------------- /autosar/NM/Autosar网络管理：节点外发第一帧网络管理报文处理策略，再说一次.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：节点外发第一帧网络管理报文处理策略，再说一次 2 | 3 | 提示：基于Can总线讨论。 4 | 5 | ## 1、如何确保节点外发第一帧报文是网络管理报文？ 6 | 7 | **答**：在回答这个问题之前，我们需要清楚：**节点可以发送网络管理报文**，**说明此节点的网络类型不是Passive的**，这个前文有说明，可以回顾[Autosar网络管理：基础问题知多少](http://mp.weixin.qq.com/s?__biz=MzUyNDU4NTc1NQ==&mid=2247486784&idx=1&sn=bf632b1d953d812193a355a7b4e85b1e&chksm=fa2a5334cd5dda220361c955fa9f42850979a105977c0a97a8ae5fb5327bbbbd8e06c194f215&scene=21#wechat_redirect)。 8 | 9 | 首先，我们要清楚导致Node外发第一帧不是网络管理报文的原因，如下所示： 10 | 11 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzNCQmfJ3iaRnDatwwYysLlPOmvVz4fqh1LnOzOSXbKl8bUkXy4vQrUrfJnibOHegt8Tl0tWibffdD9Q/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 12 | 13 | 如上：假设应用报文所在区间0x00~0x4FF（一个节点一般包含多个应用报文），网络管理报文CanID所在区间：0x500~0x5FF，当前节点的网络管理报文CanID = 0x500。 14 | 15 | **具体解释**：当ECU被加电或者程序复位（t0时刻），完成初始化动作和准备工作，在t1时刻允许通信，此时如果应用报文和网络管理报文都请求发送，应用报文（这里主要指周期性应用报文）会被优先发送，因为应用报文的CanID优先级高于网络管理报文的CanID。 16 | 17 | **解决策略**：既然应用报文的优先级高，那么在第一次周期性应用报文发送的时候，将其Offset一段时间，让**网络管理报文在t1时刻发送**，**应用报文在t2时刻发送**即可避免该问题的出现，具体需要配置哪些模块参数，可以参考前文：[Autosar网络管理PN：路由超时大Bug](http://mp.weixin.qq.com/s?__biz=MzUyNDU4NTc1NQ==&mid=2247484944&idx=1&sn=796eb70b20d845359f5e019656773d1a&chksm=fa2a5864cd5dd17285e66df13316d623d54c04647e9a19bd697311df110883dbf8cb7a91a0ea&scene=21#wechat_redirect)，如下所示： 18 | 19 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzNCQmfJ3iaRnDatwwYysLlPTOgiaia6ibl2GtneLmXyPaUIgJtD6SAHOVrD3ks9ms96KaHHBxykhbx9g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 20 | 21 | 如上处理就万事大吉了吗？不一定，假设ECU3的网络管理报文CanID = 0x504，在其发送网络管理报文的时候，可能由于其网络管理报文CanID优先级低于其他节点网络管理报文的CanID，而导致其仲裁失败，如下所示： 22 | 23 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyPic7iapP5dwib7WklM6GntDcNOguppDYg6EBiaDlPCP7QRGLQZIAWFeEDR72wN5qqePlXicWnGIbR6Qw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 24 | 25 | 当然，也可能由于其他某些工况导致当前周期的网络管理报文发送失败，所以，为了确保网络管理报文的发送成功，需要确保其在当前周期发送失败以后，在下一个轮询周期(Task)内，再次尝试网络管理报文的发送，如下所示： 26 | 27 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzNCQmfJ3iaRnDatwwYysLlPricEe6ZD2SOicNtHSVIVsGIuruBK64X8waT7VpU5bFlYSH4AVRW3BKiaA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 28 | 29 | **提示**：在CanNM模块，配置CanNmRetryFirstMessageRequest参数即可实现NM Msg的重发。注意，如果当前节点的网络类型是Passive的，CanNmRetryFirstMessageRequest参数配置无效。 30 | 31 | 32 | 33 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/quuOyCqONwdD16hI11wAQWxGp4ajJ4DMnbsHGb4ViandFryeibcQb1Idxb3MHmrh20988OSES3OU1wPTicQbAr94g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 34 | 35 | 36 | 37 | 参考资料 38 | 39 | SIMPLE TITLE 40 | 41 | AUTOSAR_SWS_CANNetworkManagement.pdf -------------------------------------------------------------------------------- /autosar/NM/Autosar网络管理：问题纠错篇.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：问题纠错篇 2 | 3 | 如标题，本文对Autosar网络管理文章的一些表述进行纠错。再次感谢读者对我的包容和指正！我会继续扔砖头，接受大家的批评，之后改正，反馈大家正确的观点。 4 | 5 | ## 纠错1 6 | 7 | [Autosar网络管理：网络管理报文的收/发与网络管理时间配置参数解析](http://mp.weixin.qq.com/s?__biz=MzUyNDU4NTc1NQ==&mid=2247488000&idx=1&sn=fae533f0404e3c5cf4d570e9d625ba6d&chksm=fa2a4c74cd5dc562ba7be2c1e59dab384aaaf00efd597ed2d724c0ed56fc5c3a06447299ae1d&scene=21#wechat_redirect)一文中，提到这样一个观点 **“****3.有快速发送功能（网络被动唤醒）：在RMS状态下，先以快发周期发送一定次数的网络管理报文，eg：20ms发送10次，之后以正常周期发送网络管理报文，eg：500ms。****”** 8 | 9 | 此处表达不准确，收到网络管理报文（没有PN功能），被动唤醒(调用CanNm_PassiveStartUp()接口)，没有快发模式。即：被动唤醒没有快发模式。 10 | 11 | 快发模式需要满足的条件： 12 | 13 | 1. 节点非PASSIVE MODE； 14 | 2. 调用CanNm_NetworkRequest()接口主动请求网络； 15 | 3. CanNmImmediateNmTransmissions＞0。 16 | 17 | 看一下Autosar规范给的解释，如下所示： 18 | 19 | **CASE1**： 20 | 21 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwUiafg8qBOic9pg7WII3eia7qfqf76ODHSp2MueguETIGSaTlCI0y3miaLdOYNMWo3m9eUbp3xiaTkLow/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 22 | 23 | 可以看出，由BSM或者PBSM进入RMS，由CanNm_NetworkRequest()触发，且CanNmImmediateNmTransmissions＞0时，使能快发模式。 24 | 25 | **CASE2：** 26 | 27 | ![图片](https://mmbiz.qpic.cn/mmbiz_jpg/eEEQvxEw8vwUiafg8qBOic9pg7WII3eia7q1a0HptTAPB3NRibNP0DaYxY3xf76wOgI4wDoErOic6BwrH77MoVrOP5w/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1) 28 | 29 | CanNmPnHandleMultipleNetworkRequests = TRUE，可以理解为PN功能使能，调用CanNm_NetworkRequest()接口进入RMS状态时，CanNmImmediateNmTransmissions＞0，使能快发模式。 30 | 31 | **注意**： 32 | 33 | - CanNmImmediateNmTransmissions设置为1，没有意义，工程需求中，常见设置：10、20等； 34 | - CanNmRepeatMessageTime > CanNmImmediateNmTransmissions * CanNmImmediateNmCycleTime，即：快发模式限于RMS状态； 35 | - 快发功能使用时，CanNmMsgCycleOffset不再适用，既然都快发了，就是想快速唤醒网络，所以，没必要再延迟发送NM Msg。 36 | 37 | ## 纠错2 38 | 39 | [工程开发问题（七）：Flexray网络状态切换错误，通信异常](http://mp.weixin.qq.com/s?__biz=MzUyNDU4NTc1NQ==&mid=2247488954&idx=1&sn=ff07bd826e514cc2f70605a9f2124594&chksm=fa2a4bcecd5dc2d81f605918b23a52dfcd946ed0efbb5b103f514608d289e5de6f617aa02e48&scene=21#wechat_redirect)一文中，说到：“ 40 | 41 | Fr节点进入RSS状态以后，即使本节点有内部网络请求（Network Request，比如：VFC置位），节点也不会进入NOS状态。”，该表达不准确。完整的解读Autosar规范如下所示： 42 | 43 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwUiafg8qBOic9pg7WII3eia7qSVILCibA5YCn4A1KpsIRgCgHx0V7KknRaYT27oOZM4SwrdmJmBd5Tfw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 44 | 45 | 意思是说，Flexray节点在RSS状态下，如果同时满足如下条件： 46 | 47 | 1. FrNm_ReaySleepCnt>0； 48 | 2. FrNm_NetworkRequest=TRUE，主动调用FrNm_NetworkRequest()接口； 49 | 3. FrNM_RepeatMessage=FALSE。 50 | 51 | 在当前Repetition Cycle结束后，Flexray节点的网络状态由RSS进入NOS状态。 52 | 53 | ## 网络管理问题QA 54 | 55 | **Q1**：**Application软件升级，$11复位后，节点处于何种网络状态？** 56 | 57 | **A1**：本问题源于一个朋友的讨论。在此，说一下个人理解。正常的刷写流程中，一般操作如下： 58 | 59 | Step1：拓展会话($10 03)中，使用功能寻址将总线上的所有节点通信（0x28服务）和DTC监控（0x85服务）禁用，功能寻址一直在周期性发送$3E 80（维持会话）； 60 | 61 | Step2：使用物理寻址升级目标ECU（进入编程会话，$10 02），比如：下图的ECU3； 62 | 63 | Step3：ECU3升级完成以后，使用物理寻址发送$11 01服务，复位ECU3； 64 | 65 | Step4：等待一定时间（比如：2s）,功能寻址发送$10 03服务，使ECU3进入拓展会话； 66 | 67 | Step5：再等待一定时间（比如：2s）,功能寻址发送$28服务，使能所有节点通信； 68 | 69 | ...... 70 | 71 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwUiafg8qBOic9pg7WII3eia7qyMVbSWez2uS0eyQMGth61y1ic3V44b0NRicM8PgOnThK7lDl832C2L6Q/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 72 | 73 | **具体解释：** 74 | 75 | Step3中，发送$11 01使ECU3复位，ECU3执行复位，由Boot跳转到Application，Application程序初始化，Application程序运行起来，需要一定时间，这是上位机（Tester）延迟2s的作用(确保Application程序已经完成初始化动作)，这个时间内ECU3节点网络处于BSM（Bus Sleep Mode）模式； 76 | 77 | Step4中，功能寻址发送$10 03服务，主要使ECU3进入拓展会话。在升级ECU3的过程中，由于Tester一直周期性发送$3E 80（避免因S3超时，ECU1、ECU2进入默认会话，使得通信和DTC控制失效），ECU1和ECU2一直在拓展会话呆着。 78 | 79 | Step5中，又经过2s时间，Tester发送$28 00服务，开启通信。提示：$28服务针对非诊断报文的通信（比如：网络管理报文、应用报文），主要是把总线让给诊断报文，提高刷写速率。所以，ECU3只要完成启动流程，Controller和Transceiver进入Normal模式，ECU3就可以正常接收诊断报文。如果开发的ECU要求网络管理报文唤醒网络，此时ECU3节点的网络状态处于何种模式呢？答：个人理解，BSM。虽然上位机从请求ECU复位到发送$28服务（开通信）间隔了4s时间，但是这4s时间内有一定的时间ECU在完成初始化（一般要求100~300ms时间范围）。 80 | 81 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzkqL2nJHwQmInOymXvLRy6Z1WJniaUJsXbVHu24XBuTUOPTp5qY9xbnGJxUMwezrgW2aSP94uncBg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 82 | 83 | 84 | 85 | 如上图： 86 | 87 | T0时刻，ECU3收到$11 01复位，一般程序会在Boot呆一定时间，比如：50ms（Stay In Boot功能），之后识别到App程序有效，Jump到App，完成App初始化，在OS RUN之前需要100~300ms时间不等（每个项目的代码量和功能有所不同，耗时不同）。 88 | 89 | 到T2时刻使能通信之前的这段时间，ECU3处于BSM模式，原因：没有收到有效的唤醒事件（比如：没有收到网络管理报文）。注意：ECU1和ECU2一直处于NM（Network Mode），因为诊断报文在一直维持两者的网络状态。 90 | 91 | T2时刻，ECU1和ECU2的通信使能，可以发送网络管理报文和应用报文，ECU3接收到网络管理报文以后，进入NM，ECU3相当于被动唤醒。 92 | 所以，从ECU3复位，到接收到$28 00服务，近4s的时间内，ECU3的网络状态处于BSM模式。 93 | 94 | **注意**： 95 | 96 | - 再次提醒：不要混淆ECU唤醒和网络唤唤醒。虽然ECU3收到诊断报文，可以处理诊断服务，但是诊断报文并不是有效的唤醒源，如果Transceiver没有硬件过滤功能，诊断报文可以将ECU唤醒（uC被供电），但是网络并未唤醒，此时ECU会保持一定时间验证唤醒事件的有效性，比如：3s等； 97 | - 有些节点的Transceiver有过滤功能，即：只能有效的网络管理报文被接收，所以，冷启动时，诊断报文，ECU接收不到； 98 | - 某些ECU的开发中，会将诊断报文作为有效唤醒源，即：网络管理报文一样，可以唤醒网络，诊断报文和注意识别。 99 | 100 | ## $11 01诊断服务思考 101 | 102 | 工程中，ECU刷写后，需要$11 01执行uC的复位，这个复位可以操作PORST Pin，控制uC的Vcc供电（5V），使得uC完成一个热启动过程，即：ECU复位。注意，这个复位动作，虽然也给uC重新供电，但是，它不同于KL15硬线上电，不能看作主动唤醒，所以$11 01诊断复位不能触发网络的主动唤醒。 103 | 104 | **提示**：$11 01复位，执行uC的下电流程，需要执行NVM的存储。 105 | 106 | 如下通过控制SBC（System Basis Chip）实现uC复位，也可以通过控制外部看门狗实现。 107 | 108 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzkqL2nJHwQmInOymXvLRy6Hkqd8edeMO8cCoIZJkeicd9PXc7yN9vp9FKpUIdHOApQrNuIkSWcsOA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 109 | 110 | -------------------------------------------------------------------------------- /autosar/NM/Autosar通信栈：FullCAN和BasicCAN基础.md: -------------------------------------------------------------------------------- 1 | # Autosar通信栈：FullCAN和BasicCAN基础 2 | 3 | 在搞清楚FullCAN和BasicCAN是什么之前，我们先搞清楚一些基础的东西。 4 | 5 | 1 6 | 7 | 基础概念 8 | 9 | **提示：**以英飞凌tc397为例。 10 | 11 | ## 1、CAN Module与CAN Node、Controller关系 12 | 13 | 平时开发中，我们说“ECU有3路CAN”，所说的“3路CAN”和3个Node是一个概念吗？不是。**我们平时所讨论的“3路CAN”是指3个网络，也就是我们口语中的“节点”**。而芯片手册中（Data Sheet），一个CAN Module会包含多个Node（即，Controller），比如：tc397芯片手册中，MCMCAN Module包含3个CAN Module，每个Module包含4个Controller，如下所示： 14 | 15 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyP3p9jEnk3vRzHtwD1qv7QTOupsu9gtN6CrfG1cALymPHVXpqmf6Dvvh3SicRgiaTq8IAzGshhrByw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 16 | 17 | **2、Controller与Transceiver关系** 18 | 19 | 在实际的使用中，**一个Controller必须配一个Transceiver**，Controller+Transceiver = Network，如下所示： 20 | 21 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzIkpfAqvqURIgo9x6ZSibKFAUdoUMJoAC6ORic0PXZHNj7HYNkT8w70dMyiaPZ3q54tzTryxgzHmicUA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 22 | 23 | 所以，平时我们口语话的“3路CAN”是指3个Controller+Transceiver组合，即：3个Network，我们也常称“3个节点”。 24 | 25 | ## 3、Controller与RAM资源关系 26 | 27 | 刚提到，tc397中，一个CAN Module包含4个Controller，那每个Controller可以发送多少个CAN报文，接收多少个CAN 报文呢？这里我们要区分硬件缓存CAN报文的数量和项目中要求发送/接收报文的数量。 28 | 29 | - **硬件缓存CAN报文数量**：是指上层请求发送报文或者接收报文时，CAN驱动最多能缓存的数量； 30 | - **项目中要求发送/接收报文的数量**：是指当前节点要外发或者接收的报文数量。 31 | 32 | 以发送CAN报文数量为例：需求要求当前网络节点发送100帧CanID不同的CAN报文，实际该节点CAN Controller可用的硬件发送缓存区最多有32，意味着底层硬件最多缓存32帧发送报文，如果超过32帧发送请求，则会因没有硬件空间缓存而发送请求失败。 33 | 34 | tc397 CAN Module资源情况如下所示： 35 | 36 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzIkpfAqvqURIgo9x6ZSibKF2bcwyJRCrEEf4KvXGFQicmD7cyoL2lGFcVO18d1JHGa9YKqJCd94jEw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 37 | 38 | **提示**：上图中的Controller用“Node”表示。 39 | 40 | 由上可以看出，3个CAN Module，共12个Controller。**每****个CAN Module（4个Controller）****共用32个发送Tx Buffer，共用64个Rx Buffer**... 41 | 42 | 对于发送缓冲区，每个CAN Module共用32个发送缓冲区，如果配置了32个Tx Dedicated Buffer，则没有空间配置Tx FIFO/Queue；同理，每个CAN Module虽然有两个Rx FIFO，如果配置了64个Rx Dedicated Buffer，则没有空间配置Rx FIFO。一般，Tx/Rx Buffer配置时，会混合使用，比如： 43 | 44 | - 20 Tx Dedicated Buffer+ 12 Tx Queue 45 | - 40 Rx Dedicated Buffer+ 24 Rx FIFO 46 | 47 | MCMCAN Module RAM区地址划分顺序如下所示： 48 | 49 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzIkpfAqvqURIgo9x6ZSibKFA37htL34icV7o1AmFSejvNesdAic7pMB8eEOd7c4qKfuia9TlkUo5e4zw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 50 | 51 | ## 4、Mailbox、HRH、HWObject 52 | 53 | **Mailbox**：邮箱，就是CAN驱动所具有的接收缓存区和发送缓存区，接收缓存区和发送缓存区均在RAM区。 54 | 55 | **HWObject**：硬件对象，包含CAN ID、DLC、Data等信息的RAM区。 56 | 57 | **HRH**：Hardware Receive Handle，接收句柄，一个HRH表示一个接收HWObject。 58 | 59 | **HTH**：Hardware Transmit Handle，发送句柄，一个HTH表示一个发送HWObject。 60 | Mailbox、HWObject、HRH、HTH、Controller、Transceiver之间的关系如下所示： 61 | 62 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzIkpfAqvqURIgo9x6ZSibKF3z1Arrc59KyI1Upliashib6zibn0zG3Cy6hrCROfMFzKKkw7QK16yBkmA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 63 | 64 | 2 65 | 66 | FullCAN和BasicCAN是什么？ 67 | 68 | 首先，FullCAN和BasicCAN是CanIf模块配置的参数。 69 | 70 | - **BasicCAN**：一个HWObject(Hardware Object)可以处理一段范围的CanId 71 | - **FullCAN**：一个HWObject(Hardware Object)只能处理单个CanId 72 | 73 | Autosar对FullCAN和BasicCAN的解释如下所示： 74 | 75 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzIkpfAqvqURIgo9x6ZSibKFUxlKELUXcL84DtzfE0ygLqMac2xeDBYuMfCLwcJMEr1on4EmVmibziag/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 76 | 77 | 将上述的解释进一步细化，如下所示： 78 | 79 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzIkpfAqvqURIgo9x6ZSibKFczZfiaEJfRbA47wpfZoaSKCDJcjEaiaCtPfGibGM1CvL5puh3cbPmJCtw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 80 | 81 | 使用工程中，MCAL会将缓存区分配成FIFO和Dedicated Buffer，FIFO和Dedicated Buffer的区别是什么呢？Dedicated Buffer区域，**Hareware Object与HRH/HTH一一对应**，而FIFO区域，**一个****HRH/HTH对应多个Hareware Object**，如下所示： 82 | 83 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxSRuDpmo2G7icibBqU2lo7hQWY2QwxGHGRGqxOWZCUia8zPrwgiayqNNGH9mmOZDk8zswtBm9gtbrtyQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 84 | 85 | 3 86 | 87 | 为什么需要FullCAN和BasicCAN？ 88 | 89 | 在CAN驱动层，可以通过过滤的方式，过滤一段范围内的CanID，也就是说：会有一段范围内的报文接收进来，但是接收进来的这一段范围的报文并不一定都是上层所需要的，怎么办呢？用软件方式，再过滤一遍，由CanIf过滤所需要的CAN报文。因此，提出了FullCAN和BasicCAN的概念。 90 | 91 | 比如：HRH对应BASIC CAN类型，接收CanID范围：0x10~0x18，CanIf根据过滤算法，在0x10~0x18范围内过滤出需要的0x10、0x13、0x14、0x16、0x17送给上层，而其余的丢弃，如下所示： 92 | 93 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxSRuDpmo2G7icibBqU2lo7hQp0RzZmbADuWoyXhVMkLsAu7XjBYzoy3H9lJSZ3TkaZnqG0XC3h6d2w/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 94 | 95 | CanIf可以通过设置CANIF_HRHRANGE_LOWER_CANID、CANIF_HRHRANGE_UPPER_CANID方式过滤，也可以通过设置CANIF_HRHRANGE_BASEID、CANIF_HRHRANGE_MASK进行过滤。 96 | 97 | ## 不同报文类型如何选择FULL CAN/BASIC CAN 98 | 99 | **应用报文**：一般选择配置成FULL CAN类型，对于应用报文，一般不需要缓存，使用最新接收的数据即可。对于发送的应用报文，都配置成FULL CAN类型需要一个前提：**上层需要****发送应用报文数量＜底层硬件缓存区数量**。比如：底层发送硬件缓存区数量为32，节点需要发送的应用报文数量为50，显然无法将50个发送的应用报文都配置成FULL CAN。遇到这种情况，一般会将重要的应用报文配置成FULL CAN，而其他要发送的应用报文配置成BASIC CAN。这样配置以后，硬件缓存区的分配就需要混用，即：Dedicated Tx Buffers+Tx Queue或者 Dedicated Tx Buffers+Tx FIFO，如下所示： 100 | 101 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyP3p9jEnk3vRzHtwD1qv7QwR6L9ASvOFTbqlKlsZ1vfGzDOxJibHaVKqvprfrcfXTTTJlCc6YajdQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 102 | 103 | 如上图，ID3、ID15、ID20是比较重要的应用报文，配置成FULL CAN，分别给一个独立的缓存区；其他的缓存区则配置成BASIC CAN，即：一个缓存区可以发送多个不同CanID的报文。 104 | 105 | **诊断报文**：一般选择配置成BASIC CAN类型（结合FIFO Buffer使用），因为诊断报文的请求/响应不能错序，需按照顺序处理，且数据不能覆盖； 106 | 107 | **网络管理报文**：接收一般选择配置成BASIC CAN类型，因为一个节点一般会要求接收一段范围的网络管理报文，eg:0x500~0x53F。发送网络管理报文配置成FULL/BASIC CAN类型均可，如果资源够用，推荐配置成FULL CAN类型，因为每个节点的发送网络管理报文唯一； 108 | 109 | **标定报文**：一般选择配置成FULL CAN类型。 110 | 111 | 112 | 113 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/quuOyCqONwdD16hI11wAQWxGp4ajJ4DMnbsHGb4ViandFryeibcQb1Idxb3MHmrh20988OSES3OU1wPTicQbAr94g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 114 | 115 | 116 | 117 | 参考资料 118 | 119 | SIMPLE TITLE 120 | 121 | Infineon-AURIX_TC3xx_Part2-UserManual-v01_00-EN.pdf 122 | 123 | AUTOSAR_SWS_CANInterface.pdf -------------------------------------------------------------------------------- /autosar/NM/Autosar通信栈：I-PDU、N-PDU、L-PDU，要掰扯清楚.md: -------------------------------------------------------------------------------- 1 | # Autosar通信栈：I-PDU、N-PDU、L-PDU，要掰扯清楚 2 | 3 | 学习协议规范实际在学啥？我的理解：学“规矩”。“规矩”就是规范里的细枝末节，不能囫囵吞枣。当然，我是一个Autosar学徒，很多细节掌握的不到火候，需要读者不断的指正，大家一起进步。本文，和大家聊一下Autosar通信栈中，各层级对应的PDU表达方式。 4 | 5 | 1 6 | 7 | Autosar通信栈层级架构 8 | 9 | Autosar的分层架构没有完全按照OSI的七层模型定义，可以将Autosar的模型大致分为：数据链路层、网络层、交互层，如下所示： 10 | 11 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyhiaaqUZAdRnKlaSx6KRhuTYnq4mQq0ZSicU3AwJDTb4FEMVnlIdicIN0Uq2fibqYH1iaicMjkfhg9pSlA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 12 | 13 | 由上图，我们可以看出：每个层级都会包含PCI和data Structure，PDU = PCI + data Structure，SDU = data Structure。 14 | 15 | PCI、SDU、PDU又都是啥呢？咱们看一下官方解释： 16 | 17 | | **Abbreviations** | **Description** | 18 | | ----------------- | ------------------------------------------------------------ | 19 | | **SDU ** | **Service Data Unit**. It is the data passed by an upper layer, with the request to transmit the data. It is as well the data which is extracted after reception by the lower layer and passed to the upper layer. ***A SDU is part of a PDU\***. | 20 | | **PCI** | **Protocol Control Information**. This Information is needed to pass a SDU from one instance of a specific protocol layer to another instance. E.g. it contains **source and target information**. *The PCI is added by a protocol layer on the transmission side and is removed again on the receiving side.* | 21 | | **PDU ** | **Protocol Data Unit**. The PDU contains SDU and PCI. On the transmission side the PDU is passed from the upper layer to the lower layer, which interprets this PDU as its SDU | 22 | 23 | 对应到实际的开发，PCI可以理解为头部信息，比如：CanTp，在发送数据的时候，会添加SF、CF、FF、FC信息等；data Structure就是要发送的信息，用一个结构体表示，结构体里会有数据存储起始位置（指针），数据长度。 24 | 25 | data Structure（即：PduInfoType）的具体声明形式示例，如下所示： 26 | 27 | - 28 | - 29 | - 30 | - 31 | - 32 | - 33 | - 34 | - 35 | 36 | ``` 37 | typedef uint8 PduLengthType;typedef uint8* SduDataPtrType; 38 | typedef struct{ SduDataPtrType SduDataPtr; PduLengthType SduLength;} PduInfoType; 39 | ``` 40 | 41 | 示例如下所示： 42 | 43 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyhiaaqUZAdRnKlaSx6KRhuTAAQFCpYwJgcks2s7mWp6Z6NrwekL6CFuhgASc8ot7ez56IrcrtkhHw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 44 | 45 | 2 46 | 47 | I-PDU、N-PDU、L-PDU关系 48 | 49 | L-PDU、N-PDU、I-PDU三者的关系如下所示： 50 | 51 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyhiaaqUZAdRnKlaSx6KRhuTxEuOQ9qqxqmhibNsPKUyN1mYibJYsk7nraj0IzpdzIqSATzJf67jozXQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 52 | 53 | L-PDU：对应链路层的PDU，一般来说，我们称接口层(Interface，XX_If)为链路层，比如：CanIf、FlexrayIf等。更确切地说是**Driver**和**Interface**构成链路层。我个人觉得Driver作为链路层更合适，Interface毕竟是抽象模块，与硬件不是强绑定的关系，比如：以太网中，MAC层为链路层，与芯片平台强相关。 54 | 55 | N-PDU：网络层对应的PDU，一般来说，我们称传输层(Transport，XX_Tp）为网络层，比如：CanTp、FlexrayTp等。 56 | 57 | I-PDU：交互层（表示层）对应的PDU。交互层都有哪些模块？如下图所示： 58 | 59 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyhiaaqUZAdRnKlaSx6KRhuTWV4Qnx6c12Rz45ooOl1QqKdc5CBYWtOtpQ4gXiabiaDNKNIFyHJzPBOw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 60 | 61 | XX_If以上模块的信息交互依赖I-PDU，注意：XX_If与XX_Tp模块的交互依赖N-PDU。 62 | 63 | 一般来说，小数据传输时，用XX_If；大数据传输时，用XX_Tp。所以，在诊断的多帧传输时，XX_Tp层会将**多个N-PDU**缓存，直到**一个完整的I-PDU**接收完，之后通过PduR送给DCM，即：I-PDU = n * N-PDU（n是大于1的正整数）。 64 | 65 | **参考资料** 66 | 67 | ISO 14229-1_2013(E).pdf 68 | 69 | AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf -------------------------------------------------------------------------------- /autosar/NM/Autosar通信栈：发送返回OK和发送确认是一回事吗.md: -------------------------------------------------------------------------------- 1 | # Autosar通信栈：发送返回OK和发送确认是一回事吗 2 | 3 | 先给出问题答案：不是。 4 | 5 | 1 6 | 7 | 发送返回值(Std_ReturnType) 8 | 9 | 以CAN发送为例，当某帧报文需要发送的时候，调用的发送接口会有一个返回状态值，该值表明当前数据的**发送请求状态**。比如：CanIf_Transmit()接口会有一个Std_ReturnType类型的返回状态(E_OK、E_NOT_OK)。 10 | 11 | - E_OK：表明当前数据已经成功放入底层硬件缓存区中，**发送请求成功**，之后等待发送。 12 | - E_NOT_OK：表明当前数据未能成功放入底层硬件缓存区中，发送请求失败。 13 | 14 | 如果数据不能成功放入底层硬件缓存区中，也就意味着数据不能被发送到总线。不能成功放入底层硬件缓存区的原因有哪些呢？可能因为总线Busoff，也可能因为底层硬件缓存区已满。 15 | 16 | CanIf_Transmit()函数原型如下所示： 17 | 18 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxWdPtdEN3L8ca5Oe7POibpFWyqzPicuZZZ9ibB2iawKWqmlOWD2qBK8WnoGMd5eLZ95ibm5EdoAZheKQA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 19 | 20 | 2 21 | 22 | 发送确认(TxConfirmation) 23 | 24 | 程序中，上层需要获悉数据是否成功发送到总线上，以便于选择之后的执行动作。上层怎么知道数据是否发送到总线上了呢？显然，通过发送接口的返回值是不能知道数据是否成功发送到总线上，只能知道数据成功放入底层硬件缓存区与否。此时，就需要上层在底层注册一个回调函数，当放入底层缓存的数据成功发送到总线以后，可以通过该回调函数告知上层，该回调函数可以放在中断中，也可以放在main函数中（Polling方式通知上层数据发送结果）。 25 | 26 | CanIf_TxConfirmation函数原型如下所示： 27 | 28 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxWdPtdEN3L8ca5Oe7POibpFYl24VJoEFY3tq0pWwAc6Xsz2Hic5gWs6cUYxayM6AEcJeHuwGCprZQw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 29 | 30 | CanIf是CAN驱动层的上层，CanIf在CAN驱动层注册回调函数CanIf_TxConfirmation，当CanIf请求发送的数据成功发送到CAN总线以后，CAN驱动层通过此函数告知CanIf，CanIf请求发送的数据成功发送到CAN总线。 31 | 32 | 以此类推，CanIf上层模块的数据发送请求和发送状态，使用同样的数据处理方式。 33 | 34 | 以上可以知道，发送请求和发送确认是异步行为，发送请求和发送确认的时间不同。 35 | 36 | **注意**：即使待发送数据已经成功放到底层硬件缓存区，如果发生Busoff，则硬件缓存区待发送数据被清除，数据无法发送到总线上，将不会发送确认。 37 | 38 | 以中断通知方式为例，数据发送请求和发送确认通知流程如下所示： 39 | 40 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxWdPtdEN3L8ca5Oe7POibpFMJAeVglvQH5WA2fXNf1g3e7tFMI9qZpibFRMjUcvPJT2972ibNnK9jcQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 41 | 42 | **总结：**发送接口的返回值表示**请求****发送的数据****是否成功放入底层硬件缓存区**，而发送确认则表示**数据成功发送到总线与否**。 43 | 44 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/quuOyCqONwdD16hI11wAQWxGp4ajJ4DMnbsHGb4ViandFryeibcQb1Idxb3MHmrh20988OSES3OU1wPTicQbAr94g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 45 | 46 | 47 | 48 | 参考资料 49 | 50 | SIMPLE TITLE 51 | 52 | AUTOSAR_SWS_CANInterface.pdf 53 | 54 | -------------------------------------------------------------------------------- /autosar/NM/Autosar通信栈：基础问题知多少(二).md: -------------------------------------------------------------------------------- 1 | # Autosar通信栈：基础问题知多少(二) 2 | 3 | "走得越远见识越多，认识的人越多，你就越能体会到，人这一辈子你真的在意的，同时又在意你的，就那么几个。这几个就是你全部的世界。三两知己，爱人在侧，父母康健，听起来平平无奇，但已经是中等偏上的人生答卷了。" 4 | 5 | --《人世间》“李潈”评论 6 | 7 | ## QA1、Rx Signal Filter有何用？ 8 | 9 | **答**：Rx Signal Filter有什么用呢?通信开发中，大家应该碰到过这样的问题：信号阈值判断。举例：车速信号（Vehicel_Signal）用一个uint16数据类型表示，Vehicel_Signal有效取值范围：0~300Km/h，如果Vehicel_Signal ＞ 300Km/h，则丢弃该信号，保持上一次的有效值。所以，使用Rx Signal Filter，即可处理类似的问题。 10 | 11 | 一个I-PDU会包含1~N个Signal（N为大于1的正整数），这些Signal可以不包含在任何SignalGroup中，也可以包含在多个SignalGroup中。 12 | 13 | 为更好地理解Signal Filter，这里讨论一下信号的接收处理流程： 14 | 15 | **Step1、**COM模块收到一个I-PDU，该I-PUD包含5个信号：Signal00、Signal01、Signal02、Signal03、Signal05。其中Signal01、Signal03、Signal05属于SignalGroup01; 16 | 17 | **Step2、**在COM层，将接收到的I-PDU拆分成Signal，如果信号有Filter Condition，则进行Filter Condition判断； 18 | 19 | **Step3、**如果Filter Condition = FALSE，则丢弃该信号，**对应的Rx Signal Buffer不更新**。如果Filter Condition = TRUE，则更新信号对应的Rx Signal Buffer； 20 | 21 | Autosar规范对Filter Condition的解释如下所示： 22 | 23 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyTgId0OibCnOsDBibr7aw9UuSjj4DaOC2w2bBHeMuUlMc8nVuVoz6agXB1pKIqv95nz3bdqQTibUEKg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 24 | 25 | Autosar规范中解释Signal Filter Condition = False，如果这个Signal不在SignalGroup中，该**信号**对应的接收缓存区数值无需更新；如果这个Signal**在SignalGroup中**，该**信号组**对应的接收缓存区数值无需更新，即：保存上次值，如下所示： 26 | 27 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyTgId0OibCnOsDBibr7aw9Uubz5UNCnkI5D6bm3qg37fbt0SrxWy8S5ZTqQ7NsHUM5VH74ShYyibCOQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 28 | 29 | **Step4、**如果信号不属于任何的SignalGroup，上层可以直接调用Com_ReceiveSignal()接口，从Rx Signal Buffer获取信号数据。如果信号属于某个SignalGroup，则需要通过Com_ReceiveSignalGroup()接口，将信号数据从Rx Signal Buffer缓存区Copy到SignalGroup Rx Buffer(shadow buffer)，之后上层再通过Com_ReceiveSignal()接口读取信号值。 30 | 31 | Rx Signal接收流程如下所示： 32 | 33 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyTgId0OibCnOsDBibr7aw9Uu7U4PoBX396nfcUic6G1iaIurxhd6LQkMprTtE9y5atiboXjhS8TqQOsuA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 34 | 35 | ## QA2、Tx Signal Filter与Tx Mode有何关系？ 36 | 37 | **答**：从QA1中，可以知道Rx Signal Filter可以检查信号阈值。那么Tx Signal Filter能否也检查信号阈值呢？Autosar规范给出了解释，如下所示： 38 | 39 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyTgId0OibCnOsDBibr7aw9Uuc8ubaur0tBoibn3r9u77Yc436rI85fVggDiapic8h0JNOZASzF3kHHvHg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 40 | 41 | 总结：Tx Signal Filter不能检查信号发送的阈值，只是I-PDU发送模式的判断依据。Tx I-PDU有哪些发送模式呢？ComTxModeTrue或者ComTxModeFalse。如下通过一个示例分析ComTxMode与Tx Signal Filter关系： 42 | 43 | **Step1、**如果信号不包含在任何TxSignalGroup中，上层通过调用Com_SendSignal()接口，直接更新Tx Signal Buffer。如果信号包含在某个TxSignalGroup中，上层通过调用Com_SendSignal()接口，更新SignalGroup Tx Buffer(Shadow Buffer)中信号数据，之后通过Com_SendSignalGroup()接口更新Tx Signal Buffer； 44 | 45 | **Step2、**通过Filter Condition检查Tx Signal过滤条件； 46 | 47 | **Step3、**TMS(Transmission Mode Selector）判断Tx I-PDU中每个Signal的发送模式接口，如果其中一个Signal的检查结果是TRUE，则Tx I-PDU选择ComTxModeTrue发送行为；如果所有的Signal的检查结果均为FALSE，则Tx I-PDU选择ComTxModeFalse发送行为。 48 | 49 | Tx Signal的发送行为如下所示： 50 | 51 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyTgId0OibCnOsDBibr7aw9UuH9G14s1t53obibMmK8G4jKjjSck72puoVFY4KG2j9qubGPZibwa4lTwQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 52 | 53 | ## QA3、ComTxModeTrue、ComTxModeFalse使用场景？ 54 | 55 | **答：**为什么一个Tx I-PDU会有ComTxModeTrue、ComTxModeFalse**发送模式**呢？一个Tx I-PDU的**发送类型**有：DIRECT、MIXED、PERIODIC。 56 | 57 | DIRECT：事件型，比如：连续发送3次，发送最小间隔20ms。 58 | 59 | PERIODIC：周期型，比如：每100ms发送一次。 60 | 61 | MIXED：包含DIRECT、PERIODIC两种发送行为。 62 | 63 | ComTxModeTrue、ComTxModeFalse可以存在这样的使用场景：Tx I-PDU Mode = TRUE时，使用PERIODIC发送行为；Tx I-PDU Mode = FALSE时，使用DIRECT发送行为。 64 | 65 | ## QA4、Tx Signal的发送行为注意事项 66 | 67 | **答**：上层通过RTE调用Com_SendSignal()接口，更新需要发送Signal数值，注意：此时信号数值只是更新到了发送缓冲区。信号值的发送，依赖信号所在的Tx I-PDU周期。同时，COM层的发送主函数Com_MainFunctionTx()周期判断每一个Tx I-PDU周期到时与否，如果Tx I-PDU周期到时，调用PduR的发送接口发送Tx I-PDU. 68 | 69 | **对于周期型报文**，假设：Com_MainFunctionTx()周期 = 10ms，周期型报文Tx I-PDU对应的发送周期为30ms，发送行为如下所示： 70 | 71 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyTgId0OibCnOsDBibr7aw9UuBt0VC3Fjo2gNMQviccD9tcRicFGID0r1icYchH8pflUS7PYsicibricZicabg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 72 | 73 | 需要注意：上层信号的更新频率不应超过Tx I-PDU的发送周期，否则信号值被覆盖，如下所示： 74 | 75 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyTgId0OibCnOsDBibr7aw9UuhsHAH38xqzfIzzia4uhZeyeBGOhPUnzBINLtMeFZsPSKpB5wXlOXbZg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 76 | 77 | 大家可能在想：使用Queue机制不可以吗？信号数据队列发送，遗憾的是：目前，Autosar规范中的信号发送行为，不考虑Queue。 78 | 79 | **对于事件型报文**，假设：Com_MainFunctionTx()周期 = 10ms，事件型报文Tx I-PDU对应的最小发送间隔为20ms，发送行为如下所示： 80 | 81 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyTgId0OibCnOsDBibr7aw9UuUNLHXjNoJBTPmNUo1tmUPibPLN1RCsOC81gBrCavMhvoUUuAMuz78tQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 82 | 83 | 同样，上层信号的更新频率过快，会导致发送信号的数值被覆盖，如下所示： 84 | 85 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyTgId0OibCnOsDBibr7aw9Uu4DYygOXNXfA0GKw9AXNrHC3LypWI1j1APGutwa7Npdz3KlNQyWllzg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 86 | 87 | 88 | 89 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/quuOyCqONwdD16hI11wAQWxGp4ajJ4DMnbsHGb4ViandFryeibcQb1Idxb3MHmrh20988OSES3OU1wPTicQbAr94g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 90 | 91 | 92 | 93 | 参考资料 94 | 95 | SIMPLE TITLE 96 | 97 | AUTOSAR_SWS_COM.pdf -------------------------------------------------------------------------------- /autosar/NM/Autosar通信栈：基础问题知多少.md: -------------------------------------------------------------------------------- 1 | # Autosar通信栈：基础问题知多少 2 | 3 | 积土而为山，积水而为海。——荀子 4 | 5 | ## QA1：CAN报文发送，有优先级吗？ 6 | 7 | **答**：有。以英飞凌tc3xx系列为例，MCMCAN模块有多个硬件发送缓冲区，也就是说同一时刻可以缓存多个待发送的报文，这些报文放入待发送的缓冲区以后，会置位发送Pending标志，等待发送，谁先发送呢？在回答这个问题之前，我们先说待发送的报文在硬件缓存区中的存储方式：Dedicated Tx Buffers 、Tx FIFO、 Tx Queue。 8 | 9 | 对于Dedicated Tx Buffers与 Tx Queue两种存储方式，根据lowest Message ID原则发送，即：发送的CanID数值越小，优先级越高。具体发送顺序示例如下： 10 | 11 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzoAgzzT5e9T6WOIYgSMsLicRb5hPLWc6C63KwezqyGUPWsicQ0GG1xibaxPlyT8wF74ODhZRnz3VLYQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 12 | 13 | 对于Tx FIFO存储方式，报文的发送顺序由进入FIFO缓存区的先后顺序决定，即：先进先出，具体发送顺序如下： 14 | 15 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzoAgzzT5e9T6WOIYgSMsLicHB28mCFAxriblnSfzBFuYoZvzdTU7PwSACF8EUJsPA5osBw9eKzzqTA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 16 | 17 | 如果使用Dedicated Tx Buffers与 Tx Queue两种存储方式，优先级低的报文(比如：网络管理报文、诊断报文、标定报文等，优先级比应用报文低），是不是永远得不到发送了？不是，我们要清楚：发送的硬件缓存区不止一个，而是多个（比如：tc397有32个发送缓冲区），足以在某一时刻缓存多个待发送的报文。是否存在某一时刻（如下t1），发送报文的个数超过硬件缓存区个数？这种可能性是存在的，这也是为什么会有发送报文丢帧的原因。 18 | 19 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzUWHKOibQVqT0GBibugKVCOia3BhGbjJ130ib0yjdHYzFtJBgDAiaX0iacG9gb2s8T84QyDn93wK3Q45LA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 20 | 21 | 为了避免发送丢帧或者周期性报文抖动问题，我们可以将**相同周期性报文**的发送做一个Offset处理，**避免周期性相同的报文以同一个基准时间计时**。比如：通信启动后，周期性报文Msg01(周期10ms)在t0时刻开始周期性发送；而周期性报文Msg02(周期10ms)在t1时刻开始周期性发送，这样即可避免两者在某一时刻的发送重叠，如下所示： 22 | 23 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzUWHKOibQVqT0GBibugKVCOiaF9oYKU4L6FC5F5ibM9UFvyX18eEoPmubvX1Hz2ryGuJWDqIEicJgodpA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 24 | 25 | ## QA2：Tx FIFO发送方式可能引发的问题有什么？ 26 | 27 | **答：**对于CAN报文，使用FIFO方式发送，我能想到的场景：诊断中，发送诊断指令使用FIFO缓存，保证诊断指令请求的顺序。不知道大家在何种情况下使用过Tx FIFO，还请大家给普及。 28 | 29 | 这里思考到了一种工况，可能会因使用FIFO发送方式，导致报文的发送延迟，具体如下所示： 30 | 31 | 假设：CAN BUS上有两个节点：ECU1::CAN1和ECU2::CAN1，ECU1::CAN1使用Tx FIFO缓存待发送数据，ECU2::CAN1使用Dedicated Tx Buffers方式缓存待发送数据。在某一时刻，ECU1::CAN1的Buffer Index0待发送报文的CAN ID = 0x30，ECU2::CAN1待发送的6个报文的CAN ID ＜0x30，所以，每次总线仲裁，都会优先发送ECU2::CAN1缓存的报文，而ECU1::CAN1因为总线仲裁失败，导致ECU1::CAN1 FIFO中的高优先级报文无法及时发送出去，如下所示： 32 | 33 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzoAgzzT5e9T6WOIYgSMsLicOJJiaGZfNP2bibHiaiaGftZaQTv9vvXfPLo0JSFDYqluyhTOuU7D2yERibA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 34 | 35 | 所以，在使用Tx FIFO方式时，需要注意此工况。 36 | 37 | ## QA3：程序应先处理发送报文还是应该先处理接收报文？ 38 | 39 | **答**：TBD。为什么是未定义呢？在实际的项目开发中，先处理Rx报文还是先处理Tx报文确实没有明确规定，在项目不出问题之前，没有人会留意两者的处理顺序。这里我们讨论一下先处理Rx Msg，再处理Tx Msg的情况，实质就是讨论Task中，Com_MainFunctionRx()/Com_MainFunctionTx()的处理顺序。 40 | 41 | 假设：Com_MainFunctionRx()/Com_MainFunctionTx()均在5ms的Task中，且先处理Com_MainFunctionRx()，再处理Com_MainFunctionTx()，如果此节点收/发的报文数量不多，任务在规定的时间内处理完（t1时刻之前），不会引发问题，如下所示： 42 | 43 | 44 | 45 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzUWHKOibQVqT0GBibugKVCOiaQlYqPE37MoL2HUJ1SnD2FicKedubgx3DBHiar21jNibOE2ibE8ZAwv0SwA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 46 | 47 | 如果当前节点接收的报文数量较多，Com_MainFunctionRx()消耗了任务处理的大部分时间，导致Com_MainFunctionTx()处理被Delay，可能会导致本节点发送报文的周期抖动问题，比如：本来10ms的Tx Msg，由于延迟导致Tx Msg＞10ms + 容差值，假设容差值±10%(1ms)，比如：实际Tx Msg周期13ms，导致通信出问题。 48 | 49 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzUWHKOibQVqT0GBibugKVCOiaibiaib2EGRKckNRSuqm5RFzaZrDBFYlVreWDonMuJaWtBquE9Dm364g0Q/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 50 | 51 | 对于一个节点，**接收报文**数量存在不确定性，比如：接收的报文类型如果有事件性应用报文、高周期应用报文（如：1ms周期性应用报文）等。那么Com_MainFunctionRx()的处理时间就会存在一定的不确定性。相对于接收报文，节点发送报文的数量相对比较确定，发送所消耗的时间也比较确定，所以，从处理顺序上来说，**先处理确定的发送再处理不确定的发送比较合理**，这样可以确保发送报文的时间。而对于接收，即使超一点时间，如果Task没有超过Deadline Time，对程序的运行也不会造成太大影响。 52 | 53 | 再者，对于CAN报文，发送报文还需要进行总线仲裁，仲裁失败也会存在一定的延时（参考QA2）。 54 | 55 | **注意**：上述假设OS所使用的基准计数器是可信的，即：基础计数器准确，一般由GPT或者STM驱动。 56 | 57 | ## QA4:周期型报文Offset的作用是啥？ 58 | 59 | **答：**降低同一时刻，多个发送报文的Burst Send问题。这个问题属于QA1的延申。 60 | 61 | 一个节点，发送的报文类型可以有多种（QA1提到）。其中，节点外发的应用报文从几个到几十个不等。应用报文又分为事件型、周期型、混合型。以周期型应用报文为例，可能有5ms、10ms、20ms、50ms等周期。如果本节点外发的报文数量较大，在某一时刻会存在大量并发请求。比如：MsgA Cycle =5ms，MsgB Cycle = 10ms，MsgC Cycle = 10ms，如果MsgA的发送时刻为5ms、10ms、15ms、20ms、25ms、30ms.....MsgB、MsgC的发送时刻为10ms、20ms、30ms.....，在time　＝　10ms、time　＝　30ms......等时刻，MsgA 、MsgB、MsgC会同时请求发送，节点要发送的报文数量越多，某一时刻（如下图time = 10ms 时刻），请求发送的报文数量可能就越多。 62 | 63 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxWkjOHrD2yuu5hSeiaCUjmvnyG6lDzocogIWjYFKsibYyKOMbVDbS2k77gn2rgoErq37MH50C7DfwA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 64 | 65 | 在某一时刻，发送报文数量过多会带来什么问题呢？这就是QA3中的问题，会使得某个发送报文发送延迟，使得其发送周期出现抖动，即：超过该周期报文的允许误差值，一般来说，≤100ms的周期性应用报文允许的偏差为3％，＞100ms的周期性应用报文允许的偏差为1％(看OEM要求)。既然应用报文会Burst Send，如何降低这种并发请求行为呢？**偏移相同周期报文的发送时机**，比如：MsgB　Offset 5 ms，MsgC Offset 10ms，这样两者的发送就不会重叠，如下所示： 66 | 67 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxWkjOHrD2yuu5hSeiaCUjmvTtExtB1ibQo6dFsribQB6iaTlK0YXnjyrCeOt3ic5IvXamKtCTFdOQKjZw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 68 | 69 | 那偏移不同周期的应用报文有用吗？因为周期性报文发送取决于Com_MainFunctionTx()所在任务周期，Offset Value = n * Cycle（n为非负整数，Cycle指Com_MainFunctionTx()的任务周期），所以，Offset Value是Com_MainFunctionTx()任务周期的整数倍。这样，即使设置MsgA、MsgB的Offset Value不同，也不能避免某一时刻（如：time = 10ms时刻），两者的并发请求，如下所示： 70 | 71 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzoAgzzT5e9T6WOIYgSMsLicLsEiaQe8709BXQ3iamHn6nxTEG9HTyLttdWtpxRdd5UEQdKP3Mc1SpCw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 72 | 73 | 74 | 75 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/quuOyCqONwdD16hI11wAQWxGp4ajJ4DMnbsHGb4ViandFryeibcQb1Idxb3MHmrh20988OSES3OU1wPTicQbAr94g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 76 | 77 | 78 | 79 | 参考资料 80 | 81 | SIMPLE TITLE 82 | 83 | Infineon-AURIX_TC3xx_Part2-UserManual-v01_00-EN.pdf -------------------------------------------------------------------------------- /autosar/NM/Autosar通信：网络管理报文和应用报文，谁先发？.md: -------------------------------------------------------------------------------- 1 | # Autosar通信：网络管理报文和应用报文，谁先发？ 2 | 3 | 汽车嵌入式开发中，具有**周期性**外发的报文目前只有网络管理报文和应用报文，当通信开启的时候，这两种类型的报文谁先外发呢？本文从需求角度，聊聊这两种报文到底该谁应该先发送，谁应该后发送。 4 | 5 | 1 6 | 7 | IpduGroup概念 8 | 9 | 为了便于对应用报文的管理，COM层将发送和接收的I-PDU进行分组处理（分组情况根据需求配置）。COM通过Com_IpduGroupControl()接口具体的控制I-PDUs的收/发行为。 10 | 11 | Com_IpduGroupControl()函数原型如下所示： 12 | 13 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzW0KUgCslNz5D9iaXPxvnwsPnTeY9ibsJib2hWDSxnXzzmLVANgtQWpn8651xkMPHEERqHhjEbHodHA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 14 | 15 | 以控制Tx PDU为例，ipduGroupVector、IpduGroup、I-PDU关系如下所示： 16 | 17 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzW0KUgCslNz5D9iaXPxvnwsCXKh5MwdUwibwG3h1ngndghjNRaf5Ds4sLWibk59Bfr5tGEBx3yObSqA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 18 | 19 | 再看看Autosar怎么描述IpduGroup、I-PDU关系的，如下所示： 20 | 21 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzW0KUgCslNz5D9iaXPxvnwsWlCIYGTFTX8g4kjQMo5DwxYKbS5ZjvDybr06yuLmbNwKSMHF5YD7TA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 22 | 23 | 有点晕？没关系，咱们简单说说： 24 | 25 | 一个I-PDU可以放在一个IpduGroup里，也可以放在多个IpduGroup里； 26 | 27 | 一个I-PDU既可以放在Rx IpduGroup里，也可以放在Tx IpduGroup; 28 | 29 | 一个I-PDU所在的**任意一个**IpduGroup激活，此I-PDU的收/发行为被激活。 30 | 31 | 2 32 | 33 | 网络管理报文和应用报文谁先发？ 34 | 35 | 首先，需要明确当前Node的网络类型，如果当前Node的网络类型是Active的，Node可以外发网络管理报文，那么就需要明确一下两者谁先发送的问题了。为了快速的唤醒网络，需求中多数会要求“**外发的第一帧报文是网络管理报文**”，且会有时间约束，比如：150ms＋10%。这个话题前面我们有提到过，可以回顾前文[Autosar网络管理：确保第一帧是网络管理报文方法](http://mp.weixin.qq.com/s?__biz=MzUyNDU4NTc1NQ==&mid=2247485362&idx=1&sn=36ba60564be3450103d2575922f3e1d4&chksm=fa2a59c6cd5dd0d004ff096c6127049f345227e20b7843f0d2f8638f9ade44fe205d2f872b9a&scene=21#wechat_redirect)。 36 | 37 | 如果当前Node的网络类型是Passive的，意味着本Node不会外发网络管理报文，只能接收网络管理报文。所以，此种情况，就**只有应用报文先外发**，即使是应用报文，第一帧报文的外发时间也是有约束的，比如：100ms＋10%。刚才我们提到Com_IpduGroupControl()控制应用报文的外发行为，当然COM层也管控着应用报文的外发时机，即：配置参数ComTxModeTimeOffset。不要忽视此参数的配置，如果ComTxModeTimeOffset ＞0，意味着应用报文的外发时机要Offset，如下所示： 38 | 39 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzW0KUgCslNz5D9iaXPxvnwsGjF3pZ14jawro7jRsQkhFBYN1xWIcvcBxB6N2tr8vdc3u9nKoVgMYw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 40 | 41 | ComTxModeTimeOffset具体作用如下所示，可以看出，ComTxModeTimeOffset作用于PERIODIC or MIXED两种类型的应用报文。 42 | 43 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzW0KUgCslNz5D9iaXPxvnwsBRgmEwDJ3YJTZa7MD4NuLhKZ8GcMeH41FW4CHBRtP9ItS6C5nUlz4g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 44 | 45 | 当ComTxModeTimeOffset ＞ 0时，会延迟Com_MainFunctionTx()的调用，进而使得第一帧应用报文的外发时间延长。所以，在实际项目的开发中，嫌少使用该参数，或者将其配置为0。 46 | 47 | **如果遇到外发第一帧应用报文时间超时，可以看一下该参数的配置情况**。 48 | 49 | 这里还有一个问题我们没有解释：Com_MainFunctionTx()对应的ComTxModeTimeOffset谁来计时？既然Com_MainFunctionTx()需要周期性调度（比如：5ms调度一次），就会被OS管理，如果Com_MainFunctionTx()所在Task想延迟一段时间激活。可以，OsAlarm粉墨登场，ComTxModeTimeOffset延迟时间由OsAlarm精准把控，比如：延迟10ms，激活Com_MainFunctionTx()所在Task，那么周期性应用报文的第一次外发将会被延迟10ms。 50 | 51 | TaskOsAlarm作用如下所示： 52 | 53 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzW0KUgCslNz5D9iaXPxvnwshp4qN6pZiaibIav9Izuvp6KicM1tKk9JJoN2uUDpXVXkCHz7ATxVVbX3w/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 54 | 55 | ## 拓展思考 56 | 57 | 前面我们讨论过：“如何确保外发第一帧报文是网络管理报文”。同样，我们可以利用ComTxModeTimeOffset参数，延迟Com_MainFunctionTx()所在任务的激活时机来实现该功能。注意：需要先确定使用的软件包是否具有该功能，因为并不是每家Autosar供应商都实现了该功能。 58 | 59 | **参考资料** 60 | 61 | AUTOSAR_SWS_COM.pdf 62 | 63 | AUTOSAR_SWS_OS.pdf -------------------------------------------------------------------------------- /autosar/NM/CAN总线指定帧唤醒的硬件实现方式.md: -------------------------------------------------------------------------------- 1 | # CAN总线指定帧唤醒的硬件实现方式 2 | 3 | CAN的指定帧唤醒是一种网络管理的场景，对于我这个偏硬件的工程师来说，网络管理也就是通过CAN来唤醒不同的ECU，而指定帧唤醒就是特定的某些CAN ID的报文能够唤醒ECU。 4 | 5 | 讲到CAN总线就必须要涉及到跟CAN总线相关的稍微“高级”一点的用法，那就是指定帧、任意帧唤醒的一点知识。最近也是接触到了一些可能需要同一个网络上某些节点唤醒而另外一些节点不用唤醒的案例，但在分配网络管理帧的时候依然遇到一些问题，针对这种最经典的应用案例，在没有广泛了解CAN ID如何分配的前提下，我觉得可能有解决方案，正所谓不知者无畏。 6 | 7 | 8 | 9 | **一 指定帧唤醒的硬件基础** 10 | 11 | 12 | 13 | 从目前应用最为广泛的带指定帧唤醒的CAN收发器TJA1145的管脚定义如下，其中跟唤醒相关性最强的就是INH脚，规格书上这个注释直译是“禁止输出以切换外部稳压器”，其实不用整这么麻烦，它的用途就是当CAN总线上有唤醒帧的时候，INH会置位变成高电平可以用来使能外部的电源芯片。 14 | 15 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/3vPe9ic1J8QDphpOt5QnlpBWZbKmwmzyNbAKRoqr6fffpOuTKGzkF5VCXanAhD52TxpNquW2NNz28AicHo7Dnic1g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 16 | 17 | 从TJA1145的芯片内部示意图里面可以看到大概的用途，当报文过滤器的的报文与唤醒帧寄存器相匹配的时候，COMPARE LOGIC就会认为检测到唤醒帧，然后就会闭合INH内部的开关，让INH脚输出12V。 18 | 19 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/3vPe9ic1J8QDphpOt5QnlpBWZbKmwmzyNlInNf31JaQe45C09FbQsuibj9npZPyichyvRr4JqKyffb4Z1Mibx9S1OQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 20 | 21 | 所以从上面看来，CAN唤醒需要硬件配合来实现才行，下图就是比较典型的一种网络管理唤醒的硬件拓扑，首先带唤醒的CAN收发器必须要12V常电供电，另外INH脚需要连接到电源芯片的使能脚，这时当CAN总线上有网络管理帧的时候，INH变成高电平去唤醒电源芯片，就完成了一次完整的网络管理唤醒。 22 | 23 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/3vPe9ic1J8QDphpOt5QnlpBWZbKmwmzyNkjKLaTCiaicdIW1kAjes0r2ickCedmIjZTtph6RfTiajFrzRv4DMjnHGHw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 24 | 25 | 下图这个是TJA1145芯片手册中推荐的应用电路，基本上跟我画的拓扑差不多，如果有兴趣的话可以直接去网上下载TJA1145的芯片手册去了解一下。 26 | 27 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/3vPe9ic1J8QDphpOt5QnlpBWZbKmwmzyNo0hicFFExrP1nRAO8cCr59x1Lz0ZzxPod1URaAgB5hZC019McqQ67pA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 28 | 29 | **二 指定帧唤醒的配置方式** 30 | 31 | 32 | 33 | 在芯片内部框图可以看到有一个Wakeupframe configuration memory，这个寄存器就是用来配置唤醒报文的。之前我也讲到过CAN报文的格式，其中CAN ID是11位，也就是从0x000~0x7FF这个范围。一般来说定义网络管理帧是各个主机厂自己定义的，常用的包括0x4xx，0x5xx，0x6xx，0x7xx都是有人用的。 34 | 35 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/3vPe9ic1J8QDphpOt5QnlpBWZbKmwmzyNrHEPmvVl3GohUZpxFefZnUQBVyPBq3CsoqiagyDug3F5AdRFFWVtILA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 36 | 37 | 对于配置指定帧的寄存器，分为两个部分，一个是11位的CAN ID区域，一个是11位的ID mask区域。用通俗一点的语言就是CAN ID区域就是用来标注制定帧的具体唤醒ID，而mask区域与之相对应的位里面，如果是0，就表示对应的ID那一位是需要必须满足的，如果是1，就表示对应的ID那一位可以不用关注。因此在规格书上的这个例子就是表示唤醒帧是00110100xxx，后三位xxx可以是0也可以是1，所以网络管理唤醒帧的范围就是从0x1A0到0x1A7。 38 | 39 | 还是上面这个例子，如果ID mask中放开的位数只有1个，那就表示只有2个ID的报文才能唤醒CAN收发器。假设ID mask是0000000 0100，那对应的制定CAN ID就是0x1A4，0x1A0。我们如果把这2个ID分配成一个收，一个发并且给到同一个ECU，这样的话，我们就能够实现精准的网络管理唤醒，对于同一个网络的不同节点，虽然都支持指定帧唤醒，但是我依然可以用不同的网络管理帧来实现不同的唤醒需求。 40 | 41 | 42 | 43 | **总结** 44 | 45 | 46 | 47 | 当然这个只是从理论上来说一下网络管理唤醒的理想状态，在实际应用过程中，同一个CAN总线上不同的节点之间一般都是存在相互通讯的需求，只唤醒某些节点必然会导致其他节点校验出来报文丢失的故障，因此实际应用中，配置网络管理通常是直接配置一个网段，例如上面我说到的0x4xx，0x6xx这种。 -------------------------------------------------------------------------------- /autosar/NM/CAN通信基础：Tx Comfirmation、Rx Indication以及Ack.md: -------------------------------------------------------------------------------- 1 | # CAN通信基础：Tx Comfirmation、Rx Indication以及Ack 2 | 3 | 嵌入式开发中，知识细碎，工程实际中，如果某些细碎的问题理解不到位，就可能成为Bug的拦路虎。本文，聊一聊CAN通信中的Tx Comfirmation、Rx Indication以及Acknowledgement（Ack）。 4 | 5 | ## 1、Tx Comfirmation 与 **Acknowledgement(Ack)** 6 | 7 | 了解Tx Comfirmation之前，我们需要先清楚“发送请求（Transmit Request）”，只有先发送请求，才有对请求结果的确认（Comfirmation）。可以参考前文[Autosar通信栈：发送返回OK和发送确认是一回事吗](http://mp.weixin.qq.com/s?__biz=MzUyNDU4NTc1NQ==&mid=2247487913&idx=1&sn=a5e02e3ae6887dd7f14ac617ad6b4623&chksm=fa2a4fddcd5dc6cb2e7f894df52815da7aabb2daf503448f1096f8ed65ccb034b95a826cc56e&scene=21#wechat_redirect)。 8 | 9 | **先说发送请求**，当用户请求发送CAN报文时，最终会调用Can_Write()接口，完成报文发送的请求动作，该接口有一个返回值，表示发送请求成功与否。如果发送请求成功，返回E_OK；如果发送请求不成功，返回E_NOT_OK。E_OK表示什么意思呢？意思是说：CAN驱动有可用的缓存空间（RAM），请求发送的报文信息已经被成功地放入CAN驱动缓存区（注意，还没有发送到CAN BUS)，这只是完成了发送请求，如下绿色框图： 10 | 11 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxGRIaTrn4xPltek94SlVYWuRRVmFyjk2ImaypFUEUc6XP9RMxeW5u0DibjrG7icRAiaDiaRrLbEmEZkA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 12 | 13 | 当发送的报文信息被成功添加到驱动缓存区以后，这些报文就时刻准备发送到总线。我们知道，一个网段内可以有多个节点，每个节点都等着发送各自缓存区中的报文，谁先发送呢？答：通过仲裁决定哪个节点可以使用CAN BUS，仲裁赢的节点，获取总线使用权，进而发送报文。谁发送的报文优先级高（CAN ID越小，优先级越高）谁就可以抢占总线使用权。可以参考前文[CAN总线仲裁原理](http://mp.weixin.qq.com/s?__biz=MzUyNDU4NTc1NQ==&mid=2247489165&idx=1&sn=9f9c3edaeab7611c228e4d76ab8e8d2e&chksm=fa2a48f9cd5dc1efc810269798bfaa0a3c31fc71c99ec59d67ab3f33ad91818e8516f4cad777&scene=21#wechat_redirect)。 14 | 15 | 当网段内的某个节点获取总线使用权以后，就开始发送缓存区中最高优先级的报文，发送节点为了获悉自己所发报文信息是否正确，在使用Tx Pin发送的同时，使用Rx Pin接收（CAN总线是串行总线)，当然，总线上的其他节点（处于监听状态的节点）也会通过CAN BUS接收总线上的报文。 16 | 17 | 发送节点边发送边接收过程如下所示： 18 | 19 | ![图片](https://mmbiz.qpic.cn/mmbiz_gif/eEEQvxEw8vxGRIaTrn4xPltek94SlVYW3jvIR22L3xvXyibSsgiaTXBCh96qlYqUvMRjJqofH6IkgWHnpNO7Fhpg/640?wx_fmt=gif&wxfrom=5&wx_lazy=1) 20 | 21 | 发送节点按照CAN报文格式发送各个位域，发送节点发送ACK Field(ACL Slot、ACK Delimiter)时，2 Bit均发送隐性位（Recessive，1），当接收节点接收到ACK Field的第一个Bit（ACK Slot，ACK应答槽）时，接收节点将其置为显性位（Dominant，0），由于"线与"原则（显性位覆盖隐性位），所以，CAN BUS上，ACK Slot = 0，这个动作称为应答（Acknowledgement），即：接收节点应答发送节点，告知发送节点，其发送的报文已被成功接收，如下所示： 22 | 23 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyg5ap9aAQfVnGq8pQJwQkoCqw9rE7vHHcAsBItP4vyUcNFjDqFG4nZ6xRcpkqEvKYbCAKoG5lBjA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 24 | 25 | 接收节点收到隐性（"1"）的Ack Slot时，将其置为显性（"0"），这个动作由**接收节点**的Tx Pin触发。 26 | 27 | **提示**： 28 | 29 | - Ack动作由Controller完成，不是Transceiver； 30 | - 总线上可能有多个接收节点，只要其中一个应答（Ack）,发送节点就认为数据发送成功； 31 | - 当总线上没有节点应答发送节点时（即：总线上只有一个节点），发送节点检测到Ack Slot为隐性（"1"），会发出错误帧（Acknowledgment Error），同时，发送节点的TEC累加，之后发送节点尝试重传。所以，TEC很快会达到128，进入Error Passive模式。注意，如果一直是Acknowledgment Error，TEC不会再累加，不会进入Bus Off。 32 | 33 | 当发送节点的发送报文被其他节点成功接收以后，发送节点就会将这个信息反馈给对应的User，告诉请求发送的User，这个过程就是Tx Comfirmation。这个反馈途径有两种： 34 | 35 | 1. 中断方式，成功将一帧报文发送到总线，且被其他节点有效接收以后，发送节点进入发送完成中断例程，调用User注册的回调接口，比如：CanIf_TxConfirmation()，CanIf在进一步调用目标上层Xx_TxComfirmation 回调接口告知User发送结果。 36 | 2. Polling方式，CAN驱动的Main函数周期性（eg:5ms）的检测是否有报文被成功发送，如果有，则调用目标User的Xx_TxConfirmation()，告知其请求发送报文被接收的结果，即：已被其他节点成功接收，且被应答。 37 | 38 | ## 2、Rx Indication 39 | 40 | 什么是Rx Indication呢？CAN BUS上有节点发送报文，就有目标节点接收报文，当接收节点接收到所需的报文以后，需要将接收的信息给到目标User，如下所示： 41 | 42 | ![图片](https://mmbiz.qpic.cn/mmbiz_gif/eEEQvxEw8vxGRIaTrn4xPltek94SlVYWwfqicdhEGGEPxksrEsCiaczramia9mOP2iaJ36t2L8zkCbu9GV7sV0NQ9A/640?wx_fmt=gif&wxfrom=5&wx_lazy=1) 43 | 44 | ## 如何通知目标节点呢？两种方式： 中断方式，当接收节点成功接收到一帧CAN报文以后，程序进入接收完成中断例程，在接收完成中断例程中，会通过上层注册好的Call Back（eg:CanIf_RxIndication()）将接收的报文信息送给目标上层。Polling方式，CAN驱动的Main主函数不断地查询是否有报文接收，如果有，则调用Xx_RxIndication()将接收信息送给目标User处理。 如上，将接收报文信息通知到目标User的过程就是Rx Indication。 -------------------------------------------------------------------------------- /autosar/NM/Flexray总线：Frame结构，几张图就能看明白.md: -------------------------------------------------------------------------------- 1 | # Flexray总线：Frame结构，几张图就能看明白 2 | 3 | Flexray报文包含：帧头、有效负载、帧尾三部分组成。如下所示： 4 | 5 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vydFM3zFKibVhZ3rltJxbAhFd8RjOiaaR4w6XIBJteUcCI2qj51LpQDOC9Qfw70iahXOyVOyUL9AUwNg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 6 | 7 | Flexray的Frame结构如下所示： 8 | 9 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzOXpHnGAb03FHcnyGiawUXIJ8SIQyN0X5IDlVHplhUGksnht7TRDFsLmVIZXx5RYXgWoQuFibPXoyQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 10 | 11 | **提示**：参考《FlexRayCommunicationSystem V2.1》 12 | 13 | 1 14 | 15 | 帧头 16 | 17 | 18 | 19 | 帧头共由40个Bit构成（5 Byte），具体包括：Indicators、ID、Payload Length、CRC、Cycle Count。 20 | 21 | **1、Indicators** 22 | 23 | Indicators由5bit构成，精确指示报文信息。 24 | 25 | **Bit1**:保留位，发送节点将发送逻辑0，接收节点忽略该bit位值。 26 | 27 | **Bit2**:有效负载指示位。 28 | 29 | - 当该bit = 1时，如果是**静态报文**，则有效负载中正在传输**网络管理向量**；如果是动态报文，则有效负载中正在传输**报文标识符**。 30 | - 当该bit = 0时，说明静态报文没有传输网络管理向量或者动态报文没有传输标识符。 31 | 32 | **Bit3**:空帧指示位。 33 | 34 | - 该bit =1，表示负载段包含数据； 35 | - 该bit =0，表示负载段数据无效，发送节点可以将负载段的数据全设为0 。 36 | 37 | **Bit4**:同步帧指示位，指示**静态段**中传输的报文是否为同步帧。 38 | 39 | - 该bit = 1，所有的接收节点要进行同步处理； 40 | - 该bit = 0，接收节点不做同步处理。 41 | 42 | **Bit5**:启动帧指示位。指示**静态段**中传输的报文是否为启动帧。 43 | 44 | - 该bit = 1，此静态Frame是启动Frame，规范中要求只有冷启节点同步帧置位时，启动指示位才能置位，即Bit4 = Bit5 = 1； 45 | - 该bit = 0，此静态Frame不是启动帧。 46 | 47 | **2、ID** 48 | 49 | ID由11 Bit表示。ID标识报文，并与时隙相对应，0x00表示无效报文（接收节点进行错误处理），所以有效ID范围是1~2047（2^11）。 50 | 51 | **3、Payload Length** 52 | 53 | Payload Length由7 bit构成，表示**负载段**数据的大小（**以word为单位**）。一条报文最多可以传输254 byte，即最大Payload Length(cPayloadLengthMax) = 127（2^7）。 54 | 55 | 在静态段中，同一Cycle中所有的Frame负载长度是固定的，即长度一致，比如都是32 byte，一般可配置gPayloadLengthStatic参数。 56 | 57 | **4、CRC** 58 | 59 | CRC序列由11Bit构成（这里的CRC是Header的CRC），该序列的计算基于ID、Payload Length、同步帧指示符(Bit4)和启动帧指示符(Bit5)。 60 | 61 | ![图片](https://mmbiz.qpic.cn/mmbiz_gif/eEEQvxEw8vydFM3zFKibVhZ3rltJxbAhFKxb16j7Uf1mWvv3AIHm1iafU1Eiaxfvr2JXoCwuF4BjmyAr5X6Jic8AGg/640?wx_fmt=gif&wxfrom=5&wx_lazy=1) 62 | 63 | **5、Cycle Count** 64 | 65 | 帧头的最后是周期计数器，由6个bit构成，表示报文发送的周期数。周期计数器的范围是0到63。 66 | 67 | 2 68 | 69 | 有效负载 70 | 71 | 一帧Flexray报文最多可以传输254个字节的数据。 72 | 73 | 为静态Flexray报文设置了有效负载指示位，则静态段中前0~12 Bytes用来传输网络管理向量，用于FlexRay的网络管理；如果为动态Flexray报文设置了有效负载指示位，则负载段的前2 Bytes表示Message ID。 74 | 75 | 3 76 | 77 | 帧尾 78 | 79 | 帧尾是24 Bit的CRC计算域，计算的范围包括帧头和有效负载，如下所示： 80 | 81 | ![图片](https://mmbiz.qpic.cn/mmbiz_gif/eEEQvxEw8vydFM3zFKibVhZ3rltJxbAhFqvCicRBrOyvLXPBExayXy3SvaXmcV1z0OEudibfA0KFf9vExkFaZIt6g/640?wx_fmt=gif&wxfrom=5&wx_lazy=1) 82 | 83 | 4 84 | 85 | 编码 86 | 87 | Flexray帧的传输并不是从报文的Header开始传输，是从TSS（Transmission Start Sequence）开始传输，TSS包含3~15个低电平，之后是FSS（Frame Start Sequence）和BSS（Byte Start Sequence）。至此，报文头才真正的开始传输，但是报文每个字节被传输之前都需要传输一个BSS，这样接收方可以**通过BSS的跳变进行同步**，当报文的最后一个字节传输完成后，以FES（Frame End Sequence）标识。**在FES之后是11 Bit的隐性位，即通道空闲界定符**。 88 | 89 | 静态报文的传输时序如下所示（图片来自Vector）： 90 | 91 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vydFM3zFKibVhZ3rltJxbAhFgVEr2hBMAXFuWPc4RPXYficWeib5alIUMqqvl5z9sIknouZe7baZZia8Q/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 92 | 93 | 动态报文的传输时序如下所示（图片来自Vector），相对于静态报文，动态报文在FES之后还有一个DTS（Dynamic Trailing Sequence）,这样可以让接收方准确的知道动态报文结束时机。 94 | 95 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vydFM3zFKibVhZ3rltJxbAhFvcbogFQfyoOaEH3V6S0lSjQVsCXB7iaFDHMp4UorgxM29ZWmWQf9WcA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 96 | 97 | -------------------------------------------------------------------------------- /autosar/NM/PN/1.Autosar网络管理：CanNM PN功能.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：CanNM PN功能 2 | 3 | 我们清楚Autosar网络管理，也知道收到网络管理报文会唤醒网络，但是网络管理如果上PN功能的话，就只能是指定的网络管理报文才可以唤醒网络。这个指定网络管理报文是如何过滤的呢？来，我们看看Autosar怎么做的。 4 | 5 | 1 6 | 7 | **缩写词** 8 | 9 | 10 | 11 | | **Acronym/abb**reviation | **Description** | 12 | | ------------------------ | --------------------------- | 13 | | **CBV** | Control Bit Vector | 14 | | **PN** | Partial Network | 15 | | **PNC** | Partial Network Cluster | 16 | | **PNI** | Partial Network Information | 17 | 18 | **PNC解释** 19 | 20 | 为便于理解，以最常见的Can总线为例，其它总线同理。比如在某个Can网段内，有3个ECU，其中ECU1包含3路Can，即Node1、Node2、Node3，ECU2包含两路Can，即Node4、Node5，ECU3包含1路Can，即Node6。如下所示： 21 | 22 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzI1TkuukBq8F1xiafagEcWPlTDz2UjibTDoXP6hH6mIgR8rP1ticvusBrWfdpYbTNKSsgqrk9koIKCA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 23 | 24 | 假设，我们示例中的Can网段设计了5个PNC，分别定义PNC ID为：0x01、0x02、0x03、0x04、0x05。**一个Node可以加入一个PNC**，**也可以加入多个PNC**。这里的PNC类似Ethernet的**多播组**概念。举个例子：我的微信里有100个好友，但是我要将一些事情告诉某些好友，而不是全部好友。于是，我将好友1、2、3拉了一个小群，设置标签PNC1；我又拉了好友1、2、5、6组建了另一个小群，设置标签PNC2。我发朋友圈的时候，选择PNC1标签的好友可见我的消息，即使我的所有朋友都会看朋友圈，但是只有我的好友1、2、3可以看到我的消息（即唤醒Node1、Node2、Node3）。 25 | 26 | 假设需求如下所示： 27 | 28 | PNC1：Node1、Node5、Node6 29 | 30 | PNC2：Node2、Node4、Node6 31 | 32 | PNC3：Node2、Node6 33 | 34 | PNC4：Node1、Node2、Node3、Node4、Node5 35 | 36 | PNC5：Node2、Node5 37 | 38 | 需求可以进行如下分配： 39 | 40 | | | PNC1(0x01) | PNC2(0x02) | PNC3(0x03) | PNC4(0x04) | PNC5(0x05) | 41 | | ---------- | ---------- | ---------- | ---------- | ---------- | ---------- | 42 | | **Node1 ** | 1 | 0 | 0 | 1 | 0 | 43 | | **Node2** | 0 | 1 | 1 | 1 | 1 | 44 | | **Node3** | 0 | 0 | 0 | 1 | 0 | 45 | | **Node4** | 0 | 1 | 0 | 1 | 0 | 46 | | **Node5** | 1 | 0 | 0 | 1 | 1 | 47 | | **Node6 ** | 1 | 1 | 1 | 0 | 0 | 48 | 49 | **注释：** 50 | 51 | 1 表示使能Node，0 表示不使能Node。 52 | 53 | 2 54 | 55 | **NM PDU Format** 56 | 57 | 58 | 59 | 一般来说，CAN网络管理报文的PDU格式如下所示： 60 | 61 | Byte0:节点ID，比如Node ID为0x509（假设网络管理报文：0x500~0x5FF），工具配置时，此字节设置0x09即可。因为0x05是网段标识，底层收到0x05xx的报文即可知道是网络管理报文，之后根据偏移值（本例：0x09）即可知道是哪个Node。 62 | 63 | Byte1:控制位向量。 64 | 65 | Byte2~Byte7：用户数据 66 | 67 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxTiciatKmWaUNQADsjjAlGIKcmXGorWZf8gKY8hv49LriaUDo4xXforxbgU4Q0vibOPRibBYbzGZAPOOQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 68 | 69 | 这里只讨论和PN功能相关的Bit6。 70 | 71 | - Bit6 = 1，表示有PN请求，如果有PN请求，则后面要判断收到的网络管理报文的PNC，判断该节点是否在此PNC内； 72 | - Bit6 = 0，表示没有PN请求，一般收到网络管理报文就直接唤醒网络。 73 | 74 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxTiciatKmWaUNQADsjjAlGIKuyiaCFvqJsNBFN9UBzec6Aaeic9Lem60UzGviceKmL9sia4F5LwgJRMicwQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 75 | 76 | 3 77 | 78 | **NM PDU过滤算法** 79 | 80 | 81 | 82 | 前面的讨论为本小节做了铺垫，那我们就好奇一个问题了：如果节点有PN功能，如果判断收到的网络管理报文可以唤醒当前节点的网络？ 83 | 84 | 这里就涉及到了PDU的过滤算法问题。 85 | 86 | **示例** 87 | 88 | CanNmPnInfoOffset = 4，Pn Info在PDU中偏移的距离 89 | 90 | CanNmPnInfoLength = 2，Pn Info在PDU中的长度 91 | 92 | | Byte0 | Byte1 | Byte2 | Byte3 | Byte4 | Byte5 | Byte6 | Byte7 | 93 | | ----- | ----- | --------- | ------- | --------- | ----- | ----- | ----- | 94 | | NID | CBV | User Data | PN Info | User Data | | | | 95 | | 0x09 | 0x40 | 0xFF | 0xFF | 0x12 | 0x8E | 0xFF | 0xFF | 96 | 97 | 如何识别出网络管理报文可以唤醒该节点呢？Autosar中使用了屏蔽掩码过滤的方式，如上例，Pn Info的长度为2byte，对应设置2个Mask，比如： 98 | 99 | CanNmPnFilterMaskByteIndex= 0，设置CanNmPnFilterMaskByteValue = 0x01； 100 | 101 | CanNmPnFilterMaskByteIndex= 1，设置CanNmPnFilterMaskByteValue = 0x97。 102 | 103 | 之后对每个Pn Info采用位与运算，运算结果如下所示： 104 | 105 | | Filter Mask Value(Byte) | Compared to received PN info | Resulting | 106 | | ----------------------- | ---------------------------- | --------------------------------- | 107 | | 0x01(byte0) | 0x12(NM PDU Byte4) | 0x00 (no relevant PN information) | 108 | | 0x97(byte1) | 0x8E(NM PDU Byte5) | 0x86(relevant PN information) | 109 | 110 | 其中，有一个字节与结果不为0，表示该报文可以唤醒当前节点。如果两个字节的比较均为0x00，则当前节点网络不被唤醒，忽略该网络管理报文。 111 | 112 | **提示：** 113 | 114 | 有些transceiver有PNC过滤功能，也可以在硬件上设置此过滤功能。针对NXP TJA1145 Transceiver而言，只能过滤通信速率在1Mbps的报文，因此要注意项目中的网络管理报文速率，如果使用的是CANFD，且速率是500Kbps/2Mbps，则NXP TJA1145 Transceiver硬件过滤功能可能就不能使用。也许在不久的将来，硬件变速率过滤功能也将成为现实。 115 | 116 | CANXL要来了，嵌入式的小伙伴，让我们拭目以待吧。 -------------------------------------------------------------------------------- /autosar/NM/PN/2.Autosar网络管理PN：路由超时大Bug.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理PN：路由超时大Bug 2 | 3 | 项目包含Autosar网络管理时，一般会要求Node外发的第一帧是网络管理报文，目的是为快速唤醒网络；同时也会充分考虑通信栈的任务周期和时序，因为网络状态切换与其密切相关，如果未考虑好这两点则可能带来潜在的Bug。本文从工程实际出发，分享一个实例：Node路由超时引发的Bug。 4 | 5 | 1 6 | 7 | **需求描述** 8 | 9 | 10 | 11 | 如下图，Node1所在CAN/Flexray总线接收网络管理报文NM1，该网络管理报文在VCU内部转发给Node2（Node2连接CAN总线），如果收到的NM1包含Node2的PNCdes置位，则Node2网络唤醒，且Node2发送网络管理报文NM2。这里使用了PN的GateWay功能。 12 | 13 | **注意**：Node1接收的NM1报文可以是不同的节点发来的网络管理报文，即测试时，接收到的NM1报文时间可以是随机的。 14 | 15 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxbC71HeF974kPRqelApOz1b7lN4btCczcHuPTKTkiahAib6FYwtgOk8cJnOvmFXVyFn43oYwprKYSA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 16 | 17 | 接收的NM1报文，**第一次**PNCsrc = 1、PNCdes = 1时，设置时间为T1，Node2外发第一帧NM2的时间设置为T2，**需求规定****T2-T1 ＜ 15ms**，偏差10%，即(**T2-T1**)max < 15+15*10% = **16.5ms**，T2-T1=Tgate。 18 | 19 | NM1在Node1 Bus和NM2在Node2 Bus的具体行为如下所示： 20 | 21 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxbC71HeF974kPRqelApOz1KuNJ0ZoMpaeO7T6K2DbaNVMZJ8XOxGA6ibe6XIAnHIvCuu0zIj5QmqQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 22 | 23 | ***\*实际测试结果\**：**实际测试Tgate ＞ 16.5ms，不符合需求，Bug就这么来了。 24 | 25 | 2 26 | 27 | **Bug原因分析** 28 | 29 | 30 | 31 | **问题点1**：Node2发出的第一帧报文不是网络管理报文NM2，而是Node2的应用报文（周期性报文），由于NM2的优先级低于应用报文，导致NM2发送延迟。 32 | 33 | **具体分析1**：如下图所示，如果NM、App等报文在通信开启的那一刻（t0）都请求驱动发送报文，比如：Can Controller，它只能根据优先级（CANID）决定报文发送顺序，因为NM报文相对App报文优先级低，所以NM报文会被延迟发送。 34 | 35 | 如果让每个周期性App报文，偏移（Offset）一段时间（t1、t2等）发送，而不是在t0时刻抢占NM报文，则可以让NM报文优先发送。 36 | 37 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxbC71HeF974kPRqelApOz1EAHxOYEyL1RVfgbv9ia8xwEjWjqM0WnFEB4Kp7W6mIfkaDAyFUf0lXg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 38 | 39 | **问题点2**：通信栈模块周期不匹配，这个因素影响较大 40 | 41 | **具体分析2**：比如CanSM、CanNM、Can等模块任务周期是5ms，ComM模块任务周期是20ms。当收到NM1中的PNCsrc = 1时，信息由CanNM通知到ComM，ComM切换到FULL_COMMUNICATION，这个过程实际只是一个状态切换指令下发，真正做状态切换的是CanSM，而CanSM状态机的切换需要时间，切换状态后通知到ComM，**此时ComM至少要一个任务周期（20ms）才能知道状态是否切换成功**，切换成功才请求NM启动网络，**网络状态切换告知ComM时间过长导致路由时间超时**。 42 | 43 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vz4ydKBO3HGper30gMf1vgVcXBamSqAic5meeL422RhG1R7Nxk5mb8abRNv9ELQK8Cicjx0yN28DI5A/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 44 | 45 | 46 | 47 | 3 48 | 49 | **Bug修复策略** 50 | 51 | ** 52 | ** 53 | 54 | ## 问题点1修复策略 55 | 56 | **CanNM模块修改配置** 57 | 58 | 配置**Retry Frist Message Request**，确保Node2的NM2报文发送成功，即当前周期发送失败，下一周期继续尝试发送。 59 | 60 | **Com模块修改配置** 61 | 62 | Com模块中，配置所有**周期性(PERIODIC)/混合(MIXED)应用报文**偏移值（ComTxModeTimeOffset，默认值为0），避免高优先级的应用报文在通信开始时，抢占网络管理报文，确保网络管理报文被优先发送。 63 | 64 | ## 问题点2修复策略 65 | 66 | 修改ComM模块任务周期。由20ms调整到5ms，与CanSM、CanNM、Can等通信模块任务周期匹配，确保ComM能更快地获取底层状态切换结果。 -------------------------------------------------------------------------------- /autosar/NM/PN/3.Autosar网络管理：网管节点路由时间解读.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：网管节点路由时间解读 2 | 3 | Autosar网络管理中，如果节点是网关节点，对开发和测试来说都是不小的挑战，如果对需求解读不到位，开发架构设计错误，后期的测试也就bug bug bug... 4 | 5 | 本文针对网关节点（包含PNC功能）解读路由需求以及开发注意事项。本文讨论的内容涉及PN（Partial Network）功能，本文源于工程实际，还是能给大家点启发的。 6 | 7 | **提示**：基于can总线讨论 8 | 9 | 1 10 | 11 | 需求明确 12 | 13 | 需求：某个ECU包含两个节点：Node1和Node2，两者为网关节点，均包含PNC功能。要求网络管理报文的路由时间＜15ms。 14 | 15 | **提示**： 16 | 17 | - Node1和Node2是主动激活节点，即两个Node均具有快发模式; 18 | - PNC1和PNC2**均关联Can1和Can2**。 19 | 20 | 21 | 22 | 2 23 | 24 | 需求说明 25 | 26 | 这里我们从测试角度分析需求应该如何测试。 27 | 28 | **举例分析**：上位机（Tester）模拟发送一帧网络管理报文0x5xx（网络管理报文有效范围：0x500~0x53F）到Can1 Bus，Can1 Node收到这帧网络管理报文以后，内部转发给Can2 Node（实际由ComM判断PNC，进而决定哪些Node网络状态切换）。在Normal Mode模式下，Node1会发送网络管理报文0x502到Can1 Bus，Node2会发送网络管理报文0x503到Can2 Bus。 29 | 30 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzOzTCMfibKg3PvAiaFWGZVianEg7gibLVLmHSa6k9I5zfkxJoQOvDunRHTt34maiamYk1PxQkMtaWXEOw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 31 | 32 | 测试关键步骤： 33 | 34 | 1. Tester发送**仅包含**PNC1的网络管理报文0x5xx； 35 | 2. 5s后，Node1和Node2进入NOS(Normal Operation State)状态，且两者均以1s周期外发各自的网络管理报文； 36 | 3. 此时上位机模拟发送一帧网络管理报文(**包含PNC1、PNC2**)给Node1，Node1、Node2均进入快发模式，Can1 bus总线上**第一次**出现PNC2置位的**模拟网络管理报文**时间记为T1； 37 | 4. Node2也进入快发模式，当Node2发送出**第一帧包含PNC2的网络管理报文0x503**的时间记为T2（Node2此时处于快发模式），如果T2-T1 < 15ms+(15*0.01)ms = 16.5ms，则测试通过。 38 | 39 | 测试分析图如下所示： 40 | 41 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzOzTCMfibKg3PvAiaFWGZVianIpYAr4ibc1K4xIuSGia7CZzmvbaKfBeZD2O6SCkqSaQ7laJ55JnVrmOg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 42 | 43 | 3 44 | 45 | 开发注意 46 | 47 | 48 | 49 | 当理解了需求以后，开发者实现过程中有几点需要注意： 50 | 51 | 1. Node1接收的网络管理报文是一个范围，而非某帧网络管理报文，比如：本例网络管理报文的范围是0x500~0x53F，该范围内的任一帧网络管理报文，如果PNC关联Node2，均应使得Node2进入快发模式，反之亦然； 52 | 2. Node1和Node2的唤醒与PNC相关，与应用报文的路由不要混为一谈。PNC关联哪些Node，ComM会请求哪些Node的网络状态切换，而应用报文的路由可以通过PDUR进行PDR级别路由或者Com层的信号（Signal）路由； 53 | 3. **配置参数CanNmPnHandleMulti勾选；** 54 | 4. **网络管理有PN功能时，ComM负责调用CanNm_NetworkRequest()接口。** 55 | 56 | **坑点**： 57 | 58 | Node1和Node2均有Pn功能，配置参数CanNmPnHandleMultipleNetworkRequests需要勾选，当状态由NOS->RMS(Repeat Message State)切换的时候，Node进入快发模式。 -------------------------------------------------------------------------------- /autosar/NM/PN/6.Autosar网络管理：从CanNM模块看Partial Networking.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：从CanNM模块看Partial Networking 2 | 3 | Partial Networking(PN)功能相对来说，稍稍复杂一点。PN功能的实现也不能单单看某个模块，因为模块间的交互信息对网络状态的切换至关重要。对于PN功能，我主要想从CanNM和ComM两个模块谈，本篇先从CanNM聊。希望能将一些概念讲透，因为在实际项目中，工具的很多配置项我们可能一知半解，在问题排查时，多少让我们摸不着头脑。因此，我想把自己解读的Autosar信息传达出来，分享一下。 4 | 5 | **提示**：基于CAN总线。 6 | 7 | 1 8 | 9 | 为什么要PN功能 10 | 11 | 为什么需要PN(Partial Network)功能呢？实质还是为了节能。没有PN功能时，一个网段内的所有ECU同醒同睡。有时，在一个网段内，可能只需要某些ECU正常工作即可，不相关的ECU没必要唤醒（费电）。所以，增加PN功能是节能的一个优选项。 12 | 13 | **举例：** 14 | 15 | **不含PN功能的网段**，所有ECU同睡同醒。某些工况下（A工况），其实只需要ECU2和ECU4保持工作状态即可，因为没有PN功能，所以该网段内的ECU1、ECU2、ECU3、ECU4、ECU5均保持唤醒，所以就费电了，如下所示： 16 | 17 | ![图片](https://mmbiz.qpic.cn/mmbiz_gif/eEEQvxEw8vwnKJvFjx5YnvNpY1OZ0cRP4OfibiayFMiapiamiagl9AO70ntkF6XrIGklpJde1gmvWORyZ83DFFr7FSQ/640?wx_fmt=gif&wxfrom=5&wx_lazy=1) 18 | 19 | **含有PN功能的网段**，同样A工况下，ECU2和ECU4保持正常工作状态，ECU1、ECU3、ECU5休眠，相对不含PN功能的网段，含PN功能的网段将更节能，如下所示： 20 | 21 | ![图片](https://mmbiz.qpic.cn/mmbiz_gif/eEEQvxEw8vwnKJvFjx5YnvNpY1OZ0cRPyzgn6r59d9KEAelTsVyxG35gS9gyjeqzE0odHRNvsxWWEnyiazygyDw/640?wx_fmt=gif&wxfrom=5&wx_lazy=1) 22 | 23 | 2 24 | 25 | NM PDUs的接收处理 26 | 27 | 在嵌入式中，任何信息的交互无非就是收和发。对于PN功能的实现也不例外，节点收到网络管理报文是PN功能讨论的基础。对于CanNM模块而言，它通过注册在CanIf中的回调函数CanNm_RxIndication()获取NM PDUs信息。拿到NM PDUs信息以后，CanNM模块开始拆解信息，通过对信息的拆解决定是否将信息进一步传递给其他模块，比如：COM、ComM、NM等。 28 | 29 | 在Autosar中，PN功能的开启需要多个模块配置PN参数选项，先说CanNM模块。在CanNM模块，首先需要**配置CanNmPnEnabled参数**，即**CanNmPnEnabled = TRUE**。 30 | 31 | （1）如果参数CanNmPnEnabled = FALSE，CanNM收到NM PDUs直接进行后续动作，即通知NM模块等，此时PN功能忽略（无效）。只要收到有效范围的网络管理报文（一般会规定网络管理报文是一个范围，比如：0x500~0x57F），网络即可唤醒； 32 | 33 | （2）参数CanNmPnEnabled = TRUE，也不能说PN功能开始生效。此时需要进一步判断参数CanNmAllNmMessagesKeepAwake和PNI(Partial Network Information Bit)信息。PNI在NM PDUs中所处的位置如下所示： 34 | 35 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwnKJvFjx5YnvNpY1OZ0cRPeZOmgtOIGRJRwHibwkY0qsian8b5fmAO08Y1oiaIA9mO3WjsF5xZxdrlQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 36 | 37 | **提示**：Control Bit Vector简称CBV，和Source Node Identifier（SNI）一样，一般需要在配置工具中配置，即配置CBV和SNI在PDU中的位置。 38 | 39 | - 如果PNI = 0（即没有PN请求），也就没有PN功能的进一步处理，此时如果CanNmAllNmMessagesKeepAwake = TRUE，那么接收的任何有效网络管理报文进一步处理，即可以唤醒该节点网络；如果CanNmAllNmMessagesKeepAwake = FALSE，则该NM PDUs也不用再进一步处理了，CanNM模块直接丢弃该PDU，即该节点的网络无法唤醒。 40 | - 如果PNI = 1（即有PN请求），CanNM模块需要过滤User Data中的PNC(Partial Network Cluster )信息，换句话说：**PN请求信息包含在User Data中**。一般由PNC个数决定使用多少User Data空间，比如：需要设置9个PNC，而每个PNC占用一个bit，即需要9个bit，则使用2个User Data（2 Byte）空间即可。过滤前面聊过，可以参考[Autosar网络管理：CanNM PN功能](http://mp.weixin.qq.com/s?__biz=MzUyNDU4NTc1NQ==&mid=2247484915&idx=1&sn=3bd7013e8fd42df0f8e3a0775c4d433a&chksm=fa2a5b87cd5dd291f68216955dfd7930926be9934d6c3f007e443502550921de7fdfe82d63b9&scene=21#wechat_redirect)。如果过滤PNC信息，发现每个bit都与该ECU不相关，且CanNmAllNmMessagesKeepAwake = FALSE，那么CanNM直接丢掉该NM PDU，如果CanNmAllNmMessagesKeepAwake = TRUE，那么当前节点网络仍然需要被唤醒。 41 | 42 | PNC信息可占用位置如下所示（User Data部分），如果SNI不用，则User Data可以拓展到7 Byte，将CBV配置为第一个字节，如下所示： 43 | 44 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwnKJvFjx5YnvNpY1OZ0cRPqEIpcwbFGy4pqpIBR9OsTUfCNGbtSRsAlYibQsjiaqoHOmTiapyM6Pe2A/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 45 | 46 | 3 47 | 48 | ERA/EIRA 49 | 50 | 开发PN功能的朋友，对ERA(External Request Array )/EIRA(External and Internal Request Array )想必并不陌生。但是能说清楚这两个参数怎么用吗？老实说，我理解得可能不是很到位，此段抛砖引玉。 51 | 52 | 对于ERA/EIRA，可以理解为PN请求的状态集，而这个状态集的信息分别存储在各自的Buffer中，简单说：可以独立配置。 53 | 54 | **ERA**：可以理解为外部PN请求，比如：接收到其他ECU发送来的网络管理报文，PNI置位，PNC有效。 55 | 56 | **EIRA**：可以理解为外部PN请求和内部PN请求，外部PN请求和ERA一样，内部PN请求可以理解为不同channel转发过来的PN请求，比如：某个ECU包含两个CAN节点（CAN1和CAN2），且都可以作为网关节点（实际还需要关注网关类型）。CAN1收到网络管理报文，对应的PNC关联CAN2，CAN1可以内部转发给CAN2，唤醒CAN2网络，这就是内部PN请求。 57 | 58 | 内部请求实际是通过signal走COM传递给ComM，这里简单提一下，后面我们在讨论ComM和PN的关系。可以把ERA和EIRA看作信号，通过COM层标准收发接口进行信息交互。既然依赖COM，那么CanNM此时可以看作底层模块，通过PduR_CanNmRxIndication()接口通知到PDUR，PDUR再路由给COM模块，之后ComM通过COM层信号接口获取PN请求的状态信息。 59 | 60 | PduR_CanNmRxIndication()属于配置接口，Autosar中描述如下所示： 61 | 62 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwnKJvFjx5YnvNpY1OZ0cRPHhKvbxtMoLe8e6x8tFuRdZJCxcQ284nmumMYzyjEDJ5UrXQxLB9KCw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) -------------------------------------------------------------------------------- /autosar/NM/PN/7.Autosar网络管理：从ComM模块看Partial Networking.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：从ComM模块看Partial Networking 2 | 3 | 上一篇我们从CanNM模块分析PN功能，本篇接着从ComM模块分析。因为网络管理的PN功能主要由这两个模块控制。不清楚CanNM模块与PN关系的可以参阅前文[Autosar网络管理：从CanNM模块看Partial Networking](http://mp.weixin.qq.com/s?__biz=MzUyNDU4NTc1NQ==&mid=2247485683&idx=1&sn=47c6527a7b6dabb3d60a3ca5f17d2c3b&chksm=fa2a5687cd5ddf91c55c850897f28e09c1697acdcd912009c1ef97787993f8bb2058a48a7b8f&scene=21#wechat_redirect)。 4 | 5 | 对于每一个PNC（partial network cluster）的通信状态，ComM模块都有独立的一套状态机进行管理。当CanNM从CanIf层拿到NM PDU以后，会将User Data部分数据独立拆解出来，通过PDUR、COM，以信号的形式最终送给ComM模块。为什么将User Data部分独立拆解出来？因为User Data部分包含着PNC信息，该信息取决于项目需求：需要多少PNC，就开辟多少User Data空间。也就是说，ComM获取的PNC信息与NM PDU中User Data 一一对应。 6 | 7 | 使能或是关闭PNC，最终的表现就是允许PNC关联的Node（或者说Channel）通信与否。我们知道应用报文（Com层对应的Pdu）的发送/关闭由BswM管控，如果ECU收到的PNC关联其对应的某个Channel，ComM模块就会进行通信请求（进行状态切换），BswM获取请求信息后，使能或者禁止Com层对应的I-PDU groups通信。 8 | 9 | 1 10 | 11 | ComM对PNC管理 12 | 13 | 14 | 15 | 前面我们说PN功能开启需要在CanNM模块打开CanNmPnEnabled参数，而在ComM模块还需要将配置参数**ComMPncSupport**打开。在Autosar中，规定CanNmPnEnabled和ComMPncSupport需要存储在NVM中，以便诊断服务使用，但是在实际的项目开发中，是否这样实现还是需要看具体项目需求。 16 | 17 | ComM管理每一个PNC状态的切换，当状态切换时，均需要通过接口BswM_ComM_CurrentPncMode()通知到BswM，以便BswM对Com层的I-PDU groups进行通信的管控。 18 | 19 | ComM在管控每个PNC状态机之前，首先要获取对应Channel的PNC信息，PNC信息通过Com层标准信号接口获取ERA signal或者EIRA signal。如果signal是多字节的，一般会在Com层配置成uint8_n类型。 20 | 21 | Autosar里规定PNC对应的信号，最大可以包含56个PNC状态位信息，这最大56是如何来的呢？对于一个经典CAN帧，一个PDU中最多携带8 byte有效数据，在CanNM模块中，**CBV字节是必须的**，而NodeID是可选则，这样在CanNM层级最多可以有7 byte的User Data，因此ComM最多可以管控7*8 = 56个PNC。 22 | 23 | 虽然NodeID在CanNM是可选的，但还是要识别和过滤NM PDU，当NodeID在CanNM可选时，可以依赖xxIf层或者驱动层对NM PDU过滤和识别，驱动层负责将有效ID范围的NM PDU送给xxIf层，xxIf层通过识别ID，负责将该PDU发送给对应的上层，比如：xx_TP层，xx_NM层等。 24 | 25 | 一直在说ComM通过信号获取对应的PNC信息，这里我们再具体说一下，对ComM来说，获取的是 EIRA 或者 ERA信号，这两个信号独立。可以使用其中一个，也可以均使用，ComM通过Com_ReceiveSignal()接口获取。 26 | 27 | ComM既然会接收信号，当然也会将PNC状态信息通过信号发送给对应的通信总线。 28 | 29 | ComM模块可以处理EIRA 或者ERA信号的接收，但是发送只能处理EIRA信号。 30 | 31 | 2 32 | 33 | ComM PNC状态机 34 | 35 | 对于每个Partial Network，会对应一个PNC状态机，因为PNC最多可以有56个，因此ComM最多可以管理56个PNC状态机。注意：PNC和ComM层的Channel不是一个概念，ComM的Channel对应具体的物理总线数。 36 | 37 | 在ComM模块中，**一个Channel可以对应一个PNC，也可以对应多个PNC**。 38 | 39 | ComM管理的PNC状态机包括两大Mode：PNC_FULL_COMMUNICATION、PNC_NO_COMMUNICATION。PNC_FULL_COMMUNICATION模式又包含三个子状态：PNC_PREPARE_SLEEP、PNC_READY_SLEEP、PNC_REQUESTED。 40 | 41 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyGEiasFVS3NAj7Xpx7FmetnkLEoI82Xlv3kjWA7ndNLr0EDiaqUOaQ6I0NQyCFpgRq49m3KmzdD2Pw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 42 | 43 | 对上图状态行为进行解读： 44 | 45 | 46 | 47 | ## PNC_NO_COMMUNICATION主状态行为 48 | 49 | 系统上电时，PNC默认状态即PNC_NO_COMMUNICATION。如果某个PNC进入PNC_NO_COMMUNICATION状态后，没有收到内部或者外部请求，则状态不跳转。 50 | 51 | （1）**EcuM或者NM模块调用ComM_EcuM_WakeUpIndication()接口,且配置参数ComMSynchronousWakeUp = TRUE**，PNC的状态由PNC_NO_COMMUNICATION切换到PNC_FULL_COMMUNICATION::PNC_PREPARE_SLEEP状态。且该PNC对应的ComMPncPrepareSleepTimer（ComMPncPrepareSleepTimer > 0）启动，同时通知到BswM，PNC状态切换。 52 | 53 | **（2）EcuM模块调用ComM_EcuM_WakeUpIndication()接口,且配置参数****ComM_PncWakeUpEnabled = TRUE** ,PNC的状态由PNC_NO_COMMUNICATION切换到PNC_FULL_COMMUNICATION::PNC_PREPARE_SLEEP状态。且该PNC对应的ComMPncPrepareSleepTimer启动（ComMPncPrepareSleepTimer > 0），同时通知到BswM，PNC状态切换。 54 | 55 | （3）如果PNC请求信号收到（至少一个bit在EIRA 中置位），PNC的状态由PNC_NO_COMMUNICATION切换到PNC_FULL_COMMUNICATION::PNC_READY_SLEEP 状态。 56 | 57 | （4）如果ComMUser调用ComM_RequestComMode()接口请求 FULL_COMMUNICATION，PNC的状态由PNC_NO_COMMUNICATION切换到PNC_FULL_COMMUNICATION::PNC_REQUESTED 状态。 58 | 59 | （5）**如果PNC请求信号收到（至少一个bit在ERA 中置位）**，AND **ComMPncGatewayEnabled = TRUE**，AND **ComMPncGatewayType != NONE**。PNC的状态由PNC_NO_COMMUNICATION切换到PNC_FULL_COMMUNICATION::PNC_REQUESTED 状态。 60 | 61 | ## PNC_FULL_COMMUNICATION主状态行为 62 | 63 | 该状态下，所有与此PNC关联的通道均进入Full Communication状态。 64 | 65 | ***\*进入PNC_REQUESTED子\**状态工况：** 66 | 67 | - ComMUser对此PNC请求COMM_FULL_COMMUNICATION； 68 | - ERA信号中的PNC置位，且此PN是同步的。 69 | 70 | **进入PNC_PREPARE_SLEEP子状态工况：** 71 | 72 | - 接收的EIRA信号PNC未置位； 73 | - EcuM通知ComM，Passive唤醒事件发生，且是同步唤醒，且ComMPncPrepareSleepTimer > 0。 74 | 75 | **进入PNC_READY_SLE****EP子状态工况：** 76 | 77 | 此PN的所有ComMUser请求COMM_NO_COMMUNICATION， AND 接收到的EIRA信号PNC置位 ，AND 所有的ERA信号PN未置位，且此PN是同步的。 78 | 79 | 3 80 | 81 | PNC Gateway 82 | 83 | 84 | 85 | 使能PNC的网关功能，需要在ComM中配置参数**ComMPncGatewayEnabled = TRUE**。默认的网关类型是：COMM_GATEWAY_TYPE_ACTIVE。 86 | 87 | PNC的网关类型分为：Active PNC Gateway和Passive PNC Gateway 两种。 88 | 89 | ComM通过ERA或者EIRA与其他ECU交互PNC信息。对于ERA，**仅当PNC网关功能开启**，**分配给多个ComM通道时可用**。每个PNC在位向量中使用相同的位位置，由 PNC ID 定义。比如：定义PNC1、PNC2，这两个PNC均长度均为2 byte，其中bit0均表示关联某个ECU的指定Channel与否。 90 | 91 | **ComM负责协调网络的网关行为**，即**将PNC激活请求**从一个通道路由到其他通道。**通过发送 EIRA TX 信号完成路由**。**通道的路由取决于该通道的网关类型**。 92 | 93 | ## PNC请求在Passive通道 94 | 95 | 如果在网关类型为PASSIVE的通道上接收到ERA=1的请求，则该请求不会镜像回该通道，即该请求不会在EIRA Tx 信号中设置，并且不会路由到网关类型为PASSIVE的通道。请求仅路由到网关类型为ACTIVE 的通道。 96 | 97 | ## PNC请求在active通道 98 | 99 | 如果在网关类型为 ACTIVE 的通道上通过 ERA=1接收到PN请求，则该请求会镜像回此通道，且路由到所有其他协调通道。 100 | 101 | ## PNC请求在网关类型为NONE的通道 102 | 103 | 如果在网关类型为NONE的通道上通过ERA=1接收到请求，则该请求不会存储在内部ComM ERA信号中，即该PNC请求被忽略。因此，请求不会镜像回此通道，也不会路由到任何其他通道，即请求不会设置在EIRA发射信号中。 104 | 105 | 网关类型为NONE的通道忽略通过ERA信号接收的PNC请求，但它们处理通过 EIRA Rx 信号接收的PNC请求。在这种情况下，目标PNC状态不受通过 ERA 接收的PNC请求影响，但通过EIRA=1 接收的 PNC 请求而进行状态改变。 106 | 107 | -------------------------------------------------------------------------------- /autosar/NM/PN/8.Autosar网络管理：为什么要网络管理.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：为什么要网络管理 2 | 3 | 近几年，汽车智能化和网联化的发展，使得更多的控制器（ECU）被部署到E/E(Electronic/ Electrical)架构中。更多的ECU被部署到整车网络拓扑中，意味着：总线中的Message（报文）数量增加，网络系统的复杂度提高。虽然，单个节点（eg：CAN节点）的容错很高，但是，当多个节点放到整车环境中，工况复杂多变时，整车通信的稳定性是否还能像单节点那样，稳定可靠呢？没人敢保证。实际的工程开发中，我们也能体会到这一点：明明单件开发时，功能都很正常，但是，将单件集成到整车环境中，一测试，问题总是不停的报出来。为了提高整车网络的稳定性，网络管理必不可少，网络管理通过协调各个节点的网络状态，进而控制节点间的通信行为，增加车辆的安全与稳定。 4 | 5 | **提示：**本文讨论CAN总线网络管理。 6 | 7 | 不管何种总线，它们的载体都是Message，也就是我们常说的"报文"。报文中携带着信号（Signal），通过Signal的接收、处理、发送，控制着车辆的各个功能，当然，也会因这些信号的收/发时机不对带来各种各样的问题。为了更好的约束这些信号的收/发时机，Autosar CanNM定义了网络管理状态： 8 | 9 | **Network Mode**（Repeat Message State、Normal Operation State、Ready Sleep State）、**Prepare Bus-Sleep Mode**、**Bus-Sleep Mode**。不同的网络状态下，约束着各类报文报文的收/发行为，进而管理好整车网络。 10 | 11 | ## 1、常见NM工程需求 12 | 13 | 工程中，比较常见的一种CAN网络管理需求如下所示： 14 | 15 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vx9tVZwCcTMH6lzwrbpLl8ogsyGBqTcIhVLMIW8ic9p7MicRbicHcPfGfd85JoslnQajw4r47cJwhiaDw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 16 | 17 | **需求解读：** 18 | 19 | （一）**Bus-Sleep Mode：**不能发送NM Msg，可以接收NM Msg，App Msg既不能发送，也不能接收。这里解释一下App Msg，App Msg包括：诊断报文、标定报文、应用报文、测试报文等。这里的测试报文是一种预留报文，主要用于开发阶段，携带一些目标信息，便于Bug问题排查。 20 | 21 | （二）**Prepare Bus-Sleep Mode：**不能发送NM Msg，可以接收NM Msg，App Msg既不能发送，也不能接收。 22 | 23 | （三）**Neteork Mode：** 24 | 25 | - **Repeat Message State**：NM Msg和App Msg即可以收，也可以发送。 26 | - **Normal Operation State**：NM Msg和App Msg即可以接收，也可以发送。进一步细化，对于能进入NOS状态的节点来说，意味着该节点是主动网络节点，在该状态下，会周期性地发送网络管理报文。 27 | - **Ready Sleep State**：NM Msg可以接收，不能发送，App Msg即可以收，也可以发送。进入RSS状态，意味着节点网络的“Release”，所以释放网络的节点就停发NM Msg，表达自己不想通信的意愿。 28 | 29 | 通过如上的需求可以看出，整个网络管理依赖一个特征报文（NM Msg），这个特征报文可以控制着整个网段内各个节点的网络状态。网络状态的切换进而控制着各类报文的收/发行为。 30 | 31 | 所以，网络管理的实质是在管理各类报文的收/发时机。可是，网络管理的目的是“**节能**”，如何节能呢？节能的本质是降低对车辆蓄电池的耗电，工作的ECU越多，耗电量就越多，所以，减少非必要工作ECU的数量就可以降低电量消耗。我们进一步想：怎样让非必要的ECU不工作呢？通过停发NM Msg协调网段内的ECU节点进入BSM模式，进而再停发App报文，最终，让这些ECU休眠，以此达到节能的目的。 32 | 33 | **比如：**某一时刻，CAN 1总线上的ECU1和ECU2没必要参与工作，可以让ECU1和ECU2释放网络（停发NM Msg），进而切换两者的网络状态，最终让ECU1和ECU2休眠。 34 | 35 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzf7RAiaW6sJJhfQicSib75SZY7das6aOY3xgNOvkuVh5xDzOicb0pjyb4H6pLa7P5aCfJ4dWhBoEuh5g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 36 | 37 | ## 2、局部网络管理(PN：Partical Network) 38 | 39 | 对于刚才所讨论的网络管理问题，有一个特点：一个网段内的节点要不一起醒，要不一起睡。如此这样，就不能满足一些工况的需求。我们假设几个场景： 40 | 41 | **场景一**：对于新能源车，插枪充电时，一个网段内的部分节点（ECU）没必要工作，只要参与充电功能的节点工作即可。 42 | 43 | **场景二**：ECU下电，同一个网段内的某些节点有延时下电要求（eg:5min），有些节点则不需要延时下电，如果延时下电的节点一直拉着非延时下电节点，不让其休眠，势必增加蓄电池的耗电，怎么办呢？ 44 | 45 | **场景三：**车辆无钥匙进入功能，车主携带钥匙靠近车辆时，车门自动开锁并解除防盗警戒状态，同时车灯闪烁，这些功能是不需要所有ECU参与工作的。 46 | 47 | 上述的场景很多，不一一列举。对于这样的工况，局部网络管理（PN）应运而生。PN的目的：在全局网络管理的基础上进一步节能。 48 | 49 | 与全局网络管理不同，局部网络管理根据组件功能划分不同的网络簇（PNC：Partial Network Cluster），每一个PNC就是一个虚拟的局部网络。PNC可以在同一个网段，也可以跨不同的网段。 50 | 51 | **（一）PNC在同一个网段，如下所示：** 52 | 53 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzf7RAiaW6sJJhfQicSib75SZY9eQ2esYdguFkbwiblHckjWicgyKFR9LibkXRgSO2eo5ogER3xsCRYv5Hg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 54 | 55 | 如上，ECU6、ECU7、ECU8均在CAN 3总线，其中，ECU6、ECU7构成PNC 16局部网络簇，ECU7、ECU8构成PNC 17局部网络簇。注意：一个节点可以被划分到不同的局部网络簇，eg：ECU7。 56 | 57 | **（二）PNC在不同的网段，如下所示：** 58 | 59 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzf7RAiaW6sJJhfQicSib75SZYlGx5QBmqah4eF1HUML2H5XDxeQOHI4MtN24Wg9KRcgYA61dYCD1rVQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 60 | 61 | 如上，ECU3在CAN 2总线，ECU6、ECU7、ECU8在CAN 3总线，其中，ECU3、ECU6构成PNC 16局部网络簇，这里的PNC16就是跨网段管理。ECU7、ECU8构成PNC 17局部网络簇。 62 | 63 | 全局网络管理通过特征报文（NM Msg）管理各个节点的网络状态，同样，对于局部网络管理，也是通过特征报文管理PNC的网络状态。每个PNC包含两个网络模式：**PNC_FULL_COMMUNICATION**与**PNC_NO_COMMUNICATION**。其中，PNC_FULL_COMMUNICATION网络模式又包含三个网络状态：**PNC_PREPARE_SLEEP、PNC_READY_SLEEP 、PNC_REQUESTED**。 64 | 65 | 66 | 67 | 不同于全局网络管理，局部网络管理的PNC信息存放在NM Msg的User Data部分，如下所示： 68 | 69 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzf7RAiaW6sJJhfQicSib75SZYT3SVbTtiaywllcjmiapHx8TnaMAzytNibfzMQnjADDvXoywPOIxYKEQYg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 70 | 71 | 每个局部网络簇分配一个PNC ID，每个PNC ID占用User Data的一个Bit。进行PN网络状态管理时，PNI（Partial Network Information）必须有效，只有PNI有效以后，才去进一步识别PNC ID是否关联对应的节点（ECU）。 72 | 73 | PNI在NM Msg中的位置如下所示： 74 | 75 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzf7RAiaW6sJJhfQicSib75SZYqicVshw4K3qSQY3lJFaTxAgvcVMib7x6lvicic4m89F8VtKZkyyYPPns9g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) -------------------------------------------------------------------------------- /autosar/NM/PN/9.Autosar网络管理：PNC = 0，为何不能路由？.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：PNC = 0，为何不能路由？ 2 | 3 | 本文讨论Autosar局部网络管理（Partial Network）的一个问题：“对于网关（Gateway）节点，Channel A收到PNC #n = 0，可以路由到Channel B吗？（假设Channel B的PNC Gateway Type = Active）”，在给出答案之前，先假设几个工况。 4 | 5 | ## 工况一 6 | 7 | 某个网络拓扑如下所示： 8 | 9 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwuSCf7fTfYF3uKtf97tQxqUVnGaQxkkAjTMseVjTCFt77Eliblia64S0vf8iao5yVO2cbklhuv7ZAIg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 10 | 11 | 网关节点（ECU 0）包含两个Node：Node A、Node B，其中Node A的PNC Gateway Type = Passive，Node B的PNC Gateway Type = Active。ECU 1包含Node C，ECU2包含Node D。其中：Node B关联PNC 16，即：Node B收到PNC 16 = 1的网络管理报文，发送的网络管理报文中，PNC 16置位（=1）。 12 | 13 | 如下工况： 14 | 15 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwuSCf7fTfYF3uKtf97tQxqWjCZN50xAloUBv4xCsu63SbibGibQNvWD3LVMuQibicpfmEo5LqypGqS9A/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 16 | 17 | **T0时刻**，Node D发送的NM Msg中，PNC 16 = 1; 18 | 19 | **T1时刻**，Node C发送的NM Msg中，PNC 16 = 0，Node A接收到PNC 16 = 0; 20 | 21 | **T2时刻**，假设Node A可以将PNC 16 = 0路由给Node B，则Node B此时发送的NM Msg中，PNC 16应该等于多少？ 22 | 23 | 如上，Node C和Node D分属不同的网段，两者发送NM Msg的时机存在不确定性，因此T0与T1之间的间隔不确定。如果Node B接收到Node D NM Msg(PNC 16 = 1)之后，同时又收到了Node A路由过来的PNC 16 = 0，可能使得Node B最终收到的PNC 16 = 0，当Node B发送NM Msg时，PNC 16可能一直等于0，如果Node D收到的PNC 16 = 0，则Node D关联PNC 16的应用报文均不会处理（这里的不处理包括接收和发送）。 24 | 25 | 因此，网关节点收到的NM Msg中，PNC 16 = 0时，不可以路由到其他节点（或者说网段）。 26 | 27 | ## 工况二 28 | 29 | 假设，某网络拓扑如下所示： 30 | 31 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwuSCf7fTfYF3uKtf97tQxqLrJaBtvTPt0HDb4cNUGjYIfqM2ZeAnFoH36iaoicbqM5UicKb61SkzeFQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 32 | 33 | 网关节点ECU 0包含三个Node：Node A、Node B、Node C，其中，Node A和Node B的PNC Gateway Type = Passive，Node C的PNC Gateway Type = Active。ECU 1包含Node D，ECU 2包含Node E，ECU 3包含Node F。 34 | 35 | 工况如下： 36 | 37 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwuSCf7fTfYF3uKtf97tQxqx1gzwrmbISvY1cU0nvb8voXGL2lWibjkxVnoTZfOYic5cw3GWG17IM7w/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 38 | 39 | **T0时刻**，Node F发送的NM Msg中，PNC 16 = 1，通过Node B路由给Node C； 40 | 41 | **T1时刻**，Node D发送的NM Msg中，PNC 16 = 0（假设PNC = 0可以路由），通过Node A路由给Node C； 42 | 43 | **T2时刻**，Node C发送的NM Msg中，PNC 16 = ？ 44 | 45 | 显然，此工况造成的问题同工况一，不再赘述。因此，网关节点收到NM Msg中，PNC = 0时，不可以路由到其他网段。 46 | 47 | 因此，对于**网关节点项目，PN网络管理中，只能路由PNC = 1的信息，这点类似COM模块的信号（Signal）路由，只有接收的UB（Update Bit）信号有效，接收的Signal才能路由**。对于UB的理解，可以参考前文[工程开发问题（五）：UB(Update-Bits)、UD(Update Deadline)的需求理解及实现](http://mp.weixin.qq.com/s?__biz=MzUyNDU4NTc1NQ==&mid=2247488494&idx=1&sn=85a345c2ca4b56eaed903efad6c36f1e&chksm=fa2a4d9acd5dc48c069b491e3a3152a16e9555f8ed9793ee9e358d9d1245da0fb2514e51017e&scene=21#wechat_redirect)。 48 | 既然收到的NM Msg中，PNC #n = 0不能路由，那么路由的PNC #n = 1何时复位（ = 0）呢？答：**CanNmPnResetTime超时**。CanNmPnResetTime设置多少合适呢？答：CanNmMsgCycleTime＜CanNmPnResetTime ＜CanNmTimeoutTime。 49 | 50 | **假设：**项目需求中，要求CanNmMsgCycleTime = 1s，CanNmTimeoutTime = 3s。则1s＜CanNmPnResetTime ＜3s，其中，常见的需求中：CanNmPnResetTime = 2.95s。 51 | 52 | ## 为什么CanNmMsgCycleTime＜CanNmPnResetTime ＜CanNmTimeoutTime ？ 53 | 54 | **（一）为什么CanNmMsgCycleTime＜CanNmPnResetTime？** 55 | 56 | 假设：CanNmPnResetTime = 800ms，CanNmMsgCycleTime = 1000ms。 57 | 58 | 网络拓扑如下： 59 | 60 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwuSCf7fTfYF3uKtf97tQxqtMuV2eR1UXCoCmibMJe3XfoNDNWJ7L7fGBoxbSty5tK15hNePPewQDQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 61 | 62 | **需求**：Node A收到 Node C的PNC 16 = 1，需要路由给Node B，Node B发送的PNC 16 = 1，Node D收到PNC 16 = 1的NM Msg以后，发送Message A给Node B。 63 | 64 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwuSCf7fTfYF3uKtf97tQxqXRB0fric1l5XRL3vfqb9BsbrobiaZrDzmTddwicRA2JWR0PFOOFfIdIUQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 65 | 66 | **T0时刻**，Node B发送的NM Msg中，PNC 16 = 0； 67 | 68 | **T1时刻**，Node C发送的NM Msg中，PNC 16 = 1，通过Node A路由给Node B，对应的PNC 16 Bit置位（ = 1）; 69 | 70 | **T2时刻**， CanNmPnResetTime(800ms)超时，对应的PNC 16 Bit复位（ = 0）； 71 | 72 | **T3时刻**，Node B再次发送NM Msg时，PNC 16 = 0，导致Node D不发送Message A。 73 | 74 | **（二）****CanNmPnResetTime ＜CanNmTimeoutTime？** 75 | 76 | 假设：CanNmPnResetTime = 4000ms，CanNmTimeoutTime= 3000ms。 77 | 78 | 网络拓扑如下所示： 79 | 80 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwuSCf7fTfYF3uKtf97tQxqFNZYFN4ZH9UoXKzb9iaeHxuIILMicpBt37wao1gfG6MK9HuPLyExwkbQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 81 | 82 | CAN 2总线上的Node B和Node D网络状态如下所示： 83 | 84 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwuSCf7fTfYF3uKtf97tQxquyKvxeNvmQL0g83h3n7vjyKkiaO9xH4jAN6OicfnrFIs7hM7ibtChJ5iaA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 85 | 86 | **T0时刻**，Node A路由PNC 16 =1给Node B，Node B发送一帧NM Msg，Node B、Node D的CanNmTimeoutTime均重置为3s，并且Node B、Node D同时释放网络，进入RSS（Ready Sleep State）状态，两者均不发送网络管理报文； 87 | 88 | **T1时刻**，由于Node D的CanNmTimeoutTime超时，Node D进入PBSM（Prepare Bus-Sleep Mode）模式，同时停发应用报文； 89 | 90 | 由于CanNmPnResetTime = 4000ms，Node B的PNC 16网络没有释放，导致Node B在T1~T2时间内，一直处于RSS状态，且PNC 16对应的应用报文一直外发，Node B的应用报文可能会导致网段的网络状态不稳定。同时，Node B无法协调同一网段内其他节点的网络状态。因此，需要**CanNmPnResetTime ＜CanNmTimeoutTime。** -------------------------------------------------------------------------------- /autosar/NM/PNC/Autosar网络管理：CanNM网络状态机真的全看懂了？.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：CanNM网络状态机真的全看懂了？ 2 | 3 | 先回答标题问题：“对我自己而言，没有”。有时我自己会有这样的感受，Autosar的某些规范即使看了很多遍，工程上也碰到了些问题，但是每次再去读，发现：依然有些东西是不清晰的。本文就CanNM的网络状态机，再和大家抠几个细节，希望对你有用！ 4 | 5 | ## 1、CanNmPnHandleMultipleNetworkRequests 作用 6 | 7 | 如果项目中，网络管理不用PN（Partial Network）功能，可能不太会关注CanNmPnHandleMultipleNetworkRequests。先看一下Autosar规范给出的解释：Specifies if CanNm performs an additional transition from Network Mode to Repeat Message State (true) or not (false). 8 | 9 | 也就是说，该参数使能与否决定着节点网络状态是否可以切换到RMS（Repeat Message State）。从哪种状态切换到RMS状态呢？ 10 | 11 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vy1XCloMJUBwjTafNImJUg9sfvvVxWvQOnXVEr3IL7iaHH2dHaRyIZLicQcEnbrRFTClKL2sIbXSTUQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 12 | 13 | 由上图可以看出，使用CanNmPnHandleMultipleNetworkRequests参数时，均与CanNm_NetworkRequest()接口的调用相关，主要有两个地方会判断该参数的使能情况。 14 | 15 | **位置 1** 16 | 17 | 如果节点的网络状态在RSS(Ready Sleep State)，调用CanNm_NetworkRequest()接口请求网络时，能否进入NOS(Normal Operation State)取决于CanNmPnHandleMultipleNetworkRequests的使能情况： 18 | 19 | 1. CanNmPnHandleMultipleNetworkRequests = FALSE，节点网络状态由RSS切换到NOS； 20 | 2. CanNmPnHandleMultipleNetworkRequests = TRUE，节点网络状态由RSS切换到RMS。 21 | 22 | 为什么CanNmPnHandleMultipleNetworkRequests = TRUE，网络状态需要切换到RMS状态呢？先看Autosar规范给的解释： 23 | 24 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vy1XCloMJUBwjTafNImJUg9kmXpBWMupEMSzugRNm6IrxmKDTfReY9mz4EJWIibyp8yZHlQnpH6hlg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 25 | 26 | CanNmPnHandleMultipleNetworkRequests 的使能，我们需要先意识到一个前提：**PN的使能**，即：CanNmPnEnabled == true。使用PN功能，意味着每个节点会关联对应的PNC，只有接收到的PNC和节点相关，节点网络才能唤醒。 27 | 28 | 如下图，假设某CAN BUS上有ECU1、ECU2、ECU3三个节点，ECU1关联PNC 16和PNC17，ECU2关联PNC 16，ECU3关联PNC 17。 29 | 30 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vy1XCloMJUBwjTafNImJUg9Ul8PhrdXgR2ZNicmQEA3Zaf9ibZuPeHkJbfSAF0nf5uAjkKCLgezekOA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 31 | 32 | 假设： 33 | 34 | **t0时刻**，只有ECU1和ECU2在通信，即：NM Msg只包含PNC16，且ECU1进入RSS状态，ECU2在NOS状态，ECU3未有唤醒（处于BSM）； 35 | 36 | **t1时刻**，由于ECU1上层主动请求网络，ECU1 需要唤醒ECU3参与通信，主动调用CanNm_NetworkRequest()接口请求网络(比如：对应的PNC17的VFC置位)，同时发送的NM Msg中包含PNC 17。ECU3收到包含PNC17的NM Msg以后，网络状态由BSM进入RMS状态，为了保证三个节点在同一网络状态，因此，ECU1需要从RSS状态切换到RMS状态，同时，ECU1发送的NM Msg中，Repeat Message Request Bit = 1，将ECU2由NOS状态也拉回RMS状态，以此确保三个节点在相同的网络状态。不理解RMR Bit作用，可以参考前文[勘误篇(一)：Autosar网络管理：RepeatMessageRequestBit作用，你清楚吗？](http://mp.weixin.qq.com/s?__biz=MzUyNDU4NTc1NQ==&mid=2247487447&idx=1&sn=0fa6ba9f73244ef1a8ab4ea4a17b6923&chksm=fa2a51a3cd5dd8b54a0ab073a13b9eb12d7dcc9d80587f59b8ce482fca278d66f8e80625ecfc&scene=21#wechat_redirect)； 37 | 38 | **t2时刻**，Repeat Message Timer超时，三者脱离RMS状态，ECU1、ECU2、ECU3进入NOS状态。 39 | 40 | 上述过程如下所示： 41 | 42 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vz8ticLVOFzbSMzrpl6rNuqcv22vsiaG6rNdsEdjZKV5rRaFoLaX0bZBvw0AQOhoRAkVnIj4de8I6nw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 43 | 44 | **位置 2** 45 | 46 | 此处说明，只要在NM（Network Mode）模式下调用CanNm_NetworkRequest()接口，且CanNmPnHandleMultipleNetworkRequests ==TRUE，网络状态需要切换到RMS状态，且重启Repeat Message Timer。分析同上，此处不再赘述。 47 | 48 | 举例说明PNC请求与Channel NM Status关系： 49 | 50 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vz8ticLVOFzbSMzrpl6rNuqcARlRKmLRZicM0ZzfVP0rewUgk51JDlQzgFRhojVIG3aOxELlHuVma0A/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 51 | 52 | **t0时刻**，PNC #n保持请求（PNC #n = 1）,假设PNC #n映射的Channel网络状态为NOS； 53 | 54 | **t1时刻**，PnResetTime（2.95s）内收到PNC #n = 0（或者没有收到），PNC #n释放； 55 | 56 | **t2时刻**，PNC #n再次请求，PNC #n映射的Channel网络状态由NOS进入RMS； 57 | 58 | **t3时刻**，PNC #n保持请求，Channel由RMS进入NOS状态； 59 | 60 | **t4时刻**，2.95s时间内没有PNC #n请求，PNC #n释放，Channel保持NOS状态； 61 | 62 | **t5时刻**，PNC #n再次请求，同t2时刻。 63 | 64 | ## 2、网络启动，第一帧是否应该是网络管理报文？ 65 | 66 | 从网络状态机可以看出，CanNm_PassiveStartup()、CanNm_RxIndication()、CanNm_NetworkRequest()接口的调用均可将节点网络状态切换到RMS。 67 | 68 | **CanNm_NetworkRequest()**：调用此接口，说明节点需要主动唤醒网络，如果此节点由BSM、PBSM模式进入RMS状态，第一帧报文需要是网络管理报文，快速将网段内其他节点唤醒； 69 | 70 | **CanNm_PassiveStartup()、CanNm_RxIndication()**：调用这两个接口，个人理解：第一帧报文没有必要是网络管理报文，因为总线上已经有网络管理报文在发送，说明有主动网络节点发送了网络管理报文，承担着快速唤醒网络的“重任”，所以接收节点无需保证第一帧报文是网络管理报文，接收节点需要做的是把应用报文快速发出，保证功能的快速使能。 71 | 72 | ## 3、CanNmMsgCycleOffset的使用场景 73 | 74 | 网络唤醒时，各主动网络节点均发送各自的NM Msg，会增加总线负载，为了降低网络唤醒时的总线负载，会为每个主动网络节点设置一个Offset值，比如：CanNmMsgCycleOffset。CanNmMsgCycleOffset的使能需要注意： 75 | 76 | 使能快发模式时，CanNmMsgCycleOffset不适用，需要注意的其他条件，Autosar也给出了其他解释，如下所示： 77 | 78 | **CASE 1：** 79 | 80 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vy1XCloMJUBwjTafNImJUg9z6YicgZC3VdicficUrI1hs6A5kbRqve2dDy28NSTnY7vZbO2utQvhOY0Q/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 81 | 82 | **CASE** **2：** 83 | 84 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vy1XCloMJUBwjTafNImJUg9LicGdrPGz2SGvLXBEgmWPVEyricV52X5Tb2o1O7OH5CnnZRLsD7Ihh3g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 85 | 86 | **注意：**CanNmMsgCycleOffset是发出第一帧网络管理报文时的偏移值，即满足NM Msg发送时，第一次发送NM Msg时的偏移。 -------------------------------------------------------------------------------- /autosar/NM/PNC/Autosar网络管理：CanNmPnResetTime对关联Tx PDU的发送影响.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：CanNmPnResetTime对关联Tx PDU的发送影响 2 | 3 | 看到CanNmPnResetTime这个时间参数，大家应该能猜到，本文要聊Partial Network问题，前文中有聊过CanNmPnResetTime，可以参考前文[Autosar网络管理：Partial Network基础](http://mp.weixin.qq.com/s?__biz=MzUyNDU4NTc1NQ==&mid=2247488696&idx=1&sn=33bb533107d4eb07a77c1cea5169fe64&chksm=fa2a4acccd5dc3da7776c36b928fe40c8a329634836a745cda514346ba299fc2f648fe80b296&scene=21#wechat_redirect)。本文着重点：CanNmPnResetTime对关联Tx PDU的发送影响。 4 | 5 | 1 6 | 7 | PNC #n与Tx PDU关系 8 | 9 | 网络管理的需求中，会要求配置不同的PDU Group，而不同的PNC #n会关联不同的PDU Group，进而控制不同PDU的收/发行为。假设：某节点关联PNC16和PNC21，PNC16关联Tx PDU Group01，PNC21关联Tx PDU Group02，Tx PDU Group01内包含Tx PDU 10、Tx PDU 11、Tx PDU 12，Tx PDU Group02内包含Tx PDU 20，如下所示： 10 | 11 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyfSViaZSpgBMypUMiaqCoczbvez6ibaALR8GiaXwpPX1OjQkVS6ChMaXpA0yHSiaP718Wqj7eenFoXYBw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 12 | 13 | 个人认为：平时所说的“PNC #n与某个发送报文关联”表达并不准确，应该是PNC #n与某个PDU Group关联。 14 | 15 | 2 16 | 17 | PNC #n与Tx PDU发送时序 18 | 19 | **举例**：某节点网络类型是主动网络，该节点与PNC21关联，PNC21对应Tx PDU Group02，Tx PDU Group02中包含Tx PDU 20，节点网络管理报文的正常发送周期为1000ms，PNC21置位/复位与Tx PDU 20（周期200ms）的发送行为如下所示： 20 | 21 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyfSViaZSpgBMypUMiaqCoczb6ibp4ibs9bxKSf1ZtIWNt2vY3Hp3PKxyxFo8ice90tSMTmhU7uxKuxUUg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 22 | 23 | **t0时刻**，节点接收到一帧有效的网络管理报文，其中PNC21 = 1，此时重置CanNmPnResetTime（ = 2950ms），这里重置的Timer包括ERA、EIRA的CanNmPnResetTime; 24 | 25 | **t1时刻**，节点发送网络管理报文，**PNC21 = 1**，假设节点在NOS（Normal Operation State），同时重置EIRA的CanNmPnResetTime； 26 | 27 | **t2时刻**，2300ms内没有收到PNC21 = 1的网络管理报文，节点最后一次发送网络管理报文PNC21 = 1，即：CanNmPnResetTime（EIRA）最后一次重置为2950ms； 28 | 29 | **t3时刻**，2950ms内没有收到网络管理报文或者收到的网络管理报文PNC21=0，此时CanNmPnResetTime = 0（ERA），同时复位PNC21，即：PNC21 = 0; 30 | 31 | **t4时刻**，节点发送的网络管理报文，PNC21 = 0； 32 | 33 | **t5时刻**，节点PNC21对应的应用报文Tx PDU 20停发。 34 | 35 | **假设：**网段内只有一个PNC或者其他Channel路由过来某个PNC（比如：PNC21），NM Msg的发送行为如下所示： 36 | 37 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxvo2NHqgL8PLicX5wvjUqeMcovwpD15gUAKIRRtDaS1n4os1a1wAxYhWBFsLlsLBLCDylfiaVg2jmg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 38 | 39 | t3时刻，PNC21 = 0，网络释放（主动调用CanNm_NetworkRelease()接口），使得节点进入RSS(Ready Sleep State)，节点停发应用报文。 40 | 41 | ## 1、CanNmPnResetTime分析 42 | 43 | CanNmPnResetTime实际对应两个Timer，一个**ERA** CanNmPnResetTime，一个**EIRA** CanNmPnResetTime。 44 | 45 | - 每次接收/发送NM Msg时，如果PNC #n = 1，则重置EIRA CanNmPnResetTime，Autosar解释如下所示： 46 | 47 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxvo2NHqgL8PLicX5wvjUqeMvWStfWz3g1qtbJYKGf1gyC2ubBLcdoJXrcX36CA6iaBgqo9f2FQPkvw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 48 | 49 | **注意：**当节点收到PNC #n = 1时，节点自身发送的网络管理报文中，PNC #n = 1，同时CanNmPnResetTime（EIRA）重置。 50 | 51 | - 每次接收NM Msg时，如果PNC #n = 1，则重置ERA CanNmPnResetTime，Autosar解释如下所示： 52 | 53 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxvo2NHqgL8PLicX5wvjUqeM0veShYfBAdP8jEUf4mJoFPvg0nEnbQ5W7LDcLh63pHyBH3MM0vCk1w/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) -------------------------------------------------------------------------------- /autosar/NM/PNC/Autosar网络管理：Partial Network基础 之 ERAEIRA、PNC Gateway.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：Partial Network基础 之 ERA/EIRA、PNC Gateway 2 | 3 | 如果初学Autosar网络管理，Partial Network功能的ERA/EIRA、PNC Gateway相对比较费解（我开始学习这块时的感受）。本文，聊一聊两个概念。 4 | 5 | 1 6 | 7 | PNC路由 8 | 9 | ## 1、PNC路由拓扑 10 | 11 | **假设**：整车中的某部分网络拓扑有4个ECU，ECU1包含两路CAN和一路Flexray，ECU2、ECU4各包含一路CAN，ECU3包含一路Flexray。其中，ECU1承担网关（Gateway）角色，如下所示： 12 | 13 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwJkv5e8NEdXlZibW7bwAOp65BQ5LXImCWD7gibvfxdrCurNpc3k8UPMsQfsicEgkR4KM03EN4lr9aVA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 14 | 15 | PNC路由的实质是将PNC请求（PNC #n）由**总线A转发到总线B**。那如何将PNC请求的信息由当前总线转发到其他总线呢？**依赖ERA信号**。在Autosar规范中，如果使用PNC Gateway功能，需要使能配置参数ComMPncGatewayEnabled （ComM模块的配置参数），即：ComMPncGatewayEnabled = TRUE。当PNC Gateway功能打开以后，默认PNC Gateway = COMM_GATEWAY_TYPE_ACTIVE，除了COMM_GATEWAY_TYPE_ACTIVE，PNC Gateway还有一种类型：COMM_GATEWAY_TYPE_PASSIVE。所以，当PNC Gateway功能打开以后，ComM的Channel可以配置成COMM_GATEWAY_TYPE_ACTIVE或者COMM_GATEWAY_TYPE_PASSIVE。 16 | 17 | ## 2、ERA信号如何传递给ComM呢？ 18 | 19 | ERA信号中包含PNC信息，而PNC信息由NM Msg的User Data部分携带。以CAN总线为例，分析一下ERA信号如何将PNC信息传递给ComM: 20 | 21 | **Step1：**当某个CAN节点由CAN总线接收到NM Msg以后，经由CanIf传递给CanNM，由于PN功能的使能，且配置参数CanNmPnEraCalcEnabled = TRUE。CanNM模块将NM PDU中的User Data（包含PNC信息部分）映射到两个PDU：ERA PDU、EIRA PDU（如果CanNmPnEiraCalcEnabled = TRUE）； 22 | 23 | **Step2：**CanNM通过PduR将ERA PDU路由给COM模块（PduR模块只能路由PDU，不能路由Signal）； 24 | 25 | **Step3：**COM模块将接收到的ERA PDU进一步拆分成ERA Signal（实际工程中，ERA PDU只包含ERA Signal，即：ERA PDU长度 = ERA Signal长度，比如：4 byte）； 26 | 27 | **Step4：**此时，ComM可以通过COM的标准接口Com_ReceiveSignal(Rx_ERA_Signal)获取ERA信号中的PNC信息，再通过Com_SendSignal(Tx_EIRA_Signal）接口将PNC信息发送给目标Channel，进而实现PNC的路由功能。 28 | 29 | ERA信号传递路径如下所示： 30 | 31 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwJkv5e8NEdXlZibW7bwAOp6lW8Zvxu24sZiahicibcb0RCpIRZm6IXjhz2RbfXNtIhK0ZKic3Oicmo2TUw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 32 | 33 | ## 3、PNC路由原理 34 | 35 | PNC路由本质是将当前网段PNC #n请求转到目标网段，也就意味着ECU具有多个物理通道，ECU对应的ComM模块具有多个Channel。使能PNC Gateway以后，即可配置ComM Channel的路由类型：COMM_GATEWAY_TYPE_ACTIVE、COMM_GATEWAY_TYPE_PASSIVE。这两者有什么区别呢？ 36 | 37 | **假设：**某ECU有4个节点，1个Flexray，3个Can。Flexray1和CAN3配置成COMM_GATEWAY_TYPE_PASSIVE；CAN1和CAN2配置成COMM_GATEWAY_TYPE_ACTIVE。Flexray1、CAN1、CAN2、CAN3均关联PNC16。 38 | 39 | **Case1：COMM_GATEWAY_TYPE_PASSIVE节点收到PNC16 = 1** 40 | 41 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwJkv5e8NEdXlZibW7bwAOp63eMFaHr0p2uLQoSYtsCMVdTCwXibGKgkNYTm75wfJHghw51q00EIlNg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 42 | 43 | - Flexray1接收到NM Msg，且PNC16 = 1，Flexray1发送NM Msg时，对应的PNC16没有置位（=1）操作； 44 | - Flexray1需要将PNC16 = 1转发给PNC Gateway类型是COMM_GATEWAY_TYPE_ACTIVE的节点，即：CAN1和CAN2。COMM_GATEWAY_TYPE_ACTIVE节点发送NM Msg时，置位PNC16（=1）； 45 | - Flexray1不会将PNC16 = 1信息转发给PNC Gateway类型是COMM_GATEWAY_TYPE_PASSIVE的节点，即：CAN3。 46 | 47 | **Case2：****COMM_GATEWAY_TYPE_ACTIVE节点收到PNC16 = 1** 48 | 49 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwJkv5e8NEdXlZibW7bwAOp6mibT6pP2S6QMvdK7YYgqazOiaW5noUFcbLMsVNEmibqWBqtzCEmTiaxQxQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 50 | 51 | - CAN1接收到NM Msg，且PNC16 = 1，CAN1发送NM Msg时，对应的PNC16置位（=1）； 52 | - CAN1需要将PNC16 = 1转发给PNC Gateway类型为COMM_GATEWAY_TYPE_ACTIVE、COMM_GATEWAY_TYPE_PASSIVE的节点，即：Flexray、CAN2和CAN3，且这3个节点发送NM Msg时，均将PNC16置位（=1）。 53 | 54 | ## 4、EIRA信号理解 55 | 56 | 对于ComM的某一个Channel可以配置3个Signal，2个Rx Signal：Rx_ERA、Rx_EIRA，1个Tx Signal：Tx_EIRA。就是这3个Signal，配合COM的Com_ReceiveSignal()、Com_SendSignal(），让ComM模块可以实现PNC信息在不同Channel之间的路由。 57 | 58 | 对于EIRA接收过程，与ERA相同，不同的是：EIRA包含的PNC信息不会路由给其他的Channel。所以，ERA与路由相关，EIRA与路由无关。 59 | 60 | Channel对应的Rx_ERA、Rx_EIRA、Tx_EIRA信息设置如下所示： 61 | 62 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwJkv5e8NEdXlZibW7bwAOp6icicmiaicAIScnVsBtfhwsIM2OwrHnkhztul4xcuy93glkTnZibbqrjLm9w/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 63 | 64 | Flexray接收到PNC = 1（COMM_GATEWAY_TYPE_PASSIVE），路由到CAN1、CAN2（COMM_GATEWAY_TYPE_ACTIVE）示意如下所示： 65 | 66 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwkCptwZmFzkPMlHU05oWrLgVdFPqjlEDicjQkI5leooDyhDibbFRIlSvDicH6PF70p5Mllxm8icJiaIEQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) -------------------------------------------------------------------------------- /autosar/NM/PNC/Autosar网络管理：主动唤醒源被动唤醒源与网络主动唤醒被动唤醒的关系.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：主动唤醒源/被动唤醒源与网络主动唤醒/被动唤醒的关系 2 | 3 | 网络管理中，主动唤醒源/被动唤醒源与网络主动唤醒/被动唤醒的关系有时让人傻傻分不清，本文侃侃这几个名词。 4 | 5 | **提示**：基于CAN节点讨论。 6 | 7 | 1 8 | 9 | 主动唤醒源/被动唤醒源 10 | 11 | **主动唤醒源**：承担着主动唤醒网络责任的唤醒源，称为主动唤醒源。比如：KL15硬线，User请求，ERA信号等。 12 | 13 | 1. **KL15硬线**：通过KL15硬线方式唤醒网络，说明当前网络没有节点参与通信，为了快速将网络唤醒，建立通信功能，被KL15硬线唤醒的节点，需要主动地去唤醒网络，进而将网络上其他节点唤醒。所以，可以将KL15硬线看作主动唤醒源。同理，类似于KL15硬线唤醒网络的其他硬线唤醒方式，也可以看作主动唤醒源； 14 | 2. **User请求**：User请求，是指通过ComM_RequestComMode()接口请求通信的方式，发起点为SWC，由于功能需要，节点需要在某些工况下主动拉起其他节点通信； 15 | 3. **ERA信号**：ERA信号怎么看作是主动唤醒源呢？首先，ERA信号的使用，说明当前节点有多个物理Channel(ComM的Channel与之一一对应)，PNC信息需要在不同的Channel之间路由，以实现不同网络唤醒的目的。 16 | 17 | 比如：CAN 1在CAN BUS 1上收到一帧网络管理报文，包含PNC #n = 1，且PNC #n与CAN1和CAN2均关联，PNC #n需要由CAN1路由到CAN2，CAN BUS2网段内可能节点均没有唤醒，需要有节点承担唤醒CAN BUS2 网络的责任，即：主动唤醒CAN BUS2网段内的节点。此时，路由到CAN 2节点的ERA信号就可以充当主动唤醒CAN BUS2上节点的责任，所以ERA信号可以看作主动唤醒源。 18 | 19 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzmX0JBRKq368kkqh9XBYta8SHV4l012YqjWicJ3VApRfzBCSA0Zd3xN7ZRib9DUQxobVs7uoWrYibYA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 20 | 21 | 除了上述的的主动唤醒源，还有一些定时器、传感器也可以作为主动唤醒源。传感器一般与硬线连接，类似于KL15硬线。定时器的使用场景不清楚大家有没有遇到，这里给一个场景：智能补电。如果车辆长时间处于休眠状态，蓄电池可能亏电，亏电会导致车辆无法正常使用。为了防止蓄电池亏电，有些车上会配置智能补电功能，通过定时器设置定时时间，如果此时间内车辆未有启动，则定时器主动触发对应节点的唤醒，对蓄电池进行补电。 22 | 23 | **被动唤醒源**：不需要承担唤醒网络责任的唤醒源，称为被动唤醒源。比如：收到NM Msg。对于收到NM Msg需要分情况讨论： 24 | 25 | 1. **网络管理没有PN功能**：节点收到的网络管理报文没有PNC信息，此时网络管理报文看作被动唤醒源。 26 | 2. **网络管理具有PN功能**：如果对应的ECU充当Gateway角色，且有多个物理Channel，PNC #n关联多个Channel，网络管理报文可看作主动唤醒源（前面提到的ERA信号）；如果PNC #n仅关联本Channel，不需要路由，网络管理报文看作被动唤醒源。 27 | 28 | 2 29 | 30 | 网络主动唤醒/被动唤醒 31 | 32 | **网络主动唤醒**：由主动唤醒源触发，调用CanNm_NetworkRequest()接口唤醒网络的方式称为网络主动唤醒。 33 | 34 | **网络被动唤醒**：由被动唤醒源触发，调用CanNm_PassiveStartUp()接口唤醒网络的方式称为网络被动唤醒。 35 | 36 | ## 问题拓展思考 37 | 38 | 对于PNC模式的切换，群内小伙伴提出了这样一个问题："ERA = 1时，PNC由PNC_NO_COMMUNICATION切换到PNC_REQUESTED。而EIRA = 1时，PNC由PNC_NO_COMMUNICATION切换到PNC_READY_SLEEP"，两者为什么不同呢？ 39 | 40 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwcPcNScv5Cyaq5xv7Ja0w9dTt81k9w8V51zajog2g4ImIEVMickxOhyGdtbWuh2iactWiawVufwc7Gw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 41 | 42 | 关于ERA、EIRA前文已经聊过，可以参考[Autosar网络管理：Partial Network基础 之 ERA/EIRA、PNC Gateway](http://mp.weixin.qq.com/s?__biz=MzUyNDU4NTc1NQ==&mid=2247488858&idx=1&sn=163dd2e1d9000507d5a726543a8d5c21&chksm=fa2a4b2ecd5dc238db82f4e6ba7be2accd7e50b5e30f0f506b860b0351c097df8b3f5510c1bd&scene=21#wechat_redirect)和[Autosar网络管理：CanNmPnResetTime对关联Tx PDU的发送影响](http://mp.weixin.qq.com/s?__biz=MzUyNDU4NTc1NQ==&mid=2247488904&idx=1&sn=3c2edb2298cdbeee772471a70241f56c&chksm=fa2a4bfccd5dc2ea2beb373cfea36e63d37e0882d664794e1b86c4de49f7a21b89c653362b1d&scene=21#wechat_redirect)。这里说一下个人理解：ERA的使用需要配合Gateway的使能，当某个PNC = 1时，说明有节点（假设节点A）需要通信，假设节点A需要和不同网段的其他节点（假设节点C）通信，需要经过节点B、节点D的路由，如下所示： 43 | 44 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyMkgspzzsiajg4oWzCdQQDicFJ2YwF9ttSpialibyB57f5ewsyQjmsps6fQWh7rrvUwKHlayOpFzSwrQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 45 | 46 | 如果想唤醒Can2 Bus的节点C网络，需要节点D（与节点C同一个网段）发送网络管理报文唤醒节点C。主动发起通信的节点A在Can1 Bus，需要和Can2 Bus上的节点C通信，需要外部信号（PNC #n = 1）发送给节点B，由节点B路由给节点D，将PNC信息发送给节点C。 47 | 48 | - ERA = 1，与此PNC相关的节点（B、D）进入PNC_REQUESTED状态，节点B、D的Channel请求进入 COMM_FULL_COMMUNICATION 状态，调用Nm_NetworkRequest()接口将Can 2 Bus上的节点唤醒；如果进入的是PNC_READY_SLEEP模式，ComM将会释放COMM_FULL_COMMUNICATION状态，且PNC信息不能路由，Can 2 Bus上的节点无法唤醒，节点A、C无法通信。 49 | - EIRA = 1，只是想把通信留在本网段，当前节点参与通信即可，不需要和外部网段通信，因此进入PNC_READY_SLEEP状态，网络被动唤醒。 -------------------------------------------------------------------------------- /autosar/NM/PNC/Autosar网络管理：被动唤醒和Passive Channel QA.md: -------------------------------------------------------------------------------- 1 | # Autosar网络管理：被动唤醒和Passive Channel QA 2 | 3 | 关于Autosar网路管理的问题，我聊过很多，有兴趣的可以往前找找。比如：[Autosar网络管理：ERA/EIRA问题QA](https://link.zhihu.com/?target=http%3A//mp.weixin.qq.com/s%3F__biz%3DMzUyNDU4NTc1NQ%3D%3D%26mid%3D2247489285%26idx%3D1%26sn%3D284490bc7494012a4b62fbdc63a21823%26chksm%3Dfa2a4971cd5dc067134144f819405f188d6ea7667ca8571a65bbd423ec86edbfefd5ab58c24b%26scene%3D21%23wechat_redirect)等。本文，继续和大家死磕Autosar网络管理的问题。 4 | 5 | 1、节点被动唤醒，会发网络管理报文吗？ 6 | 7 | 2、对于网关节点，ComM Channel配置为Passive PNC Gateway，对应的PNC Bit何时置位？ 8 | 9 | ### **1、节点被动唤醒，会发网络管理报文吗？** 10 | 11 | 关于被动唤醒源和被动唤醒的解释，前文聊过，可以参考[Autosar网络管理：主动唤醒源/被动唤醒源与网络主动唤醒/被动唤醒的关系](https://link.zhihu.com/?target=http%3A//mp.weixin.qq.com/s%3F__biz%3DMzUyNDU4NTc1NQ%3D%3D%26mid%3D2247489138%26idx%3D1%26sn%3D6975890311fad819099b92c96df00c77%26chksm%3Dfa2a4806cd5dc11017a8c3bd833a596005101c028d55467134baaff978653e7bb31c12493956%26scene%3D21%23wechat_redirect)。何为被动唤醒？简单理解：无需承担网络唤醒责任，只对“自己”负责。比如：节点A收到节点B的有效网络管理报文，节点A确保自己正常唤醒网络即可。但是，节点B可能需要确保网段内的其他节点被唤醒，以便于建立正常的通信。一般，网关节点是网段内第一个被唤醒的节点。 12 | 13 | 这里，节点A属于被动唤醒，问题：节点A可以发送网络管理报文吗？答：分情况，需要看节点A是否是被动网络节点，即：CANNM_PASSIVE_MODE_ENABLED == TRUE ？ 14 | 第一、CANNM_PASSIVE_MODE_ENABLED = TRUE，说明节点A的网络类型是Passive Mode，节点A也就没有外发网络管理报文的能力。 15 | 第二、CANNM_PASSIVE_MODE_ENABLED = FALSE，说明节点A的网络类型非Passive Mode，节点A有发送网络管理报文的能力。 16 | 注意：这里不要和Node Detection功能混淆，Node Detection功能打开，虽然也能使得节点外发网络管理报文，但是时机不同。CanNmNodeDetectionEnabled = TRUE时，节点在NOS（Normal Operation State）或者RSS（Ready Sleep State）状态下，内部请求进入RMS（Repeat Message State）状态时，节点外发网络管理报文会置位RMR Bit，请求网段内的其他节点也进入RMS状态，协调节点网络状态。当节点被动唤醒，由BSM（Bus-Sleep Mode）/PBSM（Prepare Bus-Sleep Mode）进入RMS状态时，发送的网络管理报文，RMR Bit不置位。 17 | （1）节点A收到节点B的网络管理报文（RMR = 1/0），节点A网络状态由PBSM/BSM模式进入RMS状态时，则RMR Bit=0，如下所示： 18 | 19 | ![img](https://pic3.zhimg.com/80/v2-ae7331626adc7e050502352ce83e25ca_720w.webp) 20 | 21 | 22 | （2）节点A网络状态由NOS/RSS进入RMS时，如果是节点A主动请求进入RMS状态，RMR Bit = 1，如下所示： 23 | 24 | ![img](https://pic1.zhimg.com/80/v2-36aae7692e9bdc3e13fbe0c41d069bd4_720w.webp) 25 | 26 | **提示**：内部请求，是指主动调用CanNm_RepeatMessageRequest()接口。 27 | **2、对于网关节点，ComM Channel配置为Passive PNC Gateway，对应的PNC Bit何时置位？** 28 | 29 | ComM Channel配置路由类型时，说明我们是在讨论网关ECU，只有ECU具有多个物理Channel时候，才有Gateway的讨论。本小节讨论ComM Channel配置Passive PNC Gateway时，PNC#n的置位问题。 30 | 31 | **问题**：“ECU4::E节点的路由类型配置成Passive PNC Gateway，当ECU4::E节点收到ECU1::D或者ECU4::F节点的网络管理报文（PNC #n置位），PNC #n关联ECU4::E节点，ECU4::E节点发送的网络管理报文中，PNC #n是否需要置位？”，网络拓扑示意如下： 32 | 33 | ![img](https://pic1.zhimg.com/80/v2-7ecc528ef8e96ed7161d007a5e2c8e8c_720w.webp) 34 | 35 | （1）如果ECU4::E节点收到的网络管理报文来自ECU1::D节点，即使PNC #n置位，ECU4::E节点发送的网络管理报文也不会置位PNC #n，避免中央网关和子网关的互锁。 36 | （2）如果ECU4::E节点收到的网络管理报文来自ECU4::F节点，则ECU4::E节点发送的网络管理报文需要置位PNC #n，以便于唤醒Can2 Bus上的PNC #n网络簇。 -------------------------------------------------------------------------------- /autosar/NM/一文讲透AUTOSAR PNC数据流.md: -------------------------------------------------------------------------------- 1 | # 一文讲透AUTOSAR PNC数据流 2 | 3 | ## 1.从PN到PNC 4 | 5 | PN一般指Partial Networking，中文名是部分网络或局部网络。 6 | 7 | 根据AUTOSAR_EXP_LayeredSoftwareArchitecture这篇PPT的说法，PN的初衷是在AUTOSAR中，实施高效的能源管理，其目标是提供一种节能机制，尤其是在总线通信处于激活状态时（例如充电或KL15处于激活状态时）。 8 | 9 | Partial Networking允许在不需要那么多ECU工作的时候，关闭一批ECU的网络通信。其他ECU可以继续在同一总线通道（比如动力CAN）上通信。对于从节点来说，就是需要你的时候，你必须在；不需要你的时候，你必须闭嘴。通常CAN和FlexRay是支持Partial Networking的。 10 | 11 | Partial Networking的兄弟被称为Pretended Networking，姑且翻译为装模作样联网。这种方式允许在总线通信时关闭现有网络中的ECU，节点可以自行决定是否切换到休眠模式。比如一个从节点，把KL15拔了，ECU就不工作了，发什么CAN报文唤醒都不起作用。 12 | 13 | 14 | 15 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/fOVQt3pZrMbtibM4SYp3FR25Sdia9rnibdtuLMmia929H8H2iccxKB3NnEkFyMySQvlGuzY56r2S3y91QibxrHawnGXQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)AUTOSAR_EXP_LayeredSoftwareArchitecture（V4.2.2）p155 16 | 17 | 18 | 19 | 如上图，黑线是真实的CAN总线，ECU A、B、C、D都被真实的双绞线连在了一起。但是！从功能上来讲，ECU A和B可以划分为一组，ECU B、C、D可以划分为一组。这样我们就把真实的物理CAN总线，圈成了两个相对独立的网络小组，组1和组2。我们管这样的小组叫做Partial Network Cluster，中文名是部分网络集群，姑且理解为虚拟CAN小组。这些小组成员的特点是，要醒一起醒，要睡一起睡。 20 | 21 | PNC一般指Partial Network Cluster，是一组用于支持车辆功能的系统信号，这些功能分布在车辆网络中的多个ECU上。 22 | 23 | PNC若是蝶，它化茧成蝶之前是VFC。VFC指Virtual Function Cluster， 是初期设计阶段的一种通信概念，用于实现一个或多个车辆功能所需的软件组件之间的端口级通信。这里要解释下AUTOSAR的开发思想，为了实现功能我们需要若干个SWC（Software component，软件组件）。这些SWC根据功能组成了若干个CSWC（Composition SWC），把CSWC之间的端口（Port）连在一起，就组成了VFC网络。 24 | 25 | 26 | 27 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/fOVQt3pZrMbtibM4SYp3FR25Sdia9rnibdtaPjTXjp6ha51wxRxevsA8icBP5alAAsqkXUA7Z5W7ra7B1iblpiclKQvw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)AUTOSAR_EXP_LayeredSoftwareArchitecture（V4.2.2）p158 28 | 29 | 30 | 31 | 后来，图纸变成了现实，VFC变成了PNC（基于CAN的）和ECU内部的Interface，CSWC则变成了真实的ECU。 32 | 33 | 34 | 35 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/fOVQt3pZrMbtibM4SYp3FR25Sdia9rnibdt9FK6TVIhibdUbfCk39HBia4n15SScmIemOjgLyTbE8XIVUX090SBS0dQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)AUTOSAR_EXP_LayeredSoftwareArchitecture（V4.2.2）p158 36 | 37 | 38 | 39 | **总结：PNC是住在CAN Bus上的小团体，既求同年同月同日醒，又求同年同月同日睡。** 40 | 41 | ## 2.PNC醒和睡的暗号是什么 42 | 43 | CAN上的网络管理帧有8个字节，通常我们会占用Byte2（含Byte2）之后的字节，作为PNC的区域。举个例子，Byte2里头有效的PNC位就是PNC16-PNC23，Byte7里头有效的PNC位就是PNC56-PNC63。以PNC16举例，如果这个位的值是1，就是PNC生效，反之为0则PNC失效。 44 | 45 | 46 | 47 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/fOVQt3pZrMbtibM4SYp3FR25Sdia9rnibdtaGqXXJYXvibDib3Sib4wCibLDHAc7Z0ib3FsNG0WeKQlFI2xFNYZVPsjuJw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)AUTOSAR_SWS_CANNetworkManagement（V4.2.2）p32 48 | 49 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/fOVQt3pZrMbtibM4SYp3FR25Sdia9rnibdtVibKCewZOeHakwC0ZMIOxk4xhAl2Y7S04EjW5AwrY7goyLaLZOql3Mw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)AUTOSAR_SWS_CANNetworkManagement（V4.2.2）p33 50 | 51 | 52 | 53 | 这里也要注意，对于一帧含有PNC信息的网络管理报文来说，位于Byte1（CBV，控制位向量）的PNI Bit是需要置起的，这是后续判断PNC生效与否的先决条件。即PNI Bit若为1，则需要继续检查PNC各个位是否置起；PNI Bit若为0，PNC信息整体丢失，注意不是失效，是上层收不到PNC信息。 54 | 55 | **总结：PNC有效与失效的信息藏在网络管理报文的User data中，以位为最小单位，1有效，0无效。但PNI是前提条件，PNI为1，PNC信息才能向上层传递；PNI为0，算作没收到PNC信息。** 56 | 57 | ## 3.从站获取PNC信息的数据流 58 | 59 | 60 | 61 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/fOVQt3pZrMbtibM4SYp3FR25Sdia9rnibdt3hiabAInRmx7zzJNYEqicz2blxEEKVF6AdO6HxX2eOXCuKiboQunlSJVQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1)AUTOSAR_EXP_LayeredSoftwareArchitecture（V4.2.2）p159 62 | 63 | ![图片](https://mmbiz.qpic.cn/mmbiz_jpg/fOVQt3pZrMbtibM4SYp3FR25Sdia9rnibdtGlaplMiaQ0WOo9KLLDFOZmZqUQb57j58qKvykeINicgHScQNiaHlWiaMYw/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1) 64 | 65 | 66 | 67 | 我们看下数据流的流向。为了获取到EIRA（External Internal Request Array）这个信息，我们在Ecu Config中设置了三个Global PDU，即PDU_CanIf_CanNm(8bytes)，PDU_EIRA_CanNm_PduR(6bytes)，PDU_EIRA_PduR_Com(6bytes)。 68 | 69 | 首先是CanIf，我们在这里可以先对网络管理报文根据CAN ID进行滤波，之后将数据放到PDU_CanIf_CanNm里面。 70 | 71 | 再向上是CanNm，8个字节去掉了Node ID和CBV，变成了6个字节。检查CBV中PNI bit的值，若为1则向上层传递User Data。PNI如果为0的话，就算没收到任何PNC，一定时间后会报超时。 72 | 73 | 到了PduR，我们配置了一条Path，把PDU送往Com（注意这里是Trigger发送），ComSignal我们假定主机厂要求只取前3个字节，后面3个字节被舍弃。这样我们只剩下了原来网络管理帧的Byte2-Byte4。 74 | 75 | 最后ComSignal传给了ComM，我们会进一步通过Pnc Id去找到Pnc的位置，并检查它的值是到底1还是0。 -------------------------------------------------------------------------------- /autosar/NM/从EcuM角度看唤醒源状态切换.md: -------------------------------------------------------------------------------- 1 | # 从EcuM角度看唤醒源状态切换 2 | 3 | **前言** 4 | 5 | ​ 在AUTOSAR中，Ecu的唤醒流程并不能简单的看作是对各个外设模块的供电动作。Autosar给了软件开发人员很大的自由度去设计目标项目Ecu的唤醒动作，而自由度越大的代价就是开发人员需要很好的设计Ecu的唤醒时序，提供Ecu唤醒过程的鲁棒性。 6 | 7 | **唤醒源的状态** 8 | 9 | 在EcuM中规定了唤醒源的4中状态：NONE、PENDING、VALIDATED、EXPIRED。四种状态关系的切换关系如下所示： 10 | 11 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyDjHyv777XHFEswPTSXFSxtz8NFqpPqia1aDyuX1Bj8OCuJyZnRuQZt0LwVjPk2M72MZ8wia6rCu9g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 12 | 13 | ​ 当Ecu上电时，唤醒源的初始状态是NONE，当唤醒源状态切换到NONE时，需要通知到BswM模块，上图也可以看出，唤醒源的每次状态切换都需要通知到BswM模块，通知接口：BswM_EcuM_CurrentWakeup。 14 | 15 | 16 | 17 | ​ EcuM是如何知道有唤醒事件呢？EcuM如果想知道有唤醒Ecu的事件，最好的方式就是给底层提供一个接口或者注册一个回调，Autosar里规定了标准接口：EcuM_SetWakeupEvent。当有唤醒事件发生时，底层的硬件模块（例如：Transceiver、Sensor）最先识别到，之后通过该接口上报给EcuM。 18 | 19 | ​ EcuM主函数会轮询检测底层上报的唤醒事件，如果想进一步的分析唤醒事件是不是有效的总线唤醒源（网络管理报文），需要Ecu有正常的收发报文能力，想要收发报文，Transceiver和Controller两个模块均需要启动。一般来讲，Transceiver会在程序初始化时进入正常的工作模式，而Controller进入正常的工作模式是EcuM调用EcuM_StartWakeupSources的结果，而该接口的内部功能的实现由开发者自行把控，autosar并未做硬性的要求。 20 | 21 | ​ 启动Transceiver和Controller，建立了报文的正常收发能力，Ecu即可进一步的将报文上报上层模块，如：CanIf，即此时Ecu可以拿到总线的Raw Data，不管是不是网络管理报文，Ecu都可以做进一步的功能实现，如收到诊断报文唤醒网络等。 22 | 23 | 一般来说，会在EcuM模块配置两个时间参数，CheckWakeup和ValidateWakeup时间，如果CheckWakeup时间走完走完没有判断到有效的唤醒源，则调用EcuM_StopWakeupSources关闭唤醒源，这里多数关闭controller，进而Ecu失去通信能力。 24 | 25 | ​ ValidateWakeup时间参数配置与否决定了是否使用唤醒事件的验证功能，如果配置该参数，且验证唤醒事件有效后则通知ComM使能通信，调用ComM接口：ComM_EcuM_WakeupIndication。如果该参数没有配置，则EcuM不在绕圈，直接通知BswM唤醒事件有效，通知ComM开启通信。个人理解：该参数配置较合理。第一：可以验证唤醒事件的有效性，避免因总线抖动等干扰造成的非预期Ecu唤醒；第二：如果使用的Transceiver没有Pn功能，Ecu会因总线的扰动而不断的唤醒，假设总线有应用报文没有网络管理报文，ValidateWakeup时间给0，Ecu将会不断的走上下电流程，如果下电选择OFF流程(实际项目中很多开发人员没有开启Reset流程的Operation,即直接冷启动，这不符合autosar规范，也不安全)，将会带来未知问题（如果Ecu内核有一定时间内唤醒次数限制，超过阈值则可能上锁保护），设置该参数可以有效的延迟Ecu唤醒频率。 -------------------------------------------------------------------------------- /autosar/NM/吐血推荐之AUTOSAR网络管理.md: -------------------------------------------------------------------------------- 1 | # 吐血推荐之AUTOSAR网络管理 2 | 3 | 言：最近正好在学习CAN总线的AUTOSAR网络管理，前期踩了很多的坑，总结了一下最近所学和大家一起学习。学的很浅，有不正确的地方请各位前辈同仁不吝赐教~ 4 | 5 | ## 1、什么是AUTOSAR？ 6 | 7 | **官方一点**：AUTOSAR 就是AUTomotive Open System ARchitecture的简称，中文翻译就是汽车开放系统架构。 8 | 9 | **直白一点**：将汽车电子控制单元（ECU）的软件底层做了一个标准的封装。使得大家都能共用一套底层软件，只需要修改其中的一些参数，就可以匹配不同硬件，也可以匹配不同的应用层软件。如此之后，用户只需要专心负责应用层功能开发即可，底层都交给AutoSAR工程师就行了。 10 | 11 | **再直白一点**：“就是一套写的比较好的底层软件”。其实现了硬件驱动的封装（类似于STM32的库），实现了操作系统的功能。用户只需要开发操作系统上层的软件应用即可（类似于基于安卓开发App）。 12 | 13 | **再再再直白一点：**各个厂家在五花八门的硬件上随意开发，想怎么写就怎么写，怎么爽怎么来，导致开发一时爽，维护火葬场，如果底层硬件换掉了，上面的代码基本就要全部推倒重来，而且不同厂家之间的代码移植性也几乎没有，各个厂家和工程师都很头大，于是AUTOSAR应运而生。AUTOSAR将各个硬件的底层接口做了封装，以后如果换硬件，只需要配置一下AUTOSAR，告诉它我换硬件了，赶紧给我适配就可以了，上层代码完全不需要改动就可以使用。从开发的角度来讲，提高了代码的复用性，降低了代码的复杂度，提高了代码的可维护性。 14 | 15 | ## 2、什么是网络管理？ 16 | 17 | 网络管理的目的是使网络中的ECU节点有序的睡眠和唤醒。在没有通信需求的时候睡眠，在需要通信的时候唤醒，可以节约汽车电池的电量。 18 | 19 | ## 3、什么是CAN总线？ 20 | 21 | 这个CSDN和知乎都有很多的介绍，这里就不赘述了。 22 | 23 | ## 4、CAN总线的AUTOSAR网络管理报文（以下简称NM报文）长啥样？ 24 | 25 | 首先要明确一点，NM报文就是CAN报文。NM报文符合CAN报文的格式，由帧起始、仲裁场、控制场、数据场、CRC场、应答场、帧结尾组成。 26 | 27 | 一般厂家在设计的时候会规定好NM报文的ID范围。 28 | 29 | 举个例子：规定标识符在0x500到0x5FF范围为NM报文。当在CANoe中抓取到此ID范围内的报文，那就是NM报文。 30 | 31 | 32 | 33 | ![图片](https://mmbiz.qpic.cn/mmbiz_jpg/fOVQt3pZrMb0EicMpEXxeGvjRAicqs0BUu7qZjMqGtfNFLy44BkUHFMCREw77HSOZ9wTZ2pWew6BnibC0WXwBMO0Q/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1) 34 | 35 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/fOVQt3pZrMb0EicMpEXxeGvjRAicqs0BUuL0we4iboEcpiciclNfYRcSDcUb2Yolv6OXQSMfDN6cxI8pcaXWHP4BF6g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 36 | 37 | 38 | 39 | NM报文的重点在于数据场8字节里的内容： 40 | 41 | 42 | 43 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/fOVQt3pZrMb0EicMpEXxeGvjRAicqs0BUutHEbuvEkdxAcH9tKckP3xstcz78pZxPFHslFGd5gC9WZY6dibQvq68Q/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 44 | 45 | 46 | 47 | **Byte0**：这里填的是ECU的地址，或者叫ECU的ID； 48 | 49 | 此报文的ID=一个基础值+ECU的ID，例如厂家规定基础值为0x500，那么此报文的ID=0x500+0x8=0x508； 50 | 51 | 这里要注意区分报文的ID和ECU ID的概念，很容易混淆； 52 | 53 | **Byte1**： 54 | 55 | 56 | 57 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/fOVQt3pZrMb0EicMpEXxeGvjRAicqs0BUuFbh210xg0eWWsQeLGrIonz6SwxKkfNdtruBSYGFIkIz7zfMGzr2otQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 58 | 59 | 60 | 61 | 这里关注下bit0和bit4： 62 | 63 | bit0：当此位置1时强制进入RMS（下面会讲到）； 64 | 65 | bit4：告诉其他节点自身是怎么被唤醒的。 66 | 67 | 置0：被动唤醒、远程唤醒，比如被其他节点发送的NM报文唤醒； 68 | 69 | 置1：主动唤醒、本地唤醒，比如给ECU上电； 70 | 71 | **byte2-byte7**里的user data数据由用户自行定义。 72 | 73 | ## 5、CAN NM状态介绍 74 | 75 | AUTOSAR网络管理有三种状态： 76 | 77 | 睡眠模式（Bus-Sleep Mode）：当节点没有本地网络唤醒以及远程唤醒请求时，ECU通讯控制器切换至睡眠模式，ECU功耗降低至适当水平；此模式下，NM报文**只收不发**，APP报文**不收不发**，当出现有效唤醒源时**必须要被唤醒**； 78 | 79 | 预睡眠模式（Prepare Bus-Sleep Mode）：这个状态是为了等待总线上的所有节点能够在进入Bus-Sleep Mode之前有时间停止节点的active状态（如清空队列中为发送的报文）；此模式下，NM报文**只收不发**，APP报文**不收不发，**如果缓冲区有APP报文那可以继续发完； 80 | 81 | 网络模式（Network Mode）： 82 | 83 | 包含3个子状态： 84 | 85 | 重复报文状态（Repeat Message State）：NM报文可收可发，APP报文可收可发； 86 | 87 | 正常工作状态（Normal Operation State）：NM报文可收可发，APP报文可收可发； 88 | 89 | 准备睡眠状态（Ready Sleep State）：**NM报文只收不发**，APP报文可收可发； 90 | 91 | 总结见下图： 92 | 93 | 94 | 95 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/fOVQt3pZrMb0EicMpEXxeGvjRAicqs0BUuR1tkhziauEf6tGNSuzicicF12PlRSEZ2N7VRwdBtjcet6YtY9ACiaCHAIQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 96 | 97 | 98 | 99 | ## 6、定时器及参数介绍 100 | 101 | 102 | 103 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/fOVQt3pZrMb0EicMpEXxeGvjRAicqs0BUuDhQmcAdzjTRWficNYJ7E7mWeCG8tjoz4GibYzSbBkCFjgD85r9Lliac2g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 104 | 105 | 106 | 107 | 第5小节和第6小节的内容看一遍可能理解不了，学完下面的状态迁移图，再回过来多看几遍就能理解了。 108 | 109 | ## 7、状态机 110 | 111 | 112 | 113 | ![图片](https://mmbiz.qpic.cn/mmbiz_jpg/fOVQt3pZrMb0EicMpEXxeGvjRAicqs0BUuE5LedyLrbT5zKUKtSTkSNZf0wIOUibJBf9kZWHPrThBica3S2BsF8DGQ/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1) 114 | 115 | 116 | 117 | 现在终于来到AUTOSAR网络管理的最难理解也是最容易使人秃头的状态机了，这里我不打算把每一条状态转换的文字描述直接贴上来，跟着我的思路，我们来一个一个看吧。 118 | 119 | 在开始之前，先了解一下各种缩略语： 120 | 121 | > BSM-睡眠模式 NM-网络模式 PBM-预睡眠模式 122 | > RMS-重复报文模式 NOS-正常操作状态 RSS-准备睡眠模式 123 | 124 | **01**：给ECU上电，ECU自己就会初始化进入睡眠模式。如果没有唤醒源来唤醒此节点，那就会一直待在睡眠模式。 125 | 126 | **02+03**：当出现本地唤醒（03）或者远程唤醒（02）时，进入RMS状态。这里再解释下，本地唤醒就是我自己想要**主动**和其他节点通信；远程唤醒是其他节点想要和我通信。 127 | 128 | **04**：我们现在已经走到网络模式的重复报文子状态了。话说为什么叫重复报文子状态呢，因为在这个状态里的时候，ECU需要一直发送周期报文，来告诉别人：我在线，性感ECU在线陪聊，你再不来找我我就要开始想念你...... 129 | 130 | 如果是走03（本地唤醒）进来的，那么需要先在NM Immediate Transmit State中以很快的周期发送N帧报文（例：以20ms的周期连续发送5帧报文），发完这N帧报文再进入到NM Normal Transmit State中以正常的周期发送报文（例：500ms为周期发送报文。这个在上面的表格里有定义）。如果是直接走02进来的，那么直接以正常周期发送NM报文就可以了。一直发到T_repeat_message定时器超时。 131 | 132 | 这一步的目的是如果是本地唤醒的话，可能此ECU下面还有很多从属节点，当此ECU唤醒之后，需要同时唤醒其他兄弟节点一起通信，所以最开始的N帧报文周期很短，目的是为了快速、低延迟地唤醒其他节点。为什么被远程唤醒就不需要这一步呢？欢迎大家在评论区里一起讨论~ 133 | 134 | **06+12**：且慢，我们先来计算一下从BSM到这一步花费了多少时间了。参考上面定时器的定义，在02或03中，最大唤醒时间为T_wake_up=200ms；在04中，T_repeat_message=1600ms。总计1800ms，差不多为2s的时间，此时ECU有可能已经不需要通信了（2019-11-29补充：ECU持续处于唤醒状态的条件是有持续的唤醒源，例如一直有NM报文远程唤醒、或一直有本地唤醒源例如上电）。如果还需要继续通信，走06，进入NOS，继续周期发送NM报文，可以收发APP报文，当不再需要通信了，就停止发送NM报文，等待T_NM_timeout超时之后走09；如果直接不需要通信了，直接走12。 135 | 136 | **10**：收到本地唤醒，进入NOS。 137 | 138 | **11**：收到NM报文的byte1字节的重复请求位如果置1，强制进入RMS。 139 | 140 | **08+14+05**：T_NM_timerout定时器超时，不改变当前状态。定时器需要重置。 141 | 142 | **13**：在RSS状态，NM报文不可以发送。等待T_NM_TIMEOUT定时器超时后进入PBM。 143 | 144 | **15+16**：PBM状态只可以接收NM报文，其他报文不发不收。收到远程唤醒，走15；收到本地唤醒，走16。 145 | 146 | **17**：如果PBM状态收不到任何唤醒源，在T_WAIT_BUS_SLEEP定时器超时后进入BSM。 147 | 148 | 以上就是CAN总线AUTOSAR网络管理的内容分享。之前写这篇文章的时候只是理论学习，最近在实际测试的时候，对AUTOSAR网络管理有了一些新的认识。 149 | 150 | **DUT在RSS状态的时候，如果收到本地唤醒（如KL15电闭合），会走NM\*11进入RMS状态；\*那如果收到远程唤醒报文呢？** 151 | 152 | 根据主机厂的设计不同，可能会有下面两种action：①在RSS收到远程唤醒报文，不会发生状态跳转，但是会重置T_NM_TIMEOUT定时器，即：在RSS状态收到持续的远程报文唤醒，会一直保持在RSS状态，此时DUT不能发出NM报文，但是可以收发APP报文；②在RSS状态收到远程唤醒报文，会重新进入NOS。 -------------------------------------------------------------------------------- /autosar/NM/网络管理中，这几个概念你清楚吗.md: -------------------------------------------------------------------------------- 1 | # 网络管理中，这几个概念你清楚吗 2 | 3 | ## **前言** 4 | 5 | AUTOSAR网络管理实际工程项目中，有时会对一些概念理解不清或者需求不清楚的情况，不知道你是否有同感？本篇就一些网络需求和概念东西做一些分享。 6 | 7 | ### **Network states**/**Network Mode** 8 | 9 | **Network Mode**对应网络开发人员并不陌生，它包含Repeat Message State、Normal Operation State、Ready Sleep State三个子状态。**Network states**包含requested和released两个子状态。 10 | 11 | Network states表示，软件组件是否需要在总线上进行通信，通信与否需要调用CanNm_NetworkRequest/Release接口，接口的调用需要根据实际项目的需求开发，如：收到有效的Power On信号等。 12 | 13 | 节点收到总线NM报文，且没有调用CanNm_NetworkRequest，通信是如何起来的呢？ 14 | 15 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyI2zxZPflE4iatRdOkIANqzZHhIP8RicPuG9qfOJsnbbLf0QcicFguIemOuDyrDRkBRPeIjwiaNxV2iaA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 16 | 17 | 如上图(1)，网络在BSM状态收到NM报文，有两种方式进入NM(Normal Mode)，一种是调用CanNm_NetworkRequest接口，另一种是调用CanNm_PassiveStartup接口。 18 | 19 | CanNm_NetworkRequest接口：这种方式由实际开发需求决定，因为CanNm_NetworkRequest接口不是主动调用的接口，如果需求要求收到本地唤醒源，如：KL15、Power On激活网络，即Network states进入requested，则在上层逻辑中可主动调用该接口实现需求。 20 | 21 | CanNm_PassiveStartup接口：由上图可以看出，如果在BSM/PBSM下收到网络管理报文，且没有调用CanNm_NetworkRequest接口，则程序会主动调用CanNm_PassiveStartup接口，让Network states进入requested，进而节点正常通信。CanNm_PassiveStartup接口之所以被调用，是ComM在COMM_FULL_COMMUNICATION状态下请求网络激活的结果。 22 | 23 | ### **Passive M**ode**/Passive** **Startup** 24 | 25 | Passive Mode:表示该节点只能接收NM PDU，不能外发NM PDU。注意：**Autosar CANNM**规范中规定对于一个节点（即一个ECU）来说，该节点内的所有网络要么都使用Passive Mode，要么都不使用**Passive Mode**。 26 | 27 | Passive Startup：表示该节点网络的启动方式是被动启动，不是主动启动，即该节点接收到总线报文由BSM（Bus Sleep Mode）或者PBSM（Pre-Bus Sleep Mode）进入NM（Normal Mode）。这里的报文一般是NM报文。 28 | 29 | Passive Startup并不是说当前节点不外发网络管理报文，是否外发网络管理报文取决于当前节点是否是Passive Mode，而这需要根据项目需求确定当前节点是否需要设计成Passive Mode。 30 | 31 | 这里提一个问题，**为什么有些节点要设计成**Passive Mode？个人理解：在一个网段里，如果挂接的节点过多，在启动时每个节点都外发自己的NM报文，由于总线仲裁，高优先级的报文可以发送，其它节点的NM报文则会被阻塞，优先级最低节点的NM报文可能外发的时间被大大延迟，导致该节点不能在规定的时间内发出自己的应用报文（一般需求会要求第一帧是NM报文，确保网络被快速激活，之后是应用报文），如果将这样的节点设计成Passive Mode则不存在这样的问题，即这些节点收到其他节点的NM报文以后发送自身的应用报文（应用报文可以增加Offset，即初始第一帧应用报文延时一段时间发送）。减少NM发送，也可以降低一些总线的负载率。 32 | 33 | ## **参考资料** 34 | 35 | （1）AUTOSAR_SWS_CANNetworkManagement.pdf -------------------------------------------------------------------------------- /autosar/NM/网络管理为什么需要ECU保持激活一段时间.md: -------------------------------------------------------------------------------- 1 | # 网络管理为什么需要ECU保持激活一段时间 2 | 3 | 4 | 5 | ## **前言** 6 | 7 | 上一篇中讲只有Transceiver、Controller处于正常工作模式以后才能有效的收发报文，进而才能识别报文的类型（NM Message、XCP Message、Diagnostic Message、APP Message）。但识别出这些报文需要一个前提：ECU上电同时整个主程序运行起来，且需要一定的时间去识别报文类型。 8 | 9 | 项目中，唤醒事件（也称唤醒源）有效性验证为什么要设置一段时间？ECU上电，整个主程序如何运行起来？ 10 | 11 | 本篇就上述问题进行分析。 12 | 13 | ### **唤醒事件有效性验证时间分析** 14 | 15 | 在实际的网络管理项目中，大家可能会遇到这样的需求：**收到有效唤醒事件（如：网络管理报文），网络激活，报文正常收发；如果收到的报文是非网络管理报文，****ECU****需要保持一定时间后休眠（如：ECU****保持5s****，即5s内ECU****处于供电状态）**。注意后者网络仍然在BSM（Bus Sleep Mode），只能此时间内接收报文，不能发送报文。如果ECU在该时间内收到有效唤醒事件（多数是网络管理报文，也可能是有效的Power ON信号报文），网络将激活，进而进行正常的报文收发。 16 | 17 | 注意：ECU**唤醒是网络唤醒的前提条件，ECU****唤醒并不一定网络唤醒，如果网络激活（进入Normal** **Mode****）则ECU****一定唤醒（RUN模式）**。 18 | 19 | 为什么要ECU保持一段时间呢?这里说一下个人理解，ECU自身并不知道唤醒事件是不是有效，ECU只要被供电就从启动文件指定的位置开始执行程序。如果要识别该唤醒事件是不是有效需要上层模块（EcuM）识别，而EcuM从开始验证到确认该事件的有效性需要调用底层模块确认（如：Controller或者Transceiver），这需要时间，且EcuM的验证和确认一般是异步执行，这也需要时间。上述时间其实并不长，项目不同执行的时间不等（每个项目初始化模块数量和读NVM时间不同），但多数在几十毫秒内执行完，但又为什么会要求1s或者5s或者更长呢？个人理解：ECU被唤醒，整个冷启动（可以理解为与电压相关的启动）花费了“较长”的时间，废了这么大劲立马Shutdown有点“过分”，如果ECU下电又被干扰起来还需要重头再来（各个模块、外设初始化、读NVM等），既然这样还不如等待一段时间确定没有有效唤醒事件以后，ECU再走Shutdown流程，进而避免ECU频繁的唤醒->休眠->唤醒，注意是ECU，不是网络被唤醒->休眠->唤醒，网络只有有效唤醒源才能激活。 20 | 21 | ### **ECU上电，程序运行过程分析** 22 | 23 | ECU如果要正常的运行程序，则需要供电，之后程序开始执行：启动文件->BootLoader->Application，进入“main”函数，也就是我们熟知的用户代码程序。用户代码程序包含ASWC的runnable以及各个模块的main handler（如：CanTrcv_30_Tja1145_MainFunction），这些程序在OS的调度下周期性或者事件触发执行，这也是上层模块可以收到消息和处理消息的基础。 24 | 25 | 这里主要分析EcuM管理的上电到程序运行过程。AUTOSAR中，EcuM分为Flexible和Fixed两种类型，因为Fixed并不支持多核且不灵活，本文主要讨论Flexible类型的EcuM。 26 | 27 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyI2zxZPflE4iatRdOkIANqzIrs5iahIcg66twUFFHR4utmrOIeXBcT7PAHJSqbExCmhMZuIZe0dG0A/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 28 | 29 | 如上图(1)所示，C Init Code一般是应用程序的main函数，即EcuM_Init在应用程序的main函数被调用，EcuM将控制ECU的启动流程，EcuM调用StartOS，让Os完成Task的激活。 30 | 31 | EcuM_Init并不能完成MCU所有的初始化动作，在StartPreOS Sequence阶段主要完成DET模块（最先完成初始化，以便其它模块可以上报开发错误）以及一些硬件外设的初始化，如MCU、Port、Internal Watchdog等（主要根据项目需求设置要初始化的外设模块）。 32 | 33 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyI2zxZPflE4iatRdOkIANqzH1M7iauNIyfUPHqiaRc7drqkVliak5ycVNBodzEU5Rm4LIx1Mu6ok4RQw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 34 | 35 | 如上图，EcuM_StartupTwo将完成SchM（Os），BSW模块的初始化，其中各个模块的初始化（Can_Init、CanIf_Init等）在BswM中完成。程序所需的所有外设、模块初始化之后，启动Scheduler 定时，即周期性的执行BSW/SWCs任务，至此Application程序得以运行。 36 | 37 | ## **参考资料** 38 | 39 | (1)AUTOSAR_SWS_ECUStateManager.pdf -------------------------------------------------------------------------------- /autosar/NM/英飞凌TriCore中断向量表的深度剖析.md: -------------------------------------------------------------------------------- 1 | # 英飞凌TriCore中断向量表的深度剖析 2 | 3 | 嵌入式开发中，中断的理解和使用对开发人员来说至关重要，如果不能很好的理解和使用中断，那么在查找和解决问题时很可能一头雾水，无从下手。本文着重从链接文件、Map文件及代码角度梳理中断程序是如何被找到和执行的。本文基于英飞凌Tc277芯片讨论，Tc2xx/Tc3xx类似。 4 | 5 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/xYkoLSnrGQOg2OWDVyRZBKX2Fnx9Wl30ianw6CiamqCAxQZF0fcJiaP3xNlmetsGBWjQ2HZ6Pjz2pJAaCKEoWx0EQ/640?wxfrom=5&wx_lazy=1&wx_co=1) 6 | 7 | 英飞凌中断向量表入口访问理解 8 | 9 | ​ 设计中断之前，需要先理解如下几个问题： 10 | 11 | 1. 中断向量表基地址在哪里定义？ 12 | 2. 中断向量表为每个中断条目预留多少空间？ 13 | 3. 在每个中断条目中如何跳转到中断函数？ 14 | 15 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwpZS7v5Q0wU1MnXiaoWw2Bwwtys445GafqbA0HMxQxh9gJOPzp8HGU6HNPbA23fY0C2Xzib2jIbo9A/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 16 | 17 | ​ 如上图，目标芯片32Bit。在英飞凌产品中，中断入口条目访问的方式有3种，如上所示，本文只讨论常用的方式a。 18 | 19 | ​ (1)中断向量表基地址在哪里定义？ 20 | 21 | ​ 答：一般将CPU中断向量表的基地址定义在链接文件中，这里以*.lsl链接文件为例，如下所示，在链接文件中定义CPU0中断向量表的基地址为0x800F0000。 22 | 23 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwpZS7v5Q0wU1MnXiaoWw2BwMctBvtoDOYoSten2jm3MmUUYX3wSSzdKOea61ZH0lvHUQjf5hMicdBw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 24 | 25 | ​ 一般会将中断函数在链接文件中做弱声明，或者使用如下方式，每个中断定义一个SECTION。 26 | 27 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwpZS7v5Q0wU1MnXiaoWw2BwDKhkB1uLJKV6gQbYFu1kuq4FOwZKicy1AGNH73dUJxGHiaoxnaMpSpRQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 28 | 29 | 中断向量表的基地址定义以后，CPU或者DMA是如何准确找到该地址的入口位置呢？ 30 | 31 | 答：在芯片中有一个特殊功能寄存器(BIV)存放中断向量表的基地址，如下所示： 32 | 33 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxMKONaJULmibg4AqIhNQm4rHOticduhX6vNjabicjIMsnCsJtcB7DibmZBTiakqxBWB69JeKz7lr7iap1A/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 34 | 35 | ​ BIV赋值操作，一般在启动代码中实现，如下所示： 36 | 37 | #define CPU_BIV 0xFE20 /* Load Base Address of Interrupt Vector Table. we will do this later in the program */__mtcr(CPU_BIV, (uint32)__INTTAB(0)) 38 | 39 | ​ 注意：在对特殊功能寄存器进行操作时，不能对地址直接操作，**必须使用编译器指定的内嵌功能函数操作**，本例使用__mtcr对BIV进行赋值。 40 | 41 | （2）中断向量表为每个中断条目预留多少空间？ 42 | 43 | 答：tc277为每个中断条目预留32Byte或者8Byte。这里只讨论使用32byte情况。 44 | 45 | ​ 基地址确定以后即可为CPU中断条目分配空间，Tc277中的每个CPU可以设置255个中断，也就是说每个CPU可以有255个中断向量号（1~255,0是无效中断向量号），且CPU的中断向量号越大优先级越高。如果所有中断均使用，需要分配的空间32*255Byte，实际应用中并不是所有中断都打开。 46 | 47 | （3）在每个中断条目中如何跳转到中断函数？ 48 | 49 | ​ 答：使用方式a可以看出，中断条目所在位置由**中断向量号**和**中断向量表基地址**决定。中断向量号可以在1~255任意配置。 50 | 51 | 举例：配置STM0的中断向量号为37，则STM0的中断条目访问地址 = （(37<<5) | 0x800F0000） = 0x800F04A0。注意，0x800F04A0并不是中断函数的地址，跳转中断函数是在条目空间中通过跳转指令实现的。 52 | 53 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/xYkoLSnrGQOg2OWDVyRZBKX2Fnx9Wl30ianw6CiamqCAxQZF0fcJiaP3xNlmetsGBWjQ2HZ6Pjz2pJAaCKEoWx0EQ/640?wxfrom=5&wx_lazy=1&wx_co=1) 54 | 55 | 中断仲裁 56 | 57 | ​ 在这里再提一下中断的仲裁过程。如下图，中断使能以后，满足中断触发条件后，需要将中断向量号、中断服务者（CPU或者DMA）、ECC信息提供给中断路由模块（IR），中断向量号已经说过，结合中断向量表基地址可以让中断服务者找到准确的中断条目入口地址，进而执行目标功能或者调用中断程序。中断向量号大的优先获得中断服务者的使用权，中断服务者对中断信息进行校验，如果信息正确则执行中断功能，否则报错给SMU（安全管理模块）。 58 | 59 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxMKONaJULmibg4AqIhNQm4rxIiayc1BpJqTpgvCBicsvOjREZe13ygAQsKpKA5tVYHiaIxDNYicDq6Wkg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 60 | 61 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/xYkoLSnrGQOg2OWDVyRZBKX2Fnx9Wl30ianw6CiamqCAxQZF0fcJiaP3xNlmetsGBWjQ2HZ6Pjz2pJAaCKEoWx0EQ/640?wxfrom=5&wx_lazy=1&wx_co=1) 62 | 63 | *.map文件中的中断条目 64 | 65 | ​ 由*.map文件可以看出，在中断条目（每个中断条目占用32 bytes）中，只使用了0xe字节空间(最大可用32 bytes，如果32 bytes可以实现中断需要操作的功能，也可以不跳转到中断函数)，而就这14 bytes指令实现了中断函数的跳转。 66 | 67 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwpZS7v5Q0wU1MnXiaoWw2Bwiadgpk80KRExNlpETsmfmsjoSiciamzfYFkGoMQ0j9ibkiaQOmcUutYJNgg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 68 | 69 | ​ STM0的中断发生以后，通过中断向量号与中断向量表基地址查找到中断条目的入口地址0x800F04A0，在此地址开始继续执行指令，**可以看出14 Bytes指令的最后两个即是跳转指令，即跳转到真正的中断处理函数位置**。 70 | 71 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwpZS7v5Q0wU1MnXiaoWw2BwicF4ZQ5z03Ndhr3h1OKmuib7g9dibF5ibsMsaGOMerxMQv14ZiacMZeJ2kw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 72 | 73 | ​ 看到这，有点好奇这14 bytes指令哪里来的？ 74 | 75 | ​ 看一下代码，是不是和上图的操作指令一摸一样，本例使用了__asm编写部分中断功能，具体不在此展开讨论。 76 | 77 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxMKONaJULmibg4AqIhNQm4rA683EViclticEX8OtYHv9BbEibIskwFmaPFVfwnyasp1NILUVLWVbnOnw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 78 | 79 | ​ 如下图，最后跳转的地址(a14寄存器中的地址)是0x80000518，即中断函数地址。 80 | 81 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwpZS7v5Q0wU1MnXiaoWw2BwZvoFGd6uC30nQ37TTWnQmR7iaOFWVykmWBIWGqPtutv6BhJribBssD6A/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 82 | 83 | ​ 最终执行用户编写的中断函数stm0Sr0ISR。 84 | 85 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vwpZS7v5Q0wU1MnXiaoWw2BwWVfkFx722NOLqerLO5gAiajibfWNicYsJZ7CvFPcxLTicTjtTpFG4ZzTpw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 86 | 87 | 中断函数stm0Sr0ISR在*.map文件标识如下所示，对应地址0x80000518： 88 | 89 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vxMKONaJULmibg4AqIhNQm4rhx9mahgr22wvwBzzR3FBHZD4BC5ZnjZnz1MK49guPx3yEzZNaCqBhw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 90 | 91 | -------------------------------------------------------------------------------- /autosar/NM/（节点唤醒==网络唤醒）？FALSETRUE.md: -------------------------------------------------------------------------------- 1 | # （节点唤醒==网络唤醒）？FALSE:TRUE 2 | 3 | **前言** 4 | 5 | ​ 正如标题所示，节点唤醒等于网络唤醒吗？如果**当前节点有网络管理**，我给的答案很明确，不是！之所以要写这个主题，是因为实际工作中，接触的很多工程师对这两个概念有点混淆，因此本文侃侃这两个概念。注意，本文基于节点有网络管理的前提进行讨论。 6 | 7 | **Autosar EcuM** 8 | 9 | ​ Autosar的模块划分很细，分工也很明确，也正因如此才使得软件有了层次，即分层。同时，也使得抽象模块具有更好的跨平台移植性。 10 | 11 | 这里说一下EcuM模块，本文不讲EcuM功能，但为什么提EcuM呢？EcuM即Ecu Manager，这样直白的解释，我们应该清楚了，EcuM就是管理Ecu的。Autosar中,EcuM使用Phase、Mode、State表示Ecu各个状态，每个层级对内对外可见性不同，EcuM状态图如下所示： 12 | 13 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyzcCz1zTxYrRMT6gMCrOtfOUJL6LjsZbGvLYlHPumTSichAkLkNXbibZ8oYJAtSPrdibHXxuib7rWpIQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 14 | 15 | 由上图是不是可以看出什么？这既是我们常说的“**节点唤醒**”，说的更具体一点就是EcuM切换到Run Phase时，节点唤醒。如果要从外部评判节点唤醒，就是外设功能供电且正常工作，可以在电源中看到电流达到正常的工作电流。但此时网络唤醒了吗？ 16 | 17 | **Autosar xxNM** 18 | 19 | 这里xx指总线类型，CAN/Flexray/Ethernet等。本例以CANNM为例讨论。刚才提到EcuM进入RUN Phase阶段即我们常说的“节点唤醒”，和网络唤醒等价吗？说到这里，我们应该都清楚了，这本就不是一回事。节点唤醒不能看作是网络唤醒。而且Autosar也给了我们很明确的答案，不然为什么又会分出CANNM呢？ 20 | 21 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vyzcCz1zTxYrRMT6gMCrOtf77SpxJeK3qlR8ksToJATtf4nma0OFqV321sB3IJH9x02ictSyb3j4QA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 22 | 23 | ​ 如上图，这个答案给的是不是更明确一些，CANNM和EcuM干的就不是一件事，因此也就不能将两者等价。由上图可以看出，EcuM上电，网络从Bus Sleep Mode切换到Network Mode需要有附加条件，一般是如下两种情况满足其一，第一有网络主动请求（CanNm_NetworkRequest()），第二网络有被动唤醒请求（CanNm_PassiveStartup()）。如果没有外部请求，网络会一直在Bus Sleep Mode状态呆着，如果用Canoe等设备监控，可以看到当前节点不发任何报文到总线上，只能接收总线报文（EcuM在RUN Phase阶段时）。 24 | 25 | ​ 总结来说，就是EcuM处于RUN Phase阶段是网络能进入Network Mode的充分必要条件。换成我们常说的就是：**节点唤醒是网络唤醒的充分必要条件**。 26 | 27 | ​ 说到这里我们应该对这两个概念有了一定认知，如果当前节点有网络管理，且收到网络管理报文唤醒网络，那么总线必须先有一帧报文唤醒Ecu，Ecu进入了RUN Phase阶段，收到的网络管理报文才能送到上层模块（如EcuM,BswM,ComM,NM等），进而上层才能决定开启通信，报文才能外发到总线。如果收到非网络管理报文，Ecu会唤醒，也可以理解为Ecu被供电（主程序被周期调度），因为不是有效唤醒源，之后Ecu走下电流程。至于Ecu收到非网络管理报文保持Ecu唤醒多久取决于系统需求。 -------------------------------------------------------------------------------- /autosar/Security_HSM_Automobil-Elektronik_201808_PressArticle_EN.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/autosar/Security_HSM_Automobil-Elektronik_201808_PressArticle_EN.pdf -------------------------------------------------------------------------------- /autosar/Vector Davinci官方帮助配置手册（AutoSAR）.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/autosar/Vector Davinci官方帮助配置手册（AutoSAR）.pdf -------------------------------------------------------------------------------- /autosar/rumen/AUTOSAR入门-汽车电子架构演进（一）ECU和域控制器.md: -------------------------------------------------------------------------------- 1 | # AUTOSAR入门-汽车电子架构演进（一）ECU和域控制器 2 | 3 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/KibCRZcaN7AS5ldglcxvUGpgAuI0WrgnR0D4zwic7ktbzYWqy6MuiatNkicBfKwFVaeVAytv5t8ZAk6DKrGvw1KPZw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 4 | 5 | 本次文章不**show me the code**，对一些汽车基础问题进行梳理。首先我们讲的这套AS平台的代码https://github.com/thatway1989/as，实现了**AUTOSAR cp**的功能，但是这套**代码跟汽车**有什么关系？整天AUTOSAR、诊断、CAN什么的，但是不知道在车上怎么用，就像**只听见过猪叫，没见过猪跑**一样。 6 | 7 | 首先AS这个平台**模拟了一个域控制器**，并且上面跑的代码就是AUTOSAR cp的代码。那么什么是域控制器，在汽车软件演进的过程中又扮演了什么角色，AUTOSAR的软件框架又是什么，跟汽车业务又有什么关系？这些将在文中一步一步分析。 8 | 9 | 另外，汽车电子框架演进为三步：**分布式（ECU）-》集中式（域控制器）-》中央式（硬件虚拟化+SOA）**，也将在文中说明。 10 | 11 | 汽车电子构架演进涉及的内容比较多，这里分**三篇**进行介绍。本次文章先介绍**ECU**和**域控制器**。 12 | 13 | # 14 | 15 | # **1. 什么是ECU？** 16 | 17 | **电子电路**相对于**机械**控制的优点在于**精细化**和**自动化**，是**智能化**的基础。 18 | 19 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/KibCRZcaN7AS5ldglcxvUGpgAuI0WrgnRlQvAJTJiaZYeicTHicicKdyKKedoQFx7IvibhvHyicaK9KS3fiayYsgNVQJsg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 20 | 21 | 首先，要精细化的控制，就需要在传统机械设备上**引入电子电路**。1968 年电子设备首次出现在汽车中，当时大众汽车在大众1600轿车的发动机中安装了电子控制单元 (ECU)，以帮助**控制燃油喷射**。 22 | 23 | 24 | 25 | 另外，在当今**智能化**汽车对**控制**要求更加严格，内燃机提供的动力比较奔放，不利于进行细微的控制，而电机，特别是**步进电机**，转动一圈360度可以按角度进行控制，极其精密，这样给**智能驾驶**提供了可能，智能驾驶需要非常细微的控制，复杂难控制的**燃油发动机**是**不具备精细控制**的条件的，不然把人撞死就完了。除却**新能源**，这就是电动车将要取代燃油车一个重要原因。 26 | 27 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/KibCRZcaN7AS5ldglcxvUGpgAuI0WrgnRf0toaXnEcgcu1SxnkurzCuibj9pK9kqibDG3JX2XxTgrzZic3U7Al8p4Q/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 28 | 29 | 上面提到**ECU**（Electronic Control Unit）电子控制器单元，它们的用途就是控制汽车的行驶状态以及实现其各种功能，是一块**独立的电路板**。主要是利用各种传感器、总线的数据采集与交换，来判断车辆状态以及司机的意图并通过执行器来操控汽车。 30 | 31 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/KibCRZcaN7AS5ldglcxvUGpgAuI0WrgnRkUZNib0U8wNHM0UGDziaFvjTzjl0RdaIpCTJ5HUxWnv9aCtntjVZlA4A/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 32 | 33 | 随着汽车智能化的发展，汽车里面ECU逐渐增多，达到了**100+**。这么多ECU，汽车软件这时候的构架是**分布式**的，汽车里的各个ECU都是通过**CAN和LIN**总线连接在一起，如下图： 34 | 35 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/KibCRZcaN7AS5ldglcxvUGpgAuI0WrgnRd2jvlOoJ4cpIhO0v2OdUM0LGT6ZpaWDNAIFfI29jSYErC6sggB5iapQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 36 | 37 | 下面罗列一些主要的ECU： 38 | 39 | EMS（Engine Mangement System）**发动机管理系统**，应用在包括汽油机PFI（如上图）、GDI，柴油机，混合动力系统等，主要控制发动机的喷油、点火、扭矩分配等功能。 40 | 41 | TCU（Transmission Control Unit）**自动变速箱控制单元**，常用于AMT、AT、DCT、CVT等自动变速器中，根据车辆的驾驶状态采用不同的档位策略。 42 | 43 | BCM（Body Control Module）**车身控制模块**，主要控制车身电器，比如整车灯具、雨刮、洗涤、门锁、电动窗、天窗、电动后视镜、遥控等。 44 | 45 | ESP（Electronic Stability Program）**车身电子稳定控制系统**，车身电子稳定控制系统。ESP可以使车辆在各种状况下保持最佳的稳定性，在转向过度或转向不足的情形下效果更加明显。ESP是博世公司的专门叫法，譬如日产的车辆行驶动力学调整系统VDC（Vehicle Dynamic Control ），丰田的车辆稳定控制系统VSC（Vehicle Stability Control ），本田的车辆稳定性控制系统VSA（Vehicle Stability Assist Control），宝马的动态稳定控制系统DSC（Dynamic Stability Control ）等。现如今很多中高端合资车、国产车都会配备这个模块。 46 | 47 | BMS（Battery Management System）**电池管理系统**，顾名思义这个控制器是专门针对配备有动力电池的电动车或者混合动力车准备的。主要功能就是为了能够提高电池的利用率，防止电池出现过度充电和过度放电，延长电池的使用寿命，监控电池的状态。 48 | 49 | VCU（Vehicle Control Unit）**整车控制器**，用于混合动力/纯电动汽车动力系统的总成控制器，负责协调发动机、驱动电机、变速箱、动力电池等各部件的工作，提高新能源汽车的经济性、动力性、安全性并降低排放污染。 50 | 51 | # **2. 什么是域控制器？** 52 | 53 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/KibCRZcaN7AS5ldglcxvUGpgAuI0WrgnRH8nS9z4ic2tP5tRgYklvJGsoicZWiaMAib4jIx7hxeM3ecZvqQGkphO6tg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 54 | 55 | 当出现了这么多ECU，首先从成本上来说，这么多电路板，每个电路板上都有芯片，成本非常的高，并且这么多ECU要连线，**线束的总长度很大**，**成本很高**。这些电路板很多**功能都是一样**的，完全可以**一个电路板**把活干完，但是由于汽车不同零部件的供应商不一样，**很难协调**。另外这些ECU如果需要交互，在一起协调工作就变的很困难，**满足不了智能控制**的需求。 56 | 57 | 为了解决**分布式EEA**（Electrical ElectronicArchitecture电子电气架构）的这些问题，人们开始逐渐把很多功能相似、分离的ECU功能集成整合到一个比ECU性能更强的处理器硬件平台上，这就是汽车“**域控制器****（Domain Control Unit，DCU）**”。域控制器的出现是汽车EE架构从ECU**分布式**EE架构演进到域**集中式**EE架构（**如下图**）的一个重要标志。 58 | 59 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/KibCRZcaN7AS5ldglcxvUGpgAuI0WrgnRphZ8J4SxD0qGxySVBSRjYL1Bg2RiaEZC3FdmhslicaIEpN4fvXK8Q7iaA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 60 | 61 | 域控制器是汽车每一个功能域的核心，它主要由域**主控处理器**、**操作系统**和**应用软件****及算法**等三部分组成。**平台化、高集成度、高性能和良好的兼容性**是域控制器的主要核心设计思想。依托高性能的域主控处理器、丰富的硬件接口资源以及强大的软件功能特性，域控制器能将原本需要很多颗ECU实现的核心功能集成到进来，极大提高系统功能集成度，再加上数据交互的标准化接口，因此能极大降低这部分的开发和制造成本。 62 | 63 | 对于功能域的具体划分，各汽车主机厂家会根据自身的设计理念差异而划分成几个不同的域。比如BOSCH划分为5个域： 64 | 65 | **动力域****（PowerTrain）、** 66 | 67 | **底盘域****（Chassis）、** 68 | 69 | **车身域****（Body/Comfort）、** 70 | 71 | **座舱域****（Cockpit/Infotainment）、** 72 | 73 | **自动驾驶域****（ADAS）**。 74 | 75 | 这也就是最经典的**五域集中式EEA**，如上图所示。也有的厂家则在五域集中式架构基础上进一步融合，把原本的动力域、底盘域和车身域融合为整车控制域，从而形成了**三域集中式EEA**，也即： 76 | 77 | **车控域控制器****（VDC，Vehicle Domain Controller）、** 78 | 79 | **智能驾驶域控制器****（ADC，ADAS\AD Domain Controller）、** 80 | 81 | **智能座舱域控制器****（CDC，Cockpit Domain Controller）**。 82 | 83 | 大众的MEB平台以及华为的CC架构都属于这种三域集中式EEA。 84 | 85 | 86 | 87 | 后记： 88 | 89 | 前面说到域控制器是由**域****主控处理器**、**操作系统**和**应用软件****及算法**等三部分组成，而这三部分正式AUTOSAR软件构架所规范的内容，可以这么说**AUTOSAR规范了域控制器的实现**方式。下节介绍AUTOSAR软件框架。 -------------------------------------------------------------------------------- /autosar/vector_autosar/AUTOSAR开发工具DaVinci Configurator里的Modules.md: -------------------------------------------------------------------------------- 1 | # AUTOSAR开发工具DaVinci Configurator里的Modules 2 | 3 | DaVinci Configurator 里面有个Module这个概念。 4 | 5 | 如你所想，基本上跟AUTOSAR架构里面的Module相对应 6 | 7 | ![1](https://user-images.githubusercontent.com/80186561/188121890-f000fe08-f732-49a3-a987-b12a9f1769e4.png) 8 | 9 | 10 | 从软件的Project菜单中的Basic Editor项可以打开 11 | 12 | ![2](https://user-images.githubusercontent.com/80186561/188121943-cebc8316-681e-4edb-8877-1327b135e3ca.png) 13 | 14 | 15 | 打开这个菜单后，会看到很多Modules项以及其相关配置项 16 | 17 | ![3](https://user-images.githubusercontent.com/80186561/188121988-0f93de68-b5f1-4699-b1d7-2bfcaf43e623.png) 18 | 19 | 20 | 这个Basic Editor显示出整个ECU配置中的所有Module配置项 21 | 22 | 即使是Configuration Editor里面的配置项都能在Basic Editor找到对应的，例如下图的IoHwAb 23 | 24 | ![4](https://user-images.githubusercontent.com/80186561/188122055-66d4513a-ec98-46f9-874b-52b8182cb7d0.png) 25 | 26 | 27 | 对于Basic Editor里面的Module内容，也许你会有几个疑问： 28 | 29 | 1. 为什么Module有几种不同的颜色图标，各代表什么意思？ 30 | 2. Module下面的选项也有不同图标，各又是什么意思？ 31 | 32 | 以下一一讲解。 33 | 34 | 不同颜色Module图标代表的意思： 35 | 36 | | ![1](https://user-images.githubusercontent.com/80186561/188122259-09ac0727-52d1-4332-9c80-94d2e4f18a3e.png) | AUTOSAR module. | 37 | | ------------------------------------------------------------ | ---------------------------------------------------- | 38 | | ![2](https://user-images.githubusercontent.com/80186561/188122397-a4510324-7d39-4a5d-9cb7-8538769ac447.png) | **AUTOSAR driver module.** | 39 | | ![3](https://user-images.githubusercontent.com/80186561/188122447-f24f4316-d153-4a19-9201-55b08002d523.png) | **Non AUTOSAR module.** | 40 | | ![4](https://user-images.githubusercontent.com/80186561/188122488-171a5d71-5e60-48f4-9cab-0250f94a63e5.png) | **Non AUTOSAR driver module.** | 41 | | ![5](https://user-images.githubusercontent.com/80186561/188122527-b9a8a5f8-4f83-4dc4-9da2-5b1d3d24cb8f.png) | **Module without associated BSWMD file in the SIP.** | 42 | 43 | 不同颜色Module图标代表的意思： 44 | 45 | ![image-20220902172839264](https://user-images.githubusercontent.com/80186561/188117935-896c305b-9f88-40dc-bebc-0c64fbfb5fc3.png) 46 | 47 | 48 | 对了，还有个问题，Module是怎么添加进来的？ 49 | 50 | 从Project菜单中的Project Settings界面 51 | 52 | ![5](https://user-images.githubusercontent.com/80186561/188122123-88ce39f0-1626-4c16-8d56-9e0cead2debe.png) 53 | 54 | 55 | 然后点击Modules，在右侧点击**+**或**x**图标来增删Module。 56 | 57 | ![6](https://user-images.githubusercontent.com/80186561/188122177-2531f7fc-cb57-409d-bcdd-8f1f97a7b315.png) 58 | 59 | 60 | 至于你能增加哪些Module，就取决于你的SIP包了。 61 | -------------------------------------------------------------------------------- /autosar/vector_autosar/AUTOSAR折磨，从新建工程开始.md: -------------------------------------------------------------------------------- 1 | # AUTOSAR折磨，从新建工程开始 2 | 3 | 1**使用案例工程** 4 | 5 | 方法1，直接使用案例工程，一般SIP包会有一个创建好的案例工程，在这样的路径YOUR_SIP_DIR/Applications/SipAddon/StartApplication下面 6 | 7 | ![1](https://user-images.githubusercontent.com/80186561/188132803-cab1b33b-aa92-4c45-aead-66da12e77724.png) 8 | 9 | 10 | 直接打开这个*.dpa文件即可看到已经预先做好的工程： 11 | 12 | ![2](https://user-images.githubusercontent.com/80186561/188132856-5fde9d85-03f3-4492-87b1-5ef667d097c7.png) 13 | 14 | 15 | 但是，这个也不是全的，也不一定完全正确，至少MCAL是没有配置好的（MCAL是IC厂商提供的，并不归属SIP包的一部分）。这样就需要你自己去配置你想要的模块，修改里面的错误。 16 | 17 | 18 | 19 | 2**创建空工程** 20 | 21 | 方法2，直接打开SIP包里面的DaVinciConfigurator软件，YOUR_SIP_DIR/DaVinciConfigurator/Core/DaVinciCFG.exe，如下： 22 | 23 | ![3](https://user-images.githubusercontent.com/80186561/188132891-42b18e24-30ff-4341-86bf-98955453108b.png) 24 | 25 | 26 | 根据下面的步骤可以创建一个空工程： 27 | 28 | ![4](https://user-images.githubusercontent.com/80186561/188132923-c7f72dcd-257c-422a-ac5c-d611326512a1.png) 29 | 30 | 31 | 呵呵？工程是要依赖SIP包的，选择你的SIP包，并给工程起一个名字。 32 | 33 | ![5](https://user-images.githubusercontent.com/80186561/188132965-8228eed8-c62a-4404-bfdd-8d11ccc3ff87.png) 34 | 35 | 36 | 以下目录结构就是你创建工程后生成的结构，从下面的名字你可以大概猜测到各个目录的用途。其中这个GenData就是存放配置信息和生成的代码的目录。 37 | 38 | ![6](https://user-images.githubusercontent.com/80186561/188133002-ad8fc6ee-e5a2-4731-a4f7-fbabea49edc7.png) 39 | 40 | 41 | 选择你用的MCU和编译器，我这里以RH850_1587和GreenHills为例。 42 | 43 | ![7](https://user-images.githubusercontent.com/80186561/188133088-b9947b9a-0f0e-4b68-9227-cc7df213ded3.png) 44 | 45 | 46 | 好了，不骗你，创建的空工程，真的是空的。 47 | 48 | ![8](https://user-images.githubusercontent.com/80186561/188133203-7f3b4df2-799a-4ba7-b95d-077e2d6e2979.png) 49 | ![9](https://user-images.githubusercontent.com/80186561/188133340-8385fbe8-9ec3-4a51-9b73-ea50f489dc85.png) 50 | 51 | 那么，怎么添加模块呢？打开Project，选Project Settings 52 | 53 | ![10](https://user-images.githubusercontent.com/80186561/188133754-a127e7b3-fe17-43c4-a7ec-bbfa9cf47fec.png) 54 | 55 | 56 | 这样，你可以看到个Modules，然后点击右边的“+”号，Add你所需的模块。 57 | 58 | ![11](https://user-images.githubusercontent.com/80186561/188134769-5da27e15-d102-4aad-a280-4db67ba7a791.png) 59 | 60 | 61 | 到这一步，它会问你，所要添加的模块从哪里来？当然SIP啊！ 62 | 63 | ![12](https://user-images.githubusercontent.com/80186561/188135096-bd8c992c-6124-4ce7-823c-94e05bcc9e35.png) 64 | 65 | 然后，勾选你SIP包里面所包含的模块吧，如果没有你想要的，有可能是你的SIP包里面没有（没购买），或者是非AUTOSAR标准模块。 66 | 67 | ![13](https://user-images.githubusercontent.com/80186561/188135309-524696c4-93c4-4f8b-ba3e-76a9ed67bcdb.png) 68 | 69 | ![14](https://user-images.githubusercontent.com/80186561/188135578-2df57afb-dcfd-4f68-819c-c396d818be00.png) 70 | 71 | ![15](https://user-images.githubusercontent.com/80186561/188135795-901bc1aa-8d14-417f-8e1e-b9c8fb308523.png) 72 | 73 | 添加好后，就长这样子了。 74 | 75 | 其中，左边的是按类组合分的，右边就是原始添加的一个个模块的模样（界面叫Basic Editor） 76 | 77 | ![16](https://user-images.githubusercontent.com/80186561/188137801-271668c4-d844-4874-bb45-0797507eb3a0.png) 78 | 79 | 80 | 问题来了，添加后的模块在Configurator自动检查后会提示你有很多错误。 81 | 82 | 然后，下面这个界面对于大部分错误都有提示或修改建议，有些可以双击一下会自动修复。文章篇幅有限，这里没办法写下所有的错误解决方法，后续有机会再针对具体的问题写分享吧。 83 | 84 | 如果解决不了的，只能靠经验或者请教有经验的人了。 85 | 86 | ![17](https://user-images.githubusercontent.com/80186561/188138120-ef558761-9e76-43ad-95ee-2119d7bd8197.png) 87 | 88 | 当你解决完上面的错误，你可以点击检查和生成代码。 89 | 90 | ![18](https://user-images.githubusercontent.com/80186561/188138225-9271aa5c-0e16-49be-a757-6cf4d72c993d.png) 91 | 92 | 93 | 选择你要检查或生成的模块 94 | 95 | ![19](https://user-images.githubusercontent.com/80186561/188138277-74e043a6-323b-45db-9107-e05014b04c7c.png) 96 | 97 | -------------------------------------------------------------------------------- /autosar/vector_autosar/AUTOSAR架构的 Pdu Router.md: -------------------------------------------------------------------------------- 1 | # AUTOSAR架构的 Pdu Router 2 | 3 | 前言： 4 | 5 | 6 | 7 | PDU Router（路由器）在本文将简称为PduR，考虑到个人对PduR模块认识深度有限，且接触的CAN通讯功能运用PduR模块功能也较简单，所以本文仅对PduR模块做简单介绍。 8 | 9 | ## 10 | 11 | ## *1* **基本概念** 12 | 13 | 首先了解下**路由**的概念，**路由是指路由器从一个接口上收到数据包，根据数据包的目的地址进行定向并转发到另一个接口的过程**（引自百度百科）。 14 | 15 | 接着了解下PduR更多的作用，引自[1]：PduR模块提供路由I-PDU（Interaction Layer Protocol Data Units）服务，使用在通讯接口模块（比如CanIf，CanNM，FrIf）和传输协议模块（比如CanTp，COM和DCM），如下图1所示。常用的PDU路由使用模块有：与UDS服务相关的AUTOSAR 诊断通讯管理模块（Diagnostic Communication Manager,DCM）和传输协议模块，与CAN通讯相关的AUTOSAR COM，通讯协议模块等。 16 | 17 | ![图片](https://mmbiz.qpic.cn/mmbiz_jpg/6PYxCJZfNqfRkmhGovkInXP5Xr6mIiaJnribN4RRy1Vv9Ufic7IZZb6Yib9yuOsoeEAcjDcujEAZKjnV7HjKCF4dDQ/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1) 18 | 19 | 图1 AUTOSAR架构下的PduR模块，引自[1] 20 | 21 | PduR主要由2部分组成： 22 | 23 | - PduR路由表：静态路由表描述每个被路由的I-PDU的路由属性；I-PDU路由的执行是基于静态定义的I-PDU ID。 24 | - PduR引擎：根据PduR路由表执行路由动作的实际代码，该引擎不得不路由I-PDU从源头到目的地，以及根据I-PDU ID的源头翻译其目的地。 25 | 26 | ![图片](https://mmbiz.qpic.cn/mmbiz_jpg/6PYxCJZfNqfRkmhGovkInXP5Xr6mIiaJn20IQvXm8v2HubibPEztBgnib76FZVDicRXZp2rLPVYRoPA5icPZ1xFJd1A/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1) 27 | 28 | 图2 PduR模块的组成，引自[1] 29 | 30 | 通过以上知识对应到CAN通讯，**就是PduR模块从CAN接口模块/COM模块接收到了PDU，然后根据PDU ID查找已定义好的静态路由表，获得其目标地址，定向并转发到COM模块/CAN接口模块，即路由PDU，故称为PDU Router。** 31 | 32 | ## *2* **发送与接收操作** 33 | 34 | 从CAN通讯的发送与接收来看，再来理解下PduR模块的作用，即： 35 | 36 | - 发送时，PduR模块将来自COM模块的发送请求路由到Can接口模块，将来自Can接口模块的确认路由到COM模块，如下图3。 37 | - 接收时，PduR模块将来自Can接口模块的通知路由到COM模块，如下图4。 38 | 39 | ![图片](https://mmbiz.qpic.cn/mmbiz_jpg/6PYxCJZfNqfRkmhGovkInXP5Xr6mIiaJnxOgSicc50icuQv76qiavAWKXmdx13DZ3ZjqoE0ibvxQeHo7lC3SU33j5MQ/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1) 40 | 41 | 图3 42 | 43 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/6PYxCJZfNqfRkmhGovkInXP5Xr6mIiaJnR8Uu50qjdL3n1g8CynfEpNIfNwbEonJhmRORcZ3UicPtf04AqCe0CjA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 44 | 45 | 图4 46 | 47 | 下面借助文档了解下上述函数的定义，发送请求函数如下图5所示： 48 | 49 | ![图片](https://mmbiz.qpic.cn/mmbiz_jpg/6PYxCJZfNqfRkmhGovkInXP5Xr6mIiaJnXOexwgkC4CVc0Nib0VZmN7yGB3M97hRbaGFbxbkwkdluMfibbJFu65XQ/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1) 50 | 51 | 图5 发送请求函数，引自[1} 52 | 53 | 注意User:Up与当前的功能有关，CAN通讯的话，User:Up为Com，即发送时，COM模块调用PduR_ComTransmit函数。当然作为PduR模块的函数，会根据不同功能路由到其他模块，自然需要采用这种定义方式。同样地发送确认函数和接收通知函数也一样。 54 | 55 | ![图片](https://mmbiz.qpic.cn/mmbiz_jpg/6PYxCJZfNqfRkmhGovkInXP5Xr6mIiaJn4Qty8GROZxlluEQcXsxvUMiapYXfZ5RcVQSJ2sLRHhSwt6h2bGTojIQ/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1) 56 | 57 | 引自[1] 58 | 59 | 发送确认函数的定义如下图6，其中User：Lo的定义如下表，发送时，Can接口模块调用PduR_CanIfTxConformation函数向上确认。 60 | 61 | ![图片](https://mmbiz.qpic.cn/mmbiz_jpg/6PYxCJZfNqfRkmhGovkInXP5Xr6mIiaJnVGsvQf8GvtA4vheFhCibZIJmtXF35tWnwrbky9bTJFaT0x6243y9fRQ/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1) 62 | 63 | 图6 发送确认函数，引自[1] 64 | 65 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/6PYxCJZfNqfRkmhGovkInXP5Xr6mIiaJn2ts6aJKobrQRWQankgkmC4H34AuhhdcDicD0KQfg7xCCjuibaoe28u3w/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 66 | 67 | 接收通知函数的定义如下图7，其中User：Lo的定义如上表，即Can接口模块调用PduR_CanIfRxIndication函数。在此就发现图4用PduR_RxIndication函数就不够准确咯。 68 | 69 | ![图片](https://mmbiz.qpic.cn/mmbiz_jpg/6PYxCJZfNqfRkmhGovkInXP5Xr6mIiaJnVzNCbUVWdQ4EGjZBs7NMrqhsXgYGFS3sQabsWqmNaPebR2ibHRhUAibQ/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1) 70 | 71 | 图7 接收通知函数，引自[1] 72 | 73 | ## *3* 74 | 75 | ## **路由表** 76 | 77 | 目前觉得PduR模块最关键还是路由表的定义，一是路由路径的确定，二是由源头ID到目的地ID的确定。特此再引用两例说明，如下图8、9。 78 | 79 | ![图片](https://mmbiz.qpic.cn/mmbiz_jpg/6PYxCJZfNqfRkmhGovkInXP5Xr6mIiaJnfCiaUOFyOSrvgIoO2tbOSicVgGN8oWrLxe0dyUsDUo4zGibSQ343QianvA/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1) 80 | 81 | 图8 接收通知路由，引自[2] 82 | 83 | ![图片](https://mmbiz.qpic.cn/mmbiz_jpg/6PYxCJZfNqfRkmhGovkInXP5Xr6mIiaJn2oRIDUmTyo7iaRcOzxQHvTpXIicibstk7qenR7s7QSJSUdwjDjr3Scabw/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1) 84 | 85 | 图9 发送请求路由，引自[2] 86 | 87 | ------ 88 | 89 | 以上就是简单介绍了PduR模块在CAN通讯的发送与接收所起的作用，当向上进入COM层后，简单地说就是：接收时，将PDU解包成一个一个的信号，供ASW使用；发送时，将一个一个的信号打包成PDU，向下发送。那么具体怎么实现？请看下篇文章。 -------------------------------------------------------------------------------- /autosar/vector_autosar/Autosar概念：Callout与Callback，请不要混肴.md: -------------------------------------------------------------------------------- 1 | # Autosar概念：Callout与Callback，请不要混肴 2 | 3 | 本文讨论焦点是Callout与Callback，在Autosar里面，Callout与Callback分别是什么？两者区别是什么？搞Autosar这些年了，你分清楚了没？ 4 | 5 | 1 6 | 7 | Callback 8 | 9 | 来，先看一下，Autosar规范里是如何定义“Callback”的，如下所示： 10 | 11 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vy8uOnSVqfz28p2lUE2X9aG1KFfRQq0n6FN3Fpo0wWqBZicKQHxJuFYNEpxs38KV9a1ibDfw2W514Pg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 12 | 13 | 这里就不照着翻译了，来说一下个人理解。Autosar的软件架构将各个模块进行了分层，每个模块各司其职，但又需要信息交互。信息交互的过程中，底层需要为上层提供服务，上层也需要时时知道自己请求服务的状态（是否执行成功），比如：有应用层消息来了，路由模块（如：PDUR）将该消息路由给COM层。但是这个消息怎么给COM呢？对，就是上图说的，COM需要在PDUR提前注册一个函数，当有消息给COM的时候，PDUR直接调用对应接口通知到COM即可，而COM不必一直等待。 14 | 15 | 这里说的消息就是上图中发生的特定事件（Certain Events）或者异步处理完成事件（asynchronous processing completes）。 16 | 17 | ## Com_RxIndication 18 | 19 | 以Com_RxIndication 为例，如下所示： 20 | 21 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vy8uOnSVqfz28p2lUE2X9aGnMZfuhO91icrSdg47Ok6ydjJTicVDouR2tKjcCv6IeeO3Nm7NHXiav3XQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 22 | 23 | 也就是说，当PDUR接收到一个I-PDU（xxIf模块传给PDUR），且该I-PDU需要送给COM时，PDUR需要调用COM提前在PDUR注册好的接口：Com_RxIndication。 24 | 25 | Com_RxIndication接口有什么特点呢？**它是Autosar标准接口**。在Autosar规范中，其函数原型有详细说明，如上图。 26 | 27 | 在Autosar中，Callback会有独立的章节讨论，比如COM层，其Callback接口如下所示，大家在看Autosar规范时可以留意一下。 28 | 29 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vy8uOnSVqfz28p2lUE2X9aGczmGPezGjG960WlMJnJTciakr1mMQCqVfNyibPzoonDTSfX9ZdOJNXjA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 30 | 31 | 32 | 33 | ## Callback的百度词条解释 34 | 35 | 百度词条中给出的callback解释如下所示： 36 | 37 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vzPvthbrfEqtIfbqTcWUNIStClqSq0kUschuURmv2ZWyCvcqWkwlic2OqW4POmuVjQeZK7LGgC9sqQ/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 38 | 39 | Callback在项目的开发中，使用还是很频繁的。这里谈论一下自己开发中的使用经验。Callback的地址经常会当作一个函数形参，我常常用其作为一个功能模块的“后门”，为什么这样做呢？做项目开发中，有些框架或者模块成熟了以后，后期的开发一般会移植、复用。但是当新的项目有额外功能要求时，又不想推倒原有的框架重来，那么通过预留的Callback实现，就方便了很多，而且不用修改框架。 40 | 41 | **模块中Callback的使用示例**： 42 | 43 | ``` 44 | typedef void* (*callBack_Pre)(void* argu1, void* argu2); 45 | typedef void* (*callBack_Post)(void* argu1); 46 | 47 | typedef struct{ 48 | int Module_A_arg; 49 | callBack_Pre Module_A_CallbackPre; 50 | callBack_Post Module_A_CallbackPost; 51 | }Module_A_Type; 52 | 53 | Module_A_Type Module_A_Obj; 54 | 55 | void Module_A_Handler(Module_A_Type* Module_A_Obj_Info) 56 | { 57 | /* Module A Pre Handle */ 58 | if(Module_A_Obj_Info->Module_A_CallbackPre != nullptr) 59 | { 60 | Module_A_Obj_Info->Module_A_CallbackPre(nullptr, nullptr); 61 | } 62 | /* Module A Post Handle */ 63 | if(Module_A_Obj_Info->Module_A_CallbackPost != nullptr) 64 | { 65 | Module_A_Obj_Info->Module_A_CallbackPost(nullptr, nullptr); 66 | } 67 | }typedef void* (*callBack_Pre)(void* argu1, void* argu2); 68 | typedef void* (*callBack_Post)(void* argu1); 69 | 70 | typedef struct{ 71 | int Module_A_arg; 72 | callBack_Pre Module_A_CallbackPre; 73 | callBack_Post Module_A_CallbackPost; 74 | }Module_A_Type; 75 | 76 | Module_A_Type Module_A_Obj; 77 | 78 | void Module_A_Handler(Module_A_Type* Module_A_Obj_Info) 79 | { 80 | /* Module A Pre Handle */ 81 | if(Module_A_Obj_Info->Module_A_CallbackPre != nullptr) 82 | { 83 | Module_A_Obj_Info->Module_A_CallbackPre(nullptr, nullptr); 84 | } 85 | /* Module A Post Handle */ 86 | if(Module_A_Obj_Info->Module_A_CallbackPost != nullptr) 87 | { 88 | Module_A_Obj_Info->Module_A_CallbackPost(nullptr, nullptr); 89 | } 90 | } 91 | ``` 92 | 93 | **说明：** 94 | 95 | 如上，需要开发一个Module A模块，实现某个功能需求，一般我会先定义这个模块所需的信息**对象**，即定义一个**结构体**Module_A_Type，该结构体里面会包含两个函数指针，一个是Module A处理信息前的Action，一个是Module A处理信息后的Action。 96 | 97 | 需要添加特定功能时，可以根据实际情况，决定在Module A处理信息之前添加还是处理信息之后添加。 98 | 99 | 2 100 | 101 | Callout 102 | 103 | Autosar规范对Callout的具体定义如下所示： 104 | 105 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vy8uOnSVqfz28p2lUE2X9aG5TsTQYMGc3suibcBpMjRyqqXMqR7ibetxiar6dRrEpVxYyeUaBHdLXaPg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 106 | 107 | 简单说：**拓展Autosar功能的函数叫Callout**，但Autosar并没有明确Callout的形式。 108 | 109 | ## 为什么要用Callout 110 | 111 | 为什么要用Callout呢？我们应该知道，实际工程项目中，需求是多变的，在一个项目的工程周期内，OEM可能会增加N次的需求修改，有些需求按照Autosar是没法实现的，说白了，配置工具是配不出来定制需求的。怎么办？给系统说做不了？项目不做了？别急，万事有办法。制定Autosar的这帮家伙，都是人精一样的存在，他们怎么会没有想到呢。所以，在Autosar的框架里，很多模块都给你提供了Callout的配置项，如下，给出部分含有Callout选项的模块。 112 | 113 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vy8uOnSVqfz28p2lUE2X9aG03bQm8NibhNHgpdfyQ3h3rbibibObiadTAHyPXAH04DLA1WntFH6qJyQuw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 114 | 115 | ## Callout Class1/Class2 116 | 117 | 在Autosar中，Callout又分为Class1和Class2两个层级。 118 | 119 | Class1：强制的，开发者没得选，必须结合项目实际完成此部分的功能实现； 120 | 121 | Class2：可选则，开发者根据项目情况决定是否需要拓展此功能。 122 | 123 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/eEEQvxEw8vy8uOnSVqfz28p2lUE2X9aGKTUF6BqYc4ickf9B63Js5YyeXib7zt3ricwerV19R2xyb4eNE4VSBE2nw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 124 | 125 | 如上图，“Opt”栏，“no”表示此Callout必须实现，比如：获取复位原因，ECU每次复位时，会从对应寄存器或者读取目标IO口读取复位原因通知上层。该功能必须要有，但是每个项目复位的触发方式和数量不同，因此Autosar留给开发者实现。“yes”表示此Callout可选，可以实现，也可以不实现。 126 | 127 | Callout特点：**针对指定模块**。Callout不像Callback那样，可以跨模块。Callout是本模块功能的拓展，或者说某个函数功能的拓展，而Callback即可以是上下层模块信息交互的标准接口，也可以是本模块中，某个函数的形参。 128 | 129 | **参考资料** 130 | 131 | AUTOSAR_TR_Glossary.pdf 132 | 133 | AUTOSAR_SWS_COM.pdf 134 | 135 | AUTOSAR_SWS_ECUStateManager.pdf 136 | 137 | https://baike.baidu.com/item/CALLBACK -------------------------------------------------------------------------------- /autosar/vector_autosar/[Classic AUTOSAR学习] SecOC通信安全模块（入门篇）.md: -------------------------------------------------------------------------------- 1 | # [Classic AUTOSAR学习] SecOC通信安全模块（入门篇） 2 | 3 | ## 简介 4 | 5 | SecOC模块的目的是在PDU的级别，针对关键数据作资源高效且可行的验证机制，保证数据安全，这种安全机制可以无缝集成到AUTOSAR项目当中。 6 | 7 | SecOC既可以支持对称加密方式，也能支持非对称加密方式，AUTOSAR规范主要基于对称加密方式进行说明。在对称加密过程当中，消息认证码（MAC）是关键，它能以更小长度的密钥以及实现的便利程度，达到非对称加密同样的安全等级。 8 | 9 | 对于既有项目来说，这样的方式也充分考虑了过去的系统当中所能提供的有限资源，尽量将资源消耗程度降到最低。 10 | 11 | ![图片](https://mmbiz.qpic.cn/mmbiz_jpg/ITL4l9Iicic4AbTTSpy7PWn317Pelcp1NwepTXA1h7OhTG1s0JJK0b934b0QxNHR0tzeEeibCTGVXAd3xSpbpAAcw/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1) 12 | 13 | SecOC既作为PduR模块的上层模块，也是PduR的下层模块，在数据流的收发双向中做数据的加密与解密。以Can总线上的接收为例，CanIf将接收到的加密信息传给PduR，PduR交给SecOC，SecOC利用CSM的服务和RTE之上的Key management和Counter management进行解密，然后SecOC再将解密后的数据给到PduR，PduR继续路由给对应的模块。 14 | 15 | ![图片](https://mmbiz.qpic.cn/mmbiz_jpg/ITL4l9Iicic4AbTTSpy7PWn317Pelcp1NwrgvMk0xecRPvoq7B0eV288fpQ46KnSA1qx1mEb18wfsqUygPhEfAkA/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1) 16 | 17 | 所以，很显然地，SecOC和底层通信协议无关。 18 | 19 | ## AUTOSAR中的安全解决方案 20 | 21 | 确保接收到的数据从正确的ECU发送而来，并且是正确的数据，对于车辆功能系统完成正确且安全的操作，是非常重要的。在这里，涉及到**认证（Authentication）**及**完整性（Integrity）**两个概念。 22 | 23 | SecOC模块提供了必要的功能，来验证车内ECU通信的PDU的真实性（authenticity）和新鲜度（freshness）。 24 | 25 | 在发送方，SecOC为IPdu加上验证信息，组成了Secured IPdu。验证信息包括验证器Authenticator（例如消息验证码，下称MAC）以及可选的新鲜值字段。当使用了新鲜值，而不是时间戳的情况下，新鲜值计数器应当在生成验证信息前，由新鲜值管理器不停地自加并提供这个值。 26 | 27 | 基于同样验证方法以及新鲜值管理器（下称FvM）的接收方，SecOC模块负责检查Authentic IPdu的新鲜值以及验证码。 28 | 29 | ![图片](https://mmbiz.qpic.cn/mmbiz_jpg/ITL4l9Iicic4AbTTSpy7PWn317Pelcp1Nwq0w8dgc6TfsRZjtFaQKn7VSPohiaI9H98dw7uzz1Cjb2v3RVZuNxIMQ/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1) 30 | 31 | 一般地，在使用对称加密时，我们使用术语MAC，在使用非对称加密时，我们使用术语签名（signature）或者电子签名（digital signature）。 32 | 33 | ## Authentic I-Pdu和Secured I-Pdu 34 | 35 | Secured IPdu的payload包括Authentic IPdu以及MAC值，也可以包含新鲜值（可选），并且这个新鲜值会被用来作为计算MAC值的一部分。 36 | 37 | ![图片](https://mmbiz.qpic.cn/mmbiz_jpg/ITL4l9Iicic4AbTTSpy7PWn317Pelcp1NwIIWeKvvd53icickUpibqgCvL0jv3SxDiczuMKNR2ejZAhAK6L6MY8gCeTQ/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1) 38 | 39 | 对于不同的Authentic IPdu，新鲜值和MAC值可以设置为不同的长度。 40 | 41 | MAC值由密钥，Secured IPdu的数据ID，payload（Authentic IPdu）以及新鲜值作为输入并计算而得，具有唯一性，足以在收发双方进行安全的通信。 42 | 43 | 由于可能会出现数据长度有限，无法将MAC值每一位都放在消息中进行发送的情况，SecOC模块也可以设置截断值，将MAC值截取一部分放在payload当中。不同的Secured IPdu都可以设置不同的截断值。 44 | 45 | 对于MAC值，应当截取高位数据，而对于新鲜值，截取的是低位数据。 46 | 47 | 截取位长度该怎么选，这是个问题。从规范上的说明来看，理想状态下，最好是有至少128bit长度的MAC值，不过，一般情形下，64bit以上也能覆盖大多数场景，不会被攻破。当然，具体怎么截取，需要由项目的信息安全负责人来确定。 48 | 49 | ![图片](https://mmbiz.qpic.cn/mmbiz_jpg/ITL4l9Iicic4AbTTSpy7PWn317Pelcp1NwHCQiajffoFWEqZnpPlIKrHPXrj3aAAthR2icDc1iaMia6WjTBLedrYbF3w/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1) 50 | 51 | 无论是新鲜值，MAC还是Data ID等，SecOC模块都是基于大端模式来处理数据。 52 | 53 | ### 用来计算验证码的数据 54 | 55 | 上文已经提及到，这些数据会被用来计算验证码：Data ID，（被保护的）Authentic IPdu数据，完整的新鲜值。 56 | 57 | ### 新鲜值 58 | 59 | 每一个Secured IPdu都可以配置至少一个新鲜值，新鲜值用来保证Secured IPdu的新鲜程度。新鲜值需要有新鲜值管理器作为一个SWC来提供，既可以是消息计数器，也可以是时间戳。 60 | 61 | 如果想要配置截取值，可以配置SecOCFreshnessValueTruncLength，如果此项配置为0，那么新鲜值将不会被包含在Secured IPdu内。 62 | 63 | ![图片](https://mmbiz.qpic.cn/mmbiz_jpg/ITL4l9Iicic4AbTTSpy7PWn317Pelcp1NwkdSnl0JeRK9EoyxhhGXibx3PlGrCKKBC9TR07KNWjcboqH5P1IhlM4A/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1) 64 | 65 | 在降低总线负载，进行新鲜值截取的同时，又不希望新鲜值重复导致丢弃本应该接收的消息，我们还可以来利用SecOCUseAuthDataFreshness选项，让Authentic IPdu的部分内容作为新鲜值的一部分。我们可以设置对应起始位(bit)以及长度(bit)----比如Authentic IPdu中有4bit的E2E Counter---作为新鲜值的一部分，这样就可以不用对原有的新鲜值做扩展。 66 | 67 | ![图片](https://mmbiz.qpic.cn/mmbiz_jpg/ITL4l9Iicic4AbTTSpy7PWn317Pelcp1NwVgyBW9wKjiceu3kvochv27Eoha4ERgofbb6DgzQ0eaq48BbluO1asMQ/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1) 68 | 69 | 如果设置SecOCAuthDataFreshnessStartPosition为11，SecOCAuthDataFreshnessLen为4，假设收到的PDU数据为0xABCD，那么它的**Authentic Data新鲜值**为0xD。 70 | 71 | ![图片](https://mmbiz.qpic.cn/mmbiz_png/ITL4l9Iicic4AbTTSpy7PWn317Pelcp1NwjTYY2BDtV4F73jqoNzYlYlPoj8Q4Ad0C4G2EbYY5bLfOAje4xibN4KA/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1) 72 | 73 | 获取新鲜值有两种方案，一种是经由RTE，通过FvM SWC的FreshnessManagement_GetTxFreshness()来获取，另一种是直接调用C API接口SecOC_GetTxFreshness()： 74 | 75 | ![图片](https://mmbiz.qpic.cn/mmbiz_jpg/ITL4l9Iicic4AbTTSpy7PWn317Pelcp1NwfFSvLWhcddLKEAIBy9m8yxribmsXxCSvAnXY13s45rSwmxErVaHN6hg/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1) 76 | 77 | ## Secured IPdu的创建 78 | 79 | 创建一个Secured IPdu分为以下六步： 80 | 81 | - 准备Secured IPdu，分配所需buffer 82 | - 获取待构建数据，也即Data ID，Authentic IPdu还有新鲜值 83 | - 生成验证码 84 | - 构建Secured IPdu 85 | - 增加新鲜值 86 | - 发送Secured IPdu 87 | 88 | ## IPdu的验证 89 | 90 | Secured IPdu的验证也分为六步： 91 | 92 | - 解析Authentic IPdu，新鲜值和验证码 93 | - 从新鲜值管理器获取新鲜值 94 | - 获取待验证数据 95 | - 检查验证信息 96 | - 给新鲜值管理器发送确认 97 | - 将Authentic IPdu传给上层 98 | 99 | ![图片](https://mmbiz.qpic.cn/mmbiz_jpg/ITL4l9Iicic4AbTTSpy7PWn317Pelcp1Nwbw0ERZTZAzoIROibmUJVFslgMJLAalSYV0AGV9iajKw8A4zuqRuRp1WA/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1)MAC验证 100 | 101 | ![图片](https://mmbiz.qpic.cn/mmbiz_jpg/ITL4l9Iicic4AbTTSpy7PWn317Pelcp1NwLNDo38vXCIXyibpXgXnUfwbQIY114iaeUScbwQ3M5NydTCr7WZcrsUjw/640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1&wx_co=1)新鲜值验证 102 | 103 | 根据配置的不同，验证结果可以通过Verification Status Callout API接口或者服务接口SecOC_VerificationStatusIndication通知出去。 104 | 105 | ## 如果是非对称加密呢？ 106 | 107 | 在使用非对称加密的场景当中，密钥分为私钥和公钥。发送方使用私钥生成签名，接收方使用公钥来验证接收到的数据。接收方无法拥有私钥，也无法通过公钥获取私钥。 108 | 109 | 在验证阶段，接收方需要完整的签名信息，因此之前提及的MAC截取，在这种场景下是不能使用的。 110 | 111 | 另外，对称加密通信时，接收方的SecOC会请求重新计算MAC值并与接收到的MAC值作比较；而对于非对称加密时，所有数据作为输入给到验证器，通过一个布尔结果值知晓验证结果。 112 | 113 | -------------------------------------------------------------------------------- /canoe/CANape_CASL_Manual_EN.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/canoe/CANape_CASL_Manual_EN.pdf -------------------------------------------------------------------------------- /canoe/VN5000_Manual_EN.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/canoe/VN5000_Manual_EN.pdf -------------------------------------------------------------------------------- /doip/4. AVB TSN协议介绍.pdf4. AVB TSN协议介绍.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/doip/4. AVB TSN协议介绍.pdf4. AVB TSN协议介绍.pdf -------------------------------------------------------------------------------- /doip/AN-IND-1-026_DoIP_in_CANoe.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/doip/AN-IND-1-026_DoIP_in_CANoe.pdf -------------------------------------------------------------------------------- /doip/AUTOSAR_SWS_DiagnosticOverIP.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/doip/AUTOSAR_SWS_DiagnosticOverIP.pdf -------------------------------------------------------------------------------- /doip/DoIP_faltblatt_softing.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/doip/DoIP_faltblatt_softing.pdf -------------------------------------------------------------------------------- /doip/DoIP协议介绍.pdfDoIP协议介绍.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/doip/DoIP协议介绍.pdfDoIP协议介绍.pdf -------------------------------------------------------------------------------- /doip/SOA在汽车上怎么用-外发版.pdfSOA在汽车上怎么用-外发版.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/doip/SOA在汽车上怎么用-外发版.pdfSOA在汽车上怎么用-外发版.pdf -------------------------------------------------------------------------------- /doip/SOME IP协议介绍.pdfSOME IP协议介绍.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/doip/SOME IP协议介绍.pdfSOME IP协议介绍.pdf -------------------------------------------------------------------------------- /doip/车载TSN设计与实践.pdf车载TSN设计与实践.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/doip/车载TSN设计与实践.pdf车载TSN设计与实践.pdf -------------------------------------------------------------------------------- /doip/车载以太网DoIP协议介绍.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/doip/车载以太网DoIP协议介绍.pdf -------------------------------------------------------------------------------- /doip/车载诊断标准ISO+13400-3中文.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/doip/车载诊断标准ISO+13400-3中文.pdf -------------------------------------------------------------------------------- /misra-c/MISRA C_2012 Guidelines for the use of the C language in critical systems.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/misra-c/MISRA C_2012 Guidelines for the use of the C language in critical systems.pdf -------------------------------------------------------------------------------- /misra-c/MISRA C_2012浅析_恒润.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/misra-c/MISRA C_2012浅析_恒润.pdf -------------------------------------------------------------------------------- /misra-c/MISRA Compliance 2020.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/misra-c/MISRA Compliance 2020.pdf -------------------------------------------------------------------------------- /misra-c/MISRA_C_2004中文版.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/misra-c/MISRA_C_2004中文版.pdf -------------------------------------------------------------------------------- /misra-c/MISRA_C_2004英文版.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/misra-c/MISRA_C_2004英文版.pdf -------------------------------------------------------------------------------- /中华人民共和国国家标准_道路车辆 统一诊断服务(UDS).pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lixin0824/ADAS/83e91af4fd3f5d3c17004080fcf11253338e8462/中华人民共和国国家标准_道路车辆 统一诊断服务(UDS).pdf --------------------------------------------------------------------------------