2万字长文说清自动驾驶功能架构的演进
多解释一下，AEB看似是L0级功能，但是其开发难度不低于NOA脱手功能，主要挑战在于如何权衡误制动和漏制动。这既是功能话题，又是安全话题，业界做的最好的Mobileye，AEB的成绩是10万公里误制动一次，俗称AEB false positive，而这个成绩对于预期功能安全的AEB接受准则（某公司要求30万公里误制动一次），还远远不够，当前乘用车+商用车的AEB前装量接近100%，市场配置AEB车辆的数量巨大，意味着每天都会发生由于AEB导致的急刹车，进而可能导致追尾事故。
功能安全：该架构支持的功能清单中，如AEB存在ASL D的安全目标，但是通过执行器的性能限制/安全阀值约束，降低整车风险至ASIL B，分配给传感器整体满足ASIL B即可，camera和前毫米波雷达满足ASIL B。
功能架构简介：
特斯拉为啥删掉毫米波雷达？
域控式ADAS架构存在的意义是什么？
这种架构形态对于OEM而言是一种技术过渡的中间态，然而这个阶段却是OEM技术沉淀的一个缓冲期， 都有哪些短平快策略的进场信号？ OEM同步搭建感知融合团队、域控制器团队、规控团队、基础软件团队、标定团队、定位团队、软硬件集成团队，大大提高了资源整合能力（控制器布置、线束布置、总线通讯设计、接口定义平台化设计、工具链的打通、仿真测试能力建立）， 时机成熟后OEM会迅速切入跨域式融合架构，把域控式架构中的控制器从架构中剥离出来，作为后续跨域冗余架构的fallback控制器（别急，下文跨域冗余式架构章节会详细解析），这就体现了架构的艺术，架构的价值！
低配版行泊一体功能架构图
高配版行泊一体功能架构图
系统架构如何设计？
未来单SOC的价格会比SOC+MCU便宜，即使单SOC也能符合功能安全ASIL D的要求（目前行业内的大算力SOC只能做到ASIL B），也可以满足网络安全要求，但是对于完全自动驾驶安全而言做到“相对安全”还远远不够，需要做到“本质安全”，因此笔者认为外挂MCU还是非常有必要，笔者是独立MCU的拥护者。
OEM的“外患、内忧”有望解除
L3功能架构设计
L3架构的安全考量
5.主控接入的传感器和副控接入的传感器从预期功能安全角度形成互补，对于L3主功能而言是逻辑“或”的关系，这种设计能大幅度规避corner case，但也不能完全消除corner case。
L3的主控制器毋庸置疑是需要达到ASIL D的（非预期类安全目标），主控制器应该按照ASIL D能力开发，SOC和MCU是串联的关系，那么都要符合ASIL D，ASIL D的MCU常见，但是符合ASIL D标准的SOC还没有，行业内SOC几乎都是ASIL B（最新消息：安霸CV2FS/CV22FS芯片已做到ASIL C，获得Exida认证，为全球首例），那这个差异会造成什么后果呢？
.ASIL B和D在软件的单元设计和架构设计上差异不大，但硬件方面差异较大——ASIL B的单点、潜伏、随机硬件失效率的要求均低于ASIL D，意味着只达到ASIL B标准的SOC的某些故障无法被探测到，这导致主域控制器无法设计对应的安全机制，那么如何规避SOC在功能安全上的短板呢？