End-Of-Line test system - Page 1
Forum section: electronics / projects

author: css
author_rank: Newbie
timestamp: December 25, 2018, 06:56:46 pm
content: Hi allWe are building a new End-Of-Line test system for an electronic unit and seek some advice.Attached is an illustration of the setup. The main purpose is to make the EOL test system easily scalable.In short, the system is designed as follows:1. A PC is connected to several "test rigs" using Wifi2. Each test rig consists of a raspberry pi zero w + a custom board (with relay, measurement point, connections to the PI, etc.).3. A Device Under Test (DUT) is connected to each test rig.What we would like to do is to initiate the tests from the PC and get the results back on the PC. The execution of the test sequence is done by the RPI. The test sequences may differ depending on the configuration of the specific DUT.Currently, our solution is to use Jenkins on the PC and let Jenkins initiate test jobs on the RPIs. The test jobs will be written in Python and will report back to Jenkins if the test was successful or not.We seek advice on the following:- Any "control software" better suitable than Jenkins on the PC?- Any Python frameworks suitable for EOL testing?- Any Python reporting systems which integrate easily with Jenkins (or an alternative control software)?- Any alternative ways to accomplish above?- Any experiences with EOL-testing at scale?Looking forward to your repliesThanksBrChristian

author: gmankev
author_rank: Newbie
timestamp: December 27, 2018, 10:39:42 am
content: Its a while since I worked on a python test framework, but we did a lot of hardware test with custom DUT and interface boards. Some of this may easily be covered in now in standard test frameworks.-) Eliminate all manual work of setting a file here, running a script there, there will be mistakes..- ) try and appoint local masters of the framework who really care about its efficiency and running tests well1) Use a stable configuration in git and check it out new every night to your rpis.. You dont know what local design went on that day desigining the test2) have your test scripts 'require items_of_infra' then let your test runner query the environment, or stored state to define which rpi is best suitable for the test3) Have standard reporting methods, that can be easily graphed4) try and work hard to have standard test suites that run quickly for regression, and add on the new test suites at the end.5) aim to batch your tests and prepare to reassert a stable config when tests start failing.6) have standard calls to restart, gather crash data, and run them similarly in all test suites7) methods it reserve test equipment, so that batches of tests will not overrun one another or interfere with someone elses late night debughave simple ways of reading the hardware id of hte custom DUT or interface board. After months of work, you can easily have variations in test rigs that will be useful to know and record9) make sure your batch method can quickly run short tests quickly so that engineers have the one environment for all tests

author: max_torque
author_rank: Super Contributor
timestamp: December 27, 2018, 12:59:52 pm
content: Personally, unless there is a very good reason to use it, i'd avoid wireless coms!Given the ease of implementing wired coms and the robustness of those coms, wi-fi seems an unnecessary extravagance to me!

author: css
author_rank: Newbie
timestamp: December 27, 2018, 01:14:34 pm
content: Hi,thanks for the feedback. gmankev, you have some really good points, thanks.max_torque, I agree that it would be nice to avoid wireless, however, I think the formfactor of the PI Zero is better suited for this application (compared to the regular PIs) - unfortunately, it does not have wired ethernet.Any suggestions on the python test framework? seems that most test frameworks are designed towards testing of python code ("unit-testing") not "system-testing" of devices.

author: coppercone2
author_rank: Super Contributor
timestamp: December 27, 2018, 02:09:13 pm
content: i recommend you use isolated connections to prevent ground loops and fortify those interface electronics with lots of protection if you are making home brew assembly line test equipment. the last thing you want is a batch of damaged products going out damaged by the testers. and probobly a verification procedure for the tester to be performed once in a while to make sure its right, being calibration, voltage level tests, jitter, glitches, etc.they did not design a raspberry pi for industrial manufacturers its a learning computer.and put everything in shielded boxes, give the PC a surge protector and use ESD precautions.and if its part of your ISO procedures and something breaks your line is going to go tits up until its fixed. a serious recommendation would be to have a duplicate PC system in case it breaks, then 5 years later it stops working because some hard to find incompatibility issue. Factories end up running windows 2000 machines in the year 2018 with software that depends on the old windows etc... but it can probably happen anywhere, last thing you want is a high priority weird software problemand keep in mind how much RASPI changes over the years. I have had issues with raspberry pi software working on the older models but not the newer ones. i thought linux would be magic but it just ended up pissing me off.

author: LapTop006
author_rank: Unknown
timestamp: December 28, 2018, 02:39:36 pm
content: Bunnie wrote ablog postabout a testing framework calledExclavethat might be something to build on.

author: css
author_rank: Newbie
timestamp: January 06, 2019, 11:32:39 am
content: HiThanks for your replies.I will look into Exclave.Br