SASETECH
建立安全生态圈，成为汽车安全的布道者
SASETECH
SASETECH第二十六场
线下沙龙成功举办
- SASETECH OFFLINE SALON -
SASETECH沙龙致力推动汽车安全领域的深度交流，建立安全从业人员的技术交流平台和精神家园，共同推动安全在行业内外的影响力，成为国内最具影响力的公益型汽车安全社区，推动自动驾驶、芯片产业正确发展。
活动回顾
2024年11月23日下午，SASETECH第二十六期沙龙在上海静安TUV-NORD成功举办，受到来自各个OEM和tire1同行和同事的热情报名，共20余位行业里资深专家们参加了本次分享活动。
01
开放会议空间
本次沙龙以“软件开发中的安全问题”为主题。来自联想车计算的严海亮，敛影科技的汤云卿老师以软件功能安全的开发与信息安全的融合为出发点，抛砖引玉，引导大家沉浸式对现有软件功能安全的开发进行讨论。
-SASETECH-
02
本期议题分享
Clause1：ECU功能安全和信息安全的 融合开发
功能安全与网络安全的融合开发。随着汽车智能化、网联化的快速发展，ECU的安全问题日益受到关注。
1. 基本概述：
功能安全与网络安全：功能安全主要关注系统自身的电子/电器系统失效问题，遵循国际标准ISO 26262；而网络安全则聚焦于外部因素，如黑客攻击等，遵循ISO/SAE 21434标准。两者共同构成了汽车安全的两大支柱。
威胁分析：在功能安全方面，我们面临的威胁包括汽车传感器、控制器或执行器的电子电器故障；在网络安全方面，车内通信、车载终端、车云交互和V2X信息交互都可能成为黑客攻击的目标。
融合开发必要性：随着汽车电子系统的复杂性增加，融合开不仅能够提升汽车的整体安全性，还能应对日益严峻的网络安全威胁。
融合策略与方法：主要通过三个步骤展开：架构融合设计（分层架构设计、分区架构设计）、协同开发流程（联合需求分析、同步设计与开发）和安全技术融合（安全通信与密钥管理融合、冗余设计与网络防御协同、联合测试与验证）。
分层架构设计：采用分层架构来融合功能安全和网络安全，对ECU进行物理和逻辑分区。
分区架构设计：在分区架构设计中，功能安全会区分功能安全和非功能安全分区，而网络安全会区分安全和非安全分区。
联合需求分析：共同开展需求分析工作，包括功能安全需求列表和网络安全需求列表的制定，如传感器故障检测和处理、安全状态切换、入侵检测、安全启动等。
同步设计与开发：联合设计系统架构、硬件电路和软件模块，制定全面的联合测试计划，并进行同步设计与开发。
联合测试与验证：进行功能安全测试和网络安全测试，确保融合后的系统满足安全要求。
安全通信与密钥管理融合：设计统一的安全通信机制，提升整体的抗风险能力，如CAN通信的E2E保护和SECOC等。
冗余设计与网络防御协同：进行冗余的通信网络设计，并加强通信接口的入侵检测，以提高系统的安全性和可靠性。
案例实践： 通过对主要安全流程和安全分区的设计开发，将分区和分层单独进行映射，以分层为例：针对功能层网络安全可以对通信的签名验签和隐私进行保护，类似功能安全功能层的通信监控，保证功能的正常进行。第二层通过功能监控层，结合安全存储、安全启动等协同开发，既能满足功能安全开发要求，同时也可以在基础服务层，实现对网络安全的要求。
针对功能安全和网络安全流程的协同进行，包括联合需求分析、同步设计开发等阶段。
在联合需求分析中，详细列出了功能安全需求列表和网络安全需求列表，如传感器故障检测和处理、安全状态切换等功能安全需求，以及入侵检测、安全启动等网络安全需求。
安全通信与密钥管理的融合，如CAN通信的E2E保护和SECOC等安全技术。
Clause2：基于软件架构的软件功能安全分析
1. 基础内容：
软件架构是指程序或计算系统的结构，包括软件组件、组件的外部可见属性以及它们之间的关系。
功能安全与非功能安全需求：软件架构设计不仅满足功能安全需求，也满足非安全需求，通常在同一开发过程中处理。
重要性：软件架构设计是软件功能安全开发流程中的关键活动，承接软件安全需求，分配到具体组件，并形成追溯关系，引导详细设计。
2. ISO26262软件开发流程及架构设计要求：
软件开发流程：ISO26262规定了软件开发流程，包括功能安全特有的开发活动、常规软件开发活动以及两者共有的活动。
架构设计原则：ISO26262对软件架构设计提出了多项原则，包括适宜的软件组件分层结构、限制组件规模与复杂度、限制接口规模、高内聚低耦合等。（Note：图中“红色框”代表功能安全特有的开发活动，“黄色框”代表常规软件开发会涉及到的开发活动，“绿色框”代表功能安全和常规软件都具有的开发活动）。
3. 软件架构安全分析及相关失效分析：
完成软件架构设计之后，需要进行有效的安全分析和相关失效分析，其作用是支持设计规范和设计验证活动，以保证当前设计的架构能够应对硬件问题和软件问题的风险和威胁。
● 安全分析的主要目的是验证软件架构设计的正确性和合理性，能够识别潜在的安全风险与漏洞，确保系统在实际运行中的安全性与稳定性，分析失效后果并发现设计缺陷；
● 相关失效分析主要是为了证明软件安全机制的有效性，证明软件层级ASIL分解的有效性以及实现软件组件之间的共存问题，这也是功能安全特有的软件开发活动。
相关失效分析：证明软件安全机制的有效性，ASIL分解的有效性，以及软件组件间的共存问题。
4. 软件安全分析SW-FMEA和软件相关失效分析SW-DFA：
SW-FMEA：软件安全分析SW-FMEA用于识别软件失效模式、原因和影响，以及减少其有害后果的方法，确保软件实现系统分配的安全需求。
进行FMEA分析时首先要确定软件系统的范围和边界，根据软件开发范围定义出对外接口，分析层面，在软件架构设计图中确定分析对象；然后对确定好的范围内软件架构图的结构进行分析，分析的最终对象是软件单元模块，明确软件单元模块和涉及到的软件组件和软件单元之间的关系，以及上下单元之间的关系，数据传递的关系，为功能分析奠定基础；功能分析主要是给架构图中个软件组件单元分配相关的功能，详细描述每个功能以及影响，将安全要求分配给子功能，用于后续失效影响分析；失效分析主要是对软件最底层的软件单元分析，找出所有可能的失效模式和失效原因，并生成一个失效链；风险分析是针对现有失效模式严重度的评估和安全机制评估，以及制定的预防控制措施的评估，为后边的优化奠定基础；优化主要是对当前分析对象中识别出未考虑安全措施并可能违反安全目标的故障时，应确定后续的改进和优化活动，例如设计新的安全措施以降低风险。还应该评估和验证这些改进和优化的有效性。注意，一旦确定了这些改进和优化要求，应通过变更过程更新设计要求，并根据更新的要求设计新的架构，直到分析对象的所有可能违反安全目标的故障都被考虑并采取相应的安全措施，并有效降低风险和影响。
分析流程：包括确定软件系统范围、功能分析、失效分析、风险分析和优化。
SW-DFA：软件相关失效分析SW-DFA用于确认设计中实现的独立性或免于干扰，减轻可能的相关失效。
● SW-FMEA用来进行单点故障分析，因此在考虑某个底层故障时既不考虑其他故障对自身的影响，也不考虑对其他故障的影响；但是对于一个真实的系统而言，往往会出现底事件A发生故障同时导致底事件B和底事件C发生故障，所以FMEA分析的结果是不完整的，对完整性的弥补将由相关失效分析来完成。
● 标准对于“独立性”的定义是：两个或多个要素之间不存在导致违背安全要求的相关失效。意思就是只要要素具有充足的独立性以后，也就不会发生相关失效。这里面的相关失效其实就两种情况，一种叫级联失效，一种叫共因失效。
● 软件相关失效分析即SW-DFA是在软件架构层面执行安全导向分析的，主要的目的是通过分析其潜在原因或引发因素，确认设计中充分实现了要求的独立性或免于干扰；以及如有必要，定义安全措施，以减轻可能的相关失效。
分析流程：识别潜在的相关失效，判定是否为相关失效引发源，分析失效原因和模式，制定安全措施，评估安全措施的有效性。
1. 共享资源：例如被2个软件组件使用的驱动程序、RAM、数据库等；
2. 共享信息输入：两个软件函数的全局常亮或者变量，也就是两个函数使用的一个输入参数（一个软件函数计算的结果被多个其他软件函数调用）；
3. 环境抗干扰能力不足：这个一般对硬件层面的影响比较大，不直接适用软件本身，但是可能影响软件的行为的环境因素；例如，硬件设计抗电磁干扰不强的话，影响数据的采集和传输等；
4. 系统耦合：相同的软件工具如IDE（集成开发环境）、编译器、软件配置器；相同的编程和建模语言（主要指的是软件开发系统）；
5. 相同类型的组件：相同的源代码扩展了两次，例如通过使用C语言宏；从不同位置调用相同的数据库和标准软件模块的实例，也被认为是共享资源；
6. 通讯：通过全局变量的数据流；消息传递；传递参数的函数调用；
7. 非预期接口：由于使用相同的内存空间，导致可能出现错误的内存分配和内存泄漏。
-SASETECH-
03
议题总结
分组讨论完成之后，大家针对所讨论的问题，都提出了自己的看法。同时基于目前的工作经验，对其中还存在问题的地方进行了初步探讨：
● 如何在项目里进行第三方软件组件的鉴定工作，具体包含哪些工作以及怎么做；如果COTS供应商无法提供评估证明该如何?
讨论结果：COTS软件：对于商用现货（COTS）软件，可应用“在用证明”（A proven in use），使用历史数据预测功能故障模式的未来趋势。
因此标准中对这种情况的要求相当苛刻：
1. 必须证明现场数据在规定的观测期内是可用的，且这些数据实质性地与功能安全相关（必须进行详细分析）；
2. 如果在观察期内进行了变更，则必须证明这些变更不会影响数据的相关性；
3. 必须采用系统性集成的方法；
4. 必须给出计算观察期（服务期）的理由。
● 软件单元测试只是跑覆盖率吗？在执行过程中还需要关注哪些具体内容？
讨论结果：需要重点考虑测试用例设计时能否对边界条件进行验证，能否设计测试用例以覆盖不同的等价类，测试单元对异常输入和错误条件的处理能力。
同时还需要考虑代码覆盖率（语句覆盖率、分支覆盖率和条件覆盖率）；检查验证实际输出与预期输出是否一致。检查数据结构和对象的状态是否符合预期，评估单元在最坏情况下的时间性能，检查内存使用、CPU使用等资源消耗是否合理等内容。
● 面对MISRAC和HIS等旧有编码或编程规则，当前复杂SOC的软件功能安全开发规则如何做相应的调整?
讨论结果：随着SoC中多核处理器的普及，需要增加对并行编程、线程安全和同步机制的支持。
更新规则以包含对多核编程最佳实践的指导，如避免共享数据竞争和死锁。
由于SoC可能包含多种内存类型和层次结构，需要更新内存管理规则，以确保有效的内存使用和避免内存泄漏。引入对动态内存分配和释放的规则，以及对内存保护和隔离的要求。
更新规则以包含对实时性能的要求，如响应时间和任务调度。引入对实时操作系统（RTOS）的支持和最佳实践。增加对安全启动、安全更新和加密通信的需求，以保护SoC免受攻击。更新规则以包含对安全存储和安全执行环境的要求。
● 如何进行形式化验证？
形式化验证是一种数学方法，用于证明软件或硬件系统是否符合其规格说明。通过使用精确的数学语言（如形式化规格语言）来定义系统的行为和属性。结合适合项目需求的形式化验证工具和方法构建系统的数学模型，包括状态机、数据流图或时序图。确定需要验证的属性和条件，以及验证的顺序和方法，使用自动化工具或手动方法来检查模型是否满足规格说明。
● Part6中集成验证测试嵌入式验证测试，以及Part4中的系统和相关项集成和测试，在测试目，标和环境方面的区别。
Part6更侧重于对软硬件系统在集成后的整体功能和性能进行验证，而Part4则更关注系统的各个元素在集成过程中的正确性和稳定性。同时，两者在测试环境方面也有所不同，以适应不同集成阶段所面临的实际情况和条件。
集成验证测试：其主要目标是验证软硬件系统在集成后的整体功能和性能是否满足功能安全要求。这包括验证系统内部各组件之间的接口和通信是否正确，以及系统是否具备必要的安全性能。
嵌入式验证测试：侧重于对嵌入式软件或硬件在特定环境下的功能和性能进行验证。它通常关注软件或硬件在集成到系统之前或之后的特定行为，以确保它们能够正确地执行其设计的功能，并满足相关的安全要求。
Part4的系统和相关项集成和测试。
系统和相关项集成：其目标是确保系统的各个元素按照系统架构设计进行集成，并通过测试来验证每个系统元素的交互是否正确，是否符合技术和功能安全要求。这包括验证系统内部各组件之间的集成和交互，以及系统与车辆内其他系统的集成和交互。
测试：旨在提供证据，表明集成的系统元素符合系统架构设计的安全要求，并为确保不存在可能违反安全目标的意外行为提供足够的信心。
● Part6附录中的软件配置(配置和标定)在V模型中哪些阶段需要考虑？
系统设计阶段
在系统设计阶段，系统的架构设计、输入输出流程、外部交互等都会被定义。软件配置的具体需求和实现方式也应在这个阶段得到明确。包括确定哪些软件组件需要配置、如何配置、以及配置参数的范围和默认值等。
软件单元验证和软件集成验证阶段
在这两个阶段，软件单元和软件集成后的功能会被验证。对于软件配置来说，这意味着需要验证配置参数的正确性和配置逻辑的有效性。可以通过单元测试、集成测试、以及模拟配置参数的不同组合来实现。
嵌入式软件测试阶段
在嵌入式软件测试阶段，软件在特定硬件环境中的行为会被测试。这包括测试软件配置在硬件环境中的表现，以确保配置参数的正确性和稳定性。可能需要使用专门的测试工具和环境来模拟不同的配置场景和硬件条件。
系统和相关项集成和测试阶段
在这个阶段，整个系统（包括软件和硬件）会被集成并测试其整体功能。软件配置在这个阶段需要被验证以确保其与其他系统元素的集成和交互是正确的。可能包括测试软件配置在不同系统状态下的行为、以及与其他系统元素的通信和同步等。
-SASETECH-
大家的讨论持久不绝，思想的碰撞在探讨中升华为灵感。夜幕降临，大家恋恋不舍结束了本次沙龙，让我们一起期待相聚下一期沙龙相聚SASETECH大家园。
END
往期精选
JOIN US
长期招募
上海/杭州
— 高级信息安全工程师
欢迎将个人简历发送至邮箱：
double.ma@sasetime.com
SASETECH是国内首个由汽车安全专家发起组建的技术社区，致力于为汽车安全的从业者提供交流、学习、合作的中立性平台。
SASETECH
扫码联系管理员加入交流群→
