Wednesday, January 8, 2014

Telemetry and Telecommand Syntax

The Console TM/TC architecture is based on the communication of brief messages that are lists of name - value pairs. Some instrumentation communicates with a name - value syntax, others with values only, and others with more complex analog or digital methods. The programmatic adaptation of instrument communication to the Console is performed in a dynamic library or a Linux system device. This article is intended to present TM/TC Console interoperation in a nutshell, as well as a review of a useful instrumentation protocol.

The name - value pair syntax is a register architecture. When implemented in the instrument, a collection of instrument registers are accessible via "telnet" (style) communication on a (TCP/IP or Serial) transport medium. An instrument may be queried and controlled by interaction with its registers. The approach is simple, effective, and efficient.

The Console sends and receives line oriented ASCII messages which employ the following syntax.

    Message := ( NameValuePair ( <sp> NameValuePair)* )

    NameValuePair := ( Assignment | Query )

    Assignment := Name "=" Value 

    Query := Name "?"

    Name := [ A-Z a-z 0-9 . _ ]+

    Value := ~[ <ws> "=" "?" ] 

The Message is a list of one or more space separated name - value pairs, where each pair may have one of two forms: Assignment or Query. The Name string is alphanumeric ASCII with dot qualifiers, and accepts underscore. Only one dot is permitted in a Name string. The Value is a string not containing whitespace, equals, or question - mark characters. The length limit on the Value string is 255 bytes, while some of the longest strings found in practice are date - time strings. Naturally the most common form of Value is a number in the real domain, which is best formatted as an exponential (e.g. "1.000000e-03" as C stdio printf "%e" format string). On the wire, a Message line is terminated by CRLF (0x0D, 0x0A) or LF (0x0A).

Typical applications of this format might not employ qualified (dotted) names, but simple register name strings like "TEMP", "PRES", "SP1" and "SP2". A qualified name like "SENS.COLOR" or "SENS.LABEL" might be seen downstream from the instrument in the Graphical User Interface or Data Grid.

An instrument should support the automatic sending of telemetry messages. In this feature it may have a mode register to enable automatic telemetry. For example: "M=A" may be sent to the instrument to enable automatic telemetry, and "M=M" may be sent to the instrument to disable automatic telemetry.

An automatic telemetry message may contain only values which have changed since the last auto message (dynamic), but the recommended form is the conventional (static) emission of all (physical system) measurement and control registers. The following illustrates the automatic telemetry message with a plausible example.

TEMP=1.000000e+01 PRES=1.000000e-02 SP1=1.000000e-03 SP2=1.000000e-08 

"Glob queries" like "PRES?" or "TEMP?" which produce lists of assignment expressions for actual registers "PRES1", "PRES2", and "TEMP1", "TEMP2" are very useful for telnet users as well as the effective construction of dependent software systems.

The instrument's handling of Units is an interesting subject which illustrates some information architecture. A Units register (e.g. "U") is correctly associated with the instrument ("U.TEMP") rather than the sensor ("TEMP.U"). Most instruments have one sensor channel, and only one Units Register is necessary ("U"). For an instrument with multiple Units, as in temperature and pressure, the Units Register should be associated with the instrument: the "U" register would be qualified as "U.TEMP" and "U.PRES". The inverse qualification ("TEMP.UNITS" or "PRES.UNITS") fails the test of coherency for multiple channels by multiple specification. The multiple specification of identical Units is incorrect: it has a negative utility by creating the possibility of user error. Therefore expressions of the form "TEMP.U" or "PRES.U" are incorrect in terms of the state of the instrument or information architecture.

The subtleties of qualified naming follow the principles of information architecture as illustrated in the previous paragraph, and may also provide for the utility of glob queries. An example of the latter case can be seen in the case of an instrument which describes attached devices or sensors. The greatest utility is served when a software machine (in particular) can discover attached devices with a simple query like "A?". In this example, the response is a list of assignment expressions for numbered registers in the set "A1", "A2", etc., which provide a brief identifier for the end user.

The TM/TC Console register naming conventions and their description include the following.

AAttached devices information
DCNDevice connection name is an option from the instrument layer to identify a fully qualified port identifier like an IP address or Serial port name. A two part identifier may be separated by a colon (:), as in the concatentation of an IP address with a port number.
MRequired telemetry mode, "A" or "M"
PRESPressure measurement
TRequired automatic telemetry emission period in seconds as a real number: integer or (dot) decimal
TEMPTemperature measurement
TIMEMessage receipt time may be formatted as a long integer number of milliseconds since Jan 1, 1970 (Unix epoch) but is not required from the instrument
UUnits: a full name, case insensitive (e.g. "celcius" or "millibar") -- should be lower case
VInstrument firmware version
The names of measurement registers should follow the numbered set (globbing) format (e.g. "TEMP" and "TEMP1", "TEMP2") but are otherwise free of requirements excepting that of data grids. While the Console is not dependent on register naming conventions for principal measurement and control registers, data grid schemae benefit from uniformity in naming.

The TM/TC Console interaction protocol has three terms (transition graph nodes): Query, Verb, and Noun. The Query term is a syntactic expression distinct from an Assignment expression. The Assignment expression has two interactive forms, the Verb and Noun. A request to the instrument is a Verb, and a response from the instrument is a Noun. An instrument response is required of each request, and may take the form of a Query expression in the case of an unrecognized register name, or a plain question - mark (?) for unrecognizable input.

A correct assignment expression entered into the instrument input channel (Verb) is acknowledged by an equivalent response (Noun). An erroneous Verb assignment value produces a response Noun which echos the state of the register -- as in the case of a Query.

For example, "SP1=1.0e-3" is a Verb when entered by the instrument user, and a Noun when emitted by the instrument. The (request) Verb "SP1=1.0e-3" would produce the numerically equivalent (response) Noun "SP1=1.000000e-03". The error case is represented similarly when the instrument responds with the state of the register before an erroneous input was received. A subsequent Verb "SP1=foo" would produce Noun "SP1=1.000000e-03".

Of course, the design of a TM/TC protocol has two objectives: to present an interface to the features of the instrument, and to enable software machines to use the instrument. A substantial contribution to maximizing instrument product value and minimizing dependent software investment is a well designed telemetry and telecommand interface. The approach described here is efficient and effective subject to utility for "telnet" users and software systems.

No comments: