软件定义汽车将需要多种机制,保证汽车在各种情况下的安全和正常行驶。这些机制的专有解决方案需要大量的验证工作,并且很难与不同的软件架构集成。安全关键型分布式通信是否有标准化软件框架?
多年来,传统车身系统中执行分立功能的电子控制单元(ECU)数量一直在增加,这些单元的可编程性较弱。然而,目前先进的汽车设计开始有所转变,逐步转向只分布在几个(域)处理器上的灵活且可互操作的软件。分布式软件执行自动驾驶、娱乐中控、动力和车身控制等协调任务,同时共享处理器、网络和传感器,能够降低系统成本。转向软件定义汽车是汽车行业最重要的趋势之一,软件功能将成为重要的差异化优势。
要在这个领域赢得竞争,汽车制造商需实现快速轻松构建模块化分布式应用,而运行这些应用需要可编程、可靠且低成本的半导体设备。因此,具有易于使用的应用编程接口(API)的标准化软件平台(如 POSIX 和AUTOSAR )日益受到欢迎。这些软件平台的一个关键组件是中间件,它是各种操作系统和高级应用之间的软件层(见下图)。简单地说,中间件是一个软件库,它使分布式系统组件能够相互通信。软件定义汽车的安全性在很大程度上取决于中间件和底层网络处理器,依靠这两者才能实现分布式进程之间的可靠的实时数据通信。
一流的自动驾驶(AD)系统通常采用双通道架构来实现冗余,即在正常情况下控制AD系统的主通道旁边部署备用通道。如果主通道出现故障,汽车控制将切换回备用通道。这样能够同时提高AD系统的安全性和可用性。这种架构需要一个安全检查工具来验证主通道的运行状态,并在必要时触发安全机制,如安全停车。显然,安全检查工具的计算和通信功能非常关键,这对其容错和可靠性提出了很高的要求。
恩智浦S32G汽车网络处理器非常适合执行具有各种安全机制的高度可靠的AD系统。S32G中的Arm® Cortex®-A53内核提供高性能计算能力,ASIL D Cortex-M7安全内核适合在锁步模式下运行安全关键型功能。此外,面向服务型网关的S32G GoldBox参考设计上集成的SJA1110以太网交换机提供了时间敏感网络(TSN)功能,可与网络上分布的高级AD应用进行实时可靠的通信。
除了完整性较高的硬件外,在S32G中的Cortex-A53和Cortex-M7内核上运行的数据分发服务(DDS) 中间件软件负责管理分布式系统的数据和通信。DDS中间件协议基于对象管理组织®(OMG)标准化的发布-订阅模式。DDS已集成到各种关键的汽车平台生态合作体系中,例如AUTOSAR Adaptive和ROS2。DDS提供低延迟数据连接、可靠性和可扩展的以数据为中心的通信。此外,DDS附带了一组丰富的内置服务质量(QoS)策略,可控制DDS行为,如资源消耗和通信可靠性。如需了解DDS的基本原理和QoS策略,可以尝试互动式Shape演示应用或观看演示视频。
请注意,面向资源极度受限环境的DDS通过使用OMG DDS-XRCE协议 实现。这是客户端到代理协议,意味着DDS-XRCE客户端节点通过外部代理节点与DDS网络通信。DDS-XRCE非常适合为物联网设备开发轻量级DDS应用,但在安全关键型系统中使用时,该代理可能会成为单点故障。然而,运行在S32G Cortex-M7上的RTI Connext®DDS Micro无需任何桥接或代理,可直接与功能齐全的DDS网络进行通信,从而消除了单点故障。ISO 26262汽车安全环境中也可构建集成RTI Connext DDS Micro,其安全等级最高可达ASIL D级。
以下是对实施冗余自动驾驶通道特别有意义的DDS QoS策略:
一旦DDS中间件层就绪,就可以使用DDS内置QoS策略。这简化了开发过程,极大地提高了软件组件的互操作性和可重用性。DDS分布有多种版本,可满足分布式AD组件的不同系统要求。在分布式AD系统中实施DDS既设立了一个通用的通信和数据管理框架,也毫不费力地增加了系统多样性。此外,基于DDS构建的系统可以使用单个DDS XML文件轻松建模和配置。XML文件格式使系统开发更加容易,可帮助架构师和应用开发人员在系统层面设计软件定义汽车。
如果组合得当,DDS QoS策略可启用各种故障处理机制和安全措施,应对性能限制。DDS中间件层为在其上运行的所有AD组件设立了一个通用框架。无需太多工程工作即可实现不同规模的各种安全机制,例如故障切换到完全冗余的AD通道或组件的无缝接管。下面我们将详细介绍在我们的概念验证演示设置中实现的安全机制。
故障切换是安全关键型系统中广泛使用的安全机制。它通常依赖故障静默组件,这些组件在发生故障时停止产生输出。通常,当主AD通道静默发生故障时,系统应退回到冗余安全通道,操纵汽车进入安全状态。该机制可以使用DDS活跃度和所有权QoS策略来实现。如果主通道中的汽车控制数据写入器发生静默故障或失去与系统其余部分的通信,那么由所有权强度较低的安全通道的数据写入器生成的样本将自动对汽车执行器可见,并开始无缝控制车辆。同时,使用安全检查工具来监测由于数据写入器故障而导致的DDS网络活跃度变化。系统可以根据此类诊断信息实施恢复机制,例如重启。
即使发生故障的AD组件不是故障静默的,系统也可以实施接管安全机制,在不影响系统可用性的情况下主动否决故障或不可靠的组件。可以使用DDS独占所有权和所有权强度QoS策略来实现接管。这些QoS策略控制允许哪个数据写入器向数据读取器发送数据。当安全检查工具检测到主数据写入器未正常运行(例如错过截止日期或发送越界数据)时,会触发所有权强度更高的健康数据写入器将数据发送到数据读取器。
DDS截止日期、活跃度、独占所有权和所有权强度可以结合在一起,实现同时利用故障切换和接管机制的混合机制。例如,通过监测DDS网络的活跃度,安全检查工具可以在节点静默故障时灵活地触发故障切换机制,或者在运行的节点未故障静默并发布错误数据或错过截止日期时激活接管机制。由于所有权强度QoS值不同,系统在主通道和安全通道之间无缝切换时,也可以轻松处理系统中的过渡故障。
为了在真实环境中评估我们基于DDS的S32G安全机制,恩智浦与RTI(Real-Time Innovations)公司的汽车工程专家团队合作。RTI是一家领先的自动驾驶系统软件框架提供商,经营名为Connext DDS的DDS产品和工具组合。我们携手将恩智浦安全检查工具集成到基于Auoware.Auto的自动代客停车(AVP)演示中,Auoware.Auto是Autware基金会的一个开源项目。该演示展示了汽车如何自动驶入代客停车场。Autoware.Auto是一个基于ROS2的成熟的端到端自动驾驶框架,它使用DDS作为底层中间件。
我们的硬件在环评估演示设置的架构如下图所示:
在评估设置中,我们将类似于现实问题的故障注入AD系统,并观察基于DDS的安全机制如何处理这种情况。下面的演示视频展示了我们的安全检查工具是如何监测、检测和应对系统故障的,如软件崩溃、掉电和网络连接中断。
为了顺应向软件定义汽车转变的发展趋势,汽车系统软件需要模块化、可靠和可扩展。正如我们的Autoware.Auto AVP实验所示,恩智浦S32G ASIL D Cortex-M7处理器内核能够很好地在自动驾驶系统中充当安全检查工具。RTI Connext DDS中间件为整个汽车系统的强大处理器和资源受限的微控制器提供了一个通信框架,从而促进了这一进程。DDS凭借其丰富的服务质量策略,在软件定义汽车中实现了多种安全机制,其工程工作量低,互操作性强。
Jochen Seemann是荷兰恩智浦半导体的嵌入式软件架构师。他毕业于巴登-沃尔滕堡合作州立大学应用计算机科学专业,在工业PC接口全栈软件开发方面拥有5年经验。Jochen还担任过5年的汽车领域一级软件工程师和架构师,主要致力于IVI和自动驾驶产品的工作。此外,他还促进了开源Qt框架的开发。
Yuting Fu是荷兰恩智浦半导体公司的系统工程师。她拥有埃因霍温理工大学和柏林理工大学嵌入式系统硕士学位。Yuting编写了3本与自动驾驶系统车辆安全机制有关的科学出版物。此外,她还是经过认证的IEC 61508功能安全专家。
Andrei Terechko是荷兰恩智浦半导体公司的高级首席架构师。Andrei拥有15年跨国公司工作经验,10年初创公司工作经验。目前,他致力于自动驾驶的安全机制和架构工作。Andrei与他人合著了20多本国际出版物和公开演讲稿。
Emilio Guijarro是Real-Time Innovations (RTI)的高级汽车应用工程师,在国防和汽车行业(包括汽车娱乐中控系统)方面拥有超过15年的工作经验。他于2019年加入RTI,致力于将DDS集成到汽车用例和特定开发环境(包括AUTOSAR生态系统)。
2021年9月6日
2021年8月17日
2021年10月20日