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
Nov 23, 2022
The current challenge in custom/mixed-signal design is to have a fast and silicon-accurate methodology. In this blog series, we are exploring the Custom IC Design Flow and Methodology stages. This methodology directly addresses the primary challenge of predictability in creat...
Nov 22, 2022
Learn how analog and mixed-signal (AMS) verification technology, which we developed as part of DARPA's POSH and ERI programs, emulates analog designs. The post What's Driving the World's First Analog and Mixed-Signal Emulation Technology? appeared first on From Silicon To So...
Nov 21, 2022
By Hossam Sarhan With the growing complexity of system-on-chip designs and technology scaling, multiple power domains are needed to optimize… ...
Nov 18, 2022
This bodacious beauty is better equipped than my car, with 360-degree collision avoidance sensors, party lights, and a backup camera, to name but a few....

featured video

How to Harness the Massive Amounts of Design Data Generated with Every Project

Sponsored by Cadence Design Systems

Long gone are the days where engineers imported text-based reports into spreadsheets and sorted the columns to extract useful information. Introducing the Cadence Joint Enterprise Data and AI (JedAI) platform created from the ground up for EDA data such as waveforms, workflows, RTL netlists, and more. Using Cadence JedAI, engineering teams can visualize the data and trends and implement practical design strategies across the entire SoC design for improved productivity and quality of results.

Learn More

featured paper

How SHP in plastic packaging addresses 3 key space application design challenges

Sponsored by Texas Instruments

TI’s SHP space-qualification level provides higher thermal efficiency, a smaller footprint and increased bandwidth compared to traditional ceramic packaging. The common package and pinout between the industrial- and space-grade versions enable you to get the newest technologies into your space hardware designs as soon as the commercial-grade device is sampling, because all prototyping work on the commercial product translates directly to a drop-in space-qualified SHP product.

Click to read more

featured chalk talk

Clamping Down on Failure: Protecting 24 V Digital Outputs

Sponsored by Mouser Electronics and Skyworks

If you're designing IEC61131 compliant digital outputs for these PLCs or industrial controllers, you need to have a plan to protect these outputs from a variety of unknowns. In this episode of Chalk Talk, Amelia Dalton chats with Asa Kirby from Skyworks about an innovative new isolated smart switch device from Skyworks that gives you an unprecedented level of channel flexibility and protection, letting you offer customers a truly “set it and forget it” solution when it comes to your next PLC design.

Click here for more information about Skyworks Solutions Inc. Si834x Isolated Smart Switches