LONWORKS – LOCAL OPERATING NETWORKS

ABSTRACT

A technology initiated by the Echelon Corporation in 1990, the LonWorks

provides a platform for building industrial, transportation, home automation and public

utility control networks to communicate with each other. Built on the Local Operating

Network, it uses the LonTalk protocol, in order to have a peer to peer communication

with each other, without actually having a gateway or other hardware.

IEC Intelligent Technologies has been developing LONWORKS technology

applications for over nine years, and was a LONWORKS Independent Developer for

over six years. As the result of this extensive background in applying LONWORKS

technology solutions to problems in the real world, products and services from IEC can

make almost any LONWORKS application simply better.

 1. INTRODUCTION:
A local operating network consists of intelligent devices, or nodes, that are
connected by one or more communications media and that communicate with one
another using a common protocol. Nodes are programmed to send messages to one
another in response to changes in various conditions and to take action in response to
messages they receive.

The nodes on a LON may be thought of as objects that respond to various inputs
and produce desired outputs. Linking the inputs and outputs of network objects enables
the network to perform applications. While the function of any particular node may be
quite simple, the interaction among nodes enables a local operating network to perform
complex tasks. A benefit of local operating networks is that a small number of common
node types may be configured to perform a broad spectrum of different functions
depending how they are linked in a network.

2. OPEN SYSTEMS:
Each component part of a control system plays a role. Hardware is used to
measure real-time values and cause control actions and software is utilized to
manipulate system hardware for the purpose of monitoring and controlling system
functions. The physical devices that are commonly found in an HVAC control system
include:

• Sensors, Control Devices, Controllers, Networks, Operator Interface PC

The software installed on a user's PC, which is required to support installation

and operation of the control system, is often proprietary. Manufacturers over the years
have marketed software using three common designs. Older designs were based on a
line-programming structure similar to Basic where HVAC applications were actually
written and compiled much like computer programs.

Typically, control system software supports the following functions:

 Network configuration: These functions are used to identify, install, and
configure component parts of the control system. In other words, these functions are
used to define system architecture.

Develop and edit control logic: Typically used with programmable controllers,
this software is used to develop control applications that can be downloaded into
programmable controllers.

Provide human-machine interface (HMI): Graphical user interface that

provides these functions: real-time data display (both text and graphic), trending and
data collection, alarming, remote communications (modem dial-up and Internet), and
more.

System architecture is the term used to describe the overall network structure of
a control system. In many instances, a primary LAN, using a standard protocol such as
TCP/IP, provides connectivity for operator interfaces to remotely access control system
data. A router and/or area controller acts as a bridge between the primary LAN and the
fieldbus on which DDC controllers exist.

In control systems, gateways are often used to connect systems from different
manufacturers—they act as an interface between proprietary control systems, allowing
equipment using different proprietary protocols, communication speeds, and/or data
formatting to exchange data.

A host bridge combines the functions of a user interface with those of a gateway
to provide a high-end workstation that communicates with multiple vendors' proprietary
control system equipment. In this architecture, software drivers replace separate
gateways. The workstation is typically capable of displaying real-time data, allowing
control commands and setpoint changes, and handles alarms and error messages, but
detailed editing of control logic still requires knowledge and use of underlying
proprietary software.

2.1 Openness in Control Systems:

There are three classifications of protocols: closed, open, and standard.

Historically, designs have been protected by their manufacturer, which have resulted in
very little cooperation and far less interoperability. Recently, though, in the interest of
promoting vendor independence, the market has been pressuring vendors to pursue
designs that are more open. As a result, varying degrees of openness are emerging.
These range from designs that merely support coexistence on the same network to
designs that support full interchangeability.

2.2 The Vendor’s view of Open Systems:

From the vendor's perspective, a move towards the production of hardware and
software products that support open systems carries major risk:

• Products become commodities, which drives margins down.

• A move away from proprietary designs poses a threat to incremental

work.

• Customers have the ability to move more easily to alternative vendors.

A good halfway position is to move towards using open or standard protocols

within a closed system environment. In other words, market your products as being
open, but employ proprietary network configurations, thick clients, and specialty
programming tools. This increases the potential for incremental work and restricts
customer mobility.

2.3 The Customer's View of Open Systems:

From the customer's perspective, a move towards openness allows them to

utilize a systems integrator to install control systems composed of devices selected
solely on price and function.

• All incremental work should be best of breed.

• Changing SIs should be possible at minimal cost.

• Long-term relationships with SIs are based on consistent value delivered

project to project.

• Service after the installation is the basis for continuing those

relationships.
 • New opportunities beyond the offerings of a single vendor for new
products and diverse sub-systems.

LONWORKS OVERVIEW:
LonWorks is the name given to the collective technology developed by the
Echelon Corporation for implementing control system networks. The root term, LON, is
an acronym for local operating network, which refers to an intelligent control network
that facilitates communications between devices or nodes that communicate with one
another over a variety of transmission media using a common, message-based control
protocol. Echelon's design endeavors to provide an off-the-shelf method for
manufacturers to build devices that can coexist and operate as peers on a flat,
interoperable control network.

Components often found in a LonWorks control network include:

1. Local Control Nodes: These are network devices that monitor and control the
operation of attached sensors and/or actuators based on local and remote stimuli.
2. Supervisory Nodes: These are network devices that collect and pass data from one or
more local control nodes. Supervisory nodes may also coordinate the operation of one
or more local control nodes.
3. Network Management Tools: These are the software tools and services that are used
to logically address nodes, configure them, and bind their network variables. Network
management tools are also used to monitor nodes, diagnose communications errors,
and effect repair or replacement of devices on a control network.
4. Routers: Routers provide transparent connectivity between two LonWorks network
channels.
The overall LonWorks design approach is to:
• Define the nodes required in the system.
• Define the relationships between the nodes.
• Develop the application-specific programming for each node, which defines its
behavior.

3.1 Echelon Corporation:

 Echelon Corporation, based in Palo Alto, California, was founded in 1988 by the
co-founders of Apple Computer and ROLM Corporation (A.C. Markkula and M.Kenneth
Oshman, respectively). They report over 3,500 users for their 80-plus products and, as of
March 1999, the company had received 71 United States patents, with 18 additional
applications pending for technologies relating to their initial design. The company
employs approximately 166 employees based primarily in the United States, with a lesser
presence in Japan, the Netherlands, and the United Kingdom.
Echelon develops and markets hardware components and software development
tools targeted at original equipment manufacturers (OEM) and systems integrators (SI) to
design and implement open, interoperable, distributed control networks based on the
LonWorks design.

3.2 Application and Distributed Channels:

Fundamental to the LonWorks design is its support of multi-vendor control
products communicating across different types of transmission media in a single system.
As a result, LonWorks provides a highly functional control networking scheme to meet
the special needs of a widely diverse collection of application purposes including
building and industrial automation, transportation, home/utility automation, and more.
Using standardized data types, devices designed for different application purposes by a
variety of manufacturers can share information and also be monitored from a common
PC interface, allowing interoperability and integration.
For example, in an office building containing a LonWorks network the
subsystems will work together as one system providing integration of HVAC, Lighting,
Security, and Access Control.

3.3 LONMARK:
If a device is designed to use the LonWorks technology, depending on the
implementation, it may or may not interoperate with other LonWorks devices. Simply
using the LonWorks technology does not guarantee interoperability. The LonMark
certification is granted through the LonMark Association, which is a large, relatively
independent organization of manufacturers, suppliers, and end users from around the
world.
The organization develops technical product specifications and guidelines that
promote interoperability among participating equipment manufacturers. Participation of
this nature promotes interconnection and intercommunication with other products.
LonMark refers to the mark signifying that a product has met LonMark guidelines that
allow it to interoperate with other LonMark devices on a LON.

3. LONWORKS DESIGN CONCEPTS:

Echelon began developing the LonWorks technology in 1988 with the goal to
develop a universally accepted standard for control networks. As such, LonWorks would
become the standard platform on which control system devices could communicate on a
peer-to-peer fashion to monitor sensors, control actuators, and provide complete access to
control system data. In many ways, LonWorks control networks resemble typical local
area networks.
4.1 LANs and LONs:
Communications networks are for sharing data. A network of computers that
serves users within a limited geographical area is referred to as a local area network
(LAN). In a networking scheme, where peer-to-peer communications is used, each
computer on the LAN has equal responsibility for initiating, maintaining, and terminating
a session. The structure of the LonWorks communications protocol is similar to a LAN in
that computers or nodes on a common network share data continually using peer-to-peer
communications. But, because LonWorks devices operate according to a special set of
rules or protocol (different from what is typical for LANs), the network has been termed
a local operating network (LON).
1. The primary distinction between LANs and LONs is their purpose.
Traditionally, LANs are designed to move large amounts of data from one
computer to another over a network connection. The performance of a LAN is
viewed in terms of throughput, which is the amount of data transferred from
one location to another, and it is often measured in megabits per second
(Mbps).
 2. A LON, on the other hand, is designed to transmit sensing and control
messages, which are typically very short and relate specifically to monitoring
real-time status and triggering a control action. Therefore, LON performance
is not measured in terms of throughput, but in terms of completed transactions
per second and response time. For a LON, the critical performance factor is
assuring that relatively small messages are rapidly delivered from one location
to another. A real-time control system does not necessarily need to handle vast
amounts of data, but it does require timeliness, dependability, and accuracy.

4.2 LonTalk Protocol:

A LON, which is a control system field bus, allows intelligent devices, such as
actuators and sensors, to share data directly, using a standard protocol. The protocol,
known as LonTalk, is Echelon's open-architecture communications protocol used by all
LonWorks-based devices. It allows intelligence and communication capabilities to be
embedded into individual control devices that can be connected together through a
variety of transmission media including twisted pair data cable, existing power lines,
radio frequency (RF), coax, fiber, and others.
The core of this embedded intelligence is a mixture of hardware and firmware on
device known as a Neuron chip, which is an integrated circuit manufactured under
license by Cypress, Motorola, and Toshiba. Almost 10 million Neuron chips have been
shipped since 1992 on devices from Echelon and roughly 4,000 other manufacturers
worldwide.
The Neuron chip implements the LonTalk protocol and performs a variety of local
sensing and control functions. In addition, each node includes a physical interface or
transceiver that couples the node to its transmission medium. A typical node in a
LonWorks control network performs a simple task, such as measuring a temperature,
monitoring equipment status, or controlling a motor. When combined together with
complementing nodes, the overall network can perform rather complex control
applications, such as running a manufacturing line or automating a building.

4.3 Smart Devices:

 A LonWorks control network enables a group of electrical devices, or nodes, to
be connected together to implement sensing, monitoring, control, and communications
capabilities for a variety of applications. Each node contains a Neuron chip, a power
supply, and a communications transceiver. The communications transceiver couples the
Neuron chip to the transmission medium and the Neuron contains the firmware and
software required for sending, receiving, and acting upon a variety of control signals.
In addition to these components, each node has a physical ID, a timer, a
computation unit, device controllers, I/O ports, and communications and control
software. In effect, each node is a rather sophisticated computer, which is why they are
often referred to as intelligent or smart devices.
4.4 Network Architecture:
The network architecture of a LON can be best understood by examining three
different models of a distributed control system. These include:
• A centralized control system.
• A fully distributed (flat) control system.
• A semi-distributed control system.
3.4.1 Centralized Control System
A centralized control system uses a single supervisory processor that directly and
individually connects to low-cost, non-intelligent I/O devices. In this model of a
centralized control system, the supervisor hosts all system operations. It creates a
Master / Slave relationship between the Supervisors and the non-intelligent I/O devices.
Figure 4-1 Centralized architecture (non-distributed).
4.4.2 Fully Distributed (Flat) Control System
A fully distributed control system is the opposite of a centralized system. This flat
architecture is Echelon's vision of control system network architecture. In this model,
intelligence is distributed to each device on the network—to every switch, each sensor,
and to every controlled device. In a fully distributed control system, every field device
contains a Neuron, a communications transceiver, and the other firmware and software
required of a LonWorks node.
Each node exchanges data on the LON with its peers and the tasks it performs are
defined individually in that node. Peer-to-peer communications is the ability of nodes to
communicate directly with one another rather than have a central control system manage
those efforts.
Figure 4-2 Distributed control system architecture.
4.4.3 Semi-Distributed Control System:
In between the centralized and fully distributed control systems is the semi-
distributed control system (Figure 4-3). Many control system manufacturers have chosen
this model as the best combination of economy and usability in delivering LonWorks-
based control.

Figure 4-3 Semi-distributed control system architecture.

 In this model, application-specific controllers use their own processing power to
provide interoperability combined with onboard I/O to interface with low-cost sensors
and actuators that do not contain a Neuron. Managing collections of the application
specific controller are area controllers, they provide global control strategies and over all
coordination of the system. This architecture allows for the best of both worlds by
supporting the peer-to-peer communication at the application specific level while
maintain control of the big picture at the area controller level.

4. LONWORKS ARCHITECTURE:
5.1 Elements Overview
The LonWorks technology includes all of the elements required to design,
develop, and deploy control system networks. These include:
• The Neuron Chip
• LonTalk protocol
• LonWorks communications transceivers and network interface
• Network management tools
In addition to the Neuron chip, LonWorks devices require a transport system that they
can use for communications. As part of the LonWorks technology, Echelon has defined
and provides much of the infrastructure needed to implement these networks.
5.1.1 The Neuron Chip
The central component of an Echelon node is the Neuron chip. Each Neuron chip
contains three 8-bit, in-line CPUs, on-board memory, eleven general-purpose I/O pins,
and a complete interoperable implementation of the LonTalk protocol. In fact, on
Neuron-based nodes, the Neuron chip alone does the vast majority of the work performed
by the node. Except for the power supply, I/O devices, and some of the transceiver
functions, all work performed by the node is done by the Neuron chip.
 As shown in Figure 5-1, the Neuron chip performs several different duties at
once. It is a processor, a device controller, a memory chip, and it has built-in EEPROM
that contains network configuration and addressing information, a unique permanently
programmed 48-bit serial number, and optional user-written application code. There are
two models of the Neuron chip available from Echelon: the 3120 and the 3150. Both
models provide three processors (two dedicated to communications and another dedicated
to applications processing), I/O device controllers that support connection to applications
hardware, timing and counting hardware, and a transceiver interface. Both chips include
on-board memory. The 3120 includes RAM (1K) and ROM (10K), where the 3150
includes 2K of RAM (no ROM) and an external memory interface for more complex
applications processing.

5.1.1.1 Neuron Chip Data Structures

Figure 5-2 depicts the various data structures that may be stored in on-chip
EEPROM, off-chip EEPROM, flash, or NVRAM.
5.1.1.2 Processing Units
The three processors contained on the Neuron chip include the Media Access
Control (MAC) processor, the Network Processor, and the Application Processor.
• The MAC processor drives the communications subsystem. It communicates
with the Network Processor using network buffers located in shared memory.
• The Network Processor handles network variable processing, addressing,
authentication, network management, and more. It communicates with the MAC
processor using network variables and with the Application Processor using
application buffers.
• The Application Processor executes user-written code together with operating
system services called by that code. Applications code is primarily written in
Neuron-C, which is a derivative of the ANSI C language optimized for
LonWorks-based distributed control applications.

5.1.1.3 Network Image

A node's network image describes how the node appears to all other nodes on the
network. It contains the address assignments of the LonWorks node, binding information
connecting network variables and message tags between nodes on the network,
parameters of the LonTalk protocol that may be set at installation time, and configuration
variables of the application program.
Portions of a node's network image can be set by the manufacturer at production
and others are downloaded over the network by a network management tool into
EEPROM when the node is installed. Network images contain the following data:
Neuron ID, Mfg Data, Node Type, Node Address, Address Table, Location ID, NV
Configuration Table, NV Fixed Table, Comm Data, Mode Table, and SI-SNVT/SD.
5.1.1.4 Domain Table
The domain table contains an entry for every domain to which a node belongs.
5.1.1.5 Address Table

The address table defines the network addresses to which a node can send
messages and network variables. It also defines the group(s) to which the node belongs.
For each address table entry, the first byte contains the type of address table entry
including group, subnet/node, broadcast, turn-around, or not in use.
• Group addressing is used for multi-casting, when a network variable or message
tag is used in a connection that has more than two members.
• A subnet/node address is used when a message is to be sent to only one other
node.
• Broadcast addressing is not typically used, but it is supported by the protocol to
allow explicit messaging.
5.1.1.6 Network Variable Tables
Network variables have three associated tables: the network variable
configuration table, the network variable alias table, and the network variable fixed table.
• Network Variable Configuration Table: Defines the configurable attributes of
the network variables in the node. The table is located in EEPROM so that it can
be modified and it becomes part of the network image written to the node during
installation.
• Network Variable Alias Table: Defines the configuration attributes of the alias
network variables in the node. This table is also located in EEPROM,
immediately following the network variable configuration table.
 • Network Variable Fixed Table: Defines the compile-time attributes of the
network variables in the node. The table may be located in ROM and it is part of
the application image written at the time the device is downloaded.
5.1.2 Hosted Nodes
In addition to Neuron-based nodes, where the application layer (OSI layer seven)
runs in the Neuron chip, control devices can also use a separate dedicated microprocessor
to run the layer seven applications. Nodes that off-load the application layer to a separate
host processor are referred to as hosted nodes.
Three different communications interface modules are available:
Microprocessor Interface Program (MIP): This module supports custom network
interfaces.
The Network Services Server (NSS) engine: This module is used in the LNS
architecture to process network services, maintain the network database, and enable and
coordinate multiple points of (PC) access.
Network Services Interface (NSI): This module is used in the LNS architecture to
provide connectivity to the LonWorks network from multiple clients.
5.1.3 Transceivers, Media, and Network Topology
In addition to the Neuron chip, LonWorks devices require one of several
transceiver modules for communications. These devices are manufactured by Echelon
and they provide connectivity for virtually every transmission media including twisted
pair, power line, RF, infrared, coaxial cable, and fiber.
Probably the most versatile and popular transceiver is the FTT-10 Free Topology
transceiver, which supports twisted pair, unshielded, polarity-insensitive, peer-to-peer
communications at 78 Kbps. Examples of FTT-10 network topologies are illustrated in
Figure 5-3 and Figure 5-4.
 A network segment in a free topology network is any part of the network in
which each conductor is electrically continuous. Each of the four diagrams above is a
segment. Some application may require two or more segments.
5.1.3.1 FTT-10 Topology
As illustrated in Figure 4-3 and Figure 4-4, there are two broad categories of
wiring topologies supported by FTT-10: the Free Topology approach and the Doubly
Terminated approach.
• The Free Topology approach allows any number of tees, stars, loops, or bus
combinations in a wiring segment.
• The Doubly Terminated approach, although it supports greater wiring lengths, is
significantly more restrictive in terms of wiring topology.
A single wiring segment supports up to 64 nodes (FTT-10 transceivers), but a channel
can span multiple segments that employ physical layer repeaters to expand both the
number of nodes and the length of the control network. Depending on the application and
expected network performance (in terms of response time), the maximum number of
nodes supported by a LonWorks network is 32,385.

5.1.3.1.1 Free Topology Restrictions

 Although free topology wiring is very flexible, there are a few restrictions
including:
• The maximum number of nodes per segment is 64.
• The maximum node-to-node distance is 1640 feet (500m) when using Belden
85102 cable or 1312 feet (400m) when using Belden 8471.
• The maximum total cable length is 1640 feet (500m) unless you use TIA
Category 5 cable, in which case total wire length cannot exceed 1476 feet (450m).
• One 52.3 ohm (0.25W, 1%) termination resistor is required in each segment. If
you install a repeater and another segment, you need to install a termination
resistor in that segment.
5.1.3.1.2 Doubly-Terminated Bus Topology
The trade-offs are
1. This topology must be rigorously adhered to during installation and for all future
retrofits, and
2. Two termination resistors are required (at the ends of the bus).

The restrictions on a doubly-terminated bus topology include:

• The maximum number of nodes per segment is 64.
• The maximum total bus length depends on the wire size.
 • The maximum stub length is 9.8 feet (3m). A stub is a piece of cable that is wired
between the node and the bus—if the bus is wired directly to the node, there is no
stub.
• Two 105 ohm (0.25W, 1%) termination resistors are required in each segment.
One resistor must be located at each end of the bus.
5.1.3.2 Channels
The term channel is an Echelon term used to describe the physical medium to
which a node is attached and the transceiver type it uses to communicate. Although the
LonTalk protocol supports networks with segments using different media (channels), all
devices on a given channel must communicate using the same type of transceiver.
Every LonWorks node is physically connected to a channel. The physical form of
a channel depends on the medium: a twisted pair channel is a twisted pair wire; an RF
channel is a specific radio frequency; a power line channel is a continuous section of AC
power wiring, and so on. Multiple channel types are connected by routers.
5.1.3.3 Routers
Routers are used to manage network message traffic, extend the physical size of a
channel (both in terms of length and the number of devices attached), and to connect
channels that use different media (transceiver types). Routers attach to two channels and
route packets between them. They can be configured using one of four routing algorithms
that employ varying degrees of intelligence.
5.1.3.4 Routers versus Repeaters
Routers consist of a pair of Neurons and transceivers each watching a separate
(independent) channel. Each packet of data is received by the router and only re-
transmitted to the alternate channel if the router determines the target address of the
message requires that operation. Although routers introduce a 2.5 millisecond delay in
forwarding a message, the overall effect (on bandwidth) is negligible since the router
only transmits what needs to go across the junction.
5.1.3.5 How Learning Routers Work?
Learning routers are used to selectively route packets between two channels.
Initially, learning routers set their internal routing tables to indicate that all subnets exist
on either side of the router, but as messages are passed, they learn (and record) on which
side of the router subnets actually exist. Within a very short period of time the router
knows whether to pass messages or simply ignore them.
5.1.3.6 Learning Routers versus Configured Routers
When choosing between a learning router and a configured router, take into
account the following:
• The initial flood of traffic that occurs while a learning router is learning the
network may cause congestion problems.
• Network topology may include loops that prevent a learning router from
accurately learning the network. This is particularly common in power line and
RF networks.
• A learning router is always learning. It will update its internal routing table for
changes it finds in network topology.
• Learning routers do not learn about groups, but configured routers can be
configured to selectively forward group addressed packets.
5.1.4 LonWorks Network Interface
Standard network interfaces are available to support direct and remote connection
between a workstation running LonWorks-aware software and the LonWorks network.
The workstation connects to the LonWorks network (as a node) using an Echelon
LonTalk adapter, also known as an NSI (Network Services Interface), which is available
in a variety of form factors depending on the channel type used, the architecture of the
PC bus, and the functions that are to be performed by the PC.

5. LONTALK PROTOCOL
LonTalk is Echelon's open-architecture communications protocol that defines the
rules for communicating on a LonWorks network. The protocol follows the OSI
reference model developed by the International Standard Organization (ISO) and it uses
all seven layers of that model, as shown in Table 5-1.
6.1 Logical Addressing:
Since each Neuron ID is unique, it could be used as an address. But, such an
addressing scheme would support only one-to-one transactions (meaning no groups). To
simplify routing, the LonTalk protocol defines a hierarchical form of address to logically
address each node. In the process known as network management, software is used to
associate the node's unique 48-bit Neuron ID to a logical domain, subnet, and node
number.
The components of a logical address include:
• Domain—Nodes must be on the same domain to communicate, but if different
network applications exist on the same transmission medium, different domain
identifiers can be used to keep the applications separate.
• Subnet— The second level of addressing is the subnet. A subnet is a logical
grouping of up to 127 nodes from one or more channels. Each domain can have
up to 255 subnets.
• Node Address—Each node must have a unique node number on a subnet. Up to
127 nodes can exist on a subnet.
The transmission medium (channel) does not affect the way a node is logically
addressed. Domains can contain several channels as can subnets and groups.
6.1.1 Routing Messages
A router or bridge is a special purpose node that contains two Neuron chips and
transceivers, each connected to a separate channel.
 • A physical layer repeater is the simplest form of a router, merely forwarding all
packets it receives. Using a repeater, a subnet can exist across multiple channels.
• A bridge forwards messages for a given domain ID. Using a bridge, a subnet can
exist across multiple channels.
• A learning router monitors network traffic and learns the topology at the
domain/subnet level and it uses that knowledge to selectively route packets
between channels.
6.2 Communications Services
The LonTalk protocol offers four basic types of message service. The first two,
acknowledged and request/response, are end-to-end acknowledged and the other two,
repeated and unacknowledged, are unacknowledged. In addition to the LonTalk message
service options, the protocol offers a priority mechanism to improve response time for
critical messaging and authentication for security. System design should employ the most
effective use of network efficiency, response time, security, and reliability, but, generally
speaking, the LonTalk protocol defaults to that which provides the greatest level of safety
and verification for all network communications.
1. Acknowledged Service: The most reliable message service is acknowledged.
With this service, messages are sent to a node or a group of nodes, and individual
acknowledgements are expected from each receiving node.
2. Request/Response Service: The request/response service is as reliable as the
acknowledge service, in fact, it is the same as the acknowledged service, except a
response is sent rather than an acknowledgement.
3. Repeated Service: Also referred to as the unacknowledged/repeated service, this
service sends a message to a node or a group of nodes multiple times (n times at
intervals of m milliseconds) and expects no response.
4. Unacknowledged Service: The least reliable message service is
unacknowledged. With this service, the message is sent one time and no response
is expected. A timer, called the free buffer wait timer, is used to determine how
long the node waits for a free message buffer prior to sending its message.
6.3 Collision Detection:
All networking protocols use a media access control algorithm to allow devices to
determine when they can safely send a packet of data. These algorithms are designed to
reduce the number of collisions that occur when two or more nodes on the network
attempt to send data at the same time. Packets that collide cannot be successfully
delivered, which results in a delay in response time.
The LonTalk protocol implements a unique collision avoidance algorithm that
allows an overloaded channel to carry close to its maximum capacity, rather than have its
performance degrade due to excessive collisions. This is of particular importance when
the medium being used lends itself to collisions (for example, twisted pair). In such a
case, the LonTalk protocol:
• Optionally cancels transmission of a packet as soon as a collision is detected, and
• Waits a random period of time before attempting to retransmit.
6.4 Timers
There are several timers used with the LonWorks messaging service. Typically,
these timers are automatically configured by a network management tool. Also known as
layer 4 timers, these include:
• Free Buffer Wait Timer
• Transaction Timer
• Group and Non-Group Receive Timers
• Repeat Timer

6.4.1 Optional Priority:

The LonTalk protocol supports an optional priority messaging service that gives
priority messages earlier access to the transmission medium. The protocol allows the user
to allocate priority time slots on a channel dedicated to priority nodes and because there
is no contention for the medium during the priority portion of a packet cycle, those
packets realize improved response time over non-priority nodes.
6.4.2 Authentication:
Authentication is the process used to verify the integrity of a transmitted message.
Authentication is achieved by distributing 48-bit keys to the nodes at installation, with a
sender and receiver of an authenticated message both requiring the same key.
The authentication process includes the following steps:
1. A message requiring authentication is sent.
2. The receiving node challenges the sending node to provide authentication
information. Each time a challenge is made, the receiving node uses a random 64-
bit challenge number.
3. The sending node uses its authentication key and the data from the original
message to transform the challenge message, and then it responds. The receiving
node transforms the challenge message, as did the sending node. The receiving
node compares the result of its transformed message with the value received from
the sending node. If both match, the message is accepted.
4. The receiving node sends an acknowledgement to the sending node.

6. NETWORK MANAGEMENT TOOLS:

Network management defines the architecture of the LonWorks network,
including channels, routers, nodes, and more. During the network management process,
each device is queried and information about that device is recorded including its name,
program ID, Neuron ID, its network variables, and binding information. All of that
information is used to construct what is known as a network database.
Network management tools typically provide graphical, applications-oriented
views of the system and allow the user to develop control solutions in that environment.
This protects the user from the specific complexities of the underlying technology as they
design, commission, manage, and maintain LonWorks networks. Network management
tools often provide the following:
• Device programming
• Device installation and configuration
• Device monitoring and control
• General purpose support
7.1 System Overview:
The major functional areas of a LonWorks system include the following:
• Network database—A collection of information about the nodes that exist on the
network including name, Neuron ID, program ID, network image, and so on.
• Network management—The services that are needed to install and maintain
nodes on the network.
• Application programming—Software that is used to create Neuron-C code that
is loaded into a programmable device, which defines its control logic.
• User interface—Human/machine interface used to monitor and control
LonWorks devices.
• Network interface—That which provides connectivity for each node on the
network.
Figure 6-1 shows the relationship between these functional areas.

7.2 Structure of a Network Management Tool

Theoretically, the structure of a network management tool, regardless of
manufacturer is identical. This structure is represented in Figure 7-2 below.
Figure 7-2 Structure of a network management tool
7.2.1 Network Management Services
LonWorks network management services are a formal part of the LonTalk
protocol. Support for these services is contained in each LonWorks node. This guarantees
that all nodes, regardless of manufacturer, can respond to LonTalk commands from nodes
designed to perform network management functions. Network management functions
typically include:
1. Discovering new nodes as they are physically attached to the network.
2. Network configuration and commissioning of nodes.
3. Receiving service pin messages.
4. Importing node self-documentation and self-identification information.
5. Importing node external interface files.
6. Copying configuration network variable values from one node to another.
7. Installing, removing, and replacing nodes.
8. Connecting and disconnecting network variables and message tags.
9. Loading application images into nodes.
10. Querying and setting node properties, such as locations, priority slots, self-
documentation, and network variable attributes
11. Resetting, winking, and testing nodes

7.3 LonWorks Network Installation

The network installation process determines how each device will be ultimately
used in the system and establishes the relationships between it and other devices on the
network. Among the details defined for each device at installation time, a network
management tool tells a device what its logical address is, what type of internal
configuration the device has, where the device resides on the network, and with which
other devices it is required to talk.
7.4 Network Database
As a by-product of installation, network management tools create a network
database. The database contains comprehensive descriptions of all network devices
including channels, routers, nodes, network variables, binding information, and more.
Since an image of the network resides in each of the nodes, the network database may not
be needed for normal operation—nodes will continue to be able to share data. But, access
to the network database is necessary for network monitoring and control applications,
modification, and maintenance.
7.5 Application Programming
The programming language for LonWorks devices is Neuron-C. Most modern
LonWorks application programming tools provide a graphical development environment
that allows the user to create control strategies, compile that logic into Neuron-C, then
download it into programmable controllers on the network. LonWorks devices come in
varying degrees of programmability including:
Configurable Devices— These devices are application-specific, in that they come from
the manufacturer with an application, but require some degree of customization.
Programmable Devices—Also known as general purpose controllers, these devices
are provided with only the code that is necessary to enable I/O—actual control logic must
be created with a software tool.
Hybrid Devices—Hybrids are a mix between application-specific devices and general
purpose controllers. Echelon's Lampooned devices are examples of hybrids.

7. INTEROPERABILITY
8.1 Network Variables
Echelon defines a network variable as a data item that a particular device
application program expects to get from other devices on a network (an input network
variable) or expects to make available to other devices on a network (an output network
variable). Network variables can be any single data item, or they can be data structures.
Examples of network variables may include temperature, switch positions (binary), or
actuator position (analog). An example of a network variable that uses data structures is
SNVT_temp_setpt—this one variable contains 6 setpoints.

Network variable connections:

• Can create virtual wiring
• Can be deleted and added with a network management tool
• Can be changed without reprogramming the device
• Make adds, moves, and changes easy.
8.1.1 Network Variable Restrictions
There are some restrictions on network variable bindings (that is, only so many
bindings can be made in given situations).
• A Neuron-based node can have up to 62 network variables bound.
• A Hosted node can have up to 4096 by using a LonWorks network interface.
8.1.2 Standard Network Variable Types (SNVTs)
Every network variable is defined by a data type. Data type defines the units,
scaling, and structure of the data contained within a network variable. The LonMark
Association has defined and published definitions for at least 145 common data types
(version 10.00) including standard network variable types (SNVTs, pronounced “sniv-
its”). When programmers program Neuron chips using the Neuron-C programming
language, they declare inputs, variables, and outputs using SNVTs.
Alternatively, manufacturers can define their own user-defined network variable
types (UNVTs). SNVTs are expressed as either fixed-point numbers, floating-point
numbers, enumeration lists, or structures. For a complete listing of all the different
SNVTs, refer to the LonMark SNVT Master List document.

8.2 Explicit Messages

Applications that require a different data interpretation model then network
variables can send and receive explicit messages. Explicit messages use LonTalk
messaging services, but with minimal data interpretation. Each explicit message contains
a message code that can be used by the application to determine the type of data
contained in the message.
8.3 Applications
Every device must contain an application. Applications may be pre-configured at
the factory or downloaded (file extensions .APB and .NXE) in the field during
installation. The application determines the actual control algorithm that reads network
variable inputs, makes calculations based on some level of intelligence, and writes
network variable outputs.
Applications in LonWorks devices are divided into one or more functional blocks,
which are collections of network variables and configuration properties that perform a
common task. Network variables that exist in different devices pass data between nodes
using connections called bindings. To be connected, the network variables must be of the
same type, one must be an input, and the other must be an output. The process of
connecting network variables is known as binding.
8.4 Program IDs
A program ID is a unique identifier for the device functionality that is included in
a LonWorks device. Devices that have been certified by the LonMark Association
contain program IDs in a standard format that includes manufacturer, device
functionality, the transceiver type used, and documentation relating to the intended use of
the device. Program IDs are used by network management tools to identify nodes on the
LonWorks network.
Program IDs are 8-byte identifiers (for example: 80:0:C:50:5A:3:4:12) that
includes Format, Manufacturer ID, Device Class, Device Subclass, and Model Number.

8. RECENT APPLICATIONS
a. Buses in Italy Stop for LonWorks Networks
Brescia Trasporti SpA, the public transportation company for the Italian city of
Brescia, decided to improve its monitoring system to allow the immediate exchange of
data between buses, electronic bus stops, and a control center.

To monitor the bus network within the city of Bresica, Italy, Microlab Sistemi
srl implemented a flexible and expandable integrated solution based on Echelon’s
LonWorks technology. This new system consists of a meshed network, which connects
56 electronic bus stops. Each electronic bus stop is connected via existing twisted-pair
cable to central control center. Furthermore, each bus stop contains a special LonWorks
based CPU, integrated with a Neuron 150 chip and FTT-10 transciever.

Travelers Always Up to Date

Employees can send messages from any workstation at the central control center
directly to individual electronic bus stops and have them appear on displays located
inside each bus. These messages can be created by control center personnel using
simple text editors, or they can be automatically created by the Automatic Vehicle
Monitoring (AVM) system.

With a meshed network, messages are guaranteed to reach their correct

destination by exploiting alternative network routes. Both the electronic bus stops and
busses themselves are equipped with a 2.45 GHz short-range Low Power Device (LPD)
LonWorks transceivers so as to not interfere with other electric systems within the city.
These transceivers offer a 625 Kbits transfer-rate which allow data exchange between
the busses (mobile nodes) and the electric bus stops (fixed nodes) every time a bus
enters the 100 meter transceiver beam.
 Microlab Sistemi has also integrated LonWorks technology into various units
onboard the bus such as validating machines, consoles, information displays, odometers
and other individual sensors.

Problem-free Expansion
Connection between the various electronic bus stops has been obtained by using
existing twisted-pair cable. However, Microlab Sistemi needed to offer a future-proof
solution that would facilitate easy system expansion at a later date. In a city center it is
extremely difficult, if not impossible, to obtain excavation permission. Thus, installing
further twisted-pair cables would not be an option, as this would necessitate road works.

Key Benefits

• Integrated monitoring system enables more efficient bus service.

• Real-time monitoring allows immediate exchange of data between

busses, bus stops, and control center.

• Passengers get up-to-date status on service and journey

9. SUPPLIERS AND USERS

The principal suppliers of LonWorks networks are:

• Echelon Corporation. Development tools, smart transceivers, Neuron chips,

network management tools, support and training.
• Cypress Semiconductor and Toshiba. Neuron chips.
• Authorized Network Integrators. Specification, design, and installation of
LonWorks network solutions.

In addition, LonWorks developers worldwide supply everything from transceivers to

network management tools to end-user systems.

Companies that have adopted the LonWorks platform include:

• Most of the world's leading building automation system suppliers (such as

Honeywell, Johnson Controls, TAC, and Distech Controls)
 • Leaders in appliance, home, and building control (such as Samsung Electronics)
• Leading engineering firms (such as Teng and Associates)
• Transportation suppliers (such as Bombardier and Kawasaki)

In additional, many end user organizations require the LonWorks platform, including
the US Army Corps of Engineers and the New York CIty Public Schools District.

10. CONCLUSION
In Summary….

The simple way of installation and operation, the standardized by the Lonmark
organization network variables (SNVT's) the device templates, the wide choice of
communication channels and transceivers and the information which is freely spread for
the Lon technology make Lonworks the most interoperable protocol at the BMS sector
today. The Lon networks are sponsored as open networks and probably this is the best
way to describe the protocol itself.

Future plans for the BMS networks

All the big BMS manufactures such as Siemens, Johnson controls, TAC and
Honeywell have turned to Lonworks technology, a fact that ensure the future of
Lonworks as the interopable protocol of the BMS industry. Very close to the
development of lonworks we can relate the TCP/IP protocol which gave the opportunity
to all the computers in a network to communicate directly nomatter what operating
system or hardware they use. TCP/IP which was first brought to the computer market a
few years ago today has dominated the computer world and especially the internet which

is the largest computer network ever seen up to now.