LONWorks & BACnet

Описание LONWork
реализация BACstack C#

What makes The Neuron Chip so different?
The Neuron chip is the heart of almost all LonWorks based devices. The Neurons contains the entire LonTalk protocol stack and is comprised of multiple CPUs, communications port, memory, firmware, operating system and I/Os. The Neuron chip is a complete system on a chip.

There are two basic types of Neuron chips

  • TMPN3120FE3MG (
    TMPN3120AM, TMPN3120B1M, TMPN3120B1AM, TMPN3120FE1M, TMPN3120A20M, TMPN3120E3M, TMPN3120FE3M,
    TMPN3120FE5M)
  • TMPN3150B1AFG  (TMPN3150AF, TMPN3150BF, TMPN3150B1F, TMPN3150B1AF)
  • TMPN5000 is combined with inexpensive serial memory, 5000 processor provides a low cost, high-performance LONWORKS solution than those based on previous-generation Neuron 3120 and Neuron 3150 chips.

How Does the Neuron chip connect To a Network?
The Neuron Processor comes with versatile 5-pin communications port that can be configured in two ways:

1) 3.3 V Single-Ended Mode
2) 3.3 V Special- Purpose Mode.

In Single-Ended Mode

  • Pin CP0 is used for receiving serial data
  • Pin CP1 for transmitting serial data
  • Pin CP2 for enabling an external transmitter

Data is communicated using Differential Manchester encoding.

 In Special-Purpose Mode

  • Pin CP0 is used for receiving serial data
  • Pin CP1 for transmitting serial data
  • Pin CP2 transmits a bit clock
  • Pin CP4 transmits a frame clock for use by an external intelligent transceiver.

In this mode, the external transceiver is responsible for encoding and decoding the data stream.

Any 3.3V transceiver or a 5V transceiver with TTL-compatible inputs can be used with the Neuron Processor because the communications port has pins that are 5V tolerant and drive a 3.3V signal. Common transceiver types that can be used with a Neuron Processor include twisted-pair, RF, IR, fiber-optic, and coaxial.

What Is The Neuron ID?

Neuron chips each have an exclusive 48-bit Neuron ID; this is comparable to the MAC ID in Ethernet. Echelon manages those numbers to insure uniqueness. Communications is instigated using the Neuron ID and then logical address assignments are made for the application.

What is LonTalk?

The LonTalk protocol is the core technology providing an executed, corrected, sustained, and proven protocol. It implements full functionality of the 7 layer OSI protocol standard. 

 

 Layer 6,7: Application & Presentation Layers Application:
 Network variable exchange,
 Application-specific RPC etc. 
 Layer 5 :  Session Layer
Request-response service
 Layer 4 :  Transport Layer
Acknowledged and unacknowledged unicast and multicast

Authentication
server
 Layer 3 :  Network Layer
Connection-less, domain-wide broadcast, no segmentation,
Loop free topology, learning routers
 Layer 2 :  Link Layer
Framing, Data encoding,CRC Error checking

MAC Sub layer
Predictive p-persistent – CSMA collision avoidance:
Optional priority and collision detection
 Layer 1 :  Physical Layer
Multiple media, Medium specific protocols (e.g. spread-spectrum)

What are SNVTs?
The use of Standard Network Variable Types (SNVTs, pronounced «snivets») contributes to the interoperability of LONWORKS products from different manufacturers. Echelon maintains a growing list of over 100 SNVTs for nearly all physical measurement types including the type of variable such as integer or floating point. For example, a SNVT for continuous level is defined as SNVT_lev_contin.

Download the Lonworks SNVT Mater list

If all manufacturers use this variable type in their application when a network variable for continuous level is defined, any device reading a continuous level can communicate with other devices on the network that may be using the variable as a sensor output to initiate an actuator. As long as a network input variable and a network output variable are defined with the same SNVT when the developer creates the applications, they can be connected together on the network through a process called binding.

When you install a node, you specify which network variables are to be connected between nodes. This is easily done by highlighting the output network variable on one node and the input network variable on the node or nodes to be connected. Only network variables of the same SNVT type can be bound together. In other words, a temperature type could not be bound to a pressure type.

 What does LonWorks have for Security?

The LonTalk protocol does not implement data encryption but it does implement Sender Authentication. While mathematically similar, they provide different protection. Data encryption is commonly used to hide data. Your checking account balance is an example of encrypted data. Sender Authentication is used for verifying that the sender of a message is an authorized sender. Let’s examine the home utility meter as an example. The utility would like to be able to update the utility pricing rates within the meter by sending a message to the meter with the new pricing schedules. The meter receives the new data, but how does it really know that the new schedules came from an authorized source (in this case the utility)? The utility doesn’t want to hide the data, because other devices within the home can make use of the pricing schedules to more efficiently run the house. But they do not want just anyone being able to change the pricing rates so they use Sender Authentication.

The way it works is that the utility places a unique 48-bit key in the meter — an authentication key. This is not the same as the 48-bit Neuron ID. The authentication key cannot be read out of the Neuron and cannot be changed without already having the key. Once the key is in place and the utility sends the update-pricing message, the meter now sees an Authenticated message. The meter responds to the Authenticated message by sending back a challenge with a 64 bit random number. The sending device receives the random number and performs an authentication transform on it and returns the transform back to the meter. The meter performs the same transform and if it matches the response from the utility, then the «update pricing» message will be processed.

At no time is the authentication key transmitted in this exchange. A spy on the network would see the pricing schedule, followed by a 64 bit random number, followed by a transform. Mathematically, given the random number and the transform, it is virtually impossible to determine the key.

While this authentication mechanism is very secure, it should be used judiciously since it does double the amount of traffic for each authenticated message.

 

Физическая реализация Toshiba TMPN3150B1AFG
(Siemens PXC64-U)

IMG_0320 IMG_0226_cr

Справочная информация

   
Типы стандартных сетевых переменных (SNVT) SNVT
Типы стандартных конфигурационных свойств (SCPT)  
Toshiba Neuron Data book
Power-Line-31xx-Smart-Transceiver-datasheet
 Neuron 5000 processor
NEURON CHIP Distributed Communications and Control Processors
LON&LAN networks connection based on neuron chip
 Parallel I/O Interface to the Neuron Chip

 

http://karl.hiramoto.org/lonworks4linux/ 

 

Function code

The function code (FC) in the telegram header identifies the telegram type, such as Request telegram (Request or Send/Request) and Acknowledgement or Response telegram (Acknowledgement frame, Response frame). In addition the function code contains the actual transmission function and control information that prevent loss and duplication of messages, or the station type with FDL status.

7 6 5 4 3 2 1 0 FC: Function Code Request
  1             Request Telegramm
      X         FCV = Alternating bit switched on
    X           href=»http://profibus.felser.ch/en/funktionscode.htm#aufruffolgebit»>FCB = Alternating bit (from frame count)
1       0 (0x0) CV = Clock Value (Clock synchronization)
1       other Reserved
0       0 (0x0) TE = Time Event (Clock synchronization)
0       3 (0x3) SDA_LOW = Send Data Acknowledged — low priority
0       4 (0x4) SDN_LOW = Send Data Not acknowledged — low priority
0       5 (0x5) SDA_HIGH = Send Data Acknowledged — high priority
0       6 (0x6) SDN_HIGH = Send Data Not acknowledged
0       7 (0x7) MSRD = Send Request Data with Multicast Reply
0       9 (0x9) Request FDL Status
0       12(0xC) SRD low = Send and Request Data
0       13(0xD) SRD high = Send and Request Data
0       14(0xE) Request Ident with reply
0       15 (0xF) Request LSAP Status with reply 1)
0       other Reserved

1) this value is in the last version of the standard not defined anymore but only reserved

7 6 5 4 3 2 1 0 FC : Function Code Response
  0             Response telegram
0               Reserved
    0 0         Slave
    0 1         Master not ready
    1 0         Master ready, without token
    1 1         Master ready, in token ring
        0 (0x0) OK
        1 (0x1) UE = User Error
        2 (0x2) RR = No resources
        3 (0x3) RS = SAP not enabled
        8 (0x8) DL = Data Low (normal case with DP)
        9 (0x9) NR = No response data ready
        10(0xA) DH = Data High (DP diagnosis pending)
        12(0xC) RDL = Data not received and Data Low
        13(0xD) RDH = Data not received and Data High
        other Reserved

Frame Count Bit The frame count bit FCB (b5) prevents message duplication by the acknowledging or responding station(responder) and any loss by the calling station (initiator). Excluded from this are requests without acknowledgement (SDN) and FDL Status, Ident and LSAP Status requests.

For the security sequence, the initiator must carry an FCB for each responder. When a Request telegram (Request or Send/Request) is sent to a responder for the first time, or if it is re-sent to a responder currently marked as non-operational, the FCB must be set as defined in the responder. The initiator achieves this in a Request telegram with FCV=0 and FCB=1. The responder must assess a telegram of this kind as the first message cycle and store the FCB=1 together with the initiator’s address (SA) (see following table). This message cycle will not be repeated by the initiator. In subsequent Request telegrams to the same responder, the initiator must set FCV=1 and change the FCB with each new Request telegram. Any responder that receives a Request telegram addressed to it with FCV=1 must evaluate the FCB. If the FCB has changed when compared with the last Request telegram from the same initiator (same SA), this is valid confirmation that the preceding message cycle was concluded properly. If the Request telegram originates from a different initiator (different SA), evaluation of the FCB is no longer necessary. In both cases, the responder must save the FCB with the source SA until receipt of a new telegram addressed to it. In the case of a lost or impaired acknowledgement or response telegram, the FCB must not be changed by the initiator in the request retry: this will indicate that the previous message cycle was faulty. If the responder receives a Request telegram with FCV=1 and the same FCB as the last Request telegram from the same initiator (same SA), this will indicate a request retry. The responder must in turn retransmit the acknowledgement or response telegram held in readiness. Until the above-mentioned confirmation or receipt of a telegram with a different address (SA or DA) that is not acknowledged (Send Data with No Acknowledge, SDN) the responder must hold the last acknowledgement or response telegram in readiness for any possible request retry. In the case of Request telegrams that are not acknowledged and with Request FDL Status, Ident, and LSAP Status, FCV=0 and FCB=0; evaluation by the responder is no longer necessary.

b5 b4 Bit position
FCB FCV Condition Meaning Action
0 0 DA = TS/127 Request without acknowledgement
Request FDL Status/ Ident/ LSAP Status
Delete last acknowledgement
0/1 0/1 DA # TS Request to another responder Delete last acknowledgement / response
1 0 DA = TS First request FCBM := 1
SAM := SA
Delete last acknowledgement / response
0/1 1 DA = TS
SA = SAM
FCB # FCBM
New Request Delete last acknowledgement / response
FCBM := FCB
Hold acknowledgement / response in readiness for retry
0/1 1 DA = TS
SA = SAM
FCB = FCBM
Retry Request FCBM := FCB
Repeat acknowledgement / response and continue to hold in readiness
0/1 1 DA = TS
SA # SAM
New initiator FCBM := FCB
SAM := SA Hold acknowledgement / response in readiness for retry

FCBM stored FCB in memory SAM stored SA in memory

×

Length information

The two equivalent length bytes in the telegram header of the variable format contain the number of information bytes in the body of the telegram. These include: DA, SA, FC and the PDU. The value ranges from 4 to 249, so that no more than 246 bytes can be transferred to the PDU of a telegram. No value <4 is allowed, because a telegram must comprise at least one DA, SA ,FC and a data byte. The longest telegram therefore comprises 255 bytes overall.

7 6 5 4 3 2 1 0 LE and LEr: length byte
4  to 249 Length byte
×

Checksum

The FCS (Frame Check Sequence) checksum required in the telegram for Hamming distance 4 is always located directly in front of the end delimiter (ED) and has the following configuration:

7 6 5 4 3 2 1 0  
0 to 255 Checksum

For the without-data format (SD1) the checksum must be formed by the arithmetical sum of DA, SA, and FC without start delimiter (SD) or end delimiter (ED) and disregarding sums carried over. For the fixed length format with data (SD3) and the variable length format (SD2) the checksum must also include the payload (PDU). Example of bytes added together in the FCS:

SD2 LE LEr SD2 DA SA FC DSAP SSAP PDU FCS ED

See also the section on Error handling.

×

In the PROFIBUS DP-V2 version clocks in a PROFIBUS network can also be synchronized. For this purpose, a station is defined as the time master which then distributes the time within its network. This time master must be a master and is designated as a class 3 master.

Clock synchronization

Clock synchronization

The time master reads its current time and starts an internal timer. As soon as the time event (TE) telegram (see FC: Function Code Request) is sent with the read time, this internal time is stopped. In a subsequent  counter value (CV) telegram, the time difference between the read time and the sent time is transmitted.

 

On receipt of the TE telegram, the receiving station also starts its own internal timer. The value of this internal timer plus the current value from the TE telegram and the correction value from the counter value (CV) telegram give the time to be set.

Sequence of telegrams for clock synchronization

Sequence of telegrams for clock  synchronization

 

This clock synchronization service must always require the support of hardware to start and stop the timers. Not all modules (ASIC) available on the market can support this service.

×

Address byte

The two address bytes in the telegram header of telegrams (Request, Confirmation and Response telegrams) contain the station’s destination address (DA) and source address (SA).

7 6 5 4 3 2 1 0 DA: Destination address
  0 — 127 (0x7F) Destination address
0
1
              no DSAP (SAP = NIL)
DSAP present
7 6 5 4 3 2 1 0 SA : Source address
  0 – 126 (0x7E) Source address
0
1
              no SSAP (SAP = NIL)
SSAP present

Address 127 is reserved as a global address for broadcast or multicast messages (telegrams to all bus users or user groups selected via service access point; only allowed with Send Data with No Acknowledge, SDN). The address byte of the Request telegram should be reflected in the Response telegram in reverse, i.e. the SA byte of the Response telegram contains the destination station address and the DA byte the source station address of the Request. For formats with a PDU, the address extension serves to identify a destination and/or source address extension in the form of a Service Access Point (SAP) that immediately follows the FC byte in the PDU. The address extensions of a Request telegram must be reflected in the Response telegram in reverse. If the address extension bit has not been set, it is the special SAP = NIL. This Service Access Point has the advantage that its telegram is 2 bytes shorter and is therefore used for cyclic data exchange.

×