侵权投诉
订阅
纠错
加入自媒体

系统架构设计详解

2020-10-25 21:56
Elektroauto
关注


上一篇,我们讨论了故障度量和安全机制的ASIL等级。本篇我们来聊一聊系统架构设计相关内容。

01

系统架构设计和TSC

当我们开始写TSC时,会涉及到下图中一系列的内容:

当我们完成前三期(链接见文末)提到的安全机制规范后,我们就要开始整理好所有的安全需求并在系统架构设计(SysArchiD)中来实现它们。不要忘记为每一个安全要求制定ASIL级别。也可以理解成安全要求(TSR)=安全机制或者TSR(由FSR分解得到)。

注意 → TSR受到FSC和系统架构设计的高度影响。我们来看一个SbW的案例:

安全机制示例:

包含外部看门狗定时器和电源监控的SBC;

监控功能块对某个算法进行监控;

TMR架构;

同质冗余:两个执行器;

异构冗余:一种执行器及其监视器;

02

Item Definition of SbW

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

关于安全技术要求的实现,系统架构设计应考虑以下因素:

验证系统架构设计的能力,使其易于验证;

预期的硬件和软件要素在实现功能安全方面的技术能力;记录系统架构设计安全相关的要素的规范;

在系统集成器件执行测试的能力;通过为增加的机制制定明确的接口,使设计可测。而且,设计不能太复杂以至于系统集成成为一个噩梦般的任务。

以上,就是本期的全部内容,我们下期再见啦!
参考资料:外文文献资料免责声明:本文章中内容是由小编翻译自外文文献资料,免费传播知识。

声明: 本文由入驻维科号的作者撰写,观点仅代表作者本人,不代表OFweek立场。如有侵权或其他问题,请联系举报。

发表评论

0条评论,0人参与

请输入评论内容...

请输入评论/评论长度6~500个字

您提交的评论过于频繁,请输入验证码继续

暂无评论

暂无评论

电子工程 猎头职位 更多
扫码关注公众号
OFweek电子工程网
获取更多精彩内容
文章纠错
x
*文字标题:
*纠错内容:
联系邮箱:
*验 证 码:

粤公网安备 44030502002758号