História stránky

...

Example - a dump from trace file of a KOM process with the debug enabled:

  === ASN Body beg ===
  objectIdentifier (tag 0) OBJID 0 analog-input,10
  listOfResults (tag 1) SEQUENCE {
    propertyIdentifier (tag 2) ENUM 85 present-value
    propertyValue (tag 4) SEQUENCE {
     ENUM 1
    }
  }
  === ASN Body end ===
 

...

...

• Kotva
  requesttype requesttype

  Request type: Reading and writing of the object properties may be done in several ways:

  • Kotva
    readproperty readproperty

    ReadProperty - a periodical reading of object property as request-response. A polling period is configured on the Time parameters tab of station. The ReadProperty-Request message is used for the request and the ReadProperty-Ack message is the response from the device. The periodic reading burdens the network and is ineffective. That is why, if the device supports the sending of change data, we recommend you to use SubscribeCOV or SubscribeCOVProperty requests.
    The ReadProperty-Request message is sent if the Subscribe/read checkbox is checked.
  • ReadPropertyMultiple - the functionality is similar to the previous parameter. Unlike ReadProperty, more object properties are sent in one request/response, so communication is much more effective. The ReadPropertyMultiple-Request message is used for the request and the ReadPropertyMultiple-Ack message is the response from the device.
    The ReadPropertyMultiple-Request message is sent if the Subscribe/read checkbox is checked.
  • WriteProperty - the WriteProperty-Request message is used for writing the values. The Application tag parameter must be specified as well. If Subscribe/read is checked, the written value is verified by reading from the station using the ReadProperty-Request message after writing.

  • Kotva
    subscribecov subscribecov

    SubscribeCOV - activation of reading of object value when they change. If the Subscribe/read checkbox is checked, after starting, the KOM process sends the SubscribeCOV-Request message which asks the device to send information about the change of object value. You can specify whether the device will send the confirmed notifications (ConfirmedCOVNotification-Request message) or the unconfirmed ones (UnconfirmedCOVNotification-Request). The confirmed notification requires an explicit confirmation from the KOM (the BACnet-SimpleACK-PDU message), so puts more load on the network. However, the probability that the notification will be lost is lower than in case of using unconfirmed notifications (if the device does not receive a confirmation, it repeats the message).
    
    Note 1: Besides the dynamic registration by the SubscribeCOV-Request message, some devices can support also a static one (it is saved in the configuration). So the registration is not required and the checkbox Subscribe/read may be left unchecked.
    Note 2: The registration can be sent at regular intervals (e.g. because of a potential failure of the device power supply). You can set this interval on the station - the Resubscribe interval parameter.
    Note 3: SubscribeCOV-Request messages (and also SubscribeCOVProperty-Request messages, see the following point) are also sent after the connection with the station is re-established (after a failure or after switching from the StOFF state to the StOn).

  • Kotva
    subscribecovproperty subscribecovproperty

    SubscribeCOVProperty - the functionality is similar to SubscribeCOV. Moreover, you can specify the Property identifier (so you can monitor also the changes of other object properties than the present value) and Increment - a size of increment which causes the change to be sent (i.e. a dead band).
    The SubscribeCOVProperty-Request message is sent.
    
    Note: The Siemens PXC64-U device did not support the Increment parameter.

  • Kotva
    whois whois

    WhoIs - the identification message Who-Is-Request to detect the type of Device Object in a device. The I-Am-Request message is the response (it contains the iAmDeviceIdentifier, maxAPDULengthAccepted, segmentationSupported, and vendorID fields). If the I/O tag is TxtI, this information is extracted to the value of the I/O tag in a text form. After you identify the Device Object, you can configure the I/O tag for reading the property object-list of this Device Object. If the device implements this property, it returns the list of identifiers of all objects which it contains. Then you can query the properties of these objects (object-name, location, description, present-value ..)
    
    Note: For Siemens PXC64-U you must set the Array index and then read the property object-list. Array index=0 defines the number of array elements, Array index=1 up to N enables the access to the individual elements.

  • Kotva
    whohas whohas

    WhoHas - the identification message Who-Has-Request to detect the object name from the object identifier or vice versa. The response is the I-Have-Request message (it contains the fields deviceIdentifier, objectIdentifier, and objectName). The Who-Has-Request message is sent only once when initialization of I/O tag (or after the TELL command SETPTADDR). It is intended for the transfer between names and identifiers of objects.
    The message Who-Has-Request will contain either name or identifier of the object depending on whether the Address type has been configured as Name or Object type+Instance in I/O tag.
    If Subscribe/read is checked, you can use the information from the BACnet cache, which is much faster than detection from the communication.

  • Kotva
    readwritescheduler readwritescheduler

    ReadWriteScheduler - the ReadProperty-Request message is used for the request, the WriteProperty-Request message is used for write (it writes N time-value pairs). The configuration is used for the reading and writing of objects of schedule type, see the Scheduler in Siemens Desigo devices paragraph.

  • Kotva
    geteventinformation geteventinformation

    GetEventInformation: detection of objects that are in alarm or error state or they need to be acknowledged, see the section Information about events.

  • Kotva
    acknowledgealarm acknowledgealarm

    AcknowledgeAlarm: the acknowledgment of alarms that have been read by the GetEventInformation request. See the section Information about alarms. I/O tag must be the text output (TxtO).

• Kotva
  addresstype addresstype

  Address type: Each object in the BACnet protocol is addressed by an Object identifier. When designing the application in the Desigo system, the objects are represented by a name, but the object address is not accessible and can vary following the changes of application. On the other hand, the Delta Controls devices contain the objects whose addresses are defined by the author of the application. For this reason, there are two ways how to define the address of I/O tag which corresponds to two Address type:
  • Name: enter the object name. A type of object and instance number is queried dynamically from the communication. To avoid the overloading of communication lines when starting the KOM process, data is stored in a BACnet cache.
  • Object type + Instance: enter the type of object and an instance number. This is recommended for BACnet objects with constant addresses.
• Object type: type of objects, whose properties will be read/written. You can use the predefined types or write the number of a new type of object which has been defined by a producer. The type of object is a 10-bit number.
• Instance: an object identification number within the object type. Each object has a unique Object Identifier in the device, which is a pair [Object type, Instance].

• Kotva
  objectname objectname

  Object Name: name of the object, when Address type = Name, i.e. it means the I/O tag address [Object type, Instance], is detected dynamically from the communication. Object Name must be specified exactly, i.e. spaces in the beginning and at the end are not tolerated, and the upper and lower case letters must correspond to the object name that is stored in the BACnet device.
• Property type: type of property - only PropertyIdentifier is specified for Simple, and both PropertyIdentifier and Complex address must be specified for Complex. The complex type of property is necessary for the parsing of OEM-extended standard messages (items of 'Abstract Syntax & Notation' type). When sending the ReadProperty-Request, ReadPropertyMultiple-Request, SubscribeCOV-Request, and  SubscribeCOVProperty-Request messages, the Complex address is ignored.
• Property identifier: identifier of an object property. You can use the predefined properties or configure a numeric identifier of new property which was defined by the OEM manufacturer. The type of property identifier is Enumerated Value, the properties 0-511 are reserved for BACnet, the numbers from 512 to 4194303 can be used by the OEM manufacturer.
• Array index: some properties may be defined as arrays of values. In this case, a particular item of an array can be read or written.

• Kotva
  application_tag application_tag

  Application tag: it must be specified when writing the value (Request type=WriteProperty) and possibly for other types of requests if the parsed response contains context tags which application type is unknown because it is the extension of messages defined by the OEM manufacturer. The exception is an output tag of text type that is considered to be 'AnyTree', if the application tag is unspecified, and it can be used to write any user-specified ASN sequence.
  
  Note: If the value is Invalid, it is not written as the defined Application tag, but as Application tag "Null".

• Kotva
  complex_address complex_address

  Complex address: address of a tag in a 'tree' in connection with the extension of messages that have been defined by the OEM manufacturer.
  Example of address: [1].[3].2.1
  Description:
  [1] - context tag No.1 (it is assumed that it is the sequence),
  [3] - it is the context tag No. 3 in this sequence (again, it must be a sequence),
  2 - it is the second tag in order in this sequence (again, it must be a sequence),
  1 - it is the first tag in order in this sequence.
  The address in 'tree' starts from the propertyValue level (see the examples below). The easiest way to view the parsed message is to turn on debugging for a line and watch the debug info on the console or in the line log file.
  
  Example 1: Let's have a device that contains the object of type 2 (Analog Value) with instance number 1. Let's assume that the device sends the object value as a triplet of numbers. The first number is the current value, the second one is a one-minute average and the third one is a ten-minute average. The log of the parsed message could be the following:

  
   === ASN Body beg ===
   objectIdentifier (tag 0) OBJID 2 analog-value,1
   listOfResults (tag 1) SEQUENCE {
    propertyIdentifier (tag 2) ENUM 85 present-value
    propertyValue (tag 4) SEQUENCE {
     REAL 1.40000E+00
     REAL 1.10000E+00
     REAL 1.30000E+00
    }
   }
   === ASN Body end ===
  

  If you want all three values, you must configure three I/O tags (Object type=analog_value, Instance=1, Property-identifier=present-value, Property-type=complex), which differ in the complex address (for the first I/O tag specify 1, for the second one specify 2, and for the third one specify 3). Tick off the checkbox Subscribe/read in a configuration of one of these I/O tags only, because the response to one request is the message with three values. When sending the ReadProperty-Request, ReadPropertyMultiple-Request, SubscribeCOV-Request, SubscribeCOVProperty-Request, and WriteProperty-Request messages, the complex address is not used.
  
  Note: If you configure the I/O tag with Property-type=simple, its value would be set to the first found value after parsing the message (in the previous example it is 1.40000E+00).
  
  Example 2: Siemens Desigo PXC64-U contains I/O tag (Object type=schedule, Instance=6, Subscribe-read is checked, Property-identifier=weekly-schedule, Property-type=complex, Array index=1, Complex address=1). A debugging has been started on the line. After the I/O tag is saved, the KOM process sends the request and writes the response:

  
   === ASN Body beg ===
   objectIdentifier (tag 0) OBJID 17 schedule,6
   propertyIdentifier (tag 1) ENUM 123 weekly-schedule
   propertyArrayIndex (tag 2) UNSIGNED 1
   propertyValue (tag 3) SEQUENCE {
    SEQUENCE {
     TIME 0:0:0.0
     UNSIGNED 2
     TIME 4:0:0.0
     UNSIGNED 3
     TIME 22:0:0.0
     UNSIGNED 1
    }
   }
   === ASN Body end ===
  

  In propertyValue, there is the sequence of 6 values (time and positive number alternately). If you want to access the first time, you have to set Complex address=1.1, if to the first positive number, set Complex address=1.2. I.e. the first element - sequence - the second element in the order within it (UNSIGNED 2). If you need to access more times and/or values at the same time, you must configure several I/O tags and check the Subscribe/read checkbox in one of them only.
  
  Note 1: If the I/O tag was created with a complex address 1, its value would remain Unknown, because this address matches the 1st element in propertyValue, which is a sequence, not a simple type.
  
  

  Kotva
  pozn2 pozn2

  Note 2: The I/O tag of Text type is able to contain not only simple value but also any ASN sequence. The values are written according to rules for the writing of ASN sequence. If you set Complex address=1 and change the I/O tag to text input or text output in the previous example, its value will be a string " T0:0:0.0; u2; T4:0:0.0; u3; T22:0:0.0; u1; ". If Property-type=complex, but Complex address is not defined, the value will be "0{ T0:0:0.0; u2; T4:0:0.0; u3; T22:0:0.0; u1; }".
• Increment: increment of value change in the object property which causes the reporting of a change (see SubscribeCOVProperty).
• Confirmed: the checkbox specifies whether the device should send the confirmed notifications (ConfirmedCOVNotification-Request) or unconfirmed one (UnconfirmedCOVNotification-Request) for the configured Request types SubscribeCOV and SubscribeCOVProperty.

• Kotva
  subscriberead subscriberead

  Subscribe/read: if the checkbox is ticked, the respective messages for reading/registration of value changes are sent for the configured Request types:
  ReadProperty: the ReadProperty-Request message
  ReadPropertyMultiple: the ReadPropertyMultiple-Request message
  SubscribeCOV: the SubscribeCOV-Request message 
  SubscribeCOVProperty: the SubscribeCOVProperty-Request message 
  ReadWriteScheduler: the ReadProperty-Request message

...

Note: If the Application tag is not configured properly (for the binary value it is Enum), the Desigo station returns an error 'invalid-data-type' when attempting to write:

  error-class ENUM 2 property
  error-code ENUM 9 invalid-data-type	

...

Using the string "0{ 0D2.10.2005 } 2{ T1:0:0; u1; T12:0:0; u3 } 3u10" you can write the time schedule for the day October 2, 2005. The scheduler has the value 1 since 1:0:0, the value 3 since 12:00:00. The priority of the exception-schedule is 10. When reading a value after writing (Subscribe/Read was configured) with the activated debug on the line, you can see the following log:

 === ASN Body beg ===
 objectIdentifier (tag 0) OBJID 17 schedule,6
 propertyIdentifier (tag 1) ENUM 38 exception-schedule
 propertyValue (tag 3) SEQUENCE 3 {
  readResult (tag 0) SEQUENCE 0 {
   date (tag 0) DATE 2.10.2005 NoDay
  }
  listOfTimeValues (tag 2) SEQUENCE 2 {
   time TIME 1:0:0.0
   value UNSIGNED 1
   time TIME 12:0:0.0
   value UNSIGNED 3
  }
  eventPriority (tag 3) UNSIGNED 10
 }
 === ASN Body end ===

...

At the end of the list, there is the moreEvents attribute that is non zero if the list of events is incomplete (e.g. the exceeding of the maximum length of the message, etc.). In this case, you must reconfigure the I/O tag and set Object type and Instance to the last object in the list. It causes the generation of a new GetEventInformation-Ack message.

Example of GetEventInformation-Ack response:

 === ASN Body beg ===
 listOfEventSummaries (tag 0) SEQUENCE 0 {
  objectIdentifier (tag 0) OBJID 0 analog-input,1
  event-state (tag 1) ENUM 3 high-limit
  acknowledgedTransitions (tag 2) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
  eventTimeStamps (tag 3) SEQUENCE 3 {
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 9.11.2005 Wed
    time TIME 13:28:49.0
   }
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 9.11.2005 Wed
    time TIME 13:25:59.0
   }
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 9.11.2005 Wed
    time TIME 13:25:56.0
   }
  }
  notifyType (tag 4) ENUM 0 alarm
  eventEnable (tag 5) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
  eventPriorities (tag 6) SEQUENCE 6 {
   eventPriority UNSIGNED 3
   eventPriority UNSIGNED 3
   eventPriority UNSIGNED 7
  }
  objectIdentifier (tag 0) OBJID 214,1
  event-state (tag 1) ENUM 2 offnormal
  acknowledgedTransitions (tag 2) BITSTRING 0,1,0 to-offnormal(0),to-fault(1),to-normal(2)
  eventTimeStamps (tag 3) SEQUENCE 3 {
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 18.11.2005 Fri
    time TIME 12:52:11.0
   }
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 18.11.2005 Fri
    time TIME 11:16:23.0
   }
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 9.11.2005 Wed
    time TIME 12:23:58.0
   }
  }
  notifyType (tag 4) ENUM 0 alarm
  eventEnable (tag 5) BITSTRING 0,0,0 to-offnormal(0),to-fault(1),to-normal(2)
  eventPriorities (tag 6) SEQUENCE 6 {
   eventPriority UNSIGNED 3
   eventPriority UNSIGNED 3
   eventPriority UNSIGNED 7
  }
 }
 moreEvents (tag 1) BOOLEAN FALSE
 === ASN Body end ===    

...

You can acknowledge the events and alarms, whose list has been received by the GetEventInformation request. According to the BACnet protocol, the format of this request is (the record in ASN.1 syntax):

  *********************** Confirmed Alarm and Event Services ******************
  AcknowledgeAlarm-Request ::= SEQUENCE {
    acknowledgingProcessIdentifier [0] Unsigned32,
    eventObjectIdentifier [1] BACnetObjectIdentifier,
    eventStateAcknowledged [2] BACnetEventState,
    timeStamp [3] BACnetTimeStamp,
    acknowledgmentSource [4] CharacterString,
    timeOfAcknowledgment [5] BACnetTimeStamp
  }

For a more detailed description of the parameters, see the literature.
The acknowledgment is executed by the writing of the above-mentioned sequence to the text of the output I/O tag according to the rules of writing of any ASN sequence.

Example: The following list of alarms and events was read using the GetEventInformation request:

   ===  ASN Body beg ===
   listOfEventSummaries (tag 0) SEQUENCE 0 {
    objectIdentifier (tag 0) OBJID 0 analog-input,1
    event-state (tag 1) ENUM 4 low-limit
    acknowledgedTransitions (tag 2) BITSTRING 0,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventTimeStamps (tag 3) SEQUENCE 3 {
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 11:54:23.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:4:37.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 11:54:23.0
     }
    }
    notifyType (tag 4) ENUM 0 alarm
    eventEnable (tag 5) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventPriorities (tag 6) SEQUENCE 6 {
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 7
    }
    objectIdentifier (tag 0) OBJID 0 analog-input,2
    event-state (tag 1) ENUM 3 high-limit
    acknowledgedTransitions (tag 2) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventTimeStamps (tag 3) SEQUENCE 3 {
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:41:59.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:12:20.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:12:21.0
     }
    }
    notifyType (tag 4) ENUM 0 alarm
    eventEnable (tag 5) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventPriorities (tag 6) SEQUENCE 6 {
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 7
    }
    objectIdentifier (tag 0) OBJID 214,1
    event-state (tag 1) ENUM 2 offnormal
    acknowledgedTransitions (tag 2) BITSTRING 0,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventTimeStamps (tag 3) SEQUENCE 3 {
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 11:54:23.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:12:20.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:12:21.0
     }
    }
    notifyType (tag 4) ENUM 0 alarm
    eventEnable (tag 5) BITSTRING 0,0,0 to-offnormal(0),to-fault(1),to-normal(2)
    eventPriorities (tag 6) SEQUENCE 6 {
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 7
    }
   }
   moreEvents (tag 1) BOOLEAN FALSE   === ASN Body end === 

...