汽车软件开发中的功能安全挑战与应对策略：基于Jira平台构建端到端的可追溯性，实现精细化需求管理

2024年7月18-19日，龙智携汽车软件开发及管理解决方案创新亮相2024 ATC汽车软件与安全技术周。龙智技术支持部负责人&Atlassian认证专家叶燕秀、龙智功能安全高级工程师景玉鑫在活动主会场联合发表了精彩演讲，分享推动汽车软件开发与功能安全的创新实践。

本期，龙智技术支持部负责人&Atlassian认证专家叶燕秀，将分享如何应对汽车行业的功能安全挑战，以及如何借助先进的项目管理平台Jira，实现精细化需求管理等方面的经验与见解。

以下为演讲实录（内容有精简润色）。

---

大家好，我是叶燕秀，我与我的同事景玉鑫一同来自上海龙智数码科技股份有限公司。龙智已深耕DevSecOps领域超过十年，我们与众多产品生命周期管理解决方案的国际知名公司保持着深度的合作关系，提供从产品规划与需求管理、开发，到测试、部署以及运维全生命周期的解决方案与管理工具。迄今为止，我们已经为包括汽车行业在内的多个行业的上千家客户，提供了专业的咨询、实施、培训、运维以及二次开发等全方位服务。

功能安全挑战

首先，我们来探讨一下当前汽车行业所面临的功能安全挑战。

为什么要强调功能安全？

随着汽车信息化，特别是智能化与电动化趋势的加速，汽车正逐渐从传统的机械产品转变为高度电子化的产品。为了满足并不断提升用户对汽车功能和用户体验的需求，车辆上安装的控制器数量日益增多。目前，中高档车辆上的控制器数量已高达40至50多个，车辆出厂时就配备了数千万行的代码，来负责管理发动机、变速器控制、制动转向以及各子系统的大量诊断信息。对于有人驾驶的车辆而言，这已是庞大的系统。而针对自动驾驶车辆，其代码量更是有可能突破数十亿行。

汽车电子部件的数量与复杂度的增加，更是会大大提升电子失效的风险，特别是底盘、动力等关键部件一旦失效，比如刹车、转向失灵，都将会造成极其严重的后果。

这也是为什么现在仅仅针对汽车的物理部件，来满足各项标准已经远远不够了。在汽车设计的系统、软硬件层面，我们同样需要解决安全问题，确保功能安全，以应对日益复杂的汽车电子化趋势。

功能安全标准

鉴于汽车对软件的依赖性日益增加，国际标准化组织（ISO）于2011年发布了ISO 26262标准，并在2018年发布了更新版本，来作为汽车行业系统及设备所有软件的详细的行业指南。

那么，我们为什么需要针对汽车行业制定一份专门的标准呢？

这是由汽车工业的独特特点决定的。汽车是大众消费市场中单价最高的大规模量产产品，其所有的确认工作都必须在量产之前，即所谓的SOP（Start of Production）之前完成。这意味着汽车的开发和验证过程必须做到完整且充分，以确保产品的安全性和可靠性。这一要求与工业产品以及其他消费类电子产品存在着显著差异。

因此，针对汽车行业专门制定一份标准尤为重要。ISO 26262标准的出台，为汽车行业提供了明确的指导，帮助汽车制造商在设计和开发过程中充分考虑功能安全要求，降低电子失效风险，确保汽车产品的安全性和可靠性。

那么如何降低风险呢？

我们需要认识到，风险与安全是相对的概念，我们是无法完全消除风险的，但可以通过一系列措施将其降低至合理的范围内。在功能安全领域，为了评估风险并确定其合理度，我们引入了“Automotive Safety Integrity Level”（ASIL）这一标准。

在功能安全的概念阶段，最重要的工作就是危害分析与风险评估。只有通过深入分析，我们识别出潜在的危险，才能为后续的功能安全开发工作奠定基础。危害分析与风险评估的过程需要结合整车的功能，在不同应用场景下假设失效情况，以评估可能存在的危险。

为了全面评估风险，我们通常会结合整车功能的失效模式、运行场景等因素，构建出可能的危险场景。然后从严重度、暴露率和可控性三个维度对风险进行量化评估。其中，严重度越高、暴露率越高、可控性越小，意味着风险越高，ASIL等级也会更高，后续的安全开发工作也需要更加严格。

那么我们如何实现功能安全呢？

下面这张图总结了功能安全的实现原理。

首先，我们会去识别失效的模式及其潜在影响，然后采取一定的纠正措施以避免失效，最终通过验证与确认来评估措施的有效性。若效果未达预期，就需要进行多次的完善与迭代。基于这样的思路，功能安全标准整理确立了一套完整的功能安全开发流程，为了保障流程被正确实施，我们同时还需要在管理流程、需求设计和工具层面上辅以支持。

功能安全开发过程

上图是对于功能安全开发过程的整理，涵盖了需求、设计、验证与确认三个层面，每个层面在不同的阶段均有不同的实施活动。在概念阶段，就是从用户需求出发，我们产生一个想法，提出一个功能定义，这个通常是整车功能层面的一个应用设计，对于功能安全来说就是定义一个研究对象和功能，进行风险分析，定义安全目标、功能安全概念等。要实现这些想法，就需要工程人员进行产品的开发，包括系统开发、软硬件开发，以及验证和测试等。

对于生产维护，主要是实施在开发阶段识别出的可能影响功能安全的特性及保障措施，比如制定生产保障的计划、流程，提供相应保障的证据等等。

需求管理贯穿功能安全流程

贯穿整个功能安全开发流程的主线，就是需求。

随着产品的开发，需求从概念阶段一直传递到系统阶段和软硬件阶段。概念阶段即是安全目标、功能安全需求；系统阶段即是技术安全需求；软件阶段即是软件安全需求；硬件阶段也就是硬件安全需求。

功能安全需求是针对安全目标，并结合整车的系统架构所制定的需求。我们所有的开发工作都是围绕满足这些需求展开，最终通过验证与确认来实现功能安全。

精细化需求管理

对于这样一个功能安全的过程与流程，我们无法完全依赖传统的Office办公软件或Checklist检查项清单来进行有效的管理和跟踪。而是需要更加专业、灵活的工具平台，来帮助有效地管理相关需求，例如Jira Software这一数据驱动的产品开发平台。

以数据驱动的产品开发平台

以往，我们通常将需求记录在Word文档中，这些文档可能包含成百上千条的需求。而“以数据驱动的管理方式”则是将每一条需求、每一个相关联的测试用例、风险项、缺陷项都独立拆分出来，作为单独的条目进行管理。通过这种条目式的管理，我们能够针对具体需求进行版本控制，跟踪其变更历史，并收集针对该条需求的反馈信息。同时，我们还可以通过需求中定义的关键属性（如ASIL等级），来快速过滤和检索需求，以及生成对应的需求风险分析报告。

有了这样的工具平台，我们也无需手动在文档中维护大量的需求ID，或者追溯上下游的需求链接，而是可以更方便地在平台上实现追溯。在评审效率方面，我们可以专注在少量的迭代式的需求评审，而无需在等待整个需求文档提交后，才能提供相关的反馈信息。

整个V模型的端到端可追溯性

不管是ASPICE还是ISO 26262，都强调了V模型。

我们可以借助Jira平台来建立端到端的可追溯性，快速识别系统、子系统及其具体需求，并分析需求如何被拆分为更详细的规格：例如用户需求包含了哪些系统需求？系统需求又拆分为哪些软硬件需求？相关的架构设计是什么？若需要验证需求，关联的测试用例有哪些？测试结果是什么？等等。

当需求发生变更时，Jira平台也能方便地进行影响分析，了解识别该项变更对上下游需求和测试的连锁反应，通过完整的追溯关系来保障我们的产品质量，改进变更管理流程。此外，借助V模型端到端的完整追溯链，我们也可以通过追溯报表，快速识别未被覆盖的需求或设计，及时进行调整和修正。

集成风险管理，简化合规流程

同时，我们可以通过Jira平台集成风险管理，简化合规流程。

Jira平台支持多种风险评估方法。对于前面提到的一些关键风险值，比如ASIL等级，它可以根据该项需求的严重度、暴露率、可控性等参数，自动进行计算和呈现风险。通过将风险管理集成至统一平台，我们可以在整个产品开发过程中，定期执行风险分析，并生成对应的分析报表。

将需求与测试用例及其结果链接来提高质量

正如我们前面介绍到的，在汽车行业中，量产前一定要进行完整、充分的功能验证。通过Jira平台，我们可以将验证用例与需求直接关联，记录执行结果，以确保产品质量。若在测试过程中发现缺陷，也可以一键提交缺陷，并与相关的用例、步骤、需求相关联，实现缺陷的统一分配、处理和进度跟踪。

与传统管理方式不同，通过采用一套专业的管理平台Jira，我们能够实现内部垂直团队之间的紧密合作，同时加强与客户及供应链的外部协作。这种合作机制有助于我们消除开发过程中的冲突，确保项目的顺利进行。此外，Jira平台还能帮助我们收集合规所需的大量细节，如团队遵循流程的证据，从而助力顺利通过ASPICE评估认证，或满足ISO 26262提出的功能安全要求。

当前正处于AI时代，Jira管理平台也集成了多种AI智能化和自动化功能，帮助提升工作效率。借助这一专业平台，我们能够实现精细化的需求管理，通过将重复性、低效的工作交给AI工具处理，而拥有更多的时间专注于创新和优化产品。

审核编辑 黄宇