LonWorks™ is an open solution for device networking in the Building Automation, Industrial, Public Utility and many other markets. Created by Echelon Corp in 1988 LonWorks is a leading networking solution for Building Automation with a growing presence in Industrial Automation. Estimates for the number of nodes installed worldwide range into the millions.
When used in an industrial environment, a LonWorks solution is very different from the open device networks like DeviceNet, Profibus and Modbus typically found on the factory floor. First, unlike these popular device busses, LonWorks is a completely peer-peer network. Instead of moving data through a “Master” device, any device can exchange data with any other LonWorks device on the network. Second, LonWorks is not tied to a single physical communication layer. Where DeviceNet is limited to CAN and Profibus and Modbus are limited to RS485, LonWorks can use twisted pair, Ethernet or even a power line as its communication channel. Finally, network data exchanged on LonWorks is configured by a network configuration tool. This operation called “binding” ties an input of one device to an output of another device independent of the operation or application software in either device.
The Neuron chip is the heart of almost all LonWorks based devices. The Neuron chip is a complete system on a chip. The Neuron contains the entire LonTalk protocol stack and is comprised of multiple CPUs, memory, I/O, communications port, firmware, and operating system.
The Neuron chip contains three CPU's. One CPU is the Media Access Processor (MAC). The MAC processor is responsible for the sending and receiving of messages on the network. It also checks to verify if the CRC and the message destination is correct. The Network Processor is responsible for the middle layers of the protocol, doing things like packet routing, destination addressing, end-to-end acknowledgements, retries, duplicate message detection, etc.
The third processor is the Application processor. It is the processor that runs the users custom application. This is an 8-bit processor and does not have any hardware floating point. So it will not handle every application but if you can implement your application in a typical 8-bit micro then you shouldn't have any problem using the Neuron chip. For those more powerful applications you can either port the protocol to another high-end processor or turn the Neuron into a communications co-processor. The Neuron can connect to another processor and let that high-end processor run the application while the Neuron handles the communications.
The LonTalk protocol is the core technology providing an implemented, debugged, maintained, and proven protocol. It implements full functionality of the 7 layer OSI protocol standard. This provides a great deal of flexibility and expandability. Small networks are not required to use all the services but as that network grows, the features are there for expansion without having to upgrade software or firmware.
There are a variety of addressing mechanisms within the LonTalk protocol. In one mechanism you address a device directly so that you can assign it a logical address. Within the Neuron that logical address is comprised of three parts - the Domain ID, Subnet ID and the Node ID.
There is tremendous flexibility in addressing mechanisms. Where and how each is used is beyond the scope of this overview, but suffice it to say that there are strengths and weaknesses to each. It is important to understand your network architecture so that you can pick the addressing mechanism most appropriate for your application.
A major goal of the LonTalk protocol is to give developers, from the same or different companies, the ability to design products that will be able to interact with one another. The LonTalk protocol provides a common applications framework that ensures interoperability using powerful concepts called network variables and Standard Network Variable Types (SNVTs). Functional device models have been developed by the LONMARK Interoperability Association to assure plug and play compatibility.
Communication between nodes on a network takes place using the network variables that are defined in each node. The product developer defines the network variables when the application program is created as part of the Application layer of the protocol. Network variables are shared by multiple nodes. Some nodes may send a network variable while others may receive. By only allowing links between inputs and outputs of the same type, network variables enforce an object-oriented approach to product development. This greatly simplifies the process of developing and managing distributed systems.
Whenever a node program writes a new value into one of its output variables, the new value is propagated across the network to all nodes with input network variables connected to that output network variable. This action is handled by the protocol within the Neuron Chip.
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.
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.
