Within "Concepts and Architecture/Technology" I suspect that Interfaces (and "Access Points"), Retargeting and Transformation are going to be key elements that need to be defined and explained. That'll be part of the "education" as I expect that understanding those is going to be essential to be able to read any of the rest of the standard.
"Impediments" is maybe something of a "catch all" term at this stage: They probably come in several forms: Those that might prevent you applying the standard at all, those that might prevent you applying the standard to part of the system, or those that don't stop you implementing the standard but reduce it's effectiveness. I could imagine that some may not be obvious at the outset - I could envisage a case where after setting up and initiating a test action you need to retrieve the result within a certain timeframe, but the paths between what you want to use as the test controller and the test instruments has too much delay to meet the requirement.
I'm thinking that Test Portability is probably a topic in it's own right: There are probably several aspects to this that might come into play within the standard in different ways: Porting of canned tests from a device vendor into the STAM arena (and do we want to say anything about how a vendor should package such a test so that it is more readily usable by STAM?); Porting of tests from an external host controller to an embedded host controller; Porting of test across different vendors tool sets, etc.
We've talked a little about defining methods/formats for describing e.g. transforms that will be needed to build up the system model, but have we considered how the model will learn about the topology? It surely needs to know how the available interfaces relate to each other: It can't just assume that because Device A has an I2C master and Device B has an I2C slave that Device A has access to Device B. Netlists are the obvious answer but two things cross my mind on that:
For 1149.1 to be useful at the board level, it also needs a netlist. But I don't think the standard ever mentions netlists, and I think users of the standard (including tool vendors) just kind of infer/assume the use of netlists. Do we want to leave the same fill-in-the-blanks-yourself situation or do we want to be more specific?
We've previously noted that interconnection of boards is often an ECAD blackhole: You may have a netlist for a backplane as well as the plug-in boards but that doesn't guarantee that you know where the boards plug in. That's especially true when you have multiple boards that could fit a given socket or multiple sockets that could accommodate a variable number of plug-ins.
