本书是一本面向车载网络管理技术的实践指南，核心内容围绕FlexRay、CAN/CAN FD、LIN三大总线技术的硬件设计、协议实现与工程应用展开。全书采用“硬件基础→协议层→网络管理→安全机制→测试实践”的递进结构，系统覆盖从物理层收发器到应用层AUTOSAR标准化的完整技术栈。
本书技术体系架构涵盖物理层（收发器选型、信号转换机制）、协议层（帧格式、错误处理、唤醒逻辑）、网络管理层（OSEK/CP AUTOSAR状态机、局部网络技术）、安全机制（SecOC认证、Freshness Value防重放）、容错与测试（Bus-Off机制、VH6501测试工具）。特别强调AUTOSAR标准下的模块化设计（如FrNm、CAN NM、ComM等模块），以及节点唤醒同步、功耗管理、异常恢复等实际工程问题的解决方案。
本书读者对象包括车载嵌入式系统工程师、汽车电子开发工程师、AUTOSAR架构师、网络协议测试工程师等；此外，相关专业的院校师生也可将本书作为学习研究车载网络管理的参考读物。

前言
第1章　车载控制器网络管理构成1
1.1　收发器（Transceiver）1
1.1.1　FlexRay收发器2
1.1.2　FlexRay收发器唤醒方式9
1.1.3　CAN/CAN FD收发器11
1.1.4　CAN/CAN FD收发器唤醒方式21
1.1.5　收发器信号转换原理24
1.1.6　两帧CAN报文唤醒网络原理26
1.1.7　LIN收发器28
1.2　控制器（Communication Controller）36
1.2.1　FlexRay控制器36
1.2.2　CAN/CAN FD控制器55
1.2.3　LIN控制器60
1.3　本章小结61
第2章　FlexRay、CAN/CAN FD、LIN物理层63
2.1　FlexRay总线协议63
2.1.1　FlexRay帧格式63
2.1.2　FlexRay编码与解码67
2.2　CAN/CAN FD总线协议85
2.2.1　CAN/CAN FD帧类型和格式85
2.2.2　LLC（Logic Link Control）94
2.2.3　MAC（Media Access Control）95
2.2.4　CAN/CAN FD编码与解码96
2.2.5　CAN报文优先级109
2.2.6　CAN FD的延时补偿机制（TDC）109
2.3　LIN总线协议112
2.3.1　LIN帧结构组成113
2.3.2　LIN编码与解码116
2.3.3　LIN总线调度机制125
2.4　唤醒源类型131
2.4.1　本地唤醒131
2.4.2　远程唤醒131
2.5　本章小结132
第3章　网络管理分类133
3.1　OSEK网络管理133
3.1.1　OSEK直接网络管理134
3.1.2　OSEK间接网络管理134
3.1.3　OSEK NMPDU结构134
3.1.4　OSEK NM的寻址机制137
3.1.5　逻辑环的建立139
3.1.6　网络休眠140
3.1.7　错误状态处理142
3.2　CP AUTOSAR网络管理144
3.3　Bootloader与网络管理145
3.3.1　Bootloader唤醒源146
3.3.2　Bootloader的网络唤醒逻辑 147
3.3.3　Bootloader的休眠逻辑148
3.4　本章小结149
第4章　FlexRay网络管理150
4.1　CP AUTOSAR网络管理150
4.1.1　协调算法机制151
4.1.2　CP AUTOSAR中的FlexRay状态机152
4.1.3　CP AUTOSAR中的FlexRay NM-PDU格式158
4.2　本章小结163
第5章　CAN/CAN FD网络管理164
5.1　CP AUTOSAR CAN NM网络管理164
5.1.1　CP AUTOSAR中的CAN NM网络管理报文格式164
5.1.2　CP AUTOSAR中CAN NM的网络状态机172
5.1.3　Bus Load Reduction机制181
5.1.4　CAN/CAN FD诊断报文能否唤醒网络183
5.2　本章小结183
第6章　LIN网络管理184
6.1　LIN网络管理唤醒原理184
6.1.1　从节点通信状态机184
6.1.2　唤醒机制185
6.1.3　LIN网络的休眠（Go to Sleep）机制186
6.2　本章小结187
第7章　AUTOSAR SecOC188
7.1　SecOC出现背景及概念188
7.1.1　SecOC功能描述188
7.1.2　SecOC通信描述189
7.1.3　SecOC通信相关基本概念191
7.2　Freshness Value构造197
7.2.1　FreshnessValue长度配置197
7.2.2　FreshnessValue的提供者FM199
7.2.3　基于单Freshness Counter的Freshness Value构造和验证199
7.2.4　基于单Timestamp的FreshnessValue构造和验证201
7.2.5　基于多个Freshness Counter的Freshness Value202
7.3　同步报文的发送和接收215
7.3.1　同步报文组成215
7.3.2　Master ECU发送同步报文流程217
7.3.3　Slave ECU接收同步报文流程218
7.4　SecOC报文发送和接收流程219
7.4.1　SecOC报文的发送流程219
7.4.2　SecOC报文的接收流程223
7.4.3　接收方的可接受窗口225
7.5　本章小结227
第8章　CAN Bus-Off228
8.1　CAN错误帧228
8.1.1　CAN错误帧格式228
8.1.2　CAN的仲裁原理233
8.1.3　CAN错误类型234
8.1.4　错误计数原则235
8.2　网络启动时的错误处理237
8.3　节点重新上线后的行为237
8.4　CAN Bus-Off产生原理238
8.5　如何制造CAN Bus-Off239
8.6　CAN Bus-Off对通信的影响239
8.7　基于VH6501的Bus-Off测试240
8.7.1　测试环境241
8.7.2　测试原理243
8.7.3　CAN Bus-Off的CAPL测试脚本245
8.7.4　Bus-Off CAPL测试脚本及测试现象245
8.7.5　Bus-Off快慢恢复测试249
8.8　本章小结251
第9章　局部网络管理252
9.1　PN简介252
9.1.1　VFC和PNC定义254
9.1.2　PNC信息格式256
9.2　PN网络管理状态机258
9.2.1　网关ECU的PNC信息接收262
9.2.2　终端ECU的PNC信息接收263
9.2.3　PNC信息的发送流程265
9.2.4　CP AUTOSAR中的ComM PN模式266
9.3　PNC请求272
9.3.1　ERA请求272
9.3.2　EIRA请求273
9.4　PNC路由273
9.4.1　PNC主动路由274
9.4.2　PNC被动路由275
9.5　PNC状态机切换示例276
9.6　本章小结278
第10章　CAN/CAN FD网络唤醒测试实践279
10.1　CAN/CAN FD测试需求279
10.1.1　网络启动时间测试281
10.1.2　网络唤醒测试286
10.1.3　网络休眠测试287
10.2　本章小结288
参考文献289

为什么要写这本书
为什么要写这本书？促成的因素并不是单一的。最开始，有出版社的朋友通过微信联系到我，希望能将我微信公众号的文章整理一下，基于工程的视角写一本书。老实说，平日里的工作和生活的柴米油盐已经挤满了我的时间表。自认为很难“挤”出一丁点的时间去写一本书。因为我知道，基于工程的视角写一本书，需要庞大的知识储备，而我对自己的储备并没有信心。那么，又是什么给了我动力去撰写本书呢？
家人的肯定。我爱人说：“你写了那么多公众号文章，写书这事你真的可以认真考虑一下。”确实，我一直有整理工作内容的习惯，利用碎片化时间整理自己的所思和所想，然后通过“开心果 Need Car”这个公众号分享出来，也通过它收获读者的反馈和斧正。既然文字可以帮助他人，也能提升自己，为什么不写一本书呢？除了爱人，我想，我儿子是我坚持写完本书的最大动力。小家伙问我：“爸爸，你写的书会有很多人看吗？”我没有正面回答，但是很开心。此时，我更加清晰地知道自己为什么要写了——为他树立榜样。我想以身作则地教会他坚持，让他觉得爸爸“很厉害”。或许，这比任何的说教都来得实际，因为这种“成长”是潜移默化的影响。写书的日子里，有时确实很累，有时也不知道写得是否合理，也有时想放弃……但是，每每想到为儿子树立榜样这件事，放弃的念头就瞬间打消。
朋友的鼓励。有些朋友知道我要写书，便给予我很多鼓励，让我更深信撰写本书的意义。写书不是为了炫耀自己的才能，而是能通过本书的分享去收获更多。就像我写公众号，有时写的论点或者对问题的理解并不准确，有些相关领域的读者，看到后给我留言或者私信，通过交流，不仅加深了我对问题的理解，也让我意识到自己的“浅薄”。所以，写书的事也就势在必行了。
读者的期待。微信公众号“开心果Need Car”从2021年开始写，一直坚持到现在。随着写的量和内容质量的提高，被抄袭的也越来越多。甚至一些读者看不惯，还会转我一些被抄袭内容，替我愤愤不平。最开始，自己也试着去举报一些过分的抄袭者，但是，这太耗费自己的时间和精力。怎么办？转念一想，如果我分享的内容可以真正地帮到那些需要的朋友，那就这样吧。有不少读者给我留言，语言很温暖，也很有力量，我在此向他们表达谢意。我记得有位读者说过，我的文字像坐在身边的同事。如果本书也能达到同样的效果，写本书的意义也就从另一个层面具象化了。
所以，上述多种因素的叠加，为我撰写本书加注了动力。
读者对象
本书适合以下读者阅读：
嵌入式硬件工程师
嵌入式软件工程师
汽车嵌入式领域的相关从业者
对汽车嵌入式领域感兴趣的高校师生及爱好者
如何阅读本书
关于如何阅读这本书，我从个人的工程实践经历，浅谈自己的看法。如果你是一家企业的工程师，当出现工程问题时，或许，在不少的时间里，会觉得自己对问题无从下手。当然，这也是我开始从业时的感受。为什么会有这样的感受？原因是对知识框架的掌握不够充分和细致。为什么这样说？目前来说，汽车控制器的开发周期短，而且一个工程需要众多开发工程师的协作配合，每个工程师分担的工作内容很聚焦，在考虑问题时，就难免有一定的局限性。同时，工具链在很大程度上“屏蔽”了工程师对细节的了解。所以，当出现跨模块的复杂、偶发问题时，初入行的工程师，会感觉无从查起。
基于此，本书在前两个章节着重讨论通信物理层的知识。物理层的知识就像房子的地基，构建好了基础，才能更好地设计上层建筑。
本书从第3章 ~ 第9章讨论上层协议。如果我们有了很好的物理层基础，构建上层协议将不再困顿，甚至能更好地理解协议设计的目的。如此，上层和下层知识贯穿，我们开发的工业产品才能达到预期的设计目标，甚至超出预期。
本书的最后一个章节虽然只对CAN/CAN FD讨论了关注的测试项，但是，基于这样的思路，也可以延伸到其他总线。
当然，本书还有很多想写却未展开的内容，比如：CAN XL、Ethernet、硬件路由等。如果本书有机会再版，我将试着补充进去。
勘误和支持
限于自己水平的局限性，书中所述内容难免出错或者表达不精准，恳请读者包容和指正。如果你想纠正书中表达不准确之处，烦请通过微信公众号“开心果 Need Car”留言。期待你的留言，在技术的路上我们共勉。对于本书的内容，很多是结合工程问题，反向“咀嚼”对应规范和资料的产物，它并不是创新，而更像是一位技术工程师的学习过程。所以，读者朋友们可以将本书看作一本“工具书”，更精准地描述，还是需要回归到原有的技术规范、客户需求或者器件的手册说明。
致谢
我想表达的感谢已经在前面为什么要写这本书里提及。这里，向我的家人、朋友、读者，还有自己，道一声：谢谢。

宋　鑫