Connect with us

Metrology service

Discussion in 'Electronic Design' started by D Yuniskis, Jul 4, 2010.

Scroll to continue with content
  1. D Yuniskis

    D Yuniskis Guest

    Hi,

    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.

    (etc.)

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

    Thx,
    --don
     
  2. D Yuniskis

    D Yuniskis Guest

    [forwarded from a conversation on a private list]
     
  3. D Yuniskis

    D Yuniskis Guest

    1 Lucky Texan wrote:

    [8<]
    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! ;-)

    Thanks!
    --don
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-