Minutes of Weekly Meeting, 2010-01-18

Meeting called to order at 10:41 AM EST

1. Roll Call

Eric Cormack
Ian McIntosh
Adam Ley
Heiko Ehrenberg
Michele Portolan
Brad Van Treuren
Tim Pender (joined 10:45)

Patrick Au
Carl Walker

2. Review and approve previous minutes:

01/11/2010 minutes:

  • Draft circulated on 11th January:
  • In Heiko's comment against Q2.2 'you' should be 'your'
  • Brad moved to approve, seconded by Eric; 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?
  • Establish whether TRST needs to be addressed as requirements in the ATCA specification if it is not going to be managed globally (All)
  • Adam review ATCA standard document for FRU's states
  • All to consider what data items are missing from Data Elements diagram
  • 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
  • Ian/Brad: Draft "straw man" Volume 4 for review - Ongoing
  • All: Review "Role of Languages" in White Paper Volume 4 - Ongoing
  • All: Review 'straw man' virtual systems and notes on forums:
    http://forums.sjtag.org/viewtopic.php?f=29&t=109. - Ongoing
  • All: Add to, or comment on, the bullet point list of architecture drivers. - Ongoing.
  • All: Provide forum comment on the graphics used during the meeting; suggest "building blocks" that may be used in future:
    http://forums.sjtag.org/viewtopic.php?f=29&p=257#p257 - Ongoing.
  • Ian: Ensure that Calling Notice includes correct meeting number and web link details - COMPLETE.
  • Ian: Email survey respondent for further expansion on comment on "consolidation of the release of the proposed IEEE standards" - COMPLETE.
  • Ian: Email survey non-respondents to offer final chance to participate - COMPLETE.
  • [Brad] I had problems following the link to the WebEx.
  • [Eric] I had to click the 'Join a Meeting' link then type in the meeting number. That worked OK.
  • [Ian] The link Carl sent out last week is different from the one I have in Outlook. I'll need to check with Carl as I thought the link I had might have been customized for me as an alternate meeting host. {ACTION}
  • [Ian] I sent and email requesting clarification of the comment we discussed last week, so I've completed my action, but I haven't received a reply yet.
  • [Ian] I also mailed those who hadn't completed a survey. That has raised three notes of interest, one of which has turned into a submission.

4. Discussion Topics

  1. 2009 Survey - Preliminary review of submissions
    • [Ian] I'd like to take a look at the comments we got on ROI.
    • [Tim] Which question is this?
    • [Ian] It's not one of the charted ones, it was just text responses: It's 8.6 'What do you feel you need to get your return on your investment?'
    • [Ian] First comment is "1 year max". I guess they mean that they need to see the ROI in that timescale for it to be viable for them.
    • [Ian] Second comment may be suggesting that SJTAG is costly at present.
    • [Brad] Or are trying to define what ROI involves or means to them.
    • [Ian] That could be closer to the mark.
    • [Eric] The third comment "simple and quick test" might mean that they don't want to overcomplicate things by adding JTAG.
    • [Ian] Fourth comment wants to avoid custom tooling, and get exports of data directly from CAD tools.
    • [Ian] In comment five there's some kind of reluctance being expressed; I'm not sure who needs to be convinced to use JTAG in the field here.
    • [Eric] I wouldn't think there'd be a reluctance
    • [Brad] Maybe need to convince people that it is a viable feature to put in the system, and not for manufacturing only. Or an issue of integration with the system diagnostic software.
    • [Tim] Could be the cost of providing a $5000 external JTAG controller to use in the field.
    • [Ian] I guess compared to using a laptop and an ethernet or USB cable that could be a factor.
    • [Brad] Which is why I'm pushing to embed as much as possible. It makes it easier if you just need to include the software.
    • [Ian] The sixth comment makes two points: Freedom in architecture and a standard way to supply the description to the tooling.
    • [Brad] Sounds like pie in the sky!
    • [Ian] Is it? I think we'd agree that SJTAG shouldn't constrain the system architecture too much, and we have tried a couple of times to see how we could describe the system to our tools.
    • [Ian] Comment seven seem to need a success story to convince management.
    • [Brad] Even with an example, or several examples, it can be difficult for some to understand what SJTAG is bringing to the table. Most people don't understand the bigger picture, maybe the way they used to.
    • [Ian] I feel that some of the organisational "tools" may contribute there. I see our policy of IPTs - Integrated Product Teams - mean that people get compartmentalized into their own product area. You don't get to see the bigger picture and don't get the cross-fertilization we used to have 15 years ago.
    • [Ian] In many ways, comment eight gets to heart of what I think is one of the big cases for SJTAG - System Diagnostics.
    • [Brad] It's worth noting that this is not the same as Built-in Test or BIST.
    • [Brad] Nine is bringing out service turnaround time.
    • [Ian] Yes. "Availability" is the key word on many support contracts now, rather getting into the detail of MTBF and MTTR. I think one the other related terms is Performance Based Logistics - PBL.
    • [Ian] Comment ten is closely related to nine.
    • [Brad] The key is ensuring you replace the proper broken part.
    • [Ian] I've seen cases where the diagnostic is vague or wrong and you can only hack around until you get a fix.
    • [Ian] In eleven, this is the use of remote diagnostics so you can send out the right spare to be on-site as the engineer arrives. This is the sort of thing you've mentioned before, Brad.
    • [Brad] It is indeed.
    • [Ian] In twelve, I can see the Use Case having an effect on the perceived ROI, but I'm not sure about the last part of the comment.
    • [Brad] The Use Case will largely determine the implementation. That implementation will cost more or it will cost less. If all I need to do is to update config memory, I could use a Bit Bang - it only needs some software, no hardware, but it'll be slow. So there's a tradeoff in cost against performance. What you implement is going to be directly driven by the Use Case.
    • [Ian] Thirteen seems to missing the point. Fewer field failures is more about general testability, fault coverage, escaping defects, I think.
    • [Ian] For fourteen, I guess "<10%" refers to the cost of SJTAG as a proportion of the product cost.
    • [Eric] That's all I can think it means.
    • [Ian] I think I understand fifteen. With the long service life of many of our products, we see support contracts as major source of profit, more so than original product sale. But you can only realize that potential if you can diagnose faults quickly and repair them quickly.
    • [Brad] Yes, uptime is the important factor. Not everyone realizes that the Time-to-Diagnose and the Time-to-Repair add together to give the total repair time.
    • [Ian] I've seen some mis-estimation on factory TE utilization where diagnosing failing product wasn't factored in to the total usage.
    • [Brad] Yes. A BScan test can help to filter out those parts that need to go onto the expensive diagnostic sites.
    • [Ian] We've pretty much used our time up today. Has anyone seen anything in the charts of particular interest that we could look at quickly?
    • [Brad] I noticed a conflict in the results of 3.7 versus 3.8. In both cases "A collection of CAD files" is the top answer.
    • [Ian] I see what you mean: We generally found that systems aren't really described in CAD, but in some other form of documentation. So I suspect that these are responses that haven't been fully thought through.
    • [Brad] That's what I'd think.
    • [Brad] The comments for 2.2 to 2.4 showed that this person had applied some thought and insight. I don't necessarily agree, but there has been thought go into the comments.
    • [Brad] In 3.4 the majority are using external control, but what surprised me was the number claiming to use a mixture of external and embedded.
    • [Ian] OK, well that may be something we can compare with the answers to section 9.
    • [Brad] Well, there are clearly some "high runners" there that we need to consider for our "dot 0" standard, the ones with all "Yes" or "Do" answers.
    • [Ian] Which is pretty much all of them!
    • [Brad] Well in 9.13, 20% is still a pretty large number that need to be convinced.
    • [Brad] 9.9 has a surprise. I wouldn't expect 10% to say they wouldn't consider JTAG for updates.
    • [Ian] No, to me that one is a "no brainer", it's almost fundamental.
    • [Tim] Maybe they prefer to use an alternative method, maybe they use the configuration port or similar.
    • [Brad] OK, but since the JTAG is there anyway, it can always be used as a secondary path.
    • [Ian] Yes, even if your primary update path is something else, JTAG can give you back door if it goes wrong. I've seen bootstrap loaders get missed out in an update so JTAG was the only way back in.
  2. Outline Schedule for Q1
    • {Not discussed due to lack of time}

5. Schedule next meeting

Schedule for January 2010:
Monday January 25, 2010, 10:30 AM EST

Schedule for February 2010:
Monday February 1, 2010, 10:30 AM EST
Monday February 8, 2010, 10:30 AM EST
Monday February 15, 2010, 10:30 AM EST
Monday February 22, 2010, 10:30 AM EST

6. Any other business


7. Review new action items

  • Ian: Confirm WebEx access link with Carl.

8. Adjourn

Brad moved to adjourn at 11:44 AM EST, seconded by Heiko.

Respectfully submitted,
Ian McIntosh