标签: ATE

关键词： ATE，Automated Test Equipment,自动化测试设备 CDM，Charged Device Model，至微电子器件带静电后，与接地的导体发生接触，而产生的剧烈静电放电事件 Field-Induced CDM，静电感应方式使电子器件带静电的CDM情形 ESD，Electro-Static Discharge，静电放电， 芯片封测工厂中末段的许多自动化电性测试设备(ATE，Automated Test Equipment：涉及DC参数测试、open/short测试、functional测试、烧录等)都存在共同的ESD失效风险：处于高静电带电状态的IC接触到测试机的测试pin发生剧烈的静电放电，产生快速放电脉冲冲击IC内部器件结构，并导致相应的电性参数失效。 芯片在ATE设备上是否会产生电气失效，主要取决于： 1.芯片的ESD敏感等级(也就是芯片能够承受的最大CDM电压水平)； 2.芯片在ATE设备中的最高静电带电水平(取决于的芯片的封装材质与ATE设备的自动化设定技术条件)。 关于芯片封测工厂的ESD失效问题，现实中代表性的ESD现象主要包括： 1.同一批生产的芯片在不同ATE设备上的电性不良率呈现差异(表明不同ATE设备的ESD防护有效性存在差异)； 2.同一批生产的芯片经过ATE测试会比未进行ATE测试的出现较高的电性不良品(充分表明ATE设备的ESD防护不到位)； 3.ATE设备测试判定为良品的芯片再次进行ATE测试仍会再次出现电性不良品(表明前面的ATE设备在测试座取出芯片发生了ESD失效，或后面的ATE设备的ESD防护不到位)。 芯片在ATE设备中的静电带电来源，主要包括： 1.搬运robot真空吸嘴取放芯片在芯片绝缘封装壳体上累积静电； 2.芯片在test socket中loading/unloading过程，导致test socket的芯片导向部件累积静电。 解决芯片在ATE设备中的ESD失效，关键在于芯片在自动取放过程中的静电带电水平是否可以控制到位，具体可以通过ATE相关取放机构的ESD改造及芯片在测试座区域的取放过程的离子化静电消除等技术手段来实现。 附件：微电子器件的（Field Induced）CDM ESD敏感度评测方法

簧片继电器被众多用户认为是最可靠的低功率开关解决方案,它们几乎没有移动部件和并且拥有很长的机械使用寿命。当然,并不是所有簧片继电器构造都拥有相同的 高标准。Pickering使用姐妹公司Pickering Electronics的簧片继电器来搭建开关模块产品,因为这些继电器可以提供最好的性能。许多ATE供应商也选择使用Pickering Electronics簧片继电器,因为它们的参数指标表明它们拥有最稳定的性能和更长的寿命。这让Pickering 产品竞争优势超过其他供应商的继电器切换系统的簧片继电器。 一、簧片继电器的基础结构 在下面的内容中,我来解释一下为什么这些继电器可以提高产品的可靠性。（下图是簧片继电器的结构图） 簧片继电器是很简单的设备,它是一个簧片组装到一个包括一个线圈和回程二极管的盒子里。最常见的形式是常开类型的继电器，初始状态是开路。其他类型也是可以的,但是由于各种原因往往很难生产，并且可靠性比较低。 簧片本身是一个密封的玻璃管中包含两个由磁敏材料组成的簧片触片。玻璃管充满干燥的惰性气体,以防止器件氧化。簧片触片选择的是镀层，两个刀片组合在一起形 成一个可重复的电触点。触片通过一个轴向磁场的作用而组合在一起，从而让两刀片移动和接触。簧片继电器的磁场是由一个环绕着玻璃管的线圈产生的。 这个结构中很多人会关心以下的问题: 触片分离是什么？ 多大的磁场才能关闭连接器？ 玻璃管的密封性好不好？ 用于连接器电镀材料是怎么样的？ 能切换多大功率,电压,电流？ 簧片的总长度？ 触片的刚度多大？ Pickering Electronics在产品研发方面有相当多的经验,他们知道怎么样选择正确的簧片用来构造继电器。例如,钌连接器可以提供更好的性能，可以支持更大的 电流。Pickering 只低电压开关继电器模块中使用这些钌簧片的。簧片都是选择性能最佳的，这些继电器通常被称为仪器级的簧片，它们给Pickering 带来的主要优势主要是在中低功率交换式 电源 条件下表现出来的。 二、组装干簧继电器     为了选择最好的舌簧开关组件簧片组装到一个簧片继电器。簧片继电器 封装 了簧片开关到组合包中，包含线圈和回程二极管，控制EMF的线圈时释放开关。舌簧开关是一个脆弱的设备，很容易受损,一直到封装的时候，必须保护好，直到继电器完成,而且在封装的时候会对簧片可靠性产生重大影响。 典 型的结构使用的是Pickering Electronics的产品，竞争对手使用的是硬塑料成型材料封装的簧片,线圈和二极管包。 塑料材料是可用的簧片继电器组件,但由于工作原理是通过温度循环,环境变化引起的,线圈操作或信号路径损失会加热触片，导致局部膨胀——因为部分的温度系数不匹配,在任何情况下局部加热组装意味着不是所有的区域都是相同的温度。 以下是Pickering所使用的SoftCentre组合结构：     Pickering Electronics产品使用不同的施工方法。簧片,线圈和二极管安装在一个经过蚀刻的引线框架上。引线框架是安装在一个硬塑料壳和外壳的内部充满了柔和的封装材料,允许局部膨胀。 还有其他差异，Pickering Electronics在簧片上用的former-less线圈,线圈直接在玻璃管上，从而保证了线圈的磁场簧片触片更紧密的连接在一起。另外还包括一个 护盾,限制外部磁场对继电器产生影响——阻止簧片继电器的磁场与相邻的继电器产生相互作用。 最终的结果是拥有更可靠的结构，和质量质量更好的产品,可以安装在印刷 电路 板上，也不用担心继电器交互，这就使Pickering能够研发出密度更高和更可靠的簧片继电器开关模块产品，如一些高密度的矩阵开关，这些很适合用于信号切换系统之中。 (本文作者：虹科 电子    郑南润)  引用请注明出处。

In Part 1 , I left off by discussing the industry shift to proactively managing tester configurations. I'm sure my story triggered memories of a similar season at your company when a more global assessment of your test configurations and capacity became essential to your survival. If so, how did you first start tracking your configurations back then? Maybe your experience and tool set was like mine described below.   Much like the case today, the test systems in the mid-1990s produced an electronic configuration file or "config file" that contained a rich set of detail on the hardware options in the system. The problem was that config files were readable by only a select few in the test community.   As a Field Product Specialist at Teradyne, I was trained to be one of those few. I spent a great deal of time manually checking and translating those files to not only ensure accurate alignment to system orders and device requirements, but to create readable summaries for sales, purchasing, and management. I also had to make sure important information not included in the config file made it into the orders, summaries, and the like. This work was performed using a variety of familiar formats like text files, spreadsheets, and presentation slides, but many of the details in the original config file were inevitably lost in translation.   While many loathed the config file, I embraced it. I considered it part of what allowed me to have "Specialist" in my title. More importantly, working with config files always provided an opportunity for geek humor by making the proverbial, but likely overused, "secret decoder ring" reference ( figure ). I just did it again.   Config files, often written with text editors or spreadsheets, contain information on how ATE systems will be set up for a particular test.   Not everything was, however, done in a text editor. The most innovative related endeavor at the time was the internal development of a customer tester configuration manager in HTML, to be viewed on what was then a nascent Netscape browser. A clever solution for sure, but one that drove perhaps five page views per month, and really had just two unique visitors: I was one, with the other another test engineer in the office with a similar thing for configurations.   When I look back on those times, I don't really see much that has changed in the area of test capacity management tools and methodologies. The system config files are still esoteric and are complicated even further by the addition of floating feature licensing schemes. The tools used to document tester configurations have changed versions but are also largely the same. Unfortunately, there remains a loss of information and efficiency in the translation and communication process. Perhaps now is the time to bring back that web-based configuration manager!   Dan Hamling is CTO at Team A.T.E.

I recently underscored the major stakeholder groups in the test industry that care about test capacity and how it's managed: the test specifier, test provider, test equipment manufacturer, and third-party supplier. Over my long career in the test industry, I've been fortunate to have had the opportunity to think about test capacity and its management challenges from the perspective of each of these groups.   Although I saw significant and exciting innovation in ATE and test techniques over those 27 years, I saw relatively limited development of test capacity management tools and methodologies. My next few posts will provide a chronological review of some of my test capacity management experiences to see if you agree.   My early years as a test engineer at Hewlett-Packard had no test capacity management challenges. As part of a low-volume custom bipolar ASIC design center, we did all our test engineering and production on just one Sentry Series 80 tester. We were essentially both the test specifier and test provider in this case, but with access to only a single fixed unit of test capacity. Our challenge then had more to do with testing a 2 GHz bandwidth, 500 Msps oscilloscope front-end sampling device on a 20 MHz tester. (Answer: rack-n-stack like crazy and develop 3 GHz probecard technology).     When you have more than one ATE station, test management becomes important.   When I joined Teradyne and relocated to Austin, Texas in 1995 to primarily work with Freescale (then Motorola's Semiconductor Products Sector), I saw for the first time the world of large device portfolios and high-volume manufacturing. Along with that world came test capacity management challenges I hadn't experienced before. As Freescale built up its installed base of A5-Series testers and transitioned to the new Catalyst platform for their analog and mixed-signal products, we spent a significant amount of time together planning and managing the ATE configurations that would be used worldwide by this multi-national company.   Proactively developing a set of ATE configurations that aligned with the long-term device roadmap is common test capacity management practice now, but was actually not as prevalent for earlier generations of ATE. The proud owner of hundreds of tester platforms at the time, Freescale, like other large semiconductor companies, got to that point by allowing its various product groups to independently specify ATE based largely on just the technical requirements of their new device or, at best, family of devices. And, test equipment manufacturers such as Teradyne happily provided specific solutions for each device.   This strategy was eventually disrupted by the realization that test capacity utilization was an important cost-of-test lever that must be managed more closely to effectively compete in the growing global semiconductor industry. Coupled with this trend was the advent of architectural innovations in ATE that allowed for a much wider range of configuration options and thus demanded a more careful configuration assessment and plan.   So, what compelled you to first start prioritizing and performing long-term ATE configuration planning? When did it happen for you? In Part 2, I'll continue my discussion of this first major movement in test capacity management, focusing on the tools and methods we used to perform this work.   Dan Hamling is CTO at Team A.T.E.  

这是我以前在百思论坛上发的，参考http://www.baisi.net/viewthread.php?tid=217268，当时是一知半解，其实自动测试重在测试需求分析，解决“做什么？”这个问题，软件、测试平台等都是解决“怎么做？”这个问题，技术是发展的，但需求是永恒的，今后会补充需求分析这方面的内容。   我对ATE的理解   本来我是想写成论文格式的，但查阅了不少别人的论文，发现我的想法大部分没什么新意，即使写了，也只能叫做低级重复，有点新意的那一部分呢，还没得到证实，充其量只能叫做设想，达不到我想象中的论文要求。写成这种类似帖子的格式，目的也是一样的，就是告之后来人一些经验，提供点参考，但就可以不那么严谨，可以发挥的余地就比较大了，而且本人更加喜欢这种文章的风格。 本文所写的是我对ATE的理解，重点包含对ATLAS语言的理解，所写的是个人看法，如要比较严谨的解释，可以参照相关论文。 对ATE的整体看法 ATE就是自动测试设备的英文首字母的缩写，我们为什么要生产ATE设备，显而易见，为了省事，省得人工去测试。但自动测试设备要能完成人所能完成的功能，就要有类似人的传感器代替人的各种感觉器官，有执行机构代替人手来操作被测产品，有固化的程序之类的代替人的思维。当然这些传感器、执行机构可以做得比人更为精确、迅速，程序也可以做成那样，但灵活性就不如人了，遇到特殊情况也不行了。其实不管什么东西，都是信号输入，经过处理，再输出的，至于如何实现每一步的，我估计随便一个细节都可以成为一门学科的，下文会给出稍微详细的解释的。 我对传感器的看法 言归正传，传感器一般有测量电压、电流、温度、湿度、功率等等，当今社会，一般人能想到的基本上也应该能做到了，我们做的只不过要挑选适合自己的。速度、精度、价格、寿命、可操作性等都是要考虑的因素，使用起来也是千差万别，但这种产品会越来越容易操作，生产厂家一般都会给出详细使用说明，我们只要做好外部接口，依葫芦画瓢就可以了。当然我也见过要用诸如单片机发送特殊格式的命令字才能工作的传感器，但操作起来也是依葫芦画瓢就可以了。得到的数据也是千差万别，常见的是电压和特定格式的编码，照者DEMO做就可以了。 我对执行机构的看法 如果说传感器有一千种，那执行机构就有一万种了。但用起来也不难，也是依葫芦画瓢就可以了。一般有产生电压、电流的，当然也有带动某个轮子呼呼转的，有简单的也有复杂的，要操作起来也是有方便的也有麻烦的。但归根结底是不怎么要去自己想一种新的方法去使用的，和传感器一样，最多是照者DEMO做就可以了。 解释以下我所说的DEMO就是类似一种例子程序，使用起来一般只要修改修改参数就可以了，要变化的话也只是把几个DEMO修改后一起做，那都是算复杂的了。 我对程序的看法 程序这一块就相对灵活得多了，当然有现成的DEMO可以照抄是最好的，但DEMO不可能有那么多，也不可能像如传感器、执行机构的DEMO那样可以基本穷尽所有具体用法。有人说执行的语句就那么几种，怎么不能穷尽，我说英文字母也就才26个。也许我接触的软件不算太多，我的理解就是程序就是语法加算法（这句话其实是一位计算机史上的泰斗说的）。语法很容易，就曾经有人号称两天学会了JAVA，这我是相信的，语法也就那么多固定的语句，ATLAS据说是最复杂的语言之一，但不也就那一两千个单词，常用的也就一百个吧。算法才是本质，就像你要写本书，没准你认识的字比鲁迅还多，但写出来的文章能够比他好吗？程序的算法好象是可以申请知识产权的，道理我也就不多说了。 算法得表示出来，大家认同，共同研究的算法才是能够得到发展的，但表示的格式可以不拘一格的，程序员之间甚至就可以写一个DEMO就可以表示他的思想了。但对大部分人来说，虽然算法最终要用程序来实现，但他不懂程序，或还没能达到用程序的思维去思考程序（说得有点悬乎了，但可参考老师常说的用英文的思考方式去读英文，不要老想着把它翻译成中文后再理解这句话），怎么办，我们可以用信号流图，框图等来表示，本质上这些还是程序（第四代语言好象就往这方面靠拢），但只要看那么几分钟就会明白，因为不管是信号流图还是框图，只有顺序、分支、循环还有一个用得很少的跳转这几种形式。 有人说这每一句我都看得懂，但这一段就不明白了。每一句都看得懂电脑也能啊，要人干什么，我认为这才是人的用武之地。看这个首先要“断句”，分成一块一块的，有不少块还是重复的，可一略而过，重点要分析的就要重点分析（废话，但很有用）。这也是一个靠经验的活，见多识广在这里是真理。各人分析的方法不一样，可由下而上，可由上而下，也可两者结合。我喜欢由上而下，一般的程序用它也就足够了。总体把握了，就知道每一步是在干什么，要怎么干，当然由下而上也有它的好处，当然要应时应势而变。有人说这每一小段我都知道要干什么，具体到ATLAS语言就是这一小段是测啥测啥的，够了，不识庐山真面目，只源身在此山中，除了看懂每一段，还要整理出来，再进行分析，就高了一个层次，具体怎么办，涉及商业秘密和知识产权，就是不说。我现在就是在干这个，虽然有不少进展，但没完全弄清楚，发言权就不多了，当然其它方法我还没试过。 我对ATLAS的看法 前面那些分析是做铺垫的，下面的才是本人查遍万方、维普，外带IEEE，呕心沥血一两个月来得出的“一家之言”。如有错误，请及时告之，不胜感激！ 和所有语言一样，开始我还以为它有多艰深，还是主席说得好，战略上要藐视敌人。 先COPY一段简介：ATLAS作为国际通用的自动测试语言 ，应用在航空领域是航空电子系统简略测试语言(Abbreviated Test Language for Avionics Systems)的英文缩写；在其它领域，则是所有系统简略测试语言(Abbreviated Test language for All Systems)的英文缩写。ATLAS广泛应用于国际军用和民用ATE中。ATLAS作为标准的 TPS程序语言，当初是基于 FORTRAN语言制定的，但经过几十年的发展演变，如今更趋近于C语言。ATLAS测试程序是ATE  TPS的重要组成部分，通用 ATE 成功与否也就在于其拥有的TPS数量的多寡程度。分析研究 ATLAS测试程序的结构，对编写出好的测试程序极为重要，也可以知道如何根据已有的ATLAS程序来自己做个达到其功能的ATE，除了不受制于人外，还能省不少$呢。 ATLAS测试规范和 ATLAS测试程序是有些区别的，再COPY一段：ATLAS语言是一种用于测试的人机通讯的高级语言，是面向UUT而与测试设备无关的信号描述语言，没有提供特定测试系统执行测试程序所需的全部细节。ATLAS测试规范只说明与UUT相关的测试需求，因而，要在ATE上执行测试规范，需要增添一些必要的细节，包括对ATE的说明和它的资源、限制条件以及UUT接口情况。这个处理工作通常由ATLAS编译器或解释器来完成，它用测试系统规定的信息，将 ATLAS转换成可执行程序。（补充一点，这种编译器对于你现有的硬件条件也未必适用，而且D版的也要￥1000，小弟只想FREE，谁有D版的PAWS，告诉我，我会感激涕淋的，EMAIL:xiazhifei@yahoo.com.cn。）因此，ATLAS测试规范和 ATLAS测试过程与测试设备是相互独立的，而ATLAS测试程序才与某种测试系统有关联。测试规范只有在考虑了测试设备的限制条件、编译器如何工作和仪表精度等因素后，才能将其转化为测试程序。因此，某个UUT的ATLAS测试规范，指的是UUT独立于测试设备的测试需求。ATLAS测试程序是在具体的 ATE上执行该 UUT的测试规范。但住 ATLAS标准文本或日常使中，总是“程序(Program)来指“规范”(Specification)、“过程”(Procedure)或“需求”(Requirement)，遇到“ATLA测试程序”一词时，须注意区分其内涵。航空电子 CMM 手册中提供的ATLAS文件，通常是ATLAS测试规范或 ATLAS测试过程。 要写的比较多，改天继续写。 我对ATE的一些看法 在整体看法那一段是我个人看法，以下是一篇论文中的看法：典型的ATE系统中有如下几类组件：开关，矩阵和标准仪器，前两类为连接装置，用于在UUT与仪器间建立通路，标准仪器我就不多说了，可以相当于传感器，也可以是执行机构。 也有这样的看法，把ATE可以细分：测试控制器、激励资源、检测资源、开关系统与信号接口装置。测试控制器实现自动测试系统中各种激励资源、检测资源和开关系统的自动配置，并决定其工作方式、状态、功能和参数，控制测试信号的通道选择与切换。测试系统与被测单元的信号交联则是通过信号接口装置实现。 我对开发ATE的看法 这方面经验不多，只好借鉴别人的经验，以下只是众多方法中的一种： ①需求分析。对每个UUT的测试过程进行分析，得出所有的UUT对自动测试系统的全部需求，即需要自动测试系统提供的资源，包括设备能力、开关能力，根据这些需求进行 自动测试系统设计，这是整个ATE设计的基础和目标 ； ②ATE系统设计。根据需求分析，系统设计规定了ATE需要的设备能力、开关能力、各部分的接口关系等，这是下面步骤的基础和目标； ③ATE硬件构形。硬件设计规范必须采用国际上先进的、成熟的工业标准，以保证功能模块的兼容性，根据需求分析构形 ATE 硬件平台，目前ATE硬件构形主要是VXI、PXI、PCI、GPIB等标准化接口的构形方式 ； ④设备数据库开发。设备数据库提供ATE测试程序设备服务的能力，根据上述的系统设计来开发测试系统中设备的驱动程序，使设备能够满足上述需求； ⑤开关数据库开发。开关数据库提供ATE为测试程序开关服务的能力，根据上述的系统设计来开发测试系统中开关的驱动程序，使开关能够满足上述需求； ⑥使用 ATLAS语言开发每个UUT的测试程序。 其中后面3步可以并行开发。 这中间比较基础的是需求分析，开始一定要弄正确，至少要越正确越好，要不然谬之毫厘，失之千里。对于软件工程的话，可能这是最重要的，但ATE的需求分析相对应简单不少。最灵活变化的应该是系统设计，没实践过，我也没啥好说的。要费事的可能要数数据库的开发，我感觉这有点像在修改DEMO之类的，虽每一个不难，但数量众多，要有耐心，不过重复的多，会越做越快的。到最后是用ATLAS开发，但估计一般的厂家会用如CVI、LabView之类的替代，道理也很简单，ATLAS编译器太贵了，还不一定好用，而用NI等公司产品的无论是人还是相关资料都是比较多的，性价比高。 我对UUT程序的看法 这程序吧，思考的角度不一样，得出得结果肯定会不一样，还是那句话，要应时应势而异。不管是写程序还是根据已有的程序得到适合自己的程序时，基本也就要考虑以下部分： 一般测试流程为:(1)根据UUT的被测特征来为其分配一个合适的测试仪器;(2)将UUT和分配到的仪器连接起来;(3)测试仪器根据测试需求作出一些测试动作;(4)测试完毕后断开连接。其中第1步是测试中最重要的一步。 也有这样的流程：(1)证实待测UUT是否正确：(2)UUT安全检测；(3)上电安全检测；(4)读故障存储器； (5)BITE 测试：(6)UUT各功能测试。 还有这样的，把ATLAS的每一步测量细分：1)将虚拟资源、信号类型、被测量及参数描述字符串映射翻具体的资源 ；2)将连接描述字符串映射到具体的继电器；3)闭合相应的继电器； 4)延迟； 5)调资源的驱动，测量信号参数值 ，并放到测量描述字符串对应的变量中； 6)断开继电器，仪器复位。 反正如果要是没有PAWS之类的软件或硬件不一样，现有的软件用处不大的话，有一点是一样的，就需要人工实现由虚拟资源到实际资源的转化，当然根据自己的硬件情况，写个编译器是最好的:-)。 我对资源的看法 先COPY一点：仪器的性能数据由REQUIRE语句提供。REQUIRE总结出了所有需要的测试资源，并把它们作为虚拟资源 。这些虚拟资源是根据UUT信号需求定义的，而不是根据在具体测试系统中所用实际资源的性能定义的，一个实际资源没有必要只对应一个虚拟资源 。比如，一个现代的数字万用表就可以对应多个虚拟资源，如包含交流电压表，直流电压表，电阻表，直流表等。其实实际资源与虚拟资源也可以说是多对多的关系，有时一个检测步骤需要测量N种参数，可以用多种仪器测量。在这里会存在一张资源分配表，而且应该是动态的，每个设备使用的时间甚至有什么特殊情况都是不可预见的，使用完了才能释放相应资源，让其它接口使用。可编程开关、开关矩阵、继电器等就是用来根据需要，动态地在ATE的实际资源和UUT之间起一个连接作用的。当然如果系统比较简单，可以人工静态地给它分配好，这样无论是写程序还是做硬件实现起来会很省事。基本原理我估计就是这样，但实现起来，我没有实践，也就没发言权了。 我对根据已有的ATLAS制作ATE设备的看法 如果你同意以上我说的，请继续往下看，否则对你来说可能是误导:-)。 很多种情况下，我们都是已经有现成的CMM手册，当然也有ATLAS源程序（应该叫测试规范，但叫程序习惯了，先入为主），但就是没有对应的ATE硬件平台，买不到或不想买那些硬件平台，怎么办，就要根据已有的ATLAS，已有的可买到的硬件制作ATE设备了。 前面说过，一般用如NI公司的一些产品来实现，但人家NI公司的产品不支持ATLAS，就要连同源ATLAS程序都要修改了，改成符合他们标准的如LabView、CVI等支持的语言了。（等哪天中国强大了，也自己制作标准）。驱动也要用符合他们标准的，机箱也要用符合他们标准的，我相对比较关心的就是如何根据ATLAS源程序选用什么样的硬件，怎样能把ATLAS源程序变为CVI程序。 说到这，我想起来一个笑话，说某一天，主持人问大家，有一个水龙头，一个空壶，一个炉子，怎样才能得到一壶热水，大家说，先把水壶装满水，再放炉子上烧热，就可以了。 再问如果壶里有水，怎么办？一物理学家说，直接放到炉子上烧热就可以了。一数学家说，把壶里水倒掉，然后按照大家刚才说的那样去做。 我想程序之间的转化，我愿意成为那个数学家。有时虽然这一段ATLAS语言你很容易明白，甚至你可以简单地用一个C语句表示，但整本ATLAS语言就不能每句都是那样了，每句都要分析透彻到干啥干啥的，起什么作用，在这段占什么地位也不容易，也不省事，也未必是件好事。ATLAS中的动词就那么几个，无非是比较，测量得到一个什么结果，发送点什么信号啊、码啊，再有就是如延时、要求于用户互动，要求用户输入，再给用户输出点什么，这些东西应该完全能用C语言替代，甚至可以到一句替代一句的程度，只是一般用C还省事一些。 有人说替代不会得到我要的那种图形化界面的要求，这是肯定的，当初人家美国人写ATLAS语句的时候WINDOWS可能还没出世呢，但得到一个DOS界面下的程序还是完全可以的。有人说你C语言能实现虚拟资源到真实资源的转化吗？那本来应该是ATLAS编译器的事，这就是我下面要说的重点。还有其它问题，如ATLAS能一句就实现测量什么什么参数，C能吗？C当然用函数实现，调用下层函数，直至驱动真实仪器工作（一般应该是数据采集卡一类的），然后由真实仪器返回参数，直至刚才调用它的C语言函数。当然了，实现起来应该可能是比较麻烦，但思路是很清晰的，不会有理论上的难点。其它如发送什么特定格式的数据，加身什么电压、电流都可以依此类推，至于加什么电阻、电容、电感之类的，虽然没有特定的仪器，但可以用可编程矩阵开关、可编程电阻等实现，理论上不难，实际上我还没实践过，不说了。 我对虚拟资源转实际资源的看法 这应该是个难点，我闭门造车，想出了一种方法，自认为简单实用。 不管是虚拟资源还是实际资源，都要有一张表，暂称为虚拟资源表和实际资源表，关键就是把这两者一一联系起来。虚拟资源程序很好实现，要什么，在表中做个标记，用完了，再做个标记。实际资源也可以根据真实仪器来实现，在用的有一个标记，空闲的有一个标记，在系统执行每个测量函数之类的，这表都要检查，这样虽然可能系统每执行一句，这两个表都可能有改动，但现在计算机速度很快，这就是小菜一碟，内存1G才100多，不在乎。当然还有一张表，就是虚拟资源到实际资源之间的连接表，这个就涉及开关矩阵和适配器了，我最多每用一次查一遍。所有的这些都是用的时候去查，去临时构建，这样就省去了麻烦。有人用有向图动态实现，算法复杂。有人基于静态的资源关系，人为先配置好，虽编程简单，但人为把资源匹配，数据多的时候较费人力。自我感觉有些创意，还小高兴一下，但发现郭瑞的论文早就提到，诸位想得到比较严谨的说法，还是看看人家写的。 但有一点可以说是我独创，用C++中的CLASS来做比喻，可以充分利用CLASS的继承、派生特性，ATLAS中的REQUIRE完全可以定义为CLASS，测量语句中的MEASURE就如同CLASS的实体，测量范围比原定义小，是派生，又省去写不少重复的要求，是继承，再小高兴一下。 话说到此处，该说的也差不多都说了，但要实现起来，还是比较艰巨的。ATE这一块是博大精深，我现在涉及的只是冰山一角，感谢众多前辈做的工作，使我可以延着你们已经开辟的道路走下去。本文没打算做论文写，文中引用的语句皆未标出来源（本人也比较懒）,望见量。其实要得到这些出处也不难，keywords用ATLAS的论文就是了，总共也没几篇。在此再次请求，谁有ATLAS编译器如PAWS，共享之，不胜感激。Email：xiazhifei@yahoo.com.cn