PAR scope and direction

[Bradford Van Treuren]

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:

viewtopic.php?p=1158#p1158

[Bradford Van Treuren]

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]

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.

[Ian McIntosh]

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"?

[Joel Irby]

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.

[Bradford Van Treuren]

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-Tut ... lide18.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.

[Adam W Ley]

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?

[Adam W Ley]

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.

[Ian McIntosh]

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'.

... 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]

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.

[Heiko Ehrenberg]

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.

[Ian McIntosh]

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".

[Heiko Ehrenberg]

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]).

[LYUngar1]

I think there are two other "needs" that we should address:
Need "C" is the ability by the properly identified maintainer to overcome security restrictions that may disable use of test and diagnostic features.
Need "D" is some quantitative fault metrics that apply to systems. At a minimum, this should apply to fault detection, but may also need to be extended to metrics of diagnoses. These two, fault detection and diagnoses, are different enough that they need to be treated differently.

[Ian McIntosh]

I'm thinking that I made a mistake is using the word "Need" in describing Need 'A' and Need 'B'. "Need" can take on alternative usages which make its use here potentially confusing so maybe "Aim" would have been a better choice. It then becomes more readable if you want to say "To achieve Aim 'A' you will need X, Y and Z". It started out as trying to answer "what industry needs are we trying to fulfil?" so it seemed reasonable enough at the time, but it seems to have morphed a little since.

Need also implies something that is mandatory and within a standard we will probably have some things that are mandatory, some that are recommendations and some that are optional and we'll need to be clear about which are which - or at least the Working Group will.

I'm also strongly of the opinion that Aim 'A' and Aim 'B' will need to be addressed by two separate standard documents (i.e. two PARs). While it may be possible to roll them up together I don't see it being helpful to anyone: You have an 'A' that doesn't need to use 'B' and a 'B that doesn't need to deliver 'A', so you risk creating a standard that has two main elements that are both optional creating a case where someone can do neither but claim to conform to the standard.