介绍了 车载网络的结构，及CAN和ECU在车载网络中的作用。
以下内容摘自： 李闯. 车载网络CAN总线报文异常检测技术研究[D].天津理工大学,2021.
目录
传统车载网络结构
上图为常见的车载网络结构。
CAN总线
目前大部分车载网络总线都是部署的 CAN 总线，它连接着车内传动轴、发动机、变速箱等一系列重要设备 。
CAN 总线并不是直接控制这些设备，而是通过 ECU 接收和发送总线上的数据，这些 ECU 又连接着传动轴、发动机、变速箱等设备。
根据传输速率可以将 CAN 总线分为高速 CAN 总线和低速 CAN 总线。
高速 CAN总线和低速 CAN 总线的物理层电气特性不一样，因此不能将它们连接在一起。
高速 CAN 总线的传输速率为 125Kbps 到 1Mbps，主要应用在传动轴、发动机等要求数据传输速度快、保证实时传输无延迟的场合；
而低速 CAN 总线的传输速率最高为 125Kbps，主要应用在对车身控制系统等对可靠性要求高的场合，如仪表盘和远程信息处理等。
CAN总线数据帧
CAN 总线是一个广播类型的总线，所以总线上传输的数据很容易通过总线上的其他任意节点监听到，它允许标准的微控制器和设备互相进行通信。
现在，CAN 总线不只是用在汽车内各设备的通信，也可以在许多其他通信环境中使用。
CAN 协议标准定义了四种消息类型，通过一种叫做比特位仲裁机制来控制每条消息进入 CAN 总线，所以消息的优先权是提前标记好了的。其具体格式如图2.2 所示。
ECU
CAN 总线上的数据都是通过 ECU发送和接收来传输的。
ECU 是汽车中用来控制电气系统、电子系统及汽车子系统的嵌入式系统[33]，其本质就是一个微型计算机。
ECU 的主要功能是运算和处理从各个设备上读取数据，然后把数据传送到 CAN 总线上，其他 ECU 就可以从CAN 总线接收到这些数据；任意 ECU 都可以从 CAN 总线上读取数据，并通过对接收到的数据运算和处理来控制当前设备的运转。
以上内容摘自： 李闯. 车载网络CAN总线报文异常检测技术研究[D].天津理工大学,2021.
ECU--> 软件定义的汽车
https://blog.csdn.net/programmer_editor/article/details/121518666
与20年前的数据中心类似，传统汽车是经典的“硬件隔离软件”架构。
每一辆量产车有50+软件供应商，要让这么多软件模块安全可靠地在同一辆车上运行，传统的方法是让每一个供应商把软件封装在自己的计算机硬件里面。
这些供应商封装提供的计算机叫作ECU。每个ECU里面有一套完整的芯片、存储、操作系统与应用软件，ECU之间只通过简单的实时网络传输信息，从而达成隔离不同供应商软件的目的。
今天每一辆汽车有100~150个ECU，其软件的复杂性已经很难管理。
因而，以Tesla为代表的“造车新势力”开始采用以软件为中心的架构，新一代智能汽车也不再有100+ECU，而是拥有一台到几台通用计算机。
2021智能网联汽车专题报告_王博（Kings）的博客-CSDN博客-
特斯拉通过Model3率先推出“区域zone”概念，跨越式发展车载电脑和区域导向架构，车身包含CCM（中央计算机模块）、BCMLH（ 左车身控制模块）、BCMRH（右车身控制模块）三个模块，其中中央计算机模块整合了驾驶辅助系统和信息娱乐系统两大域，左右车身控制系统则分别负责剩下的车身与便利系统、底盘与安全系统和部分动力系统功能。
----------------------------——
汽车电子电气架构（E/E 架构）是指整车电子电气系统的总布置方案，即将汽车里的各类传感器、处理器、线束连接、电子电气分配系统和软硬件整合在一起，以实现整车的功能、运算、动力及能量的分配。
传统汽车架构升级遵循分布式架构-域集中架构-跨域融合-中央计算平台路径。传统汽车采用分布式的电子电气架构具有计算能力不足、通讯带宽不足、不便于软硬件升级等缺陷，无法满足现阶段汽车发展的需求 。
E/E架构升级——域集中式，现阶段主流发展形式
域集中控制器架构，以几个大单元为单位将其从属功能整合在区域内，进行模块化和集中化 ，最终实现系统模块数量级的减少。
域集中架构能够将几十个甚至上百个ECU控制单元，减少到3-5个“域”控制系统，即车身系统 、娱乐系统、底盘与安全系统、动力系统，和高级辅助驾驶系统等五个大“域”。
不同“域 ”之间安全隔离的同时，也可以根据需求进行通信和互操作，变成了可共享的资源和算力，在其上层可以有一个统一的“操作软件”。
供应商的软件作为模块运行在这些计算机上，隔离不同供应商模块的不再是硬件与网络，而是软件容器，这就是“软件定义的汽车”。而以软件为中心的新架构对下一代汽车的基础软件，包括其核心操作系统，提出了新的要求。
ADAS域与座舱域
目前，智能汽车正在从ECU向“软件定义”过渡，车企不能一步到位，走到每辆车只有一台超级计算机的架构，只能过渡到每辆车3~4个“域计算机”（也称“域控制器”），其中有两个很重要的域：ADAS域与座舱域。
- ADAS域计算机管理着汽车自动驾驶的传感器、AI推理、决策与控制。
- 座舱域计算机管理着汽车座舱的控制与用户交互体验。
这两个域的操作系统并不相同。
在座舱域中，车企一般使用的是Android系统，或者是剪裁版的Linux，以保证大量应用程序的兼容性。座舱里的Linux与Android系统使用开源的底层操作系统，有巨大的开发者社区。其上层的应用App可以是开源或闭源的。
在ADAS域中，车企一般使用商业的实时操作系统，如QNX与VxWorks等。ADAS的底层操作系统一般不开源，而应用虽然有开源的，如Autoware与百度的Apollo，但是绝大部分算法、传感器集成以及推理应用都是不开源的。
当然，这两个域的操作系统也有重叠的地方。例如，座舱域中显示驾驶数据的屏幕（车速、自动驾驶信息）一般是用QNX，以保证实时的数据读写。在座舱内，对Android、Linux与QNX的需求还产生了专门的Hypervisor虚拟化解决方案，如OpenSynergy，能让几个操作系统用虚拟化的方式运行在同一个硬件计算机上。
沙盒技术：Docker --》webAssembly
未来，如果软件定义的汽车发展到每辆车只有一台超级计算机，对这台计算机的操作系统与软件生态的控制权，更是整车厂不能放弃的。
这里的挑战是，整车厂或者域供应商，如何在一个开放的计算平台上安全高效地集成多个下游供应商与开发者写的软件？其实，这个问题在“软件定义的数据中心”已经有了很好的解决方向：使用软件容器隔离各个供应商写的模块。
云原生数据中心用Docker这类软件容器实现隔离。汽车厂商也一直在试图使用Docker这样的软件容器。但是，在云原生数据中心大量使用的Docker与K8s并不能从根本上满足汽车上软件容器的需求。它们太慢，太重，也不能满足实时性的需求。市场上急需一个更好的解决方案。
新一代的轻量级软件沙盒/容器技术，如支持多种编程语言与多种操作系统/硬件的WebAssembly Runtime，是在汽车这种边缘设备上实现软件隔离的很好选择。WebAssembly直接从操作系统的线程启动，并不需要模拟一个自己的操作系统环境，在启动时间上可以比Docker这类解决方案快100倍以上。并且，WebAssembly Runtime抽象了底层的硬件与操作系统，开发者就能用现代的编程语言与框架，如Rust，写出高性能、可移植的汽车应用。
智能汽车操作系统——行业动态
在智能汽车火热的中国市场中，有技术实力的汽车软件公司也都在向自研操作系统努力。它们都是从基于Linux的座舱系统（如前述的AGL）往实时车控操作系统演进。其中比较有代表性的是以下几家。
阿里与上汽合资的斑马智行于2021年7月获得30亿元的增资，主要用于基于开源的AliOS的汽车操作系统开发。
华为于2021年发布了开源微内核的鸿蒙操作系统，业界普遍认为是可以用在未来汽车上的。
镁佳在2021年5月融资一亿美元，用于汽车操作系统与应用商店的研发。
中科创达是国内领先的汽车软件应用开发商，其高层在最近的访谈中反复强调了公司要做操作系统的决心。
加之前面提到的seL4基金会成员地平线、蔚来、理想、Second State，中国厂商目前在汽车操作系统的两个主要方向都有布局，正走在世界智能汽车操作系统领域的前列。