标签: ats

这是我以前在百思论坛上发的，参考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