System integration - Implementation

See also:

• AlphaCom OPC Server
• VS-SDK for AlphaCom

The AlphaCom exchange is a very powerful tool for both complex audio switching, and as a system integration tool. In many cases the AlphaCom can control everything, call queuing,, CCTV, pagers, remote control outputs like door opening, technical alarm inputs etc.

In other cases the customer wants screen based system integration (e.g. a building management system) as a common user interface, and uses the AlphaCom as a subsystem.

Throughout this document the term “PC” is used when referencing to “the external computer system “.

Introduction

AlphaCom functionality for security systems

When the customer decides to have an audio system, the AlphaComs potential should be used. This means that door stations should have call (help) buttons, the guard workplace should have a Control Room Master station with queue display and answer possibility etc. The intercom stations will be very natural to use, and will also serve as a backup should the high-tech screen system fail.

The typical built-in AlphaCom features are:

• Call queuing: A substation push button will dial a Call Request dir.no, which puts the station into a Control Room station’s call queue (sorted on priority and arrival time). The substation gets an (optional) voice message, then ringing and LED flashing while waiting.
  

Note that Call Requests will arrive into the Control Room station’s queue independent of the use of the station - queuing will not be blocked e.g. by an on-going conversation.

• Conversation set-up: The Control Room master typically establishes out-going connections, either due to a previous Call Request (dial 7638 to answer first-in-queue), or on own initiative (keypad dialling or DAK key-press). An successful out-going connection will remove a possible Call Request from the called station.
  

Sometimes substations are set to fixed PRIVATE, so that incoming calls will not connect unless accepted by the person in the room. The Control Room station must then be set to high call priority, in which case it connects directly when answering Call Requests.

• Speech direction control: The AlphaCom operates normally in voice-switched duplex. Security systems often handle noisy areas, and the guard will often revert to simplex using the M-key while speaking.

• Remote Control: During connection, the guard can press digit 6 on his station to cause a Remote Control Output related to the other station to pulse for 5 sec., typically opening a door. (Actually any action is possible. e.g. sending a data command to PLC which controls digital I/O etc.)

• Park call in queue: If the guard needs to use the intercom station to assist the calling substation, it’s possible to dial a code 55(normally on a DAK key labelled PARK), which creates a call queue entry for the station. The Control Room station can then be used for other purposes, then the original call can be re-established by answering the queue again.

• Conversation cancel: A conversation is cancelled when one of the involved stations presses C-key (or goes on-hook). Substations often have no local cancel key, so they should normally be called back from a guard which then controls the operation.

• Special case: Cancel of queue entry without connection: In some situations a Call Request can be removed without conversation:

In a prison, when there is a call from the cell, a ward in the corridor will go directly to the cell without using the intercom. He can then cancel the call from a button placed outside the cell (either a DAK key, or a Remote Control Input RCI with a “cancel queue” action.

On a railway platform, a panel with an “Info” call key can have a “forget it” key also

Technical alarms which has no audio related to it can be removed by the input going inactive

The Control Room master also has the possibility to do “remove queue entry” by dialling 70 + 0. It can be a prisoner that does repeated calls just to pass time….

• Special case: Privacy ringing: In some simple Control Room applications it’s possible to let substations call the Control Room station directly. They should be configured in the AlphaCom so the incoming call is set up in PRIVATE, i.e. the station rings and the guard must accept the call. If a second substation attempts to call, it will queue up in Camp-On-Busy and eventually connect automatically when the Control Room station becomes free. Privacy ringing will terminate after a programmable time, or the guard may reject it by pressing the C-key.

The Mail system

In AlphaCom all stations can receive “mails”.

• Mails are generated by the Call Request feature, CallBack during connection, technical alarms, line error reports etc. All mails will be presented on a display station by dialling 70, then using digits 7 or 9 go scroll forward/backward through the queue. Some mails has a corresponding pre-recorded voice message, and some have an attached Call Back directory number which can be activated by dialling 8 while scrolling.

• The queues can have up to 1000 entries (in which case it’s the guard that’s in trouble, not the system!).

• Mails can be sent to groups of stations, which can be used to implement Control Room parallel servers. The mail sender determines if the mail is removed from all stations in the group if one answers it.

The Link Layers

AlphaCom offers several link layers which can be used when connection a PC.

• Start with the Simple Link Layer, which is a plain ASCII protocol without retransmissons etc. You can connect an ASCII terminal and type ahead, and you will receive messages from the exchange as they occur. It’s easy to try exchange features and see the exact responses.

Note: To get response messages back to the port, you must define at least one external device on this port. If several devices are set up on the port, the lowest device number will be used as default device number in commands where device number is not stated explicitly.

• Later you can upgrade the communication part of your software to a reliable transport protocol.

ISO 1745 is a half duplex protocol which is fairly slow, but OK for security systems.

Stentofon Link Layer is a sliding window protocol for high speed messaging. It’s also the most complex to implement!

To prepare your system to handle any link layer:

• Use binary representation of data protocol messages in your application.

• Your system should be constructed using parallel processes which communicate via message queues. There should be message queues between your application and the I/O drivers for AlphaCom (which runs the link layer). This way your application can send a number of messages without waiting for the AlphaCom, and the AlphaCom can send bursts of messages to you without loss.

• Your main application should not be blocked if the driver for the AlphaCom is not able to send messages to the AlphaCom (AlphaCom reset takes 60 seconds, or AlphaCom may be permanently dead). This may occur with all handshaked link layers, except Simple Link Layer which is “printer style”.

• Conversion to ASCII e.g. for Simple Link Layer takes place close to the serial port low-level drivers (interrupt ring buffers).

General considerations

Functional division between systems

From the description above:

• Try to let the AlphaCom do basic call queuing and conversation handling. It’s always very difficult to have two systems with internal states, and trying to keep them identical (sooner or later something will get out of synch). One thing is the large number of set-up/cancel features in the AlphaCom, another thing is delays in data protocol messages which means that status/command messages will cross each other.

• Think redundancy in case of equipment failure. If the AlphaCom should be able to do door opening on it’s own, maybe the PC should do door opening by sending commands to the AlphaCom rather than using a separate I/O system.

On broadcasts and addressed messages

The basic principle for the AlphaCom data protocol is addressed messages, which the received must acknowledge, else they will be retransmitted. This means that a PC primarily will receive only responses to actions which itself initiates.

Broadcast messages - overview

To allow external Call Handlers which monitors all stations in an exchange, some exchange events will be reported as broadcasts:

• Q_ELEM_ADDED, Q_ELEM_REMOVED

These is the result of mail insert/delete operations. For a Control Room station it may be only Call Request from stations, but in the general case it can be any mail.

• CONN_STATUS_BC, DISCON_STATUS_BC

These messages indic ate start and stop of a real conversation.

• ST_BUSY_BC, ST_FREE_BC

Simple station busy/free information. May be used on a screen to show which stations are currently being used. Intended primarily for logging of call statistics.

• CALL_STATUS_BC

A call progress message, most useful for statistics logging. In a simple system which relies on incoming private calls, CCTV could be switched on during the ringing by monitoring these messages.

• EXT_FEATURE_BC

Special feature: You can set up one or more directory numbers which does nothing in the exchange except sending out this broadcast message (the station cancels immediately). It’s then up to the PC to use this for any purpose. Example: A simple guard station which has CCTV monitors in front of it could send messages to the CCTV switch by dialling on it’s intercom keyboard.

AlphaNet considerations

Addressed messages:
You must address each message to the correct exchange by setting the destination node in the network layer header. The exchange will in general NOT route messages based on station directory numbers, even if the station is encoded as NET_OBJ_REF with correct node number (the exception messages are noted in the data protocol document, currently only CONN_REQUEST.).

The implication of this fact is that a system which communicate with a network of AlphaComs must store node numbers along with directory numbers, and this information must be used in an intelligent way when sending commands to the exchange.

Broadcast messages:
Broadcast messages are only broadcast in OWN exchange. In a network, a PC will only see AlphaNet Call Requests and Conversations involving (at least) one station in the AlphaCom which the PC is directly connected to.

The way around this is to use each exchange’s Event Handler. Here you can monitor events like “received mail” and “conversation - outgoing”. As action, send the data protocol messages the PC looks for (xxx_BC), addressed explicitly to the node/device of the PC.

Exchange features vs. DP messages

Exchange database

Directory numbers

Data protocol messages to/from PCs will in general refer to stations etc. as directory numbers. It’s possible to send commands to the exchange using physical addresses, but the responses will always be translated to dir.no.

The basic piece of information is:

• A station’s 4-digit directory number.

Note that the intercom system distinguishes “0123” from “123”, so you must store the numbers either as left adjusted text, or as the AlphaCom does internally as 4-bit BCD coded digits with trailing Fs for unused digits 0x123F (see the description of NET_OBJ_REF).

• In AlphaNet: also it’s node number.

The node number is an integer value 0 to 255 (byte).

Station names

When presenting intercom calls on a PC screen you probably want station names also. The broadcast messages does NOT contain name texts.

• The AlphaNet is normally maintained from one AlphaPro PC which stores information for all nodes in one database. The database is FoxPro, i.e. “xbase” format (*.dbf). It can be read easily using e.g. Microsoft Jet (Access, Visual Basic), or third-party C libraries. Here you will find node names (8 or 24 chars), and station names (12 chars).

• The PC can have it’s own name strings. Often the user wants more than 12 chars to describe the location, building, floor, …, and use of a station.

Handling the exchange via Data Protocol

Call queuing

The simplest variant is to let the PC monitor Q_ELEM_ADDED / Q_ELEM_REMOVED broadcasts. Even when using parallel servers, there will be one message per queuing station / PC. These messages can be used very much like any other “digital alarm” signal to a PC queue/map display.

Note that this message contains a “mail tag”. It’s possible to read out the intercom station’s call queue entry by entry (EXT_MAIL) based on the tags and GET_FIRST_MAIL/GET_NEXT_MAIL commands. For a pure intercom Call Handler this is nice, but for a PC monitoring all kinds of subsystems it’s probably just adding complexity.

Please consider reset/boot periods for the PC. Call requests activated while the PC is “off line” will not reach the PC’s call queue. It will still be presented on the intercom station’s display and may be answered from it (reading the station’s call queue once after reset may cure this problem!).

If the PC shall have a response action to a Call Request (action when Map clicked, or event list line selected), set up a conversation from the guard station to the substation. This will automatically clear the queue entry in the intercom system. (Note that the CONN_STATUS_BC message will probably arrive before the Q_ELEM_REMOVED!)

If the PC shall remove a queue entry in the intercom without conversation, use CANCEL_MAIL <dir.no> (alternatively DELETE_MAIL <tag>). Note that CANCEL_MAIL can be set up to delete more than one mail, so be careful!

Conversations

Start and stop of conversations is handled by monitoring CONN_STATUS_BC, DISCON_STATUS_BC broadcasts. They can be used e.g. to show active mode for a station on a map.

Setting up a conversation:

• Preferred variant: Use the message CALL_SETUP . (Require AMC 08.20 or newer)

Sets up a conversation like dialing from a station. Default behavior:

• A station is disconnected if busy

• Call can result in Private ringing, Absent, Busy or Transfer like a ordinary call

• The A station's call priority in NVRAM is used.

• No acknowledge messages are returned.

Adding optional parameters to the CALL_SETUP message can modify the default behaviour.

To cancel send a C_KEY message, alternatively DISCON_ST (AMC 08.20). DISCON_ST let you specify the disconnection tone.

Note that CALL_SETUP only work for conversation setup between intercom stations. To activate features like group call etc. DIAL_DIGITS must be used.

The CALL_SETUP is easier to use than the CONN_REQUEST message, and there are more options to control the call setup.

• Reliable variant: Use the message CONN_REQUEST.

It’s possible to set call priority both for the A and the B station in this message, e.g. to connect directly to stations normally set in PRIVATE.

The exchange responds with a CONN_REFERENCE, incl. a parameter “connection reference”. This reference must now be used for all further control of this conversation (NOT the directory number).

The PC must accept the conversation with CONN_REF_ACK, else it will be cancelled within a short time (alternatively, you can use an optional parameter to CONN_REQUEST which means that there is no need for an accept)

To cancel send a DISC_REQ (see the DP document on DISC_xxxx and DISCONNECT_xxxx) for details, alternatively send a C-key <dir.no>.

Note that the station can disconnect any time during this sequence, so you must monitor DISCONNECTED also, especially if you implement the full DISC_REQ protocol.

• Simple variant: Use the message DIAL_DIGITS.

This message causes no data protocol response from the exchange. If the user notices that nothing happens, he must try again!

If the PC has an on-screen “intercom keyboard” this message should be used.

It must also be used for any activation of intercom features like group calls etc.

Remote control (door opening)

The PC may use the AlphaCom’s built-in door opening feature.

Several ways:

• Simulate a door opening feature.

Send EVENT_REPORT to the substation which is related to a door. It’s normally sent to a B-subscriber during connection, but will work at any time. Door opening is event 2, sub-event 0.

The exchange times this feature, so it sends the corresponding OFF event after 5 seconds. A PC must either rely on a pulse-trigged door lock motor, or have an internal timer corresponding to the exchange (or rely on the PC user pressing a button as long as the door shall be open).

The advantage of a high-level approach like this is that it’s the destination exchange’s Event Handler that actually does the job, and if there should be additional actions they will work independent of the source of the door opening.

• Control the “logical RCO” output (general remote control, not “door open” specific).

Use SET_LOGICAL_RCO.

This is a low level control of a digital output, and the PC manipulates it’s state directly.

The logical RCO is mapped to a physical RCO by the exchange. It can be redefined in the exchange, to be either a RCO on a subscriber line board, or a RCO in a RIO bus device, and the PC need not know about this change.

• Control the physical RCO pin.

Use SET_RCO.

This requires the PC to run the “RIO” protocol for controlling low level hardware. Not recommended!

Acknowledgement messages

The AlphaCom uses functional ACK messages in most cases. That is, even if the data link layer transports messages error-free using retransmission etc., the intercom application sends/expects an ACK message in return when a message is received/executed successfully.

• In the beginning, a command XXXX would generate distinct XXXX_ACK - XXXX_NAK messages.

• Later on, as the number of messages grew, a general COMMAND_RESPONSE was introduced, holding both which message it’s a response to, and the success/failure as parameters.

• Some messages first introduced for AlphaNet has no ACK messages (to reduce signalling in AlphaNet). This is mainly “station simulation” messages like DIAL_DIGITS, M_KEY, C_KEY etc.

It’s sometimes possible to use secondary messages as a functional ACK, e.g. DIAL_DIGITS will eventually cause a CONN_STATUS_BC.