集成电路功能验证方法（共3篇）
集成电路功能验证方法 篇1
摘要：本文首先介绍几种传统的验证方法并剖析其优缺点, 然后针对基于仿真的功能验证引入提高验证效率的方法。从生成高质量测试向量和检测验证程度的完备性两方面介绍如何提高验证效率。
关键词：功能验证,基于覆盖率的方法,测试矢量
0 引言
随着半导体技术的发展, 芯片设计的规模和复杂度也不断增加。设计者在缩短设计周期同时, 还要尽可能保证芯片设计的正确性, 其关键的问题是设计验证问题。目前, 验证所花费的时间大约占集成电路设计周期的70%~80%。正确性验证已经逐渐成为大规模集成电路设计的主要瓶颈。当前验证面临的挑战主要有以下几个方面:
1) 巨大的验证空间;
2) 验证环境的可重用性;
3) 验证结果的数据一致性检查;
4) 验证工作结束的标志。
1 传统的功能验证
目前, 采用的验证测试方法主要有3类:基于参数的验证测试, 基于结构的验证测试, 和基于功能的验证测试。
功能验证不考虑电路的结构, 只考虑电路的功能流程, 在验证因果设计方案时是非常有用的。其仿真结果得到的测试向量还可以应用在检验生产厂家的产品上。目前针对微处理器的功能验证可分为基于形式验证的方法和基于仿真的验证方法。
1.1 基于仿真的验证
基于仿真的验证又称模拟验证, 其验证过程是将验证用的激励向量加载到待测系统上进行运行, 通过结果比较来验证待测系统的功能正确性。根据仿真结果检验方式的不同, 大致可分为协同仿真和自测检验两类[1]。
1) 协同仿真。协同仿真的方法是将激励信号同时赋给待测系统和参考模型, 并比较两个系统的输出是否一致, 判断待测系统的运作是否正确。理论上, 协同仿真的测试向量可以是任意代码。在实现时, 协同仿真的测试激励信号往往是系统以前版本积累下来的测试向量、应用程序或标准的Benchmark等。因此协同仿真的测试向量集更大, 可验证的逻辑更广。在获得待测系统响应输出的同时将待测系统的模拟运行状况记录下来, 通过覆盖率统计工具进行分析, 还可以获得验证的覆盖率[3]。
2) 自测检验。自测检验的方法是把带有自测性质的测试向量作为激励信号输入到设计方案中, 由运行结果体现系统行为。其测试向量包括两部分内容:执行某一特定功能的代码和对系统行为的判断。
1.2 基于形式的验证
基于形式的验证不采用传统的激励——响应机制, 是一种无向量的验证方法。形式验证主要通过数学分析的方法来判断某个设计是否在所有的输入或状态条件下能按预期的情况工作[3]。形式验证将需要检测的某个功能或设计缺陷抽象为一个公式或数学表达式, 然后将整个电路系统也用数学方法抽象为某个或某组数学表达式, 最后用数学的方法来证明前者是否满足后者。
1.3 基于断言的验证
基于断言的验证 (Assertion-Based Verification) 是一种半形式验证方法, 其中断言是一种主动性的注释, 能够监控信号、预测行为和禁止行为。在RTL级的验证中正确应用基于断言的验证方法最为有效。
目前, 形式验证的研究和开发应用还不完善, 尚不能作为一种验证方法独立使用。因此, 基于仿真的功能验证方法仍为当前普遍使用的验证技术。
2 提高功能验证效率的方法
基于仿真的功能验证的方法是在输入端将加载激励信号, 收集输出端的响应信号, 并对此做出分析。可见, 如何产生高质量的测试激励和如何判断待测系统验证程度成为功能验证的两个关键问题。
2.1 测试向量的生成
测试向量的生成主要有3种方法:手工编写、伪随机生成和针对流水线模型生成。手工编写测试向量的方法具有较强的针对性, 编写的测试向量较为精简, 对于系统中一些诸如边角情况等不易验证的功能点进行验证是十分有效的。但这种方法需要耗费大量人力和时间, 无法满足大规模集成电路验证的要求。
另一种生成测试向量的方法是伪随机方法。所谓的伪随机是指在给定的约束条件下, 大量生成任意组合的随机序列。该技术已成为当前研究的重点, 许多EDA厂商开发了相应的辅助工具集, 如Cadence公司开发的Test Builder等。通过伪随机的方法产生的激励既满足特定条件, 又可实现充分的随机性, 具有一定的可控性, 大大节省了编写测试激励的时间。但由于其随机性, 会产生冗余向量, 降低了验证的效率。
针对流水线模型生成激励的方式主要是在引起流水线冲突的条件下, 验证流水线冲突是否得到解决, 其针对性强, 效率较高。但无法验证由非流水线冲突引起的设计错误, 验证的完备性较差。
通过以上3种方法的比较可以看出, 对设计系统的验证单独使用某一种方法产生测试激励不能达到验证要求。所以在实际应用中, 应根据待测系统的具体情况合理运用3种方法生成高效的测试向量, 有效减少冗余向量, 达到提高验证效率的目的。
2.2 验证完备性的度量
基于仿真的功能验证方法由于受验证时间和电路复杂程度的限制, 无法穷举所有的激励向量, 因此验证程度是否完备成为验证的另一个关键问题。
传统的验证方法只能反映发现问题的数目, 无法体现验证程度, 因此验证人员无法把握验证进度, 这使得待测系统验证的目的性不明确。因此, 要想提高验证的有效性, 需要引入一个反馈环节来监视并提高验证的完备性。图1显示引入覆盖率作为反馈环节的验证流程。通过覆盖率的分析来确定是否需要增加或调整测试向量, 以达到理想的验证目的。
覆盖率技术按对验证充分性衡量的不同标准, 可分为:代码覆盖率, 分支覆盖率, 条件表达式覆盖率, 路径覆盖率, 信号翻转率, 功能点覆盖率等。各种评估准则各有优点和局限性, 很难给出每种评估准则与其发现错误能力之间的定性关系。而实际应用中, 单独使用某个覆盖率准则并不能充分体现验证程度。为了更有效地衡量验证的程度, 需要把几种覆盖率结合起来。如代码覆盖反映HDL代码被运行的彻底程度, 功能覆盖则从系统的角度来指示哪些功能被测试到, 哪些功能没测试到。几种覆盖率高度互补, 可以达到很好的验证效果。
3 结论
本文介绍了几种传统的功能验证方法并剖析了其优缺点, 并针对基于仿真的功能验证提出解决提高验证效率的方法。采用多种测试向量生成方式相结合和在验证过程中引入覆盖率作为衡量验证程度完备性的反馈, 从而大大提高验证过程的效率。
参考文献
[1]解咏梅, 张珩, 张福新.基于覆盖率的功能验证方法[J].计算机应用研究, 2005 (1) :23-28.
[2]张蓓莉.微处理器基于功能覆盖率的伪随机验证方法[J].计算机与信息技术, 2006 (4) :59-60.
[3]任宇, 王以伍.VLSI设计中一种新型的功能验证方法[J].微计算机信息, 2006.
[4]刘卓军, 吴尽昭.集成电路验证技术[J].中国基础科学, 2007 (11) :11-13.
[5]顾震宇, 虞志益, 沈泊, 章倩苓.基于仿真的32位RISC微处理器的功能验证方法[J].小型微型计算机系统, 2004, 25 (4) :752-756.
基于事务的功能验证方法 篇2
随着集成电路复杂度进一步加大,验证变得非常困难。比如,在规模达到数百万门ASIC、复用IP核的SoC设计中,验证至少占据70%以上的设计工作量[1]。估计验证所花的时间将随设计规模呈平方增长,验证工作的增长速率将超过摩尔定律。因此,如何采用有效的验证工具和技术是业界越来越关心的一个问题。
本文介绍一种基于事务的验证方法,可以在一个较高的抽象层次上进行功能验证,从而加速测试平台(Testbench)的开发。并以一个FIFO设计为例,介绍了这种验证方法中Testbench的架构、事务验证模型的组织和构建,在较高抽象层次的调用,以及在仿真软件工具环境下相关运行程序。
2 基于事务的验证方法
一个有效的验证测试集,应该有尽可能高的覆盖率,具有自检功能以避免手工确定期望值,在仿真中很容易确定设计的错误,很方便分析覆盖率确定这个测试集的质量[2]。基于事务的验证方法有助于构建这样的测试集。
2.1 事务的概念
事务(transaction)是指测试平台(Testbench)和被验证设计之间通过设计的特定接口进行的高层次数据或控制信号的传输。简单的事务可以是对存储单元的一次读或写,复杂的事务可以是数据通行中的一次报文传输[2]。事务的概念把Testbench分为2个层次:
(1) 顶层的测试,是建立在事务级的抽象层,形态上表现为多个事务的组合序列,不需要考虑各个事务中所需处理的信号级时序细节;
(2) 底层的事务,具体负责处理的信号级时序细节,由于信号级时序是针对被验证设计的特定接口而言的,所以被验证设计的不同接口具有不同的事务。
通过这种抽象,事务的概念把验证上升到一个比较高的抽象层次[2],用户可以少注重信号级时序细节,更多考虑事务级上的验证行为,提高验证的工作效率。
2.2 基于事务的验证方法的基本组成元素
基于事务的验证平台主要是由3个部分组成[2],如图1所示。
(1) 测试(tests)。
他是定义验证所需事务的一段程序(事务的组合序列),可以用HDL或是C/C++来描述。对于测试的编写,不需要了解详细的设计接口的协议,只需确定采用那些事务来产生激励、事务的次序怎样、相关事务在验证中占有的比例等等。
(2) 事务验证模型(Transaction Verification Model,TVM),也称为transactor,或者是总线功能模型(Bus Function Model,BFM)。
TVM是基于事务的验证方法的核心,代表针对DUV特定接口的所有事务的集合,主要任务就是将高层次的事务转化为其所代表的具体信号级时序的二进制信号,作为激励信号通过与DUT相连的引脚传输给DUT,并接收DUT的响应信号。一个设计往往具有不同的接口,在一个验证环境中针对不同接口需要不同的TVM。
(3) 被验证设计(Design Under Verification,DUV)。
就是需要验证的设计描述,可以是RTL级代码或门级网表。
2.3 基于事务的验证方法的工作原理与流程
基于事务的验证方法(Transaction Based Verification,TBV)中,tests是一段事务集合的程序,他并不关心每一个事务所代表的具体信号时序,这些事务的信号表示在TVM中被解释。而在TVM中,事务是由称为“任务”(task)的子程序转换成DUV所需要的具体信号,然后通过设计接口连接到DUV。也就是说,TVM由单个的任务子程序组成。使用TVM最大的好处就是验证工程师只需要处理高层次的事务,不需要关注具体的细节,能更好地把握整个验证环境。TBV方法的工作流程[1]如图2所示。
3 应用实例
用一个FIFO为例,详细介绍TBV方法在具体设计中的应用。
在数字电路系统的设计中,数据从一个时钟域传递到另一个时钟域,并且当目标时钟域与源时钟域不相关时,这些域中的动作是不相关的。独立时钟域之间高性能并行接口可用异步FIFO存储器来实现[3,4]。其结构图如图3所示。
存储器(16×8 b)模块有2个指针,读指针和写指针。这2个指针是由读写控制器产生,复位后,读写指针都被清零。写指针总是指向下一个将要写入的单元,每写入一个数据后,写指针增加,指向下一个要写入的位置;同样,读指针总是指向将要读出的单元,每读出一个数据后,读指针增加,指向下一个要读出的单元。当存储器中没有空间可写是,产生满标志位;当存储器中没有数据可读时,产生空标志位。
3.1 验证计划的制定
设计都是基于一定的规范文档,是验证和设计的共同出发点,是最好的参考和准测。通常包括2个不同抽象级别的文档:一是结构级的规范,定义了设计的功能要求,如上述FIFO的基本工作原理;二是设计规范,详细地描述系统在模块级的具体实现[5],如图3所示的基本结构图。验证工程师由此指定验证的目标和任务,如验证途径、验证技术、采用的模型、基本功能的验证、边界条件的验证,随机性验证等,形成验证计划[1]。本例中为叙述简单,主要关注空满指针标志位产生时FIFO的行为和FIFO读出数据的正确性。
3.2 Testbench结构及TVM构建
整个Testbench结构如图4所示。
FIFO的功能是在2个不同的时钟域之间传递数据,因此针对写时钟域和读时钟域相关接口构建了2个TVM,对应写时钟域接口的TVM(write TVM)为FIFO提供(写入)数据,对应读时钟域接口的TVM(read TVM)用于处理从FIFO中读出的数据,主要是检查读出数据正确与否以及空满指针标志位的产生情况。
TBV将不同接口的事务通过任务子程序封装在不同的TVM中,在Testbench顶层(tests)中调用或例化这些TVM(不同功能的TVM和对应于设计中的不同接口)的任务。tests中可以多次调用某一个TVM任务或者同时调用多个TVM任务,完成事务到具体信号之间的转换。
在write TVM中,封装2个任务:write task和wrst task。wrst task为写时钟域提供复位信号。write task按照图5所示的写数据时序,当full为0时,在时钟下降沿同步产生输入数据data和写使能控制信号wen。输入数据和写使能信号延长一个必要的保持时间后消失。当full为1的时候禁止data和wen的产生,避免出现逻辑错误。在write task中,输入数据由一个自加“1”加法器在写时钟的下降沿产生,在紧接着的上升沿被读入到存储器中。
在read TVM中封装了3个任务:rrst task,read task,check task。
rrst task为读时钟域提供复位信号。read task将FIFO中的数据读出,相关控制信号的时序与图5类似,区别是empty为0的时候可以读出数据,empty为1的时候禁止读使能信号的产生。
check task校验空满指针产生和读出数据的正确性。通常对于仿真结果的校验主要包括2个部分[6,7]:在仿真时对设计点的监控;把监控捕获值与期望值自动做比较,check task采用第2种方法。为了确定写入数据和读出数据的个数,在check task中定义2个变量i,k表示已写入和读出的数据个数。check task的检验程序如下:
if((wfull==1)||(rempty==1))
if ((i-k>14)||(i-k<2))
begin
display("---i=%d,---k=%d,---i-k=%d",i,k,i-k);
end
else
display("i-k=%d,error",i-k);
finish;
当空或者满指针为1后比较i,k2个变量来确定存储器中数据的个数,以验证空、满指针产生正确与否。当i-k>14时,wfull=1。当i-k<2时rempty=1。若有错误,在check task中给出错误发生的时刻和具体i,k及其差值,快速定位错误发生的位置。
3.3 基于事务的tests的建立
基于事务的tests程序就是一系列有序或随机调用系统中各个TVM任务[2]。一个比较完整的同时读写的tests流程如下:
initial
read_TVM.rrst; //读时钟域复位
initial
write_TVM.wrst; //写时钟域复位
initial
begin
repeat(n) //提供n个输入数据
write_TVM.write; //写数据
end
always
begin
delay m; //经过m个延时后开始读数据
read_TVM.read; //读数据
read_TVM.check; //对所读数据校验
end
读写时钟域逻辑复位后,调用write TVM中的write task n次,即为FIFO提供n个输入数据。经过适当的m个延时后,再调用read TVM中的read task,将FIFO中的数据读出。并在每读出1个数据后都调用1次read TVM中的check task来校验所读数据的正确性。其中为FIFO提供数据的个数以及调用read task的延时时间都是参数可调的,方便不同情况下的验证工作。
4 结 语
验证是一个过程,而不是一系列验证平台的简单集合。在基于事务的验证平台中,如同IP设计一样,采用标准接口的TVM设计有利于验证平台的重用,大量减少验证时间,缩短开发周期。
模块化和可重用的验证平台可以采用TestBuilder,Vera或Specman Elite等来开发。,
摘要：功能验证是百万门级IC设计中的一个重要瓶颈。基于事务的验证方法把验证工作提高到一个更高的抽象层次,减少了验证中对信号级时序细节的考虑,更注重于事务级行为的验证,并可提高验证代码编写的重用性,有利于提高验证的工作效率。介绍这种功能验证方法及其测试平台的建立。
关键词：功能验证,事务,测试平台,IC设计
参考文献
[1][美]拉申卡,帕特森,信赫.系统芯片(SoC)验证方法与设计[M].孙海平,丁健,译.北京:电子工业出版社,2005.
[2]Dhananjay S Brahme,Steven Cox,Jin Gallo,et al.TheTransaction Based Verification Methodology[OL].CadenceBerkeley Labs,http://www.mentor.com,2000.
[3]Clifford E Cummings.Simulation and Synthesis Techniquesfor Asynchronous FIFO Design[OL].SNUG 2002(Synop-sys Users Group Conference,San Jose,CA,2002)User Pa-pers,Section TB2,2nd paper.http://www.sunburst-de-sign.com/papers/,March 2002.
[4]Michael D Ciletti.Advanced Digital Design with the VerilogHDL[M].张雅绮,李锵,译.北京:电子工业出版社,2006.
[5]Janick Bergeron.Writing Testbench Function Verification ofHDL Models[M].Kluwer Academic Publishes,2003.
[6]Michael Keating.Reuse Methodology Manual for System-on-a-Chip Design[M].Third Edition.Kluwer Academic Pub-lishers,2002.
集成电路功能验证方法 篇3
随着民用飞机的复杂性、综合和集成化的不断提高, 同时伴随民机市场的竞争越来越激烈, 飞机的安全性、测试性、故障诊断、故障隔离、故障预测和维护性等问题越来越受到飞机系统或设备供应商、飞机制造商 (OEM) 、特别是飞机客户关注。现代民机上主要采用中央维护系统 (简称为CMS) 来分析、监控、诊断或预测飞机故障, 以帮助维护人员工作, 保证飞机持续适航性和运行安全, 提高飞机的测试性、维护性和经济性等。通过该功能可以降低对维护专业人员要求、减小/缩短飞机维护时间、提升飞机签派率, 最终降低飞机维护和运行成本以及提高飞机的经济性, 同时通过识别反复出现的故障和趋势支持提高可靠性, 防患于未然。
测试和调整功能 (Test And Rigging, 简称为TAR功能) 是集成于CMS的一个必不可少的子功能, 通过人机交互的模式实现各个成员系统 (将使用TAR功能的飞机非航电机载系统称为TAR功能成员系统) 自身调整、自检测 (BIT) 、详细故障信息查看、清除历史数据、软件构型信息与系统状态信息查看等。TAR功能各成员系统需基于自身系统复杂和重要程度以及自身特点, 决定并负责实际实现各自系统的TAR功能。CMS作为该功能的集成者, 主要为各系提供通用、统一的交互方式和入口, 并显示测试和调整结果。由于该功能采用交互的方式、各成员系统TAR功能相对独立且具体负责逻辑实现, 通常将与各系统相关的TAR功能称为各系统TAR功能。
中国民用运输类飞机起步晚, 且发展比较缓慢, 国内对于TAR功能的认识、验证以及对CCAR25部相关适航条款的符合性等需要进一步研究。为此, 本文详细阐述空气管理管理TAR功能及其一种验证方法, 以为后续其他民用运输类飞机项目TAR功能设计、验证和符合性方法提供参考和建议。
1 空气管理系统TAR功能
1.1 空气管理系统TAR功能内容
飞机空气管理系统 (AMS) 由气源系统、空调系统、压调系统和机翼防冰系统组成, 空气管理系统控制器 (后续简称为控制器) 为上述四个子系统的综合集成控制器, 负责整个空气管理系统的控制和监控。
AMS TAR功能一般在飞机处于地面且制冷组件不工作的情况下才可以使用, 以保证飞机和系统安全性。该功能相对于其他成员系统的TAR功能相对简单, 不包含Rigging和从LRU的NVM (NonVolatile Memory) 数据下载和清除功能, 主要包含两方面的内容:测试系统参数和IBIT (Initiated Built-in-test) 。其中, IBIT包含控制器IBIT以及CPCS/ECS/WAIS/BAS IBIT。测试的系统参数举例如下:
a) 活门命令/位置状态信息;
b) 传感器数据, 若传感器超出范围将显示“--”;
c) 开关选择状态信息, 若开关位置错误将显示“--”;
d) 控制器软件构型以及其内部压力传感器温度;
e) 飞机状态信息, 比如飞机型别, 控制器识别、软件运行模式和货舱加热器选装。
1.2 空气管理系统与CMS之间TAR功能通讯架构
一般, AMS控制器与CMS之间按照ARINC 604协议进行通讯传输和处理以实现AMS TAR功能, 通讯架构见图2。随着综合化、模块化航电系统的发展, CMS软件和集成后的TAR功能XML将驻留在航电系统综合处理机柜 (Intermediate Processing Cabinet:IPC) 的通用处理模块中, CMS相关功能信息显示在多个功能显示器 (Multifunction Display:MFD) 上。AMS TAR功能通讯模式有两种:
a) 交互模式:控制器与CMS之间交互响应以执行测试操作和输出构型信息;
b) 自动模式:在控制器通道进入相应的具体测试操作或页面后, 控制器对应通道将自动自动更新MFD显示的信息。
实现AMS TAR功能主要条件:
a) 集成后的AMS XML:可以将其视为支持AMS TAR功能的机载数据库, 主要用于定义和提供TAR功能通讯和显示的一些信息, 比如LRU名称、设备ID (Equipment ID) , 页面名称、组件名称 (Component Name) 和组件类型 (Component Type) 等;
b) CMS软件:集成CMS的所有功能, 并在MFD上显示;
c) AMS控制器及其所含软件:AMS控制器软件主要负责实现AMS控制和监控, 其含具体AMS TAR功能逻辑实现。
1.3 空气管理系统TAR功能XML开发集成
通常, 用于支持TAR功能的ARINC 604协议以及XML的开发集成工具由CMS供应商或飞机主制造商应提供, 这样可以确保TAR功能各成员系统能够按照正确统一的要求开发XML和各系统软件相关TAR功能代码。AMS供应商基于统一的XML开发工具开发分别适用于AMS控制器各个通道的XML, 同时还需按照ARINC 604协议要求开发AMS控制器软件所含的TAR功能相关软件代码。飞机制造商使用XML集成工具将TAR功能成员用户的XML集成为飞机级TAR功能 (含AMS XML) , 以用加载到试验室或飞机上进行TAR功能试验。各个成员系统的XML和TAR功能相对独立, 互不影响, 这保证各成员系统可以独立进行TAR功能验证。AMS TAR功能XML开发集成大致步骤如下:
2 空气管理系统TAR试验验证方法
由于TAR功能需要专门的XML支持以及各成员系统TAR功能的差异性, 若要各成员系统供应商对TAR功能XML和整个环节TAR功能进行验证, 则需要AMS供应商具备航电相关试验平台软硬件等, 试验成本和难度很大;反之, 若要CMS开发商进行全机TAR功能XML和整个TAR功能环节验证 (含AMS) , 则CMS供应商需要拥有所有各成员的各相关试验平台软硬件等, 试验成本和难度更大, 因此通常该验证工作由飞机主制造商负责。
由于一般民用运输类飞机TAR功能为DAL E级, 且通常作为民用运输类飞机机载软件和数据库符合性方法的DO-178B对DAL E级机载软件和数据无要求, 因此申请人无需针对XML对DO-178B符合性开展专门验证工作。依据中国民航要求, 运输类飞机必须满足CCAR25部要求, 申请人为验证AMS TAR功能满足设计要求, 特别表明符合适航相关条款要求, 可采用如下验证方法或组合。
2.1 申请人试验室研发试验
申请人应在试验室进行研发试验, 以进行整个AMS TAR功能测试 (含AMS控制器软件逻辑、传输以及最终显示结果) , 用于验证TAR功能的正确性和保证飞机安全。AMS TAR功能试验室试验方式见图4。由于试验室试验可模拟较全面的输入, 特别是能够模拟AMS一些非正常构型或状态, 比如开关故障、客舱高度告警、传感器超出范围等, 这相对于机上试验容易、成本低、且安全。
2.2 申请人机上研发试验
由于试验室并非飞机真实构型以及试验条件的部分限制, 特别是当运行AMS IBIT测试时, 根据AMS TAR功能控制逻辑设计, 需要相关系统设备动作 (比如活门等) , 这些需要在飞机上进行相关试验才能够真实验证, 因此AMS TAR功能要进行必要的机上研发试验。机上研发试验与试验室试验应在试验目的、内容上有所不同并各自有其侧重点。
2.3 表明符合性机上地面试验 (简称为MOC5)
由于国内目前民机取证经验欠缺, 特别是考虑申请人试验室及人员资质条件, 上述3.1和3.2节描述的TAR功能验证方法仅为申请人自己的研发试验, 因此为满足条款要求还需进行专门的AMS TAR功能表明符合性MOC5试验。MOC5试验前试验大纲和试验构型需获得局方批准, 试验前局方需进行机上制造符合性检查。试验后的试验报告及试验结果应能表明AMS TAR功能符合设计要求、试验满足大纲判据, 并最终需获得局方批准试。
3 结束语
本文概述了民用运输类飞机空气管理系统TAR功能、通讯架构、XML开发集成以及验证方法。对于TAR功能过验证方法, 由于项目及其主制造商和供应商责任分工的差异性, 不同的运输类飞机项目申请人采用的TAR功能验证方法可能不同。随着国内对民机研制规律认识的不断深入以及经验的不断积累, 若申请人相应的试验构型和人员资质能够获得局方认可, 且在申请人与局方就TAR功能符合性验证方法达成一致前提下, 若申请人在进行研发试验室和机上地面试验室前相关试验大纲获局方批准, 则申请人的研发试验室和机上地面试验可并行视为局方表明符合性试验, 这样可以避免重复进行TAR功能表明符合性MOC5试验, 这在一定程度能够节省项目研发进度和成本。
参考文献
[1]陈雯.先进的中央维护系统[J].民用飞机设计与研究, 2010 (1) .
[2]赵瑞云.民用飞机机载维护系统的中央维护功能[J].中国民航大学学报, 2008, 26 (5) .