Introduction to AME
AME (Automated Manufacturing Engine) is a stand-alone console application which will run DMM test sequence files in an unattended batch-mode manufacturing environment.
AME is driven by a text file which specifies:
1. where the AME .log files should be created
2. What test sequence to run based on qualifiers of
-VENDOR, PRODUCT, HBA, or DEFAULT
3. Which HBA(s) and Drive(s) to run the tests on.
Step 1 – Create your Test Sequence files
Using the STB Suite Disk Manufacturing Module (DMM) GUI application you create any test sequence you want. In our example we will create two test sequences.
One, to do a DoD-5220 purge on SATA drives, and another to do the same thing on SAS/SCSI/FC drives.
Using DMM allows you to test, modify, tweak, perfect, and finally save your test sequence.
Step 2 – Run AME
AME is a GUI-less console application. It can be run from a command window or from another program, perhaps as part of a larger manufacturing process.
AME is called with a few command-line arguments – here is a screenshot of our example:
The AME Configuration File
First is the AME configuration file name/location. This is a simple text file which directs AME regarding which test sequence to run on which drives.
Here is the contents of our example AMEPurge.txt
PATHTOLOGFILE:c:\AMELogfiles
DEVSEQ:VENDOR=Seagate,SEQ=1-Dod5220-SCSI-SAS-FC.seq
DEVSEQ:VENDOR=ATA,SEQ=1-Dod5220-SATA.seq
This simply tells AME that we want our .log files to be put into a folder named “AMELogFiles”, and it uses the DEVSEQ term to select which drives will have which test sequence run.
We know that SATA drives on our test system always have a PRODUCT of “ATA”.
We want to run the SATA-specify DoD purge sequence only on SATA drives, so line 3 tells AME “if the drive PRODUCT is “ATA” then run the SATA purge”
We also know that we have a (any) number of Seagate SAS drives also connected to the same HBA, and so line 2 tells AME “If a drive PRODUCT is “SEAGATE” then run the SAS disk purge.
Note: this example doesn’t have one, but you can specify a DEVSEQ of “DEFAULT”. This would run whatever test sequence you want on any drives that don’t match the preceding DEVSEQs.
Specifying Drives to test
The second part of the command-line arguments tells AME what drives to test.
In our example we specified “HBA=0”
This means that AME will look at all drives on HBA 0, and all drives which match a DEVSEQ spec will be tested.
You can specify multiple HBA’s, and you can also specify explicit drive specs, such as HBA 1, drive 254.
In our example AME will test all drives on HBA 0.
While AME runs
There is a window available which will show information about the process –
This shows information about the test sequences being used and also shows which drives qualified for test.
Another use for this window is for an operator to watch for test completion.
Since AME is GUI-less the only indication you will have of completion is the above window closing, and all associated .log files being closed.
AME .log files
AME will create a unique plain-text .log file for each drive under test, placed in the folder specified in the AME configuration file.
In addition AME will create an Access database file, logging all device, test, and results information. And AME will also create a comma-delimited .csv file with the same information contained in the Access file.
Conclusion
AME – allows unattended testing of multiple drives at once.
AME – can only run DMM test sequence files – it cannot be used to edit or modify test sequences. This prevents any accidental or malicious changes being made to your test sequences.
AME – can run tests on multiple HBA’s with multiple drives connected.
These drives can be mixed type (SCSI, SATA, FC, SAS), and as our example shows AME can run one test on one drive or set of drives while simultaneously running other tests on other drives.
Like DMM, AME is fully threaded and multiple CPU aware. Each drive can proceed at its maximum speed – faster drives will not be throttled back by slower drives.
AME – creates the same .log files as DMM.
The STB Suite DMM test development environment allows rapid development of the most complicated test sequences you could imagine.
AME – allows these test sequences to be run unattended, uninterruptable, unchangeable, simultaneously, on many, many drives.