Specifications

1 Introduction and Scope
MCS stands for “monitoring and control system”. As described in the LWA station architecture
document [1], MCS monitors and controls ASP (“analog signal processing”), DP (“digital process-
ing”), and other subsystems. The purpose of this interface control document (ICD) is to define a
common interface between MCS and connected subsytems.
Compliance with this ICD is necessary, but not sufficient for integration with MCS. As explained
below, this ICD provides a framework for the interface between MCS and subsystems which are
directly connected to it, including electromechanical interfaces and protocol information. It is ex-
pected that subsystems connecting to MCS will cite this ICD in their subsystem-specific ICDs, and
then specify subs ystem-specific information as extensions within this fr amework.
This ICD does not apply to the interface between DP and the interim data recording capability
being provided by MCS, described in Section 3 of [2].
2 Summary
1. The sole physical interface with MCS will be a single 1000BASE-T (full-duplex gigabit ether-
net) connection over Category 6 (“Cat-6”) cable terminated in RJ45 connectors.
2. The sole protocol interface with MCS will be UDP, with direct passing of messages using
sockets.
1
IP addresses are static and defined in a separate document. Port assignments are
defined in a separate document. The term “message” is defined henceforth to mean a single
command or response, containined entirely within the data field of one or more UDP packets.
A message will normally correspond to a single use of a “send()” or “recv()” function (with
syntax dependent on the programming language, of course). Message structure is defined in
Section 4.
3. The interface will operate according to a “polling” paradigm. Connected subsystems will never
initiate communications, and will only respond to an MCS message to the extent required by
the applicable ICD(s). Subsystems shall not communicate with subsystems other than MCS
over this interface.
3 MIB
“MIB” stands for “management information base”.
2
The MIB provides a means for organizing sub-
system status information that is jointly understo od by communicating subsystems.
The MIB has an index/outline structure, as demonstated by the MIB fragment in Figure 1. (Note
this fragment is an example only, shown only for the purposes of explaining the MIB concept.) In
this fragment, each line is an “entry”, consisting of an “index” (e.g., 2) and a “label” (e.g, A2). Each
MIB index/label possibly also has an associated data value. A “branch” is a set of entries with a
common index/label; for example, br anch 2 (also known as “A2”) contains the data values B21 =
3.4, D221 = “PRR”, and E22 = 7. Other examples: Branch 2.1 contains the data value B21 = 3.4
only, and branch 2.2 (also known as “C22”) contains data values D221 = “PRR” (D221) and E222
= 7. Note that entries with “sub-entries” are for organizational purposes only (making it possible to
refer to multiple entries using a single index/label), and do not contain data. For example, entries
2 and 2.2 have labels only and contain no data.
1
For the uninitiated, see http://en.wikipedia.org/wiki/User
Datagram Protocol and/or
http://docs.python.org/library/socket.html.
2
The use of this term is a nod to the MIB concept used in the SNMP protocol, but the two MIBs are not the
same, and in fact are different in many respects.
2