The discussion forum for the SJTAG Initiative Group

PAR scope and direction

Discuss the generic proposals for SJTAG
User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 77
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: PAR scope and direction

Postby Bradford Van Treuren » Wed Aug 31, 2016 4:24 pm

In today's meeting we refined the PURPOSE further. Here is what we came up with as Slide 33 in the new stack:

PURPOSE: The purpose of this standard is to provide a means to seamlessly integrate component access topologies (that follow a Capture, Shift, Update Cycle), interface constraints, and other dependencies at the board and system level with a uniform description that focuses on topology and behavior (as opposed to physical structure). By modeling this topology at the board and system level, a common set of interfaces may be used by higher level tools defined to coordinate these access topologies (communication interfaces) providing and provide a means of routing data sets to particular destination registers in the correct time order.


We also added two bullet points for Seamless Access and one for Problem Domain. The new set of brainstorm items is:
  • Seamless Access
    • system, board, device meld into a uniform description (Abstraction of “Assembly”)
    • Behavioral aspects than structural
    • treat the interfaces (access links, data links) as "black boxes“
    • Standardize on the right-hand side following the CSU protocol.
    • Schedule, Order, Application of vectors
    • Provide a means for higher level tools to make use of
  • Problem Domain (what we are trying to do)
    • Inadequacy of existing standards
    • Aggregation of circuit boards (w/ varying protocols e.g., 1149.x, 1687, I2C, USB, SPI)
    • Trying to create a software abstraction to the existing hardware standards

Please review the latest revision and make your comments on the forum. Next time we want to begin looking at the bigger picture of the SCOPE, PURPOSE, and NEED. You may recall we moved the old PURPOSE to the NEED and we should review the NEED accordingly. You may view the latest version of the NEED here:

http://forums.sjtag.org/viewtopic.php?p=1158#p1158
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 77
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: PAR scope and direction

Postby Bradford Van Treuren » Wed Sep 07, 2016 4:20 pm

The revisions to the PURPOSE are listed below:

PURPOSE: The purpose of this standard is to provide a means to seamlessly integrate component access topologies (that follow a Capture, Shift, Update cycle), interface constraints, and other dependencies at the board and system level with a uniform description that focuses on topology and behavior (as opposed to physical structure). By modeling this topology at the board and system level, a set of familiar and yet interchangeable interfaces may be used by higher level tools to coordinate these access topologies and provide a means of routing data sets to particular destination registers in the correct time order.

The revised NEED section follows:
NEED: A standardized method is needed to coordinate component access topologies, interface constraints, and other dependencies at the board and system level in order to be able to effectively leverage the existing and future component level standards. Thus, a new supervisory standard is required to define the coordination and dependencies of instruments as well as configuration, management, and application of vector based testing at the board and system levels. For example, IEEE 1687 and IEEE 1149.1-2013 provide methods for describing each of the instrument interfaces on a per component basis, but fail to provide the contextual prerequisites for the dependence on each instrument configuration and/or aggregation of multiple instruments for the overall board and/or system maintenance operations. Further, many components only support non-JTAG interfaces (e.g., I2C or SPI) to their instrumentation registers. This standard will provide a means to utilize the pin level access provided by other standards.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 77
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: PAR scope and direction

Postby Bradford Van Treuren » Wed Sep 21, 2016 4:17 pm

Today we wrapped up the SCOPE, PURPOSE, and NEED statements with a minor change to PURPOSE and NEEDS. The finalized text for each is presented below.

SCOPE: This standard defines methods to allow, in conjunction with existing methods, for the coordination and control of device, board, and sub-system test interfaces to extend access to the system level. The standard does not replace or provide an alternative to existing test interface standards, but aims instead to leverage them by defining a description to better manage how they are used in the system.

PURPOSE: The purpose of this standard is to provide a means to seamlessly integrate component access topologies (that follow a Capture, Shift, Update cycle), interface constraints, and other dependencies at the board and system level by using a uniform description that focuses on topology and behavior (as opposed to physical structure). By modeling this topology at the board and system level, a set of familiar and yet interchangeable interfaces may be used by higher level tools to coordinate these access topologies and provide a means of routing data sets to particular destination registers in the correct time order.

NEED: A standardized method is needed to coordinate component access topologies, interface constraints, and other dependencies at the board and system level in order to be able to effectively leverage the existing and future component level standards. Thus, a new supervisory standard is required to define the coordination and dependencies of instruments as well as configuration, management, and application of vector based testing at the board and system levels. For example, IEEE 1687 and IEEE 1149.1-2013 provide methods for describing each of the instrument interfaces on a per component basis, but do not provide the contextual prerequisites for the dependence on each instrument configuration and/or aggregation of multiple instruments for the overall board and/or system maintenance operations. Further, many components only support non-JTAG interfaces (e.g., I2C or SPI) to their instrumentation registers. This standard will provide a means to utilize the pin level access provided by other standards.

The working slides from today may be found under my file manager directory as Final SPN Draft 20160921.pptx.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Ian McIntosh
SJTAG Chair
Posts: 354
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo MW Ltd, UK
Contact:

Re: PAR scope and direction

Postby Ian McIntosh » Wed Nov 08, 2017 9:20 pm

From some of the recent discussions, I'm sensing that there are probably two distinct areas of "need" being expressed. I'll try to describe what I think they are in that hope that it helps to solidify what we're doing as a study group in the remaining few weeks of the year.

Need 'A' is a requirement for a standardised scheme that permits a "health report" from a component part of an assembly (e.g. a board within a sub-system) to be passed to that higher level assembly, and for that assembly to then report its overall health, and so on up through the hierarchy. These health reports may be either Go/NoGo indications or may include diagnostics detail dependant upon the information available. Specific information provided at the lowest levels need not be "rippled through" to the highest levels as the intent at each level of assembly is only to allow fault isolation only to next lower level. This requires a degree of functional awareness (and BIT) at each level in order that the health report for that level can be assembled from the responses of its component parts.

Need 'B' is a requirement to standardise a way to use disparate "instruments" (which may be parallel IO port registers, sensors, transmitters, receivers, etc.) in concert in order to conduct a test, where there may be a variety of physical interfaces to those instruments, and most typically where the test stimulus and measurement are not in the same device. For example, where a transmitter on PCB1 needs to be looped back to a receiver on PCB2. This is considering lower level behaviour and need not reflect the intended function of the parts involved.

Need 'A' and Need 'B' may overlap but they are not homogeneous. Assemblies trying to meet Need 'A' might exploit Need 'B' but it would not be mandatory to do so. Similarly, Need 'B' could be met without any reliance on Need 'A'.

Does any of this make sense? Am I incorrect in my perception of these two "needs"?
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

User avatar
Joel Irby
SJTAG Member
Posts: 2
Joined: Mon Sep 18, 2017 4:12 pm

Re: PAR scope and direction

Postby Joel Irby » Wed Nov 08, 2017 9:44 pm

It does make sense, Ian, and I think articulating the needs separately adds clarity.

Under Need "B" if we add "actuators" to the list of instruments, then perhaps it will be more obvious that robotic systems are included in the scope. We can also add "antennas" so the reader will be encouraged to consider that communication channels in the system can be wired, wireless, or both, depending on the system topology.

User avatar
Bradford Van Treuren
SJTAG Chair Emeritus
Posts: 77
Joined: Fri Nov 16, 2007 2:06 pm
Location: NOKIA / USA

Re: PAR scope and direction

Postby Bradford Van Treuren » Wed Nov 08, 2017 9:57 pm

Ian, I think you are spot on with your assessment. They are related, but not dependent on each other.

For Need A in the embedded environment is typically implemented as a series of agents running on the next lower level entity that is responsible for performing the operations requested by the upper level. For embedded BSCAN, the operation calls and returned behavior needs to mimic those found with functional tests, in order for the assimilation of these structural tests into the existing test framework of a system. A slide from an ITC 2006 tutorial Ben and I gave on the subject of SJTAG depicts this a little better. It can be found at:
http://files.sjtag.org/Brad/ITC2006-Tutorial-8-Part-4-Slide18.pdf

The diagnostic agents (DA) are responsible for supplying the diagnostic manager (DM) with the behavior required based on the System Test Architecture designed in the product. These are software message interfaces that provide the data in specific formats as specified by the architecture. The implementation of how the task is performed is through the Diagnostic "Plug-ins" for each behavior required.

My perspective of Need B is one of needing to support not only the run-time code, but also to provide support for the data generation stages (e.g., the retargetter) as these ECAD tools understand the problem from the instrument level. Need B is trying to apply instrument scoped test fragments as part of a larger assembled test that has to be controlled at a higher level of board topology that may (and usually is) a different interface test bus from what the instrument is directly connected to. Therefore, transformation of the data required at the leaf or obtained from the leaf has to be performed as it passes through each level of the topographic hierarchy. Need B requires the understanding of how the specific bits at the leaves map to the data found at the top of the hierarchy in order to be able to reassemble the content of the leaves for diagnostic purposes. Need B is dealing with the hand off Jeff Rearick was describing the P1687.1 team is looking to SJTAG to help resolve.
Bradford Van Treuren
Distinguished Member of Technical Staff
NOKIA MN

User avatar
Adam W Ley
SJTAG Established Member
Posts: 21
Joined: Mon Nov 12, 2007 1:35 pm
Location: ASSET InterTech, Inc./ USA
Contact:

Re: PAR scope and direction

Postby Adam W Ley » Thu Nov 09, 2017 8:21 pm

This makes sense to me, too, but begs the question as to whether each of these should be articulated distinctly in the Need statement of disparate PARs?

Or, even if we consider these as inextricably bound to a single omnibus Need, perhaps they still drive to different Purpose and Scope in disparate PARs?

User avatar
Adam W Ley
SJTAG Established Member
Posts: 21
Joined: Mon Nov 12, 2007 1:35 pm
Location: ASSET InterTech, Inc./ USA
Contact:

Re: PAR scope and direction

Postby Adam W Ley » Thu Nov 09, 2017 8:31 pm

I'd like also to specifically address the matter of diagnostic information as it pertains to "Need A". Per our discussion and demonstration in the past, one of the needs we have sought to address is that tools used for test development may have access to more structural information than is available to the system test runtime environment. As such, we have proposed that there would be a way to export the test fail data from the system test runtime environment toward the tools used for test development so that structurally relevant diagnostic analysis can be done there.

User avatar
Ian McIntosh
SJTAG Chair
Posts: 354
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo MW Ltd, UK
Contact:

Re: PAR scope and direction

Postby Ian McIntosh » Fri Nov 10, 2017 9:36 pm

Adam W Ley wrote:This makes sense to me, too, but begs the question as to whether each of these should be articulated distinctly in the Need statement of disparate PARs?
I agree that this a crucial question to answer. My initial sense of it is that these two needs could stand independent of one another, but with the option for 'A' to lean on 'B'. I'm not so sure that 'B' gains any value from 'A'.

Adam W Ley wrote:... one of the needs we have sought to address is that tools used for test development may have access to more structural information than is available to the system test runtime environment. As such, we have proposed that there would be a way to export the test fail data from the system test runtime environment toward the tools used for test development so that structurally relevant diagnostic analysis can be done there.
OK, so this is Need 'A' but perhaps with a qualification (or clarification?) that the "diagnostics detail" passed up is the raw, failing test result data from the lowest level, rather than an interpreted diagnostic.
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

User avatar
Ian McIntosh
SJTAG Chair
Posts: 354
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo MW Ltd, UK
Contact:

Re: PAR scope and direction

Postby Ian McIntosh » Mon Nov 20, 2017 4:37 pm

Starter on Purpose, proposed by Louis:
To facilitate test and/or diagnostics of systems made up of lower level sub-systems.

The object is to try to encompass both Need 'A' and Need 'B' in a single statement. Please try to expand/refine from here.
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

User avatar
Heiko Ehrenberg
SJTAG Vice Chair
Posts: 37
Joined: Wed Nov 21, 2007 3:15 pm
Location: GOEPEL Electronics - Austin, TX
Contact:

Re: PAR scope and direction

Postby Heiko Ehrenberg » Mon Nov 20, 2017 9:35 pm

So, are we now considering to mention specific use cases in the Purpose statement of the PAR for an initial SJTAG standard, referring to "test and diagnostics"?

A previous draft "purpose" didn't mention specific use cases:
The purpose of this standard is to provide a means to seamlessly integrate component access topologies (that follow a Capture, Shift, Update cycle), interface constraints, and other dependencies at the board and system level by using a uniform description that focuses on topology and behavior (as opposed to physical structure). By modeling this topology at the board and system level, a set of familiar and yet interchangeable interfaces may be used by higher level tools to coordinate these access topologies and provide a means of routing data sets to particular destination registers in the correct time order.
- Heiko

User avatar
Ian McIntosh
SJTAG Chair
Posts: 354
Joined: Mon Nov 05, 2007 11:49 pm
Location: Leonardo MW Ltd, UK
Contact:

Re: PAR scope and direction

Postby Ian McIntosh » Tue Nov 21, 2017 11:00 am

Heiko Ehrenberg wrote:So, are we now considering to mention specific use cases in the Purpose statement of the PAR for an initial SJTAG standard, referring to "test and diagnostics"?
I'm not sure - we certainly avoided it intentionally before: Uses cases have relevance to Need 'A' (I propose "Health Reporting" as a recognisable label for this) but less so to Need 'B' ("Instrument Cooperation"?) which is essentially agnostic to the use case.

I'm still uncomfortable about the notion of a single standard to address both needs. While it may be possible, I can't shake off the feeling that it's not desirable: We spoke yesterday about Health Reporting possibly being permitted rather than required. But does that help the NAVAIR guys who've said more than once that they want something they can point to as a requirement? If you try to make both needs mandatory then I think you'll get push back from people who feel "I'd like to use X, but Y is extra effort I don't need, so I'll use neither".
Ian McIntosh
Testability Lead
Leonardo MW Ltd.

User avatar
Heiko Ehrenberg
SJTAG Vice Chair
Posts: 37
Joined: Wed Nov 21, 2007 3:15 pm
Location: GOEPEL Electronics - Austin, TX
Contact:

Re: PAR scope and direction

Postby Heiko Ehrenberg » Wed Nov 22, 2017 9:18 pm

In that case I'd think "Need B" would need to be supported by a standard first, and then additional standards / extensions can be developed for various use cases (such as "Health Reporting").
Then, perhaps, the "original" purpose statement could be taken as is / tweaked as needed to fit "Need B" and for a PAR for the initial SJTAG standard. (The next question then would be if we want the Scope could be kept wide enough to cover Needs A [use cases] and B [coordination/management]).
- Heiko


Return to “SJTAG General Discussions”

Who is online

Users browsing this forum: No registered users and 1 guest