上一篇,我们讨论了故障度量和安全机制的ASIL等级。本篇我们来聊一聊系统架构设计相关内容。
01
系统架构设计和TSC
当我们开始写TSC时,会涉及到下图中一系列的内容:
当我们完成前三期(链接见文末)提到的安全机制规范后,我们就要开始整理好所有的安全需求并在系统架构设计(SysArchiD)中来实现它们。不要忘记为每一个安全要求制定ASIL级别。也可以理解成安全要求(TSR)=安全机制或者TSR(由FSR分解得到)。
注意 → TSR受到FSC和系统架构设计的高度影响。我们来看一个SbW的案例:
安全机制示例:
监控功能块对某个算法进行监控;
TMR架构;
同质冗余:两个执行器;
异构冗余:一种执行器及其监视器;
02
SbW相关项定义描述了系统的功能,但是ECU或者SOC/PSOC/ASIC/Micro-Controller分配的详细技术规范。如下图:
03
FSC of SbW
在功能安全概念中,相关项定义架构将会对细节/粒度进行微调。除了粒度之外,FSR也是在这个初步的体系架构中实现的。我们来看一下下面的内容,可以清楚的说明这一点。
SG01:The SbW system shall prevent unintended self-steering in any direction under all vehicle operating conditions . → ASIL-D
比如,我们添加了如下FSR给SbW:
The SbW control module is to have an arbitration strategy for steering-assist requests from the driver and other vehicle systems. → ASIL-DThe SbW shall run a self-test for steering assist at startup. Steering-assist commands shall not be issued until the validation of the communication channels is successful. → ASIL-B (注意:这里为什么是B而不是D,因为这是一个自检的要求,具体请看上一篇)Power Supply of the SbW shall be monitored. → ASIL-DSbW system shall have a redundant Steering Motor to achieve fail-operational safe state when the primary Steering Motor fails → ASILD下图展示了带有FSR分配的功能安全概念的初步系统架构。注意,这各系统架构设计包含另一个粒度级别,也就是说,里面包含了一些在相关项定义中找不到的内容。
如果放大看的话,我们会发现这里只分配了FSR01,FSR03和FSR04。
为什么没有分配FSR02?因为它是一个软件组件,将在软件架构设计(SAD)中来实现和演示。也就是说,它可以是硬连接的自测或者是STL的软件组件。注意:SbW控制器周围的所有块都被认为是逻辑函数。我们在当前阶段不关注它们是硬件、软件、机械结构件或者备用件。在技术安全概念上,我们来开发SysArchiD。也就是说,所有这些功能块都可以是软件,SbW控制器可以是软件控制器算法。
04
TSC of SbW
在技术安全概念阶段,架构粒度级别将达到ECU和实际处理单元的级别。下图展示了在功能安全概念阶段架构中没有体现的更多细节。
05
Internal and External Interfaces
应该定义安全相关要素(ASIL要素)的内部和外部接口,以确保其他要素(内外部接口)不会对安全相关要素产生不利的安全相关的影响。也就是说,我们的预期是解决架构问题,而不是把其他的BUG引入到系统中。
06
SysArchiD Consistency&Discrepancies
如果在技术安全概念阶段对架构设计进行了更改,那就必须在功能安全概念、HARA和相关项定义中对其进行更新。
那么,我们可不可以把更新后的系统架构直接从技术安全概念阶段复制到功能安全概念阶段?答案是否定的,因为我们的架构必须和FSC规定的粒度级别保持一致。那我们需要更新什么呢?
只更新新功能并将其重新抽象为合适的功能级别,删除任何特定的技术细节;
应该更新相关项定义、HARA和FSC规范,见下图:
如果我们去对比前面3、4部分的图片,会发现TSC级别的系统架构设计中添加了在FSC级别没有的新功能。
如何定义差异?如果我们只是添加了新功能,如车道保持辅助(Lane Keep Assist)功能块,它将被视为新功能,而不仅仅是从FSC到TSC的粒度,因此我们需要返回到相关项定义、HARA和FSC层面,并更新它们。
07
Testing&Integration
关于安全技术要求的实现,系统架构设计应考虑以下因素:
验证系统架构设计的能力,使其易于验证;
预期的硬件和软件要素在实现功能安全方面的技术能力;记录系统架构设计安全相关的要素的规范;
在系统集成器件执行测试的能力;通过为增加的机制制定明确的接口,使设计可测。而且,设计不能太复杂以至于系统集成成为一个噩梦般的任务。
以上,就是本期的全部内容,我们下期再见啦!
参考资料:外文文献资料免责声明:本文章中内容是由小编翻译自外文文献资料,免费传播知识。
-
ISO
+关注
关注
0文章
254浏览量
39576 -
系统架构
+关注
关注
1文章
69浏览量
23527
发布评论请先 登录
相关推荐
评论