Minutes of Weekly Meeting, 2012-12-17

Meeting called to order: 11:06 AM EST

1. Roll Call

Ian McIntosh
Brian Erickson
Harrison Miles
Patrick Au
Carl Walker
Peter Horwood
Heiko Ehrenberg (joined 11:11)
Eric Cormack (joined 11:15)

Excused:
Adam Ley
Brad Van Treuren

2. Review and approve previous minutes:

12/10/2012 minutes:

  • Two corrections noted in the draft:
    • Adam should have been recorded as an excused absence.
    • The note in 4 referring to Brad joining should be removed.
  • Brian moved to approve with the above amendments, seconded by Carl. No objections or abstentions.

3. Review old action items

  • 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)
  • Harrison will attempt to come up with a table of use cases and their associated layer and what can be done at that layer. Ongoing.
  • Ian - Provide the slides used today and a link to the original PDF source. COMPLETE

4. Reminders

  • Consider Adam's three points (from the action from the first weekly meeting) and suggest what is preventing us from answering those questions:
    • Establish consensus on goals and constraints
    • What are we trying to achieve?
    • What restrictions are we faced with?
  • Forum thread for discussion: http://forums.sjtag.org/viewtopic.php?f=3&t=172

5. Discussion Topics

  1. Consider 'layers' and dependencies as they relate to Harrison's table and Brad's cube model.
    • Ian summarized the 5 tables that had been identified at the previous meeting, noting that the first of those, hierarchy of dependencies, had been started by Harrison for the Structural Test Use Case. Harrison had also supplied a table, circulated with the draft notes, of lifecycles against various product classes, in respect of Table 5. Ian felt this probably wasn't expressing the same 'lifecycle' that Brad had referred to when suggesting the table, so Harrison had supplied an alternate chart. Unfortunately Ian did not have that available, but had a similar one from Selex that could be used for discussion.
    • {Lifecycle chart shared}
    • {Eric joined}
    • This showed nine main stages running from pre-bid/concept (Stage 0) through to 'Disposal' (Stage 8). The earliest stages clearly had no associated test activity and Ian suggested that it was the stages from 'Integration' onwards that concerned SJTAG. Firstly, Harrison agreed that this chart was similar to his but argued that there was usually a need for test during development of the design, perhaps for component selection, and at this point there may be a need to check the integrity of the board. By the time of integration the board will require more of a functional test. Ian agreed but explained that in his chart 'Design' was probably more concerned with the processes prior to there being a physical asset to test.
    • Ian wondered if the early developmental tests were really something that should concern SJTAG. Harrison then commented on the linkage to primitive level testing, noting that if SJTAG is only concerned with test after integration then it probably needs to live without knowledge of the test vectors. Ian described that it was typical in his business not to invest in boundary scan tests during early development and instead wait until the designs had largely stabilized. That meant that in most cases at least one 'working' system would exist and boundary scan was usually targeted at supporting 'series production'. Harrison accepted that for some industry sectors and drew a comparison with the production of server blades.
    • Ian felt that one of the issues for SJTAG, and that existed at least for parts of the Telecom sector was the possible incorporation of third party boards into a system by the end user, and the subsequent need to diagnose faults if they occurred.
    • Harrison felt that it would be useful to consider these discussions against the table of industry sectors he originally supplied for 'Lifecycle'.
    • {Table shared}
    • This originated from an activity on counterfeiting. The industry categories are those used by iNEMI and do not always correspond to those used by the industry analysts although there are some equivalences. The 'Desired Product Life-cycle' column is the expectation either from the customer or from the businesses' own experience. Ian commented that in some cases, such as Aerospace, Automotive and Telecom there is probably an expressed requirement for the serviceable life of the product but that at the consumer end it may be more of judgement of what the marketplace will tolerate. Harrison thought it was more competition driven, and there may be benefits in testing as the products may be using more leading edge devices that may also be in short supply. The opposite case might exist in the example Ian mentioned where the desire is to use the same devices over a long period. Ian added an additional note that in his sector it was common for the product to go through 'mid-life updates' or 'obsolescence removal' yet the original deployed test equipment might be expected to remain in service through the full product service life.
    • Harrison remarked that certain forms of testing may have value in certain phases and the tests that are useful in the factory may have less value once the product moves out of the factory when it adopts a higher level of functionality, so Uses Cases could map onto the lifecycle. Ian agreed but felt that it might depend on things like repair strategies, and gave an example of some part of a radar failing on an aircraft: BIT would probably suggest which LRU (box) to remove but offer no more detail. Swapping LRUs gets the aircraft in service but you then want to confirm the fault and determine which module to swap to get the LRU back in service. It's a case of wanting to diagnose to the next level down, not necessarily to component level. But Ian also noted that Brad has previously described a customer demand for detailed fault information as early as possible and from the system level, and Carl noted the likewise. Harrison noted that the 'Netcom' sector had large, pervasive systems - covering a large area with limited human resource to service it - so the scenario was quite likely.
    • Ian concluded that best way forward with this might be to merge Harrison's second lifecycle chart with Ian's and then create a cross-reference against the Use Cases. {ACTION}

6. Key Takeaway for today's meeting

None.

7. Schedule next meeting

Next Meeting:
January 7. Brian expects to miss.

January schedule:
14
21
28

8. Any other business

Rohit had circulated an email to WG chairs on the confidentiality of ballots and giving a reminder that all press releases must be approved by the Sponsor and issued only after the standard is released.

9. Review new action items

  • Ian: Merge Ian's and Harrison's lifecycle charts and prepare a cross-reference against Use Cases.

10. Adjourn

Eric moved to adjourn at 11:58 AM EST, seconded by Patrick.

Respectfully submitted,
Ian McIntosh