My need is...

[Ian McIntosh]

With reference to Need 'A' and Need 'B' (see viewtopic.php?p=1227#p1227), what do the group members think best fits their own particular expectations.

I'll leave the poll open for 15 days and I'll allow people to change their mind during that time .

[Joel Irby]

I'm hoping the rest of the group can help me think about a possible use-case in Automotive electronics. Hypothetically, let's say we're working at the Texas Department of Transportation and want to algorithmically discover the topology of a well-defined system -- for example, all vehicles currently traveling Interstate-35 between Austin and Dallas which can communicate wirelessly with our server, and then securely, in compliance with pre-defined authentication rights, test their compliance with established rules and the health of their components: Computer Vision, LIDAR/RADAR, etc.

Are needs 'A' and 'B' as currently phrased sufficient? (I'm already sure they're necessary.) Do we need to expand the definition of "system" to include such cases, in which the components are by definition always changing?

Now, what if we want to overlay other information, for example, all of the vehicles on the same stretch of roadway which aren't trackable by TxDOT? (Think older passenger cars, pickup trucks, tractors, bicycles, go-karts, etc.) We might have incomplete information about such vehicles, perhaps from satellite imagery or strategically-placed cameras alongside the road.

It's just a thought experiment, so feel free to poke holes in the scenario or point out aspects I've neglected to mention. Thanks in advance!

[Ian McIntosh]

I'm seeing this poll as not being a simple question...

I see the value in Need 'A' and would benefit from it, without doubt, but I also see it as a "hard sell": It'd be difficult to get board/module designers to take on the additional effort even when it's in-house and even more so to expect COTS item vendors to do it. It requires, I believe, implementation in both hardware and firmware/software to make it work, so it is potentially quite onerous. It's something that has "value" to the user but to the supplier it probably just looks like "cost". So there'd need to be a strong case made for why it's needed, and it needs to flow down from the top as a hard requirement (and most of our customer requirements would never go so far as to specify "how" testability is achieved - their requirement is "availability" (or readiness) - and I think that's probably correct).

Need 'B' seems primarily to be a task for test software tooling. There is an assumption that the test interfaces are available at the board edge (which is often the case anyway), so the additional task is to ensure that the interconnects between boards/modules (generally the backplane) makes those interfaces available up the hierarchy, something that may not always happen just now (and I know there can be push back on pin-count usage for non-operational functions such as test). But I see it as something I could use right away on (some) existing designs without any further work.

So I'd prioritise 'B' over 'A' (from my own personal perspective) as the former gives me a "quick win" while the latter is more of a "long game".

[Ian McIntosh]

I'm hoping the rest of the group can help me think about a possible use-case in Automotive electronics. ...
It's just a thought experiment, so feel free to poke holes in the scenario or point out aspects I've neglected to mention. Thanks in advance!

It's perhaps a little off-topic from the poll itself but...
The problem of how you deal with a dynamically changing system composition is something that the Initiative Group had thought about. Notwithstanding your specific example, you could consider that the composition of a rack deployed at a customer site may have its configuration changed from how it was (and tested) at the point of delivery, perhaps by having one or more modules added or existing modules replaced by upgraded parts, perhaps even from a third party. So the notion is valid even without the concept of vehicles moving in/out of a region of interest.
I think Need 'A' copes, with or without the support of Need 'B', provided that each vehicle provides a consistent interface (that may be a form of call-back from the vehicle that tells TxDOT what that vehicle can do and how to interrogate it) and provides a "beacon" of some sort to say it is joining the network. Your thought experiment is simplified by the fact that each vehicle is effectively "stand-alone" and does not have any need to know the state of any other vehicle in order to report its own health, so there's no requirement for Need 'B' at the first level of decomposition. The fact of whether or not a vehicle uses Need 'B' internally will be transparent to TxDOT.
As for the "off-grid" vehicles, I guess you don't know what you don't know.

Incidentally, what you're describing is roughly similar to the Car Genie system offered by our AA (Automobile Association, similar to the US' AAA, rather than Alcoholics Anonymous ) - A module that is left plugged into your car's OBD-II port and relays data to a centralised system that continually monitors for changes in conditions that could indicate an impending fault: https://www.theaa.com/breakdown-cover/connected-car

[RShannon]

My need is to see JTAG scale beyond chips. For this to happen, both A and B will be necessary.