车载网络测试 - UDS诊断篇 - CAN与OSI七层模型

为什么会介绍OSI七层模型？

好久没有更新文章了，实在是太累了最近；偶尔有时间也是想着给自己放个假思考下人生，转眼间，人生已经过去一小半了，即将变成曾经自己眼中的中年男人，然而随着年龄的增加，身体也因为这些年的加班、熬夜一直在走下坡路，逐渐的想走向躺平的状态；不过想想身上的担子，还是要继续努力，人嘛，总归要为自己的付出代价的；

以上纯属瞎扯，今天主要介绍下CAN诊断在OSI七层模型中各个layer中我们想要学习所需要的了解的协议规范吧，为什么要介绍这块呢？

以下纯属个人观点，大家感觉对的话就一起探讨下，如果感觉不对，那我也没办法了；你如果有更好的学习方法，也希望分享以下给我，我也想学习。把CAN总线或者以后大家有机会接触LIN总线、Ethernet总线等等，这些内容都是比较抽象的，而我们学习有具象的东西会更加的快速，否则学习难度将呈现指数难度增加；当我们把不容易接触到的总线协议放在了常见的OSI七层模型中之后，我们将会更加容易的去记住一些关键信息，有助于我么掌握这门知识，以及建立我们的本身的知识体系，这也是我们第一部分我个人认为对的一个答案。

CAN规范与OSI模型

今天咱们主要介绍在前装开发中使用的总线协议，也就是下图中的第二列介绍的内容。

1、Physical Layer 1

CAN的物理层相关的定义都是集中在ISO 11898相关的文档中，这些文档大家可以在ISO官方网站进行购买ISO - International Organization for Standardization，不过这种比较贵，我们大部分人是负担不起的；那就可以选择淘宝几块或者十几块就能解决，非常便捷；这块对应我们测试交付中的物理层测试，如果物理层测试存在疑问，可以在这里进行查找源头。不过由于这块一般是由硬件工程师和硬件测试工程师负责，作为软件出身的我有点无能为力，大家有兴趣的话可以去深入研究一下。

2、Data Link Layer 2

数据链路层，个人感觉数据链路层和物理层差异并不明显，特别是是在做CAN总线的这个过程中，测试工程师一般都会把数据链路层和物理层归结为一个层级 -- 物理层，因此如果是硬件工程师或者硬件测试工程师，就多去了解一下吧，软件测试工程师感觉没必要花费太多精力在这里，毕竟术业有专攻嘛1

3、Network Layer 3 & Transport Protocol Layer 4

网络层和传输层，为什么把这2个层级归为一个层级呢？这也是由于它本身的特性所决定的，这2个层级软件测试工程师接触最多的协议就属ISO 15765 - 2了，他主要定义了CANTP层的传输逻辑，当然CAN通信测试的实际上也是这块的内容，测试工作中常说的诊断协议栈和通信协议栈底层配置，就是说的这里。说道这里了，不得不提一下车载行业软件的开发流程，我们常听说的供应商一般是指车上各个ECU的供货厂家，这里面又根据不同的类型进行了分门别类；另外一种供应商是做底层协议栈的，最出名的就是大家比较熟悉的Vector、ETAS、EB；当然这三个都是全球知名的；我们国内也有：东软瑞驰、经纬恒润和普华基础软件，这些年我们国产软件也在逐步的变强，希望有朝一日我们能够超越全球，做到第一。

扯远了，第三层和第四层，作为软件测试工程我们主要关注的就是CAN的通信层测试和CAN诊断的TP层测试，这2块一定要把握好，基本没什么问题了。

4、Transport Protocol Layer 4

传输层，这里主要对应的是ISO 14229 - 2，而在这里我们常见的测试主要就是诊断服务测试，这里面包括：会话切换服务 - 10；测量读取服务 - 22；设置写入配置服务 - 2E；重启服务 - 11；线程控制服务 - 31；IO控制服务 - 2F；安全解锁服务 - 27；刷写使用的上传下载、确认等服务 - 35/36/37等等。

另外的测试就是我们常说的ID测试，包括DID、Routine ID、IO Control ID等测试，这块协议层的测试将包含大量的测试用例，我们有机会可以进行一个更进一步的详细了解。