Patent Description:
The manufacturing, production and integration of an electronic system includes the production and testing of circuit card assemblies and printed circuit boards (PCBs). Which go thought different levels of testing as the circuit card/board moves along the production process. Failures are often encountered on which engineering support is needed to resolve the issues before circuit card assemblies and PCBs can be released to a system integration step.

For example, in an in-circuit test (ICT), an electrical probe tests a populated (PCB), checking for short circuits, open circuits, resistance, capacitance, and other basic quantities which will show whether the board was correctly fabricated. The ICT is typically performed with a bed of nails type test fixture and special test equipment, or with a fixtureless in-circuit test setup. Similarly, functional testing, for example, quality assurance testing, is a method of testing that inspects the functionality of a system or an application without peering into its internal structures or workings. Functional testing typically involves six steps:.

However, current processes and troubleshooting system do not allow for fully designing anywhere, producing anywhere, and integrating the circuit card assemblies and PCBs (boards) anywhere, especially where the technical knowledge needed to troubleshoot them when they fall out of the production line is far away from where the boards are being produced. The logistics to put the technical knowledge and the falling out PCBs together involves traveling of the technical knowledge, or shipping of the faulty boards and time and cost not directly associated with the troubleshooting.

A test point is a location within an electronic circuit utilized to monitor the state of the circuit or to inject test signals. During manufacturing test points are used to verify that a newly assembled device is working correctly. Any equipment that fails this testing is either discarded or sent to a rework station to attempt to repair the manufacturing defects. Also, after production and sale of the device, test points may be used at a later time to repair the device if it malfunctions, or if the device needs to be re-calibrated after having components replaced.

Typically, PCB testing of the finished products validates the performance of the PCB with a test function. Defects are exposed during the testing step and at that time technical expertise are brought into the process to correct defects and return the corrected PCBs back into the production flow. Troubleshooting defective PCBs require intimate knowledge of the failed circuit(s) in question as well as physical proximity to probe electrical points on the PCB. However, most defects tend to repeat such that a knowledge base of defects allows for less knowledgeable personnel to fix defects as the production matures.

<CIT> describes an online fault diagnostic apparatus for a circuit board. The online fault diagnostic apparatus comprises an upper computer and a lower computer, wherein the upper computer is used for performing online signal processing and fault diagnosis, the lower computer is used for providing needed signals for a tested circuit board and uploading test information, and the upper computer and the lower computer are connected and communicated by using a serial bus. <CIT> describes a system and method for providing adaptive manufacturing diagnoses in a circuit board environment. An example method is provided and includes collecting inputs for a circuit board under test; evaluating historical repair records using a neuron network; providing repair actions for the circuit board based on the historical repair records; and providing an output reflecting a particular component of the circuit board to be replaced or to be repaired, where the output is associated with a developed probability of successfully fixing an issue that was identified by the test. In more specific implementations, the inputs include fault syndromes and log files associated with the circuit board under test. Additionally, at least one of the inputs of the neuron network is a syndrome vector extracted from a failure log. In yet other instances, particular outputs having higher probabilities are selected as the repair actions. The neuron network can be weighted using diagnosis knowledge weights.

The claimed invention provides a system for autonomous trouble shooting of a circuit card assembly according to claim <NUM>, a corresponding method according to claim <NUM>, and a non-transitory storage medium storing a set of corresponding instructions according to claim <NUM>.

In some embodiments, the disclosed invention is a system and method for autonomous trouble shooting, using artificial intelligence and machine learning. In some embodiments, the disclosed invention is a system for autonomous trouble shooting of a circuit card assembly having a plurality of replaceable components. The system includes: a test station including: a first computer having a display, memory coupled to the computer to store an artificial intelligence (AI) program and a knowledge database (KDB), wherein the KDB includes a plurality of indexes, each index corresponding to associated test points of a unit under test (UUT), and respective acceptable test results for each test point represented by an acceptable test vector, a test probe to test the circuit card assembly as the UUT, and a network interface to communicate with a communication network. The system further includes: an operator station including a second computer and memory to send commands to the test station via the communication network to teach the AI program to capture and store the acceptable test result for each test point of the UUT by the test probe, in the KDB, wherein the AI program when executed by the first computer commands the test probe to test the UUT, stores the results in a test result vector, compares the test result vector with the stored acceptable test vector, and displays recommendation as which replaceable component in the UUT to be repaired or replaced.

In some embodiments, the disclosed invention is a method for autonomous trouble shooting of a circuit card assembly having a plurality of replaceable components. The method includes: storing an artificial intelligence (AI) program and a knowledge database (KDB) in a memory coupled to a first computer by a test station, wherein the KDB includes a plurality of indexes, each index corresponding to associated test points of the circuit card assembly identified as a unit under test (UUT), and respective acceptable test results for each test point represented by an acceptable test vector; testing the UUT by a test probe; and based on a command received via a communication network from a second computer of an operator station teaching the AI program to capture and store the acceptable test result for each test point of the UUT by the test probe, in the KDB. The AI program when executed by the first computer commands the test probe to test the UUT, stores the results in a test result vector, compares the test result vector with the stored acceptable test vector, and displays recommendation as which replaceable component in the UUT to be repaired or replaced.

In some embodiments, the disclosed invention is a non-transitory storage medium (such as RAM, ROM, hard drive and/or CD) for storing a set of instructions, the set of instructions when executed by one or more processors perform a method for autonomous trouble shooting of a circuit card assembly having a plurality of replaceable components. The method includes: storing an artificial intelligence (AI) program and a knowledge database (KDB) in a memory coupled to a first computer by a test station, wherein the KDB includes a plurality of indexes, each index corresponding to associated test points of the circuit card assembly identified as a unit under test (UUT), and respective acceptable test results for each test point represented by an acceptable test vector; testing the UUT by a test probe; and based on a command received via a communication network from a second computer of an operator station teaching the AI program to capture and store the acceptable test result for each test point of the UUT by the test probe, in the KDB. The AI program when executed by the first computer commands the test probe to test the UUT, stores the results in a test result vector, compares the test result vector with the stored acceptable test vector, and displays recommendation as which replaceable component in the UUT to be repaired or replaced.

These and other features, aspects, and advantages of the present invention will become better understood with regard to the following description, appended claims, and accompanying drawings.

In some embodiments, the disclosed invention relates to the production of circuit card assemblies, where technical expertise to troubleshoot production defects resides in a different location where the production and testing is taking place. The disclosed invention provides a virtual presence of the technical expertise and thus eliminating the need for traveling or shipping of defective goods. The disclosed invention includes artificial intelligence (AI) capabilities to the testing sites such that as the production matures, troubleshooting can be performed autonomously by an autonomous system capable of providing solutions to common production defects. This way, the disclosed invention places the engineer with the needed technical knowledge in the same place as the defective boards via a broadband network. The virtual presence of the technical knowledge eliminates the need for traveling and shipping and delays associated with that activity.

In some embodiments, the disclosed invention provides the capabilities to remotely troubleshoot circuit card assemblies and PCBs (boards) in the production facility making it possible to design anywhere produce anywhere. This approach also allows for the engineering knowledge to be transferred to the test station such that this knowledge can be mined to troubleshoot the boards in future by less experienced support personnel and as the product matures autonomous troubleshooting is highly desirable for the cost benefit and the fact experts move to other products and other programs taking with them the require knowledge to support an aging product.

<FIG> is a block diagram of a trouble shooting environment <NUM>, according to some embodiments of the disclosed invention. As shown an operator station (OS) <NUM> is in (remote) communicating with a troubleshooting (or test) station (TS) <NUM>, via a communication network <NUM>, such as a private or public network. The OS <NUM> includes a computer <NUM> including memory and a graphical user interface, network interface circuit <NUM>, the X, Y coordinates of the UUT <NUM> (e.g., stored in a memory), a robotic application <NUM> (e.g., stored in a memory) to control one or more robot arms <NUM> for probing the UUT <NUM>, and an oscilloscope application <NUM> (e.g., stored in a memory) for capturing, analyzing and displaying the test results. The one or more robot arms <NUM> are capable of holding scope probes and capable to probe the unit under test.

The TS <NUM> includes the UUT <NUM>, one or more robot arms <NUM>, an oscilloscope <NUM> for capturing the test results, and software and or firmware stored in a memory for execution by a computer <NUM>. The oscilloscope <NUM> is capable of capturing probed test data to be transmitted to computers <NUM> via network interface <NUM> and communication network <NUM>. In some embodiments, the software/firmware includes a robot arm driver <NUM> for controlling the one or more robot arms <NUM>, an AI application (program) <NUM> for performing autonomous trouble shooting using a knowledge database (KDB) <NUM>, handshake routine <NUM> and network interface <NUM> for communicating with the OS <NUM>. TS <NUM> also includes a map of test point flags <NUM> and a map of X, Y coordinates <NUM>, for the UUT <NUM>. In some embodiments, the AI application <NUM> includes a database of X, Y coordinates of the UUT <NUM> and acceptable values of the test results for each component of the UUT <NUM>. In some embodiments, this data base of X, Y coordinates may be part of the KDB <NUM>. The software/firmware sends control signal <NUM> to the robot arm <NUM> and the UUT <NUM>, and receives position feedback <NUM> from the UUT <NUM>.

A test point is defined by X, Y coordinates and thus probing the electrical activity on, for example, pin <NUM> of a component U34 corresponds to X, Y coordinates (for example, <NUM> on the X axis and <NUM> on the Y axis on side A of the UUT <NUM>). Consequently, a control command <NUM> to probe U34, pin <NUM> includes the X, Y coordinates (<NUM>, <NUM>) and the position feedback data <NUM> contains the actual position of the test probe such that a closed control loop guarantees the position (<NUM>, <NUM>), regardless of external influence such as vibration at the station, etc. In other words the position feedback data <NUM> would include X, Y coordinates (X+Δx, Y+ Δy) and a control loop makes correction to make Δ equal to zero.

In some embodiments, the disclosed invention troubleshoots UUT <NUM> autonomously and with no interaction with any operator, and is capable of offering troubleshooting recommendation based on the data stored in KDB <NUM>. KDB <NUM> captures valid results of data points defined by X, Y coordinates on UUT <NUM>. Typically, these X, Y coordinates <NUM> are already available in a file or database and are utilized during the manufacturing the bare board and the placement of the components on the bare board.

In a learning mode or troubleshooting assistance mode, the disclosed invention troubleshoots UUT <NUM> using troubleshooting station <NUM> and probes electronic circuits in the UUT <NUM> by the robot arm <NUM> as commanded by OS <NUM> and following the X, Y coordinates of test points. OS <NUM> sends probing commands to TS <NUM> via communication network <NUM>, as commanded by an operator using computer <NUM>. OS <NUM> also displays the results of the probing on a display of computer <NUM>, which includes a database of X, Y coordinates and expected electrical outcome at each coordinate. The results of the probing is captured by oscilloscope <NUM>, transmitted through the communication network <NUM>, analyzed by oscilloscope application <NUM>, before they are displayed.

<FIG> is an exemplary process flow on an operator station and a test station for a learning mode, according to some embodiments of the disclosed invention. In these embodiments, the disclosed invention includes a supervised learning process to capture and store acceptable results of the probing at each test point in KDB (e.g., <NUM> in <FIG>), such that acceptable outcome at each test point can be determined. Once the acceptable or unacceptable state at a test point is determined, recommendations to make test points acceptable are generated to assist with the troubleshooting of the UUT <NUM>. In these embodiments, the training process entails having an expert probe testing a UUT <NUM> via the robot arm <NUM> and the oscilloscope <NUM>. As the operator probes the data base of (X,Y) coordinates (e.g., <NUM>) and the acceptable values are created and stored in the KDB <NUM>. When defects are found, deviations from the acceptable value are identified that correlates with a particular component in the UUT and optionally, a weight is associated to each vector.

For example, at the end of the testing stage when all test points have been acquired, the test results can be seen as a vector space defined as (V<NUM> , V<NUM> , V<NUM> , V<NUM> ,. Vn ), where Vn is the result of each test point. If there is an UUT, on which there are eight components, U1 through U8, and <NUM> test points, TP<NUM> , TP<NUM> ,TP<NUM>, TP<NUM> and TP<NUM> , the vector (for each component) at the end of all the above-mentioned tests would be (V<NUM> , V<NUM> , V<NUM> , V<NUM> , V<NUM> ). Therefore, each test is associated with each variable of the test vector. Accordingly, for the above example with five test point, the test vector could be (<NUM>,<NUM>,<NUM>,<NUM>,<NUM>), if the UUT passes test points <NUM>, <NUM> and <NUM>. Each component will be affected by each test point differently and thus the optional weight associated with each vector may vary. As each vector is applied to each component U1 through U8, different weight is assigned to each component, for instance, V<NUM> will affect U1 by a weight of W<NUM>, but will affect U2 by a different weight W<NUM>. The learning process then learns the weights for each vector variable.

As shown in block <NUM>, the test station <NUM> sends a status to the OS <NUM>, for example, when and whether the UUT <NUM> is installed on a test platform and is ready for testing. Once the UUT is installed on the test station (block <NUM>), the OS sends a request for testing (e.g., request n) to the test station (block <NUM>).

In some embodiments, the request for testing is a data packet that contains a payload configuration for the oscilloscope to capture the test point value information such as: requester id, time stamp, time scale used, voltage scale used, trigger level, trigger mode, synchronization probe used, synchronization coordinates, probe used, testing point coordinates. For instance, a request to probe U34 pin <NUM> may have fields as those illustrated in Table <NUM> below.

Referring back to <FIG>, the test station <NUM> waits until the request arrives in block <NUM>. Once the request arrives, the test station executes the request by testing the relevant portions of the UUT <NUM> and send the test results back to OS <NUM>, in block <NUM>. The OS then waits until a response to the request is received from the test station, in block <NUM>. Once a response is received, the OS presents the response to the operator in block <NUM>, for example via the computer <NUM> in <FIG>. In some embodiments, the response from the test station is a graphic showing all the data captured at the test point, for example, a typical oscilloscope output displays the signal voltages, timing, frequency, and the like.

In block <NUM>, the OS <NUM> then sends good/bad flags to the test station <NUM>. In some embodiments, once the test point results are available to the operator, the operator may choose to:.

To accomplish this, the OS102 sends a packet to the test station requesting it to store the flags (if any) in the KDB as an acceptable response as well as the acceptable deviation to use it as a vector variable value to be used by the AI application <NUM>. For instance, an acceptable value for TP1 (test point <NUM>) could be 5V pick-to-pick and the acceptable deviation could be plus or minus <NUM>%. As a result, when determining whether a TP1 is passing or failing the test, any value between <NUM>. 8V and <NUM>. 2V pick-to-pick is declared as passing the test. In some embodiments, the request includes the fields shown in Table <NUM> below.

The test station <NUM> then waits to receive the flags, in block <NUM>. Every request includes one flag or no flag. If the received flag is a bad flag, which is determined by the test station <NUM> in block <NUM>, the test station discards it, in block <NUM>. If the received flag is a good flag, the test station stores it in the KDB <NUM>, in block <NUM>. The OS <NUM> then checks to find whether there are more test points to be processed in block <NUM> and ends the test session in block <NUM>, if there are no more test points to process. If there are more test points to process, the process returns to block <NUM> and repeats the above-mentioned processing for the new test point, as explained above.

In some embodiments, in the leaning mode, the process creates the KDB with the acceptable electrical behavior for each test point. Test point test results describe the electrical behavior of the test point and may include one or more of voltage values, time scale, frequency, duty cycle, and/or any electrical characteristic relevant to describe the behavior of the UUT. When the operator sends a request to test a given point, the test station responds as explained above and waits for the operator to send a good flag before the test point values are stored in the KDB. If the response from the operator is a bad flag, the test point values are not stored in the KDB and thus will not be used for future troubleshooting assistance or autonomous functions.

In some embodiments, the KDB include a plurality of indexes corresponding to associated test points and their test results. Each index is a test point number, which is define by X, Y coordinates of the UUT, and the test results are the properties describing electrical behavior of the test point. For example, a response to a request for "test point n" results on a response as "Rms voltage is 121V, voltage pick to pick is 333V, maximum voltage 166V, frequency <NUM> hertz, minimum voltage -<NUM> vols. " In this case, the test station waits for the operator to instruct weather to keep this test point values or discard it.

For the purpose of this example, if the operator decides that the test result is a good one and worth storing it as a reference value in the KDB <NUM>, the operator send a good flag response to the test station. Upon receiving the good flag, the test station stores the test result entry "test point n", which is the index to the values describing the electrical behavior of the test point, in the KDB. Once in the KDB, the test point n can be recalled.

<FIG> is an exemplary process flow on an operator station and a test station for a troubleshooting assistance mode, according to some embodiments of the disclosed invention. In some embodiments, the disclose invention assists the operator by making suggestions or answering questions for the troubleshooting of the UUT in this mode. The troubleshooting assistance process may entail the robotic arm probing X, Y coordinates autonomously per (X, Y) database and the artificial intelligence application comparing results with expected values stored in the database and presenting the results, as solutions to proceed with repair or replacement of a particular component in the UUT. As an example of troubleshooting assistance mode, if the operator requests "test point n" from the KDB (shown in <FIG>), a response is received similar to what is depicted in <FIG>.

Similar to <FIG>, in block <NUM>, the test station sends a status to the OS, for example, when and whether the UUT is installed on a test platform and is ready for testing. Once the UUT is installed on the test station (block <NUM>), the OS sends a request for testing (e.g., request n) to the test station (block304). The test station waits until the request arrives in block <NUM>. Once the request arrives, the test station checks to determine whether the request is for assistance, in block <NUM>. If the request is for assisting the operator, the test station executes an AI program and sends the troubleshooting solution (as a result of AI execution) to the OS, in block <NUM>. The AI routine for troubleshooting is further described below with respect to <FIG>.

For example, the request for assistance may take the form of "show me what this test point supposed to look like. " The test station then responds as explained above with the data stored in the KDB, if the request for assistance is in the form of how to fix the discrepancy at this time. The test station assumes all other test points are good and runs the AI application <NUM> with the faults found at this point. For instance, in the case of a system with ten testing points, assume that at test point <NUM> the operator has three test points that match the values in the KDB and two test points that do not match, there are still five more test points, before a full test vector can be defines for the UUT. In other words, the test vector at this point may look like (<NUM>,<NUM>,<NUM>, <NUM>,<NUM>, ?, ?, ?, ?, ?). If the operator requests assistance to fix discrepancies at this stage of the testing, the test station assumes the other remaining five test points that are not tested are good and executes the AI application <NUM> with a test vector of the form (<NUM>,<NUM>,<NUM>, <NUM>,<NUM>, <NUM>?, <NUM>?,<NUM>?, <NUM>?, <NUM>?), where "<NUM>?" is the assumed successful test.

In block <NUM>, when the request is not for assistance but a request for testing, a test point, the test station executes the request, compares the test results with the values stored in the KDB <NUM>. If the values found are within the acceptable values, the test station marks flag n associated to this test point as a good flag. For example, if the UUT has ten test points, the test vector for this test unit would be (V<NUM>, V<NUM>, V<NUM> , V<NUM> , V<NUM> , V<NUM> , V<NUM> , V<NUM> , V<NUM> , V<NUM> ). When the operator sends the request to test "test point <NUM>," the test station executes the request and compares the test result values for test point <NUM> with those stored in the KDB for test point <NUM>.

If the comparison is a good (acceptable) flag <NUM>, V<NUM> is given the value of <NUM> (zero) and the test vector would be (<NUM>, V<NUM>, V<NUM> , V<NUM> , V<NUM> , V<NUM> , V<NUM> , V<NUM> , V<NUM> , V<NUM> ). As more test points are tested, the test vector starts filling up with real flag values of passing or failing the tests, until all flags are defined for a final test vector of the form (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) for a UUT with no faults. Similarly, a test vector for a UUT with faults on tests <NUM>, <NUM> and <NUM>, would be (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>). Upon completion of probing all test point, the AI application is executed with the test vector created for current test iteration.

In block <NUM>, the OS <NUM> then waits until a response to the request (block <NUM> or <NUM>) is received from the test station. Once a response is received, the OS presents the response to the operator in block <NUM>, for example via the computer <NUM> in <FIG>. If the operator needs assistance (block <NUM>), the OS then sends a request for assistance in block <NUM>. The test station then responds to the request for assistance in block <NUM>, as explained above. When there are no more requests for assistance, the OS checks to determine whether the probe testing is completed in block <NUM> and ends the session, as shown in block <NUM>. The request in block <NUM> is different from the request in block <NUM>, at least for the field called "type of request. " For example, the probe request has different identification value than the request for assistance and depending on the type of request other fields could become irrelevant.

<FIG> is an exemplary process flow for an autonomous testing mode, according to some embodiments of the disclosed invention. In some embodiments, the process is executed only on the test station and the OS is not involved in the process, as depicted in <FIG>. In block <NUM>, the robot arms <NUM> are commanded to probe test point n of the UUT <NUM>, by the AI application <NUM>. The result of testing the test point n is then compared with flag n that is associated with test results of test point n, in block <NUM>. When there is a match (block <NUM>), meaning that the test result matches the expected value of test point n that is stored in the memory (for example, the memory of computer <NUM>), the robot arms <NUM> are commanded to probe next test point (block <NUM>) and probe test point n+<NUM> of the UUT.

However, when there is not a match (block <NUM>), meaning that the test result does not match the expected value of test point n that is stored in the memory, the mismatch is feed to the AI application <NUM>. In some embodiments, the KDB holds the acceptable values for each test point in the form of acceptable range values for any test point as shown in <FIG>.

When the probe testing is completed (block <NUM>), the test station executes the AI application <NUM> that includes all the mismatches related to the current test session for testing the UUT, presents solution to the OS as shown in block <NUM>, and ends the test session in block <NUM>. When the probe testing is not completed (block <NUM>), the test station causes the robot arms to probe next test point (block <NUM>) and probe test point n+<NUM> of the UUT, in block <NUM>.

Any test point with values outside of the acceptable range are considered a mismatch and the test point is flagged as a failed test point (bad flag). After all test points are tested, the UUT is defined by a test vector of (V<NUM> , V<NUM> , V<NUM> , V<NUM> ,. Vn ), where n is the number of tests for a complete test iteration. The AI application <NUM> then uses the mismatch values to populate the test vector with passing and failing values. Once the test vector is fully defined (populated), the function of <FIG> is executed for every replaceable component to identify which one(s) needs to be replaced. For instance in the case of ten tests, if the test vector is (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) indicating failure on tests <NUM>, <NUM> and <NUM>, the following will take place if the UUT is made of five potential replaceable components labeled U1, U2, U3, U4, and U5. <MAT> <MAT> <MAT> <MAT> <MAT> which leads to: <MAT> <MAT> <MAT>.

Assuming the weighs as calculated during the training stage are:
W12 = <NUM>, W15 = <NUM>, W17 = <NUM>, W22 = <NUM>, W25 = <NUM>, W27 = <NUM>, W32 = <NUM>, W35 = <NUM>, W37 = <NUM>, W42 = <NUM>, W45 = <NUM>, W47 = <NUM>, W52 = <NUM>, W55 = <NUM>, W57 = <NUM>, the solution for U1 though U5 will be: <MAT> <MAT> <MAT> <MAT> <MAT>.

As a result, the AI application recommends U3 as the candidate component for replacement.

<FIG> is an exemplary neuro circuit <NUM> for an artificial intelligent application, according to some embodiments of the disclosed invention. In some embodiments, the disclosed invention learns to perform troubleshooting by considering examples in the learning mode, for instance, the learning mode described with respect to <FIG> and automatically generates and implements troubleshooting solution from the learning test result examples that it processes. In some embodiments, each connection (artificial neuron) of the neuro circuit <NUM> can transmit a signal to another connection. An artificial neuron that receives a signal can process it and then signal additional artificial neurons connected to it. As explained above with respect to <FIG>, the process of learning is for the test station to allocate the right weight to every test result, so that the AI application can then utilize the weighted test results to suggest and/or implement troubleshooting solutions.

In some embodiments, the AI application <NUM> includes a (X, Y) data base of XY coordinates and the acceptable values of the test results, as illustrated in Table <NUM> below.

Referring back to <FIG>, "U" is the electrical component (of the UUT) under scrutiny for repair or replacement. The learning mode creates a historical data of solutions that can be mined later by computing success rate of success replacing components given a combination of failures. Any test exercises multiple replaceable components. For example component U is exercised by tests values V1 though Vn, and each test has a different probability of exposing or eliminating component U. As a result, every test has an associated weight Wn.

In some embodiments of the learning mode, the test station stores the weight each test allocates to each replaceable component, based on historical data, for example, after one hundred UUTs have been tested. In the case of the above example, if <NUM>% of the time, failed test <NUM> was fixed by replacing the component U3, then the weight W<NUM> will have a <NUM> value. Likewise, if <NUM>% of the time failed test <NUM> was fixed by replacing component U2, the weight W<NUM> will have a <NUM> value. However, if test <NUM> failed and <NUM>% of the time it was fixed by replacing component U5, then weight W<NUM> could have a "- <NUM>" value and weight W<NUM> could have a value of <NUM> to eliminate U3 in favor of U5.

The OS <NUM> runs the robotic application <NUM> to control the robotic arms and then displays the data collected by the oscilloscope <NUM>. The OS also interacts with the AI application <NUM> to train it. As described above, the AI application <NUM> has a learning mode and a troubleshooting assistance mode. During learning, the artificial intelligence application fills the database of X, Y coordinates (e.g., <NUM>) with acceptable values Vn. During the troubleshooting assistance mode, the robotic arms probe X, Y coordinates autonomously based on the data in the (X, Y) database and the AI application compares results with expected values stored in the KDB <NUM> and presents the results, as solutions to proceed with repair or replacement of a particular component in the UUT.

The AI application <NUM> then performs Σ (Vn * Wn ), by the neuro circuit <NUM> in <FIG>, to sort candidates for replacement.

For example, for a UUT with ten tests, the test vector is (V<NUM> , V<NUM> , V<NUM> , V<NUM> , V<NUM> , V<NUM> , V<NUM> , V<NUM> , V<NUM> , V<NUM>). However, if the test vector is (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) indicating failure on test <NUM>, <NUM> and <NUM>, the following will take place if the unit under test is made of five potential replaceable (or repairable) units labeled U1, U2, U3, U4, and U5. <MAT> <MAT> <MAT> <MAT> <MAT> <MAT> <MAT> <MAT>.

Let's assume the weighs, as calculated during the training stage, are:
W12 = <NUM>, W15 = <NUM>, W17 = <NUM>, W22 = <NUM>, W25 = <NUM>, W27 = <NUM>, W32 = <NUM>, W35 =
<NUM>, W37 = <NUM>, W42 = <NUM>, W45 = <NUM>, W47 = <NUM>, W52 = <NUM>, W55 = <NUM>, W57 = <NUM>,.

The solution for U1 though U5 will then be <MAT> <MAT> <MAT> <MAT> <MAT>.

If the solution for U3 is greater than <NUM>, U3 is recommended as the candidate component for replacement or repair. If the test vector was (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>)
and the weight W<NUM> = -<NUM>, W<NUM> = -<NUM>, W<NUM> = -<NUM>, W<NUM> = -<NUM>, W<NUM> = <NUM> then: <MAT> <MAT> <MAT> <MAT> <MAT>.

But, if the solution for U5 is greater than <NUM>, U5 is recommended as the candidate component for replacement or repair instead of U3. In some embodiments, when Σ (Vn * Wn ) > <NUM>, component "yn" is a candidate for replacement or repair. The weight allocated to every test may be the probability of successful rework based on the historical data collected during the learning period, as explained above.

Claim 1:
A system (<NUM>) for autonomous trouble shooting of a circuit card assembly having a plurality of replaceable components comprising:
a test station (<NUM>) including:
a test probe (<NUM>) to test the circuit card assembly as a unit under test (UUT) (<NUM>), and
a first computer (<NUM>) having a display,
memory coupled to the computer to store an artificial intelligence (AI) program (<NUM>) and a knowledge database (KDB) (<NUM>), wherein the KDB includes a plurality of indexes, each index corresponding to associated test points of the UUT, and respective acceptable test results for each test point represented by an acceptable test vector, and
a network interface (<NUM>) to communicate with a communication network (<NUM>); and
an operator station (<NUM>) including a second computer (<NUM>) and memory to send commands to the test station via the communication network to teach the AI program to capture and store the acceptable test result for each test point of the UUT by the test probe, in the KDB, wherein
the AI program when executed by the first computer commands the test probe to test the UUT, stores the results in a test result vector, compares the test result vector with the stored acceptable test vector, and displays recommendation as which replaceable component in the UUT to be repaired or replaced.