Minutes of Study Group Meeting, 2018-01-08

Meeting called to order: 11:05 AM EST

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

1. Roll Call

Ian McIntosh (Leonardo MW Ltd.)
Heiko Ehrenberg (Goepel Electronics)
Eric Cormack (DFT Solutions Ltd.)
Terry Duepner (National Instruments)
Bill Eklow (Retired)(joined 11:32)
Brian Erickson (JTAG Technologies)
Peter Horwood (Firecron Ltd.)
Bill Huynh (Marvell Inc.)(joined 11:32)
Joel Irby (ARM)
Mukund Modi (NAVAIR Lakehurst)
Naveen Srivastava (Nvidia)
Jon Stewart (Dell)
Brad Van Treuren (Nokia)(joined 11:14)
Carl Walker (Cisco Systems)
Ed Gong (Intel Corp.)
Dilipan Jayachandran (Schweitzer Engineering Laboratories, Inc.) (joined 11:07)
Russell Shannon (NAVAIR Lakehurst)
Al Crouch (Amida Technology Solutions)

By email (non-attendees):

Richard Pistor (Curtiss-Wright)
Louis Ungar (ATE Solutions)
Sivakumar Vijayakumar (Keysight)

2. IEEE Patent Slides

  • {Slides 5-9}
  • Slides have been updated for 2018 and there have been revisions to the IEEE-SA Bylaws and Operations Manual (link in AOB).

3. Review and Approve Previous Minutes

  • {Slide 10}
  • December 18
    • Draft circulated 01/03/18
    • No further corrections noted.
    • Brian moved to approve, seconded by Eric, no objections or abstentions. Approved.

4. Review Open Action Items

  • {Slide 11}
  • [10.2] Brad will draft a definition for "boundary".
    • ONGOING.
  • [14.1] ALL: Develop Purpose description.
    • ONGOING.
  • [17.1] Louis: Search for any standards that address what constitutes a fault (or pass) at system level.
    • ONGOING.

5. Discussion Topics

a) Use Cases vs Methods - re-aligning our goals

  • {Slide12 - Methods, Use Cases, Applications}
  • Purpose of this slide is to highlight that these concepts are different from each other and probably cannot all be handled in the same way.
  • {Slide 13 - PHM and IEEE 1856}
  • Newly issued standard on Prognostics and Health Management. On the face of it, the scope looks like it addresses a lot of the things people are looking for, but the content is thin: It is only a framework and describes a process to providing a solution rather than an off-the-shelf solution itself.  It is possible that SJTAG could provide part of the solution within that framework.
  • {Slide 14 - Links and references}
  • These are provided as pointers into some of the work of the Reliability Society in case anyone wishes to follow up.
  • {Slide 15 - SJTAG Universe}
  • Diagram shows application areas identified for SJTAG some time ago. It is notable that the part of the bubble for purely Reliability applications is empty (there are entries in the cross-overs regions with other fields). This may be due to lack of representation in the group from people directly involved in that field. Prognostics and Health Management is absent.
  • {Slide 16 - SJTAG Use Cases}
  • The ten Use Cases identified by the SJTAG Initiative Group. Important to note that the "stick men" are not distinct people or groups, but are roles and an individual may take the perspective of multiple roles dependent upon what they're doing at any given time.
  • {Slide 17 - IEEE 1856 PHM Process}
  • This slide should be titled "PHM Process" rather than "PHM System". As an example of an application area, we can look at this to see how SJTAG could provide some support. At the very left hand side, we're looking at "hardware"; the actual sensors. From the middle and over to the right hand side is mainly in software. SJTAG likely fits best into the "Acquire" stage - the data acquisition (DA) and data manipulation (DM) blocks.
  • {Slide 18 - IEEE 1856 Block descriptions}
  • Included only to provide the description for each of the block on slide 17.

  • NAVAIR perspective is that they simply want more insight into the cause of failures and the indictment of boards to direct the next level maintenance activities. How that happens is not something that they wish to specify. In the 1856 model, that might be looking more at the "Analyze" phase.
  • Vectors from a JTAG chain probably wouldn't help, as you also need a description of what the JTAG chain is connected to in order to understand where the bits come from and what the anomalous bit(s) mean. It needs an aggregation of data.
  • It doesn't just need that definition, it requires that there is a mechanism to actually trigger the production of the data and then get at the data.
  • Architecture is key. Delegation to embedded BScan tests on individual FRUs can provide the required level of granularity in the diagnostics, but it is not necessary to return the vectors themselves, only the result (although there may be other cases where the vectors might be needed). These are test that are run at the board level and closely replicate (or try to) the tests that would be done during manufacture.
  • It'd be useful to know if the NAVAIR people have other Use Cases/Applications to add to the Venn Diagram.
  • Architecture and DFT is crucial: You can't ask for testability to be added after the design is complete; it needs to be planned into the system design and driven down into the modules/boards.
  • Embedded BScan needs to be incorporated into embedded software such that it looks like the equivalent functional tests. Noted that a functional test usually has some latency and some distance from the point of failure to the point of observation so there is some work to do to get to the location from the point where the fault is first observed.
  • The Data Acquisition (DA) and Data Manipulation (DM) blocks seem to be the scope that SJTAG needs to focus on as extensions to 1687, etc.  The Data Manipulation processes sensor data into something more recognisable.
  • A big security piece is missing. There are time when you've got to hide some of it and especially if it's product from a third party. Health Monitoring is being used for Trojan detection or identifying counterfeit parts.
  • You could protect IP by just reporting state. However you need finer granularity for design verification even if not needed for field tests.
  • Al had tried to get a group together on security but it ended up attracting only academics and no industry support. Part of the problem in trying to handle security is that there is no single solution for security, so it has a broad scope to deal with. There does however need to be some kind of guidelines, perhaps to require some form of challenge/response to unlock access or features. Such protocols might be implemented using standard interfaces.
  • Recent Intel processors have a process that requires the processor to be booted, then a challenge/response handshake before the JTAG is accessible, meaning that if the processor doesn't boot then there is no JTAG mechanism to debug the fault.
  • Security could be treated as another Use Case.
  • A big problem is where a chip might be bought with JTAG fused off. There needs to be some sort of acceptable way to lock things down that does not resort to permanently fusing off test/debug access.
  • Possibly this should be addressed as a separate standard (although see Al's problem attempting that, above). Any interface standard could be told that it needs to push security; SJTAG need not be any different.
  • Al has looked at security aspects extensively and particularly in the context of 1687 and methods of locking/unlocking portals to gain access to instruments. There may be other methods than 1687 portals, even using GPIO signals.
  • If we try to deal with security and all its aspects we be tied in that for ever, however there does need to be consideration of the effects and implications of security.
  • Guidelines exist in certain industries/sectors and security tends to be more defined in higher criticality sectors: Avionics, automotive (e.g. self-driving cars), medical, but there's nothing really for IoT (and that is pervasive).
  • Security might require an NDA or similar authority to gain access controls. Without security access, nothing gets done.
  • If JTAG gets fused off as part of delivering to a customer and then debugging returns becomes much harder and can't really do any diagnostics.
  • There are some patented methods that are reliant on variable length chains so only really became useful when 1687 and 1149.1-2013 came along to allow that. Also using encrypted descriptions that allow access to "hidden" instruments. This is all possible now and can be implemented through 1149.1 protocols.
  • DFT needs to be in the design, but 1687 faced the question of whether it should be "prescriptive" (as 1149.1 is) and define what was required or "descriptive" and react to what was already there and chose the latter. For broadest SJTAG adoption, we probably want to do the same. In the past, the notions of "SJTAG compliant" and "SJTAG compatible" had been mooted to describe different levels of conformance and which might be useful if we need to trade prescription against description.

6. Today's Key Takeaways

  • {Slide 19}
  • Security needs to be noted, although not necessarily implemented, as part of an SJTAG standard.
  • Security should be directed towards methods that permit authorised access rather than total lock-out.

7. Glossary Terms from This Meeting

  • None.
  • Carried over:
    • BIT - clarify in line with discussion from 2017-12-18 meeting.
    • BIST - distinct from BIT in that is a self-test that does not require any additional resources other than the tested item itself.

8. Topic for next meeting

  • Work on refinement of what SJTAG is and what is merely "notations".

9. Schedule next meeting

  • January 15, 2018.
    • Russell, Mukund, Carl, Naveen, Ed and possibly Eric will be absent.

10. Reminders

  • None.

11. Any Other Business

12. List New Action Items

  • None.

13. Adjourn

  • Terry moved to adjourn, seconded by Brad.
  • Meeting adjourned at 12:15 PM EST

Respectfully submitted,
Ian McIntosh