LonSupport is a trademark of Echelon Corporation. Other brand and product names are trademarks or registered trademarks of their respective holders. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of Echelon Corporation. Copyright by Echelon Corporation. Definition of Terms
|Published (Last):||22 June 2019|
|PDF File Size:||14.15 Mb|
|ePub File Size:||4.47 Mb|
|Price:||Free* [*Free Regsitration Required]|
LonSupport is a trademark of Echelon Corporation. Other brand and product names are trademarks or registered trademarks of their respective holders. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of Echelon Corporation.
Copyright by Echelon Corporation. Definition of Terms Submitting a New Proposal C. Upgrading to the Version 3. A control network is any group of devices working in a peer-to-peer fashion to monitor sensors, control actuators, communicate reliably, manage network operation, and provide local and remote access to network data. This document provides application-layer layer 7 design guidelines, and also includes a glossary defining terms for the two volumes. Introduction 5.
Network devices are sometimes also called nodes. A device publishes information as instructed by the application that it is running. The applications on different devices are not synchronized, and it is possible that multiple devices may all try to communicate at the same time. Meaningful transfer of information between devices on a network, therefore, requires organization in the form of a set of rules and procedures.
The protocol defines the format of the messages being transmitted between devices and defines the actions expected when one device sends a message to another. The protocol implementation normally takes the form of embedded software or firmware code in each device on the network.
Applications in devices are divided into one or more functional blocks. A functional block performs a task by receiving configuration and operational data inputs, processing the data, and sending operational data outputs. A functional block may receive inputs from the network, from hardware attached to the device, or from other functional blocks on a device. A functional block may send outputs to the network, to hardware attached to the device, or to other functional blocks on the device.
The interface defined by the network inputs and outputs to the functional blocks on a device is called the device interface it is also called the application layer interface or the external interface. A network tool may upload the device interface definition from the device, or it may read the device interface definition from a standalone file called the device interface XIF file. In open multi vendor networks, the design of the device interface is vital to providing interoperability and easy integration.
Standardization of the device interfaces is an important element of designing for interoperability. The actual application software and hardware behind the interface is outside the scope of these guidelines. The purpose of the guidelines is to ensure interoperability, but not interchangeability of devices.
A major benefit to end users of interoperable devices is the freedom to choose among suppliers for the devices as well as for the maintenance of those devices. The ability to choose a specific device is provided by public device interfaces that describe the function of the device and how it exchanges information with other devices on a LONWORKS network.
The ability to choose among suppliers for system maintenance is realized by ensuring that interoperable devices do not require any private information to be successfully commissioned. The LONMARK logo is an indication to manufacturers, end users, and network integrators that a product can be easily linked with other products in a multi vendor network. If no casing is provided, the logo can be placed on a circuit board or equivalent.
The logo cannot be used without at least the 3. Figure 1. If the product does conform with the ISI protocol as described in 4. Figure 2. Related Documentation The following documents provide supplemental information to these guidelines. All documents listed here are available at unless noted otherwise.
Describes the content and structure of a device interface XIF file. Describes how to create, edit, and view resource files using the NodeBuilder Resource Editor. Available at types. Standard Program ID Reference spiddata. This file is used by development and network tools to simplify construction of standard program IDs.
This file is used by development and network tools for automatic validation and channeltype dependent calculations. Introduction 9. Device Interface Overview The device interface is the network visible interface to a device. Following is a summary of each of the elements that comprise an interoperable device interface: Neuron ID.
A number that uniquely identifies the device interface for a device. Device channel ID. A number that optionally specifies the channel to which the device is attached. Device location field.
A string or number that optionally specifies the device location. Device self documentation string. A string that specifies the functional blocks on a device. Device configuration properties. Configuration data used to configure the device. Functional blocks may also have configuration properties. Functional blocks. Logical components implemented on the device. With the exception of the Neuron ID, a network tool can read all of these elements directly from a device over the network, or from the device interface XIF file for the device as described in 2.
The benefit of making this information available directly from the device itself is that a network tool can read all of the information needed to integrate and manage the device over the network, and no accompanying manufacturer documentation is required.
The benefit of making this information available from a device information file is that the device may be designed into a network before physical access to the device is available. The latter method is typically used for engineered systems, but the former method is sometimes used when a device interface file is not available.
The device interface elements are described in the remainder of this chapter. It is also called the unique node ID. The Neuron ID is a unique number written to a Neuron Chip or Smart Transceiver when the chip is manufactured, or to other processors during development or manufacturing. Network tools use the Neuron ID to send network installation messages to a device, prior to the device being assigned a network address as described in 4. Guideline 2.
One copy should be removable so that an installer may place it on a system drawing, or similar plan. This can even be done using a barcode for ease and accuracy of Neuron ID input into a network tool. An example Neuron ID barcode label is shown in the following figure. Figure 3.
It uniquely identifies the device interface for a device. It is used by network tools to associate a device with a device interface definition. This speeds up the commissioning process by allowing a network tool to obtain the device interface definition without uploading the entire definition from every device.
The format must be 8 or 9, where format 8 is reserved for devices that have completed certification by the LONMARK International, and format 9 is used for all other devices. Format 9 must be used for devices that will not be certified, devices that will be certified but are still in development, and for devices that have not yet completed the certification process.
Device formats 0 2 and 0xA 0xF are reserved by Echelon for future use. Device formats 3 7 are used by network interfaces and legacy non interoperable devices and must not be used for other interoperable devices Manufacturer Field The Manufacturer field contains a 20 bit manufacturer ID MID.
The MID uniquely identifies the device manufacturer. Permanent MIDs are never reused or reassigned, but the manufacturer name may change if requested by the manufacturer as in the case of the manufacturer being acquired by another company. Temporary MIDs are available to anyone upon completing a simple form at They are not guaranteed to be unique, and they are not listed in the spiddata. This value is drawn from a registry of pre defined Device Class definitions.
A device may implement multiple functional blocks. One of these functional blocks may be designated as the primary functional block, and the definition of this functional block is called the primary functional profile.
If the primary functional profile number is greater than 99 and less than , the device class may be set to the profile number. Standard functional profiles are also given device classes equal to their functional profile number.
Please send your request for a device class to the certification address Usage Field The Usage field is a one byte value describing the intended usage of the device. These subfields are described in the following sections Changeable-Interface Flag The Changeable Interface flag is the msb of the Usage field. It must be set if the device uses changeable network variable types or dynamic network variables as described in The flag must be clear if the device uses a static device interface Functional Profile-Specific Flag The Functional Profile Specific flag is the second msb of the Usage field.
It must be set if the usage ID value is defined by the primary functional profile for the device. The flag must be clear if the usage ID value is defined by the standard usage ID values in the spiddata.
Based on the setting of the Functional Profile Specific flag, the usage ID is defined by one of the following: If the Functional Profile Specific flag is clear, the usage ID must be set to one of the standard usage ID values in the spiddata.
The standard channel type values are drawn from a registry of pre defined channel type definitions. To be certified, a device must include at least one node that is compatible with a channel type that has been approved for use in LONMARK devices.
A node within a device may include a transceiver for a channel type that has not been approved for use in LONMARK devices as long as the device incorporates an interface or router to a channel type that has been approved for use in LONMARK devices and as long as the device only communicates to devices outside of its physical enclosure on a LONMARK approved channel type.
In this case, the node with the non approved channel type must report its channel type as one of standard non approved channel types, if appropriate, or the Custom channel type if the node does not use one of the standard channel types listed in the spiddata.
Model numbers are assigned by the product manufacturer and must be unique within the device class, usage ID, and channel type for a manufacturer ID. The same hardware may be used for multiple model numbers depending on the program that is loaded into the hardware. The model number within the SPID does not have to conform to the manufacturer s marketing or engineering model numbers.
LONMARK Application-Layer Interoperability Guidelines
Provides detailed specifications on the electrical interfaces, mechanical interfaces, and operating environment characteristics for the FT Smart Transceiver and Neuron Processor. Provides information on all available standard enumeration types. Available from LonMark International. Provides information on all available standard network variable types SNVTs.
LonMark Application-Layer Interoperability Guidelines