【AUTOSAR-CP-CAN-0】简介、问题讨论与答疑汇总

0.关于这个专栏

曾任职于某国产新能源的 OS 开发。现辞职考研中。这个系列博客我本意是记录自己的学习内容，所而且所学的内容基本全部来自于 AUTOSAR 官方文档，所以一直没有计划收费 and balabala。

现在我有时间来维护自己的博客，我希望把自己的内容做精，做好。 我想在今天及之后的一系列博客中，从一个初学者视角，讲述这些专业知识，并且由浅入深，让所有读者有机会和 expert 站在同一个角度观察问题，思考问题。

我的最终愿景是帮助更多人深入学习和研究汽车控制的关键系统，并且成为推动标准演化，乃至创造新的汽车控制软件生态，推动汽车控制系统泛在智能，泛在互联的新生力量！

注意：如果你想寻求某些工具的使用方法，那我的系列博客，起码截止到目前我没有，也没有介绍工具使用方法的打算。你应该到此为止，并去查找其他的博客。 因为学习使用工具实在是一件简单的事，你只需要知道应该怎么做然后不断练习就可以。你会说你说的太简单了，哪有你说的那么容易。其实感到困难的原因无非只有两个，一是你不熟悉工具，别人和你说这个功能那个功能你并不知道他们在哪，也不知道是勾选一下还是需要填个数字，填个名字，导入文件还是做什么操作就可以实现你的目的；二是，你不会拆解你的任务为多个可执行的原子任务或操作。如果你相当了解工具的使用场景及边界，以及你相当熟悉你的业务，那这一切甚至比从事简单的体力劳动还不需要动脑。（至少你会有这样的感觉）

既然官方文档都有了，那我的系列博客提供什么：

1. 官方文档是目前的权威参考。如果你去随意打开一篇官方文档任意阅读中间的某个段落。你会学会接下来这句英文：What hell is that? 原因是，官方文档是由委员会的专家们维护的成熟的“规则”合集。相当于一部完善的法律，每一个子章节都有可能和其他章节，乃至其他类型的法律产生关联或者互为补充。这是官方文档很难学习的原因。事实上这本来就是专家写给业内人士的“指南”，他追求的是逻辑严谨，细节精确，以及行业认同。因此官方文档会带来很大的学习代价。事实上，我第一次学习的 COM 模块，就经历了一个相当痛苦的过程。（五万字长文的翻译，以及数不清次数的重复阅读，反复查阅，以及一些很痛苦的代码历练，才让我对这个模块有了一定的理解）因此这是我的博客存在的意义，我会从一个初学者角度出发，用几个常见的“灵魂发问”（这是什么，这在哪，为啥是这样）来让我们迅速获得对一个模块的基本理解。并且随后就会逐一探讨其技术要点以及核心内容，最终掌握其原理，知其所以然。 因此如果你满足于操作那几个工具配出来代码就完成任务，That’s DONE. 我的博客并不适合你。如果你希望了解更深入的内容，那你不妨读下去，看看我究竟是怎么个事。（开玩笑说法哈哈，这是我的风格，我也不喜欢满篇枯燥无趣）
2. 最独一无二的，是商用级 AUTOSAR 代码开发实践（代码开发而非使用配置工具）经历带来的独特的理解、观察和学习视角。我会从开发这样的代码的角度来带读者看待问题，理解标准文档，了解功能背后的机制和原因。这样深入的研究和对AUTOSAR Classic Platform的新颖解释是独一无二的，也是最宝贵的。 此外，我会在博客中补充一些代码片段和编程技巧。
3. 深入剖析技术细节：我会在任何博客中（需要的时候）引述我的资料来源，文档支撑，你可以随时自行查阅（我一般会具体到文档的页，方便查阅），当有人质疑你的理解的时候，你也可以这样做（如果你对知识的理解有十足的把握，尤其是在面对问题、质疑的时候）。在深入探讨AUTOSAR Classic Platform的架构、接口和工作原理之外，提供技术层面上的深度思考的内容。
4. 社区构建与支持。 欢迎读者在评论区提问，任何具有相关背景的可以解答问题的人都可以参与互动和讨论。此外，我会对一些关键读者的问题，在本篇文章中做深入的剖析和解答（因此这篇文章会始终在不定期更新）。 而且，已经购买的读者可以加入 AUTOSAR 交流群，我会于近期创建，并于适时时间，对已经购买本专栏的读者开放加入。
5. 关于博客内容的更新和完善：计划每周一更，每次更新会放在周五六日这三天之内。本专栏会会讲解到 CAN、LIN 报文收发所涉及的（基本上）全部内容。足以支撑读者在这一领域拥有专家级别的知识和理解支撑。
6. 很多小惊喜。相信读者对我的笔风应该有大致感受，我不喜欢沉闷枯燥的知识学习，因此，可能会比较皮，有时候甚至会用一些梗，开一些玩笑。一些简单的英文也会穿插其中，绝对不多，期望有益于提升读者的英语水平，英语水平对于学习一些国外制定的标准实在是太关键了。

适合的读者：

1. 想要深入学习相关原理和机制，不想只满足于会使用工具配置代码。
2. 有兴趣了解自动驾驶的控制系统。这个专栏基本覆盖了自动驾驶场景下一半的对通信的需求。（为什么是一半，我会在博客中详细解释）
3. 涨薪跳槽，追求更好的个人职业发展，etc。
4. Maybe 你要做什么相关投资，需要收集一些专业的信息。虽然我不能直接提供什么帮助，但是我还是偶尔会阐述一下关于这个标准的发展相关的一些个人的观点，仅供参考。

1. 简介

1.1 引言

在当今汽车电子系统的快速发展中，AUTOSAR（Automotive Open System Architecture）成为了一种广泛应用的标准化软件架构。这里将简单介绍一些AUTOSAR的基础必备知识。

1.2 AUTOSAR的背景与发展

汽车行业不断发展，车辆电子控制单元（ECU）的数量和复杂性不断增加。在过去，每个汽车制造商都采用独立的、定制化的软件架构来开发ECU，这导致了软件复用率低、开发周期长、维护成本高等问题。

为了解决这些挑战，AUTOSAR联盟成立于2003年，旨在建立一种开放的、标准化的软件架构，以促进汽车电子系统的开发和集成。AUTOSAR标准的目标是实现ECU软件的可重用性、可扩展性和互操作性，使汽车制造商能够更高效地开发和维护ECU，并为汽车产业提供共同的技术基础。

1.3 AUTOSAR架构概览

AUTOSAR架构采用分层的设计，分为应用层（APPL：Applications Layer）、运行时环境（RTE：Runtime Environment）、基础软件层（BSW:Basic Software）和硬件抽象层（MCAL：Microcontroller Abstraction Layer）。

1. 应用层：应用层是与汽车应用程序相关的软件组件的集合，它包括了各种汽车功能的实现，如发动机控制、座椅控制、车门控制等。应用层的软件组件使用标准化的AUTOSAR接口进行通信，使得这些组件在不同的ECU之间可以灵活地组合和交换。
2. 运行时环境 ：RTE负责实现AUTOSAR标准接口的运行时逻辑，使得各个SWC能够在运行时互相通信和协调工作。它提供了AUTOSAR标准中定义的一些重要接口，如Sender-Receiver Interface、Client-Server Interface等，用于SWC之间的数据传输和服务调用。通过RTE，SWC之间的通信过程得到了高度的抽象和标准化，从而增加了系统的可维护性和可扩展性。
3. 基础软件层：基础软件层是AUTOSAR标准中定义的一系列基础软件模块，包括操作系统（OS）、通信堆栈（COM）、诊断（DIAG）、网络管理（NM）等。这些基础软件模块提供了与硬件无关的接口和功能，确保了AUTOSAR应用层与底层硬件的解耦，使得软件在不同的ECU上能够更容易地移植和复用。
4. 硬件抽象层：硬件抽象层提供了对底层硬件的抽象和访问接口，使得AUTOSAR软件能够适配不同的硬件平台。硬件抽象层包括硬件抽象层驱动（HWD）和硬件抽象层微控制器抽象层（MCAL）。HWD提供了对硬件资源的底层访问，而MCAL提供了与微控制器硬件相关的接口和功能。

1.4 AUTOSAR核心概念

AUTOSAR引入了一些核心概念，这些概念是理解和应用AUTOSAR的基础。

1. ECU（Electronic Control Unit）：ECU是指装载AUTOSAR软件的电子控制单元，它负责执行汽车各种功能的软件。ECU可以是整个车辆中的某个控制模块，如发动机控制模块、座椅控制模块等。
2. SWC（Software Component）：SWC是AUTOSAR应用层的基本单元，它是实现特定功能的软件模块。一个SWC可以是一个简单的功能单元，也可以是一个复杂的子系统，通过标准化接口与其他SWC进行通信。
3. RTE（Run-Time Environment）：RTE是AUTOSAR中的运行时环境，它管理应用层SWC之间的通信，提供了AUTOSAR标准接口的实现和运行时数据交换。
4. PDU（Protocol Data Unit）：PDU是AUTOSAR中用于数据传输的基本单元，它包含了应用层SWC之间的数据和通信信息。
5. CAN（Controller Area Network）：CAN是一种在汽车电子系统中广泛使用的通信协议，用于ECU之间的数据传输和通信。
6. LIN（Local Interconnect Network）：LIN是一种低速通信协议，主要用于汽车内部较简单的控制任务，如车门控制、窗户控制等。

1.5 通信是 AutoSar 的核心业务

注意：通信是 AutoSar 的核心业务。 （工作中的客观理解，有共识，下面阐述理由）

通信是AUTOSAR Classic Platform的核心业务，这是因为AUTOSAR Classic Platform的主要目标之一是实现汽车电子控制单元（ECU）之间的标准化通信和数据交换。通信在AUTOSAR架构中扮演着至关重要的角色，包括但不限于：

1. 软件组件之间的交互：在AUTOSAR架构中，各个软件组件（SWC）被视为独立的模块，它们可以分别开发、测试和维护。这些SWC之间的交互需要通过标准化的通信机制进行，以确保它们在不同的ECU之间能够正确地协同工作。
2. 硬件无关性：AUTOSAR致力于提供硬件无关的软件开发平台。为了实现这一目标，软件组件需要与硬件平台解耦，而通信层则扮演着连接软件组件和硬件的关键角色。通过通信层的抽象，软件组件可以在不同的ECU上进行灵活的移植和复用。
3. 多ECU系统：现代汽车通常由多个ECU组成，每个ECU负责不同的功能模块。这些ECU之间需要频繁地交换数据和信息，以实现全车的整体控制。AUTOSAR的通信机制能够有效地协调多个ECU之间的数据传输，确保系统稳定性和性能。
4. 支持多种通信协议：AUTOSAR Classic Platform支持多种通信协议，如CAN（Controller Area Network）、LIN（Local Interconnect Network）、Ethernet等。这样，汽车制造商可以根据不同的功能和需求选择合适的通信协议，而无需重新设计整个软件架构。
5. 系统可扩展性：通过使用标准化的通信接口，汽车制造商可以方便地增加或更换ECU，并在整个系统中实现功能的扩展和升级。这样，汽车系统可以更容易地适应不断变化的市场需求和技术进步。

综上所述，通信是AUTOSAR Classic Platform的核心业务，它在整个AUTOSAR架构中起着连接和协调的关键作用，确保不同的软件组件和ECU能够高效地协同工作，实现复杂的汽车电子控制功能。

笔者在此甚至可以更大胆些，汽车电子电气化的核心问题就是基于总线通信的硬件资源整合、协调、扩展以及智能化。 （纯业务理解，留待读者在实践中检验！）

了解这些核心概念是理解和使用AUTOSAR的基础，它们在AUTOSAR开发中发挥着重要的作用，并为AUTOSAR系统的构建和集成提供了指导和基础。这些内容应该对读者没有什么理解上的困难，如果有，请在评论中留言，我会及时回复。同时这些也是我们专精本专栏的基础。

2. 问题讨论与答疑汇总

这篇文章除大致简介之外还会收集所有 读者老爷 提出的关于 AUTOSAR-CP-CAN 协议栈的相关问题，并在这里给出相应解释，供 读者老爷 参考、查阅、讨论。

欢迎各位 读者老爷 通过评论区或者私信提出问题。在笔者的回答中，并非标准答案，欢迎讨论，欢迎大佬指教。

2.1 网络管理报文与报文发送模式

Q1 为什么外发的网络管理报文配置成（direct+pending）不影响发送？普通报文就不行

笔者从笔者所知的发送属性和模块交互两个角度，和大家探讨一下问题。

• 发送属性：direct 是直接发送，如果只有 pending 的信号是没法发出去的，direct 发送模式的报文想发送出去只有两种可能
  • （1）信号发送属性可以触发报文发送，例如 trigger，trigger with\without repetition、trigger on change 等
  • （2）报文会被路由路径的下层模块调用 Com_TriggerTransmit 发送（这样的情况也不适合配置为 direct 模式）
• 模块交互：signal 发送属性（trigger\pending…）和报文发送模式（direct\cyclic\none\mix）的功能实现是在 COM 模块实现的，即这些属性的配置在代码中体现在 COM 模块的配置代码中。在 CAN 通信协议中，NM message 是由 CANNM 发送的（如下所示，CANNM 报文会直接走到 CanIf 发送出去），该报文并不体现信号属性、报文属性，就算配置了也没有作用。
  

2.2 IMMEDIATE 与 DEFERRED

• IMMEDIATE：the signal indications / confirmations are performed in Com_RxIndication/Com_TxConfirmation。即立即处理，一般 RxIndication 是从底层 CAN Controller 触发硬件中断到 CANIF ，再到 PDUR，再到Com_RxIndication / Com_TxConfirmation。所以 IMMEDIATE 类比支持中断处理的意思。
• DEFERRED：signal indication / confirmations are deferred for example to a cyclic task。意思就是，设置为 DEFERRED，Com_RxIndication/Com_TxConfirmation 会在 Com 对应的 MainfunctionRx\Tx 中处理，Mainfunction 是周期函数，所以这种处理方式类比支持轮询处理的意思。

关于轮询与中断，是 Linux 服务器编程中处理事件的两种经典方式。轮询，意味着固定时间的循环，循环的对象很“长”时，意味着资源消耗较大。中断，意味着为事件注册回调函数，当事件发生时再来处理即可，再事件未发生时，不需要经常的轮询，使得 CPU 做无意义的询问。（可以去搜一下，这里简单介绍一下）

3. 关注、点赞、收藏，素质三连，栓Q 读者老爷