Configuration Module

Overview

The Configuration Module configures the CSP. You should design your Configuration Module with enough flexibility to reconfigure the entire CSP, as well as a single card. The module should also be able to take groups of channels in and out of service. The configuration script file contains ideas on how to organize a CSP configuration.

Your Configuration Module should be designed to receive information about the state of the CSP from the Communication Module. If the CSP has just been turned on, your Configuration Module must configure the entire CSP. The Configuration Module does not need to do anything if the CSP resets and sends a Card Status Report indicating that the battery-backed configuration is valid (see the Card Status field).

After it configures a card, the Configuration Module can use the Tag Configuration message to tag a configuration with a number. The Card Status Report message also returns a configuration tag. Design your host application to detect the presence of previously-configured tags. If previously configured tags are present, the host does not need to reconfigure the card.

Important! Always send the Tag Configuration message last. For a list of messages that reset the tag configuration, see the Tag Configuration message in the API Reference. Any configuration message (other than the Tag Configuration message) sent to a card initializes the card’s configuration tag to 0 (zero).

When you need to clear the configuration, use the Reset Configuration message in your Configuration Module. This message allows the host to initialize configuration of a line card (a card in slots 0x00 through 0x0F) or the entire CSP. In a redundant CSP, sending a Reset Configuration message to initialize the entire CSP causes a switchover to occur.

You should design your application for dynamic deconfiguration and reconfiguration. Provide for such changes as the following:

• Incremental configuration

• Adding facilities

• Changing the existing configuration

Host Connection Configuration

As the client in the client/server model, the host must maintain the connection. The host can issue any number of requests to connect and disconnect. The CSP services each connection request instantaneously. But because each Matrix Controller card supports only one connection to one host, each additional connect request overrides the previous connection. To establish the connection, the host sends a Connect message that specifies a port number of 0x3142, along with the IP address that was configured when the Matrix Controller card was turned on. You can encounter the following scenarios when disconnections occur both gracefully and ungracefully:

Graceful Disconnection

In the CSP, a server task runs continuously so that, it is always ready to send an Accept message as soon as it receives a connect request. If the host crashes and is unable to issue a Close message, it must issue a new connect request when it returns to service. The CSP instantly accepts this connect request.

Ungraceful Disconnection

The CSP software issues a Close message on a socket only if it detects that the socket has been closed by the host. The host software must have a strategy for handling connections that are broken by the CSP. Before sending the Receive message, the host should send a Select message on the receive socket descriptor, with a time-out value that is slightly greater than the poll rate. If the host is alerted of a timeout, it assumes that the CSP has broken the connection. The host must adjust the socket descriptors and issue a new Connect request.