Who - the examiner
What - testing across the interface
Where - between the DUT and the Test Tool
When - as directed by the laboratory Good Practice Guide (GPG)
Why - to avoid contamination of evidence
To aid that process the SOP could reference the procedure with the inclusion of the relevant standard numbering and title, also directing the reader to a specific clause. It is irrelevant for the purposes of testing to ask an examiner to remember something s/he was taught some time back. A permanent record in a document of direction and advice instructing the examiner is needed. Practices and procedures should not be left to guesswork. As the old adage states " it is not knowledge you need to hold-on to in your head as this is recorded in books; it is the skills and experiences you should remember." A permanent record, then, is a reference book. The skills and experiences developed through use and discovery are those essential requirements to maintain and evolve the SOP, which when recorded then goes on to become knowledge.
In Part ONE it referred to ISO/IEC 7816-1. That is because it is the starting point that identifies other 7618-parts. Here we need to look at ISO/IEC7816-3. The above image show the specific section to be discussed. But for the sake of manner and form let us use a page within the SOP identifying Standards and Text applicable to it (the SOP and its procedures and tests therein):
INTERNATIONAL STANDARD ISO/IEC 7816-3 Third edition 2006-11-01
Identification cards — Integrated circuit cards — Part 3: Cards with contacts — Electrical interface and transmission protocols
However a short form identity for the relevant Standard and clause/s are required. This is placed at the end of paragraph following the written procedure or test (otherwise any procedure and test would be verbosely overloaded with repetition of a Title like the above).
Short Form Identity:
Note that apart from going to a separate document (e.g. relevant Standard and clause) everything that an examiner should require should be in the SOP. The reasoning behind that has many responses but to highlight: (a) avoids an examiner reading wrong, incorrect or out of date material; (b) excessive amounts of information can confuse; (c) examiners will be testing, but prior to tests and following tests contemporaneous notes should be made which could be excessively lengthy if the SOP references are not used....and so on.
It can also be helpful to produce GUI screen images and samples of APDU so that the examiner is equally guided to know what to look for in any trace file output for validation purposes.
Dependent upon the (U)SIM/(U)ICC hardware reader and software (system) used it is important that the examiner does not end up using another system to perform the tests. If a different system is used a new SOP should be created for every system in use. If support is needed for that then an example can be given here. The above screen image shows the ADPU commands and responses in the USIM Detective trace file. However, Simspy2 trace file output is different:
This might suggest the commands and responses that are output should still be identical? No, not all commands and responses will be identical. Worse still, if the examiner starts quoting one system in a report and the data used is in fact from another system. An example of this is Simspy2 and USIM Detective both issue commands and responses that can acquire different data. Both issue commands to fetch data from memory locations that are not specified in the standards. This does not suggest they are wrong, merely they offer different traced evidence.
Unless each Lab produces its own system then the market forces of commercially or freely available systems will be the pool from which systems are obtained. The more tools the better, but budgets can dictate a system to be used, although in reality obtaining free software should not present a problem. Purchasing a commercial system, it should be possible to fully scrutinised data captured and that the system has the back-up evidence to produce a trace file output containing the commands and responses where validation is needed.
Validation requires confirmed interpretation of commands issued and as mention in previous discussion seeking guidance from the standards can save an awful lot of time and assists avoiding guesswork:
Lastly, but still relevant to Test A Damaged SIM Card SOP, it should be made clear in the SOP that the standard referred to identifies the "interface" as referenced in the standard. In this discussion ISO7816-3 confirms the "electrical interface" and the transmission protocols used. However, as (U)SIM cards emerge with additional capabilities in the (U)SIM or at the (U)ICC level it is important to record additional interfaces significant to the method and process evidence is captured:
Contaminating Evidence ONE - http://trewmte.blogspot.co.uk/2017/04/contaminating-evidence-one.html
Contaminating Evidence TWO - http://trewmte.blogspot.co.uk/2017/04/contaminating-evidence-two.html
Contaminating Evidence THREE - http://trewmte.blogspot.co.uk/2017/04/contaminating-evidence-three.html