高级驾驶辅助系统以及未来的完全自动驾驶系统在不断变化的驾驶环境下独立运行,导致复杂程度不断提高。对车辆E/E架构的需求不断增长,为实现高度复杂的计算密集型车辆功能,促使从独立ECU逐渐转变成多层架构。在这种情况下,遵循功能安全(ISO 26262)和预期功能安全标准至关重要。

为保持系统协同并证明产品开发中没有不合理的风险,汽车行业受到诸多法规和标准约束。

由于智能环境传感器的出现和复杂的因果链,新系统的验证正在经历转变。显然,整个验证流程的工作流在显著增加。不仅要增加测试数量,还有全面了解开发和V&V(验证和确认)流程。数据驱动的开发和虚拟测试方式的紧密结合是开发可靠系统的支柱,它们可以让开发人员能够可靠、高效地完成认证过程。

这就需要一项合适的全面的测试策略,以仿真为核心元素,在仿真中持续重复使用测量数据——不仅要验证正在开发的系统,还要确保虚拟测试方法能够实现其目标。仿真不仅仅是一个高效的开发工具。它也是进行系统协同所必不可少的,便于全面验证已知风险以及在尚未了解的驾驶场景中验证新的危险,从而证明没有不合理的风险。

如何证明系统足够安全呢?
图1:安全、保障和流程的相互作用。

如何证明系统足够安全呢?

在开发过程中,必须考虑各种标准和法规所构成的框架条件。本着预防的原则,汽车制造商必须符合(功能)安全、网络安全标准和各项流程要求,证明在车辆上路之前,他们已经采取了所有必要的措施尽量确保系统的安全性。此外,安全性的论据基于积极平衡风险的理念,即被测系统(SUT)能够证明其性能至少与全神贯注的驾驶员一样表现出色,方可上路。

ISO 26262和SOTIF(ISO 21448)解决了安全方面的问题。ISO 26262确保不存在系统故障造成的不合理风险。其中包括零星的硬件故障和系统级的技术错误。

安全关键型应用必须确保环境的完整性。ISO 26262并没有考虑到真实用例和系统的特定操作条件(运行设计域 - ODD)对驾驶功能的制约。举个例子,如果所开发的系统带有摄像头传感器,从技术角度来看,传感器技术可能会正常运作,但在某个场景中它却无法检测到对象。鉴于真实用例和可能的误用情况,ISO 21448——预期功能安全标准应运而生,该标准对ISO 26262进行了补充。

场景何时会变得有危险?

系统及其功能设计用于特定用例,从而应对多种场景。这些场景包含的触发因素可能会限制功能,从而引发危险的行为。

图2:潜在危险场景带来的连锁效应(简化版)。

随着自动化程度的提高,这些触发因素日益复杂和难以识别。SOTIF包括一项风险评估,对可能在现实生活中引发危险的场景进行评估。此外,它还考虑到了场景变得危险的可能性。场景有四类:

  • 第1类:已知的安全场景
  • 第2类:已知的不安全场景
  • 第3类:未知的不安全场景
  • 第4类:未知的安全场景

图3:SOTIF中的验证和确认

SOTIF活动旨在系统地识别和反复评估潜在的不安全场景(第2类和第3类)。未知的不安全场景(第2类)通过将合适的测试环境和测试方法相结合来评估,例如基于需求的测试(验证)。再通过系统设计中的技术措施,降低残余风险,达到积极平衡风险的正向调整,然后重新评估,从而提供安全性证据来证明该场景造成的剩余风险足够低。未知的不安全场景通过仿真和虚拟测试程序来识别,例如基于场景的测试(验证)。随后,确认已知的不安全风险。

这样就减少第2类和第3类的残余风险,已知的安全场景随之增加,从而提高实现SOTIF的把握。

验证预期行为

开发符合法律和技术要求的ADAS/AD功能最佳实践程序,要依据ASAM测试规范研究小组报告。考虑到特定用例,测试矩阵中列出了合适的测试方法和环境。

根据ASAM测试矩阵,已知不安全场景的一种测试方法是在软件在环仿真中进行基于要求的测试。这些场景根据验收标准,对系统必须在哪些条件下安全运行提出了要求。测试规范正是根据这些要求制定的。其中包括场景、测试用例和参数的规范。

在软件在环仿真中,虚拟ECU集成到基于PC的仿真平台中。这样就可以用基于要求的测试来验证系统对预定义场景的响应。此外,基于要求的测试提供了一个工具,该工具可以评估系统设计中的技术措施的有效性。

验证未知风险
图4:降低未知风险。

验证未知风险

验证的总体目标是降低ODD中的未知风险。其中一个可能的方法就是在软件在环仿真环境中进行基于场景的测试。
就积极平衡风险而言,基于场景的测试是将被测系统与人类的行为进行对比。将真实数据集成到验证流程,便可生成代表虚拟环境的抽象场景。随后,用抽象场景生成合乎逻辑的特定场景进行仿真。还可以将车辆和地图资料接口可视化,集成到测试设置中。

智能测控随机扫描参数空间,从而识别潜在的危险场景。同时,利用实际驾驶数据评估测试结果在操作设计域(ODD)中的代表性。从而,不断识别和减少未知风险,提高系统的整体安全性。

结论——理想的V&V流程是怎样的?

要制定有效的V&V策略,必须确定SOTIF的总体目标:

  1. 验证目标是什么?
  2. 如何识别和评估触发事件及功能不全问题?
  3. 潜在危险场景的评估是否充分?
  4. 是否充分涵盖了相关场景?
  5. 所提供的证据支持哪些方法?
  6. 是否选择了合适的验证和确认方法?

这些问题并没有一个标准答案。相反,对于相应的SUT,回答这些问题时要考虑到测试目标,并在一定测试水平上将所选测试环境和测试方法相结合。

必须系统地识别和评估危险行为带来的风险。随着自动化水平的提高,识别和评估导致潜在危险行为的条件(触发因素)也变得越来越复杂,需要结合多种分析技术和真实道路测试来识别危险场景。例如,检验系统中的潜在触发因素的影响的一种方法是进行系统弱点分析。在该过程中,会对所识别的各个系统因素以及相关功能不全和触发因素进行风险分析,从而制定改进SOTIF的措施,再测试这些措施的有效性,并以适当的理由评估残余风险。

此外,总体发布策略需要融合SOTIF验证和确认流程。

将上述因素考虑进来,可以提供一个SOTIF发布论据,最好在数字系统协同流程中实现。这为处理复杂自动系统以应对不断变化的驾驶环境的流程奠定了理论基础。

dSPACE咨询服务部根据ISO 26262和ISO/PAS 21448,提供专业风险分析,针对基于场景和基于要求的设计,帮助开发测试策略,将它们无缝集成到已有的开发流程中。

2024年2月发布

作者

Nora Harlammert

Nora Harlammert

dSPACE顾问

Jann-Eve Stavesand

Jann-Eve Stavesand

dSPACE咨询服务部总监

Further Information

  • ISO 26262
    ISO 26262

    dSPACE通过完全认证的工具链和咨询服务,支持符合ISO 26262标准的汽车行业开发流程。

  • ISO/PAS 21448 SOTIF
    ISO/PAS 21448 SOTIF

    dSPACE提供咨询服务,用于定义符合SOTIF标准的方法,并将其实现为流程、方法、工具以及确认和验证标准。

  • Blueprint for Testing Software-defined and Automated Vehicles
    Blueprint for Testing Software-defined and Automated Vehicles

    To provide traceable and verifiable safety arguments for software-centric vehicles, testing, verification and validation must be managed, defined and evaluated holistically.

Contact Information

  • dSPACE咨询服务部
    dSPACE咨询服务部

    为所有开发阶段和ECU软件的验证创建理想的流程

推动创新进程。我们始终在技术开发的最前沿。

欢迎订阅我们简讯,了解我们的专业技术以及产品。希望我们的成功案例能够对您有所帮助。快速了解仿真和验证的最新信息。欢迎订阅/管理dSPACE简讯和dSPACE航空速报。

Enable form call

At this point, an input form from Click Dimensions is integrated. This enables us to process your newsletter subscription. The form is currently hidden due to your privacy settings for our website.

External input form

By activating the input form, you consent to personal data being transmitted to Click Dimensions within the EU, in the USA, Canada or Australia. More on this in our privacy policy.