Metrology service


OK, I finished the design of a metrology service. The goal, here, is to allow clients to dynamically (re)configure the server to provide its data in a way that best fits the client's (application's) needs -- WITHOUT any a priori knowledge of the capabilities of the device being served *or* the requirements imposed by other concurrent clients (!)

The service is connection oriented -- stateful. So, the characteristics required by each client are bound to that connection.

Essentially, I allow the client to query the current range of values for any of several parameters (one at a time). Within that range, the client can *specify* a value for that parameter at any time. This, in turn, may affect the range of values available for *other* (as yet, unconstrained) parameters.

The server is free to give the client *better* performance than specified but never worse. The client can examine the current value of any particular parameter (even though the client should, theoretically, *know* what it requested of the server for that parameter!).

Obviously, the ranges for each parameter vary with the device being served. And, the relationships between these parameters will likewise have device-specific interactions. My framework handles these with up-calls to device specific methods in the server.

I've had a hard time settling on the right set of parameters to support. Keep in mind, the framework has to support a variety of devices so tailoring the parameters to a particular device or device class is not acceptable. (the API also needs to be consistent!)

I allow the "high" limit on a measurement to be specified. The server is free to support *higher* than specified. Likewise, the "low" limit -- the server can support *lower*.

I allow accuracy to be specified as percent of value as well as "absolute" accuracy. Of course, the server can provide more accuracy than requested.

The client can request a desired resolution (fineness of measurement) as well as update interval. The server can provide finer measurements and more frequent, respectively.

So, to put it together, a (fictitious) client-server dialog for a temperature sensor might be:

C: get low S: -100 (e.g., degrees C)

C: get high S: 200

C: get error S: 0.25 (degrees C)

C: get tolerance S: 0.5 (%)

C: get resolution S: 0.1 (degrees C)

C: get rate S: 100 (Hz)

Note that this defines the most permissible operating envelope for the service -- the device might not be capable of operating within these UNCONSTRAINED parameters (e.g., the resolution might increase -- get worse -- if operated near the high end of the range).

The client then refines the actual operating conditions:

C: set low 50 S: 0

In this case, the server has decided that it can configure itself to support a low limit of 0 with no consequences beyond those associated with the requested limit of "50" (i.e., the server is free to provide *better* than requested)

C: get high S: 200

[The high limit capability was not affected by the choice of low limit]

C: set high 100 S: 100

C: get tolerance S: 1 (%)

By constraining the operating range, the server refines the best tolerance available FOR THAT RANGE.

C: set tolerance 2 S: 1%

The server feels it can still offer a better tolerance than requested.

C: set rate 5 S: 50

The server can offer faster updates than requested.

C: set resolution 0.2 S: 0.1

C: get rate S: 10

Note that the rate has been reduced -- a consequence of the resolution required.


When all parameters have been specified, the client can query the server for the current operating conditions/configuration. Note that this will be AT LEAST as good as requested but probably

*not* as good as initially advertised (by the server).

It is important to note that the server is only contractually obligated to provide the level of service *requested* by the client -- *not* the configuration advertised at the end of the configuration dialog! I.e., if another client connects to the server subsequently, the server might tighten the operating configuration *beyond* this advertisement -- as long as the requested configuration is still supported.

If, for example, the client *wants* to lock in this advertised configuration, then it should explicitly update each parameter with the advertised values AS IF these were its *desired* operating point.

What else am I missing? I haven't made up my mind on "precision" as I think it is too hard to find specified on most devices.

And, I don't know how to address server-side filtering. I think it may be too device-specific to reside on the server (?) -- unless I allow a function to be pushed? (creating such functions would be annoying as they would need upcalls from the server's configuration mechanism to adapt to changes in the *actual* configuration of the service -- e.g., if update rates change...)



Reply to
D Yuniskis
Loading thread data ...
[forwarded from a conversation on a private list]
Reply to
D Yuniskis

The only thoughts I had are perhaps an 'accuracy,confidence' - type progress bar as each parameter is gathered/displayed. Particularly those which are waiting on other inputs. A user in a hurry could decide when 'it's good enough' and maybe go on to a different task or block? Or even letter grades from F to A.

And if the system includes alarm/flag conditions, those could be user- defined in a ranking system. Perhaps for some devices, a reduction in accuracy is less important than a speedy report?

I dunno, just brainstorming.

Reply to
1 Lucky Texan
[8> What else am I missing? I haven't made up my mind on "precision"

Ah, sorry if I wasn't clear. The "user" (client) is a piece of software. This interface lets that software tailor itself to the capabilities afforded by the sensor.

For example, it allows a control loop to do some self-tuning by knowing what these characteristics are. So, if a sensor has a high inherent latency or slow update rate, it lets the loop "slow down" to avoid oscillation (i.e., no sense trying to control faster than the available sensory data).

It also lets the software (client) know the "goodness" of the data it is operating on. E.g., you can have great resolution but if your *precision* sucks, what good is it?

That's not really an issue, here.

Yes. In some cases, that *speed* allows you to get an even

*more* accurate report. E.g., configure for wide operating range, fast response time, sacrifice accuracy; take reading(s); reconfigure for tighter operating range (based on those observations) at higher accuracy -- possibly sacrificing response time.

It lets the measurement device *appear* to have smarts -- instead of just blindly configuring it to operate in a certain manner and then *living* with those constraints "forever".

That was my point in asking! ;-)



Reply to
D Yuniskis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.