vs code ipynb文件_汽车面向服务（SOA）架构 VS 功能安全 思考

汽车面向服务（SOA）架构 vs 功能安全 思考

毫无疑问，面向服务（SOA）是未来汽车架构发展的方向，而且（到今天为止）欧美头部主机厂已经在最新一代EE平台中落地。

SOA介绍

网上已经有资料，我就不在重复了。（除非，有朋友让我写）。

你经常听到的SOA好处

• 软件与硬件解绑。现在的主流主机厂都流行用自己的独立的软件开发外包Tier-1。
• 抽象为服务后，接口的定义清晰，软件开发更便捷。
• 功能分解为服务之后，新类型的Tier-1融入行业供应链更方便。这类型的Tier-1一般提供软件IP。
• 服务提供方和使用方不需要知道对方所运行的宿主。主机厂可选择在集成时静态配置或者用动态Service Discovery。
• 各个服务可以由不同团队独立开发。
• 符合持续部署（CI/CD）概念，运行快速部署新的功能（比OTA传统EE架构简单得多）。

功能安全问题

可是一直困扰我很久的问题是，如何将SOA带来的系统动态行为和传统功能安全静态本质结合。

传统功能安全设计，从主机厂的整车功能安全分解到各个节点，各个节点又分解到软硬件。我比较熟悉的软件团队又会分解到不同层面的组件。功能安全专家在设计阶段对安全场景做了危害分析(Hazard Analysis)之后，得出的功能的安全设计强调的都是软件组件设计尽量要静态。

那么，怎么在这个静态的环境里，安全得，动态部署新的功能呢？

自适应AUTOSAR目前没有这方面的定义。

思路

除了Service Interface定义了服务的行为，引入功能安全配置文件（是的，在已经一堆的AUTOSAR配置文件之外，又一个新的）。

这个功能安全配置文件里包含：功能安全团队指定所有可能的安全属性。这部分工作由功能安全团队在设计阶段完成。

在系统运行性，服务的提供方和使用方在建立连接时便可以检查，比如服务提供方提供的数据的可靠性等等。

与外部系统功能安全统一

处理车内服务与服务之间实现功能安全。在车外到车内的服务也能实现功能安全的衔接。

案例：基于V2X的紧急刹车

SOP阶段，只实现了前向碰撞预警。也是说V2X作为服务提供方，提供与前车的距离作为服务。HU HMI作为服务使用方在HMI上显示预警。整个服务安全等级为QM。

到V2X二期需要通过OTA加入紧急刹车功能时，按照功能安全团队的功能分解：

• V2X ECU需满足ASIL-B
• Brake ECU需满足ASIL-D
• HMI QM

在V2X这个服务提供方，它从外部收到的V2X消息，这里V2X的CAM消息里需要加入“安全容器”。

安全容器里可指定：

• ASIL等级
• 可信度（95%, 99%, …）
• 精确度

那么当V2X服务提供方和两个服务使用方Brake和HU建立连接时，除了提供距离值之外，可将安全容器里的参数暴露给刹车模块。