您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   模型库  
会员   
   
DeepSeek大模型应用开发实践
6月12-13日 厦门
基于 UML 和EA进行分析设计
6月23-24日 北京+线上
人工智能、机器学习 TensorFlow+Keras
6月22-23日 北京
   
 
 订阅
如何为域控制器及中央计算单元选择安全的系统架构?
 
作者:凡尘新质
   次浏览      
 2025-5-23
 
编辑推荐:
本文主要介绍了如何为域控制器及中央计算单元选择安全的系统架构相关内容。 希望对您的学习有所帮助。
本文来自于微信公众号电力电子系统应用智库,由火龙果软件Linda编辑、推荐。

导言:功能安全相关标准要求系统电子电气相关故障,不会造成相关人员伤害,为了满足相关要求,汽车电子等安全相关控制系统架构设计要基于功能安全概念,确保系统安全可靠;自动驾驶,电气化,中央集中式电子电气架构等技术的发展,各种功能和区域融合的域控制器应用增多,进一步要求系统在出现失效后,能够继续可运行,进一步提高安全性。在开发电子电气控制系统时,选择合适的系统架构,在安全性,可靠性和成本之间做出最合适选择,本文阐述了包含诊断的不同系统架构,比较了其特点,用于在设计时选择合适的架构进行设计。

01 系统架构模型

功能安全相关标准中在开展系统设计之前, 都会提到Item Definition, 其含义是指要定义和描述所开发项目的功能,对用户,环境(条件)和车辆中其他项目的依赖关系和交互(接口);而一个item通常由一个或者多个系统组成,一个系统应该至少包含一个控制器,一个控制计算单元和一个执行器。

输入是指传感器数据,通信数据;控制计算单元执行控制操作和预期功能,输出是指由控制单元控制的执行器,会对外部环境产生影响。

为安全关键系统(safety critical system)选择诊断架构时,要充分考虑系统是否需要诊断通道,以及需要什么样的诊断,以确保系统在发生失效后,不会产生对相关人员的危害。具有诊断系统的架构通常用MooN(D)来表示,称为N选M架构。

MooN(D): M out of N with diagnostic,表示N个通道冗余时,取其中M个通道进行逻辑处理,其中M表示需要执行安全功能的通道数,N代表整个可用的通道数,当N大于等于2时,对应架构是一种冗余架构。

例如,如果有三台发动机的喷气式飞机,只要有两台发动机工作正常即可保证安全飞行和降落,这是一种2oo3架构设计概念的应用。

02-a 1oo1 系统架构特性

1oo1: 1 out of 1,一选一架构,单通道模式架构;系统中各组件之间为串联模型逻辑关系。系统中没有冗余也没有保护模式,对系统中各组件的失效模式没有保护能力;系统中任何单个要素失效时,既可导致安全失效(输出开关断电导致回路开路),也可以导致危险失效(输出开关短路导致外部回路不能断开),只要产生任何危险失效,就会导致安全功能失效。

该架构安全性较低,只能用于系统基本功能实现,不能满足fail-safe或者fail-operational系统的设计要求。

该架构为最简单的投票逻辑,只有一个通道,没有冗余,因此无法提供故障容错能力;适用于对安全要求不高的场景,但其成本最低。

02-b 1oo1D 系统架构特性

1oo1D: 1 out of 1with diagnostic,一选一诊断架构,功能链路与诊断链路形成双通道系统;系统使用带有诊断能力的单一控制器通道,与诊断功能形成的第二个通道串联构成输出回路。

一选一诊断系统,功能相当于一种二选一系统,这种系统造价相对低廉,所以这种系统在安全应用中扮演了重要的角色。汽车分布式电子电气架构下,大部分独立ECU的架构都采用该系统架构,兼顾系统安全性和成本。

该架构由一个逻辑处理单元和一个外部的监控单元构成,诊断的输出与逻辑控制计算单元的输出形成串联操作模式,该架构可用于fail-safe的系统设计。

车载EPS(电动助力转向系统)的系统架构就属于这种1oo1D的架构,实现了安全性与成本的兼顾。

引用:Infineon

02-c 1oo2 系统架构特性

1oo2: 1 out of 2,二选一架构,双通道并联操作模式架构;只要任何一个通道功能正常,系统就能够维持安全功能(使系统能够进入安全状态)。

只有两个通道同时发生危险失效,才可能导致在要求时某个安全功能失效;此架构中任一通道发生开路失效时,系统处于常开状态;如果系统的安全状态为断开输出回路,此时系统进入安全失效状态,即fail safe;但由于系统处于断开状态导致系统不可用,所以这种架构不能满足fail operational系统设计的要求。

02-d 2oo2 系统架构特性

2oo2: 2 out of 2,并列双通道串联模式架构;在物理结构上为并列双通道,逻辑结构上为串联的架构模型(针对安全功能来说); 假设系统输出端开路为安全状态,该系统对危险失效很敏感,只要任何一个通道发生危险失效,系统将会发生危险失效(不能进入安全状态)。

这种架构系统要实现功能安全时,系统中两个通道都要求安全功能;此架构中任一通道发生开路失效时,系统还能通过另一通道维持运行;但当任一通道发生短路失效时,系统处于常闭状态,如果系统的安全状态为断开输出回路,那么系统将会发生危险失效,所以2oo2架构不能满足fail operational 系统设计要求。

1oo2系统能够降低系统发生危险失效(fail positive)的概率,2oo2系统能够降低系统发生安全失效(fail negative)的概率(即降低误停率);1oo2架构让危险失效发生的难度加大,2oo2让安全失效发生的难度加大,这两种架构都只能对单一的可靠性指标进行改进。

02-e 1oo2D 系统架构特性

1oo2D: 1 out of 2 with diagnostic,二选一诊断架构,双通道并联表决操作模式架构;此架构由并联的两个通道构成,两个通道都要求满足安全功能设计;如果任一通道中检测到一个故障,则将采用输出表决,这种情况下,系统输出状态按照另一个通道给出的输出状态;如果检测到两个通道都故障,或者检测到不在任一通道的故障范围时,系统进入安全状态。

此架构中任一通道的基本功能路径开路(如通道1),系统还可以通过通道2维持系统运行;如果架构中任意通道的基本功能路径短路(如通道1),此时通道1的诊断路径检测到故障后,会把通道1回路断开以免发生危险失效;同时系统以通道2继续维持系统运行;1oo2D架构把1oo2和2oo2架构的优势都整合在一起,可以实现fail operational 系统设计要求(没有同时发生两路失效)。

随着自动驾驶和智能底盘技术的不断演进,传统EPS会发展为双EPS(如下图架构),双EPS即为典型的1oo2D架构,可以实现fail operational 的系统设计要求。

02-f 2oo2D 系统架构特性

2oo2D: 2 out of 2 with diagnostic,双通道并联表决操作模式架构;此架构由并联的两个通道组成,两个通道都要满足安全功能设计(两个通道都进入安全状态,系统进入安全状态);两通道的结果会进行比较,以确定是否相等,由于每个通道都具有自诊断能力,因此如果结果不相等,则可以检测出来故障路径,此时,系统通过使用正确的路径保持失效运行。

相比较于2oo2架构,2oo2D架构增加了通道诊断,使安全功能的操作模式从串联模式更新到了并联操作模式,即在2oo2架构中,任一通道发生短路失效,则系统无法安全断开,到2oo2D架构时,任一通道发生短路失效,由于诊断回路的存在,系统仍然可以安全关断,因此2oo2D架构可以实现fail operational系统设计要求(没有同时发生两路失效)。

02-g 2oo3 系统架构特性

2oo3: 2 out of 3,三选二架构,三通道并联表决操作模式架构;三选二架构顾名思义就是该架构采用三重冗余,可以同时防止危险失效和安全失效的发生,该架构在降低系统发生危险失效概率同时,也提高了系统的可用性,实现了安全性可用性双重保障。

2oo3架构的输出信号具有多数表决机制,其中一个通道的输出与其他两个通道输出状态不同时,输出状态不会因此而改变,即只要系统中两个通道运行正常,系统就能够维持正常运行;此架构相当于三路串,并联操作模式结果(通道1&通道2,通道2&通道3,通道1&通道3)加上对应的表决逻辑组成。

此架构中任意通道开路(如通道1),系统可以通过通道2&通道3维持系统运行,此时系统架构由2oo3变成了1oo2; 此架构中任意通道短路(如通道1),此时系统有2oo3变成了2oo2架构,但依然可以通过通道2&通道3维持系统运行;2oo3表决架构实现了1oo2架构和2oo2架构的混联,可以实现fail operational系统设计要求(只发生一路故障)。

汽车相关电子电气控制系统一般不会用到如此复杂的系统架构,但是在航空航天,飞行器等行业,这种系统架构就会非常有必要。

03 相关概念澄清

上述系统架构属性定义中用到了若干失效后保证安全的概念,以下对这些概念进行解释:

03-a 失效安全

失效安全:fail safe,是指一个设备或者事物,即使在特定失效下,也不会造成对人员或其他设备的伤害。

对应架构设计的基本原则:系统及其主要组成部分(传感器,电子控制单元,执行器)由各种诊断功能监控,如果发生故障,系统将关闭(shut off)输出回路,以使得系统进入安全状态,这意味着系统要在发生危害事件前进入安全状态,对应的ISO 26262有FTTI的指标定义。

应用示例:

自动驾驶:低级别自动驾驶车辆(L2级)相关的安全ECU大都是Fail safe设计,失效安全的系统不表示系统不会失效或者不可能失效,失效安全的系统是指在失效后避免或者减轻其不安全的结果;

电池管理系统:当电池管理系统检测到电芯电压过压时,断开高压回路使得电池包系统进入安全状态;

激光雷达控制单元:激光雷达控制单元检测到激光发送模块温度超过预设的安全限值时,控制激光停止发射,电机停止转动,使得雷达进入安全状态;

电机控制器:当电机控制器检测到系统发生抛负载等过压时,控制栅极隔离驱动器断开对功率模块的驱动,使得系统进入安全状态;

智慧工厂机器人作业区防护门解锁装置:当有人进入作业区时,会出发连锁信号机器人控制器收到信号后,控制机器停止作业,确保系统失效安全;

03-b 失效可运行

失效可运行:fail operational,系统出现故障情况下,如果系统无法通过功能关闭来达到安全状态,则有必要使系统继续运行并维持在可控的活动状态;比如线控制动系统,需要保证其较高的可用性,其故障和关闭制动功能导致的结果一样,故此系统不能通过功能关闭来达到安全状态,而是要保证制动功能故障后系统可运行;

失效可运行对自动驾驶系统至关重要,因为要同时保证系统安全性和可用性,通过失效可运行架构可以确保。

Fail Operational安全架构可以通过多样性冗余或者同质冗余架构来实现:

多样性是通过两个或者多个不同硬件和软件应用程序来实现,这些应用程序由不同公司或者开发团队开发,或者基于不同的规范;

同质冗余系统中,硬件由同一家公司和同一开发团队开发,软件由两个或者多个相同的设计实例生成;

随着汽车自动系统逐步发展到L4或者L5, 对驾驶员的依赖性逐渐降低,需要车辆具有足够的冗余性和多样性,即使检测到故障也能继续全面运行。

除了冗余,可靠性设计中的降额设计也是一个非常好的设计手段,可以降低系统失效率,提高系统寿命,使系统对故障容忍度更高,对系统的可靠性,可用性和安全性都能做出贡献。

03-c 失效静默

失效静默:fail silent,类似于机械领域的Muting(抑制/静默)机制。

传统IT服务器操作系统容错架构设计也会用到该设计:调用服务失败后,就默认该服务一定时间内无法再对外提供服务,不再向其分配请求流量,将错误隔离开来,避免其对其他服务产生影响;比如:经常超时的服务可以使用fail-silent容错机制,防止请求堆积而消耗大量线程,内存,网络等资源,进而影响到整个系统稳定.

ADAS系统中,当智能驾驶域控中的某个冗余通道故障时,出于fail-operational的目的,将该故障通道功能抑制/静默,此时该故障通道就处于fail Silent状态。

03-d 失效安保

失效安保:fail secure,信息安全保护措施,强调的是信息系统的安全状态,是指信息系统失效时不会将资料或者存取权落入坏人之手。

某些情形下,fail secure和fail safe导致的结果完全不同,比如大楼失火时,fail safe系统会自动开锁,让人员快速逃出,消防人员可以尽快进入;而fail secure 系统会自动上锁,避免未授权人员进入建筑物。

04 系统架构特性总结

系统架构是指控制系统组件的不同拓扑和设计,相同的系统组件,通过不同的拓扑和设计,可以组成不同的系统架构。

工业中常用的系统架构及其属性如下图所示:

引用:《Control Systems Safety Evaluation and Reliability》

安全故障容错:表示为保持安全(避免故障危险状态)而存在的额外单元数量;

可用性故障容错:表示为保持可用性(避免故障安全状态)而额外存在的单元数量。

分布式汽车电子电气架构下,独立ECU通常采用1oo1D的系统架构,确保系统的高安全性;自动驾驶要求下,安全关键系统需要采用1oo2D系统架构,确保安全性和可用性兼顾;而MooN(D)定义下N大于等于3的系统架构一般用于航空航天相关应用中。

   
次浏览       
 
相关文章

CMM之后对CMMI的思考
对软件研发项目管理的深入探讨
软件过程改进
软件过程改进的实现
 
相关文档

软件过程改进框架
软件过程改进的CMM-TSP-PSP模型
过程塑造(小型软件团队过程改进)
软件过程改进:经验和教训
 
相关课程

以"我"为中心的过程改进(iProcess )
iProcess过程改进实践
CMMI体系与实践
基于CMMI标准的软件质量保证

最新活动计划
DeepSeek大模型应用开发 6-12[厦门]
人工智能.机器学习TensorFlow 6-22[北京]
基于 UML 和EA进行分析设计 6-23[北京]
嵌入式软件架构-高级实践 7-9[北京]
用户体验、易用性测试与评估 7-25[西安]
图数据库与知识图谱 8-23[北京]
 
 
最新文章
iPerson的过程观:要 过程 or 结果
基于模型的需求管理方法与工具
敏捷产品管理之 Story
敏捷开发需求管理(产品backlog)
Kanban看板管理实践精要
最新课程
基于iProcess的敏捷过程
软件开发过程中的项目管理
持续集成与敏捷开发
敏捷过程实践
敏捷测试-简单而可行
更多...   
成功案例
英特尔 SCRUM-敏捷开发实战
某著名汽车 敏捷开发过程与管理实践
北京 敏捷开发过程与项目管理
东方证券 基于看板的敏捷方法实践
亚信 工作量估算
更多...