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
Oct 26, 2020
Do you have a gadget or gizmo that uses sensors in an ingenious or frivolous way? If so, claim your 15 minutes of fame at the virtual Sensors Innovation Fall Week event....
Oct 26, 2020
Last week was the Linley Group's Fall Processor Conference. The conference opened, as usual, with Linley Gwenap's overview of the processor market (both silicon and IP). His opening keynote... [[ Click on the title to access the full blog on the Cadence Community s...
Oct 23, 2020
Processing a component onto a PCB used to be fairly straightforward. Through-hole products, or a single or double row surface mount with a larger centerline rarely offer unique challenges obtaining a proper solder joint. However, as electronics continue to get smaller and con...
Oct 23, 2020
[From the last episode: We noted that some inventions, like in-memory compute, aren'€™t intuitive, being driven instead by the math.] We have one more addition to add to our in-memory compute system. Remember that, when we use a regular memory, what goes in is an address '...

featured video

Better PPA with Innovus Mixed Placer Technology – Gigaplace XL

Sponsored by Cadence Design Systems

With the increase of on-chip storage elements, it has become extremely time consuming to come up with an optimized floorplan with manual methods. Innovus Implementation’s advanced multi-objective placement technology, GigaPlace XL, provides automation to optimize at scale, concurrent placement of macros, and standard cells for multiple objectives like timing, wirelength, congestion, and power. This technology provides an innovative way to address design productivity along with design quality improvements reducing weeks of manual floorplan time down to a few hours.

Click here for more information about Innovus Implementation System

featured Paper

New package technology improves EMI and thermal performance with smaller solution size

Sponsored by Texas Instruments

Power supply designers have a new tool in their effort to achieve balance between efficiency, size, and thermal performance with DC/DC power modules. The Enhanced HotRod™ QFN package technology from Texas Instruments enables engineers to address design challenges with an easy-to-use footprint that resembles a standard QFN. This new package type combines the advantages of flip-chip-on-lead with the improved thermal performance presented by a large thermal die attach pad (DAP).

Click here to download the whitepaper

Featured Chalk Talk

RX23W Bluetooth

Sponsored by Mouser Electronics and Renesas

Adding Bluetooth to your embedded design can be tricky for IoT developers. Bluetooth 5 brings a host of new capabilities that make Bluetooth integration more compelling than ever. In this episode of Chalk Talk, Amelia Dalton chats with Michael Sarpa from Renesas about the cool capabilities of Bluetooth 5, and how you can easily integrate them into your next project.

More information about Renesas Electronics RX23W 32-bit Microcontrollers