精品译文 | 现场可编程逻辑门阵列(FPGAs)在安全关键系统中的安全性认证(上)

汽车安全 2年前 (2022) admin
519 0 0

SASETECH


是国内首个由汽车安全专家发起组建的技术社区,致力于为汽车安全的从业者提供交流、学习、合作的中立性平台。


精品译文 | 现场可编程逻辑门阵列(FPGAs)在安全关键系统中的安全性认证(上)


精品译文 | 现场可编程逻辑门阵列(FPGAs)在安全关键系统中的安全性认证(上)


译文

现场可编程逻辑门阵列(FPGAs)在安全关键系统中的安全性认证(上)

关键词:现场可编程逻辑门阵列、可编程序逻辑、安全认证、安全评估、安全标准


原文:ARGUING THE SAFETY OF FPGAS WITHIN SAFETY CRITICAL SYSTEMS


作者:J.R.Clegg


译文审核:Erik Tang

➡本文分为上下两部分,第一部分(约5600字,23钟阅读)



1

引言

近年来,FPGA在安全关键/相关系统中的应用呈增长态势,如包括发动机控制系统及燃料控制系统在内的一系列飞机系统。通常来说,安全关键/相关系统在使用之前需要进行认证。尽管认证过程取决于领域特定的各类标准,但仍然存在部分共通的实践和过程。一般来说,这些标准应包含旨在避免或减轻危险故障的过程,包括因使用FPGA而造成的故障。目前已有一些针对包括FPGA在内的可编程电子设备的标准。


系统安全分析的两个关键要素是危险识别和故障目标以及安全要求(SRs)的推导。前者并非带有FPGA的系统专属。后者能够通过故障分析得到解决,这是因为故障分析能够明确错误(fault)的影响,并阐明错误与危险之间的联系。一旦对FPGA进行编程,它就会变得非常复杂,同时,要想确定FPGA错误/故障对安全关键/相关系统的影响也是困难重重。许多不同的领域都可能发生错误/故障。即使科研人员已对相关领域的错误/故障进行了大量的研究,但还没有能够将这些领域整合起来。换言之,目前还缺少全面的安全论证手段。


本文讨论了如何将错误/故障引入FPGA以及适用的缓解技术(mitigation technique)中,并以此为基础确定如何将认证组合起来,以证明FPGA达到了安全要求。



2

可编程序逻辑和现场可编程门阵列


现场可编程门阵列作为可编程序逻辑

本质上来说,FPGA属于逻辑块阵列,由连接到引脚的输入/输出(I/O)块包围,通过可编程互连将逻辑块彼此相接并连接到输入/输出(I/O)块。查找表(LUT)与相关存储元件控制逻辑块的功能,这与互连编程和配置输入/输出(I/O)块共同决定着FPGA的功能。


目前正在使用的FPGA技术主要有三种:反熔丝(Anti-fuse)、带电可擦可编程只读存储器(EEPROM)/闪存以及静态随机存取存储器(SRAM)。反熔丝和EEPROM FPGA具有非易失性,EEPROM和SRAM FPGA可重新编程,SRAM FPGA更容易受到单粒子效应(SEE)和电源故障的影响,但通常在技术层面上更为先进。在设计FPGA时,可以选择购买常用组件的设计。这样一来,我们就能将其纳入FPGA设计,且不透露组件设计细节,也就是我们常说的知识产权的核心(通常简称为IP)。我们能对IP进行一定程度的配置(例如,定义内存IP核的大小)。此外,许多调制解调器FPGA还包含芯片上的硬件资源(例如处理器、内存等)。



现场可编程门阵列设计过程

在过去,人们将目前称为大型FPGA设备的前身纯粹等同于硬件,并通过原理图攫取(schematic capture)以及梯形逻辑(ladder logic)等方法对其进行编程。虽然这些方法使设计者能够将此类些相对简单的设备的操作过程可视化,但是,由于调制解调器FPGA体型更为庞大,构成更为复杂,此类方法已不适用。通常,调制解调器FPGA通过硬件描述语言(HDL)或高级程序语言(HLL)来表示逻辑的复杂性,这种复杂性与软件程序相当。与软件一样,这种复杂性增加了设计故障(设计bug)的可能性。


FPGA设计流程中会产生一个比特流,并被加载到FPGA上。关键阶段包括:

  • 设计截取:通常为HDL或HLL;

  • 设计合成:将设计转化为一个结构网络表(structural netlist),从而识别门、寄存器和两者之间的联系,以及芯片上的所有硬件元素;

  • 映射:将结构网络表映射到定义其功能的FPGA和LUT的逻辑块上;

  • 布局与绕线(place&route):确定逻辑块/互连的物理位置,并生成比特流。


上述阶段具体命名及功能会在一定程度上因FPGA制造商和工具供应商不同而不同。此外,合成、映射和布局与绕线工具给予了设计人员一定自由度,使他们能够在一定程度上决定如何将设计指派给FPGA资源,并在芯片上进行布局。这些工具允许IP进行合并,并与芯片上的任何硬件资源连接。


所有的设计和研究步骤包含一系列的验证活动(verification activities)。主要验证活动包括:

  • 仿真:模拟FPGA对输入集的响应;

  • 时序分析:基于输入时序约束的静态分析;

  • 形式分析:严格证明设计属性;

  • 编程设备验证:演示硬件能够在预期环境中工作。



3

电子硬件安全标准

DO-254 [11],IEC 61508 [1] 的第二部分以及国防标准(DS) 00-54[9]等关键标准适用于在安全关键/相关系统中开发FPGA的情况。这些标准的作用在于证明FPGA能够在其预期环境中安全工作。目前正在为IEC 61508开发FPGA附件。虽然DS 00-54为DS 00-56 Issue 4所逐渐取代[10],但它仍在使用。


上述三个标准都依赖于设计保障等级(DAL)或安全完整性水平(SIL)来确定所需的置信度水平(level of confidence),以及根据该保障/完整性水平需要执行的活动。值得注意的是,不同标准使用的DALs和SILs不可直接进行比较。对于所有这些标准而言,所需的保障等级越高(即应用程序越关键),所需的证据就要越有力。


基于完整性,以上这些标准都为应用于FPGA的活动和技术提供了框架和指导。DSOO-54[9]特别注重安全案例的生成,但更具规范性,且在某些方面要求过于苛刻(比如要求除最低级别外,所有完整性级别都需要形式分析)


以上三个标准均属于基于过程的方法。韦弗(Weaver)[14]表示,这些标准还“容易混淆实现安全水平和确保安全水平这两个概念”。韦弗认为[14],这些标准重点在于确保设备的完整性,而非用于呈现其安全水平,尽管产品分析这一步骤具有强制性,或是我们所倡导的。然而,这些标准规定或建议的许多活动与基于安全论证的方法具有共通之处。


有一个比较容易造成混淆的问题是FPGA究竟属于硬件还是软件。虽然FPGA由硬件组件构成,但其复杂的逻辑通常在HDL或HLL中捕获。HDL是类似于软件的语言;用于硬件设计的HLL则属于软件编程语言或者其变体。开发安全关键软件的标准,例如DO-I78B[12]、IEC 61508[1]的第三部分,或许适用(第4.1节)


任何安全关键FPGA都是包含安全关键功能的系统的组成部分,并需要相关认证机构适当对其进行认证。目前有几个标准能对认证过程起到控制作用,尽管这些标准通常应用于特定领域。这些标准还涉及系统级的安全演示,这将影响FPGA安全论证(safety demonstration)的方式。用于防御和飞机系统的主要标准包括IEC 61508[1]、DSOO-56[10]和ARP4754[13]。



4

现场可编程门阵列与安全性

FPGA故障有可能给其所属的安全关键/相关系统带去危险后果。FPGA故障原因有很多,可以根据故障来源进行分类:

  • 设计:设计不当;

  • 实现:由设计、加载到FPGA和运行已编程的FPGA中生成比特流导致的故障;

  • 构建:FPGA生产或内置到系统时的物理故障;

  • 磨损:由持续使用或储存而引起的物理故障;

  • 外部原因:FPGA工作的外部环境引起的故障。


假设对FPGA的要求是正确的,与需求有关的争论是一个更普遍的问题。下面将讨论导致故障或者故障发生的方式以及可能的缓解措施。



现场可编程门阵列设计错误与缓解措施(Mitigations)


FPGA设计通常在HDL中捕获,最常用的HDL有VHDL和Verilog。HDL的主要问题与大小/复杂性、引入错误以及缺乏形式性相关联。HDL相对低级这一性质增大了设计的规模和复杂性,因此出现了倾向利用HLL(SystemC、 Handel-C、Esterel)来捕获FPGA设计的趋势。


DO-254[11]提醒,表面上HDL/HLL代码类似于软件,这或将误导开发人员直接在设计表示时采用软件验证方法。HDL/HHL与软件编程语言之间存在显著差异,比如,多并行进程与单线程软件的差异。软件标准(第三节)中提到的大部分过程和衡量因素(consideration)都可应用于HDL/HLL代码的开发,目的是为设计表示的正确性建立置信度。然而,要注意的是,HDL/HLL代码的执行只是模拟了硬件设备。也就是说,仅用软件方法是不够的,还需要其他技术支持,如时序分析、程控装置验证。


有许多验证技术都可用于证明设计能够满足相应的要求,包括:

  • 查核:通常需要手动执行,也有一些工具可起到辅助作用;

  • 模拟:关键问题在于需要大量测试用例以完全覆盖设计;

  • 时序分析(timing analysis):利用更高级别的设计描述,可以进行一些有限的时序分析,但这取决于相关设备性能的假设;

  • 断言验证(ABV):明确表达规定设计中特定点的代码属性的设计意图。利用形式分析和仿真过程能对这些代码属性进行检查。设计者与ABV作者间应相对保持独立。

  • 形式方法:根据需求衍生的规范(“性能检查”)或已知的可信设计(“等价性检验”)对设计进行形式验证。DSOO-54第2部分[9]指出,“没有形式语义的HDL存在遵从性问题,比如VHDL和Verilog。”


任何应用的IP都需要有适当的置信度。IP开发过程的严格程度应与预期用途相称(CAST-27[2])。一般来说,商用IP的内部设计是不可见的,所提供的文档也有限,这给验证过程带来了一些问题。一种可行的方法是在形式上指定IP属性,这些属性必须为真,以确保FPGA的安全性,然后对其进行形式验证。目前,有许多“开源”硬件内核可获取使用。虽然这些产品不足以满足SR的标准,这是因为开源内核通常可以在VHDL或Verilog中使用,但可以通过对内核进行额外验证以满足SR。深入研究这些方法的实用性将有利于其他相关领域的发展。



现场可编程门阵列执行错误及缓解措施


一般来说,需要手动将HLL需要转化为可合成的HDL。尽管有人声称HLL可以自动生成HDL,并且已有一些辅助工具可加以利用,但这种性能尚不普遍。我们可以对VHDL和Verilog在更高的抽象级别上进行编写(称为行为HDL),这同样需要经历转换为可合成的HDL的过程。


通过可合成设计生成FPGA比特流需要一套复杂的工具,该工具具有一系列选项,能够执行合成、映射和布局与绕线等任务。这些复杂的工具存在一定风险,可能会导致错误发生,因此这些工具需要具备足够资质,以达到一定的置信度。欧洲航天局(European Space Agency,ESA)对多个FPGA设计进行审查[5],发现了一些与所用工具相关的问题。设计者需要注意的是,他们不仅要了解这些工具的操作方式,还要对输出进行验证。Katz[7]引用了几个例子,其中综合设计与设计者的预期存在出入。


目前,有许多验证工具和技术旨在证明比特流能够真实地呈现设计,包括:

  • 时序分析:附加的时序和延迟信息提高了时序分析的准确性。

  • 模拟:可以在不同实施阶段的输出上进行模拟。

  • 形式分析:通常根据捕获的已被证实是正确的设计进行形式分析。

  • 程序化设备验证:演示如何正确操作程序化FPGA。



现场可编程门阵列安全硬件故障及缓解措施


FPGA芯片的选择会对芯片硬件故障的可能性产生影响。芯片硬件故障由芯片内部故障或外部环境引起。Isaac[6]罗列了一些影响FPGA的常见和特定失效机制(failure mechanism),并在经验中得到证实,涵盖了设计问题、辐射(SEE)、管脚连接(pin connection)、功率、信号上升时间和状态机等。这里列出的失效机制均与磨损或外部环境有关。


针对FPGA芯片故障的缓解措施包括制造商数据、先前经验及测试。针对SEE,可以使用容错体系结构(fault tolerant architecture),例如三重模块冗余(triple modular redundancy)。为确定最恰当的缓解措施,我们首先需要明确这些错误/故障会对系统造成何种风险。截至目前,还没有公认的技术可以在不做悲观假设的情况下处理FPGA的规模和复杂性。


分析过程中最重要的是要识别所有FPGA的块或互连的重大故障,并确定这些故障的影响。FPGA是并行设备,包含许多并行运行的块,因此一个重要的衡量因素是对时机和并发性的处理。在没有工具支持的情况下,分析具有多个门的FPGA并不符合实际。已有许多研究人员通过研究确定FPGA响应故障的方法和工具。


比如Conmy和Bate[4]探索了利用故障传播与转换演算(Failure Propagation and Transformation Calculus,FPTC)来明确故障是如何通过FPGA进行传播的。利用FPTC对部件网络的故障特征进行建模,该部件网络由FPGA网表推导而来。随后用于识别单个故障的影响,例如由SEE引起的故障。为增大该网络的实用性范围,我们还需要执行额外命令,将过程和结果分析自动化。



现场可编程门阵列工具


复杂精密的工具在FPGA开发中起着重要作用。对于所使用的工具,标准DO-254[11]、IEC 61508[1]的第二部分和DSOO-54 [9]都做出了相应规定,通常取决于DAL和SIL。通常情况下,我们需要将独立评估(independent assessment)、相关历史、分析以及测试等过程结合起来。很多工具是专有的,因此工具供应商可能无法提供足够的信息,从而缺乏资质。工具的开发首先考虑商业市场,因此通常无法达到安全关键应用所期望的完整性。



5

参考文献

[1] British Standards, “Functional safety of electrical! 

electronic/programmable electronic safety-related systems”, IEC 61508 (Part 0, 2005; Parts 1-7, 2002) 


[2] Certification Authorities Software Team (CAST) Position Paper CAST-27. “Clarifications on the Use of RTCA Document DO-254 and EUROCAE Document ED-80, Design Assurance Guidance for Airborne Electronic Hardware”, Rev 0, (2006) 


[3] J. R. Clegg, “Arguing the Safety of FPGAs within Safety Critical Systems”, MSc Project, University of York, (2008) 


[4] P. Conmy, I. Bate. “Semi-Automated Safety Analysis for Field Programmable Gate Arrays”, 16th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems, pp. 166-175, (2009). 


[5] A. Fernandez-Leon. A. Pouponnot, S. Habinc, “ESA FPGA Task Force: Lessons Learned”, MAPLD International Conference, (2002) 


[6] T. A. Isaac. “Firmware in Safety Critical Applications”, 

Proceedings of the 22nd International System Safety 

Conference, (2004) 


[7] R. Katz. “This Is What We Find In This Stuff: A Designer Engineer’s View”, National Software and ComplexElectronic Hardware Standardization Conference, (2005) 


[8] T. Kelly. “A Six-Step Method for Developing Arguments in the Goal Structuring Notation (GSN)”, (1999) 


[9] Ministry of Defence. “Requirements for Safety Related 

Electronic Hardware in Defence Equipment”, Interim 

Defence Standard 00-54, Issue 1, (1999) 


[10] Ministry of Defence. “Safety Management 

Requirements for Defence Systems”, Defence Standard 00-56, Issue 4, (2007) 


[11] RTCA Inc. “Design Assurance Guidance for Airborne 

Electronic Hardware”, RTCAIDO-254, EUROCAE ED-80, (2000) 


[12] RTCA Inc. “Software Considerations in Airborne 

Systems and Equipment Certification”, DO-I78B, (1992) 


[13] SAE, Certification considerations for Highly-Integrated or Complex Aircraft Systems, ARP4754, (1996) 


[14] R. A. Weaver. “The Safety of Software – Constructing 

and Assuring Arguments”, DPhil Thesis, Department of 

Computer Science, University of York, UK, (2003)


…(未完待续)…


免责声明:如涉及侵权请及时与我们联系反馈,我们会在第一时间做更正声明或做删除处理。文章版权及解释权归原作者及发布单位所有,仅供参考学习。

往 期 精 选

“符合ISO 26262标准的故障可运行的汽车系统的安全论证(上)”

“符合ISO 26262标准的故障可运行的汽车系统的安全论证(下)”

“汽车SoC功能安全最佳实践与挑战Part2”

JOIN US

精品译文 | 现场可编程逻辑门阵列(FPGAs)在安全关键系统中的安全性认证(上)


SASETECH致力于推动功能安全、预期功能安全、信息安全在行业内外的影响力,成为国内广有影响力的公益型安全社区。“建立安全生态圈,成为汽车安全的布道者”是我们的使命,“专业创新、开放共享、实事求是”是我们的共同价值观。在过去的半年多时间里,得益于大家的关注和支持,我们的技术社群不断发展壮大,现已有超1000人的加入,3000人的持续关注,覆盖影响了上万名安全从业者,并成功举办了22场线上专家讲坛,3场线下沙龙,8场线上沙龙,公众号精编推文90余篇。在现有工作基础上,未来我们将陆续展开安全行业大型线上WIKI、基础导读文章框架等项目。


SASETECH

(扫描二维码加入交流群)

精品译文 | 现场可编程逻辑门阵列(FPGAs)在安全关键系统中的安全性认证(上)

原文始发于微信公众号(sasetech):精品译文 | 现场可编程逻辑门阵列(FPGAs)在安全关键系统中的安全性认证(上)

相关文章

暂无评论

您必须登录才能参与评论!
立即登录
暂无评论...