- 博客(41)
- 资源 (1)
- 收藏
- 关注
RSS订阅原创 关于功能安全的若干“误解
“真正阻碍我们前行的不是我们不知道的事情，而是那些我们自以为知道却并非如此的事情”------马克吐温对于一款工业产品来说，如果这款工业品在用户正常使用过程中会威胁用户生命，甚至直接导致用户丧命，或者产生重大财产损失。那么，这款工业品是没有价值可言的。良好的用户体验是建立在安全的前提上的，如果无法保证基本的安全问题，一切的质量与体验都是空中楼阁，水中之月可望而不可及。回到我们今天的主角“功能安全”，有些事情正向很难理解，但是，反向往往容易很多。在讨论功能安全之前，不妨先讨论一下“功能不安全”.如果你的系
2021-07-18 12:59:49
547
原创 功能安全关乎“生死
安全是一个产品的基本属性，举个例子，无论是路边小摊还是米其林餐厅，我们购买食物的默认标准就是这个食物是安全的（我们不会因为吃它而丧命），那么对于汽车这个与我们生活密切相关的工业品，安全更是其首要属性。所以，我们国家产品质量法2018年修订版第13条有明确规定“可能危及人体健康和人身、财产安全的工业产品，必须符合保障人体健康和人身、财产安全的国家标准、行业标准”。而汽车作为一个十分普遍存在的工业产品，自然需要满足行业标准，我们国家针对汽车电子电器系统安全的国家推荐标准就是(GB/T 34590 -2017）,
2021-07-16 07:04:00
158
原创 不是所有的ASIL D软件都一样安全
软件和硬件有着本质上的不同，软件作为一种高度抽象的设计，它具有不可见性（软件无实体，你可能会看到存放软件的载体如U盘或者CD，但是软件本身是无法被感知的，它只是逻辑），永久性（软件不会随时间的延长出现老化，磨损等问题，载体或许会老化，但是逻辑不会，从而不需要进行维护（针对功能的拓展升级和针对错误的修复与逻辑本身无关）），问题突发性（软件问题不同于硬件问题，在出现错误之前，不会有任何的先兆特征（硬件或许会有异常振动或者性能不稳定等，软件问题会突然发生毫无征兆）），极易被篡改（软件之所以被称为软件，就是因为这个
2021-07-11 16:47:48
254
原创 什么样的软件算是功能安全软件？
在聊安全软件之前，我们首先来看两个非常重要的概念：完整性（Integrity): 软件或者系统用来表示其可以正确工作（work correctly）的定量或者定性的属性,它有时会用系统不满足功能正确的概率来表示。可用性（Availability):软件或者系统用来表示其在给定的时间点上处于功能状态的定量或者定性的属性，它有时会用系统不能提供它的有效输出的概率来表示。如果系统完整性丧失会导致系统出现不正确操作即故障功能（malfunction），例如汽车上的误导性提示信息，汽车的意外加速或者意外制动转向
2021-06-20 14:38:47
584
原创 ASPICE 与 功能安全过程融合 | 软件需求需要包含那些内容
描述如下约束下的软件操作：a) system interfaces;系统接口b) user interfaces;用户接口c) hardware interfaces;硬件接口d) software interfaces;软件接口e) communications interfaces;通讯接口f) memory;内存g) operations;操作h) site adaptation requirements; and场地需求i) interfaces with services.服务接
2020-09-10 22:22:27
570
原创 评价软件质量的三个模型及其特性介绍
软件质量是软件满足各种干系人需要并提供价值的程度。软件质量相关的可测量属性通常称为质量特性。一般来说会使用三个质量模型来评估软件，分别是使用质量模型（the quality in use model）、产品质量模式（product quality model）和数据质量模型（data quality model）.这些质量模型共同作用形成框架(Framework)来约束软件质量。这些模型会提供一些列与各类干系人相关的质量特征。 使用质量模型（the quality in use model）定义了五个与系
2020-09-08 22:34:54
1661
原创 ASPICE 与 功能安全过程融合 | ASPICE要求需求开发实践
本文是继续前文（ASPICE 与 功能安全过程融合 | 需求的属性与管理要求）进一步介绍一下ASPICE在软件开发过程中，针对需求的三个重要实践阶段，分别是SYS.1 需求挖掘，SYS.2系统需求分析以及SWE.1软件需求分析。 首先我们来看一下是SYS.1 需求挖掘阶段的基础实践及目的。SYS.1需求挖掘 的过程目的：在产品和/或服务的整个生命周期内收集、处理和跟踪不断变化的利益相关方的需要和需求，从而建立一个需求基线，作为定义所需工作产品的基础。过程成果：1)建立了与利益相关方的持续沟通；
2020-09-07 21:41:25
1197
原创 软件可靠性计划过程组成与LRU简介
上一篇文章介绍了软件可靠性性工程的基本概念软件可靠性工程简介，下面介绍软件可靠性过程SRE的软件可靠性计划如何制定及什么是LRU。在软件设计之前，为了提高软件可靠性开发的效率，首先要对开发活动进行策划。下图展现了软件可靠性计划制定中需要执行的活动以及每个活动的输入与输出。软件可靠性计划制定的第一步是软件系统的概念设计。而软件系统概念设计的起点就是识别软件系统的中现场可替换单元LRU（Line Repalceable Unit）.这个活动是进行软件SFMEA分析和可靠性评估的必要前提。一般软件产品经理负
2020-09-06 21:58:26
1679
原创 ASPICE 与 功能安全过程融合 | 需求的属性与管理要求
功能安全标准第8部分的支持过程中，将需求的说明与管理单独作为一个章节提出来。标准将功能安全提出的需求说明与管理过程的目的，概括为如下两点； 一是， 从需求特征和属性两个方面保证安全需求的正确说明。 二是，保证安全需求在开发过程中的一致性管理。 说白了就是提出了对需求的具体表达与管理的要求。而ASPICE并没有在支持过程中单独提出需求的说明与管理过程，但是，却在系统和软件层面提出了很多具体的需求过程实践，来帮助我们进行需求的挖掘与分析。将两份标准结合在一起看，我们就会
2020-09-02 22:56:49
710
原创 软件可靠性工程简介
什么是软件可靠性？ 笔者是汽车电子行业的从业者，笔者咨询过很多同行如下两个问题：1、在您现在或者以前的项目上是否有人向您提出过软件可靠性指标？ 目前笔者没有收到过肯定的答复，几乎所有人的答复都是没有指标，靠流程保证软件可靠。2、是否有流程或办法帮助我们评估软件中的海森堡bug并进行优化？ 答案基本上也是目前没有。（海森堡bug定义参见文章汽车电子读书笔记-专业术语解析07- 海森堡bug与波尔bug） 正是对上述两个问题的困惑，促使笔者去思考一个问题，软件的可靠性真的没有办法评价么？
2020-09-02 07:28:02
808
原创 ASPICE 与 功能安全过程融合 | 单条需求的规范表达形式
我在写需求之前，首先要了解一下什么是需求，参考标准IEC2914-2018对需求有如下定义：Requirement(需求) –statement which translates or expresses a need and it’s associated constraints andconditions需求是对需要的陈述，其中要包含要求的条件与约束。定义中包含了两个非常重要的元素条件condition和约束constraints。那我们再来看一下条件和约束的含义又是什么呢？Conditions(条件
2020-08-31 06:24:11
315
原创 ASPICE 与 功能安全过程融合 | 文档化如何落地
前面的两篇文章ASPICE 与 功能安全过程融合 | 文档化过程和ASPICE 与 功能安全过程融合 | 过程能力分别介绍了文档化过程的基础实践与能力评估，那么我们接下来就来看一下，如何将两者结合在一起建立文档化流程。 我们先回顾一下功能安全对文档化的要求与期望的产物，概括来看可以分成两个层次，一是对所有文档的管理计划，二是对具体工作产物的要求。那么我们再来看以下ASPICE的基础实践，它强调的要先制定策略标准、识别文档化对象、制定文档、对文档进行检查批准分发和维护。ASPICE中强调的这些内容，恰恰就是
2020-08-28 08:09:02
579
原创 ASPICE 与 功能安全过程融合 | 过程能力
前一篇文章介绍了ASPICE与功能安全过程实践的结合（ASPICE 与 功能安全过程融合 | 文档化过程）本文将引入过程能力的相关说明。目前无论是国内还是国际上的OEM对过程能力的要求大多是2级，少数要求是3级。所以本文分析的过程能力仅仅到3级。首先我们来看一下ASPICE1级到3级的过程能力要求有哪些；过程能力等级0级：不完整的过程过程未实施、或未能实现其过程目的。在这个等级只有很少或没有系统化实现过程目的的证据。很多粗犷的开发模式或者逆向开发模式会存在这个级别。过程能力等级1级：已执行的过程P
2020-08-27 11:34:40
986
原创 软件失效模式与影响分析SFMEA的8个入手点
1 功能Functional失效分析的时机一般在新的系统设计、新的需求或者需求变更时考虑。适用该失效分析的软件成果软件需求说明software requirement specification SRS\ 系统需求说明 system requirement specification SyRS典型的失效模式故障 、矛盾、名义条件或者错误处理相关需求的丢失。2 接口 Interface失效分析的时机涉及软硬件接口、软件与软件接口、人机接口时。适用该失效分析的软件成果接口设计文件 Inte
2020-08-26 21:50:39
1768
原创 ASPICE 与 功能安全过程融合 | 文档化过程
本文引用ASPICE3.1中的内容进行说明，本文参考的功能安全标准是ISO26262-2018。文档化过程在功能安全标准中属于支持流程的一部分，具体要求来自于标准第8部分的第10小节，对应的ASPICE过程要求是SUP 7。从过程目的来看ASPICE要求比较直接“开发和维护由过程产出的记录信息”，功能安全的过程目的相对来说比较抽象“为整个安全生命周期开发一个文档管理策略，来促成一个高效且可重复的文档管理过程”单纯从过程目的来分析，功能安全要求更偏重于对已有文档化成果的运用，如果是从无到有部署文档化过程，
2020-08-20 23:22:13
781
原创 功能安全实践 - 软件测试边界值方法
前一篇文章中介绍了等价类方法（功能安全实践 | CTM中等价类方法实践）。本文介绍边界值方法，边界值方法论的核心思想是“对于一个规定了使用范围的数据，边界值相对于中间值来说，更容易设计出错误敏感的测试用例”。从边界值方法论的基础来看，它与等价类方法的要求恰恰相反。因为等价类方法是选择一类值中的任何一个值（可以是中间也可以是边界），而边界值则是要求选择这一类中的某些特定值（靠近边界的值）。但是，在测试用例设计时，两种方法需要综合考虑。划分好的等价类形成了边界值测试的基础，我们继续以上文中的制动器高温报警系统
2020-08-10 21:42:50
286
原创 功能安全实践 | 软件测试方法论之分类树 CTM中等价类方法实践
上一篇文章功能安全实践 | CTM方法实践步骤01介绍了软件测试分类树CTM实践的前期内容，本文首先对上篇文章中关于等价类划分的相关内容做一些补充。a,文章中的等价类并不是结果一样，比如，对于数值计算来说，所谓等价类并不是说同一个等价类中所有输入计算的输出都是一样的（事实上绝大多数结果都是不同的）。b,等价类的划分需要具备完整性不能遗漏值。测试过程中用到的所有值都需要分配给一个类。c,等价类的划分需要保证独立性。说白了就是与测试相关的某一个值只能归为一个类，而不是多个类。这个定义与高等数学上映射的定义
2020-07-29 19:34:06
267
原创 功能安全实践 | 软件测试CTM方法实践步骤01（分类树方法前期实践与等价类划分）
上一篇文章分类树测试方法CTM介绍 | 概要介绍了CTM的概要，本文将介绍CTM的执行步骤，首先CTM方法执行的前提是被测目标的功能说明，这是CTM的起点，有了被测目标的说明，就可以进入下述的实施过程。1,功能定义第一步是基于被测目标的功能定义，来描述被测目标的预期行为。例如“当开关拉起的时候，EPB执行夹紧操作，当按下开关的时候，EPB执行释放操作”。软件是用来满足需求的，即用来解决问题的，说白了就是输入数据根据一个算法（比如函数）转化为输出数据。2，识别测试内容第二步分析功能说明，也就是说你需要
2020-07-28 19:39:16
497
原创 分类树测试方法CTM介绍 | 概要
前面的文章中已经介绍了软件单元测试中的一些基础概念参见文章（功能安全理论 | 黑盒 与 白盒和功能安全理论 | 软件组件 与 软件单元），测试是软件开发过程中必须进行的一项重要活动，当我们准备开始测试时，我们首先需要回答如下问题：1，我们需要跑多少条用例？2，我们应该测试那些数值？3，如何设计错误敏感测试？4，如何避免冗余测试用例？5，有没有忽略应该进行的测试？6，什么时候终止测试最安全？ 任何被上述问题困扰的工程师都可以了解一下分类树测试方法（CTM classification tree
2020-07-26 22:40:12
1050
原创 功能安全产品开发中的一二三四
初看功能安全标准时最大的困惑往往是“我们该如何将功能安全真正与公司的实践相结合并开发出符合功能安全标准的产品？”很多刚刚接触功能安全的人常常会进入一个误区，认为“功能安全就是一个文件体系，只要按照标准把文件准备好就可以了，比如，对于软件单元，功能安全提出了明确的要求，好像只要我们管好版本、符合MISRA C并且进行了必要的测试而且覆盖度达到了要求的指标比如MC/DC 100%我们就符合功能安全了”，然而，事实并非如此，本文将为大家介绍功能安全开发过程中会涉及的几个重要方面，笔者将其概括一个理论两个维度三个方
2020-07-24 19:06:57
348
原创 安全档案 | 具体包括那些内容01
一般的安全档案主要包含以下四个部分的内容：产品的边界Boundary of Product我们设计的系统具体包括那些内容，针对这些内容有那些声明claim。有两个不同的阶段需要定义清楚，特别是被讨论的系统是更大系统的组成部分时。 第一个阶段是解决集成过程integration process：当声明产品范围的时候，被集成方是否要求集成方集成专用驱动来与声明的产品进行交互，安全档案的声明中是否包含了与专用驱动相关的调试接口？ 第二个阶段是与使用相关；组件所有功能是否都可以使用？禁止使用的功能是否包含在
2020-07-21 08:08:06
969
原创 功能安全理论 | 软件组件 与 软件单元
组件(Compoent)在26262-1 3.21 P13中的定义是（在逻辑上或技术上可分离的非系统级元素，其中包含多个硬件或者软件单元non-system level element that is logically or technically separable and is comprised of more than one hardware part or more software units）.而软件单元的定义在26262-1 P33 3.159 中则是（atomic level soft
2020-07-20 19:32:00
1503
原创 功能安全理论 | 黑盒 与 白盒
功能安全标准ISO 26262-6的第9部分是关于软件单元验证的的，总共三个Table（7、8、9）,其中Table 7的1j要求是 Requirements-based test，无论什么功能安全级别的软件都需要进行此类测试。而在Table 9中要求ASIL B及以上等级的软件需要满足1a statement coverage即语句覆盖（又可以理解为行覆盖，只要每行代码执行过了就可以，不需要关心具体逻辑内容）。而对于ASIL D级别的软件则需要执行1b (branch coverage分支覆盖)与1c(M
2020-07-17 08:19:23
299
原创 功能安全实践 | 定义编程Style和命名规则
功能安全标准ISO26262-6 Table1的1g中推荐ASIL B及高于ASIL B等级的代码需要use of style guides（使用风格指南）而所有涉及功能安全的代码都需要使用命名规则（1.h Use of naming conventions）.什么是风格指南？为什么会有这样的要求，笔者初次接触这个要求时也十分茫然，我写的代码只要过了单元测试不就可以了么？为什么一定要定义风格呢？首先咱们一起来看看为什么这个问题。刚学编程的时候，老师通常会说养成良好的编程习惯，比如，变量的名字要有意义不要
2020-07-14 07:06:52
393
原创 功能安全实践 | 如何安全使用全局变量
做为一个CBD（code base design基于代码的设计）开发者,如果你维护的程序是以万行为单位来计算，那么你不得不面对一个问题全局变量global variable。在2018版功能安全标准ISO2626-6 Table6 1e中有如下描述（针对ASILB级以上产品）：Avoid global variables or else justify their usage(避免使用全局变量，如果必须使用，请判断并说明)而 在《The Art of Designing Embedded Systems
2020-07-12 12:12:45
570
1
原创 警惕安全档案的陷阱 | 确认偏见
安全档案存在一个比较深层次的问题，就是确认偏见。所谓确认偏见，就是一种为自己已有观点不断搜集解释依据，不断确认自己观点的心理趋向（通俗点讲就是自己骗自己）。举一个简单的例子，假如你逛某宝时发现一双自己有点喜欢的鞋子（你可买可不买），你随手把它加入购物车，随后的几天每次当你打开某宝时，你都会看一眼这双鞋，你会从不同的角度为这双鞋找优点（比如它款式真好，价格又便宜，我今天出门发现鞋子不够了等等）来不断暗示自己这双鞋太好了，然后，你慢慢发现这双鞋简直太完美了，你必须把它买下来（买回来后，你发现自己其实并不那么喜欢
2020-07-11 20:55:21
237
原创 安全档案 | 什么是安全档案? 档案为谁而写？
残余风险评估 Assessing the Residual Risks尽管采取了安全措施，系统依然会有残余风险，可能需要进一步采取安全措施。在极少案例中，安全措施可以将残余风险降低到零，所以，通常来说系统会始终存在一些可接受的风险。安全档案 safety case什么是安全档案？ISO26262中的安全档案定义是，收集了开发过程中安全活动的工作成果作为凭证，证明完整的实现了相关项的安全需求。笔者引用的英国国防部的定义（a structured argument, supported by a body o
2020-07-08 06:03:20
655
原创 功能安全中安全措施的合理性评估 | GAMAB 与 MEM
GAMEB与GAME相对于选择前文中介绍的安全措施的合理性评价方法 | ALARP，在法国应用更多的合理性评估方式是GAMAB(globalement au moins aussi bon风险水平大体相当)这种方法的要求是，当用一些可接受指标衡量新系统时，任何新系统必须提供它的风险水平，而且这个风险水平一定不能低于现存的同类系统。根据产品的不同，指标可能是每年的人员伤亡人数，每小时使用该设备的受伤人数或其他适当的衡量标准。GAMAB有时也被称为GAME（globalement au moins ´equi
2020-07-06 22:10:39
982
原创 危害与风险分析方法论 | HACCP 和 HAZOP
危害与风险分析 Hazard and Risk Analysis在文章汽车电子读书笔记-专业术语解析01中介绍过，不同的安全标准对危害与风险的解释是不同的，本文中的定义参考文章（汽车电子读书笔记-专业术语解析01）中的解释（参考文章中认为，危害hazard是伤害harm的潜在来源（客观存在的现实或事物），而风险risk则是触发危害hazard引起伤害harm的行为（主动的行为或者故障，目前26262中主要是故障）。危害和风险分析的目的是识别设备或者组件的相关的危害与风险并确定减少风险的缓解办法（mitig
2020-07-05 18:32:09
835
原创 功能安全产品开发初始分析 | 功能分析
看到功能分析很多人会首先想到分析结果（各种文件），但是，这个活动的核心是分析，文件只是活动过程的副产品。本文介绍的分析内容并不是十分详尽，但是，这些内容都是后续开发活动的基础。危害与风险分析（Hazard and risk analysis）识别与最终产品使用相关的风险与危害。对于风险、危害和缓解的定义可以参考文章功能安全-26262-理论到实践-基础概念-危害，风险，残余风险。这个分析非常关键，因为项目的安全需求和失效分析数据都来自于这个环节。安全档案（Safety case）safety cas
2020-07-05 18:30:53
761
原创 小A与小B基于功能安全标准合作的故事-序
为了后面更加直观的阐述交付物与商务合作的关系，这里咱们介绍两家虚拟公司，A汽车系统有限公司简称小A，和B汽车系统有限公司简称小B。小A是一级部件供应商(也就是我们所说的tire 1)，直接负责供货给原厂制造商OEM（也就是我们平时熟悉的各种汽车品牌如某众、某汽等）。小A作为一级供应商一般不会所有东西都自己造，它总有些需要采购的组件如芯片、操作系统等。在这个故事里面，小A希望从小B哪里买软件集成到自己的产品里面用，我们这里假设小B是卖操作系统的。小A已经通知小B希望大家可以合作，但是小A的合同中有一条是小
2020-07-02 21:53:49
186
原创 功能安全-26262-理论到实践-遵循最佳实践不等于拥有好的产品
虽然，我们在开发产品引用标准时，几乎所有标准都会定义一套必须遵守的流程，但是，作为开发人员我们关注更多的是技术层面的实现问题。在项目开发过程中存在一个很大的误区就是“好的流程就意味着好的软件A good process leads to good software”。之所以会有这样的认识，主要来自两个方面，一是很多标准都包含了一个前提假设，特别是IEC62304这样的标准，即过程质量就是最终软件质量的度量。二是，相对于评价软件质量，评价软件开发流程要容易的多（只要保证在软件发布之前，所有的设计文档都经过了评
2020-07-01 22:28:30
231
原创 什么是SOTIF? SOTFI到底讲的是什么？
危险场景的出现，往往是因为期望的功能很难预测导致的。如果期望的功能可以预测的话，那么它已经并入系统设计之中了。ISO/PAS 21448 从两个维度来评价考虑的情景：一个是情况是否已知，另一个是这些情况是否安全。如下图所示：ISO/PAS 21448 标准忽略了区域4(Area 4)中安全但是未知的情景（意外情况），主要关注的是扩展区域1( Area 1.)并缩小区域2( Area 2)和区域3( Area 3).主要通过以下两点来考虑上述问题；危险的预期行为会导致什么样的危险事件？这些危险行为的潜在原
2020-06-30 23:26:38
4397
原创 功能安全-理论到实践-机器学习中罕见事件的重尾分布与自动驾驶系统中的误判行为。
卡耐基梅隆大学教授Philip Koopman认为，罕见事件的分布是重尾的（ heavy-tailed ），因为自动驾驶车辆可能在整个产品生命周期中都不会遇到一大群鸡穿过马路的情况，所以，没有合理的理由来训练自动驾驶车辆处理这种情况。但是，如果这些罕见事件(rare events )不被包含在训练数据中的话，当自动驾驶系统遇到一只真正的鸡时，它会出现什么反应？Koopman在《The Heavy Tail Safety Ceiling》一文中给出了一个让人沮丧的结果：“The heavy tail saf
2020-06-29 21:48:52
330
原创 为什么基于机器学习的自动驾驶系统不能靠功能安全即ISO26262进行约束？
ISO26262和它的引用标准IEC61508都根植于一个共同的信念即，研究一个设备的安全性就是研究这个设备的失效（ the study of device safety is the study of device failure）。这个信念从20世纪早期安全工程中用来解决飞机是两发动机安全还是四发动机安全开始（四发动机飞机失效可能是两发动机飞机的两倍，但是每种失效都没有那么严重,可参见汽车电子读书笔记-专业术语解析02），在整个20世纪的安全工程中就没有改变过。表面上看，安全和失效之间的联系是非常强大
2020-06-29 07:46:57
278
1
原创 功能安全-26262-理论到实践-基础-安全标准与认证- 机器学习和预期功能安全01
因为，在很多危险场景中，并没有功能失效。所以，安全分析不完全等同于失效分析。然而，现在的功能安全标准如ISO26262、EN5012x和IEC61508都是基于软硬件失效可能性造成的危险场景进行分析的。其中ISO26262在这方面的规定特别清楚，它定义的“功能安全”就是“系统没有电子电气系统故障行为引起的不合理风险absence of unreasonable risk due to hazards caused by malfunctioning behaviour of E/E systems”。如果这
2020-06-28 22:34:37
408
原创 功能安全-26262-理论到实践-基础知识-基于可靠性理论的的SIL与基于系统理论的STAMP
IEC61508是与功能安全相关的最基础标准可见上图????，它的标题为电气/电子/可编程电子安全相关系统的功能安全(Functional safety of electrical/electronic/programmable electronic safety-related systems)，包含7个部分，其中前三部分是规范（normative “一份标准的“规范”部分，一般用来定义，允许干什么 和 不允许干什么”）包含项目管理和软硬件开发，后面四个部分是参考信息（informative 标准的信息部
2020-06-28 06:13:54
700
原创 功能安全-26262-理论到实践-基础知识-标准机构与认可、认证
标准机构 Standards Body起草标准的人通常高度关注怎么定义最佳过程实践(Best Practice)，而常常忽视一个问题“遵循标准的人如何向别人证明，我开发的产品是安全的这个问题”。并不是说，我们遵循了一些预先设计好的开发过程，那些所谓的最佳实践，就能证明我们开发的产品是安全的。我们需要通过评估危害(assess hazards)，设计减轻(mitigation hazards)这些危害的手段，最终剩下那些可以接受(acceptable)的残余危害(residual hazards)的方式来向
2020-06-24 20:51:40
1066
1
原创 功能安全-26262-理论到实践-基础概念-什么是软件
软件 Sotware对于什么是软件，似乎所有人都觉得定义是那么的显而易见。直觉上来看，只要砸在我们脚上能疼的，都算是硬件hardware,除此之外的都是软件 Sotware。如果这样的话，使用软件工具设计的专用集成电路（ Application-Specific Integrated Circuit ASIC）和基于模型生成的C代码算什么呢？引用英国铁道安全标准委员会的定义（http://www.yellowbook-rail.org.uk），在2007年的工程安全黄皮书《Engineering S.
2020-06-24 07:31:04
281
原创 功能安全-26262-理论到实践-基础概念-偏差恢复与意外系统
向前偏差恢复 Forward Error Recovery 向后偏差恢复 Backward Error Recovery当失误（fault）引起偏差（error）时，有时偏差（error)可以被限制住，这时我们可以在偏差引起失效（failure）之前采取一些恢复手段。恢复手段主要有以下两种；向后偏差恢复 Backward Error Recovery一旦发现偏差（error），系统立刻恢复到保留的历史状态（系统识别的数据合理并且可靠的旧状态）。然后，对于引起偏差（error）的输入是复用还是丢弃
2020-06-24 07:28:31
224
SAFETY ASSURANCE OBJECTIVES FOR AUTONOMOUS SYSTEMS V1.PDF
2020-06-29
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人