Universal Functional Test (UFT): A Cost-Effective Manufacturing Test Development Software Platform. Compactness: When writing a functional test a common step is to look for the appearance of a specific phrase, then continue to the next step OR come to an error/default condition after a preset timeout. The following 8-line tcl/expect code snippet is built on to make a number of the basic procedure calls that make up UFT. : package require Expect catch {open "com1:" r+} s catch [exp_spawn -noecho -open $s] set timeout 10 expect { "Boot Menu" {set productType UbootMenu} default {set productType generic} } This small amount of code performs the following functions: Open a serial port and passes the port it to expect. Sets a variable “productType” to “UbootMenu” if the string “Boot Menu” appears anywhere in the text produced by the port within 10 seconds. Program execution continues immediately upon this condition being met. All other conditions including errors result in productType being set to “generic” execution to continue after 10 seconds. For comparison, the following table shows the lengths of similar sample code in several other languages. Since these are publicly posted samples they do not have the exact behavior as described in the above Tcl/Expect snippet. The deviations are noted in red and would take more code to achieve the desired result. Modularity: Reliable use of test software with different hardware is a basic building block of this system. Each UUT/Tester operation is abstracted to a generic procedure call. For each UUT type and each Tester component, there is a “personality” script file containing these procedure calls. Included in the same file are any parameters required to perform each necessary operation on the given device. Devices that are out-of-rev can be upgraded automatically to current-rev prior to test. This simplifies the burden on the test engineer by minimizing the number of test varieties that must be maintained. Custom content such as test machine configurations, test steps and limits are stored in configuration files. Auto-Recognition of UUT: The general-purpose UUT-thread is provided with specific strings output by the various product families early on in their boot processes. These are used in the “Waiting for UUT” state to determine which “personality” script to load for test. Further uniqueness broken down in the “personality” script defines the use of any combination of product characteristics such as model, HW revision, FW revision, SW revision. Each UUTs has a unique connection port, and is addressed from 1 to N by logical port number (whether local, terminal server, or chassis port number). Ports may be reserved for special functions such as firmware upgrades, so your operators don’t need to press any buttons on the computer to perform these steps. Disconnect Detection: Non-idle disconnect detection or “Crash” of the product’s CLI is always a possibility. This expectation is built into the low-level routines for interacting with the product as a “Timeout” error, generally a failure. Alternatively, there is an accepted issue in your product that occasionally causes negative results like a crash, UFT can employ fault-tolerance to recover and continue the test. Idle disconnects are disconnects detected during the idle state, when the Operator is expected to disconnect the product. UUT thread loops through simple commands such as LED diagnostics, receiving the appropriate command prompt back from the product. When a command prompt is not received within a UUT-appropriate timeout, the UUT is assumed to be disconnected. The UUT thread displays final results and prepares itself to detect the next new UUT. The results are cleared from the screen upon the detection of the next UUT. Logging: A unique logfile is generated for each UUT session. Taking advantage of the unique nature of physical interfaces, there can only be one UUT at a time per Terminal Server port. Adding a timestamp to those details makes a unique filename as follows: [TestName]_UUT_[StationName]_[PortNumber]_[Time_Datestamp].log At the end of each test, logs are immediately sent to the server via fault-tolerant mechanism so that production does not stop for network/server issues. This provides an indelible record of the test while permitting production to continue even while your network is down. If the same UUT returns to the tester several times, the logs are NOT appended nor overwritten – there is a unique log for each session. All communication with the UUT or test equipment is in the form of a command-response dialog, which at times results in multiple dialogs going on simultaneously. Fortunately, there is a standardized, plain English way to track a dialog involving multiple parties. Logfiles are in playbill script format as follows: [Timestamp][Speaker:Port]:[Message] This allows technicians to view the events chronologically, or find specific events with a search. UUT logs do NOT key in on the keywords in the “expect” statements, instead recording comprehensive records of everything said by all parties. Some tests produce graphical, directory structures, or other digital collateral. This is captured along with the log file and submitted to the central repository in zip format. For More Information If you have an questions or want to know more, click the button below to email us or schedule a meeting.

Universal Functional Test ( UFT ): A cost-effective manufacturing test development software platform. J-Testr : A hardware and software platform designed for straightforward and re-usable development. High-Cost Problem Functional test in the manufacturing process requires custom development due to the unique nature of each product. The manufacturing mindset is to minimize or eliminate custom work, as it is neither inexpensive nor easy to scale. There are three general approaches for development of manufacturing tests, each with its own pressure against reusability: 1.) In-house test engineers at the end of the New Product Introduction (NPI) cycle are often under pressure to win back delays that have accumulated all along the development process. 2.) Outside test resources are generally constrained by the project bid, which is optimized for the product in question rather than reusability. 3.) Quick-deploy off-the-shelf functional test solutions generally lack key features which much be added later by returning to approach 1 or 2. Solution: Reusable Test Technologies UFT is designed from the ground up to automate the functional test processes to the greatest reasonable extent in order to: 1.) Optimize test developer and operator’s time, increasing productivity and decreasing cost. 2.) Reduce operator error, increasing productivity and avoiding false-passes, which can result in Out-Of-Box Failure or OOBF. J-Testr takes a similar software approach but leverages its own hardware platform. 1.) Supports both open-frame or clamshell “pogo-pin” fixture approaches. What about clamshell fixtures? While it is possible through complicated fixturing to “fully” automate a test process, many automated steps diverge into corner-cases which become increasingly expensive to automate for decreasing benefit. While clamshell fixtures necessitate full automation due to their restriction of technician access, open-frame fixtures allow access to the product. This fixture design approach opens up choices for cost cutting that are supported by both UFT and J-Testr . The goal when developing an open-frame test is to pick all the low-hanging fruit and cover critical features, allowing the operator to make some judgment calls at higher levels of complexity to save time and money. These platforms achieve this by providing easily reconfigurable dialogs for interacting with the operator. What about intricate functions? Any step deemed too expensive to automate is offloaded to the operator with simple, well-written instructions and/or pictures. These value decisions occur at various points in the development process against a test plan and can be handled with a minimal amount of interaction between the test engineer and the product team. Since the manual steps are easy to set up, there is little effort wasted if the decision to automate comes later on in the product’s lifecycle. What sets these solutions apart from others in the industry? Built for scalability and reusability, both UFT’s and J-Testr’s libraries of test routines have been growing for well over a decade. While they already include subroutines to perform many tests needed, each overall test plan is customized and the library expanded to ensure a given product meets its specifications. When a product fails a test, the operator is presented with details from the test and optional diagnostics relating to specific components. These test solutions ensure each manufactured product is correctly… Moving itself Measuring Analyzing data Doing whatever the product does … and is ready to be included into the next assembly or shipped to a customer. If you have any questions please send us an email or talk directly by scheduling a Calendly meeting. Click below.

Universal Functional Test (UFT): A Cost-Effective Manufacturing Test Development Software Platform. Production is a continuous operation. Each unit must endure a series of tests, but it will also be followed by another unit. A state machine is used to usher a single product through test in a controlled manner, resetting for the next product. The Process The program initializes the designated port for communicating with the Unit Under Test (UUT), then waits to hear from it. As the UUT boots up, it announces various pieces of information which are used to identify the UUT and load the appropriate test program. When immediate start is not desired or for products that don’t identify themselves, the operator scans a barcode or selects from a drop-down to select the product. A an optional “start” button allows the operator to initiate the test. The test script is generally a list of steps with attributes like diagnostics and critical failures (end test without proceeding to the next step). Procedural or decision-tree code can be added for optimal performance. For instance a top-level test that confirms that many things are correct can be followed only on failure by sub-tests that provide further diagnosis. Upon completion of the script, UFT waits in an idle state until the UUT is removed, then resets for the next UUT. Questions? If you have an questions or want to know more, click the button below to email us or schedule a meeting.

Universal Functional Test (UFT): A Cost-Effective Manufacturing Test Development Software Platform. Reuse and Scalability Before the First Line of Code. CAE Integration uses Tcl/Tk for the versatility of the language. But the most important aspect of this software is its reuse and scalability even before the first line of code. After a survey of programming languages, Tcl/Tk was selected as the base language of UFT for the following reasons: Cross-Platform Tcl/Tk is a cross-platform language purpose-built to write middleware programs. The language’s author, John Ousterhout, named it Tool Command Language (Tcl) when he designed it to automate many CAD design operations in different applications. It has since become an integral part of Xilinx Vivado design suite and other FPGA tools. Interpretation Tcl is an interpreted language, allowing the developer LIVE DEBUG capabilities. There is no need to stop the test, recompile, or get the product back to a specific state to debug the test. The test engineer can interactively query, debug, alter, and rerun the code from the Tcl command shell while the program is running and the product in the required state. Extensions and Sourcing The Tk graphical extension to Tcl is a high-level language for generation of GUIs with minimal coding. Tk is open-source and extensible, providing simple methods for inclusion of tools developed by a community of open-source contributors. Expect Expect – the number one Tcl/Tk extension for manufacturing. Originally developed for taking scripted control of a command-line program to the next level with interaction (Don Libes 1990), this language is ideal for interacting with any hardware that presents a command line interface (CLI) whether it be over serial or network connection. UFT uses Expect to communicate with: Unit Under Test (UUT) supporting command-line interface Programmable test devices such as Standard GPIB test equipment Bulk call generators Network Switchgear Test equipment with non-standard interfaces In Summary Tcl/Tk is the language CAE Integration loves most. Not only is it versatile and cost-effective, but the LIVE DEBUG capabilities highly accelerate development of the interface with your product and test equipment. Click below to email or schedule a demo.

If we had a crystal ball, we would only test the bad boards. But we don't, so why do it? Often a company with a new product is so excited to introduce it that manufacturing test is overlooked.  Products roll off the assembly line and some staffers turn them on and use them before shipping them.  This can go well for a time but eventually one of the following problems occurs: A customer has a bad out-of-box experience with a product that fails in a way not covered at test. A “bad batch” of product is produced and many units can’t be shipped. Should We Go To The Design Engineer? From here it is natural to ask the product’s designer(s) what to do about it.  The designer is usually already assigned a new product to develop and is responsible for keeping the other project on schedule.  As a result the problems reported by the manufacturing team are generally interpreted as minor projects to be completed as quickly as possible.  Often the designer has jigs used personally during prototype to validate the design, and provides or adapts one or more Design Validation Tests (DVT) to production.   Design Validation Tests Effectiveness When DVT tests are used to diagnose individual problems that occur in production, they can initially be quite effective.  Each DVT test covers one feature in depth and can provide a lot of insight for a problem within its scope.  The in-depth, investigatory nature of DVT makes it time consuming to apply.  This frustrates the manufacturing team when products pass the test because of the time and money spent running the test on a board that did not “need” it.  What manufacturing needs is tests that cover a breadth of hardware quickly. W hy not go back to the design engineer and get the DVT test adapted for manufacturing?   Here are the Differences: Manufacturing tests are much different from product design and validation.  It takes time and practice to get good at developing manufacturing test.  You pay your design engineers to be good at designing products.  Why pay your product designers to stop designing and learn how to develop manufacturing tests?  And find a go between to get the needs of the manufacturing team implemented into the test solution. . . Ready to Take the Next Step? OEMs hire us to develop manufacturing tests so their design teams can focus on developing the next product. CAE Integration specializes in meeting the needs of manufacturing while cutting engineering burden. Hit the button below to set up a meeting.

Tcl-Expect Rumors Expect was originally intended to allow programmatical interaction among various programs on Linux and Unix operating systems.  UFT primarily uses Expect to interface with equipment rather than programs. For a better understanding of why this distinction matters, it is important to understand a few fundamental differences between Windows and Linux.  In Linux and Unix everything is a file.  Not just most things, not just normal things, everything everything is a file.  When opening a file the caller has control over whether and how the input and output pipes are connected – a requirement for interactive control of a command-line program.  Since Tcl/Tk is cross-platform it was also ported to Windows, which at the time permitted connection of input and output pipes to the calling program – if the target program was compiled with that in mind.  Microsoft uses Windows to sell various products and services, and occasionally introduces new and/or discourages old interfaces for inter-process communication (IPC) such as: DDE COM Shared Memory File Mapping Sockets RPC ALPC Compatability Backward-compatibility has been a historical feature of Windows, but certain features are left by the wayside each time the number of bits in the instruction set increases (16-bit, 32-bit, 64-bit).  Expect works with programs written for 16- or 32-bit Windows, such as Cygwin and all of its utilities.  Expect for Tcl/Tk also has a handy quirk echoing the entire dialog to the Tcl console – which is really handy in the manufacturing test environment. Modification Since UFT primarily uses Expect to interface with equipment rather than programs, Windows restrictions on inter-process communication generally don’t come into play.  For occasions where we need Expect to interact with something Windows actively blocks, we developed a Linux bridge.  Since Expect for Linux does not handily display the entire dialog in the Tcl console like the Windows version does, we added this functionality into the Linux bridge program. Please leave a comment, and share your own TCL - Expect experience. To learn more click the button below to contact us.

How we tackle Functional Test Why connectors are the way to go for functional test. While shorts on connector pins are a problem, these are easy to find.  Opens are the manufacturing defect on connectors that make OEMs lose sleep at night.  More technical diagnoses for opens include cold solder, no solder, lifted pin, etc. These can be caused by a variety of minor processing, handling, or supply-chain issues. But why not use flying probe or clamshell? Drawbacks to Flying Probe or clamshell Pogo-pins such as Flying Probe or clamshell fixtures can fully test connectors that are: Rugged. Pointed in one direction. Not subject to false pass under mechanical load. A Not subject to relocation due to design changes. Pogo-pins must press the connector pin against the board.  This is not a test feature with options but a law of physics affecting all pogo pins because they are spring-loaded. In the case of an open defect, the pogo pin can force the connector pin to conduct only during the moment it is tested – a false pass.  This test challenge affects all surface-mount connections.  While some through-hole connections can get excellent coverage using pogo-pins, these connectors are often presented to the user.  In this case a test-mate to check for bent pins and mechanical defects can avoid embarrassing Out-of Box Failures. Why we go with connectors The only way to guarantee the performance of the connector is to test through the connector. Also, when cables are selected for the UUT connection, it opens up cost savings opportunities regarding test coverage.  Connectorized test allows the fixture to be constructed in an open-frame fashion allowing your technicians to diagnose failing boards by probing with their oscilloscope or multimeter.  This means the functional test code can focus on a top-level PASS/FAIL result drastically reducing the amount of code required for the test. Clamshell fixtures just don’t offer access to human measurements. If you want to learn more about Functional Test, click the button here to read. Contact CAE Integration today for a test plan optimized for your specific product.

Contest: Comic Edition Here at CAE Integration we are a bunch of nerds. This is a prerequisite to be in the field. To have some fun we were trying to think of some fun comic strips to showcase the difference between design and test engineers. Below is one that the team put together. Is the above true? Let us know in the comments down below. Welcome to the Contest Down at headquarters we want some more cool comic strips to put on the website and on our walls. We want to see some of your thoughts regarding the differences between design and test engineers. Anything goes in regards to submission. The only requirement is that it must be in the form of a comic strip and of your own work. Hand-drawings, graphic design, AI-Generated content are all acceptable in this contest. In addition, if you don't have any artwork, you can give us a description and we will run it through the AI that generated the comic above. All submissions are due by 11:30 PM EST May 4th, 2024. Prizes So, what do you win other than making some fun comics? Well, any comics deemed worthy will be posted on our website and all our social media pages tagging the creator. The first prize winner will get a $50 gift card of their choice. Only one entry per person. Best of luck! May the Fourth be with you. If you need some ideas, click the button below. Please email your comic strips to us at info@caeintegration.com.

Expos have seen dwindling attendance since COVID. This means the few who do attend get the advantage of additional attention from vendors teaching and displaying new technologies. "Even though I only attended half of the event, the latest developments surprised me!" – Chris Plumlee Technical Presentations: Criteria for Solder Alloy Adoption by Michael Osterman, Ph.D., CALCE. Michael is an academic researcher performing a unique slow-path study on solder joint reliability. He has found numerous discrepancies between the standard industrial assumptions about acceleration factors used in Highly Accelerated Life Testing (HALT) and real life applications. These erroneous assumptions in HALT testing generally result in additional failure modes that do not represent real failures of the assembly in the target environment. In other words HALT accelerators often introduce false failures. The slow path is to run representative assemblies through a real time (non-accelerated) life test in numerous target environments (temperature and vibration) over the course of years. This would never happen in industry, and I’m really glad someone in academia took on this project. He is still running the study and will be publishing soon. The result will be a table mapping a variety of solder metallurgies to a variety of applications. Overcoming the Challenges for Implementing IPC J-STD-001 in your factory by Denis Barbini, Ph.D. Denis presented an overview of a CM’s validation responsibilities under J-STD-001. He gave various examples of process changes a CM would make including: Reasons to change Risks How to select the appropriate validation to fulfil the J-STD-001 requirements. Technologies presented by vendors: The standard offering of the latest and greatest assembly and test equipment, solvents, and materials were there. Each company had experts present ready and willing to discuss specific applications. A few items that were new to me follow: Promosolv Coat UT10-UV by Inventec Performance Chemicals – a conformal coating so thin that rather than mask the connectors you allow the contact mating force to brush aside the coating. Foil Strain Gages and datalogger by Kyowa Americs – attached to a circuit board these give live feedback on circuit board flex and strain. Afraid your board is being damaged in any of the following steps? Instrument it up and find out for sure! ICT Test loading Assembly End Use Cases Scanning Acoustic Microscope by PVA TePla is an alternative to X-RAY specializing in detection of solder cracks and joint or PCB delamination. Final Thoughts Engineers are not the most social people and may take some convincing to get to events. The pressure against attending big public events has not worn off; attendance by engineers not running a vendor table was low. What engineers need to know is that they are missing great advances in technology presented at these expos! I attended for only half the day and was surprised by the latest developments. If you are interested in learning more about upcoming technologies hit the button below.

How does CAE Integration save you time and money in test development? We start off by asking a lot of questions.  We have learned from previous projects to cover a lot of ground to find out what is most important to you -- as well as what isn’t.  The biggest lesson we have learned is that each project is different and requires a flexible mindset to find an optimal manufacturing test strategy. How our Plan Begins We go over product design for opportunities to use structural test, a “black-box” approach that gives a lot of coverage quickly and inexpensively. We identify options to test all areas of your product design and organize them into an informal  test plan. We discuss our informal test plan and invite your input.  Often there are tools you already have that we can repurpose or incorporate into manufacturing test so we do not have to “reinvent the wheel”. For critical areas we have a brainstorming session with shadow boxes, cardboard cutouts, and crazy ideas. We formalize the test plan and come back for more input from your team on critical areas before we begin development.  Often at this point additional tools and approaches are provided by your team that further shorten or improve the test development project. Considerations Then we get to work.  Our team’s job is to make things easy for your team, so we keep you in the loop during the project but don’t continue to pester you with questions.  A good manufacturing test needs to be quick and easy to: Learn Perform Maintain When is the best time to start this process? Beginning Stages The best time to start manufacturing test development is right after the product architecture and major components are selected.  Without even a prototype the only test development that can be done at this stage is a preliminary test plan.  However, any hooks we suggest in the test plan to minimize costs will be the least expensive to implement at this stage.  Companies minimizing Time To Market (TTM) may send us a prototype product so we can develop longer-lead tests in parallel with their product development.  The final product is invariably different from the prototype, so we perform the initial test development with an eye towards flexibility.  Test programs are written with easily adaptable steps and test limits.  Fixtures are 3D printed for quick and inexpensive revision to fit the final product. New Product Introduction (NPI) is a critical time for an OEM, and we plan extra availability to support last-minute changes and corrections to our tests to support your manufacturing goals.  The requirement changed from MUST DO “X” to MUST NOT DO “X”?  No problem!  We have weathered many NPI events and are ready for last-minute changes, minor and major alike. What if my product is already in production? CAE Integration will meet you where you are.  If you have legacy test or no test at all, we can address your manufacturing pain points and weaknesses to put your production team on target. How many copies of a fixture do I need? At least two.  If you have a Contract Manufacturer (CM) they should be running test there to close the loop on their continuous improvement process.  Your main facility also needs a fixture to: Run product that passes at the CM but fails later Run product that is returned from the field Run failing product the CM sends over with questions Serve as a backup for the fixture at the CM. If you have global service centers that need to run the same test, they will also need copies of the test fixture. What if my production is stable for awhile but suddenly all the product starts failing test, or worse it passes test but exhibits other problems? The CM says it’s a design problem. Design says it’s a process or test problem. Purchasing says it’s a supply chain problem. CAE Integration supports the solutions we sell into your production line.  Our highest priority is to get your production line back up and running.  While we would like all problems to be understood to root cause and resolved at the same level, there are often process or design limitations requiring an interim solution.  This generally means implementing temporary steps and manufacturing and test, tracking them, then revising them with the final solution is in place.  We will work through the problem with your teams to get you back on track and stay on track.