学习路线:
这个方向初期比较容易入门一些,掌握一些基本技术,拿起各种现成的工具就可以开黑了。不过,要想从脚本小子变成黑客大神,这个方向越往后,需要学习和掌握的东西就会越来越多以下是网络渗透需要学习的内容:
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
独立性理解为:
分解后的两个或者多个功能之间不存在共同的导致初始安全需求被违背的失效来源或者该类型的失效能够被合理的安全机制覆盖;
注意,标准不仅要求对分解后的安全功能之间做共因失效分析,用于评估安全机制的有效性也需要做分析(预期功能与安全机制之间的独立性)。
要素共存的需要,如果在系统或者软件层面存在不同安全级别或非安全的功能运行在同一块资源区间,则需要保证低安全等级的功能失效不会导致高安全等级的功能失效,或者该失效类型能够被合理的安全机制覆盖。
以上独立性的要求,可以被概括为避免共因失效(Common Cause Failure)和避免级联失效(Cascading Failure),这两类失效通常由FTA及FFI分析后识别,通过DFA分析才能确认分解后的元素完全独立。
失效安全(Fail safe)
失效静默(Fail silent)
失效运行(Fail operational)
及紧急运行(Emergency operation)
在考虑不同产品的功能失效时,需要基于产品功能的可用性要求,在行业内,经常会有如下几个关于安全架构概念阶段的名词,用于定义产品架构级别的失效属性,从而判断该采取哪一种设计作为安全状态。
失效安全(Fail safe):是指一个系统失效后特定功能关闭能够让系统维持在安全状态。例如,对于发动机管理系统的避免非预期扭矩输出这个安全目标,可以考虑采用关闭发动机扭矩输出作为安全状态。或者对于L2及以下的自动驾驶系统功能,也通常考虑采用关闭该特定功能作为安全状态。
失效静默(Fail silent):失效静默类似于失效安全,但是通常理解为系统失效后的一种状态属性,失效静默表示系统失效后对外表现为静默状态,不对其他的功能和输出产生干扰。该词汇用于描述功能失效后的影响,不常用于安全状态定义。
失效运行(Fail operational):如果一个安全状态无法通过功能关闭来实现,而是要保证系统的可用性,那么就需要选择失效运行作为其安全状态。例如对于L4及以上的自动驾驶系统,如果设计要求系统失效后车辆依然可以按照既定的操作进行自动驾驶,则需要设计一套冗余的控制系统,在主控制系统失效后,Fallback系统能够及时接管车辆在既定的ODD运行。类似失效运行的概念,还有失效降级(fail degraded, fail partial),通常对于有失效后可用性要求,又不需要完整的冗余接管的系统,例如,对于车辆灯光控制系统的防止近光灯非预期的完全关闭,这个安全目标需要考虑通过双电源和日间行车灯对近光灯的冗余,保证失效后至少有一个近光灯或者日间行车灯对路面进行照明。
紧急运行(Emergency operation):这个术语不等同于失效运行。紧急运行是指如果安全状态无法在可接受的时间内实现,则需要定义一个紧急操作,让系统在FTTI时间之内能够顺利的过渡到安全状态。这里的安全状态可能是指fail silent或者fail operational。例如,对于L3级别的自动驾驶系统,如果MRC作为系统的安全状态(fail silent),那么fallback系统的MRM功能则可以定义为紧急运行。
限于篇幅,对于概念和系统阶段其他的术语笔者不作展开,主要阐述在安全架构设计时应当考虑的几个基本点,即:
如何分配安全需求;
如何考虑安全分解;
如何考虑安全状态设计。
在开展具体的安全架构设计时,还需要充分地参考安全标准具体要求。
03 E-GAS三层架构的理解及使用约束
早期从事功能安全的同行对汽油发动机管理系统的E-GAS三层安全架构应该都有了解。虽然该架构并非为实现功能安全而专门设计,但是该架构提供了一个很好的应用安全分解的解决方案。基于目前市场上的类似电控系统设计,该架构基于Lockstep Core设计可以支持到最高ASIL D级别的设计要求。
图3.1-E-GAS三层安全架构带LC示意图
(图片来源参考文献[3])
对于三层架构,如果运用安全分解策略,我们应该要注意:
a. L2层级的安全控制功能的输入需要独立于L1层级,以保证两者的独立性;
b. L2可以对L1层级的输出信号进行诊断,诊断输出控制应该独立于L1的输出控制,能够直接对系统进行关断控制,以保证安全状态控制的独立性;
c. L2 也可以通过输入信号进行独立的功能诊断,诊断输出控制应该独立于L1的输出控制,能够直接对系统进行关断控制,以保证安全状态控制的独立性。
外部监控设备需要能够独立的对系统进行关断控制而不必依赖于L1或者L2的控制指令,用于避免L1和L2的相关性失效。
在考虑应用E-GAS架构时,对其安全分解策略并无固定要求,但是通常推荐采用QM(X) + X(X)的分解策略。主要考虑:
a. 如果系统功能设计已经比较成熟,而引入功能安全后,对该系统进行功能重构复杂程度高。因此采用QM(X) + X(X)的分解能够让系统设计本身保持QM的等级,而只是对安全要求进行冗余的设计,这样能够最小化的影响功能的稳定性。
b. 系统功能安全需求数量不多,并且该系统能够采用相对简单的策略对故障避免措施进行额外的冗余设计。这样能够最小化地增加开发成本。
c. L2 也可以通过输入信号进行独立的功能诊断,诊断输出控制应该独立于L1的输出控制,能够直接对系统进行关断控制,以保证安全状态控制的独立性。
例如,传统的三电系统,发动机管理系统,变速箱控制系统及车身控制系统皆可以采用上述架构。通过E-GAS三层架构,对安全的功能和系统控制功能进行合理的分解,再配合目前主流的英飞凌AURIX(带Lockstep)+SBC(ASIL D)硬件解决方案,能够高效快速的实现高等级的功能安全设计。除此之外,对于VCU, MCU等新能源汽车上的一些控制器,通过E-GAS三层架构来实现ASIL D等级的设计也是很多主机厂和供应商的优先选择。
需要注意的是,对于一个复杂的新系统开发,或者系统功能安全需求数量大且不易做安全分解的,则不建议首先采用E-GAS三层架构。例如,对于自动驾驶系统的域控制器及备份控制器开发,安全需求除了MCU本身控制功能之外,对于感知,定位和规划算法均有涉及,而SoC和MCU之间很难采取统一的安全监控架构。因此,即使采用E-GAS架构实施安全分解策略后,也需要做大量冗余功能及独立性设计,并不能获得很好的时间或者成本的收益。对于这样的系统,可以考虑直接对安全的功能路径进行对应级别的开发,并做好独立性设计。
04 ADAS系统安全架构设计
及安全等级的分解
在考虑ADAS系统的安全设计时,应当首先考虑该系统的自动驾驶等级以帮助判断该系统安全状态,参考SAE J3016定义:
图4.1-SAE J3016自动驾驶功能等级定义
(图片来源参考文献[2])
基于定义来看,如果一个ADAS功能定义在SAE LEVEL 2及以下,则驾驶员需要时刻监督系统的运行用于保证驾驶安全。那么在定义该系统安全状态时,可以考虑采用失效静默架构,当系统失效时,对功能进行关闭即可满足该要求。
而对于SAE LEVEL 3级别的ADAS功能,由于系统定义在发生失效后的一定时间内(通常规定10s及以上),系统仍然需要正确的执行DDT,或者进行功能降级运行状态。因此在考虑该系统的安全架构时,需要设计紧急操作或者失效运行功能(L4及以上)。当主控制器发生安全相关失效而又无法进入安全状态时,备份系统至少需要在规定时间以内保持动态驾驶任务并提示驾驶员接管。
值得注意的是,SAE 并没有要求自动驾驶系统设计必须要做完全的失效运行,只要求接管系统在系统失效时一定时间内能够让车辆到达最小风险状态。因此在考虑ADAS架构设计时,不一定需要考虑系统失效时还能执行完整DDT的能力,只需要考虑接管系统是否有能力通过功能降级及驾驶员未接管后由紧急运行使车辆最小风险状态即可。
L3及以上级别自动驾驶系统安全等级评估
从功能安全的角度出发,由于高安全等级自动驾驶系统允许驾驶员脱眼或者脱手,在评估某系统的功能安全目标时,部分危害事件S,E,C会评定为最高分,继而得到ASIL D级别的安全目标。而当安全目标被违背时,系统又无法通过功能静默直接进入安全状态,因此对于控制信号的可用性设计也会要求满足ASIL D。
当前市场上ADAS系统的设计有很多,各家都在自研架构,但是整体的功能安全目标及最高级别通常均为ASIL D。为了实现最小成本的解决方案,我们需要从系统架构层级,在满足安全要求的前提下尽量简化系统的设计。因此建议在基于SAE标准下的系统架构要素,用于功能安全需求的分解。例如,将fallback系统与Main系统进行冗余,将控制指令可用性失效需求分解由fallback和Main系统实现,考虑两者之间的独立性设计,及可以将部分的安全指标降级。本文将引入一个抽象的ADAS系统架构,用于描述功能安全ASILD级别在架构上的分解及分配关系。假设该ADAS架构抽象为如下图:
图4.2-L3+ADAS自动驾驶系统抽象架构
注意:在图4.2 架构中,为实现ADAS域控制指令的独立性,实现安全分解,将ADAS指令仲裁功能分配给底盘动力域控制器。在实际项目中,指令仲裁功能也可能由ADAS Main控制器实现,通过一定的机制实现自动指令转换,基于此结构,运动域控可以不需要;另外指令仲裁功能也可以集成在底盘域控系统中。对于执行器端的冗余设计,可以基于不同的ADAS功能和安全降级的要求进行必要冗余,而非横纵向完全冗余。执行器端具体方案在本文不做详细展开。
如果定义ADAS系统的整体安全目标简化为:
防止非预期的不能提供控制指令,ASIL D:
基于图4.2,Fallback系统作为Main系统的冗余系统,通过完全的冗余和独立可以将安全指令的可用性需求分解为ASIL B(D)即:
\1. Main 系统需要提供正确的横向和纵向控制指令ASIL B(D)
\2. Fallback 系统需要提供正确的横向和纵向控制指令ASIL B(D)
\3. Main 系统和Fallback系统的控制指令需要完全独立 ASIL D(独立性要求)
需要注意的是,Fallback和Main控制器需要”热冗余”。热冗余是指在Main运行过程中,Fallback也应当同时运行,主要用于减少主控制器失效时指令切换的时间。同时,从安全角度,两者对自身失效进行诊断以防止非预期的失效导致自身控制指令不可用,无论哪个控制器诊断出自身失效,ADAS系统需要在一次驾驶循环内进行MRM或者不允许ADAS功能下次激活
防止非预期的发出错误控制指令,ASIL D
基于图4.2,由于ADAS系统运行时主要由Main系统进行仲裁及整车控制,因此对于Main系统,其安全诊断级别应当做到ASIL D。
由于 Fallback的整车接管控制在Main失效后才会启动。因此,在考虑Fallback系统安全级别时,可以从如下角度考虑适度降低:
例如,如果我们定义SAE ADAS L4系统,在主系统失效后,Fallback系统接管后最大有效运行时间为1小时, 对Fallback接管功能做HARA分析:
\1. Fallback系统的失效造成严重度与Main系统失效相同 (S3);
\2. Fallback系统失效后可控度与Main系统失效相同 (C3);
\3. 在评估暴露度时,基于Fallback功能控车总共时长不超过1小时,相比较Main系统失效场景暴露度E,可以降低其指标,分析过程如下表:
表4.1-1 Fallback系统暴露度指标评估参考
➡发生永久性故障后接管系统的最大操作时间: 假定在最坏情况下,Main控制器在其操作时间内失效。
➡假定系统运行过程由于瞬态切换而累积的接管操作持续时间:假定主系统由于系统性原因或者SOTIF影响短暂切换到Fallback系统,恢复后退回Main控制器。考虑在1000小时的ADAS操作时间内,每小时切换3s。
基于以上分析,我们可以看到,对于fallback系统,其实际的operation time只占ADAS系统operation time不到1%, 因此,可以将其E值由E4降为E2。 继而,对Fallback系统发出错误的控制指令ASIL级别由ASIL D降为 ASIL B。
备注:1. 以上分析假定的前提为Main控制器与Fallback控制器完全独立,其指令仲裁在底盘系统中实施;2. HARA分析中对暴露度E值的评估方法与本文提及的降低策略有偏差,从本文的角度,实际上基于产品Operation time定义来降解,更多的是从降低随机硬件失效概率。对于Fallback控制器系统性失效,很多同行会认为需要按照原始等级(ASIL D)来实施。该分析仅做参考。
基于以上两点,可以简单总结ADAS系统的安全概念:
FSR-1: 在ADAS系统运行过程中,如果Fallback控制器诊断出自身失效,导致无法发出控制指令,Main控制器应当基于Fallback状态,控制系统运行一段时间或者进入MRC*。ASIL B(D) (FSR a,可用性设计,*这里也可以考虑在一个驾驶循环内持续进行DDT);
给大家的福利
零基础入门
对于从来没有接触过网络安全的同学,我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线,大家跟着这个大的方向学习准没问题。
同时每个成长路线对应的板块都有配套的视频提供:
因篇幅有限,仅展示部分资料
网络安全面试题
绿盟护网行动
还有大家最喜欢的黑客技术
网络安全源码合集+工具包
所有资料共282G,朋友们如果有需要全套《网络安全入门+黑客进阶学习资源包》,可以扫描下方二维码领取(如遇扫码问题,可以在评论区留言领取哦)~
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!