Hi

I would like to know if someone could explain in detail how the lontalk protocol works

/
Thomas

 

Thomas: The LonTalk protocol cannot be explained in an email. You should go to www.echelon.com and they have all the information you need there.
Ed Meltzer

 

Thomas:

The LonTalk protocol is a defined standard and publish protocol. It is typically embeded on a complex chip called a neuron. but it can be emulated by anything , depending on how much time and money you want to spend. The Lonworks technology is similar to other fieldbus technologies, there are two popular flavors 1.25mbaud and 78Kbaud. The bus support peer to peer communications between nodes.

If you need anymore info..
checkout
www.lonmark.org
www.echelon.com
www.bcsco.com

Mark Massa
.

 

There's a reference implementation on the Echelon website that's free, for a registration: http://www.echelon.com/products/Core/protocol/Default.htm

And this same page also aims you at a place to buy the EIA 709.1 spec which has more than *I* wanted to know about it.

Finally, the LonMark site, at http://www.lonmark.org/ has some profiles of
some more-or-less useful objects which can be manipulated with the LonTalk protocol. I'm not sure the public side of the site has all the
implementation guidelines; I know they don't have the documents which are still in progress.

Enjoy!
B.O. Feb. 17, 2000
--
Robert Old, System Architecture, [email protected]
Siemens Building Technologies, Inc., Landis & Staefa Division
1000 Deerfield Pkwy., Buffalo Grove, IL 60089-4513 USA
Phone: +1(847)215-1050 x5623, Fax: +1(847)419-2401

 

Wow, I am glad you didn't ask a difficult question (please note heavy sarcasm). I'll try to detail as much as I can without overloading this email message. You can get a copy of the protocol specifications from the EIA, standard EIA 709.

First, the LonTalk protocol shares many similarities to Ethernet (TCP/IP). Ethernet is a CSMA/CD protocol - Carrier Sense Multiple Access/ with Collision Detection. LonTalk is CSMA/CA and optional CD - Carrier Sense Multiple Access/ Collision Avoidance & optional Collision Detection. Ethernet has been around for a long time and there have been many improvements and technical advances in the CSMA type protocols but due to the established base of Ethernet devices, you don't see those improvements propogated in the market. Echelon tooks some of those improvements, added some additional improvements to optimize the protocol for control applications. Echelon has numerous patents in that area.

To get an idea of the differences you need to know how Ethernet works in a basic way. For multiple Ethernet devices to communicate on the network, they first listen to the network to determine when it is quiet (Carrier Sense). When the devices see the network go quiet, they attempt to jump on and start transmitting. If 2 or more devices start transmitting simultaneously, there is a collision and the devices detect that and stop transmitting (Collision Detect). In order to resolve the collision, the colliding nodes generate a random # - essentially a time delay. The devices wait their time delay and then listen to the network again. Statistically, it is unlikely that the devices will generate the same random delay. The
problem with Ethernet is that the number of delay slots is fixed and limited to 16. What this means is that as traffic increases, i.e. more devices offer messages to the network, then the likelyhood of generating the same random # increases. At some point you get almost 100% collision rate - that happens around the 40% bandwidth utilization (this varies based on a number of factors). This behavior is not so bad in a data network, the file just takes longer to get to the printer. For this behavior to occur in a control network could be disasterous.

Echelon solved this problems through a number of innovations. First, instead of jumping on the network as soon as it detects an open slot, the
protocol automatically generates a random delay slot from the beginning (i.e. Collision Avoidance). Secondly, instead of a fixed number of randomization slots the number of slots dynamically increase based on traffic load. As traffic increases the number of randomization slots increase, as traffic decreases the number decreases. This translates to a linear response with increasing traffic load. Statistically, even at bus saturation, you will only have a 4% collision rate. So even under heavy loads messages will still get through instead of shutting down your network. Hopefully you architect your network so that you aren't operating at saturation, but in the event it happens the network continues to operate. The protocol also allows you to establish priority slots. These are reserved slots and cannot be randomized into. You can create many reserved
slots and select certain messages to use those slots. For example, the brake message on a train would probably use priority 1 slot. The LonTalk
protocol does support Collision Detection, but most networks won't need it due to the low probability of collisions using the Collision Avoidance algorithms.

The protocol also supports transparent routing. A large network will have to be broken into segments, if for no other reason than drive limitations of the transceivers. Routers are useful for bridging between multiple media. The LonTalk protocol supports essentially any media. There are transceivers available for Twisted pair, free topology twisted pair, powerline, RF, COAX, Infrared, Fiber Optic and there is even a company in New Zealand that developed a transceiver to communicate over an electric fence. A single logical network can consist of many different media. You can choose the media of choice to best suit the installation - part of the network might be twisted pair, part on powerline, and another on RF. Routers serve to
seamlessly route messages across the various media. Nowhere in your application does your device on the twisted pair channel need to know that the message it's sending is going through one or more routers to get to that other node on the powerline channel. Routers also serve to segment traffic. Routers only pass messages that are destined to the other side of the router. If I have a bunch of devices with lots of traffic between them, I might choose to isolate that traffic with a router so that I don't impact the performance of the rest of the network. But it still allows for transparent passing of messages in or out of that channel if needed.

In the Ethernet world, every physical Ethernet device comes with a unique MAC address. When you attach to the IP network, your device is assigned a logical address - i.e. a unique IP address. The LonTalk protocol works in a similar manner. Every LonWorks device has a unique 48bit ID embedded in silicon (2^48 ~ 2.8 x 10^14 ~ 280,000,000,000,000 ~ 280 trillion combinations). Its not a wise idea to address devices on a network with its physical address. If I have applications using physical addresses and one device fails, its replacement would have a different physical address and your applications would have to be re-compiled -- not very practical. So like Ethernet, its better to assign a logical address. If a device fails,
its replacement is given the same logical address as the failed device and applications continue to work without change. In LonTalk protocol that
logical address is comprised of 3 parts : 1)Domain ID, 2)Subnet ID, and 3)Node ID. The Domain ID is the address of the overall logical network. You might need a domain id if you are using leaky media or sharing a physical channel with other logical networks. An example of this would be in the Home Automation network using powerline. It is quite possible that a message generated in my home will be seen in my neighbors home, especially if the neighbor is on the same transformer. To prevent conflicts of network
messages, each logical network is given a unique Domain ID. When a message is received, the first thing checked is the Domain ID to see if the message should be discarded or passed up the protocol stack. Within the LonTalk protocol, the Domain ID is configurable in length from 0 up to 6 Bytes long. This allows the network designer to balance the overhead against flexibility. With a 6 Byte Domain ID, you can have up to 2^48th logical networks. The Subnet ID identifies a collection of devices on the same
physical channel or media. The Node ID identifies a specific device within the subnet. A single logical network or domain can have up to 255 Subnets with up to 127 nodes/subnet, which multiplies out to a maximum device per logical network at 32,385 devices. This isn't a hard limit in that any LonWorks device can belong to 2 logical networks - i.e. can contain 2 distinct Domain ID's. In addition to the domain/Subnet/Node ID's, a LonWorks device can also belong to a Group. Each LonWorks device can belong to up to 15 groups. This allows a single device to take on different behavior depending on the group addressing. For example a light could
belong to Group RoomA and to Group EmergencyLighting and to Group SecurityLighting etc. The application in the light node could take
different action depending on which group ID was used.

With this hierarchical addressing, the LonTalk protocl provides a variety of addressing modes. Unicast - sending a message to one node using its
Domain/Subnet/Node addresses; Multicast - sending the same message to a group of nodes, using Domain/Subnet or Group IDs; Broadcast - sending a
single message to every node in the network using the Domain ID. With each message there are 4 different message options to choose from.

The default message delivery service is Acknowledged Service with Retries (Acked). An Acked message goes out and the receiving device responds with an ACK upon receipt of the message. The protocol handles this automatically
not your application. Every message goes out with a 16 bit CRC for error detection and the ACK is sent upon verification of a valid packet to the
proper address. If the sending node does not receive an ACK within a given time period (configurable), then the protocol automatically retries. The default is 3 retries but this too is configurable. If after all the retries
are exhausted and still no ACK has been received then an error event is posted and the application can take appropriate action. All Acked-ACK
transactions are true end-to-end acknowledgements. That is, even if a
message traverses one or more routers to get to the destination, the ACK comes from the destination, not the router. The sending device can be assured that the message was actually received. The protocol also supports Acked service to Groups but limits the group size to 63. The protocol keeps track of group ACKs and retries to the nodes that didn't respond and having Acked service to larger groups would be a difficult task to manage.

If Acked service is not appropriate or desired then you can choose Unacknowledged Service (unAcked), or as I prefer "Send and Pray Protocol". Sometimes unAcked messages are appropriate. For non-critical messages that
are repeated on a periodic basis, unAcked might be reasonable. An example might be a Time Clock Node that sends out the current time every 5 minutes. If I miss a message, its not so critical I can get the next one. By using unAcked messages I reduce the bandwidth usage not having the ACKs. This is especially important if I have a single message going to lots of devices.
The time message might be going out to hundreds or even thousands of nodes and I certainly wouldn't want hundreds/thousands of ACKs coming back.

If you are sending a message to lots of nodes but want to increase the probability that every node recieves the message without using ACKs, then
another message delivery service available in the protocol is Unacknowledged/Repeat Service. This service is the same as unAcked except that the same message is sent out "n" times. The default is 3 but the number is configurable. The example I use here is the emergency message for lights in a building. If a fire is detected, one of the actions I would like to have happen is to have every light in the building come on. I certainly wouldn't want to clog the network with ACKs coming back from the thousands of lights. I would like to increase the probability that every
light receives the message, so I would choose unAcked/Rpt.

Finally, if all those choices aren't sufficient, the final message delivery service is Request/Response. This is an application to application acknowledgement. When the receiving node gets the Request, instead of just an ACK, the ACK is returned with response data. Another way to use Rqst/Rspns is as a poll. I want to poll a device for its current data.

An important item to note is that nowhere in your application program do you specify which delivery mechanism is being used. The default is Acked, but that can be changed in the Network Image at installation/configuration time and doesn't impact the application at all. As a systems integrator, I can choose to have one message go unAcked/Rpt and the decide later to change it
to Acked and I can do that without taking the system down or reprogramming devices. I simply attach to the network, local or remote, and change the delivery mechanism.

The LonTalk protocol also has built in security in the form of Sender Authentication. It does not implement data encryption. In control
applications data encryption is less likely to be needed than sender authentication. Take the example of a utility meter. In the deregulated
market utilities are offering tiered pricing, pricing that varies depending on time of day. The utilities need to be able to update the pricing rates in the meters. Encrypting the data is not useful, since it must be readable by other devices and the home owner in order to function properly. However, the utility does not want the homeowner to be able to change the data. The
utility would choose to Authenticate the rate schedule message. I won't go into the details of the authentication process but they are detailed out in the EIA709 specification. But to give you an idea of its veracity, the DOE has selected LonWorks as its technology of choice for securing Nuclear facilities and fissionable materials and the strength of the Authentication algorithm was one of the key reasons.

One of the most important aspects to the LonTalk protocol is that you don't have to involve yourself in all the low level details if you don't want to. The protocol has already been written, tested, debugged and implemented into
low cost silicon called the Neuron Chip. Toshiba and Motorola were the two original licensees of the technology. Toshiba recently announced renewal of their license while Motorola has opted out. Motorola will continue to produce the Neuron chip until early 2001. In the mean time, Echelon has licensed Cypress and they expect to have first samples of the Neuron chip around 3Q/4Q of this year. The Neuron chip and protocol have been thoroughly tested in thousands of applications worldwide. Approximately 10
million Neuron chips have been shipped to date. Applications using LonWorks include : Building Automation (lighting, HVAC, security, Fire Safety,
elevator controls, etc), Home Automation, Factory Automation, Medical, Transportation (aircraft, railroads, ships, RVs, etc), and many many
embedded applications.

I hope this answers your questions without boring you to death. I suggest you look at Echelon's website for application notes, data sheets, white
papers etc - http://www.echelon.com

You should also look at the LonMark website - http://www.lonmark.org . The LonMark organization is a group of developers/companies interested in
defining the interoperability guidelines (those guidelines are downloadable from the website). Here is another key strength of LonWorks. As an
integrator I can feel comfortable that I can find lots of devices on the open market and be able to make them work together on the network regardless
of who manufactured them. As a developer, I have expanded markets because the market for open systems will be greater than that for closed systems. Plus, the market is now international and LonWorks is being implemented around the world.

Regards,

Fred Graham, Field Applications Engineer
Echelon
10945 Statebridge Rd, Suite 401 PMB-305
Alpharetta, GA 30022
770-887-9024 (voice)
770-886-0547 (fax)
mailto: [email protected]