menu

安全关键系统设计

markdown写起来太麻烦了, 跳转语雀:

https://www.yuque.com/jiucai-kxrf0/wyvx1y/ag125o















以下为搜索引擎收录用, 因为懒得维护博客, 无视

传统安全关键工业领域, 像是汽车, 航天, 自动化等等方向, 因为安全性是首要关注点, 所以会形成一套固定的开发流程和软件框架。 基于Linux的行业应用, 像是生活随处可见的各种电子广告牌, 点餐机, 监控摄像头, 通信设施 ,还包括各种消费电子等等,因为更多关注可拓展性和功能, 所以在开发上不会形成特别的范式。

在一个新的方向出现的时候(比如说自动驾驶, 家用机器人等领域), 因为行业没有标准, 加上为了快速完成原型, 普遍的团队都是使用Linux行业应用的方式切入。 但这些方向,用功能安全的术语来说,不乏ASIL-D的危害事件, 也就是会造成人员损伤, 因此必须要设计成安全关键系统。为了系统达到高安全性, 还是得结合传统安全关键工业领域的开发经验。 所以我想通过对比两种领域开发方式的不同,为从普通Linux行业应用的开发方式,切换到安全关键系统的开发方式上来,增加一点输入 ——— 但肯定不是说要完全的照搬, 因为对这些方向(自动驾驶, 家用机器人等), 安全性很重要, 但是功能也重要, 更需要探索一个折中的方法, 在不损失灵活性的基础上, 让系统变的更安全。

( PS: 工作经验主要做Linux行业应用为主, 对汽车行业并没有实操的经验, 输入来源于书籍和网络资料, 可能会有比较多的错误)

导图 安全关键系统

实时系统 从安全关键系统的导图上看, 实时系统主要是为了满足安全功能设计中的时序要求。 ( 这里面涉及的东西太理论了, 还没有吸收完, 随便写写,有兴趣可以看看tttech的资料和他们的书《分布式实时系统设计》 (:τ」∠)

实时操作系统 因为实时操作系统包含了框架和系统, 因此广义上我们聊实时操作系统的时候, 对其的要求并不止是说时序上的实时, 也包含对基础软件需求。 以下导图从ISO25000的角度, 随便写写安全关键系统可能的对实时操作系统的需求。 (大部分时候我们工程师差不多也就是从这个视角看问题)

工程范式 这里主要从软件视角上看工程范式,硬件视角的话, 其实也大差不差, Linux行业应用包括消费电子的硬件设计和软件设计是相对分离的, 较少整体性考虑, 更像是软件在一个已经固定下的硬件平台上自由发挥。

V模型里的架构设计是规定性的,以核心的架构师为核心。 敏捷方法中, 架构工作是描述性的, 并且分散到多个自行组织的团队中完成。 V模型在汽车等工业领域中使用的多, 因为安全性是最首要的关注点, 安全功能的架构比较关键。 在其他软件领域里, 敏捷开发更常见, 因为功能的实现是最重要的。 敏捷开发的团队更有自组织性, 有创造力, 但相对的架构工作就变得更难以掌控。

两者的差异其实从文档就可以看出来, 一个是从下到上, 一个是从上到下 就像我们使用yuque这样的工具管理文档, 每个团队会写很多记录, 但你看不到一个整体的架构性文档 但是像汽车工业, 会使用systemweaver这样的软件来统一管理需求/设计数据库

软件技术 个人觉得, 汽车工业上的 流程管理/功能安全等方法论 和 技术上的安全系统/实时系统架构设计 等是可以学习的, 但是软件技术其实不太重点, 条条框框的太多, 是通过牺牲“复杂性”, 从而达到”安全性“, 没有“软件定义”的灵活性。 但是如果你的部分子系统是可以抽离的比较干净的, 那通过复用汽车工业的软件框架, 使这部分子系统来快速达到ASIL-D的安全性等级, 也是可以的; 至于需要“软件定义”的模块, 还是需要重新探索如何更灵活满足安全设计。

设计方法V模型是安全关键行业的一种流程方法, 主要包含设计(Design), 实施(Implementation), 验证(Verification)和确认(Validation)等工作, 相比起敏捷开发, V模型更能带来 “构建稳定的产品所必需的精心设计,开发和文档编制” 。(https://wikichi.icu/wiki/V-Model_(software_development))V模型可以用在整个系统上,也可以用在某个子系统,或者软件/硬件上, 或者“功能安全”,“信息安全” 下图为“信息安全”的V流程范例下图为“功能安全”的V流程范例, 可以看到他是由一个大V+两个2个小V组成的流程比起敏捷软件开发, V模型的一部分核心区别在于V的左侧 —— 设计(Design)。本文尝试探索, 在特定工业领域以外, 更通用的更广泛的适合行业应用的V模型中的设计流程。汽车工业功能安全https://zh.wikipedia.org/wiki/ISO_26262汽车工业最典型的V模型流程就是功能安全了, 这套流程对其他安全关键的系统也很有借鉴意义, 所以我们就来看看功能安全里的设计步骤。流程识别项目(item,特定的车用系统产品),以及定义其最上层的系统功能需求。识别项目的全面风险事件(hazardous events)针对一个风险事件,定义其ASIL(可参考Part 9)针对风险事件决定其安全目标(safety goal),其中也包括风险事件的ASIL。针对汽车层级的功能安全概念(functional safety concept),定义可以确保安全目标的系统架构。将安全目标再拆解为细部的安全需求(safety requirements)(一般而言,每一个安全需求都会使用上层安全需求或安全目标的ASIL。不过因为实际情形的限制,可能会将一个安全需求拆解为数个ASIL较低,但有冗余机能的安全需求,由独立的冗余元件来实现)。安全需求会分配到各架构组件(architectural components),可能是子系统、硬件组件、软件组件(一般而言,每一个组件都需要考虑分配到安全需求的ASIL等级,依其标准和程序进行,若有多个等级,以最高的为准)依分配的安全需求以及机能需求开发架构组件,并且确认符合对应需求。支持流程ISO 26262中有定义一些在安全生命周期中在各阶段都持续进行的支持性流程,这个是整合性的流程,也提供了为了支持通用流程目标需额外考虑的事项。受控制的企业界面,可以下达目标、需求和控制方式给分散式开发中的所有供应商。明确的标示安全需求以及在生命周期中的相关管理方式。工作文档的配置管理,有正式唯一的识别方式,可以重现配置,可以建立各工作文档和配置变更之间的可追踪性正式的变更控制,包括变更影响的管理,目的是要确保识别到的缺陷已移除,在产品变更时不会导入危害。工作文档验证的规划、控制以及报告,验证可以是评审、分析及测试,也包括各来源识别到缺陷的回归分析。计划性的识别及管理在安全生命周期中,所有有助于机能安全以及安全评估持续管理的工程文档(文件)软件工具(计划使用以及实际使用的工具)的合格性审查以往开发的软件及硬件模组,要整合到目前开发ASIL等级的合格性审查用服务历史证据来证实某项目若要用在指定的ASIL等级,已有足够的安全性。相关的软件设施IQ-PMEAhttps://www.fangzhenxiu.com/post/678397/创建的步骤如下:1、使用功能网和故障网进行系统结构建模2、为故障网补充错误探测和错误响应3、确定安全目标,设定相应的控制阀,如SPFM、LFM和PMHF等4、为每一个违反安全目标的问题确定容错时间(FTT)5、为每一个错误探测确定探测时间(FDT),为每一个错误响应确定反应时间(FRT)6、记录FIT值,如在FMEDA表格7、记录具有故障或更佳的DC值并通过错误检测8、在图形编辑器中检查时间特征是否满足目标值9、复核计算基础(FIT和DC),确保完整性10、为每一个安全目标发布故障表SQTRACER标准中文版📎ISO-26262.pdf实操网上找的具体实操的案例, 有兴趣可以看看, 以深入理解安全生命周期一个简单的, 可以快速看看https://www.nxpic.org.cn/article/id-323477一个更完整的, 以理解每个步骤要做什么《基于iso26262的功能安全》https://item.jd.com/13229940.html预期功能安全https://zhuanlan.zhihu.com/p/80649486由此可见,SOTIF(中文直译为预期功能安全)的关注点是:由功能不足、或者由可合理预见的人员误用所导致的危害和风险。例如,传感系统在暴雨、积雪等天气情况下,本身并未发生故障,但是否仍能执行预期的功能。而功能安全关注于与安全相关的失效(failure),信息安全关注于与安全相关的威胁(threat)。预期功能安全的分析方法会和功能安全不太一样, 这个主要是针对算法来说的不过这个没找到什么实操说明, 以后丰富了再研究融入其他工业我尝试找了一下汽车工业以外, 其他安全关键领域的设计方法在个别行业, 用不到太复杂的安全设计, 主要用的是额外加装保护实体的方法在某些行业比如轨道交通、过程工业等,安全防护设备(如SIS)和常规控制设备(如DCS)常常是分开的。也就是说,它们在物理上是独立的实体。从系统自顶向下分解而来的安全功能,基本上都由安全防护设备来承担,而安全防护设备基本上也只承担安全功能。功能安全只针对安全防护设备,以及安全防护设备和常规控制设备的系统集成。这样的系统架构泾渭分明,非常清晰,也比较容易理解。在航天领域,会更升级到“结构化设计方法”, ”形式化建模+验证“等等http://www.cmse.gov.cn/dmt/cbw/zrht/2007n/2007ndsq_459/200808/P020200303352709108285.pdf也会看到猎鹰9这样其实没有套用所谓航天标准的产物https://ubunlog.com/en/spacex-uses-linux-and-x86-processors-on-the-falcon-9/除开技术可能不一样, 但是大体也是和汽车一样的用ISO26262这样的流程可行路径在不牺牲敏捷开发持续迭代的特性下, 较为轻量的引入V流程中的部分阶段 (主要是安全设计完整引入就算了, 在一年一代车+OTA的背景下, 连汽车工业自己都在淘汰通过对iso26262的学习,我觉得一个可行的路径, 就是把”设计“ 和 ”确认/验证“ 都当成一个程序来维护。就好像敏捷开发中的开发是一个圆圈, 那我们的改进, 是可以把设计当一个圆圈 + 开发一个圆圈 + 测试一个圆圈, 通过伪代码/代码,在线文档/管理工具, 让死板的V流程更灵活但在环的流程,就好像敏捷开发依赖于devops, 设计的在环依赖于持续的追踪和监控能力, 不过就不在这里谈论展开了。预期功能安全主要是针对算法的TODO普通功能是沿用敏捷开发 or 引入部分V模型? 规定性的架构设计是否有必要?TODO 功能安全流程总体流程管理传统流程管理工具, teambition/aone等项目定义语雀等在线文档工具, 需要人为系统化组织危险分析和风险评估功能安全概念产品开发 - 硬件设计TODO, 建模/仿真产品开发 - 软件设计TODO, 建模/仿真/软件框架 安全确认TODO, 非本文关心其实这里的难点, 还是在于引入 ”经济上可承受的连续安全分析方法“, 在敏捷开发过程中持续保证安全, 不能简单套用ISO26262, 但我们开始不用想那么多, 先引入FMEA, 能提升一点点安全性也是好的至于软件设计/硬件设计, TODO安全设计涵盖危险分析/风险评估 危险分析和风险评估的第一步是情形分析和危险识别,即通过相关的情况分析将产品 存在的风险识别出来。这就要考虑可能引发危险的操作环境和操作模式,并且要考虑在正确 使用时和可预见的误使用时的情况。基于这样的考虑,我们应该通过大量的技术来系统分析, 注意以下一些方面: 1. 准备一个用来进行评估的操作情况清单2. 系统的确定清单上的危险。主要可以通过诸如:头脑风暴,检查列表,历史记录, FMEA,产品矩阵,以及相关的领域研究等技术手段进行。3. 风险应该用在车辆上可以被观察到的条件或影响来进行定义或描述 4. 在相关操作条件和操作模式下危险事件的影响应该被明确说明。如:车辆电源系统 故障可能导致丧失引擎动力,丧失转向的电动助力以及前大灯照明。 5. 如果在风险识别中识别出的风险超出了 ISO26262 的要求范围,则需给出合适的相应 措施。当然,超出 ISO26262 的风险可以不必分类分级。 完成风险的识别之后,就要对这些风险进行适当的分级,以便设定相应的安全目标,并 按照不同的风险等级来采取合理的措施加以避免。 风险的分类主要是通过 3 个指标来考量,即:危险发生时导致的伤害的严重性、在操作 条件下暴露于危险当中的可能性(危险所在工况的发生概率)、危险的可控性。风险分析对工具的要求就是需要记录所有风险 + 给风险分级(具体怎么分级的逻辑请看ISO-26262)功能安全概念需要能管理以下的组织如何从risk到safery goal到functional safety requirement, 主要通过FMEA/FTA等分析方式所以除了要记录层次结构, 最好还能直接集成FMEA这样的安全分析方法可行路径主要分两个流程一个是使用fema的方法事前分析可能的风险 和 对应的安全处理措施, 使用FTA事后分析出现的问题和对应安全处理措施一个是把fema/fta分析后的结果导入成功能安全的文档FEMA策划与准备:识别项目,了解项目计划,定义FMEA的边界,明确FMEA的分析过程,并填写FMEA的表格的第一步栏。结构分析:首先分析产品项目的过程,针对每个过程划分过程步骤或按工站划分,再对每个步骤识别出4M要素(人、机、料、环)。使用结构树的方式进行。功能分析:可以使用功能网络、功能书、功能矩阵等方法分析。进行功能分析前,需要了解要求、产品特性和过程特性。失效分析:主要从过程步骤开始分析,过程步骤的功能失效就是失效模式;而4M要素的失效,即是失效起因;分析失效模式的发生,产生的后果,就是失效影响。风险分析:基于现有的控制手段,对第四步识别出来的风险点进行评分和判定。从严重度、频度和探测度进行评分。优化改进:基于第五步评分结果和措施优先级,制定改进优化措施。结果文件化,输出FMEA表格FTA (1)对所选定的系统作必要的分析,确切了解系统的组成及各项操作的内容,熟悉其正常的作业图; (2)对系统的故障进行定义,对预计可能发生的故障、过去发生过的故障事例作广泛的调查; (3)仔细分析各种故障的形成原因,如设计、制造、装配、运行、环境条件、人为因素等; (4)收集各故障发生的概率数据; (5)选定系统可能发生的最不希望发生的故障状态作为顶事件,画出故障逻辑图; (6)对敌障树作定性分析,确定系统的故障模式; (7)对故障树进行定量计算,计算出顶事件发生概率、各底事件的结构重要度、概率重要度、关键重要度等可靠性指标。更多见:https://www.eet-china.com/mp/a61397.html因为没有现成软件, 所以只能第一步 fmea我们可以通过excel来做, fta也有一些工具第二步 人工从fmeal翻译到功能安全需求的结构, 来指导软件设计, 如果没有软件设计就先直接跳到开发样例功能安全我们这样相当是从0搭起, 所以实践过程中一定多看ISO-26262, 看看有没有能需要拿来的, 逐渐完善大框架(内部)