What are SNVTs?

The use of Standard Network Variable Types (SNVTs, pronounced "snivets") contributes to the interoperability of LONWORKS products from different manufacturers. Echelon maintains a growing list of over 100 SNVTs for nearly all physical measurement types including the type of variable such as integer or floating point. For example, a SNVT for continuous level is defined as SNVT_lev_contin.

Download the Lonworks SNVT Mater list

If all manufacturers use this variable type in their application when a network variable for continuous level is defined, any device reading a continuous level can communicate with other devices on the network that may be using the variable as a sensor output to initiate an actuator. As long as a network input variable and a network output variable are defined with the same SNVT when the developer creates the applications, they can be connected together on the network through a process called binding.

When you install a node, you specify which network variables are to be connected between nodes. This is easily done by highlighting the output network variable on one node and the input network variable on the node or nodes to be connected. Only network variables of the same SNVT type can be bound together. In other words, a temperature type could not be bound to a pressure type.

What does LonWorks have for Security?

The LonTalk protocol does not implement data encryption but it does implement Sender Authentication. While mathematically similar, they provide different protection. Data encryption is commonly used to hide data. Your checking account balance is an example of encrypted data. Sender Authentication is used for verifying that the sender of a message is an authorized sender. Let’s examine the home utility meter as an example. The utility would like to be able to update the utility pricing rates within the meter by sending a message to the meter with the new pricing schedules. The meter receives the new data, but how does it really know that the new schedules came from an authorized source (in this case the utility)? The utility doesn't want to hide the data, because other devices within the home can make use of the pricing schedules to more efficiently run the house. But they do not want just anyone being able to change the pricing rates so they use Sender Authentication.

The way it works is that the utility places a unique 48-bit key in the meter - an authentication key. This is not the same as the 48-bit Neuron ID. The authentication key cannot be read out of the Neuron and cannot be changed without already having the key. Once the key is in place and the utility sends the update-pricing message, the meter now sees an Authenticated message. The meter responds to the Authenticated message by sending back a challenge with a 64 bit random number. The sending device receives the random number and performs an authentication transform on it and returns the transform back to the meter. The meter performs the same transform and if it matches the response from the utility, then the "update pricing" message will be processed.

At no time is the authentication key transmitted in this exchange. A spy on the network would see the pricing schedule, followed by a 64 bit random number, followed by a transform. Mathematically, given the random number and the transform, it is virtually impossible to determine the key.

While this authentication mechanism is very secure, it should be used judiciously since it does double the amount of traffic for each authenticated message.