ICT Software Control Guide
ICT Software Control Guide
REVISION HISTORY
Applicable Station :
Jose Pacheco / Francisco Duran / Ramon Rivera Andy Widodo Manuel Ruiz
Flex Guadalajara B10 team Flex Austin Texas
7
The main focus for define the steps to follow in the process ICT SW acceptance- Focus on the
Agilent ICT 30XX machines that operate on HP Ux operative systems.
The general steps listed below was defined as general recommendation process in Flextronics,
for this reason some steps can not apply for all test process and additional steps could be
requested by specific customer.
The software acceptance applies for a new program coming from programming house or get an
used program from another CM, on both cases acceptance criteria must be fulfilled.
Fail Fail
Fail
Full Pass
BOM No
Coverage
Fixture or Release & Pass report as per
Program Create coverage
repair AutoFile expected as
BOM
Server Auto File 9
10
GR&R Study
11
Run Board Test Grader after you have completed and debugged your tests. Board Test Grader
uses one known-good board to run its grading routines. The utility relies upon statistical analysis
and multiple test executions to determine marginal tests.
Board Test Grader results are written to report files. Each test category creates its own report file.
A summary report file summarizes the results of all of the categories. You can use the reports to
keep a permanent record of your board test performance (for comparison with future tests, for
fixture and test maintenance). You also can use these reports as acceptance criteria for releasing
or accepting a board development project.
Test Types
Board Test Grader evaluates the following types of Agilent in-circuit tests:
Pins
Shorts
Preshorts
Analog in-circuit tests
Digital in-circuit tests
Analog functional tests
Limitations
Board Test Grader does not support tests with variables in Basic (common on mixed tests).
It does not support Agilent Polarity Check tests.
12
In Pushbutton Debug, select Test Grader Macros from the Macros menu to see the Board Test Grader
macros (Figure 1). They are:
Generate Test Coverage Report
Set Board Information
Create Grading Config
Create Grading Testplan
Grade Tests
1 Use Set Board Information to select which board
version or board on the panel to use during the Board
Test Grader process.
2 Select Create Grading Config to create a config.bdg
file.
3 Modify the config.bdg file according to your
requirements.
If you do not edit config.bdg, default values are used
and all tests and grading methods are run.
If you do not want a test type to run, you must set the
test type to False.
For example, if you want to test every test type except
digital quality test, change the following statement:
Digital_Incircuit_Quality_Test = True to the following:
Digital_Incircuit_Quality_Test = False When Board
Test Grader runs, it omits the digital quality test
commands in testplan.bdg. It also does not create a
report file associated with digital quality tests.
The config.bdg file contains comments to help you edit
it.
4 Select Create Grading Testplan to generate the
Board Test Grader testplan.
The testplan is created from your original testplan and Figure 1 Test Grader Macros in Pushbutton Debug
the config.bdg file. It contains the BT-BASIC commands 13
to grade your in-circuit and analog functional tests.
14
Data Files
The data files, listed in below Table 1, contain information from running the grader that will be provide to the Test engineers users the values of CP,
CPK mean std dev. From testplan.bdg. Most of the data files (with the exception of *_ver_fau.dat) use standard or customized logging
commands.
-------------------------------------------------------------------------------
AGILENT 3070 BOARD TEST GRADER Wed Jun 06 10:59:19 2012 page 1 Date & Time
Analog Incircuit Quality REPORT
-------------------------------------------------------------------------------
Board Path: ./
Ref Board Serial #: Board1
Date of Data generation: Wed Jun 6 10:56:28 2012
Designator
Number of test runs (in config.bdg): 10
Number of tests: 110
Report Flags:
F = Test failed
M = Mean not centered 66.67%
C = Coefficient of producibility too small 10.00
Data:
Designator ---Programmed---- --------Computed--------- # Flg Com
Nom Low High Mean StdDev CPK CP Bad Ref CPK,CP, StdDev
c117 200n 170n 230n 202n 11.8p 783 845 0 ...
c130 1.60u 1.04u 2.16u 1.76u 8.73n 15.3 21.4 0 ...
c131 6.20u 4.65u 7.75u 5.90u 8.86n 47.1 58.3 0 ...
c133 47.2u 33.0u 61.4u 43.1u 8.97n 375 526 0 ...
c138 35.1u 24.6u 45.6u 35.9u 39.6n 81.7 88.6 0 ...
16
17
18
19
20
21
22
23
The Generate Test Coverage Report macro performs the following actions:
1 Creates a new testplan called testplan.cov.
The existing testplan file is copied to the file testplan.cov, then is modified to allow testplan.cov to run the tests that measure
test coverage accuracy. The modifications:
Run all of the device tests (except pins and shorts) without ever applying vacuum or power to the board.
Prevent testplan.cov from exiting early due to any test failing.
The changes made differ slightly for a panelized vs. standard board.
Every line in testplan.cov that is altered is marked with the comment ! COVERAGE.
2 Executes the testplan.cov file while reporting all failures to the testcoverage_fail.dat file.
For panelized boards, you must specify (via the standard operator interface) which board or boards should be considered in
the coverage report. Any number of boards is acceptable by the test coverage tool. However, if more than one board is
selected, all devices on these boards are reported within the same report; they are not separated by individual board
numbers. Therefore, we recommend you select a single board for a report, then repeat the process for as many other boards
as desired.
If an error (or break) occurs, the testplan.cov file detects this and prevents a new report from being completed. An error
message reminds you that you cannot simply edit testplan.cov that is in the BT-BASIC window. Instead, you must edit the
testplan file. (See Running Test Coverage on a Custom Testplan.)
25
26
27
Define the Autofile number that be unique for each released mass production fixture, by default the fixture vendor follow
the fixture files specifications and the board file define this number. Each Administrator should update the number if needed
On the wiring in-side of the fixture on the control card section ( On the highest control of the fixture ) .
66 AF0/ Autofile 0
67 AF1/ Autofile 1
68 AF2/ Autofile 2
69 AF3/ Autofile 3
70 AF4/ Autofile 4
71 AF5/ Autofile 5
72 AF6/ Autofile 6
73 AF7/ Autofile 7
74 AF8/ Autofile 8
75 AF9/ Autofile 9
76 AF10/ Autofile 10
77 AF11/ Autofile 11
78 GND Autofile Ground
28
FIXTURE IDENTIFICATION
The autofile function returns the value of the current autofile code.
The autofile function identifies the fixture currently on the testhead by reading the autofile code wired into the fixture. The
autofile function points to the corresponding board directory so that the proper files can be automatically loaded. The valid
range of autofile codes is 11 to 4094.
Specifies a numeric code to automatically identify the fixture that is loaded on the testhead. This can be a number from 11 to
4094. If no autofile is specified, the fixture generation software automatically assigns the first available value starting at 4094
and decreasing to 11. The fixture generation software uses this value to add the necessary wiring to the fixture. The fixture
generation software also creates a corresponding file under $AGILENT3070_ROOT/autofile/<autofile value>. This file
contains the name of the board and the absolute path to the board directory. For example:
ps_board $AGILENT3070_ROOT/boards/ps_board For multiple-board fixtures, you need to edit the autofile file to include
a listing for each board on the fixture. For example:
board_1 $AGILENT3070_ROOT/boards/board_1 board_2 $AGILENT3070_ROOT/boards/board_1 board_3
$AGILENT3070_ROOT/boards/board_1 Note that QuickPress uses two transfer probes to change the Autofile number
only when the top plate is engaged. This allows the software to determine when to proceed with the board test.
------------------------------------------------------------------------------
3070 FIXTURE TOOLING REPORT Wed Nov 2, 1988 07:59:06 PM PAGE 2 /boards/sample/fixture/summary
------------------------------------------------------------------------------
Fixture Type : Cassette Fixture
Size : Bank2
Top Probes Allowed : ON
Autofile : 4094
Metric Units : OFF
WireWrapping : Manual
-------------------------------------------------------------------------------
29
Start
Deos
change is a Mayor
It is
necessary minor or
to debug or mayor
change ICT change Change ICT
Software
Minor Software
A
Revision
Pass
Apply Software
changes
Debug the SW
Changes A
Backup and
update master
file
Update SW
control Log
Testplan and
log Consider to be running using:
• Software backup process
End • Adequate permission by password control
30
Prerequisites
• Experience administering UNIX systems.
• Administrator log on privileges.
31
33
34
Password protection is designed to keep the notes safe from outsiders who can
make changes in programs, that are not part of the plan, or some other part of the
team, resulting in failure of the same, for this reason must assigned different
passwords.
35
36
37
38
39
40
41
1. All the ICT’s have to be standardized in order to can used every ICT fixture in any ICT
machine, If this is not possible you can divided in 2 main groups
• Half's
• Full's
3. Fixture identification
Region/Country/site/project/Family/model
Example: Ams – mx – gdln – eqx – L5xxx – RFID
43
44
In order to use all the ICT fixture in any ICT that you have in your site you need to create a
Autofile , one per every existent ICT fixture
2. Once you have all the autofiles created into the server in the direction var/hp3070/autofile
compress and generate a general .tar file
3. Send all autofiles to every ICT. (using ftp)
4. Put the file .tar into var/hp3070/autofile
• and uncompress in all the ICT machine
5. When the general .tar file is already uncompress
• you can mounted in any ICT any ICT fixture and
• will get the test program automatically
45
- Type vi filename
- Inside type the server direction contains the test program for that fixture
47
Next Step:
• Develop a demon to automatically compare resident program on ICT and
compare vs Master program located into server, if differences are found
macro will overwrite using master program and notify to system
administrator that changes was detected and corrected.
48
49