feature article
Subscribe Now

LonWorks Evolves

IP, Cloud Services, and Wireless Mesh

My, how times change! Back more than 10 years ago, I wrote about a control-oriented network called LonWorks from a company called Echelon. And I covered the basics of the protocol then. “LON” stands for “local operating network,” and, despite the question posed in the title of the previous piece, its focus has been industrial applications (with “industrial” here meaning, more or less, anything not consumer).

Echelon, one of the original developers of LonWorks, was bought by Adesto last year. The changes we’ll discuss aren’t necessarily a result of that purchase (it’s way too recent), but new owners often spur new strategies or new markets or, at the very least, new energy.

As the times change, basic assumptions also change with an evolving landscape. LonWorks has its own complete stack – one that has been standardized in the ISO/IEC 14908[1] family of standards, with a focus on building, smart city, and smart grid applications. It’s been engineered to run on a variety of media – twisted pair, power lines, even fiber. That said, the lower layers of the stack have been specific to LonWorks – as contrasted with a wildly well-proliferated protocol like IP.

Then, as now, their messaging was that they were breaking the stranglehold many controls companies had over communication between sensor, actuator, and other nodes in industrial settings. So they positioned themselves as the solution to that proprietary lock-in. But, at the time I wrote that first piece, they were focused on cost, and they were concerned that TCP/IP as a transport/network protocol was too expensive to implement. So they did their own transport.

LON with TCP, IP, and Ethernet

Well, transport yourself back from then, and we have some changes that specifically reverse some of the thinking from that time. Per their latest announcement, LonWorks can now use the ubiquitous TCP over IP over Ethernet lower-level stack for the basics of moving packets around on a wired network. What’s changed?

Well, TCP, IP, and Ethernet are pretty much everywhere. They’re not the only game in town, but in a heterogeneous environment that mixes and matches equipment and upper-level protocols, having TCP/IP as a common denominator makes for smoother packet sailing.

Not only is LON-IP a new thing, it’s been recently approved by ANSI as standard: ANSI/CTA 709.7 — a step on the pathway to ISO standardization.

In addition, they’re working on what they call IAP (IoT Access Protocol) to bring web services – the cloud – into the fold. They’ve settled on MQTT as the high-level means of moving data around. They’re particularly fond of the publish-subscribe model that MQTT uses – something LON already has in place. That’s in contrast to CoAP, which is more REST-oriented.

Wired or Wireless or Both?

In my recent discussion with Adesto, and in rereading my old piece now, I was struck by the similarities to ZigBee in some ways. According to Adesto, that’s not an accident: they say that ZigBee had numerous elements that were based on LonWorks. But there’s a critical difference in their connectivity: LonWorks focuses on wired installations; ZigBee went wireless.

Or… at least that used to be the case. The LonWorks folks have been working with Wirepas to include a wireless mesh capability. It’s set up for reliability, with self-organizing nodes and adaptive routing; every node can be a router. It’s extensible to over 16 million nodes and further extensible with multiple gateways and load balancing. It can operate on short-range device (SRD), 868-MHz ISM, 915-MHz ISM, and 2.4 GHz ISM bands. Called LON ISM-RF, Adesto’s Rich Blomseth said that it “… has been developed and is in pilot deployments for applications including outdoor lighting system controls.”

That said, the question came back to my mind: if ZigBee were derived from LON, then why not turn back to it for wireless? And Adesto’s answer is that ZigBee committed itself fully to wireless, while LON is media-independent. LonWorks is simply adding wireless to the various wired formats that it already supports.

Private Security

We also discussed security, and they use a private-key system (AES) for the wireless version. While AES is common, authentication is often done with public/private key systems as a means of exchanging public keys that are used to give confidence that each side is who it says it is. That allows more typical systems to exchange a newly minted AES key that’s encrypted by the public keys when shared – often as a byproduct of a random-number challenge.

But LonWorks doesn’t use that public/private key system; each device is equipped with a private root key that is used to generate a session key. But… how do they exchange that private key without it being snooped? There’s no public/private key to encrypt the key as it is communicated. The answer is that, since both sides have the same root key, all they have to do is communicate a mathematical operation that’s used to derive the session key from the root key. That operation can be sent in the clear, since, in the absence of the actual root key, it provides no useful information.

This, of course, raised a red flag in my mind. If every device has the same root key, then hacking one device exposes all devices. I asked about this, and Mr. Blomseth confirmed that all the root keys were the same, but that they were “… kept in protected memory storage.” While that didn’t immediately ease my spidey senses, he added that, “Our authentication algorithm was analyzed by the military because they wanted to use it for protecting a system used for nuclear waste monitoring, and their conclusion was that it was sufficiently secure to support that application.”

So that adds more reassurance. But, as a last resort, they also have a way of rekeying all of the devices – changing the root key everywhere. He said that their utility customers do that routinely. With that, then, if someone does hack the root key, it will work for only a limited period of time – assuming that the root keys are refreshed.

[Updated to refer to Echelon as “one of the original LonWorks developers” rather than the “parent,” at Adesto’s request; clarify that ANSI standardization is on the path to ISO ratification; and to correct Mr. Blomseth’s name to Rich.]

 

More info:

Echelon (now owned by Adesto)

One thought on “LonWorks Evolves”

Leave a Reply

featured blogs
Apr 11, 2021
https://youtu.be/D29rGqkkf80 Made in "Hawaii" (camera Ziyue Zhang) Monday: Dynamic Duo 2: The Sequel Tuesday: Gall's Law and Big Ball of Mud Wednesday: Benedict Evans on Tech in 2021... [[ Click on the title to access the full blog on the Cadence Community sit...
Apr 8, 2021
We all know the widespread havoc that Covid-19 wreaked in 2020. While the electronics industry in general, and connectors in particular, took an initial hit, the industry rebounded in the second half of 2020 and is rolling into 2021. Travel came to an almost stand-still in 20...
Apr 7, 2021
We explore how EDA tools enable hyper-convergent IC designs, supporting the PPA and yield targets required by advanced 3DICs and SoCs used in AI and HPC. The post Why Hyper-Convergent Chip Designs Call for a New Approach to Circuit Simulation appeared first on From Silicon T...
Apr 5, 2021
Back in November 2019, just a few short months before we all began an enforced… The post Collaboration and innovation thrive on diversity appeared first on Design with Calibre....

featured video

Meeting Cloud Data Bandwidth Requirements with HPC IP

Sponsored by Synopsys

As people continue to work remotely, demands on cloud data centers have never been higher. Chip designers for high-performance computing (HPC) SoCs are looking to new and innovative IP to meet their bandwidth, capacity, and security needs.

Click here for more information

featured paper

Understanding Functional Safety FIT Base Failure Rate Estimates per IEC 62380 and SN 29500

Sponsored by Texas Instruments

Functional safety standards such as IEC 61508 and ISO 26262 require semiconductor device manufacturers to address both systematic and random hardware failures. Base failure rates (BFR) quantify the intrinsic reliability of the semiconductor component while operating under normal environmental conditions. Download our white paper which focuses on two widely accepted techniques to estimate the BFR for semiconductor components; estimates per IEC Technical Report 62380 and SN 29500 respectively.

Click here to download the whitepaper

Featured Chalk Talk

Keeping Your Linux Device Secure

Sponsored by Siemens Digital Industries Software

Embedded security is an ongoing process, not a one-time effort. Even after your design is shipped, security vulnerabilities are certain to be discovered - even in things like the operating system. In this episode of Chalk Talk, Amelia Dalton chats with Kathy Tufto from Mentor - a Siemens business, about how to make a plan to keep your Linux-based embedded design secure, and how to respond quickly when new vulnerabilities are discovered.

More information about Mentor Embedded Linux®