Minutes of Weekly Meeting, 2012-09-10

Meeting called to order: 11:08 AM EDT

1. Roll Call

Carl Walker
Harrison Miles
Ian McIntosh
Peter Horwood (left 11:50)
Eric Cormack
Heiko Ehrenberg (joined 11:09, left 11:47)
Adam Ley (left 12:01)
Brad Van Treuren (joined 11:10)
Tim Pender (joined 11:10)

Excused:
Brian Erickson
Patrick Au

2. Review and approve previous minutes:

08/20/2012 minutes:

  • Updated draft circulated on 09/10/2012. Ian had erroneously re-sent the original notes instead of the updated ones on 08/21, and had circulated the corrected version just prior to the meeting. The corrections were the four typos noted in Tim's email.
  • No further corrections noted.
  • Eric moved to approve with the above noted amendments, seconded by Carl. No objections or abstentions.

3. Review old action items

  • Adam proposed we cover the following at the next meeting:
    • Establish consensus on goals and constraints
    • What are we trying to achieve?
    • What restrictions are we faced with?
  • All: do we feel SJTAG is requiring a new test language to obtain the information needed for diagnostics or is STAPL/SVF sufficient? see also Gunnar's presentation, in particular the new information he'd be looking for in a test language
    (http://files.sjtag.org/Ericsson-Nov2006/STAPL-Ideas.pdf)
  • Ian: Contact Bill Eklow regarding use of the ITC mailer to promote an SJTAG Fringe Meeting at ITC. - Ongoing
  • Ian: Make provisional reservation of meeting room/time slot for SJTAG Fringe Meeting at ITC. - COMPLETE

Ian had earlier emailed the group regarding the Fringe Meeting booking: A slot has been reserved 10-12 AM PST on Thursday, November 8. Bill Eklow had been approached regarding the lack of visibility or promotion of Fringe Meetings and he agreed that they were often poorly attended. He would speak to the marketing people and see what could be done. There was a mailshot due at the beginning of October just prior to advance registration closing.

4. Discussion Topics

  1. ITC 2012: Expected attendance and SJTAG Fringe Meeting
    • Largely covered in discussion of actions.
    • Bill Eklow had asked if SJTAG were presenting a poster and commented that he'd be sending an email to WG chairs shortly. Ian had replied that he was unlikely to attend but that as Heiko had indicated that he wasn't intending to run a 1581 poster this year and so could present the SJTAG poster. Ian wondered if Bill was still expecting a 1581 poster, but Heiko commented that nothing had changed since last year.
     
  2. Where and when are our Use Cases relevant?
    • At the previous meeting it was noted that we had identified our Use Cases but had not really considered where and when each might be applicable. Ian also felt that this might lead into some clarification of terminology; Ian felt that 'Manufacturing' could mean different things e.g. test after board assembly or test during system commissioning. Since Brad had raised the issue, Ian asked if he had any views on how to progress this. Brad drew comparison with object oriented software and considered that there were two approaches: Either define everything up front or by 'data mining' where you work through the Use Case and realize where it might be useful. Brad was leaning towards the latter.
    • Ian recalled that there was a Use Case diagram prepared for the SJTAG poster at ITC 2008, and wondered if that would be useful to use while reviewing the Use Cases. Brad agreed that it would be. Ian did not have the diagram locally but was able to find a copy in the SJTAG flyer on the website.
    • {Use Case diagram from flyer shared}
    • Ian briefly explained for those unfamiliar with Use Case diagrams that the bubbles represented the Use Cases while the 'stick men' were 'Actors' and the users of Use Cases. Ian noted that he needed to make this diagram readily available to the group [ACTION].
    • Brad observed that there may be a missing arrow from Hardware Design to Environmental Stress Test. Ian agreed that there may be omissions. Looking for the 'big hitter' Use Case, Brad proposed that Structural Test was the item that people would be most comfortable with.
    • {Wiki description of Structural Test (Volume 2) shared}
    • Ian quickly reviewed the content of the Use Case and remarked that the 'Application Fields' read like a simple scope and did not address where or when the Case was applicable.
    • Referring back to the diagram, this showed that Structural Test was used by Manufacturing, Hardware Design and Field Service. Brad suggested trying to better define each of these Actors: Manufacturing could break down into 'Post Assembly Test' (after board assembly) and 'Post Subsystem Assembly Test.'
    • Ian wondered if diagnosing factory returns were part of this or if those belonged to Repair Depot. Brad pointed out that there was probably a significant omission in the diagram in that it did not associate Structural Test with Repair Depot. In response to Ian's question, Brad thought that the Repair Depot depot could be colocated and the end user's facility or elsewhere; in fact as manufacturing may move all around the world it was likely that repair would be carried out somewhere other that where manufacture occurred. Carl agreed that repair could occur pretty much anywhere. Ian accepted this and noted the Actors represent 'roles' and not 'locations.'
    • Returning to the users of Structural Test Field Service could be broken down into 'Remote Diagnostics' and 'on-site diagnostics' where it is actually possible to pull boards. In both cases there is the possibility of either 'intrusive testing' or 'non-intrusive testing.'
    • {Heiko left}
    • Brad added that there was also the consideration of system states: 'Power off', 'Power on testing', 'off-line testing' or 'on-line testing.' Ian wondered how much of these states actually overlapped with the Power-On Self-Test and Built-in Self-Test cases; Brad considered that there was probably quite a bit of overlap between the bubbles and we may be exposing a deficiency in the Use Case descriptions in considering locality. Ian felt that maybe Structural Test was a sub-Use Case of both POST and BIST and that the diagram should show a 'Uses' link from those two to Structural Test. {Peter left}
    • Harrison viewed Structural Test as not being at a very high level while BIST could be right up to the application level; a structural self-test is maybe the only true primitive. Brad thought this was an interesting way to look at this and we could consider that we have structural test vectors, fault injection vectors, configuration vectors, etc., so maybe we should be thinking about the kinds of actions we're performing at the primitive level as that's how we communicate with the UUT. For example in Programming and Updates we write to a memory of some sort, in Device Versioning we extract data about the UUT, in Configuration, Tuning and Instrumentation we write to another form of memory. Brad thought this may make it easier to add in the concepts that Adam had spoken of previously, the things not considered to be conventional test.
    • Ian noted that a lot of the bubbles were in reality 'applications' so for example Environmental Stress Test is possibly a specialization of Structural Test - a structural test within a wrapper.
    • {Adam left}
    • The conclusion from the discussion was that there was important to decompose the Use Cases to identify the primitive operations that we perform on the UUT with BScan.

5. Key Takeaway for today's meeting

  1. Use Cases are portraying multiple levels in one diagram - inconsistent.
  2. Important to identify primitive functionality of what we do with BScan (not just 'read data'/'write data').

6. Schedule next meeting

Next Meeting:
September 17.

7. Any other business

None.

8. Review new action items

  • Ian: Make Use Case diagram accessible on the website prior to next meeting.

9. Adjourn

Eric moved to adjourn at 12:06 PM EDT, seconded by Tim.

Respectfully submitted,
Ian McIntosh