Minutes of Study Group Meeting, 2017-10-16

Meeting called to order: 11:05 AM EDT

The slide references relate to the pack used during this meeting, located here: http://files.sjtag.org/StudyGroup/SG_Meeting_9.pdf

1. Roll Call

Ian McIntosh (Leonardo MW Ltd.)
Brad Van Treuren (Nokia)
Eric Cormack (DFT Solutions Ltd.)
Terry Duepner (National Instruments)
Bill Eklow (Retired)
Brian Erickson (JTAG Technologies)
Peter Horwood (Firecron Ltd.)
Carl Walker (Cisco Systems)
Bill Huynh (Marvell Inc.)
Joel Irby (ARM)
Dilipan Jayachandran (SEL)
Naveen Srivastrava (Nvidia)
Roger Lin (Via CPU Platform Inc.)
Mukund Modi (NAVAIR Lakehurst)
Jon Stewart (Dell)
Russell Shannon (NAVAIR Lakehurst)
Louis Ungar (ATE Solutions)
Sivakumar Vijayakumar (Keysight) (joined 11:06)
Richard Pistor (Curtiss-Wright) (joined 11:09)

By email (non-attendees):

Heiko Ehrenberg (Goepel Electronics)
Ed Gong (Intel Corp.)

2. IEEE Patent Slides

  • {Slides 5-9}

3. Review and Approve Previous Minutes

  • {Slide 10}
  • October 9
    • Updated draft circulated 10/11/17
    • No further corrections noted.
    • Eric moved to approve, seconded by Terry, no objections or abstentions. Approved.

4. Review Open Action Items

  • {Slide 11}
  • No open actions.

5. Discussion Topics

a) Scope and Purpose

  • {Slide 12}
  • Ian proposed a couple of points on this slide that may be bounds for what SJTAG is (or isn't). These may be more related to Scope, but we might need to establish a rough framework of what we're trying to achieve.
  • Some emails through the past week to try to clarify what a system is:
    • A system has a synergistic mode and the feature of being separable into sub-systems.
    • {Shared slide 4 of "System Architecture and Partitioning" - http://files.sjtag.org/StudyGroup/MSE_Binder2.pdf}
    • Defining boundaries and/or interfaces is going to be important.
    • Many users only need to isolate a fault to the next level of replaceable item, but some customers may want more detailed fault analysis.
    • May not always want to fault find below a module or PCA level if the cost of a new item is lower than the cost to fault find and repair. However, it is important that you have a high level of confidence that you've indicted the correct item, especially if your policy is to discard faulty PCAs.
    • Talking about "access to data" and not necessarily about executing something on the component or board: An item could track some of its own activity and report "what I did last".
    • CBIT (Continuous BIT) types of activity can be powerful but require a degree of functionality to exist in the UUT. One of the advantages of the 1149.1 concept was that it was often still useful even if the board was "dead". 
    • You can have a "red light" that tells you the system has a fault, but then you'd want to validate that with observation of the data from the system.
    • It doesn't matter what the system is, you just need to have access to the interfaces of that system in order to extract data from it. That could be both "live" data and stored data.
    • In automotive, OBD-II diagnostic connector is used to isolate faults to a particular part of the system - this is nothing new. But within the OBD-II port, there may be several different protocols and interfaces used for different sub-systems: ISO, CAN, KWP2000, K-Bus, etc.
    • We may be overloading the term "interfaces". We may not be able to consider them all in the same way. There are application "interfaces" and then there are the underlying communications interfaces, such as 1687 that have no real understanding of the intent of the data - these are different kinds of interface.
    • OBD-II typically reports a self-diagnostic from the embedded systems - it's a high level interface and you don't get access to all the sensor data used for the diagnostic.
    • Is there way we can reconcile and make use of both high level interfaces (perhaps formatted messages that are relayed from a self-contained sub-system over SERDES/PCIe buses) and lower level (1149.1, SPI, I2C) interfaces?
    • What we need is to be able to reproduce what the leaf entity data is, to understand what bits of the information correspond to leaf entity bits, so we can do the diagnostics as if we were directly connected to the leaf.
    • Can we define something as a primary interface to a system, e.g. assume 1149.1 will be the primary interface? This was an initial viewpoint when the SJTAG initiative commenced but seems less viable now.
    • Testing on higher levels of assembly seems to be tied in with providing a necessary level of functionality. Testing can be done at lower levels (e.g. 1149.1 interconnect tests) but some parts of the design may need to be excluded because they're e.g. managing the system/board power. In a fault tolerant design you may be able to test those elements if the fault tolerance has been arranged specifically to allow that - designed in DFT.
    • A goal should surely be to provide for low level access into the system. 
  • Louis offered to draft up a definition of "system" from the emailed material, and possibly a definition of "system test" {ACTION}.

6. Today's Key Takeaways

  • {Slide 13}
  • None.

7. Glossary Terms from This Meeting

  • None.

8. Topic for next meeting

  • Scope, Purpose, Need (and title) - continued
    • Try to get through "Need".
    • Group may wish to continue the discussion via email or the forums in the interim (forums are preferred, as it helps maintain a record).

9. Schedule next meeting

  • October 23.
  • October 30 meeting will be affected by DST changes for European (all non-US?) participants.

10. Reminders

  • None.

11. Any Other Business

12. List New Action Items

  • [9.1] Louis will draft a proposed definition of "system" and will try to also propose a definition of "system test".

13. Adjourn

  • Terry moved to adjourn, seconded by Brian.
  • Meeting adjourned at 11:54 AM EDT

Respectfully submitted,
Ian McIntosh