需求提清楚了，项目开发起来神清气爽。需求提不清楚，项目开发起来一团乱麻。可见需求不仅得定义好还得管理好。个人觉得需求的编写和创建过程中“颗粒度”和“完整性”是困扰大家的两大问题，如果能把需求的这两个问题“完美地”处理好，那需求的其他属性/特性的满足及实现都是水到渠成的事。

E-GAS监控架构作为汽车功能安全领域的经典设计，采用三层架构模式：功能层实现控制逻辑，功能监控层校验功能正确性，控制器监控层确保硬件可靠性。该架构通过扭矩连续性和加速度比对原则，有效预防非预期加速等危险场景。第三层监控结合芯片内置机制与外部独立监控模块，实现处理器运行状态的双重保障。文中对比了MooN(D)架构与指定架构的异同，并探讨了E-GAS架构在fail-safe与fail-operati

​此篇我们来谈谈《功能安全的架构设计（一）》一文中提到的另一种架构概念——指定架构(designated architecture), 看看这种架构概念和MooN(D), fail-safe及fail-operational这些架构概念又有什么区别与联系。​

需求是产品开发工作的主线，产品整个生命周期各个阶段的工作都有需求的影子，所以能把各个阶段的需求整明白、写清楚、实现好、验证全，这侧面反映了组织具备了一定的成熟度，这种情况下整个功能安全管理工作的质量差不到哪去。

要完整地证明产品实现了安全目标的要求，除了认可措施外, 还需进行验证评审，两者在关注对象和目标上有一些差异。GB/T34590—2017的其他部分也要求这些评审, 目的是验证相关的工作成果满足项目的要求, 以及与应用案例和失效模式相关的技术要求。Q: 想想在日常工作中你有用过哪些验证评审的方法？怎么称呼这种验证评审方法？

​本篇开始来我们谈谈功能安全的架构设计和常规的功能性架构设计有什么不一样，系统架构和软硬件架构又有什么区别和联系，尤其是和硬件架构。一提到安全架构设计大家可能就会想到E-GAS，fail-safe , fail-operational，MooN，Designated architecture等概念，这些概念对应的架构有什么区别与联系？有没有针对不同ASIL的一些指定架构？