登陆
注册
首页> 资讯> ISO 26262 Item Definition（下）

ISO 26262 Item Definition（下）

来源：公众号“Elektroauto”
2020-07-08
2266
从之前的文章ISO 26262 Item Definition（上）中我们了解到，相关项定义是功能安全概念和进行危害分析和风险评估的前提。成功执行ISO 26262安全流程的关键是确定正确的相关项定义，从而启动安全生命周期，避免出现超支。但是如何正确地明确相关项呢?通过写出好的需求。如何写出好的需求呢?本期我们接着上期的话题继续聊一聊相关项定义。


01

—


如何明确好相关项定义？


设计一个好的相关项的第一步就是需要有好的需求。
图一：26262 V-Cycle

通过考虑以下准则，我们可以根据 ISO 26262 PART3写出好的功能安全需求（FSR），根据ISO 26262 PART4 和PART6 写出好的技术安全需求（TSR）。


02

—


好的需求规范


好的需求句子主要有三个特性：NVA
Necessary:
如果我们对某条需求的必要性产生了质疑，那么我们可以问下，如果没有该条需求，会发生什么糟糕的事情么？

比如上面图中这个气动尾翼：

  • 尾翼倾斜执行机构应在500毫秒内响应；

  • 尾翼的攻角应在500毫秒内反应；

这时候我们注意到，其实第一个需求不是必要的，因为第二个需求规定攻角应在500毫秒内做出反应，这已经包含了尾翼角度倾斜的执行器的移动了。换句话说，一个需求就足够了，因为另一个需求只是同样需求不同的表达方式而已。

Verificable:

同样，在编写需求时，如何保证它的可验证性? 确定验收标准。这一步有助于我们确保需求是可验证的。

  1. 任何输入的损坏/延迟应该从相关项XYZ中被弃用；

  2. 制动系统应该能够检测并且缓解产观其或者执行器中可能出现的任何错误；

  3. 所有CAN线上发送/接收的CAN信号应该进行E2E保护；

  4. 冗余监控模块应该监控变速箱的控制单元，并确保报告当前的档位符合特定的条件；

如果你是一名测试工程师，你如何测试上述第一条需求？什么是延迟输入？正确的超时时间是多少？损坏的标准又是什么？实际上，你会面对更多的模糊的问题，并且你所做的所有的测试都是无法验证此条需求的。

关于第二条需求，制动系统将如何检测传感器中可能会出现的错误？如何去测试所有的错误？如何测试可能会出现的错误？你会选择传感器还是执行器来进行测试？必须测试那些类型的传感器？必须测试那些类型的执行器？

关于第三条需求，什么是所有的CAN信号？测试仪器将测试那些信号？发送还是接收或者是同时发送？最后第四条，里面所说的某些条件是什么条件？

从上可以，为以上的需求开发测试用例特别不容易，它们是不可测试的需求。

Attainable:

为了达到可以实现的效果，需求必须是在技术上可行的，并且要符合预算、进度和其他的限制条件。

  • 后翼攻角应在50 毫秒内响应；

执行器激活时间是否为50毫秒？根据执行机构规范，这是否可行？液压缸的响应时间是否有助于在50毫秒内实现攻角？这个快速时间会影响空气动力下压力、升力或阻力吗？或者时间紧是不现实的，根本不会影响空气动力学？

系统或者需求工程师通常会遇到以下7个常见的问题。


03

—


七个常见的问题汇总


1. 使用不正确的术语；
开发者应该正确的理解shall，will 和 should:
Shall = requirements;
will = fact or declaration of purpose;
should = goal;

在写需求时，很多术语需要避免出现：Support, But not, Etc., And/or,Same , both, limited to, Minimize,Adequate, Maximize, Quick, Rapid, Sufficient, Easy, Wishful lists, User-friendly, Certain。

Support:

主动空气动力学应支持下压力。->模糊的

主动空气动力学应增加下压力。-> 明确的

But not limit to:

术语但不限于，等等被用来作为编写需求时的句子是因为开发者觉得可能需要罗列出比当前的更多。但大多时候，我们使用这些术语并不能达到开发者预期的效果，很可能会适得其反。
比如：电池管理系统应为电池组提供冷却，但不限于冷却。
And/Or:
术语和/或不适用于规范。如果使用和/或，并且我们只执行了或，那么它已经满足了我们的需求。因为本身这就是有二义性的，要么是和的关系，要么是或的关系。比如：
电池管理系统应为电池组提供冷却和/或隔离；
电池管理系统应为电池组提供冷却/隔离；
Same/Or:
比如：同一子系统还应能产生可见或可听的caution/warning signal，以引起副手或掌舵者的注意。
以上需求有哪些问题？哪个子系统？信号是可见的、可听的还是两者兼而有之？两者都有吗？小心和警告，只是小心，还是只是警告？…副手或掌舵者注意还是两者都有？危险标志包括含糊不清的用户类型和泛化词：usually, generally, often, normally, typically。
比如：用户通常需要系统入侵的早期指示。
此语句不会对系统施加任何约束或要求，但将添加或取消该功能的决定留给系统开发人员，因为他/她可以考虑一种情况，而这种情况并非“正常”情况。
Possibilities:
可能性用以下术语表示：may, might, should,ought to, perhaps, probably.
如果开发人员只做他们必须做的，他们总是忽略用户可能需要的东西。
比如：接收子系统应该足够灵敏，以便在钢架建筑内接收信号。

以上要求有哪些问题？可能会给开发者提供一个完全忽略它的理由。含有“如果”、“但是”、“除外”、“除非”、“虽然”等要求，如果处理不当，是危险的和误导性的。

再比如：当探测到烟雾时，应始终发出火灾警报，除非正在测试警报或工程部门已抑制警报。

以上要求有哪些问题？两个例子中都有两个或更多的场景。开发者试图在掩盖其他的情况。按单独需求处理。

Wishful terms:

它包含：100% reliable, Safe, Handle all unexpected failures, please all users, run on all platforms, never fail, upgradeable to all future situations。
比如：变速箱在正常运行中应100%安全；错误处理程序应在不崩溃的情况下处理所有意外错误；
以上要求有哪些问题？什么是100%安全？如何处理意外错误？
2. 编写的是实现（HOW）而不是需求（WHAT）；
规范应该说明需要什么，而不是如何提供。然而，这是需求编写者常犯的错误。大多数作者并不打算声明实现；他们只是不知道如何正确地声明需求。
问题：“系统应使用温度传感器XYZ测量试验箱温度”；
问题：#非强制设计；#相信所有的要求都被覆盖了；

这个常见的错误引起了一个经常被问到的问题。需求说明书和设计说明书有什么区别？

设计规范可以称为“设计文件”，因此“规范”与“设计文件”类似。

那么需求和规范之间有什么区别呢？规范 = 需求列表，因为它是一个文件或一本书。

3. 描述操作（OPERATION）而不是写需求；

“当用户进入传动系状态时，应禁用ADAS”。

“驾驶室错误计数器应计3次并禁用”。

陷阱：这个操作解释了它的设计。

4. 作出错误的假设；

错误的假设发生，或者是因为需求作者没有访问权限。信息充足或信息不存在。你可以排除第一个通过记录对计划或项目至关重要的信息而产生的问题，包括：

Needs，
Goals，
Objectives，
Constraints: Switching from primary electrical power steering to the secondary，
Operations Concept，
Budget : Redundant Steering，
Schedule : Complex solution instead of straight forward redundancy，Management/Organization
5. 使用错误的句子结构或者语法错误；

独一无二的ID：Object + Provision/Imperative (shall) + Action + Condition + [optional] Declaration Of Purpose/Expected Occurrence (will)。

Unique ID: 3.1.5.3；

Object: The vehicle；

Provision: shall；

Action: perform one complete track scan；

Condition: after engaging the ADAS；

“ Don’t use passive voice”；




6. 需求缺失；
通过使用标准大纲可以避免遗漏的项目，因为该标准将向目标行业和目标活动（如质量或安全）添加需求规范。

  • IEC 61508 Functional Safety of electrical / electronic / programmable electronic safety-related systems

  • IEC 62304 Medical

  • EN 50128 Railway

  • DO-178C Aerospace

  • ISO 26262 Road Vehicle " This what we are going to talk about next"

7. 过度定义；
DoD已经声明过多的规格是他们项目成本超支的主要原因。过度定义通常是由于陈述了不必要的东西或陈述了过于严格的要求。
Unnecessary Items：
不必要的需求以多种方式潜入规范中。唯一的解决办法是仔细的管理审查和控制。
Redundant:
尾翼应检查攻角范围；
尾翼应确保倾斜传感器的输入合理；
Over Stringent：

因此，你不应该说某些东西必须是某个特定的尺寸，例如100ft2，如果它可以很容易地达到100+/-10ft2。如果大于或等于200nm是可以接受的，那么您不需要要求某个东西将有效载荷精确地传送到200nm。该承包商因在为政府建造的飞机上向每个咖啡壶收费25000美元而受到严厉批评。但是对咖啡壶的要求太严格了，飞机可能会坠毁，咖啡却不会洒出来！


附上第一篇的链接，没看到第一篇的小伙伴可以在这里查看。
ISO 26262 Item Definition（上）
以上就是本期分享的全部内容，如果觉得本文章不错的话，请点击“点赞”，我们下期再见！



收藏
点赞
上一篇：OPENSYNERGY:基于虚拟I / O设备的汽车虚拟化方案研究 下一篇：L3该不该放弃？
2000
评论
  • Airon

    很好

    2020-07-20
    回复
    点赞

沪公网安备31010702008313号 沪ICP备18019345号-2 © 2019 上海工业控制安全创新科技有限公司 保留所有权利