CAN通讯系列29 - CAN信号背后都经历了什么？

当你看到这些CAN报文在鲜活的跳动时可能没什么感觉，其实每一条报文，甚至每一个信号都生而不易，也许经历了一段非常精彩的故事，有过拉扯，也有过争论，甚至掐过架。下面就来详细讲讲，那就先从整车的网络拓扑开始。

1 整车的网络拓扑  

• 域控制器：VCU, HMI和TBOX
• 子控制器：BMS和OBC

• 
  首先，最基本的点，这么多控制器要明白到认可这个功能实现的逻辑，认领各自的任务，必须通过多番的沟通。因为这一方面涉及到工作量，另一方面涉及到责任划分，有些公司是需要反复拉扯的，也许遥遥无期。
  
• 
  然后是CAN通讯，哪些信号谁来发？哪些信号谁要收？CAN通讯的变更通常涉及底层软件和应用层软件的变更，而主机厂一般采购控制器和底层软件，因此当确定了谁发谁收之后，一方面要找供应商来做变更，不仅仅涉及到时间和成本，还需要反复商讨开发计划和释放计划。基于各自利益角度的出发，拉扯和争论不可避免，有时候谁嗓门大谁强势谁胜出。
  
• 
  最后，当确定了CAN信号谁收谁发，接下来就是把这些CAN信号排进各个控制器的CAN矩阵，那么如何排？是添加到现有CAN报文，还是需要新增CAN报文? 通常由电子电器架构部门来负责，他们专门负责整车的所有通讯矩阵，包括CAN通讯，LIN通讯和以太网通讯等形式。他们有CAN信号增减的生杀大权，如果他们同意CAN矩阵变更，那由他们来决定如何增加，增加到哪个ID？具体排到从哪一位到哪一位。但是实际情况不会那么顺畅，经常碰到电子电器架构部门拒绝退回的情况，原因比如是CAN通讯的变更将导致CAN总线负载率过高，此时功能开发工程师就只能各显神通了，如果对功能影响没要么大，也许就此放弃；如果必须要的，那么就上升继续推；如果懂CAN通讯，可以算一算到底有没有增加负载率，想办法把新增的CAN信号好好排一排，塞进去。