如何利用汽车软件开发标准来降低风险

   当非专业工程师客户们想起汽车电子系统时,他们很可能想到集成的GPS、娱乐信息节目和一些可能有的用车载电脑来控制一些汽车安全特性的模糊的概念。当然,现实情况是,随着软件在包括关键安全性能的各方面汽车功能中发挥越来越重要的作用,现代汽车系统已经明显的更加复杂了。

    事实上,几十年来汽车一直在关键功能上使用着电子系统,并且,像“物联网”的推进这样的市场变化已经推动汽车制造商在可行性范围内植入更大数量的复杂电脑系统。

    与系统开发相关的业务结构和供应链进一步增加了现代汽车系统的复杂性。虽然一个制造商的工程师从头开始设计和构建汽车中所有的组件和子系统的情况很少见,但如果它发生了,将会导致潜在的集成问题。传动装置可能取自这个模型,一个好的刹车系统可能来自另一个模型,尽管它们在原来的环境中工作起来效果良好,但它们在一个全新的系统里很可能产生意想不到的、不愿看到的结果。因此,汽车软件常常是一个可能也可能没有被充分测试的复杂的大杂烩系统。采用在大杂烩系统中添加的方式实现组件而不经过适当的测试,代价将会非常巨大,尤其是在安全相关的应用程序方面。

    尽管如此,好的一方面是,用许多广为人知的实践,通过在开发过程中健壮软件的质量来帮助制造商降低失败的风险。在这篇文章中,我们将会讨论一些导致汽车软件复杂性的问题以及和汽车软件开发相关的风险。我们还将讨论如何实现开发最佳实践,如ISO 26262,帮助企业缓解这些风险。

更多的代码注入更多的风险吗?

    据估计,一个标准的中档车可能有超过一百个的电子控制单元(ECU),来处理数百万行代码——这一数字仍在不断增加。一个供应商有几个型号的汽车有超过一亿行代码也不足为奇。

    有一种看法是越昂贵的汽车植入的软件越多,并且其中的大部分软件是高端娱乐信息组件。随着你对产品线的提升,这些系统确实变得越来越复杂,甚至汽车生产线也使用软件来控制操纵、刹车系统和电力分配等等。甚至看似微小的特性变化,如蓝牙、气候控制、恒速操纵器等,也会导致代码指数增长。

    我们可以假定,更多的代码转化为更多的复杂性,因此也导致更多的风险,但未必造成重大的影响。导致汽车软件相关商业风险的一个重大原因是开发自跨越多个层的各种源的集成。包括基于ECU组件等的大部分组件都分包给了二层供应商,二层供应商又分包给第三层供应商,如此延续多层。每一个之前的层都对他们开发的组件有特定的要求。企业经常(并不总是)实践分析传入的代码来确保组件实现期望的功能。

   但是这就假设沿着供应链的每一个组件都是新开发的,事实上,下游层的代码编写常常为特定的构造、模型和年等而分支。代码的突变和复用发生在供应链中,这将导致测试问题。在如此混沌的一个软件开发生态系统中,制造商如何实现端对端测试呢?当方向盘的ECU是针对一辆汽车设计的而仪表盘的ECU是针对另一辆汽车设计的,并且这两辆汽车都不是目前嵌入的汽车,这将会有什么影响呢?你怎么确保完成预期的系统功能?完全可能在两个系统中都能通过功能测试,但却不能在所有的情况下都正常通信。这种差距的风险是什么?

软件质量的成本

    当公司试图衡量软件开发的成本时,他们倾向于看一般指标:工程师开发时间;QA测试时间;获得工具许可证、编译器和其他基础组件形式的构建材料。这些都是重要的指标,但经常被忽略,就是失败的成本。

    如果制动系统的软件失败了,返工、召回、审计、诉讼和损失的股票价值的成本是多少呢?如果有人员伤亡呢?我们认为质量成本是开发和测试软件的成本,包括所有我们确认的正常指标加上与实际操作中失败相关的有形成本。

    不合格的产品花费汽车制造商许多钱。国家公路交通安全管理局估计,汽车行业的召回和维修每年大约花费制造商30亿美元。就软件问题相关的成本而言,IEEE2005年估计,汽车制造商每年每辆车的花费大约为350美元。当考虑到汽车行业的低利润空间时,可以想象,一个足够严肃的软件的问题对这个行业的挫伤是极其严重的。

    底线是重要的,但更重要的是,人们可能因为软件缺陷而亡或者严重的受伤。不管供应链有多长,软件缺陷的起源有多么复杂,软件缺陷及其相关的后果都将成为汽车制造商的责任。因此,任何软件开发相关的成本分析都需要考虑潜在失败的成本。

软件开发的现状

    我们已经论证了汽车软件分层供应链的复杂性导致了与关键安全性系统相关的整体风险。我们还重申了汽车行业的潜在成本。但驻留在工程和软件开发之间的文化差异,是这个问题的另一个维度。

    软件开发几乎从来不是工程。然而一些从工程而来的原则和概念,如重复性,训练有素的最佳实践、对构建标准的依赖等已经在软件开发领域牢固树立。此外,对软件开发人员的培训可能前后矛盾——甚至根本不存在——公司需要一个相当长的时间来确定他们的开发人员是否具有足够的知识来开发关键的安全性软件。

    这与工程方面形成了鲜明的对比。相对于软件开发而言,工程的态度,心态和历史的训练确保其实施过程不容易出现缺陷。这不是说,工程师们知道自己在做什么而软件开发人员不知道。相反,它是说,工程领域远比软件开发领域成熟,软件的无形性和暂时性保持了一个散漫的态度,如果它成功了,那么就完成了。

    软件开发的重点在与更快的交付和功能性要求——我们能多块实现这个功能?几乎没有管理方面的激励来将良好的工程实践应用到软件开发的生命周期中。实现软件的功能安全需要特定的工程实施原则:

1. 功能安全必须具有前瞻性;

2. 过程必须可控、可测量、可重复;

3. 通过实施标准阻止缺陷的产生;

4. 测试必须是有效的和决定性的;

5. 应该为复杂的存储问题做测试;

    好消息是对于软件开发的态度正在转好。26262、MISRA和其他标准试图通过提供在软件开发过程中实施工程概念的基础来规范汽车应用的开发。一些公司把遵从ISO 26262和其他的标准视为没有任何直接价值的顶层负担,但事实是,软件缺陷相关的失败成本比保证软件质量的成本要高得多。就像在电气标准中,指定一个特定的规线携带一个特定电压一样,编码标准能够提供避免灾难性错误的指导。

    26262、MISRA和其他标准试图通过提供在软件开发过程中实施工程概念的基础来规范汽车应用的开发。一些公司把遵从ISO 26262和其他的标准视为没有任何直接价值的顶层负担,但事实是,软件缺陷相关的失败成本比保证软件质量的成本要高得多。

在Embedded Computing Design阅读《利用汽车软件开发标准来降低风险》的第二部分来了解如下内容:

a. 什么是ISO26262?为什么我要关心它?

b. 什么是MISRA?

c. 如何实现ISO26262和MISRA?

 

Parasoft 被誉为应用程序自动化功能测试领域的领导者

    我们非常高兴地宣布,Parasoft在最新版Forrester自动化功能测试工具调查报告*中已经被列为领导者。由于在为开发者提供便利、API测试和升级静态分析方面成效显著,Parasoft在Forrester调查报告中获得了所有供应商中的最高分。

1

    该报告指出,“Parasoft拥有最强大的持续性测试产品,在UI自动化和复杂的功能性API自动测试方面打造出了一系列成熟可靠的产品性能,同时还提供了第三方CI/CD工具集成、版本控制选择、敏捷开发管理的集成以及诸如集成性安全测试等自动化非功能测试。这些特点大大提高了Parasoft产品的实际性能,配合服务虚拟化工具,Parasoft的解决方案就变得非常出色了。我们在针对产品可维护性、再利用能力和报告分析能力等方面的评估也表明,Parasoft的解决方案相当出众”。

    Forrester根据33项标准,评估了11个著名的自动化功能测试工具的供应商,最终形成的这项报告,其目的是为了帮助在企业、移动设备和网页应用方面孜孜不倦进行开发的公司组织选择适合自己的测试工具。

   “Forrester的调查报告为所有功能测试解决方案提供了一个客观的基准,我们非常荣幸能够被评选为其中的领导者。” Parasoft的首席市场官Marc Brown说,“我们相信这次的报告彰显了Parasoft对于提高自动化功能测试的承诺,在保证软件质量和安全的同时寻求加速软件开发交付的流程的公司组织们会在Parasoft的努力中看到巨大的价值!” 

   Forrester公司强调了API测试对现代应用程序交付的重要性:“超越UI和测试API对于健壮测试套件和增加覆盖率来说都是至关重要的。仅仅关注测试执行的自动化无法实现真正可靠的自动化测试,我们还需要完善测试的设计和编排。”

 *弗雷斯特研究公司(Forrester Research), Inc., "The Forrester Wave™: 现代应用程序自动化测试工具, Q4 2016," December  5, 2016.