Страница 6: ДСТУ CLC/TS 50136-9:2014. Alarm systems - Alarm transmission systems and equipment - Part 9: Requirements for common protocol for alarm transmission using the Internet protocol (62644)

Annex E
(informative)

Examples of application protocols

E.1 SIA

The following SIA blocks should be present into an alarm message with the SIA protocol identifier:

- # Account block;

N New event block; or

О Old event block.

Additionally the message may contain the following block:

A ASCII text

If the combination: #N, #0, #NA, #OA is present in the alarm message, the message will be acknowledged by the receiver. The message header byte and the column parity will NOT be included in the SIA message format to the RCT, the message is already validated at the SPT side and the integrity of the message is guaranteed by the hash.

Other block like: & (origin), L (listen in), X (extended), @ (configuration) etc may (in addition to the above mentioned blocks) exists in the message but will not necessarily be processed by the receiver.

Blocks will be separated by a ']’ sign. Thus a valid message will look like:

#1234|NCL001 |ACenelecMember

#1234|OBA012|AFrontdoor

All modifiers and textual additions as specified in SIA DC-03-1990.01 (R2003.10) may occur in the event block.

E.2 Ademco Contact ID

The Ademco Contact ID messages, sometimes called POINT ID, have the following layout between SPT and RCT:

AAAAMTQXYZGGCCC

where

AAAA Account code [4...6] digits;

MT Message type (18 or 98);

Q Qualifier, value 1, 3 or 6;

XYZ Event code;

GG Group number;

CCC Zone number.

The RCT shall check if the length of the message is within range: [15... 17] and the MT equals 18 or 98. The account code shall be 4 digits long minimum and 6 digits maximum.

Account code digits shall be in the range [ ‘O’...’9’ ] (0x30...0x39). Message type and Qualifier have fixed values as defined above. All other digits shall be in the range: [‘O’...’9’ + ‘B’...’F’]

The checksum value shall NOT be present in the message.

EXAMPLE 123418113101015

Account 1234 is reporting a Perimeter Burglary Alarm on Zone 15 of Partition 1.

The length of the account code [4, 5, or 6 digits] will be determined by the total message size.

E.3 Scancom Fast Format

The Scancom Fast Format message can contain 8, 16 or 24 channels and also 1 up to 6 account digits. The correct format can be determined by the receiver just by checking the length of the received message size.

Layout of 8 channels scancom message:

AAAACCCCCCCCS

where

AAAA Account code;

C Status of the channel (values: 1,2,3, 4, 5, 6);

S System channel (values: 7, 8, 9).

The account code can vary between 1 ... 6 decimal digits.

The number of channels can be: 8, 16 or 24.

The system channel is always 1 digit.

The length of an 8 channels message then can be: 10 up to 15 digits.

The length of a 16 channels message then can be: 18 up to 23 digits.

The length of a 24 channels message then can be: 26 up to 31 digits.

All bytes shall be in the range: ‘0’ ... ‘9’.

The receiver will acknowledge the message if the size is expected (within the above values) and all bytes have the values in the correct range: ‘O’...’9’.

E.4 VdS 2465

The following Vds 2465 format should be used for alarm messages with the VdS 2465 protocol identifier.

The data field contains the VdS 2465 pay load data records. Further information are contained in VdS 2465, 8.1 „General record structure".

In the following example the information:

• input 1 is activated,

• type of message: general,

• equipment ID number 3456

were transmitted.

Annex F
(informative)

Design principles

F.1 General

This annex is added to clarify some of the principles used to design this protocol standard.

The reader of the standard should note that this standard is somewhat different from other European Standards dealing with different aspect of alarm transmission. This standard, unlike others, is intended to describe an exact design to achieve interoperability rather than to describe requirements for performance only.

F.2 Information Security

Information security is major concern when designing alarm transmission systems and equipment. The intention of this standard is to achieve high level of information security while keeping the implementation and use of compatible equipment as convenient as possible. Wherever possible, known and proven algorithms and methodology was chosen over new proprietary designs.

The commissioning phase is found to be the hardest part to design in a way that is secure and still practical. An absolute requirement there is to limit the effect of compromising one site to that site only. This is not the case in many other alarm transmission protocols working over IP.

F.3 Use of UDP signalling

UDP signalling was chosen as base to this protocol because it is available for almost any platform, and it allows much better control over the transmission than TCP. In alarm transmission it is important to be able to predict the behaviour of the communication stack as precisely as possible. This is achieved with the use of UDP.

At some later date one could consider use of SCTP for a later revision of this document, but as today it is not as commonly available for as many platforms as UDP.Bibliography

1. CLC/TS 50136-7, Alarm systems — Alarm transmission systems and equipment — Part 7: Application guidelines

2. RFC 958, Network Time Protocol (NTP)

3. RFC 1071, Computing the Internet Checksum

4. RFC 1191, Path MTU Discovery

5. RFC 4086, Randomness Requirements for Security

6. RFC 4330, Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI

7. RFC 6347, Datagram Transport Layer Security

8. X.509, ITU-T Recommendation X.509: Information technology— Open Systems Interconnection — The Directory: Public-key and attribute certificate frameworks