SBN Installation Acceptance Certificate
Site acceptance of an SBN installation proves two things: signals travel from the concentrator to the Alarm Queue without loss, and delivery continues when any one redundant component fails. Blank cells are filled in on the day of testing.
Installation details
| Item | Value |
|---|---|
| Customer (name, company #) | |
| Contract or SR reference | |
| Site / address | |
| SBN version (client and FrontEnd) | |
| SQL schema version | |
| Database platform | |
| Cluster nodes (Windows Server Failover Cluster) | |
| Cluster name and clustered roles | |
| Concentrator pair IDs (primary NN / backup NN+10) | |
| Concentrator hosts | |
| FrontEnd hosts (host1 / host2) | |
| Receivers connected (make, model, line) | |
| Test date(s) | |
| Test account(s) used (CID / Ins#) |
Scope
The signal path under test is: receiver -> concentrator -> SBN FrontEnd -> immediate queue (ma_immqueue) -> alarm generation -> Alarm Queue, with every signal also written to the Alarm Log. The concentrator has no database connection. It acknowledges the receiver only after the FrontEnd confirms the database insert (SQLACK), so a receiver ACK is evidence that the signal is stored.
The redundant components under test are the concentrator pair, the two FrontEnd hosts, and the Windows Server Failover Cluster, managed in Failover Cluster Manager, that provides high availability. Panel programming, operator procedures and reports are outside this certificate.
Test A: signal path, concentrator to Alarm Queue
Test A uses the site's live signal traffic. No particular panel, account or event is required. Observe for at least 15 minutes, or until every receiver line has carried at least one signal. A signal whose CID matches an installation that is set up raises its alarm on that installation. Every other signal falls through to ZSYSError, the catch-all error account.
| # | Step | Expected result | Observed | Result (Pass, Fail, Pass with note) |
|---|---|---|---|---|
| A1 | Check the concentrator main window | Every configured receiver line is online; both FrontEnd hosts show online; one host is marked primary | ||
| A2 | Watch incoming traffic in the concentrator | Signals arrive on every receiver line, each shown with its receiver, account and event | ||
| A3 | Check the concentrator log for the period | Concentrators send acknowledgement with no repeated NAKs, retransmissions or host-offline messages | ||
| A4 | Take 20 consecutive signals from the concentrator display and find each one in the Alarm Log | Each is logged once, with matching account, event and time, in the order received | ||
| A5 | Find the sampled signals on the installation matching their CID, if set up, or ZSYSError if not | Each sampled alarm signal appears as an alarm on the installation matching its CID, or on ZSYSError, carrying the original account and event; the longest delay from the concentrator is recorded |
Test B: high availability
Each failover is tested under live traffic. For each step, compare what the concentrator received during the outage with the Alarm Log. A step passes when signals keep reaching the Alarm Log and Alarm Queue and none of them is missing or duplicated. Record the longest delay seen.
Limitation: while the splitter is in place, it feeds only one concentrator. The backup concentrator receives no traffic, so B4 and B5 cannot show that signals keep arriving through a concentrator failure. Record B4 and B5 as Pass with note and list them under exceptions, or repeat them once the splitter feeds both concentrators.
| # | Step | Expected result | Observed | Result (Pass, Fail, Pass with note) |
|---|---|---|---|---|
| B1 | Record the baseline in the concentrator window | Both FrontEnd hosts online; note which host holds primary | ||
| B2 | Stop the primary FrontEnd host | The concentrator logs the host offline; the surviving host's head-end claims primary ("Primary status changed to" in the log); signals keep arriving with none missing | ||
| B3 | Restart the stopped FrontEnd host | The host returns online; signals keep arriving with none duplicated | ||
| B4 | Stop the primary concentrator (ID NN). Not possible with TCP Splitter. | Receivers switch to the backup concentrator (ID NN+10); signals keep arriving with none missing; the Alarm Log shows the backup concentrator ID as the origin | ||
| B5 | Restart the primary concentrator. Not possible with TCP Splitter. | It returns online and resumes its role; signals keep arriving with none duplicated | ||
| B6 | In Failover Cluster Manager, move the SBN clustered roles to the other node (planned failover) | The roles come online on the other node; the FrontEnd and SBN clients reconnect without manual action; signals keep arriving with none missing | ||
| B7 | Move the roles back to the original node | Same as B6 | ||
| B8 | Shut down the active cluster node without warning | The cluster brings the roles online on the surviving node; signals keep arriving with none missing; operators can open and handle the alarms |
Exceptions and open items
List every step marked Fail or Pass with note. Accept with exceptions only when the fix and its date are agreed below.
| Step | Issue | Agreed action | Owner | Due |
|---|---|---|---|---|
Acceptance
The undersigned confirm that the tests above were performed at the customer site on the dates recorded. SBN receives signals in the concentrator and delivers them to the Alarm Queue. It continues to deliver when a FrontEnd host, a concentrator or a database node fails.
| Outcome | Mark one |
|---|---|
| Accepted without exceptions | |
| Accepted with the exceptions listed above | |
| Not accepted |
| Customer | Innovative Business Software | |
|---|---|---|
| Name | ||
| Title | ||
| Signature | ||
| Date |