**Project X Control System Requirements**

T.Bolshakov, C. Briegel, K. Cahill, L. Carmichael, D. Finstrom, S.
Gysin, B. Hendricks C.King, W. Kissel, S.Lackey, W. Marsh, R.Neswold, D.
Nicklaus, J. Patrick, A. Petrov, R.Rechenmacher, C. Schumann, J.
Smedinghoff, D. Stenman, G. Vogel, A. Warner, T. Zingelman

Table of Contents

[1 Introduction 4](#introduction)

[2 Base Requirements 5](#base-requirements)

[2.1 Scale 5](#scale)

[2.2 Availability 5](#availability)

[2.3 Safety 6](#safety)

[2.4 Legacy Constraints 7](#legacy-constraints)

[2.5 Summary of Base Requirements 7](#summary-of-base-requirements)

[3 Low-Level Systems 9](#low-level-systems)

[3.1 Timing System 9](#timing-system)

[3.2 Equipment Interface/Instrumentation
11](#__RefHeading___Toc190137153)

[3.3 Development Environment 12](#development-environment)

[3.4 Data Acquisition/Setting 13](#data-acquisitionsetting)

[4 Central Services 18](#central-services)

[4.1 Naming Service 18](#naming-service)

[4.2 Data Acquisition Service 20](#data-acquisition-service)

[4.3 Alarm Management Service 28](#alarm-management-service)

[4.4 Data Logging Service 29](#data-logging-service)

[4.5 Hierarchical Logging Service 32](#hierarchical-logging-service)

[4.6 Postmortem Logging Service 33](#postmortem-logging-service)

[4.7 Save And Restore Service 34](#save-and-restore-service)

[5 Application Infrastructure 36](#application-infrastructure)

[5.1 Types of Applications 36](#types-of-applications)

[5.2 Application Protocols 38](#application-protocols)

[5.3 General-Purpose Database 39](#general-purpose-database)

[5.4 Security 39](#security)

[5.5 Application Framework 41](#application-framework)

[6 High Level Applications 42](#high-level-applications)

[6.1 User Interface 42](#user-interface)

[6.2 Applications 43](#applications)

[6.3 Nonstandard Applications 47](#nonstandard-applications)

[7 Controls In A Box 49](#controls-in-a-box)

[8 Beam-Based Feedback 51](#beam-based-feedback)

[9 Machine Protection System 53](#machine-protection-system)

[9.1 General Machine Protection System Requirements
53](#general-machine-protection-system-requirements)

[9.2 Beam Permit 55](#beam-permit)

[10 Software Development Environment
57](#software-development-environment)

[10.1 Production Applications and Libraries
57](#production-applications-and-libraries)

[10.2 Non-Production Applications and Libraries
58](#non-production-applications-and-libraries)

[10.3 Modular Code Development 58](#modular-code-development)

[10.4 Ease of Use 59](#ease-of-use)

[10.5 Integrated Development Environment (IDE)
59](#integrated-development-environment-ide)

[10.6 Debugging Tools 60](#debugging-tools)

[10.7 SDE Deployment 60](#sde-deployment)

[10.8 Testing Environment 60](#testing-environment)

[10.9 Diagnostics for Development and Deployment
61](#diagnostics-for-development-and-deployment)

[10.10 Version Control 61](#version-control)

[10.11 Collaborative Development 61](#collaborative-development)

[10.12 Issue Tracking 61](#issue-tracking)

[10.13 Language Support 62](#language-support)

[10.14 Documentation 62](#documentation)

[10.15 Software Quality and Process 62](#software-quality-and-process)

[11 Hardware/Operating Systems 63](#hardwareoperating-systems)

[11.1 Hardware 63](#hardware)

[11.2 Hardware Requirements for Low Level
63](#hardware-requirements-for-low-level)

[11.3 Hardware Requirements for Central Nodes
63](#hardware-requirements-for-central-nodes)

[11.4 Hardware Requirements for the Client Nodes
64](#hardware-requirements-for-the-client-nodes)

[11.5 Operating Systems 64](#operating-systems)

[11.6 Operating Systems for Low Level
64](#operating-systems-for-low-level)

[11.7 Operating Systems for Central Nodes
65](#operating-systems-for-central-nodes)

[11.8 Operating Systems for Client Nodes
65](#operating-systems-for-client-nodes)

[12 Networks 67](#networks)

[12.1 Project X Network Overview 67](#project-x-network-overview)

[12.2 The Controls Network 68](#the-controls-network)

[12.3 The DMZ Network 69](#the-dmz-network)

[12.4 The Development Network 70](#the-development-network)

[12.5 The General Network 71](#the-general-network)

[12.6 Acceptable Failure Rate and Impact
71](#acceptable-failure-rate-and-impact)

[12.7 Monitoring and response 72](#monitoring-and-response)

[12.8 Physical Layout and Network Model
72](#physical-layout-and-network-model)

[12.9 Network Security 74](#network-security)

[12.10 Remote Network Monitoring 76](#remote-network-monitoring)

[12.11 Data Center 76](#data-center)

[13 References 77](#references)

  ------------- ------------ --------------------------------------------------
  **Version**   **Date**     **Comments**

  2.1           2008-02-21   Updates to Controls in a Box

  2.0           2008-02-01   Updates from internal review

  1.0           2008-01-14   Document for internal review

  0.3           2007-11-29   Fixed the section so the match the table of
                             contents. Moved Macro Language and Synoptic
                             display from 9 to 6.2

  0.2           2007-11-18   Added references, merged with Andrey's outline for
                             Central Services

  0.1           2007-11-09   First draft into doc db
  ------------- ------------ --------------------------------------------------

# Introduction

Project X is a concept for an intense 8 GeV proton source that provides
beam for the Fermilab Main Injector and an 8 GeV physics program. The
source consists of an 8 GeV superconducting linac that injects into the
Fermilab Recycler where multiple linac beam pulses are stripped and
accumulated. The 8 GeV linac consists of a low energy front-end possibly
based on superconducting technology and a high energy end composed of
ILC-like cryomodules. The use of the Recycler reduces the required
charge in the superconducting 8 GeV linac to match the charge per pulse
of the ILC design; aligning Project X and ILC technologies. \[1\]

![](media/image1.jpeg){width="5.375694444444444in" height="2.7625in"}

The control system for this accelerator (Control X) should be of modern
design, use currently available high performance hardware and networks,
and have a track record of success in the accelerator control business.
To the extent possible, the equipment utilized should be readily
available commodity equipment. Use of standards in equipment and
software system will aid in development, diagnosis, and repair.

This document is an agreement between the users and the
designers/developers of the functionality of the control system. While
writing the document the authors, who are developers and users, are
required to discuss and eventually agree on the functionality. This
document deliberately avoids a specific implementation or design and
focuses on the 'what' rather than 'how'.

The audience of the document, once it is completed, are the designers
and developers of the control system. They will refer to the
requirements to decide on a design that is most optimal for the
requirements.

# Base Requirements

In the following section are the very basic requirements driven by the
specifics of Project X. These are meant to drive the other requirements,
or considering this structure as a tree, the base requirements are the
trunks from which smaller branches originate. For example, the scale of
Controls X, will drive requirements for a middle tier, and a large
network bandwidth. The intent is that one can always track a requirement
to it's original base requirement.

## Scale

The Tevatron complex control system currently controls about 200,000
devices\[2\]. In broad terms, Project X has a similar scale considering
the linacs, the beam injection line, the main injector recycler, and
target station. Each device can have up to five properties, which means
Control X should be designed to control about one million properties.

A generous assumption for maximum load is 200 users accessing the
control system simultaneously. The average load is probably about 50
users. From these estimates we derive the very basic scale requirement:

**Controls X shall be able to support 200 users accessing 5000
properties each.**

The large number of components and heavy traffic imply requirements for
a middle tier to balance the load and consolidate the requests, a large
network bandwidth. Any modern control system will assume that the user
may or may not be on site, so the control system must support some
remote access.

## Availability

To maximize performance we have to maximize the time the beam is in the
accelerator. And to maximize the time the beam is in the accelerator,
the control system has to be very reliable, fault tolerant, and we have
to design for a minimum mean time to repair (MTTR).

The uptime is often quoted in availability, for example 75% availability
means, the accelerator is delivering beam 75% of the time. Scheduled
maintenance shut downs are not included in the availability target. In
the example above, the scheduled maintenance is not counted towards the
25% the accelerator is not available.

The availability is defined for the accelerator complex, and the control
system is allowed to account for some fraction of that. A high
availability requirement for Project X early on will ensure availability
is considered at all stages of the design, as it can affect major design
choices as well as the detailed design of each component.

Software errors contribute up to 30% of failures and the control system
has a great amount of software that could potentially contribute to
failure. A detailed analysis of how control system availability relates
to beam availability is complicated. Ideally, the control system should
never fail\[4\]. The consequences of failure of a critical part of the
control system can be devastating, so the availability of Project X has
to be considered in the design for Control X.

The ILC control system has a requirement of 2500-hr MTBF (mean time
between failures and 5-hr MTTR (meant time to repair) and 15 hours
downtime per year. \[4\].

**Control X shall have no less than 2500-hr MTBF and no more than 5-hr
MTTR.**

## Safety

The beam power of Project X is a magnitude of 10 times larger than that
of the current operations.\[3\].

![](media/image2.png){width="4.372916666666667in" height="3.4125in"}

The current beam power is about 200 kW; Project X is targeted for 2 MW.
At 2MW, an accident can cause serious damage to people and equipment.
This drives the requirements of a stringent machine protection system
(MPS), such as hardware and software interlocks, access control, and
alarms.

**Controls X shall have an extensive machine protection system,
including hardware interlocks, software interlocks, access control, and
alarms**

With high beam power, accidents are not the only concern. Just routine
losses can activate components so that they fail more often and become
difficult to work on due to residual radioactivity. To prevent this beam
trajectories must be well controlled. This will likely require the
control system to do fast feedback.

**Controls X shall have a fast (5 Hz.) feedback system to control the
beam trajectory and thereby minimizing routine beam losses causing
components to be activated and radioactive.**

## Legacy Constraints

At the time Project X begins operation, the Accelerator NUMI Upgrade
will have been completed and the recycler, main injector, NUMI beam
line, and 120 GeV fixed target lines operated for some years in that
configuration. These elements will be controlled by an evolution of the
current ACNET system. This includes field equipment, the timing system,
front-end computers, services, and applications. While some changes will
be needed in these accelerator components for Project X, the control
system hardware and software represents a large investment that could be
difficult to completely replace by the start of Project X operation.
Hence the Project X control system must interoperate with the existing
system to the extent that is necessary for seamless operation.

## Summary of Base Requirements

Project X will have about 9 km of beam line and 1 Million device
properties. It will have 10x more beam power, and it has some legacy
constraints because it uses the Main Injector and Recycler.

From these constraints we derive the base requirements:

+----------+--------------------------------------+--------+---------+
| **No.**  | **Requirement**                      | **So   | **Pri   |
|          |                                      | urce** | ority** |
+----------+--------------------------------------+--------+---------+
| CXR-10   | The control system shall support 200 | S      | C       |
|          | users accessing 5000 properties      | .Gysin | ritical |
|          | each.                                |        |         |
|          |                                      | 1      |         |
|          |                                      | 0-2007 |         |
+----------+--------------------------------------+--------+---------+
| CXR-20   | The control system shall have no     | S.     | E       |
|          | less than 2500-hr MTBF and no more   | Gysin, | xpected |
|          | than 5-hr MTTR.                      | J.P    |         |
|          |                                      | atrick |         |
|          |                                      |        |         |
|          |                                      | 1      |         |
|          |                                      | 0-2007 |         |
+----------+--------------------------------------+--------+---------+
| CXR-30   | The control system shall have an     | S      | C       |
|          | extensive machine protection         | .Gysin | ritical |
|          | mechanism, including hardware        |        |         |
|          | interlocks, software interlocks,     | 1      |         |
|          | access control, and alarms.          | 0-2007 |         |
+----------+--------------------------------------+--------+---------+
| CXR-40   | The control system shall have a fast | J.P    | C       |
|          | (5 Hz.) feedback system to control   | atrick | ritical |
|          | the beam trajectory and thereby      |        |         |
|          | minimizing routine beam losses       | 1      |         |
|          | causing components to be activated   | 1-2007 |         |
|          | and radioactive.                     |        |         |
+----------+--------------------------------------+--------+---------+
| CXR-41   | The control system shall comply with | J.P    | C       |
|          | the safety policy of the laboratory. | atrick | ritical |
|          |                                      |        |         |
|          |                                      | 1-2008 |         |
+----------+--------------------------------------+--------+---------+

The control system for the linac and transfer line must satisfy the
following requirements to meet the legacy constraints:

+----------+-------------------------------------+---------+---------+
| **No.**  | **Requirement**                     | **S     | **Pri   |
|          |                                     | ource** | ority** |
+----------+-------------------------------------+---------+---------+
| CXR-50   | Timing signals shall be provided in | J.      | C       |
|          | a format that can be accepted by    | Patrick | ritical |
|          | legacy hardware.                    |         |         |
|          |                                     | 12-2007 |         |
+----------+-------------------------------------+---------+---------+
| CXR-60   | Machine protection system inputs    | J.      | C       |
|          | from legacy hardware shall be       | Patrick | ritical |
|          | accepted.                           |         |         |
|          |                                     | 12-2007 |         |
+----------+-------------------------------------+---------+---------+
| CXR-70   | It shall be possible to acquire     | J.      | C       |
|          | data from legacy hardware into      | Patrick | ritical |
|          | applications and into a common      |         |         |
|          | archive for proper correlation      | 12-2007 |         |
|          | across the complex.                 |         |         |
+----------+-------------------------------------+---------+---------+
| CXR-80   | It shall be possible for            | J.      | C       |
|          | applications in the legacy system   | Patrick | ritical |
|          | to acquire data from new linac      |         |         |
|          | subsystems. It may not be necessary | 12-2007 |         |
|          | to support access to all devices    |         |         |
|          | and data acquisition protocols      |         |         |
|          | however.                            |         |         |
+----------+-------------------------------------+---------+---------+
| CXR-90   | The alarms service shall be able to | J.      | C       |
|          | receive alarms generated by the     | Patrick | ritical |
|          | legacy system.                      |         |         |
|          |                                     | 12-2007 |         |
+----------+-------------------------------------+---------+---------+
| CXR-100  | Applications that run on the legacy | J.      | C       |
|          | system shall be conveniently        | Patrick | ritical |
|          | accessible to operators.            |         |         |
|          |                                     | 12-2007 |         |
+----------+-------------------------------------+---------+---------+
| CXR-110  | The control system shall adhere to  | S.Gysin | E       |
|          | lab wide security policy.           |         | xpected |
|          |                                     | 2-2008  |         |
+----------+-------------------------------------+---------+---------+

What follows are the requirements derived from these high level, and
grouped into the three tiers of functionality. Low level i.e. the
front-ends that interface directly to the instrument, central services
i.e. software running on servers, and high level which is the software
operators use. Additional sections that span all three layers are the
machine protection system, software build system, hardware, and network.

# Low-Level Systems

## Timing System

Timing systems are critical to the ability of Project-X to coordinate
beam acceleration and transfer between the various accelerators that
will make up the complex. They are also essential to the ability of the
control system to provide correlated data acquisition. In order to
provide these timing capabilities, there will be two types of clock
systems in Project-X.

The first will be a basic accelerator clock that provides high-level
timing for the entire complex and is common to all machines. In the
legacy systems this function is accomplished via the **TCLK** system. It
is an 8-bit, 10 MHz, modified Manchester encoded serial transmission of
clock events that provide basic accelerator timing information. As more
timing functionality (16 bit events, event indexing, etc.) is necessary
to facilitate the acquisition and correlation of machine data for the
new accelerators of Project-X, a new clock system (herein referred to as
**XCLK**) is required. As TCLK will continue to be generated to supply
timing signals for the legacy systems, these two clocks systems will
need to be strictly synchronized. It is expected that all new systems
installed around the complex will make use of XCLK.

The second type of clock systems are machine-specific RF based timing
systems (Beam Sync Clocks.) These systems will allow for the
transmission of the individual machine's RF and beam synchronization
markers to facilitate high precision (RF bucket level) timing for such
things as instrumentation and kicker triggering. In the legacy systems
this function is handled via the individual accelerator's Beam Sync
Clocks (MIBS, RRBS, etc.). As with TCLK, the legacy beam sync clocks are
8-bit, modified Manchester encoded serial transmissions. However, their
base frequencies are subharmonics of the machine's RF frequencies rather
than the 10 MHz of TCLK. These clocks also transmit a low amplitude copy
of the machine's RF. As beam in the new Linac of Project-X must be
synchronized to the Recycler, the Recycler beam sync clock (**RRBS**)
must be made available throughout the machine and to the source (the
Chopper).

### Basic Accelerator Clock (XCLK)

This section only covers requirements for XCLK.

+-----------+--------------------------------+---------------+--------+
| **No.**   | **Requirement**                | **Source**    | **Prio |
|           |                                |               | rity** |
+===========+================================+===============+========+
| CXR-LL-10 | Basic accelerator clock timing | G.Vogel       | Ex     |
|           | shall be sourced via a single  |               | pected |
|           | Timeline Generator (TLG) and   | 12-2007       |        |
|           | transmitted on optical fiber.  |               |        |
+-----------+--------------------------------+---------------+--------+
| CXR-LL-20 | TCLK events shall be encoded   | G.Vogel       | Cr     |
|           | to occur synchronously on both |               | itical |
|           | TCLK and XCLK.                 | 1-2008        |        |
+-----------+--------------------------------+---------------+--------+
| CXR-LL-30 | XCLK shall run on a 1 GHz, or  | G.Vogel       | Ex     |
|           | higher, carrier phase-locked   |               | pected |
|           | to the TCLK's 10 MHz carrier.  | 12-2007       |        |
+-----------+--------------------------------+---------------+--------+
| CXR-LL-40 | 16 bits of the XCLK data frame | G.Vogel       | Ex     |
|           | shall represent the XCLK clock |               | pected |
|           | event. The XCLK frame shall    | 1-2008        |        |
|           | have an additional *n* bits    |               |        |
|           | for data payload.              |               |        |
+-----------+--------------------------------+---------------+--------+
| CXR-LL-45 | XCLK events outside the range  | G.Vogel,      | Ex     |
|           | \$0000-\$00FE shall generate a | J.Smedinghoff | pected |
|           | TCLK \$FF event.               |               |        |
|           |                                | 1-2008        |        |
+-----------+--------------------------------+---------------+--------+
| CXR-LL-50 | The XCLK frame size shall not  | G.Vogel       | Cr     |
|           | exceed 1.2uS.                  |               | itical |
|           |                                | 12-2007       |        |
+-----------+--------------------------------+---------------+--------+
| CXR-LL-60 | Events occurring on XCLK shall | G.Vogel       | Cr     |
|           | not affect the timing of       |               | itical |
|           | events in the legacy system.   | 1-2008        |        |
+-----------+--------------------------------+---------------+--------+
| CXR-LL-70 | The data in the event payload  | C.Briegel     | D      |
|           | shall be self-describing.      |               | esired |
|           |                                | 12-2007       |        |
+-----------+--------------------------------+---------------+--------+
| CXR-LL-90 | 32 bits of the XCLK frame      | R             | D      |
|           | shall be reserved for a        | .Rechenmacher | esired |
|           | per-event counter (Event       |               |        |
|           | Index).                        | 12-2207       |        |
+-----------+--------------------------------+---------------+--------+
| C         | In order to provide redundancy | G.Vogel       | Ex     |
| XR-LL-100 | needed to meet availability    |               | pected |
|           | requirements, 2 fibers         | 1-2008        |        |
|           | carrying XCLK shall run from   |               |        |
|           | repeater to repeater.          |               |        |
+-----------+--------------------------------+---------------+--------+
| C         | The repeaters shall constantly | G.Vogel       | Ex     |
| XR-LL-110 | monitor and compare the two    |               | pected |
|           | transmissions and have         | 12-2007       |        |
|           | auto-switchover if one carrier |               |        |
|           | fails.                         |               |        |
+-----------+--------------------------------+---------------+--------+
| C         | The repeaters shall inhibit    | G.Vogel       | Ex     |
| XR-LL-120 | beam if total clock is lost.   |               | pected |
|           |                                | 12-2007       |        |
+-----------+--------------------------------+---------------+--------+
| C         | The hardware group shall       | G.Vogel       | D      |
| XR-LL-130 | provide hardware XCLK          |               | esired |
|           | simulators for front-end       | 12-2007       |        |
|           | developers.                    |               |        |
+-----------+--------------------------------+---------------+--------+
| C         | The hardware group shall       | G.Vogel       | Ex     |
| XR-LL-135 | provide a standard XCLK        |               | pected |
|           | decoder design.                | 1-2008        |        |
+-----------+--------------------------------+---------------+--------+
| C         | Front-end software shall be    | R             | D      |
| XR-LL-140 | able to simulate the clock     | .Rechenmacher | esired |
|           | system to allow development on |               |        |
|           | machines that don't have       | 12-2007       |        |
|           | access to XCLK signals.        |               |        |
+-----------+--------------------------------+---------------+--------+

### Beam Sync Clock

This section only covers requirements for the Beam Sync Clocks.

+------------+------------------------------------+---------+--------+
| **No.**    | **Requirement**                    | **S     | **Prio |
|            |                                    | ource** | rity** |
+============+====================================+=========+========+
| CXR-LL-150 | The Main Injector and Recycler     | G.Vogel | Ex     |
|            | shall continue to use the existing |         | pected |
|            | beam sync clocks.                  | 12-2007 |        |
+------------+------------------------------------+---------+--------+
| CXR-LL-160 | The Recycler Beam Sync Clock shall | G.Vogel | Cr     |
|            | be made available to all 8 GeV     |         | itical |
|            | line and Linac equipment           | 1-2008  |        |
|            | locations.                         |         |        |
+------------+------------------------------------+---------+--------+

## Equipment Interface/Instrumentation

The Controls System needs to interface to a variety of equipment both
purchased and designed in-house. These include instrumentation, vacuum,
power supplies, water systems, etc. In order to ensure that the Controls
System is reliable and easy to diagnose, a limited number of standard
interfaces should be implemented and duplication should be avoided. The
controls group will provide a standard equipment interface for other
groups to incorporate into their equipment designs.

+-----------+------------------------------------+-----------+--------+
| **No.**   | **Requirement**                    | *         | **Prio |
|           |                                    | *Source** | rity** |
+===========+====================================+===========+========+
| C         | General purpose digitizing         | R.Neswold | Ex     |
| XR-LL-170 | hardware shall allow all of its    |           | pected |
|           | channels to be plotted             | 12-2007   |        |
|           | simultaneously.                    |           |        |
+-----------+------------------------------------+-----------+--------+
| C         | The middleware shall provide a     | C.Briegel | D      |
| XR-LL-180 |                                    |           | esired |
|           | mechanism to redirect traffic to a | 1-2008    |        |
|           | back-up                            |           |        |
|           |                                    |           |        |
|           | node in the event of a failure.    |           |        |
+-----------+------------------------------------+-----------+--------+
| C         | The hardware group shall support   | G.Vogel   | Ex     |
| XR-LL-190 | and provide a set of general       |           | pected |
|           | purpose preferred digitizers.      | 12-2007   |        |
+-----------+------------------------------------+-----------+--------+
| C         | Front-end hardware shall support,  | T.        | Cr     |
| XR-LL-200 | as a minimum, full-duplex, gigabit | Zingelman | itical |
|           | copper communications.             |           |        |
|           |                                    | 12-2007   |        |
+-----------+------------------------------------+-----------+--------+
| C         | Front-end platforms shall support  | T.        | Ex     |
| XR-LL-210 | Ipv6 communications.               | Zingelman | pected |
|           |                                    |           |        |
|           |                                    | 12-2007   |        |
+-----------+------------------------------------+-----------+--------+
| C         | Front-end platforms shall support  | T.        | Ex     |
| XR-LL-220 | port scans gracefully.             | Zingelman | pected |
|           |                                    |           |        |
|           |                                    | 1-2008    |        |
+-----------+------------------------------------+-----------+--------+
| C         | Supported hardware and software    | C.Briegel | Ex     |
| XR-LL-230 | shall be enumerated.               |           | pected |
|           |                                    | 12-2007   |        |
+-----------+------------------------------------+-----------+--------+
| C         | A committee shall review all new   | C.Briegel | Ex     |
| XR-LL-240 | support (requested or required) to |           | pected |
|           | aid in maintaining an appropriate  | 12-2007   |        |
|           | set of solutions.                  |           |        |
+-----------+------------------------------------+-----------+--------+

### Site Facilities Integration

Various site facilities/utilities such as water, electrical power
distribution & environmental management (Heating Ventilation Air
Conditioning - HVAC) are indeed necessary for accelerator operation.
Other systems such as electrical & radiation safety systems are critical
to the success of a physics program. Such areas may have evolved
separately due to technological or political reasons. It is important to
provide an integrated structure to the above, enhancing troubleshooting,
trend analysis and cause & effect determination.

+-----------+------------------------------------+-----------+--------+
| C         | The control system shall provide   | W. Kissel | D      |
| XR-LL-245 | gateways for read access into      |           | esired |
|           | mission critical safety, utility   | 1-2008    |        |
|           | and environmental systems.         |           |        |
+-----------+------------------------------------+-----------+--------+

## Development Environment

Due to technical and historical reasons, the front-end development
environment is separate from ones used by other groups. We suggest a
consolidation of toolsets is possible, so that working on different
layers of the control system doesn't require a differing set of skills.

In addition to the requirements in this section, we would like to see
the front-end development also follow the requirements expressed in the
Software Development Environment section (10).

+-----------+--------------------------------+---------------+--------+
| **No.**   | **Requirement**                | **Source**    | **Prio |
|           |                                |               | rity** |
+===========+================================+===============+========+
| C         | The development and build      | R.Neswold     | Ex     |
| XR-LL-250 | environments for front-end     |               | pected |
|           | shall be the same as used by   | 12-2007       |        |
|           | central and high-level         |               |        |
|           | application developers.        |               |        |
+-----------+--------------------------------+---------------+--------+
| C         | Front-ends shall run on        | R.Neswold     | Ex     |
| XR-LL-260 | platforms that support memory  |               | pected |
|           | protection.                    | 12-2007       |        |
+-----------+--------------------------------+---------------+--------+
| C         | Front-end software shall use   | R.Neswold     | Ex     |
| XR-LL-270 | memory protection features in  |               | pected |
|           | its design to improve          | 12-2007       |        |
|           | reliability.                   |               |        |
+-----------+--------------------------------+---------------+--------+
| C         | Front-end systems shall run on | R.Neswold     | D      |
| XR-LL-280 | platforms that support         |               | esired |
|           | portable APIs (e.g. pthreads,  | 12-2007       |        |
|           | unix system calls)             |               |        |
+-----------+--------------------------------+---------------+--------+
| C         | The framework used to create   | R.Neswold     | D      |
| XR-LL-290 | front-end software shall also  |               | esired |
|           | be used to create OACs.        | 12-2007       |        |
+-----------+--------------------------------+---------------+--------+
| C         | The front-end shall provide a  | C.Briegel     | Ex     |
| XR-LL-300 | user application framework for |               | pected |
|           | developing and deploying user  | 12-2007       |        |
|           | code in the front-end.         |               |        |
+-----------+--------------------------------+---------------+--------+
| C         | All front-ends shall have      | R             | Ex     |
| XR-LL-310 | debugging facilities available | .Rechenmacher | pected |
|           | to developers ("post-mortem"   |               |        |
|           | facilities, access to internal | 12-2007       |        |
|           | state, etc.)                   |               |        |
+-----------+--------------------------------+---------------+--------+
| C         | All front-ends shall have a    | R.Neswold     | Ex     |
| XR-LL-320 | common set of devices to       |               | pected |
|           | monitor the front-end (CPU     | 12-2007       |        |
|           | Temperature, system load,      |               |        |
|           | memory usage, version devices, |               |        |
|           | etc.)                          |               |        |
+-----------+--------------------------------+---------------+--------+
| C         | All front-ends shall use the   | R.Neswold     | Ex     |
| XR-LL-325 | same software framework.       |               | pected |
|           |                                | 1-2008        |        |
+-----------+--------------------------------+---------------+--------+

## Data Acquisition/Setting

Fermilab has a distributed control system, meaning the data used by an
application is generally acquired from a remote machine. A standardized
network protocol is used to express how to request data and how the data
is returned to the requestor. See also Central Services (4.2) and
Network section (12).

+-----------+-------------------------------+---------------+--------+
| **No.**   | **Requirement**               | **Source**    | **Prio |
|           |                               |               | rity** |
+===========+===============================+===============+========+
| C         | One network protocol suite    | R             | Ex     |
| XR-LL-330 | shall be used to for data     | .Rechenmacher | pected |
|           | acquisition from the          |               |        |
|           | front-ends.                   | 1-2008        |        |
+-----------+-------------------------------+---------------+--------+
| C         | A device shall be viewed as   | C.Briegel     | Ex     |
| XR-LL-340 | an object with many           |               | pected |
|           | attributes and data types.    | 12-2007       |        |
+-----------+-------------------------------+---------------+--------+
| C         | Device data shall be acquired | R.Neswold     | Ex     |
| XR-LL-350 | at any rate a user specifies. |               | pected |
|           | If the rate exceeds the       | 12-2007       |        |
|           | capabilities of the device,   |               |        |
|           | data is returned at the       |               |        |
|           | device's maximum rate.        |               |        |
+-----------+-------------------------------+---------------+--------+
| C         | Acquisition protocols shall   | R             | Ex     |
| XR-LL-360 | provide a way to correlate    | .Rechenmacher | pected |
|           | the data.                     |               |        |
|           |                               | 1-2008        |        |
+-----------+-------------------------------+---------------+--------+
| C         | The acquisition protocol      | M.Sliczniak   | Ex     |
| XR-LL-370 | shall support multicast       |               | pected |
|           | requests to acquire data      | 1-2008        |        |
|           | across multiple front-ends.   |               |        |
+-----------+-------------------------------+---------------+--------+
| C         | Replies to a multicast        | M.Sliczniak   | Ex     |
| XR-LL-380 | request shall arrive before a |               | pected |
|           | deadline prior to the next    | 1-2008        |        |
|           | cycle and the reply data must |               |        |
|           | come from the current cycle.  |               |        |
+-----------+-------------------------------+---------------+--------+
| C         | Data acquisition protocols    | R             | Ex     |
| XR-LL-390 | shall include enough metadata | .Rechenmacher | pected |
|           | information that each packet  |               |        |
|           | can be decoded in isolation.  | 12-2007       |        |
+-----------+-------------------------------+---------------+--------+
| C         | All device data shall be      | C.Briegel     | Ex     |
| XR-LL-400 | described by a data           |               | pected |
|           | definition derived from the   | 12-2007       |        |
|           | front-end and consistent with |               |        |
|           | the application environment.  |               |        |
+-----------+-------------------------------+---------------+--------+
| C         | A time stamp of when the data | R.Neswold     | Ex     |
| XR-LL-410 | was captured shall accompany  |               | pected |
|           | all device data.              | 12-2007       |        |
+-----------+-------------------------------+---------------+--------+
| C         | The acquisition protocol      | R.Neswold     | Ex     |
| XR-LL-415 | shall have a global event     |               | pected |
|           | cycle count and a global      | 12-2007       |        |
|           | error/status field.           |               |        |
+-----------+-------------------------------+---------------+--------+
| C         | The latest device data shall  | C.Briegel     | Ex     |
| XR-LL-420 | be able to be retrieved       |               | pected |
|           | (known as a "one-shot"        | 12-2007       |        |
|           | request.)                     |               |        |
+-----------+-------------------------------+---------------+--------+
| C         | Data shall be retrieved at a  | C.Briegel     | Ex     |
| XR-LL-425 | periodic rate.                |               | pected |
|           |                               | 12-2007       |        |
+-----------+-------------------------------+---------------+--------+
| C         | "One-shot" and repetitive     | C.Briegel     | Ex     |
| XR-LL-430 | data shall be retrieved based |               | pected |
|           | on an XCLK event occurrence   | 12-2007       |        |
|           | followed by an optional       |               |        |
|           | delay.                        |               |        |
+-----------+-------------------------------+---------------+--------+
| C         | "One-shot" and repetitive     | C.Briegel     | Ex     |
| XR-LL-440 | data shall be retrieved based |               | pected |
|           | on a state change.            | 12-2007       |        |
+-----------+-------------------------------+---------------+--------+
| C         | Data shall be retrieved based | C.Briegel     | Ex     |
| XR-LL-450 | on an event with a specified  |               | pected |
|           | event counter.                | 12-2007       |        |
+-----------+-------------------------------+---------------+--------+
| C         | Repetitive data may be        | C.Briegel     | D      |
| XR-LL-460 | filtered to return whenever   |               | esired |
|           | the data changes by a delta   | 12-2007       |        |
|           | (or range, tolerance, etc.)   |               |        |
+-----------+-------------------------------+---------------+--------+
| C         | There shall be a minimal      | M.Sliczniak   | Ex     |
| XR-LL-465 | interval value in case the    |               | pected |
|           | delta rarely occurs           | 1-2008        |        |
+-----------+-------------------------------+---------------+--------+
| C         | Front-ends shall be able to   | R.Neswold     | Ex     |
| XR-LL-470 | acquire data from each other, |               | pected |
|           | directly from the remote      | 12-2007       |        |
|           | machine \-- not through a     |               |        |
|           | consolidator.                 |               |        |
+-----------+-------------------------------+---------------+--------+
| C         | Front-ends shall be able to   | R.Neswold     | Ex     |
| XR-LL-475 | directly set other front      |               | pected |
|           | ends.                         | 1-2008        |        |
+-----------+-------------------------------+---------------+--------+
| C         | All settings shall be logged  | R.Neswold     | Ex     |
| XR-LL-477 | (note: add filtering)         |               | pected |
|           |                               | 1-2008        |        |
+-----------+-------------------------------+---------------+--------+
| C         | While device data can be      | C.Briegel     | Ex     |
| XR-LL-480 | returned either in raw or     |               | pected |
|           | scaled values, all front-ends | 12-2007       |        |
|           | shall be capable of scaling   |               |        |
|           | the data for internal use.    |               |        |
|           | This includes data acquired   |               |        |
|           | from other nodes.             |               |        |
+-----------+-------------------------------+---------------+--------+
| C         | Devices shall be able to      | C.Briegel     | Ex     |
| XR-LL-490 | handle rapid (\~15Hz)         |               | pected |
|           | settings.                     | 12-2007       |        |
+-----------+-------------------------------+---------------+--------+
| C         | All settings get forwarded to | C.Briegel     | Ex     |
| XR-LL-495 | an archive.                   |               | pected |
|           |                               | 1-2008        |        |
+-----------+-------------------------------+---------------+--------+
| C         | The setting protocol shall    | C.Briegel     | D      |
| XR-LL-500 | allow optional reading of a   |               | esired |
|           | parameter.                    | 12-2007       |        |
+-----------+-------------------------------+---------------+--------+
| C         | All data on the network shall | R.Neswold     | D      |
| XR-LL-510 | be in network byte order.     |               | esired |
|           |                               | 12-2007       |        |
+-----------+-------------------------------+---------------+--------+
| C         | There shall be an acquisition | C.Briegel     | Ex     |
| XR-LL-520 | protocol that returns data    |               | pected |
|           | suitable for a real-time plot | 1-2008        |        |
|           | at a minimum of 1kHz.         |               |        |
+-----------+-------------------------------+---------------+--------+
| C         | There shall be an acquisition | C.Briegel     | Ex     |
| XR-LL-530 | protocol that returns an      |               | pected |
|           | array of data samples on an   | 1-2008        |        |
|           | event (i.e. a snapshot of a   |               |        |
|           | waveform.)                    |               |        |
+-----------+-------------------------------+---------------+--------+
| C         | The waveform snapshot shall   | C.Briegel     | D      |
| XR-LL-540 | also support collection on    |               | esired |
|           | alarm activation.             | 1-2008        |        |
+-----------+-------------------------------+---------------+--------+
| C         | The front-end shall provide   | B.Hendricks   | D      |
| XR-LL-545 | device metadata including ,   |               | esired |
|           | but not limited to, device    | 1-2008        |        |
|           | type.                         |               |        |
+-----------+-------------------------------+---------------+--------+

### *Network Protocol Policies*

As an evolution of our current control system, we envision the improved
protocols allow "policies" to be enabled. For instance, we might decide
that settings require authentication, or that devices can be temporarily
owned by users.

+------------+-------------------------------+---------------+--------+
| **No.**    | **Requirement**               | **Source**    | **Prio |
|            |                               |               | rity** |
+============+===============================+===============+========+
| CXR-LL-550 | "Policies" active in the      | R             | Ex     |
|            | control system shall be       | .Rechenmacher | pected |
|            | honored across all            |               |        |
|            | acquisition methods.          | 1-2008        |        |
+------------+-------------------------------+---------------+--------+
| CXR-LL-560 | Device access shall have      | C.Briegel     | Ex     |
|            | "ownership", and operators    |               | pected |
|            | shall be able to query who is | 12-2007       |        |
|            | current "owner" of the        |               |        |
|            | device.                       |               |        |
+------------+-------------------------------+---------------+--------+
| CXR-LL-570 | There shall be a policy of    | R             | Ex     |
|            | access rights for users to    | .Rechenmacher | pected |
|            | restrict who is allowed to    |               |        |
|            | make changes, mainly for      | 12-2007       |        |
|            | preventing interference in    |               |        |
|            | conflicting uses of the       |               |        |
|            | machine.                      |               |        |
+------------+-------------------------------+---------------+--------+
| CXR-LL-580 | The setting protocol shall    | R.Neswold     | D      |
|            | support optional transaction  |               | esired |
|            | semantics across front-ends   | 12-2007       |        |
|            | (i.e. settings can be queued  |               |        |
|            | for later commit or           |               |        |
|            | rollback.)                    |               |        |
+------------+-------------------------------+---------------+--------+

### Alarm Support

Alarm reporting is a very important aspect of our current control
system. A huge number of devices are scanned frequently to ensure they
are operating within their constraints. This section of requirements
covers alarm support, along with some improvements.

+-----------+------------------------------------+-----------+--------+
| **No.**   | **Requirement**                    | *         | **Prio |
|           |                                    | *Source** | rity** |
+===========+====================================+===========+========+
| C         | Front-ends shall scan devices      | C.Briegel | Ex     |
| XR-LL-600 | periodically and compare the       |           | pected |
|           | reading with alarm constraints.    | 12-2007   |        |
|           | Readings that violate their        |           |        |
|           | constraint are said to be in       |           |        |
|           | alarm. Alarm reports are forwarded |           |        |
|           | to a central alarm service, which  |           |        |
|           | reports the alarms to operators.   |           |        |
+-----------+------------------------------------+-----------+--------+
| C         | There shall be a default alarm     | C.Briegel | Ex     |
| XR-LL-610 | scan frequency, which can be       |           | pected |
|           | overridden for each device. The    | 12-2007   |        |
|           | overridden devices can be sampled  |           |        |
|           | on any acquisition event.          |           |        |
+-----------+------------------------------------+-----------+--------+
| C         | There shall be a default alarm     | C.Briegel | Ex     |
| XR-LL-620 | scan routine which, at a slow      |           | pected |
|           | rate, checks to see if any devices | 12-2007   |        |
|           | have gone into alarm. This routine |           |        |
|           | can be replaced on a               |           |        |
|           | device-by-device basis if a        |           |        |
|           | different strategy is required.    |           |        |
+-----------+------------------------------------+-----------+--------+
| C         | There shall be support for         | D         | Ex     |
| XR-LL-625 | multiple alarm blocks selected by  | .Nicklaus | pected |
|           | event.                             |           |        |
|           |                                    | 1-2008    |        |
+-----------+------------------------------------+-----------+--------+
| C         | Analog devices have alarm          | C.Briegel | Ex     |
| XR-LL-640 | constraints represented by maximum |           | pected |
|           | and minimum values.                | 12-2007   |        |
+-----------+------------------------------------+-----------+--------+
| C         | Digital devices have alarm         | C.Briegel | Ex     |
| XR-LL-650 | constraints represented by a       |           | pected |
|           | bit-mask and pattern-match.        | 12-2007   |        |
+-----------+------------------------------------+-----------+--------+
| C         | A device shall be constrained by a | C.Briegel | D      |
| XR-LL-660 | user-defined constraint.           |           | esired |
|           |                                    | 12-2007   |        |
+-----------+------------------------------------+-----------+--------+
| C         | All alarms shall have a            | C.Briegel | Ex     |
| XR-LL-670 | consecutive alarm threshold.       |           | pected |
|           |                                    | 12-2007   |        |
+-----------+------------------------------------+-----------+--------+
| C         | All alarms shall have the ability  | C.Briegel | Ex     |
| XR-LL-680 | to pull a software abort.          |           | pected |
|           |                                    | 12-2007   |        |
+-----------+------------------------------------+-----------+--------+
| C         | All alarms shall have the ability  | C.Briegel | Ex     |
| XR-LL-690 | to set a device.                   |           | pected |
|           |                                    | 12-2007   |        |
+-----------+------------------------------------+-----------+--------+
| C         | All alarms shall have the ability  | C.Briegel | Ex     |
| XR-LL-700 | to provide an unsolicited alarm    |           | pected |
|           | notification to a specified set of | 12-2007   |        |
|           | servers.                           |           |        |
+-----------+------------------------------------+-----------+--------+
| C         | There shall be event alarms, which | C.Briegel | Ex     |
| XR-LL-710 | are notifications without a clear  |           | pected |
|           | of the event.                      | 12-2007   |        |
+-----------+------------------------------------+-----------+--------+
| C         | There shall be exception alarms,   | C.Briegel | Ex     |
| XR-LL-720 | such as analog reading, digital    |           | pected |
|           | status, and alarm setting alarms.  | 12-2007   |        |
+-----------+------------------------------------+-----------+--------+
| C         | One shall be able to individually  | C.Briegel | Ex     |
| XR-LL-730 | bypass an alarm.                   |           | pected |
|           |                                    | 12-2007   |        |
+-----------+------------------------------------+-----------+--------+
| C         | Alarms shall be able to be grouped | C.Briegel | Ex     |
| XR-LL-740 | together and be bypassed as a      |           | pected |
|           | group.                             | 12-2007   |        |
+-----------+------------------------------------+-----------+--------+

### Reliability Requirements

The following requirements improve the reliability of the network
protocol.

+----------+---------------------------------+--------------+--------+
| **No.**  | **Requirement**                 | **Source**   | **Prio |
|          |                                 |              | rity** |
+==========+=================================+==============+========+
| CX       | Network packets shall be        | R.Neswold    | Ex     |
| R-LL-750 | acknowledged (or the reply      |              | pected |
|          | itself be sent) within 100ms of | 12-2007      |        |
|          | reception.                      |              |        |
+----------+---------------------------------+--------------+--------+
| CX       | Long-term, slow frequency       | R.Neswold    | Ex     |
| R-LL-760 | connections shall provide a     |              | pected |
|          | "keep-alive" status to be able  | 12-2007      |        |
|          | to detect broken or closed      |              |        |
|          | connections.                    |              |        |
+----------+---------------------------------+--------------+--------+
| CX       | The front-end infrastructure    | R.           | D      |
| R-LL-770 | shall be able to report, within | Rechenmacher | esired |
|          | a few seconds, the              |              |        |
|          | flows/connections to front-ends | 12-2007      |        |
|          | that do not involve             |              |        |
|          | \"standard\" front-end          |              |        |
|          | interface ports.                |              |        |
+----------+---------------------------------+--------------+--------+

# Central Services

A trivial control system can be built of just two parts: a set of
low-level equipment front-ends and a set of high-level user
applications. Both sides talk to each other through some common
protocol, so that the front-ends\' data is reflected in the
applications, as well as the user\'s actions are reflected in the
equipment.

The larger the system grows, the less this simple model can satisfy its
demands:

1.  There is no provision of data relevant to the entire system, such as
    a list of equipment.

2.  The number of possible interconnections increases exponentially,
    causing addressing, performance, and licensing issues.

3.  It becomes harder to maintain uniform implementations of the common
    communication protocol throughout the system, so applications may
    have to talk differently with different equipment.

4.  It becomes harder to add new features into all the front-ends, such
    as authentication or archiving mechanisms.

5.  It is difficult to implement a function that would involve a number
    of distributed front-ends at the same time, such as a transaction
    service.

In this document the term *Central Service* refers to a system supplying
the common needs of both high-level applications and front-ends, and
directly accessible through some sort of external calls. For each
service we describe functional requirements, as well as essential
features of its external interface. The latter should be applied to an
API used by the clients, which include high-level user applications,
front-ends, and other central services.

+-----------+---------------------------------+-----------+-----------+
| **No.**   | **Requirement**                 | *         | **P       |
|           |                                 | *Source** | riority** |
+-----------+---------------------------------+-----------+-----------+
| CXR-CS-10 | Each central service shall      | A. Petrov | Expected  |
|           | include a graphical user        |           |           |
|           | interface (GUI) for remote      | 12-2007   |           |
|           | configuration and monitoring.   |           |           |
+-----------+---------------------------------+-----------+-----------+
| CXR-CS-20 | Each central service shall      | A. Petrov | Expected  |
|           | report its internal status      |           |           |
|           | through the Data Acquisition    | 12-2007   |           |
|           | Service \[4.2\].                |           |           |
+-----------+---------------------------------+-----------+-----------+
| CXR-CS-25 | The central services shall be   | A. Petrov | Desired   |
|           | scalable downward to a portable |           |           |
|           | minimalistic version capable to | 01-2008   |           |
|           | provide basic functionality for |           |           |
|           | an autonomous control system.   |           |           |
+-----------+---------------------------------+-----------+-----------+

## Naming Service

Many classes of objects inside control systems are traditionally
addressed by name. These can be front-ends, devices, events, datalogging
channels, and error descriptors. Normally, the information about every
entity is stored in a relational database, so it can be easily retrieved
by applications. In practice, however, this can be affected by a number
of issues:

-   A limited amount of available database connections.

-   The lack of direct connectivity due to security constraints.

-   The need to know an exact structure of the database records for
    every class of objects, or an algorithm to extract the records from
    a legacy system.

-   The data about a single class of objects can be stored in several
    separate databases.

A central Naming Service provides the clients with a set of
characteristics for every named entry. For certain classes of objects,
an implementation of a new data repository may not be necessary, because
this information can already be retrieved from existing legacy systems.
Regardless of how the data is actually stored, the Naming Service
provides a uniform mechanism to lookup entries; browse, search, and
modify the data.

+-----------+---------------------------------+-----------+-----------+
| **No.**   | **Requirement**                 | *         | **P       |
|           |                                 | *Source** | riority** |
+-----------+---------------------------------+-----------+-----------+
| CXR-CS-30 | The control system shall        | A. Petrov | Critical  |
|           | implement a central Naming      |           |           |
|           | Service providing arbitrary     | 12-2007   |           |
|           | descriptive information about   |           |           |
|           | various classes of objects in   |           |           |
|           | the control system through a    |           |           |
|           | commonly accepted protocol.     |           |           |
+-----------+---------------------------------+-----------+-----------+
| CXR-CS-40 | All entries shall be logically  | A. Petrov | Critical  |
|           | arranged in a tree.             |           |           |
|           |                                 | 12-2007   |           |
+-----------+---------------------------------+-----------+-----------+
| CXR-CS-50 | Each entry and intermediate     | A. Petrov | Critical  |
|           | node shall have a unique name.  |           |           |
|           |                                 | 12-2007   |           |
+-----------+---------------------------------+-----------+-----------+
| CXR-CS-55 | It shall be possible to create  | A. Petrov | Expected  |
|           | aliases (symbolic links)        |           |           |
|           | pointing to existing entries.   | 01-2008   |           |
+-----------+---------------------------------+-----------+-----------+
| CXR-CS-60 | Deleted entries shall be marked | A. Petrov | Critical  |
|           | with a special attribute and    |           |           |
|           | preserved for future reference. | 01-2008   |           |
+-----------+---------------------------------+-----------+-----------+
| CXR-CS-70 | For names of entries and        | A. Petrov | Critical  |
|           | intermediate nodes, the Naming  |           |           |
|           | Service shall mandate the       | 12-2007   |           |
|           | character set, delimiter and    |           |           |
|           | escape characters, and a        |           |           |
|           | definition of uniqueness.       |           |           |
+-----------+---------------------------------+-----------+-----------+
| CXR-CS-80 | At a minimum, each entry shall  | A. Petrov | Expected  |
|           | consist of a set of named       |           |           |
|           | characteristics.                | 12-2007   |           |
+-----------+---------------------------------+-----------+-----------+
| CXR-CS-90 | For characteristic names, the   | A. Petrov | Critical  |
|           | Naming Service shall mandate    |           |           |
|           | the character set.              | 12-2007   |           |
+-----------+---------------------------------+-----------+-----------+
| C         | The characteristic values shall | A. Petrov | Desired   |
| XR-CS-100 | be type-safe.                   |           |           |
|           |                                 | 12-2007   |           |
+-----------+---------------------------------+-----------+-----------+
| C         | It shall be possible to specify | A. Petrov | Desired   |
| XR-CS-110 | a set of required and optional  |           |           |
|           | characteristics for different   | 12-2007   |           |
|           | classes of objects.             |           |           |
+-----------+---------------------------------+-----------+-----------+
| C         | The Naming Service shall        | A. Petrov | Critical  |
| XR-CS-120 | support, but not mandate,       |           |           |
|           | client authentication.          | 12-2007   |           |
+-----------+---------------------------------+-----------+-----------+
| C         | It shall be possible to specify | A. Petrov | Expected  |
| XR-CS-130 | read and write permissions for  |           |           |
|           | a principal on a class of       | 12-2007   |           |
|           | objects, and default            |           |           |
|           | permissions on all classes that |           |           |
|           | are not the subject of explicit |           |           |
|           | access control.                 |           |           |
+-----------+---------------------------------+-----------+-----------+
| C         | Existing entries shall          | T.        | Expected  |
| XR-CS-140 | [not]{.underline} be altered or | Bolshakov |           |
|           | reused in a way that            |           |           |
|           | invalidates the data stored in  | W. Marsh  |           |
|           | dataloggers and other long-term |           |           |
|           | archives.                       | 01-2008   |           |
+-----------+---------------------------------+-----------+-----------+
| C         | The Naming Service shall        | A. Petrov | Critical  |
| XR-CS-150 | mandate an entry serialization  |           |           |
|           | protocol.                       | 12-2007   |           |
+-----------+---------------------------------+-----------+-----------+
| C         | A client shall be able to       | A. Petrov | Critical  |
| XR-CS-160 | retrieve any entry by name.     |           |           |
|           |                                 | 12-2007   |           |
+-----------+---------------------------------+-----------+-----------+
| C         | A client shall be able to       | A. Petrov | Critical  |
| XR-CS-170 | retrieve the set of children of |           |           |
|           | any intermediate node.          | 12-2007   |           |
+-----------+---------------------------------+-----------+-----------+
| C         | A client shall be able to       | A. Petrov | Critical  |
| XR-CS-180 | search entries in a subtree by  |           |           |
|           | name, by presence of            | 12-2007   |           |
|           | characteristics, and by         |           |           |
|           | characteristic values.          |           |           |
+-----------+---------------------------------+-----------+-----------+
| C         | A client shall be able to       | A. Petrov | Critical  |
| XR-CS-190 | create new entries, modify      |           |           |
|           | characteristics of existing     | 12-2007   |           |
|           | entries, and delete existing    |           |           |
|           | entries.                        |           |           |
+-----------+---------------------------------+-----------+-----------+

## Data Acquisition Service

The purpose of a central Data Acquisition Service (DAQ) is to mediate in
the real-time communication of data between the front-ends and the
clients.

The front-ends provide data through individually addressable *devices*.
Devices can be combined in groups to represent a machine, a subsystem,
or a front-end. The *events* are generated by the control\'s timing
infrastructure (XCLK, 3.1.1\]), device state transitions, wall clock,
and software. As the requirements do not prescribe any concrete model
for devices and events, these terms here are provisional.

It is expected that the Data Acquisition Service may use different
protocols to communicate with front-ends and with high-level
applications, because the requirements (speed, security) on these levels
may vary. However, it is desirable to use same data formats on both
sides, so that the data samples \[4.2.1\] could come through the central
layer transparently in either direction.

+------------+--------------------------------+-----------+-----------+
| **No.**    | **Requirement**                | *         | **P       |
|            |                                | *Source** | riority** |
+------------+--------------------------------+-----------+-----------+
| CXR-CS-200 | The control system shall       | A. Petrov | Critical  |
|            | implement a central Data       |           |           |
|            | Acquisition Service (DAQ).     | 12-2007   |           |
+------------+--------------------------------+-----------+-----------+
| CXR-CS-210 | The DAQ shall provide data     | A. Petrov | Critical  |
|            | through a single Data          |           |           |
|            | Acquisition API (DAQ API). The | 12-2007   |           |
|            | DAQ API shall specify a device |           |           |
|            | model, an event model, and     |           |           |
|            | data abstractions.             |           |           |
+------------+--------------------------------+-----------+-----------+
| CXR-CS-220 | Each device in the control     | A. Petrov | Critical  |
|            | system shall be uniquely       |           |           |
|            | identified by its name.[^1]    | 12-2007   |           |
+------------+--------------------------------+-----------+-----------+
| CXR-CS-230 | The definition of devices      | A. Petrov | Expected  |
|            | shall be provided through the  |           |           |
|            | Naming Service.                | 01-2008   |           |
+------------+--------------------------------+-----------+-----------+
| CXR-CS-240 | It shall be possible to        | A. Petrov | Critical  |
|            | express each event as a text   |           |           |
|            | string containing the event    | 12-2007   |           |
|            | type, a unique event           |           |           |
|            | identifier within the type, as |           |           |
|            | a set of parameters.           |           |           |
+------------+--------------------------------+-----------+-----------+
| CXR-CS-250 | The definition of XCLK events  | A. Petrov | Expected  |
|            | and software events shall be   |           |           |
|            | provided through the Naming    | 01-2008   |           |
|            | Service.                       |           |           |
+------------+--------------------------------+-----------+-----------+
| CXR-CS-260 | A client shall be able to      | A. Petrov | Critical  |
|            | acquire data from a device in  |           |           |
|            | one blocking operation.        | 12-2007   |           |
+------------+--------------------------------+-----------+-----------+
| CXR-CS-270 | A client shall be able to      | A. Petrov | Expected  |
|            | acquire data from a device on  |           |           |
|            | an event in one blocking       | 12-2007   |           |
|            | operation. If the event did    |           |           |
|            | not occur in a certain time    |           |           |
|            | frame, the call shall abort.   |           |           |
+------------+--------------------------------+-----------+-----------+
| CXR-CS-280 | A client shall be able to      | A. Petrov | Expected  |
|            | monitor a group of devices. A  |           |           |
|            | change of any device in the    | 12-2007   |           |
|            | group shall cause a callback   |           |           |
|            | containing the new data.       |           |           |
+------------+--------------------------------+-----------+-----------+
| CXR-CS-290 | A client shall be able to      | A. Petrov | Critical  |
|            | monitor a group of devices on  |           |           |
|            | an event. The event shall      | 12-2007   |           |
|            | cause a callback containing a  |           |           |
|            | snapshot of all the devices\'  |           |           |
|            | data.                          |           |           |
+------------+--------------------------------+-----------+-----------+
| CXR-CS-300 | A client shall be able to      | A. Petrov | Expected  |
|            | limit the maximum rate of the  |           |           |
|            | data returned through          | 01-2008   |           |
|            | callbacks.                     |           |           |
+------------+--------------------------------+-----------+-----------+
| CXR-CS-310 | A client shall be able to set  | A. Petrov | Critical  |
|            | data to a device in one        |           |           |
|            | blocking operation.            | 12-2007   |           |
+------------+--------------------------------+-----------+-----------+
| CXR-CS-320 | A client shall be able to      | A. Petrov | Critical  |
|            | generate software events.      |           |           |
|            |                                | 01-2008   |           |
+------------+--------------------------------+-----------+-----------+
| CXR-CS-330 | A client shall be able to      | A. Petrov | Expected  |
|            | monitor a group of events.     |           |           |
|            | Each event occurrence shall    | 01-2008   |           |
|            | cause a callback containing    |           |           |
|            | the event identifier and a     |           |           |
|            | timestamp.                     |           |           |
+------------+--------------------------------+-----------+-----------+
| CXR-CS-340 | A client shall be able to set  | A. Petrov | Desired   |
|            | data synchronously to a group  |           |           |
|            | of devices using distributed   | 01-2008   |           |
|            | transactions \[CXR-LL-580\].   |           |           |
+------------+--------------------------------+-----------+-----------+

### Data Abstractions

In this document, an elementary quantum of data handled by the Data
Acquisition Service is called *a sample*. Each sample represents an
atomic reading from (or setting to) a front-end. At runtime, samples
exist as programmatic objects or structures specified in DAQ API.
Whereas a particular format of these artefacts is not important for the
requirements, it is essential that every sample can be rendered in three
tangible forms:

-   **Visual Representation,** a text string or an image suitable for
    human users.

-   **Transport Format,** used to send the sample over network.

-   **Persistent Format,** used to store the sample for a prolonged
    time.

The visualization function is specific to every class of objects. It
needs to provide, perhaps, only a one-way transformation. The
serialization mechanisms for transport and persistent formats shall be
defined in the scope of the entire system, and have to work in both
directions.

A sample consists of three parts: *a timestamp*, *a payload*, and
*a status.* The Data Acquisition Service may parse and use the sample\'s
timestamp and status. The payload is always application-specific and
needs to be passed between front-ends and user applications unchanged.

The sample\'s payload is a collection of values and attributes. Each
value represents the result of an actual measurement (for example, an
ADC output) or a calculation, which can change over time. Multiple
values in a single sample are allowed because some phenomena or
processes have to be observed simultaneously at several points. The
attributes provide descriptive information either about individual
values (for example, a units text) or about the entire sample.
Properties of the sample\'s data source, such as a device name, should
not be included. The attributes are close to being constant, but they
may occasionally change if the system is reconfigured. This fact must be
considered in the design of the transport and persistent formats. For
example, when samples are sent over network, some static information can
be omitted to save bandwidth, providing that later on this data will be
restored by other means. But when samples are archived, all their
attributes shall be retained.

The DAQ API can provide multiple implementations of generic data types
used as a payload, including a simple container holding one attributed
value, an array of multiple attributed values, and more complex
hierarchical formations. Also, the system can offer more specific
structures for certain groups of applications, such as Wire Scanners.
The clients must be able to properly interpret all applicable data
types.

The sample\'s timestamp identifies a time when the measurement of the
sample occurred. This can include the absolute calendar time, as well as
time relative to certain system events (e.g., beam cycle).

The sample\'s status field \[CXR-LL-415\] indicates whether the reading
operation was successful. It may also include additional information
about conditions of the data acquisition (e.g., if the device has not
responded properly) useful for a client .

For efficiency or logical harmony the control system may combine
individual samples into *time sequential groups (TSG)*. Each TSG
represents a temporal sequence of data as a whole. For example, a fast
transient process recorded by a digital oscilloscope can be received on
the client as a single TSG, rather than a long stream of individual
readings. The TSG itself does not hold a timestamp and a status field.

+-----------+---------------------------------+------------+----------+
| **No.**   | **Requirement**                 | **Source** | **Pr     |
|           |                                 |            | iority** |
+-----------+---------------------------------+------------+----------+
| C         | Each distinct data sample       | A. Petrov, | Critical |
| XR-CS-400 | handled by the Data Acquisition |            |          |
|           | Service shall include a         | R. Neswold |          |
|           | timestamp, a payload, and a     |            |          |
|           | status field.                   | 01-2008    |          |
+-----------+---------------------------------+------------+----------+
| C         | The timestamp shall include     | A. Petrov  | Critical |
| XR-CS-410 | absolute Coordinated Universal  |            |          |
|           | Time (UTC) of the sample.       | 01-2008    |          |
+-----------+---------------------------------+------------+----------+
| C         | It shall be possible to include | A. Petrov  | Desired  |
| XR-CS-415 | additional references in the    |            |          |
|           | timestamp, expressed as an      | 01-2008    |          |
|           | amount of time passed since a   |            |          |
|           | certain instance of an event    |            |          |
|           | (using per-event counters       |            |          |
|           | \[CXR-LL-90\]).                 |            |          |
+-----------+---------------------------------+------------+----------+
| C         | The DAQ shall be able to        | A. Petrov, | Critical |
| XR-CS-420 | acquire samples in time         |            |          |
|           | sequential groups (TSG).        | B.         |          |
|           |                                 | Hendricks  |          |
|           |                                 |            |          |
|           |                                 | 01-2008    |          |
+-----------+---------------------------------+------------+----------+
| C         | A client shall be able to limit | A. Petrov  | Expected |
| XR-CS-430 | the maximum number of samples   |            |          |
|           | returned from a device in one   | 01-2008    |          |
|           | call.                           |            |          |
+-----------+---------------------------------+------------+----------+
| C         | The DAQ shall mandate           | A. Petrov  | Critical |
| XR-CS-440 | serialization protocols for DAQ |            |          |
|           | samples and TSG sent over       | 12-2007    |          |
|           | network.                        |            |          |
+-----------+---------------------------------+------------+----------+
| C         | The DAQ shall mandate           | A. Petrov  | Critical |
| XR-CS-450 | serialization protocols for DAQ |            |          |
|           | samples and TSG stored for      | 12-2007    |          |
|           | prolonged time.                 |            |          |
+-----------+---------------------------------+------------+----------+
| C         | The DAQ sample\'s payload shall | A. Petrov  | Expected |
| XR-CS-460 | be a collection of values and   |            |          |
|           | attributes. The values          | 12-2007    |          |
|           | represent the results of actual |            |          |
|           | measurements. The attributes    |            |          |
|           | contain descriptive information |            |          |
|           | about individual values and the |            |          |
|           | entire sample.                  |            |          |
+-----------+---------------------------------+------------+----------+
| C         | The shall be a description of   | A. Petrov  | Desired  |
| XR-CS-470 | each device\'s data structures. |            |          |
|           |                                 | B.         |          |
|           |                                 | Hendricks  |          |
|           |                                 |            |          |
|           |                                 | 01-2008    |          |
+-----------+---------------------------------+------------+----------+
| C         | The DAQ shall not interpret or  | A. Petrov  | Expected |
| XR-CS-490 | modify samples\' payloads.[^2]  |            |          |
|           |                                 | 12-2007    |          |
+-----------+---------------------------------+------------+----------+
| C         | The DAQ API shall provide       | A. Petrov  | Critical |
| XR-CS-500 | implementations of generic data |            |          |
|           | types.                          | 12-2007    |          |
+-----------+---------------------------------+------------+----------+
| C         | The DAQ API shall provide       | A. Petrov  | Desired  |
| XR-CS-510 | implementations of data types,  |            |          |
|           | specific to common domains of   | 12-2007    |          |
|           | applications.                   |            |          |
+-----------+---------------------------------+------------+----------+
| C         | For each data type, the DAQ API | A. Petrov  | Critical |
| XR-CS-520 | shall support a mechanism of    |            |          |
|           | conversion to a human-readable  | 12-2007    |          |
|           | format.                         |            |          |
+-----------+---------------------------------+------------+----------+
| C         | The DAQ API shall explicitly    | A. Petrov  | Expected |
| XR-CS-530 | define the use of special       |            |          |
|           | values, such as *Null*,         | 01-2008    |          |
|           | *Infinity*, and *NaN* in        |            |          |
|           | samples, timestamps, payloads,  |            |          |
|           | and status fields.              |            |          |
+-----------+---------------------------------+------------+----------+

### Acquisition of Alarms

Alarms are a special kind of data generated by the front-ends. Each
alarm indicates an abnormal condition in the equipment, for example when
device data is out of band. The Data Acquisition Service shall acquire
alarms from the front-ends in the same way it acquires and processes any
other data, with a few exceptions stated below.

+------------+-------------------------------+------------+-----------+
| **No.**    | **Requirement**               | **Source** | **P       |
|            |                               |            | riority** |
+------------+-------------------------------+------------+-----------+
| CXR-CS-540 | The DAQ API shall provide a   | A. Petrov  | Critical  |
|            | data abstraction for alarms.  |            |           |
|            | At a minimum, an alarm        | 12-2007    |           |
|            | abstraction shall include an  |            |           |
|            | alarm state indicator and a   |            |           |
|            | bypass state indicator.       |            |           |
+------------+-------------------------------+------------+-----------+
| CXR-CS-550 | Each alarm in the control     | A. Petrov  | Critical  |
|            | system shall be uniquely      |            |           |
|            | identified by its name.       | 12-2007    |           |
+------------+-------------------------------+------------+-----------+
| CXR-CS-560 | The definition of alarms      | A. Petrov  | Expected  |
|            | shall be provided through the |            |           |
|            | Naming Service.               | 01-2008    |           |
+------------+-------------------------------+------------+-----------+
| CXR-CS-570 | A client shall be able to     | A. Petrov  | Critical  |
|            | change the bypass state of an |            |           |
|            | alarm device in one blocking  | 12-2007    |           |
|            | operation \[CXR-LL-730\].     |            |           |
+------------+-------------------------------+------------+-----------+
| CXR-CS-580 | Changes of the bypass state   | A. Petrov  | Critical  |
|            | of an alarm device shall      |            |           |
|            | [not]{.underline} trigger the | 12-2007    |           |
|            | monitors set by clients.      |            |           |
+------------+-------------------------------+------------+-----------+
| CXR-CS-590 | If an alarm device is         | A. Petrov  | Critical  |
|            | "bypassed", changes of its    |            |           |
|            | alarm state shall             | 12-2007    |           |
|            | [not]{.underline} trigger the |            |           |
|            | monitors set by clients.      |            |           |
+------------+-------------------------------+------------+-----------+

### Front-End Façade

It is hard to achieve a complete unification of low-level equipment in a
real-world control system. Most likely, the entire collection of
front-ends will not fully support one common set of functions and will
not be able to speak exactly one communication protocol. The higher
level components have to consider the equipment diversity and address it
accordingly. As it would be too complex to design and too burdensome to
maintain a large number of end-user applications able to talk
individually to every piece of equipment, the front-end façade service
takes over the responsibility to cast all front-end communications into
one unified form.

+-----------+-----------------------------------+------------+---------+
| **No.**   | **Requirement**                   | **Source** | **Pri   |
|           |                                   |            | ority** |
+-----------+-----------------------------------+------------+---------+
| C         | The Data Acquisition Service      | A. Petrov  | C       |
| XR-CS-600 | shall support multiple types of   |            | ritical |
|           | front-ends and multiple           | 12-2007    |         |
|           | protocols.                        |            |         |
+-----------+-----------------------------------+------------+---------+
| C         | The Data Acquisition Service      | A. Petrov  | E       |
| XR-CS-610 | shall support pluggable adapters  |            | xpected |
|           | to particular front-end types,    | 12-2007    |         |
|           | linked dynamically at runtime.    |            |         |
+-----------+-----------------------------------+------------+---------+
| C         | The semantic of each DAQ API call | A. Petrov  | C       |
| XR-CS-620 | shall be constant, unrelated to   |            | ritical |
|           | the type of front-end targeted.   | 12-2007    |         |
+-----------+-----------------------------------+------------+---------+
| C         | The Data Acquisition Service      | A. Petrov  | C       |
| XR-CS-630 | shall emulate the features of DAQ |            | ritical |
|           | API missing from particular       | 12-2007    |         |
|           | front-end implementations.        |            |         |
+-----------+-----------------------------------+------------+---------+

### Data Redirection

Normally, a control system operates with devices connected to the real
equipment front-ends. The function of data redirection replaces,
transparently to clients, the entire set of "real" devices with a
programmatically created one. There is a number of useful models that
can be employed in data redirection, for example:

-   **Setting Mirror** ---a snapshot of data represented in a memory
    model, that can be updated without addressing actual equipment.

-   **Retrospection** ---a playback of data from an archive.

-   **Physical Model** ---emulates behaviour of the machine according to
    some theoretical principles.

+-------------+-------------------------------+------------+-----------+
| **No.**     | **Requirement**               | **Source** | **P       |
|             |                               |            | riority** |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-650  | The Data Acquisition Service  | A. Petrov  | Critical  |
|             | shall support data            |            |           |
|             | redirection.                  | 12-2007    |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-660  | The Data Acquisition Service  | A. Petrov  | Expected  |
|             | shall support pluggable       |            |           |
|             | implementations of            | 12-2007    |           |
|             | redirection models, linked    |            |           |
|             | dynamically at runtime.       |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-670  | The semantic of each DAQ API  | A. Petrov  | Critical  |
|             | call shall be constant,       |            |           |
|             | unrelated to the presence and | 12-2007    |           |
|             | the model of redirection.     |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-680  | The common GUI shall include  | A. Petrov  | Expected  |
|             | a visual indicator of the     |            |           |
|             | data redirection status.      | 12-2007    |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-690  | It shall be possible to       | A. Petrov  | Desired   |
|             | operate data redirection from |            |           |
|             | both the application and the  | 12-2007    |           |
|             | central service.              |            |           |
+-------------+-------------------------------+------------+-----------+

### Interoperability

Several issues arise from the fact that the entire Data Acquisition
Service may consist of multiple programming instances distributed
throughout the control system.

+-------------+-------------------------------+------------+-----------+
| **No.**     | **Requirement**               | **Source** | **P       |
|             |                               |            | riority** |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-700  | Remote links inside the DAQ   | A. Petrov  | Critical  |
|             | shall be transparent. The     |            |           |
|             | control system shall attempt  | 12-2007    |           |
|             | to recover lost connections   |            |           |
|             | and restore internal states   |            |           |
|             | of the peers.                 |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-710  | The DAQ shall automatically   | A. Petrov  | Critical  |
|             | adjust to the actual number   |            |           |
|             | of running instances.         | 12-2007    |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-720  | It shall be possible to       | A. Petrov  | Expected  |
|             | reconfigure the control       |            |           |
|             | system without a restart.     | 12-2007    |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-730  | Each DAQ instance shall       | A. Petrov  | Expected  |
|             | provide an equal set of       |            |           |
|             | functions for the clients,    | 12-2007    |           |
|             | including access to the       |            |           |
|             | entire set of devices.        |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-740  | A client shall                | A. Petrov  | Critical  |
|             | [not]{.underline} be required |            |           |
|             | to choose which DAQ instance  | 12-2007    |           |
|             | to connect.                   |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-750  | The control system shall      | A. Petrov  | Expected  |
|             | remain operational if         |            |           |
|             | multiple nodes fail.          | 12-2007    |           |
+-------------+-------------------------------+------------+-----------+

### Data Consolidation

The volume of user requests to the low-level equipment in a control
system is unpredictable. In different cycles some data becomes more
important for the machine operation than others, thus attracting more
traffic to the front-ends providing it. As some front-ends (or the
network they are connected to) may not be capable of sustaining the high
load, they can start returning data with delays or deny the service for
some clients altogether. Data Consolidation shields the equipment from
the excessive traffic by acquiring data from each front-end and caching
it internally. All requests from the user applications and other central
services are managed by DAQ data pools and do not address front-ends
directly.

+------------+--------------------------------+-----------+----------+
| **No.**    | **Requirement**                | *         | **Pr     |
|            |                                | *Source** | iority** |
+------------+--------------------------------+-----------+----------+
| CXR-CS-760 | The Data Acquisition Service   | A. Petrov | Critical |
|            | shall support data             |           |          |
|            | consolidation.                 | 12-2007   |          |
+------------+--------------------------------+-----------+----------+
| CXR-CS-770 | The consolidation assignments  | A. Petrov | Critical |
|            | among multiple DAQ nodes shall |           |          |
|            | be defined dynamically.        | 12-2007   |          |
+------------+--------------------------------+-----------+----------+

### Resource Locking

+------------+---------------------------------+-----------+----------+
| **No.**    | **Requirement**                 | *         | **Pr     |
|            |                                 | *Source** | iority** |
+------------+---------------------------------+-----------+----------+
| CXR-CS-800 | A client shall be able to set a | A. Petrov | Expected |
|            | lock on any device or a group   |           |          |
|            | of devices in the control       | 01-2008   |          |
|            | system, in order to prevent     |           |          |
|            | settings from other clients.    |           |          |
+------------+---------------------------------+-----------+----------+
| CXR-CS-810 | Each lock shall be associated   | A. Petrov | Expected |
|            | with an authenticated client\'s |           |          |
|            | principal.                      | 01-2008   |          |
+------------+---------------------------------+-----------+----------+
| CXR-CS-820 | It shall be possible to specify | A. Petrov | Desired  |
|            | an event (including a wall      |           |          |
|            | clock event), which will        | 01-2008   |          |
|            | automatically remove the lock.  |           |          |
+------------+---------------------------------+-----------+----------+
| CXR-CS-830 | A client shall be able to       | A. Petrov | Expected |
|            | remove his own locks.           |           |          |
|            |                                 | 01-2008   |          |
+------------+---------------------------------+-----------+----------+
| CXR-CS-840 | A client with certain access    | A. Petrov | Expected |
|            | privileges shall be able to     |           |          |
|            | remove any lock in the control  | 01-2008   |          |
|            | system.                         |           |          |
+------------+---------------------------------+-----------+----------+
| CXR-CS-850 | A client shall be able to check | A. Petrov | Expected |
|            | whether a device or a group of  |           |          |
|            | devices is locked, and who owns | 01-2008   |          |
|            | the locks.                      |           |          |
+------------+---------------------------------+-----------+----------+
| CXR-CS-860 | If settings to a device are     | A. Petrov | Expected |
|            | prohibited due to a lock, the   |           |          |
|            | client shall receive a clear    | 01-2008   |          |
|            | error message referring to the  |           |          |
|            | lock owner.                     |           |          |
+------------+---------------------------------+-----------+----------+

### Access Control and Audit

+------------+---------------------------------+-----------+----------+
| **No.**    | **Requirement**                 | *         | **Pr     |
|            |                                 | *Source** | iority** |
+------------+---------------------------------+-----------+----------+
| CXR-CS-900 | The Data Acquisition Service    | A. Petrov | Critical |
|            | shall provide access control    |           |          |
|            | and support, but not mandate,   | 12-2007   |          |
|            | client authentication.          |           |          |
+------------+---------------------------------+-----------+----------+
| CXR-CS-910 | It shall be possible to specify | A. Petrov | Expected |
|            | read, set, and lock permissions |           |          |
|            | for a principal on a single     | 12-2007   |          |
|            | device, and on a group of       |           |          |
|            | devices. It shall be possible   |           |          |
|            | to specify default read, set,   |           |          |
|            | and lock permissions for a      |           |          |
|            | principal on all devices that   |           |          |
|            | are not the subject to explicit |           |          |
|            | access control.                 |           |          |
+------------+---------------------------------+-----------+----------+
| CXR-CS-915 | It shall be possible to specify | A. Petrov | Expected |
|            | a permission for a principal to |           |          |
|            | remove any lock in the control  | 01-2008   |          |
|            | system.                         |           |          |
+------------+---------------------------------+-----------+----------+
| CXR-CS-920 | It shall be possible to specify | A. Petrov | Expected |
|            | permissions for a principal to  |           |          |
|            | generate an event, or a group   | 01-2008   |          |
|            | of events. It shall be possible |           |          |
|            | to specify default event        |           |          |
|            | permissions for a principal on  |           |          |
|            | all events that are not the     |           |          |
|            | subject to explicit access      |           |          |
|            | control.                        |           |          |
+------------+---------------------------------+-----------+----------+
| CXR-CS-930 | The Data Acquisition Service    | A. Petrov | Critical |
|            | shall include a mechanism to    |           |          |
|            | disable settings from a client  | 12-2007   |          |
|            | (*a setting lock*). It shall be |           |          |
|            | possible to operate this        |           |          |
|            | mechanism from both an          |           |          |
|            | application and a central       |           |          |
|            | service.                        |           |          |
+------------+---------------------------------+-----------+----------+
| CXR-CS-940 | The common GUI shall include a  | A. Petrov | Expected |
|            | visual indicator of the setting |           |          |
|            | lock status.                    | 12-2007   |          |
+------------+---------------------------------+-----------+----------+
| CXR-CS-950 | The Data Acquisition Service    | A. Petrov | Critical |
|            | shall keep a log of connected   |           |          |
|            | clients.                        | 12-2007   |          |
+------------+---------------------------------+-----------+----------+
| CXR-CS-970 | The Data Acquisition Service    | A. Petrov | Expected |
|            | shall be able to identify       |           |          |
|            | potential misuse of the system  | 12-2007   |          |
|            | by the clients, and keep a log  |           |          |
|            | of these events.                |           |          |
+------------+---------------------------------+-----------+----------+

Note: Settings log requirement a given in CXR-LL-477.

## Alarm Management Service

Alarm Management Service provides additional functions for aggregation
and distribution of alarms in the control system.

+------------+-------------------------------+------------+-----------+
| **No.**    | **Requirement**               | **Source** | **P       |
|            |                               |            | riority** |
+------------+-------------------------------+------------+-----------+
| CXR-CS-999 | The control system shall      | A. Petrov  | Critical  |
|            | implement a central Alarm     |            |           |
|            | Management Service.           | 01-2008    |           |
+------------+-------------------------------+------------+-----------+
| C          | The Alarm Management Service  | A. Petrov  | Critical  |
| XR-CS-1000 | shall implement a mechanism   |            |           |
|            | which combines multiple       | 01-2008    |           |
|            | front-end alarms in a single  |            |           |
|            | aggregated alarm, using       |            |           |
|            | boolean expressions.          |            |           |
+------------+-------------------------------+------------+-----------+
| C          | DAQ API shall operate with    | A. Petrov  | Expected  |
| XR-CS-1010 | aggregated alarms in the same |            |           |
|            | way it works with front-end   | 01-2008    |           |
|            | alarms.                       |            |           |
+------------+-------------------------------+------------+-----------+
| C          | The Alarm Management Service  | A. Petrov  | Critical  |
| XR-CS-1020 | shall provide a GUI for       |            |           |
|            | configuration of aggregated   | 01-2008    |           |
|            | alarms.                       |            |           |
+------------+-------------------------------+------------+-----------+
| C          | The Alarm Management Service  | A. Petrov  | Expected  |
| XR-CS-1030 | shall provide a mechanism for |            |           |
|            | notifying users about alarms  | 01-2008    |           |
|            | via email.                    |            |           |
+------------+-------------------------------+------------+-----------+
| C          | The Alarm Management Service  | A. Petrov  | Desired   |
| XR-CS-1040 | shall support integration     |            |           |
|            | with notification mechanisms  | 01-2008    |           |
|            | other than email.             |            |           |
+------------+-------------------------------+------------+-----------+
| C          | The Alarm Management Service  | A. Petrov  | Critical  |
| XR-CS-1050 | shall implement access        |            |           |
|            | control and mandate client    | 01-2008    |           |
|            | authentication.               |            |           |
+------------+-------------------------------+------------+-----------+
| C          | The Alarm Management Service  | A. Petrov  | Expected  |
| XR-CS-1052 | shall keep a log of alarm.    |            |           |
|            |                               | 01-2008    |           |
+------------+-------------------------------+------------+-----------+
| C          | For redundancy, the Alarm     | K. Krause  | Critical  |
| XR-CS-1054 | Management Service shall run  |            |           |
|            | in parallel on several nodes. | 01-2008    |           |
+------------+-------------------------------+------------+-----------+
| C          | The Alarm Management Service  | A. Petrov  | Expected  |
| XR-CS-1056 | shall remain operation if     |            |           |
|            | multiple nodes fail.          | 01-2008    |           |
+------------+-------------------------------+------------+-----------+
| C          | The front-ends shall be able  | J. Patrick | Expected  |
| XR-CS-1058 | to push alarm to the Alarm    |            |           |
|            | Management Service.           | 01-2008    |           |
+------------+-------------------------------+------------+-----------+

## Data Logging Service

+-------------+-------------------------------+------------+-----------+
| **No.**     | **Requirement**               | **Source** | **P       |
|             |                               |            | riority** |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1060 | The control system shall      | A. Petrov  | Critical  |
|             | implement a central Data      |            |           |
|             | Logging Service, which        | 01-2008    |           |
|             | includes a number of          |            |           |
|             | multi-channel dataloggers.    |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1070 | Each datalogging channel      | A. Petrov  | Critical  |
|             | shall store data from a       |            |           |
|             | single device, acquired on    | 01-2008    |           |
|             | instances of a single event.  |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1080 | The configuration of          | A. Petrov  | Expected  |
|             | dataloggers and channels      |            |           |
|             | shall be provided through the | 01-2008    |           |
|             | Naming Service.               |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1090 | Each datalogger shall be      | A. Petrov  | Critical  |
|             | uniquely identified by its    |            |           |
|             | name.                         | 01-2008    |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1100 | Each channel within a         | A. Petrov  | Critical  |
|             | datalogger shall be uniquely  |            |           |
|             | identified by the device and  | 01-2008    |           |
|             | the event.                    |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1110 | It shall be possible to       | A. Petrov  | Expected  |
|             | assign an optional            |            |           |
|             | description and alias to a    | 01-2008    |           |
|             | channel. Each alias shall be  |            |           |
|             | unique within the current     |            |           |
|             | datalogger.                   |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1130 | The Data Logging Service      | A. Petrov  | Critical  |
|             | shall support *direct*        |            |           |
|             | dataloggers, acquiring data   | 01-2008    |           |
|             | from the Data Acquisition     |            |           |
|             | Service.                      |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1140 | The Data Logging Service      | A. Petrov  | Critical  |
|             | shall support *backup*        |            |           |
|             | dataloggers, acquiring data   | 01-2008    |           |
|             | from other datalogging        |            |           |
|             | channels.                     |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1150 | The Data Logging Service      | A. Petrov  | Critical  |
|             | shall support *client*        |            |           |
|             | dataloggers, accepting data   | 01-2008    |           |
|             | from arbitrary external       |            |           |
|             | processes.                    |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1160 | The Data Logging Service      | A. Petrov  | Expected  |
|             | shall mandate authorization   |            |           |
|             | of processes submitting data  | 01-2008    |           |
|             | to the client dataloggers.    |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1170 | The Data Logging Service      | J. Patrick | Expected  |
|             | shall log device access       |            |           |
|             | errors in the same way it     | 01-2008    |           |
|             | logs successful samples.      |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1180 | The Data Logging Service      | A. Petrov  | Critical  |
|             | shall provide data through a  |            |           |
|             | single Data Logging API (DL   | 01-2008    |           |
|             | API). DL API shall reuse the  |            |           |
|             | device model, the event       |            |           |
|             | model, and the data           |            |           |
|             | abstractions from DAQ API.    |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1190 | A client shall be able to     | A. Petrov  | Critical  |
|             | acquire data from a           |            |           |
|             | datalogging channel in one    | 01-2008    |           |
|             | blocking operation.           |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1200 | A client shall be able to     | T.         | Expected  |
|             | acquire data from a           | Bolshakov  |           |
|             | datalogging channel through   |            |           |
|             | asynchronous callbacks.       | 01-2008    |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1210 | The Data Logging Service      | A. Petrov  | Expected  |
|             | shall output data in TSG[^3]: |            |           |
|             |                               | 01-2008    |           |
|             | -   If the channel acquires   |            |           |
|             |     TSGs, it shall return the |            |           |
|             |     same TSGs to clients.     |            |           |
|             |                               |            |           |
|             | -   If the channel acquires   |            |           |
|             |     discrete samples, it      |            |           |
|             |     shall pack them into      |            |           |
|             |     TSGs.                     |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1220 | A client shall be able to     | A. Petrov  | Expected  |
|             | limit the maximum number of   |            |           |
|             | samples returned from a       | 01-2008    |           |
|             | channel in one call.          |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1230 | A client shall be able to     | A. Petrov  | Critical  |
|             | start/stop data acquisition   |            |           |
|             | in direct and backup          | 01-2008    |           |
|             | dataloggers, and              |            |           |
|             | enable/disable client         |            |           |
|             | dataloggers.                  |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1240 | For a given device, a client  | A. Petrov  | Critical  |
|             | shall be able to obtain the   |            |           |
|             | list of associated direct and | 01-2008    |           |
|             | backup datalogging channels.  |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1250 | For a given datalogging       | A. Petrov  | Critical  |
|             | channel, a client shall be    |            |           |
|             | able to obtain the associated | 01-2008    |           |
|             | device and event, and a       |            |           |
|             | timestamp of the oldest data  |            |           |
|             | sample.                       |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1260 | The Data Logging Service      | A. Petrov  | Critical  |
|             | shall implement access        |            |           |
|             | control and support, but not  | 01-2008    |           |
|             | mandate, client               |            |           |
|             | authentication.               |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1270 | It shall be possible to       | A. Petrov  | Expected  |
|             | specify reading and           |            |           |
|             | operational (start/stop)      | 01-2008    |           |
|             | permissions on a datalogger,  |            |           |
|             | and default permissions an    |            |           |
|             | all dataloggers that are not  |            |           |
|             | the subject of explicit       |            |           |
|             | access control.               |            |           |
+-------------+-------------------------------+------------+-----------+

### Transformations of Archived Data

+-------------+-------------------------------+------------+-----------+
| **No.**     | **Requirement**               | **Source** | **P       |
|             |                               |            | riority** |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1280 | The data logging system shall | A. Petrov  | Expected  |
|             | [not]{.underline} alter the   |            |           |
|             | data stored in the            | 01-2008    |           |
|             | dataloggers.                  |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1290 | The data logging system shall | K. Cahill  | Critical  |
|             | provide a mechanism to        |            |           |
|             | correct data returned from    | 01-2008    |           |
|             | the dataloggers, in order to  |            |           |
|             | offset past measurement       |            |           |
|             | inaccuracies and replace      |            |           |
|             | obsolete data formats.        |            |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1300 | The data logging system shall | T.         | Critical  |
|             | be capable to store a         | Bolshakov  |           |
|             | historical list of correction |            |           |
|             | functions for each device.    | 01-2008    |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1310 | A client shall be able to     | T.         | Critical  |
|             | disable the correction        | Bolshakov  |           |
|             | function.                     |            |           |
|             |                               | 01-2008    |           |
+-------------+-------------------------------+------------+-----------+
| CXR-CS-1320 | A client shall be able to     | T.         | Desired   |
|             | specify a filter to be        | Bolshakov  |           |
|             | applied to the data acquired  |            |           |
|             | from a dataloggers. (For      | 01-2008    |           |
|             | example, if a datalogger      |            |           |
|             | stores arrays of data or some |            |           |
|             | complex data structures, a    |            |           |
|             | client may want to extract    |            |           |
|             | only one element rather than  |            |           |
|             | the entire structure).        |            |           |
+-------------+-------------------------------+------------+-----------+

## Hierarchical Logging Service

The Hierarchical Logging Service (also known as Sequenced Data
Acquisition, SDA) is a multi-stage event-driven datalogging system,
which records only the data that are essential on a particular stages of
machine operation. A generalized model of hierarchical datalogging is
shown on Fig. 1.

![](media/image3.png){width="5.894444444444445in"
height="2.033333333333333in"}*Fig. 1: Model of Hierarchical Datalogging*

The hierarchical datalogging operates with *stages*. Each stage is
associated with a number of events. The events specify conditions upon
which a particular stage starts and finishes. The stages are arranged in
a trees. When a stage starts, it enables all stages on the next level,
so they can start too when appropriate events will occur. When a stage
finishes, it disables all the underlying stages, possibly terminating
those that are still running. Stages on one level can run in parallel.

The stages on the bottom of the hierarchy are called *collections*. Each
collection is an equivalent of a multi-channel datalogger \[4.4\]. Yet,
the collections usually store much less data and may have different
implementations.

The definition of every single top-level stage, along with all stages
and collections lying underneath it, constitute a *shot*. When the
top-level stage of a shot is triggered, the system starts moving through
a sequence of events, and can ultimately reach collections that will
record the necessary data. All stage instances (i.e., stages that have
already "happened" in the past) and collection instances are
individually addressable from the top to the bottom of the hierarchies.

This requirements do not constrain an implementation of hierarchical
dataloggers by prescribing one invariable model. It is assumed that the
control system may have more than one type of hierarchical logging
service, which utilize different mechanisms of storing and accessing the
data, and different state transition rules. In particular, there may be
a separate way of dealing with small frequent shots (also known as
*pulses*).

+-------------+------------------------------+--------------+---------+
| **No.**     | **Requirement**              | **Source**   | **Pri   |
|             |                              |              | ority** |
+-------------+------------------------------+--------------+---------+
| CXR-CS-1330 | The system shall implement a | A. Petrov    | C       |
|             | central Hierarchical Logging |              | ritical |
|             | Service.                     | 01-2008      |         |
+-------------+------------------------------+--------------+---------+
| CXR-CS-1340 | Each shot shall consist of a | T. Bolshakov | E       |
|             | tree, which includes stages  |              | xpected |
|             | and collections.             | 01-2008      |         |
+-------------+------------------------------+--------------+---------+
| CXR-CS-1350 | The number of level for each | T. Bolshakov | E       |
|             | shot shall be constant.      |              | xpected |
|             |                              | 01-2008      |         |
+-------------+------------------------------+--------------+---------+
| CXR-CS-1360 | The stages and collections   | T. Bolshakov | C       |
|             | shall be started and stopped |              | ritical |
|             | on events. If a stage is     | 01-2008      |         |
|             | running, it enables all      |              |         |
|             | stages and collections       |              |         |
|             | underneath.                  |              |         |
+-------------+------------------------------+--------------+---------+
| CXR-CS-1370 | Each collection shall be a   | A. Petrov    | E       |
|             | functional equivalent of a   |              | xpected |
|             | multi-channel datalogger     | 01-2008      |         |
|             | \[4.4\].                     |              |         |
+-------------+------------------------------+--------------+---------+
| CXR-CS-1380 | Each stage and collection    | T. Bolshakov | C       |
|             | shall have an index, unique  |              | ritical |
|             | on the current level within  | 01-2008      |         |
|             | the shot.                    |              |         |
+-------------+------------------------------+--------------+---------+
| CXR-CS-1390 | It shall be possible to      | T. Bolshakov | E       |
|             | assign an optional           |              | xpected |
|             | description and alias to     | 01-2008      |         |
|             | each stage or collection.    |              |         |
|             | The alias shall be unique on |              |         |
|             | the current level within the |              |         |
|             | shot.                        |              |         |
+-------------+------------------------------+--------------+---------+
| CXR-CS-1400 | The definition of shots and  | A. Petrov    | E       |
|             | a list of available          |              | xpected |
|             | collections shall be         | 01-2008      |         |
|             | provided through the Naming  |              |         |
|             | Service.                     |              |         |
+-------------+------------------------------+--------------+---------+
| CXR-CS-1410 | The Hierarchical Logging     | A. Petrov    | C       |
|             | Service shall implement      |              | ritical |
|             | access control and support,  | 01-2008      |         |
|             | but not mandate, client      |              |         |
|             | authentication.              |              |         |
+-------------+------------------------------+--------------+---------+
| CXR-CS-1420 | It shall be possible to      | A. Petrov    | E       |
|             | specify permissions to       |              | xpected |
|             | reconfigure shots,           | 01-2008      |         |
|             | permissions to read data     |              |         |
|             | from collections that belong |              |         |
|             | to a particular shot, and    |              |         |
|             | default reading permissions  |              |         |
|             | on all shots that are not    |              |         |
|             | the subject of explicit      |              |         |
|             | access control.              |              |         |
+-------------+------------------------------+--------------+---------+

## Postmortem Logging Service

In this section, the term *postmortem logging* refers to the acquisition
of data immediately preceding a failure of the system in a large scale
(e.g., accelerator quench). It does not cover various specialized
postmortem tools, such as operating systems\' core dumps or front-end
debugging facilities.

+-------------+--------------------------------+-------------+---------+
| **No.**     | **Requirement**                | **Source**  | **Pri   |
|             |                                |             | ority** |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1430 | The control system shall       | A. Petrov   | C       |
|             | implement a central Postmortem |             | ritical |
|             | Logging Service, which         | 01-2008     |         |
|             | orchestrate the collection and |             |         |
|             | distribution of postmortem     |             |         |
|             | data.                          |             |         |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1435 | The Postmortem Logging Service | A. Petrov   | E       |
|             | shall use a "snapshot on       |             | xpected |
|             | event" function \[CXR-LL-530\] | C. Briegel  |         |
|             | on front-ends. (A snapshots    |             |         |
|             | may include the data           | 01-2008     |         |
|             | [before]{.underline} the       |             |         |
|             | event, or the data [before and |             |         |
|             | after]{.underline} the event). |             |         |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1440 | The Postmortem Logging Service | A. Petrov   | E       |
|             | shall emulate the "snapshot on |             | xpected |
|             | event" function, if it is      | 01-2008     |         |
|             | missing in a front-end.        |             |         |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1445 | The Postmortem Logging Service | A. Petrov   | E       |
|             | shall be responsible for the   |             | xpected |
|             | snapshot configuration in      | 01-2008     |         |
|             | front-ends.                    |             |         |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1450 | Upon a critical event, the     | K. Cahill   | C       |
|             | Postmortem Logging Service     |             | ritical |
|             | shall collect data from        | 01-2008     |         |
|             | front-ends and store it in a   |             |         |
|             | central datalogger.            |             |         |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1460 | Upon collection of postmortem  | K. Cahill   | C       |
|             | data, the Postmortem Logging   |             | ritical |
|             | Service shall trigger an event | 01-2008     |         |
|             | to notify the clients.         |             |         |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1470 | Each postmortem logging        | A. Petrov   | C       |
|             | channel shall be uniquely      |             | ritical |
|             | identified by the associated   | 01-2008     |         |
|             | device.                        |             |         |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1480 | The configuration of each      | A. Petrov   | E       |
|             | channel shall be provided      |             | xpected |
|             | through the Naming Service.    | 01-2008     |         |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1490 | A client shall be able to read | A. Petrov   | E       |
|             | postmortem data via DL API     |             | xpected |
|             | \[4.4\].                       | 01-2008     |         |
+-------------+--------------------------------+-------------+---------+

## Save And Restore Service

+-------------+--------------------------------+-------------+---------+
| **No.**     | **Requirement**                | **Source**  | **Pri   |
|             |                                |             | ority** |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1500 | The control system shall       | A. Petrov   | C       |
|             | implement a central Save And   |             | ritical |
|             | Restore Service.               | 01-2008     |         |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1510 | Each Save And Restore archive  | A. Petrov   | C       |
|             | shall store snapshots of data  |             | ritical |
|             | samples acquired synchronously | 01-2008     |         |
|             | from a group of devices.       |             |         |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1520 | The configuration of archives  | A. Petrov   | E       |
|             | and the list of available      |             | xpected |
|             | snapshots shall be provided    | 01-2008     |         |
|             | through the Naming Service.    |             |         |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1530 | Each archive shall be uniquely | A. Petrov   | C       |
|             | identified by its name.        |             | ritical |
|             |                                | 01-2008     |         |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1540 | Each snapshot within an        | A. Petrov   | C       |
|             | archive shall be uniquely      |             | ritical |
|             | identified by the timestamp.   | 01-2008     |         |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1550 | It shall be possible to assign | A. Petrov   | E       |
|             | an optional description and    |             | xpected |
|             | alias to a snapshot. The alias | 01-2008     |         |
|             | shall be unique within the     |             |         |
|             | current archive.               |             |         |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1560 | A client shall be able to      | A. Petrov   | C       |
|             | obtain the list of available   |             | ritical |
|             | snapshots in an archive.       | 01-2008     |         |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1570 | A client shall be able to      | A. Petrov   | C       |
|             | obtain an individual snapshot  |             | ritical |
|             | from an archive.               | 01-2008     |         |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1580 | A client shall be able to save | A. Petrov   | C       |
|             | a new snapshot into an         |             | ritical |
|             | archive.                       | 01-2008     |         |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1590 | A client shall be able to      | A. Petrov   | C       |
|             | restore a previous state of    |             | ritical |
|             | the system by using an         | 01-2008     |         |
|             | archived snapshot.             |             |         |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1600 | A client shall be able to      | K. Cahill   | E       |
|             | modify data in the existing    |             | xpected |
|             | snapshots.                     | 01-2008     |         |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1610 | The modified snapshots shall   | K. Cahill   | C       |
|             | be clearly marked with a       |             | ritical |
|             | special attribute.             | 01-2008     |         |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1620 | The Save And Restore service   | A. Petrov   | C       |
|             | shall be able to take          |             | ritical |
|             | snapshots automatically on     | 01-2008     |         |
|             | events.                        |             |         |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1630 | The Save And Restore Service   | A. Petrov   | C       |
|             | shall implement access control |             | ritical |
|             | and support, but not mandate,  | 01-2008     |         |
|             | client authentication.         |             |         |
+-------------+--------------------------------+-------------+---------+
| CXR-CS-1640 | It shall be possible to        | A. Petrov   | E       |
|             | specify reading, saving ("make |             | xpected |
|             | a new snapshot"), restoring    | 01-2008     |         |
|             | ("restore data from a          |             |         |
|             | snapshot") and writing         |             |         |
|             | ("modify a snapshot")          |             |         |
|             | permissions on an archive, and |             |         |
|             | default permissions an all     |             |         |
|             | archives that are not the      |             |         |
|             | subject of explicit access     |             |         |
|             | control.                       |             |         |
+-------------+--------------------------------+-------------+---------+

# Application Infrastructure

This section discusses different types of application used in a control
system. It also gives requirements on the operational environment, data
protocols, and internal functionality common to all applications.

## Types of Applications

There are three types of applications in the control system:

> **1. Low-Level Applications** (described in \[3\]), which acquire data
> from physical equipment, front-ends, or other external sources. This
> section includes one kind of low-level applications, the **Open Access
> Clients (OAC),** also known as *software front-ends*.
>
> **2. High-Level Applications** (described in \[6\]), which provide
> human-readable data to the end users. The two types of high-level
> applications are:

-   **Custom Applications,** programs designed specifically for use in
    the current system.

-   **Third-Party Applications,** general-purpose programs that
    integrate with the rest of the system through well-defined protocols
    or data formats. This includes web browsers, MATLAB, JAS, and other
    tools routinely used to visualize and process data.

> **3. Middleware,** which mediates the communication between the
> low-level and the high-level applications and provides additional
> services to both. The middleware includes:

-   **Central Services** (discussed in section 4).

-   **Daemons**, periodically or continuously running routines.

-   **Server-Side Parts** of multi-tier high-level applications.

-   **Web Applications,** providing data via HTTP.[^4]

The applications may run on three types of computer nodes:

-   **Client Nodes,** users\' PCs, laptops, etc.; as well as shared
    consoles in control rooms.\
    The client nodes can be used to execute only high-level
    applications.

-   **Central Nodes,** servers that are administered and controlled by
    the Controls Department and accessible by the users via remote
    tools. The central nodes can be used to execute high-level
    applications, the middleware, and Open Access Clients. As all
    server-side programming components are headless[^5], they shall run
    under the control of a specialized application environment (an
    application server), rather than a human being.

-   **Front-End Nodes,** servers controlled by the Control Department
    and generally not accessible by the users. The front-end nodes can
    be used to execute only low-level applications. Specific
    requirements are given in section 3.

+-----------+---------------------------------+------------+----------+
| **No.**   | **Requirement**                 | **Source** | **Pr     |
|           |                                 |            | iority** |
+-----------+---------------------------------+------------+----------+
| CXR-AI-10 | The control system shall        | A. Petrov  | Critical |
|           | provide a technical             |            |          |
|           | specification for the hard- and | 01-2008    |          |
|           | software environment sufficient |            |          |
|           | to run high-level applications. |            |          |
+-----------+---------------------------------+------------+----------+
| CXR-AI-20 | The control system shall enable | A. Petrov  | Expected |
|           | high-level applications on the  |            |          |
|           | central nodes.                  | 01-2008    |          |
+-----------+---------------------------------+------------+----------+
| CXR-AI-25 | For high-level applications     | A. Petrov  | Expected |
|           | running on the central nodes,   |            |          |
|           | the control system shall        | 01-2008    |          |
|           | provide a means to display      |            |          |
|           | their GUI on the client nodes.  |            |          |
+-----------+---------------------------------+------------+----------+
| CXR-AI-30 | The control system shall        | A. Petrov  | Expected |
|           | include a set of central nodes  |            |          |
|           | capable of running high-level   | 01-2008    |          |
|           | applications.                   |            |          |
+-----------+---------------------------------+------------+----------+
| CXR-AI-35 | The control system shall enable | A. Petrov  | Expected |
|           | a subset of high-level          |            |          |
|           | applications on the client      | 01-2008    |          |
|           | nodes.                          |            |          |
+-----------+---------------------------------+------------+----------+
| CXR-AI-40 | The control system shall        | A. Petrov  | Critical |
|           | provide a tool for the users to |            |          |
|           | select and launch high-level    | 01-2008    |          |
|           | applications (see also          |            |          |
|           | CXR-HL-201).                    |            |          |
+-----------+---------------------------------+------------+----------+
| CXR-AI-50 | The use of third-party          | C.         | Critical |
|           | high-level applications shall   | Schumann   |          |
|           | be approved by a board of       | 01-2008    |          |
|           | experts. Unapproved programs    |            |          |
|           | shall [not]{.underline} be      |            |          |
|           | supported.                      |            |          |
+-----------+---------------------------------+------------+----------+
| CXR-AI-60 | The control system shall        | A. Petrov  | Critical |
|           | provide an application server   |            |          |
|           | for the server-side programming | 01-2008    |          |
|           | components.                     |            |          |
+-----------+---------------------------------+------------+----------+
| CXR-AI-70 | The application server shall be | A. Petrov  | Critical |
|           | capable of executing Central    |            |          |
|           | Services.                       | 01-2008    |          |
+-----------+---------------------------------+------------+----------+
| CXR-AI-80 | The application server shall be | A. Petrov  | Critical |
|           | capable of executing Open       |            |          |
|           | Access Clients.                 | 01-2008    |          |
+-----------+---------------------------------+------------+----------+
| CXR-AI-90 | The application server shall be | A. Petrov  | Expected |
|           | capable of executing deamons,   |            |          |
|           | which are continuously or       | 01-2008    |          |
|           | periodically running headless   |            |          |
|           | routines.                       |            |          |
+-----------+---------------------------------+------------+----------+
| C         | The application server shall be | A. Petrov  | Expected |
| XR-AI-100 | capable of executing            |            |          |
|           | server-side parts of multi-tier | 01-2008    |          |
|           | high level applications.        |            |          |
+-----------+---------------------------------+------------+----------+
| C         | The application server shall be | A. Petrov  | Expected |
| XR-AI-110 | capable of executing web        |            |          |
|           | applications.                   | 01-2008    |          |
+-----------+---------------------------------+------------+----------+
| C         | It shall be possible to start,  | A. Petrov  | Expected |
| XR-AI-120 | stop, and reconfigure           |            |          |
|           | individual components inside    | 01-2008    |          |
|           | the application server without  |            |          |
|           | affecting others.               |            |          |
+-----------+---------------------------------+------------+----------+
| C         | The application server shall be | A. Petrov  | Critical |
| XR-AI-130 | able to recover the states of   |            |          |
|           | all the components upon restart | 01-2008    |          |
|           | or after spontaneous failures.  |            |          |
+-----------+---------------------------------+------------+----------+
| C         | The control system shall        | A. Petrov  | Critical |
| XR-AI-140 | support individual              |            |          |
|           | configuration of application    | 01-2008    |          |
|           | servers for each central node.  |            |          |
+-----------+---------------------------------+------------+----------+
| C         | The application server shall    | A. Petrov  | Expected |
| XR-AI-150 | report its internal state       |            |          |
|           | through the Data Acquisition    | 01-2008    |          |
|           | Service \[4.2\].                |            |          |
+-----------+---------------------------------+------------+----------+
| C         | The application server shall    | A. Petrov  | Expected |
| XR-AI-160 | provide a mechanism to collect  |            |          |
|           | and keep application log files. | 01-2008    |          |
+-----------+---------------------------------+------------+----------+

## Application Protocols

The application protocols are used by high-level applications to
communicate with the middleware and low-level components. They are also
used by the server-side components to communicate with each other. The
right choice of application protocols can facilitate the development of
high-level applications and improve integration with third-party
software.

The requirements in this section use a terminology from the *OSI
Reference Model*, described at <http://en.wikipedia.org/wiki/osi_model>.

+-----------+--------------------------------+------------+----------+
| **No.**   | **Requirement**                | **Source** | **Pr     |
|           |                                |            | iority** |
+-----------+--------------------------------+------------+----------+
| C         | The application protocols      | A. Petrov  | Critical |
| XR-AI-170 | shall be platform and language |            |          |
|           | independent.                   | 01-2008    |          |
+-----------+--------------------------------+------------+----------+
| C         | The control system shall       | A. Petrov  | Expected |
| XR-AI-180 | specify the protocols that     |            |          |
|           | will be supported.             | 01-2008    |          |
+-----------+--------------------------------+------------+----------+
| C         | Each application protocol      | A. Petrov  | Desired  |
| XR-AI-190 | shall be implemented with a    |            |          |
|           | binary presentation layer.     | 01-2008    |          |
+-----------+--------------------------------+------------+----------+
| C         | Each application protocol      | A. Petrov  | Desired  |
| XR-AI-200 | shall be implemented with a    |            |          |
|           | human-readable presentation    | 01-2008    |          |
|           | layer.                         |            |          |
+-----------+--------------------------------+------------+----------+
| C         | All presentation-layer data    | A. Petrov  | Expected |
| XR-AI-210 | formats shall be explicitly    |            |          |
|           | specified.                     | 01-2008    |          |
+-----------+--------------------------------+------------+----------+
| C         | The inbound connections shall  | A. Petrov  | Expected |
| XR-AI-230 | be accepted on well-defined    |            |          |
|           | ports.                         | 01-2008    |          |
+-----------+--------------------------------+------------+----------+

## General-Purpose Database

+-----------+--------------------------------+------------+----------+
| **No.**   | **Requirement**                | **Source** | **Pr     |
|           |                                |            | iority** |
+-----------+--------------------------------+------------+----------+
| C         | The control system shall       | A. Petrov  | Critical |
| XR-AI-900 | provide a general-purpose      |            |          |
|           | application database,          | 01-2008    |          |
|           | accessible from, at least, the |            |          |
|           | central nodes.                 |            |          |
+-----------+--------------------------------+------------+----------+
| C         | The control system shall       | A. Petrov  | Expected |
| XR-AI-910 | implement database connection  |            |          |
|           | pools. All applications shall  | 01-2008    |          |
|           | obtain database connections    |            |          |
|           | from the pools.                |            |          |
+-----------+--------------------------------+------------+----------+
| C         | The database shall support,    | A. Petrov  | Critical |
| XR-AI-920 | but not mandate, client        |            |          |
|           | authentication.                | 01-2008    |          |
+-----------+--------------------------------+------------+----------+
| C         | The database shall mandate     | A. Petrov  | Critical |
| XR-AI-930 | authorization of clients       |            |          |
|           | modifying the data.            | 01-2008    |          |
+-----------+--------------------------------+------------+----------+
| C         | Common dictionaries of objects | A. Petrov  | Expected |
| XR-AI-940 | shall use the Naming Service   |            |          |
|           | \[4.1\], rather than the       | 01-2008    |          |
|           | application database.          |            |          |
+-----------+--------------------------------+------------+----------+
| C         | High-level applications shall  | A. Petrov  | Expected |
| XR-AI-950 | [not]{.underline} utilize      |            |          |
|           | direct database access from    | 01-2008    |          |
|           | the client nodes. To access    |            |          |
|           | the database, the client-side  |            |          |
|           | applications shall use a       |            |          |
|           | two-tier approach, when the DB |            |          |
|           | connection is opened in the    |            |          |
|           | middle tier.                   |            |          |
+-----------+--------------------------------+------------+----------+
| C         | All central services and       | A. Petrov  | Desired  |
| XR-AI-960 | high-level applications shall  |            |          |
|           | be designed in a way that      | 01-2008    |          |
|           | makes them reasonably          |            |          |
|           | independent from any           |            |          |
|           | particular database            |            |          |
|           | implementation (e.g., by using |            |          |
|           | Service Provider Interfaces).  |            |          |
+-----------+--------------------------------+------------+----------+
| C         | The control system shall keep  | K. Cahill  | Expected |
| XR-AI-970 | a log of application database  |            |          |
|           | queries.                       | 01-2008    |          |
+-----------+--------------------------------+------------+----------+

## Security

+-----------+--------------------------------+------------+----------+
| No.       | Requirement                    | Source     | Priority |
+-----------+--------------------------------+------------+----------+
| C         | The control system shall have  | A. Petrov  | Critical |
| XR-AI-240 | a written security policy.     |            |          |
|           |                                | 01-2008    |          |
+-----------+--------------------------------+------------+----------+
| C         | The control system shall       | A. Petrov  | Critical |
| XR-AI-250 | implement a central Identity   |            |          |
|           | Database, which registers      | 01-2008    |          |
|           | credentials of the principals  |            |          |
|           | (users).                       |            |          |
+-----------+--------------------------------+------------+----------+
| C         | At a minimum, each credential  | A. Petrov  | Expected |
| XR-AI-260 | shall include a unique name of |            |          |
|           | the principal, a principal     | 01-2008    |          |
|           | type, an optional description, |            |          |
|           | and a set of assigned roles    |            |          |
|           | (named permissions).           |            |          |
+-----------+--------------------------------+------------+----------+
| C         | The data in the Identity       | A. Petrov  | Expected |
| XR-AI-270 | Database (list of user and     |            |          |
|           | roles) shall be available      | 01-2008    |          |
|           | through the Naming Service     |            |          |
|           | \[4.1\].                       |            |          |
+-----------+--------------------------------+------------+----------+
| C         | The Identity database shall    | A. Petrov  | Expected |
| XR-AI-280 | include a graphical user       |            |          |
|           | interface (GUI) for remote     | 01-2008    |          |
|           | configuration and monitoring.  |            |          |
+-----------+--------------------------------+------------+----------+
| C         | The control system shall       | A. Petrov  | Critical |
| XR-AI-290 | support, but not mandate,      |            |          |
|           | strong authentication of user  | 01-2008    |          |
|           | principals that satisfies the  |            |          |
|           | requirements of the lab        |            |          |
|           | security policy.               |            |          |
+-----------+--------------------------------+------------+----------+
| C         | The control system shall       | A. Petrov  | Expected |
| XR-AI-300 | support a mechanism of Single  |            |          |
|           | Sign-On for user principals.   | 01-2008    |          |
+-----------+--------------------------------+------------+----------+
| C         | The control system shall       | A. Petrov  | Expected |
| XR-AI-310 | support principals assigned to |            |          |
|           | computer nodes and programming | 01-2008    |          |
|           | processes, and provide         |            |          |
|           | appropriate mechanisms of      |            |          |
|           | their authentication.          |            |          |
+-----------+--------------------------------+------------+----------+
| C         | The control system shall       | A. Petrov  | Critical |
| XR-AI-320 | provide a mechanism of default |            |          |
|           | authentication on shared       | 01-2008    |          |
|           | consoles.                      |            |          |
+-----------+--------------------------------+------------+----------+
| C         | A client program shall be able | T.         | Expected |
| XR-AI-325 | to identify itself during      | Zingelman  |          |
|           | authentication (e.g., by       |            |          |
|           | providing a high-level         | 01-2008    |          |
|           | application name, OAC name,    |            |          |
|           | etc). This information shall   |            |          |
|           | be used only in addition to a  |            |          |
|           | trusted form of                |            |          |
|           | authentication.                |            |          |
+-----------+--------------------------------+------------+----------+
| C         | The control system shall keep  | A. Petrov  | Expected |
| XR-AI-330 | a log of all authentication    |            |          |
|           | attempts.                      | 01-2008    |          |
+-----------+--------------------------------+------------+----------+
| C         | The application protocols      | A. Petrov  | Desired  |
| XR-AI-340 | \[5.2\] shall incorporate, in  |            |          |
|           | the transport layer, a         | 01-2008    |          |
|           | cryptographic protocol         |            |          |
|           | providing client               |            |          |
|           | authentication and protection  |            |          |
|           | against message tampering.     |            |          |
+-----------+--------------------------------+------------+----------+
| C         | Authorization decisions shall  | A. Petrov  | Expected |
| XR-AI-350 | be made by the server-side     |            |          |
|           | components or front-ends based | 01-2008    |          |
|           | on roles assigned to the       |            |          |
|           | current principal.             |            |          |
+-----------+--------------------------------+------------+----------+
| C         | A middleware component shall   | A. Petrov  | Desired  |
| XR-AI-360 | be able to delegate client     |            |          |
|           | credentials to another         | 01-2008    |          |
|           | middleware or low-level        |            |          |
|           | component.                     |            |          |
+-----------+--------------------------------+------------+----------+

## Application Framework

+-----------+--------------------------------+------------+----------+
| **No.**   | **Requirement**                | **Source** | **Pr     |
|           |                                |            | iority** |
+-----------+--------------------------------+------------+----------+
| C         | The control system shall       | A. Petrov  | Expected |
| XR-AI-370 | provide a programming          |            |          |
|           | framework for standard         | 01-2008    |          |
|           | high-level applications.       |            |          |
+-----------+--------------------------------+------------+----------+
| C         | The application framework      | A. Petrov  | Expected |
| XR-AI-380 | shall provide a graphical user |            |          |
|           | interface with a common        | 01-2008    |          |
|           | look-and-feel \[CXR-HL-100\].  |            |          |
+-----------+--------------------------------+------------+----------+
| C         | The application framework      | A. Petrov  | Expected |
| XR-AI-390 | shall provide an API to the    |            |          |
|           | Central Services.              | 01-2008    |          |
+-----------+--------------------------------+------------+----------+
| C         | The application framework      | A. Petrov  | Expected |
| XR-AI-400 | shall implement the GUI        |            |          |
|           | features required by the       | 01-2008    |          |
|           | Central Services \[CXR-CS-680, |            |          |
|           | CXR-CS-690, CXR-CS-940\].      |            |          |
+-----------+--------------------------------+------------+----------+
| C         | The application framework      | A. Petrov  | Expected |
| XR-AI-410 | shall incorporate an API to    |            |          |
|           | the application database       | 01-2008    |          |
|           | \[5.3\], and a database        |            |          |
|           | connection pool.               |            |          |
+-----------+--------------------------------+------------+----------+
| C         | The application framework      | A. Petrov  | Expected |
| XR-AI-420 | shall test the availability of |            |          |
|           | required external resources    | 01-2008    |          |
|           | (Central Services, application |            |          |
|           | database, and server-side      |            |          |
|           | components). If a resource is  |            |          |
|           | not reachable, the framework   |            |          |
|           | shall notify the user and      |            |          |
|           | disable the entire             |            |          |
|           | application.                   |            |          |
+-----------+--------------------------------+------------+----------+
| C         | The application framework      | C.         | Expected |
| XR-AI-430 | shall send email notifications | Schumann   |          |
|           | to application subscribers     |            |          |
|           | should the program terminate   | 01-2008    |          |
|           | abnormally.                    |            |          |
+-----------+--------------------------------+------------+----------+
| C         | Each application shall have a  | A. Petrov  | Expected |
| XR-AI-440 | link to an online help page.   |            |          |
|           |                                | 01-2008    |          |
+-----------+--------------------------------+------------+----------+

# High Level Applications

The high level application programs for Project X will have to serve a
diverse community of users. These users have different needs and they
can be divided into roughly four groups. Machine operators have the
primary responsibility for operating the accelerator. They monitor and
control the accelerator complex around the clock. They need both an
intuitive interface to deal with the myriad of systems that they
encounter as well as more low level, efficient interfaces for systems
that they are proficient with. The machine specialists are experts in a
particular portion of the complex. They carry out studies to make
improvements to their area, and they are often called upon to deal with
difficult operational situations. They need flexible, easily configured
application environments to carry out their studies, and they have
similar needs to the machine operators when they are dealing with
operational problems. Equipment specialists are responsible for
particular pieces of equipment and need applications which can access
detailed diagnostics information about their equipment, and they need
reasonable access to general facilities such as datalogging to monitor
the performance of the equipment that they are responsible for. The
final group of users are the experimenters themselves. They need
intuitive applications to monitor accelerator information that may
impact their experiment. They may also need some access to control
parameters as well. To be successful, the high level application
programs must meet all of these various needs.

The requirements in this document are not intended to apply to existing
legacy applications. They apply to new custom applications created for
Project X.

## User Interface

It is important to provide a user interface that is intuitive and more
importantly consistent. It should provide a wide variety of information
about a given machine parameter with a minimum of mouse clicks.

+--------------+-------------------------------+-------------+--------+
| **No.**      | **Requirement**               | **Source**  | **Prio |
|              |                               |             | rity** |
+--------------+-------------------------------+-------------+--------+
| CXR-HL-100   | All applications shall have a | W. Kissel   | Ex     |
|              | common look and feel.         |             | pected |
|              | \[CXR-AI-380\]                | 12-2007     |        |
+--------------+-------------------------------+-------------+--------+
| CXR-HL-110   | The user interface shall      | W. Kissel   | Ex     |
|              | support transferring data     |             | pected |
|              | between applications in a     | 12-2007     |        |
|              | standard and consistent way,  |             |        |
|              | including drag and drop, and  |             |        |
|              | copy and paste.               |             |        |
+--------------+-------------------------------+-------------+--------+
| CXR-HL-120   | The user interface shall      | W. Kissel   | Ex     |
|              | provide a standard way to     |             | pected |
|              | select devices (see Naming    | 12-2007     |        |
|              | Service section 4.1)          |             |        |
+--------------+-------------------------------+-------------+--------+
| CXR-HL-130   | The user interface shall      | B.          | Ex     |
|              | support searching for devices | Hendricks   | pected |
|              | by name, front-end node,      |             |        |
|              | device type, and any other    | 12-2007     |        |
|              | device database attributes.   |             |        |
+--------------+-------------------------------+-------------+--------+
| CXR-HL-140   | The user interface shall      | W. Kissel   | Ex     |
|              | support launching real time   |             | pected |
|              | parameter plots for selected  | 12-2007     |        |
|              | devices. \[CXR-LL-520\]       |             |        |
+--------------+-------------------------------+-------------+--------+
| CXR-HL-150   | The user interface shall      | W. Kissel   | Ex     |
|              | support launching datalogger  |             | pected |
|              | (archived data) plots for     | 12-2007     |        |
|              | selected devices.             |             |        |
+--------------+-------------------------------+-------------+--------+
| CXR-HL-160   | The user interface shall      | W. Kissel   | Ex     |
|              | support accessing database    |             | pected |
|              | information for selected      | 12-2007     |        |
|              | devices.                      |             |        |
+--------------+-------------------------------+-------------+--------+
| CXR-HL-170   | The user interface shall      | W. Kissel   | Ex     |
|              | support exporting data for    |             | pected |
|              | selected devices to           | 12-2007     |        |
|              | electronic log books.         |             |        |
+--------------+-------------------------------+-------------+--------+
| CXR-HL-180   | The user interface shall      | B.          | Ex     |
|              | support launching             | Hendricks   | pected |
|              | applications and opening them |             |        |
|              | with any selected devices.    | 12-2007     |        |
+--------------+-------------------------------+-------------+--------+
| CXR-HL-190   | The user interface shall      | B.          | Ex     |
|              | support accessing control     | Hendricks   | pected |
|              | system error help.            |             |        |
|              |                               | 12-2007     |        |
+--------------+-------------------------------+-------------+--------+
| CXR-HL-195   | The user interface shall      | B.          | Ex     |
|              | support accessing information | Hendricks   | pected |
|              | about selected front-end      |             |        |
|              | nodes.                        | 12-2007     |        |
+--------------+-------------------------------+-------------+--------+

## Applications

The user applications for Project X should support the needs of both new
employees and visiting workers from other institutions who need a
humanly understandable view of the accelerator complex. They should also
support the needs of veteran power users who want to get their work done
as quickly and efficiently as possible.

It is also desirable that applications not duplicate one another in
functionality. If functionality needed by one application is fulfilled
by another, the first program should call the other one to achieve the
desired functionality.

The requirements below list only fundamental attributes of each
application. Before implementation, a detailed requirement for each
application should be created.

+------------+------------------------------+---------------+---------+
| **No.**    | **Requirement**              | **Source**    | **Pri   |
|            |                              |               | ority** |
+------------+------------------------------+---------------+---------+
| CXR-HL-200 | There shall be a synoptic    | B. Hendricks  | C       |
|            | display application which    |               | ritical |
|            | will allow users to          | 12-2007       |         |
|            | investigate the accelerator  |               |         |
|            | in a graphical way.          |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-210 | The synoptic display         | B. Hendricks  | C       |
|            | application shall support    |               | ritical |
|            | the launching of other       | 12-2007       |         |
|            | applications.                |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-220 | The synoptic display         | B. Hendricks  | E       |
|            | application shall be         |               | xpected |
|            | editable by end users        | 12-2007       |         |
|            | employing standard drag and  |               |         |
|            | drop features.               |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-230 | There shall be a master menu | B. Hendricks  | C       |
|            | application which will       |               | ritical |
|            | support launching any other  | 12-2007       |         |
|            | application program.         |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-240 | There shall be a parameter   | B. Hendricks  | C       |
|            | plotting application which   |               | ritical |
|            | will support high frequency  | 12-2007       |         |
|            | plotting of data from the    |               |         |
|            | accelerator.                 |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-250 | The plot application shall   | B. Hendricks  | E       |
|            | support zooming              |               | xpected |
|            | functionality.               | 12-2007       |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-260 | The plot application shall   | B. Hendricks  | C       |
|            | support the plotting of      |               | ritical |
|            | multiple devices             | 12-2007       |         |
|            | simultaneously.              |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-270 | The plot application should  | B. Hendricks  | E       |
|            | support the saving and       |               | xpected |
|            | restoring of plot setup      | 12-2007       |         |
|            | files.                       |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-280 | The plot application shall   | B. Hendricks  | C       |
|            | support a real time strip    |               | ritical |
|            | chart mode.                  | 12-2007       |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-290 | The plot application shall   | B. Hendricks  | C       |
|            | support plots triggered by   |               | ritical |
|            | machine events.              | 12-2007       |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-300 | There shall be a sequencer   | B. Hendricks  | C       |
|            | application which will       |               | ritical |
|            | support programmable,        | 12-2007       |         |
|            | sequential execution of      |               |         |
|            | accelerator operations.      |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-310 | The sequencer application    | B. Hendricks  | C       |
|            | sequences shall be           |               | ritical |
|            | programmable by end users    | 12-2007       |         |
|            | perhaps with some            |               |         |
|            | restrictions.                |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-320 | The sequencer application    | B. Hendricks  | C       |
|            | shall be aware of machine    |               | ritical |
|            | events.                      | 12-2007       |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-330 | The sequencer application    | B. Hendricks  | C       |
|            | shall support individual     |               | ritical |
|            | command execution as well as | 12-2007       |         |
|            | complete sequences.          |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-340 | The sequencer application    | B. Hendricks  | C       |
|            | shall maintain an            |               | ritical |
|            | operational log to allow     | 12-2007       |         |
|            | users to evaluate past       |               |         |
|            | execution.                   |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-350 | There shall be an alarm      | B. Hendricks  | C       |
|            | display application.         |               | ritical |
|            |                              | 12-2007       |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-360 | The alarm display shall      | B. Hendricks  | E       |
|            | support user configuration   |               | xpected |
|            | of which devices are         | 12-2007       |         |
|            | displayed as well as where   |               |         |
|            | they appear on the display.  |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-370 | The alarm display shall      | B. Hendricks  | C       |
|            | support displaying alarms    |               | ritical |
|            | chronologically.             | 12-2007       |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-380 | The alarm display shall      | B. Hendricks  | C       |
|            | support displaying alarms by |               | ritical |
|            | priority.                    | 12-2007       |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-390 | The alarm display shall      | B. Hendricks  | C       |
|            | support the generation of    |               | ritical |
|            | sounds when an alarm is      | 12-2007       |         |
|            | received.                    |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-400 | The alarm display shall      | B. Hendricks  | C       |
|            | support an option to display |               | ritical |
|            | all alarms including ones    | 12-2007       |         |
|            | that are not presently       |               |         |
|            | mapped.                      |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-401 | The alarm display shall      | B.Hendicks    | C       |
|            | support displays of current  |               | ritical |
|            | readings and alarm block     | 12-2007       |         |
|            | information.                 |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-402 | The alarm display shall      | B.Hendricks   | C       |
|            | support modifying alarm      |               | ritical |
|            | block information including  | 12-2007       |         |
|            | disabling alarms and         |               |         |
|            | changing limits and masks.   |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-410 | There shall be a datalogger  | B. Hendricks  | C       |
|            | display application.         |               | ritical |
|            |                              | 12-2007       |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-420 | The datalogger display       | B. Hendricks  | C       |
|            | application shall support    |               | ritical |
|            | plotting multiple parameters | 12-2007       |         |
|            | on the same grid.            |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-430 | The datalogger display       | B. Hendricks  | C       |
|            | application shall support    |               | ritical |
|            | selection of archival data   | 12-2007       |         |
|            | event parameters.            |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-440 | The datalogger display       | B. Hendricks  | C       |
|            | application shall support    |               | ritical |
|            | the exporting of data in     | 12-2007       |         |
|            | ASCII and popular            |               |         |
|            | spreadsheet compatible       |               |         |
|            | formats.                     |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-450 | The datalogger display       | B. Hendricks  | E       |
|            | application shall support    |               | xpected |
|            | saving and restoring of      | 12-2007       |         |
|            | recently used plot setups as |               |         |
|            | well as user configured      |               |         |
|            | saved setups.                |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-460 | There shall be a device      | B. Hendricks  | C       |
|            | configuration database       |               | ritical |
|            | viewer and editor            | 12-2007       |         |
|            | application.                 |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-470 | There shall be a parameter   | B. Hendricks  | C       |
|            | list application.            |               | ritical |
|            |                              | 12-2007       |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-480 | The parameter list           | B. Hendricks  | C       |
|            | application shall support    |               | ritical |
|            | reading parameter values.    | 12-2007       |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-490 | The parameter list           | B. Hendricks  | C       |
|            | application shall support    |               | ritical |
|            | setting parameter values.    | 12-2007       |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-500 | The parameter list           | B. Hendricks  | C       |
|            | application shall be end     |               | ritical |
|            | user configurable.           | 12-2007       |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-510 | There shall be a parameter   | B. Hendricks  | C       |
|            | save, restore, and compare   |               | ritical |
|            | application.                 | 12-2007       |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-520 | The parameter save, restore, | B. Hendricks  | C       |
|            | and compare application      |               | ritical |
|            | shall support displaying     | 12-2007       |         |
|            | save file values.            |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-530 | The parameter save, restore, | B. Hendricks  | C       |
|            | and compare application      |               | ritical |
|            | shall support restoring      | 12-2007       |         |
|            | values from a save file.     |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-540 | The parameter save, restore, | B. Hendricks  | C       |
|            | and compare application      |               | ritical |
|            | shall support configuring    | 12-2007       |         |
|            | and making save files.       |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-550 | There shall be an overall    | B. Hendricks  | C       |
|            | site status display          |               | ritical |
|            | application.                 | 12-2007       |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-560 | The overall site status      | B. Hendricks  | C       |
|            | display application shall    |               | ritical |
|            | display important parameters | 12-2007       |         |
|            | and the state of all         |               |         |
|            | portions of the accelerator  |               |         |
|            | complex.                     |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-570 | The overall site status      | B. Hendricks  | C       |
|            | display application shall    |               | ritical |
|            | display important machine    | 12-2007       |         |
|            | event information.           |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-580 | The overall site status      | B. Hendricks  | C       |
|            | display application shall    |               | ritical |
|            | support the display of       | 12-2007       |         |
|            | operator entered messages.   |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-590 | There shall be an            | B. Hendricks  | C       |
|            | application to set the       |               | ritical |
|            | gradients and phases of the  | 12-2007       |         |
|            | RF cavities for the linac.   |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-600 | There shall be an            | B. Hendricks  | C       |
|            | application to steer the     |               | ritical |
|            | beam in the linac.           | 12-2007       |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-610 | There shall be an            | B. Hendricks  | C       |
|            | application to align the     |               | ritical |
|            | linac beam along the         | 12-2007       |         |
|            | magnetic axis.               |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-620 | There shall be an            | B. Hendricks  | C       |
|            | application to configure and |               | ritical |
|            | monitor the machine          | 12-2007       |         |
|            | protection system.           |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-630 | There shall be an            | B. Hendricks  | C       |
|            | application to analyze       |               | ritical |
|            | machine protection system    | 12-2007       |         |
|            | trips.                       |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-640 | There shall be an            | B. Hendricks  | C       |
|            | application to monitor and   |               | ritical |
|            | control the cryogenic        | 12-2007       |         |
|            | systems for the linac.       |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-650 | There shall be an            | B. Hendricks  | C       |
|            | application to monitor and   |               | ritical |
|            | control the high level RF    | 12-2007       |         |
|            | systems for the linac.       |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-660 | There shall be an            | B. Hendricks  | C       |
|            | application to monitor and   |               | ritical |
|            | configure central services.  | 12-2007       |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-670 | There shall be an electronic | B. Hendricks  | C       |
|            | log application which can be |               | ritical |
|            | used by the operations staff | 12-2007       |         |
|            | as well as individual        |               |         |
|            | machine departments. It      |               |         |
|            | shall be web based.          |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-680 | There shall be an            | B. Hendricks  | C       |
|            | application to monitor and   |               | ritical |
|            | control the beam position    | 12-2007       |         |
|            | monitor (BPM) system.        |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-690 | There shall be an            | B. Hendricks  | C       |
|            | application to monitor and   |               | ritical |
|            | control the beam loss        | 12-2007       |         |
|            | monitor (BLM) system.        |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-700 | There shall be an            | B. Hendricks  | C       |
|            | application to monitor and   |               | ritical |
|            | control the vacuum system.   | 12-2007       |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-710 | There shall be an            | B. Hendricks  | E       |
|            | application that supports    |               | xpected |
|            | the display of correlated    | 12-2007       |         |
|            | parameters from a given beam |               |         |
|            | pulse.                       |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-720 | There shall be an            | J. Patrick    | E       |
|            | application to monitor and   |               | xpected |
|            | control beam-based feedback. | 1-2008        |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-730 | There shall be an            | B. Hendricks  | E       |
|            | application to display       |               | xpected |
|            | hierarchical archived data   | 1-2008        |         |
|            | (SDA)                        |               |         |
+------------+------------------------------+---------------+---------+
| CXR-HL-740 | There shall be a parameter   | B. Webber     | E       |
|            | scan application.            |               | xpected |
|            |                              | 1-2008        |         |
+------------+------------------------------+---------------+---------+

## Nonstandard Applications

There must be tools for nonprogrammers or those who need to develop
something quickly to work around or to study a short term problem. In
general, there should be high level tools to empower end users to create
application programs. This allows them to create programs on their own
schedule. It also allows them to get the exact functionality and
interface that they desire.

+--------------+-----------------------------+---------------+---------+
| **No.**      | **Requirement**             | **Source**    | **Pri   |
|              |                             |               | ority** |
+--------------+-----------------------------+---------------+---------+
| CXR-HL-800   | There shall be a user       | B. Hendricks  | E       |
|              | configurable, drag and drop |               | xpected |
|              | synoptic display editor.    | 12-2007       |         |
+--------------+-----------------------------+---------------+---------+
| CXR-HL-810   | There shall be a scripting  | B. Hendricks  | E       |
|              | language which supports     |               | xpected |
|              | generic access to           | 12-2007       |         |
|              | accelerator parameter       |               |         |
|              | values as well as other     |               |         |
|              | control system parameters.  |               |         |
+--------------+-----------------------------+---------------+---------+
| CXR-HL-820   | There shall be support for  | B. Hendricks  | E       |
|              | selected third party        |               | xpected |
|              | mathematical applications   | 1-2008        |         |
|              | to acquire control system   |               |         |
|              | data.                       |               |         |
+--------------+-----------------------------+---------------+---------+

# Controls In A Box

As previously stated, the Control System needs to scale to a large user
community and a million properties. There is also a need for the control
system to be available on a small scale for one user or a small group of
users to test a small number of instruments in a relatively informal
setting. We refer to this small control system as Controls in a Box.

There are several important advantages to Controls in a Box, the most
obvious is that a single user can control an instrument without the
overhead of the large and complex control system designed to operate an
accelerator complex consisting of 9 km of instrumentation and stringent
safety and availability requirements. Controls in a Box has different
requirements, it does not have to meet many of the Operation Controls
base requirements (safety, availability, legacy constraints) and hence
can focus on the needs of the individual such as ease of use, wide and
general distribution, and installation.

Operation Controls also benefits by separating the testing of individual
instruments from the operation of the accelerator complex. It lessens
the load on all resources and avoids interference with operations.

Control in a Box is an excellent way to introduce and familiarize users
with the control system, without them having to use the Operations
Control resources such as servers and central services. Assuming
Controls in a Box is available as a download from the Web, one can
install it on the client node (laptop) and learn it by locally
controlling an instrument and having complete control over the
configuration and resources.

Any modern accelerator will be built in collaboration with national if
not international research labs. The off-site labs require remote access
and a somewhat autonomous control system for local testing and
development. Hardware designers will write controls software to operate
their hardware during test and development. If the testing software is
written for a different control system than the one ultimately used for
its operation, it needs to be ported to the Operation Controls. If
off-site hardware designers use Controls in a Box, the integration is
straight forward and no porting is necessary. This not only saves the
time it takes to rewrite the software, but it also eases communication
by using the same terms and language when integrating new
instrumentation.

In the requirements below, 'Operation Controls' refers to the large
control system used to control the accelerator complex. 'Controls in a
Box' refers to the local, small version of the control system.

+------------+------------------------------------+---------+--------+
| **No.**    | **Requirement**                    | **S     | **Prio |
|            |                                    | ource** | rity** |
+------------+------------------------------------+---------+--------+
| CXR-CB-10  | The control system shall be        | S.Gysin | Ex     |
|            | available as a small scale version |         | pected |
|            | (Controls in a Box) intended for   | 01-2008 |        |
|            | local and autonomous use.          |         |        |
+------------+------------------------------------+---------+--------+
| CXR-CB-30  | Controls in a Box shall provide    | S.Gysin | Ex     |
|            | locally programmable               |         | pected |
|            | clock-simulating events.           | 01-2008 |        |
+------------+------------------------------------+---------+--------+
| CXR-CB-50  | Controls in a Box shall include a  | S       | Ex     |
|            | local and autonomous version of    | .Gysin, | pected |
|            | selected Central Services.         | A       |        |
|            |                                    | .Petrov |        |
|            | See section 4 requirement          |         |        |
|            | CRX-CS-25.                         | 01-2008 |        |
+------------+------------------------------------+---------+--------+
| CXR-CB-60  | The Central Services for Control   | S.Gysin | Ex     |
|            | in a Box shall at a minimum        |         | pected |
|            | include the Naming Service and the | 01-2008 |        |
|            | Data Acquisition Service.          |         |        |
|            |                                    |         |        |
|            | See section 4 for definitions      |         |        |
+------------+------------------------------------+---------+--------+
| CXR-CB-80  | Controls in a Box shall be able to | S.Gysin | Ex     |
|            | store data locally.                |         | pected |
|            |                                    | 01-2008 |        |
+------------+------------------------------------+---------+--------+
| CXR-CB-100 | Controls in a Box shall be free of | J.      | Ex     |
|            | dependencies on proprietary        | Patrick | pected |
|            | software.                          | 01-2008 |        |
+------------+------------------------------------+---------+--------+
| CXR-CB-110 | Controls in a Box shall be         | S.Gysin | D      |
|            | available and simple to down load  |         | esired |
|            | from the Web.                      | 01-2008 |        |
+------------+------------------------------------+---------+--------+
| CXR-CB-120 | Controls in a Box shall be Open    | A.      | D      |
|            | Source product.                    | Petrov  | esired |
|            |                                    |         |        |
|            |                                    | 01-2008 |        |
+------------+------------------------------------+---------+--------+
| CXR-CB-130 | Controls in a Box shall have an    | S.Gysin | D      |
|            | install script                     |         | esired |
|            |                                    | 01-2008 |        |
+------------+------------------------------------+---------+--------+
| CXR-CB-130 | Controls in a Box shall be easy to | J.      | D      |
|            | configure by offering the user a   | Patrick | esired |
|            | configuration wizard or a text     | 01-2008 |        |
|            | file to edit.                      |         |        |
+------------+------------------------------------+---------+--------+
| CXR-CB-140 | Controls in a Box shall be         | S.Gysin | Ex     |
|            | supported on Linux Operating       |         | pected |
|            | Systems                            | 01-2008 |        |
+------------+------------------------------------+---------+--------+
| CXR-CB-145 | Controls in a Box shall be         | S.Gysin | D      |
|            | supported on Windows Operating     |         | esired |
|            | Systems                            | 01-2008 |        |
+------------+------------------------------------+---------+--------+
| CXR-CB-150 | Controls in a Box shall provide a  | S.Gysin | D      |
|            | user interface to read and set     |         | esired |
|            | values                             | 01-2008 |        |
+------------+------------------------------------+---------+--------+
| CXR-CB-160 | Controls in a Box shall provide a  | S.Gysin | D      |
|            | user interface to export data.     |         | esired |
|            |                                    | 01-2008 |        |
+------------+------------------------------------+---------+--------+

# Beam-Based Feedback

In order to keep beam parameters such as position, energy, and intensity
stable through the linac and transfer line, and minimize losses, fast
feedback loops will be needed. This section addresses requirements for a
feedback infrastructure that works across major (5Hz) accelerator
pulses. It is assumed that intra-pulse feedback/feed-forward will be
handled by low level hardware. Inter-pulse feedback requires obtaining
data from sensors such as beam position monitors, performing
calculations, and writing settings to such devices as corrector magnets
prior to the next major pulse. The following are requirements for the
feedback infrastructure.

+-------------+-------------------------------+--------------+--------+
| **No.**     | **Requirement**               | **Source**   | **Prio |
|             |                               |              | rity** |
+-------------+-------------------------------+--------------+--------+
| CXR-BF-100  | There should be a standard    | J. Patrick   | Cr     |
|             | infrastructure that supports  |              | itical |
|             | creating and running feedback | 01-2008      |        |
|             | loops.                        |              |        |
+-------------+-------------------------------+--------------+--------+
| CXR-BF-110  | Data acquisition,             | J. Patrick   | Cr     |
|             | calculation, and setting      |              | itical |
|             | shall all be accomplished     | 12-2007      |        |
|             | between major pulses.         |              |        |
+-------------+-------------------------------+--------------+--------+
| CXR- BF-120 | It shall be possible to       | J. Patrick   | Cr     |
|             | involve multiple front-ends   |              | itical |
|             | in a feedback loop.           | 12-2007      |        |
+-------------+-------------------------------+--------------+--------+
| CXR- BF-130 | It shall be possible to       | J. Patrick   | Cr     |
|             | conveniently enable and       |              | itical |
|             | disable loops.                | 12-2007      |        |
+-------------+-------------------------------+--------------+--------+
| CXR- BF-140 | It shall be possible to put a | J. Patrick   | Cr     |
|             | lock on a disabled loop to    |              | itical |
|             | prevent it from being         | 01-2008      |        |
|             | re-enabled by another         |              |        |
|             | application or operator.      |              |        |
+-------------+-------------------------------+--------------+--------+
| CXR- BF-150 | It shall be possible to       | J. Patrick   | Cr     |
|             | easily mask sensors without   |              | itical |
|             | rebuilding or reloading code. | 12-2007      |        |
+-------------+-------------------------------+--------------+--------+
| CXR- BF-160 | It shall be possible to set   | J. Patrick   | Cr     |
|             | limits on sensor readings     |              | itical |
|             | used in calculations.         | 12-2007      |        |
+-------------+-------------------------------+--------------+--------+
| CXR- BF-170 | It shall be possible to set   | J. Patrick   | Des    |
|             | limits on absolute and        |              | irable |
|             | relative changes between      | 12-2007      |        |
|             | major pulses.                 |              |        |
+-------------+-------------------------------+--------------+--------+
| CXR- BF-180 | There should be sufficient    | J. Patrick   | Cr     |
|             | network bandwidth so that     |              | itical |
|             | readings are not lost or      | 01-2008      |        |
|             | delayed. Either the network   |              |        |
|             | must have sufficient          |              |        |
|             | intrinsic bandwidth, or       |              |        |
|             | should have Quality of        |              |        |
|             | Service capability.           |              |        |
+-------------+-------------------------------+--------------+--------+
| CXR- BF-190 | All sensor devices available  | J. Patrick   | Cr     |
|             | for use in calculations shall |              | itical |
|             | be available to the general   | 12-2007      |        |
|             | control system.               |              |        |
+-------------+-------------------------------+--------------+--------+
| CXR- BF-200 | Calculated results shall be   | J. Patrick   | Cr     |
|             | available to the general      |              | itical |
|             | control system.               | 12-2007      |        |
+-------------+-------------------------------+--------------+--------+
| CXR- BF-210 | Settings and the readings     | J. Patrick   | Cr     |
|             | used to compute them shall be |              | itical |
|             | logged. This information      | 12-2007      |        |
|             | shall include which if any    |              |        |
|             | sensors were disabled or      |              |        |
|             | excluded from the calculation |              |        |
|             | due to error status or data   |              |        |
|             | outside of limits. To reduce  |              |        |
|             | the logged data to a          |              |        |
|             | manageable volume, it would   |              |        |
|             | be acceptable to filter the   |              |        |
|             | data.                         |              |        |
+-------------+-------------------------------+--------------+--------+
| CXR- BF-220 | A counter indicating the      | J. Patrick   | Cr     |
|             | number of cycles performed    |              | itical |
|             | shall be available to         | 12-2007      |        |
|             | indicate the loop is          |              |        |
|             | functioning even if settings  |              |        |
|             | are not changing.             |              |        |
+-------------+-------------------------------+--------------+--------+

# Machine Protection System

The 8 GeV superconducting linac under consideration for Project X will
have the potential to produce beam pulses capable of damaging the
acceleration structures, the beam line vacuum chambers, and machine
components in the event of an aberrant accelerator pulse. As a result, a
Machine Protection System (MPS) must be considered to mitigate such
damage to the system. The MPS should be considered to be the collection
of all devices involved in the monitoring and safe delivery of beam to
its final destination and not limited to any particular subsystem or
diagnostic device. The MPS protects the machine only and is not a
personnel protection system.

To deal with different machine settings and operational scenarios, a
number of beam modes should be defined by the path that the beam must
take and the pulse intensity. This section outlines the controls
requirements for a protection system. It does not describe the various
modes of operation that will be a requisite part of the protection
scheme.

Multiple time scales of interest to the protection system design dictate
the required reaction times for various parts of the MPS system. The
slow part of the protection scheme will need to have a reaction time of
200 ms determined by the maximum pulse rate of the machine (5 Hz). Fast
signals that require switching off the beam immediately within a bunch
train must be processed rapidly enough to terminate beam in mid-pulse
depending upon the distance from the chopper. Such signals may include
RF signals and beam loss.

Several other subsystems will play a critical role with the MPS, namely
RF monitoring and quench protection monitoring. Signals derived from
both the low level and in some cases higher level RF systems can
potentially be used as precursors to failures whose results should be
available via the controls system. Time stamped diagnosis of this type
of data is desirable**.**

The assumption is that the existing machine protection systems, machine
specific beam permit/abort systems, and the Beam Switch Sum Box (BSSB)
will be used for legacy portions of the accelerator complex used in
Project X.

## General Machine Protection System Requirements

The machine protection system shall have several components including
machine and beam-line specific permit systems along with software and
hardware switches that inhibit or allow beam to the various
destinations. In addition, it is expected that the system will have
inputs from the safety system. The MPS requires a control interface that
allows for system configuration, system status displays and tools for
monitoring and diagnoses.

Since the machine protection system must prevent damage to accelerator
structures in the event of a mis-steered beam pulse or a component
mishap, the MPS system will therefore control the startup procedure and
monitor operations to detect and take immediate action if fault
conditions occur. A set of accelerator parameters and settings must
therefore be defined which allows for the safe transport of the beam.
This set of parameters will also characterize the maximum allowed
difference between pulses. Unless safe settings are detected and
subsequent beam pulses lie within the boundaries defined for operation,
no beam beyond a critical current can be injected.

+-------------+-------------------------------+--------------+--------+
| **No.**     | **Requirement**               | **Source**   | **Prio |
|             |                               |              | rity** |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-100  | The machine protection system | A. Warner    | Cr     |
|             | shall pre-establish safe      |              | itical |
|             | conditions for startup based  | 1-2008       |        |
|             | on the integrity of all       |              |        |
|             | preset conditions including   |              |        |
|             | steering magnets, beam        |              |        |
|             | position monitors, and RF     |              |        |
|             | power and phase.              |              |        |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-110  | The machine protection system | A. Warner    | Cr     |
|             | shall transition to a partial |              | itical |
|             | length beam pulse, then to    | 1-2008       |        |
|             | the full repetition rate of 5 |              |        |
|             | Hz, and finally to the full   |              |        |
|             | length beam pulse while not   |              |        |
|             | exceeding the pre-programmed  |              |        |
|             | inter-pulse difference        |              |        |
|             | (PPID).                       |              |        |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-120  | The machine protection system | A. Warner    | Cr     |
|             | shall actively compare each   |              | itical |
|             | new beam pulse with its       | 1-2008       |        |
|             | predecessor at the 5 Hz       |              |        |
|             | machine rate to check that    |              |        |
|             | operational conditions are    |              |        |
|             | met.                          |              |        |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-125  | If the conditions are         | A. Warner    | Cr     |
|             | violated, extraction shall be |              | itical |
|             | inhibited or the beam shall   | 1-2008       |        |
|             | be diverted to a beam dump    |              |        |
|             | before entering the next      |              |        |
|             | acceleration stage.           |              |        |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-130  | The machine protection system | A. Warner    | Cr     |
|             | shall monitor steady state    |              | itical |
|             | machine operations and        | 1-2008       |        |
|             | inhibit injection of pulses   |              |        |
|             | as appropriate if other       |              |        |
|             | faults suddenly occur. Such   |              |        |
|             | faults will include vacuum,   |              |        |
|             | magnet power supplies,        |              |        |
|             | excessive background, over    |              |        |
|             | temperature and of course     |              |        |
|             | beam orbit or feedback system |              |        |
|             | faults.                       |              |        |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-140  | The machine protection system | A. Warner    | Cr     |
|             | shall be sensitive to machine |              | itical |
|             | operation modes.              | 1-2008       |        |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-150  | The machine protection system | G. Vogel     | Cr     |
|             | shall make use of the Project |              | itical |
|             | X timing system, XCLK.        | 1-2008       |        |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-160  | The machine protection system | A. Warner    | Cr     |
|             | shall monitor the status of   |              | itical |
|             | the beam permit systems of    | 1-2008       |        |
|             | the legacy machines.          |              |        |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-170  | The machine protection system | A. Warner    | Cr     |
|             | shall archive timestamped     |              | itical |
|             | values when a failure event   | 1-2008       |        |
|             | occurs.                       |              |        |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-180  | There shall be an application | A. Warner    | Cr     |
|             | program to analyze a failure  |              | itical |
|             | event to determine the cause. | 1-2008       |        |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-190  | The machine protection system | A. Warner    | Ex     |
|             | shall maintain alarm as well  |              | pected |
|             | as inhibit ranges for input   | 1-2008       |        |
|             | parameters.                   |              |        |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-200  | The machine protection system | A. Warner    | Ex     |
|             | shall post alarms for input   |              | pected |
|             | parameters which are out of   | 1-2008       |        |
|             | tolerance.                    |              |        |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-210  | The machine protection system | A. Warner    | Cr     |
|             | must be expandable in terms   |              | itical |
|             | of numbers of inputs.         | 1-2008       |        |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-220  | The machine protection system | A. Warner    | Ex     |
|             | shall monitor long term       |              | pected |
|             | equipment failure information | 1-2008       |        |
|             | and generate alarms warning   |              |        |
|             | about potential failures.     |              |        |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-230  | The machine protection system | A. Warner    | D      |
|             | shall be designed with        |              | esired |
|             | redundant paths for detecting | 1-2008       |        |
|             | and responding to failures.   |              |        |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-240  | The machine protection system | G. Vogel     | Ex     |
|             | shall make use of             |              | pected |
|             | combinations of XCLK events,  | 1-2008       |        |
|             | beam permits, and beam        |              |        |
|             | switches to define            |              |        |
|             | operational modes.            |              |        |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-250  | The machine protection system | G. Vogel     | Ex     |
|             | shall be designed with both   |              | pected |
|             | mechanical and software beam  | 1-2008       |        |
|             | switches to prevent beam from |              |        |
|             | being accelerated to send to  |              |        |
|             | an area not intended to       |              |        |
|             | receive beam.                 |              |        |
+-------------+-------------------------------+--------------+--------+

## Beam Permit

A beam permit system is a system that generates a signal indicating that
the machine or beam line covered by the beam permit is ready to receive
beam. A typical beam permit at Fermilab consists of a signal source and
a standalone hardware path for the signal with local inputs that can
inhibit the signal from reaching its final destinations, usually the
BSSB and the beam dump or transfer device of the next most upstream
machine. In this way dropping a beam permit will both inhibit beam from
being transported into the non-ready area and prevent the next beam
pulse from ever leaving the source by inhibiting the chopper.

The linac beam permit system must protect the machine from damage due to
beam. It should be able to dump beam in the machine as well as
inhibiting future pulses until the initial problem is addressed.

+-------------+-------------------------------+--------------+--------+
| **No.**     | **Requirement**               | **Source**   | **Prio |
|             |                               |              | rity** |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-300  | The beam permit shall be on a | G. Vogel     | Cr     |
|             | separate hardware loop from   |              | itical |
|             | the control and safety        | 1-2008       |        |
|             | systems.                      |              |        |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-310  | The beam permit shall have    | G. Vogel     | Cr     |
|             | both software and hardware    |              | itical |
|             | inputs.                       | 1-2008       |        |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-320  | The status of all beam permit | G. Vogel     | Cr     |
|             | inputs shall be readable and  |              | itical |
|             | displayed via an application  | 1-2008       |        |
|             | program.                      |              |        |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-330  | The control system shall be   | G. Vogel     | Cr     |
|             | capable of resetting the beam |              | itical |
|             | permit.                       | 1-2008       |        |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-340  | All beam permit inputs shall  | G. Vogel     | Cr     |
|             | be configurable and maskable. |              | itical |
|             |                               | 1-2008       |        |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-350  | The control system shall      | B. Hendricks | Ex     |
|             | support limiting who can      |              | pected |
|             | configure given inputs to     | 1-2008       |        |
|             | prevent critical inputs from  |              |        |
|             | being improperly masked.      |              |        |
+-------------+-------------------------------+--------------+--------+
| CXR-MP-360  | The status of the beam permit | G. Vogel     | Cr     |
|             | shall be passed to the next   |              | itical |
|             | upstream system to prevent    | 1-2008       |        |
|             | beam from entering an         |              |        |
|             | inhibited region.             |              |        |
+-------------+-------------------------------+--------------+--------+

# Software Development Environment

This section will categorize software into two types of software. These
two types are applications and libraries. These two types are defined as
follows:

-   Applications ...

    -   have a "main" routine and are therefore capable of being run by
        a user given the proper run-time environment, and

    -   are not to directly contain code that is useful to other
        applications.

-   Libraries ...

    -   do not have a "main" routine, and

    -   contain code that is useful to other applications.

The term library is used despite that term being more closely aligned
with some program languages (C/C++) than others (Java) because of a lack
of a term that does not associate with any particular language. For Java
one can think of a "library" is being implemented as a "main"-less jar
file share by multiple applications. The term library was preferred over
"main"-less jar file because the term library while not used by Java is
used by languages other than (C/C++), e.g., FORTRAN, and is therefore
the more general term.

## Production Applications and Libraries

A goal of the software development environment (SDE) is to allow any
software upon which the accelerator complex becomes operationally
dependent to be reasonably maintained even after such software's
original author is no longer available. Another goal of the SDE is to
allow software to be developed upon which the accelerator is not
operationally dependent with less administrative burden than for
software upon which the accelerator complex is dependent. To support
these twin goals all software is categorized as either production or
non-production. Only production code should be used to operate the
accelerator complex. Additional requirements are enforced on production
software to insure its long-term maintainability.

The production vs. non-production distinction is applicable to both
applications and libraries.

+-------------+--------------------------------+------------+---------+
| **No.**     | **Requirement**                | **Source** | **Pri   |
|             |                                |            | ority** |
+-------------+--------------------------------+------------+---------+
| CXR-SD-100  | The SDE shall make a           | C.Schumann | E       |
|             | distinction between production | 1-2008     | xpected |
|             | and non-production             |            |         |
|             | applications/libraries.        |            |         |
+-------------+--------------------------------+------------+---------+
| CXR-SD-120  | For all production             | C.Schumann | E       |
|             | applications/libraries the SDE | 1-2008     | xpected |
|             | shall allow individuals to     |            |         |
|             | subscribe to code change email |            |         |
|             | notifications.                 |            |         |
+-------------+--------------------------------+------------+---------+
| CXR-SD-130  | For all production             | C.Schumann | E       |
|             | applications/libraries the SDE | 1-2008     | xpected |
|             | shall maintain                 |            |         |
|             | meta-information about the     |            |         |
|             | program, e.g., the developer   |            |         |
|             | currently responsible for the  |            |         |
|             | program                        |            |         |
+-------------+--------------------------------+------------+---------+
| CXR-SD-140  | For all production             | C.Schumann | E       |
|             | applications/libraries the SDE | 1-2008     | xpected |
|             | shall provide a deployment     |            |         |
|             | mechanism by which the         |            |         |
|             | application can be made        |            |         |
|             | available to all control       |            |         |
|             | system users.                  |            |         |
+-------------+--------------------------------+------------+---------+
| CXR-SD-150  | For all production             | C.Schumann | E       |
|             | applications/libraries the SDE | 1-2008     | xpected |
|             | shall maintain the             |            |         |
|             | applications source code in a  |            |         |
|             | version control system.        |            |         |
+-------------+--------------------------------+------------+---------+
| CXR-SD-170  | For all production             | C.Schumann | E       |
|             | applications/libraries The SDE | 1-2008     | xpected |
|             | shall insure that the          |            |         |
|             | application links only to      |            |         |
|             | production libraries. (3rd     |            |         |
|             | party libraries installed on   |            |         |
|             | the systems by the system      |            |         |
|             | admins are considered          |            |         |
|             | production libraries.)         |            |         |
+-------------+--------------------------------+------------+---------+
| CXR-SD-180  | There shall be a review        | C.Schumann | E       |
|             | process for the adoption of    |            | xpected |
|             | new third party libraries.     | 1-2008     |         |
+-------------+--------------------------------+------------+---------+
| CXR-SD-190  | The SDE shall provide          | C.Schumann | E       |
|             | maintenance of application     | 1-2008     | xpected |
|             | source code and front-end code |            |         |
|             | in the same system.            |            |         |
+-------------+--------------------------------+------------+---------+

## Non-Production Applications and Libraries

  -------------- -------------------------------- ------------- --------------
  **No.**        **Requirement**                  **Source**    **Priority**

  CXR-SD-200     The SDE shall allow              C.Schumann    Expected
                 non-production applications.     1-2008        

  CXR-SD-210     The SDE shall allow              C.Schumann    Expected
                 non-production applications to   1-2008        
                 link to 3rd party non-production               
                 libraries for testing purposes.                

  CXR-SD-220     The SDE shall prevent            C.Schumann    Expected
                 non-production applications from 1-2008        
                 being deployed through the                     
                 deployment mechanism reserved                  
                 for production applications.                   

  CXR-SD-230     The SDE shall provide a testing  C.Schumann    Expected
                 environment for non-production   1-2008        
                 applications.                                  

  CXR-SD-240     The SDE shall make it apparent   C.Schumann    Expected
                 to application users whether or  1-2008        
                 not they are using a production                
                 or non-production application.                 
  -------------- -------------------------------- ------------- --------------

## Modular Code Development

  -------------- -------------------------------- ------------- --------------
  **No.**        **Requirement**                  **Source**    **Priority**

  CXR-SD-300     The SDE shall distinguish        C.Schumann    Expected
                 between libraries and            1-2008        
                 applications.                                  

  CXR-SD-310     The SDE shall allow libraries to C.Schumann    Expected
                 use other libraries.             1-2008        

  CXR-SD-320     The SDE shall allow applications C.Schumann    Expected
                 to use libraries.                1-2008        

  CXR-SD-330     The SDE shall prevent            C.Schumann    Expected
                 applications from using other    1-2008        
                 application code directly. (This               
                 requirement is present to make                 
                 autonomous deployment of a                     
                 single application tractable.)                 
  -------------- -------------------------------- ------------- --------------

## Ease of Use

  -------------- -------------------------------- ------------- --------------
  **No.**        **Requirement**                  **Source**    **Priority**

  CXR-SD-400     Any system on which the SDE is   C.Schumann    Expected
                 made available shall be          1-2008        
                 equivalent to any other, e.g.,                 
                 the availability of libraries                  
                 should be identical.                           

  CXR-SD-410     The SDE environment shall        C.Schumann    Expected
                 automate the build process,      1-2008        
                 i.e., it should be capable of                  
                 building an application given                  
                 only a collection of source code               
                 and a modest amount of                         
                 meta-information about the                     
                 application without any build                  
                 system configuration in the form               
                 of makefiles or build.xml. The                 
                 meta-information mentioned above               
                 would include, e.g., any                       
                 libraries that the application                 
                 requires.                                      
  -------------- -------------------------------- ------------- --------------

## Integrated Development Environment (IDE)

The SDE shall provide support for the recommended IDE:

+-------------+--------------------------------+------------+---------+
| **No.**     | **Requirement**                | **Source** | **Pri   |
|             |                                |            | ority** |
+-------------+--------------------------------+------------+---------+
| CXR-SD-500  | The SDE shall recommend, but   | C.Schumann | E       |
|             | not mandate, an Integrated     | 1-2008     | xpected |
|             | Development Environment (IDE). |            |         |
+-------------+--------------------------------+------------+---------+
| CXR-SD-510  | The SDE shall provide          | C.Schumann | E       |
|             | plug-ins, if needed/useful,    | 1-2008     | xpected |
|             | for integration with other     |            |         |
|             | subcomponents of the SDE,      |            |         |
|             | e.g., the version control      |            |         |
|             | system                         |            |         |
+-------------+--------------------------------+------------+---------+
| CXR-SD-520  | The SDE shall provide          | C.Schumann | E       |
|             | site-specific documentation    | 1-2008     | xpected |
|             | about the IDEs use             |            |         |
+-------------+--------------------------------+------------+---------+
| CXR-SD-530  | The IDE shall support any      | C.Schumann | E       |
|             | language supported by the SDE  | 1-2008     | xpected |
+-------------+--------------------------------+------------+---------+
| CXR-SD-540  | The SDE source code control    | S. Gysin   | E       |
|             | shall only be for IDE          |            | xpected |
|             | independent files.             | 1-2008     |         |
+-------------+--------------------------------+------------+---------+

## Debugging Tools

+-------------+--------------------------------+------------+---------+
| **No.**     | **Requirement**                | **Source** | **Pri   |
|             |                                |            | ority** |
+-------------+--------------------------------+------------+---------+
| CXR-SD-600  | The SDE shall provide          | C.Schumann | E       |
|             | profiler(s) for supported      | 1-2008     | xpected |
|             | language.                      |            |         |
+-------------+--------------------------------+------------+---------+
| CXR-SD-610  | The SDE shall provide          | C.Schumann | E       |
|             | heap/memory leak debugging     | 1-2008     | xpected |
|             | tools.                         |            |         |
+-------------+--------------------------------+------------+---------+
| CXR-SD-630  | The SDE shall provide (an)     | C.Schumann | E       |
|             | appropriate source level       |            | xpected |
|             | debugger(s).                   | 1-2008     |         |
+-------------+--------------------------------+------------+---------+

## SDE Deployment

+-------------+--------------------------------+------------+---------+
| **No.**     | **Requirement**                | **Source** | **Pri   |
|             |                                |            | ority** |
+-------------+--------------------------------+------------+---------+
| CXR-SD-700  | A subset of the SDE shall be   | R.Re       | E       |
|             | available on the users'        | chenmacher | xpected |
|             | desktops.                      | 1-2008     |         |
+-------------+--------------------------------+------------+---------+
| CXR-SD-710  | There shall be a specification | A.Petrov   | E       |
|             | about how the client nodes,    |            | xpected |
|             | i.e., users' desktops, must be | 1-2008     |         |
|             | configured in order to run the |            |         |
|             | SDE.                           |            |         |
+-------------+--------------------------------+------------+---------+
| CXR-SD-720  | There shall be a mechanism for | C.Schumann | E       |
|             | deploying changes to the SDE.  |            | xpected |
|             |                                | 1-2008     |         |
+-------------+--------------------------------+------------+---------+

## Testing Environment

A completely inclusive virtual machine/complex testing environment shall
not be provided. This is a concession to the difficulty of providing
such a environment, which would to be truly complete would have to
provide a simulation of the real machine physics, the real database(s),
the real file system, etc. However, some testing environment will be
provided. Its capabilities are specified in the following requirements.

  -------------- -------------------------------- ---------------- --------------
  **No.**        **Requirement**                  **Source**       **Priority**

  CXR-SD-810     To facilitate (some) testing and R.Rechenmacher   Expected
                 perhaps                          1-2008           
                 learning/understand/embracing of                  
                 the control system, a scaled                      
                 down server and client                            
                 environment shall be provide and                  
                 maintained to allow for basic                     
                 testing of newly developed                        
                 client and server applications,                   
                 respectively.                                     
  -------------- -------------------------------- ---------------- --------------

## Diagnostics for Development and Deployment 

  -------------- -------------------------------- ---------------- --------------
  **No.**        **Requirement**                  **Source**       **Priority**

  CXR-SD-900     The SDE shall automatically      C.Schumann       Expected
                 provide embedded version         1-2008           
                 information in each build of an                   
                 application or library.                           

  CXR-SD-910     The SDE shall provide a log      R.Rechenmacher   Expected
                 which includes version           1-2008           
                 information.                                      
  -------------- -------------------------------- ---------------- --------------

## Version Control

  -------------- -------------------------------- ------------- --------------
  **No.**        **Requirement**                  **Source**    **Priority**

  CXR-SD-1000    The SDE shall require a comment  C.Schumann    Expected
                 for any code change.             1-2008        

  CXR-SD-1010    The SDE shall record the         C.Schumann    Expected
                 programmer for any code change.  1-2008        

  CXR-SD-1020    The SDE shall support renaming   C.Schumann    Desired
                 files and directories.           1-2008        

  CXR-SD-2030    The SDE shall support branching  C.Schumann    Desired
                 and should do this in a way that 1-2008        
                 does not interfere with users                  
                 who do not wish to use it.                     
  -------------- -------------------------------- ------------- --------------

## Collaborative Development

The SDE will support collaborative development. This breaks down into
two requirements which work together as a pair to insure a well-ordered
collaborative process.

+-------------+--------------------------------+------------+---------+
| **No.**     | **Requirement**                | **Source** | **Pri   |
|             |                                |            | ority** |
+-------------+--------------------------------+------------+---------+
| CXR-SD-1100 | The SDE shall support          | C.Schumann | E       |
|             | distribution of source code to | 1-2008     | xpected |
|             | collaborators.                 |            |         |
+-------------+--------------------------------+------------+---------+
| CXR-SD-1110 | The SDE shall support          | C.Schumann | E       |
|             | integration of source code     | 1-2008     | xpected |
|             | changes from collaborators     |            |         |
|             | back into production systems.  |            |         |
+-------------+--------------------------------+------------+---------+
| CXR-SD-1120 | The SDE shall track the use of | A.Petrov   | E       |
|             | distributed licensed third     |            | xpected |
|             | party code.                    | 1-2008     |         |
+-------------+--------------------------------+------------+---------+

## Issue Tracking

  -------------- -------------------------------- ------------- --------------
  **No.**        **Requirement**                  **Source**    **Priority**

  CXR-SD-1200    There shall be an issue tracking C.Schumann    Expected
                 system.                          1-2008        

  CXR-SD-1210    The issue tracking database      C.Schumann    Expected
                 shall support the ability to     1-2008        
                 assign an issue to any                         
                 developer.                                     

  CXR-SD-1220    The issue tracking database      C.Schumann    Expected
                 shall send notification when to  1-2008        
                 a developer when an issue is                   
                 assigned to him/her.                           

  CXR-SD-1230    There shall be a method          C.Schumann    Desired
                 available for correlating code   1-2008        
                 changes to the issue tracking                  
                 database.                                      
  -------------- -------------------------------- ------------- --------------

## Language Support

The best language for the task should be used.

+-------------+--------------------------------+------------+---------+
| **No.**     | **Requirement**                | **Source** | **Pri   |
|             |                                |            | ority** |
+-------------+--------------------------------+------------+---------+
| CXR-SD-1300 | The SDE shall support C/C++    | C.Schumann | E       |
|             | and Java.                      | 1-2008     | xpected |
+-------------+--------------------------------+------------+---------+
| CXR-SD-1310 | The SDE shall be extended to   | C.Schumann | E       |
|             | support other languages as     |            | xpected |
|             | approved by a review process.  | 1-2008     |         |
+-------------+--------------------------------+------------+---------+

## Documentation

  -------------- -------------------------------- ------------- --------------
  **No.**        **Requirement**                  **Source**    **Priority**

  CXR-SD-1400    The SDE shall support inline API C.Schumann    Expected
                 documentation which is to be     1-2008        
                 published to the web.                          
  -------------- -------------------------------- ------------- --------------

## Software Quality and Process

+-------------+---------------------------------+------------+--------+
| **No.**     | **Requirement**                 | **Source** | **Prio |
|             |                                 |            | rity** |
+-------------+---------------------------------+------------+--------+
| CXR-SD-1510 | Critical software shall be      | R.Neswold  | D      |
|             | developed by a team or peer     |            | esired |
|             | approach.                       | 1-2008     |        |
+-------------+---------------------------------+------------+--------+
| CXR-SD-1520 | The SDE shall provide a tool    | B          | D      |
|             | for viewing code in a standard  | .Hendricks | esired |
|             | format.                         | 1-2008     |        |
+-------------+---------------------------------+------------+--------+

#  Hardware/Operating Systems

## Hardware

The hardware requirements cover all three tiers of functionality as
described in Section 5: front-end nodes, central nodes and client nodes.

+------------+---------------------------------+-------------+---------+
| **No.**    | **Requirement**                 | **Source**  | **Pri   |
|            |                                 |             | ority** |
+------------+---------------------------------+-------------+---------+
| CXR-HO-100 | Commercially available hardware | D.Finstrom, | Desired |
|            | based on open standards         | J.          |         |
|            | (commodity hardware) shall be   | Smedinghoff |         |
|            | used whenever possible.         |             |         |
|            |                                 | 12-2007     |         |
+------------+---------------------------------+-------------+---------+

## Hardware Requirements for Low Level

Hardware requirements for the low level are covered in Section 3.2.

## Hardware Requirements for Central Nodes

The central node hardware should be chosen to minimize the operational
impact of hardware failure.

+------------+---------------------------------+-------------+---------+
| **No.**    | **Requirement**                 | **Source**  | **Pri   |
|            |                                 |             | ority** |
+------------+---------------------------------+-------------+---------+
| CXR-HO-200 | Central nodes shall use         | D.Finstrom, | E       |
|            | hardware that is rack           | J.          | xpected |
|            | mountable.                      | Smedinghoff |         |
|            |                                 |             |         |
|            |                                 | 12-2007     |         |
+------------+---------------------------------+-------------+---------+
| CXR-HO-210 | Central nodes shall support     | D.Finstrom, | E       |
|            | full-duplex gigabit Ethernet    | J.          | xpected |
|            | over copper at a minimum.       | Smedinghoff |         |
|            |                                 |             |         |
|            |                                 | 12-2007     |         |
+------------+---------------------------------+-------------+---------+
| CXR-HO-220 | Central nodes shall undergo a   | D.Finstrom, | Desired |
|            | burn-in process to minimize     | J.          |         |
|            | infant mortality failures.      | Smedinghoff |         |
|            |                                 |             |         |
|            |                                 | 12-2007     |         |
+------------+---------------------------------+-------------+---------+
| CXR-HO-230 | Central nodes shall be          | D.Finstrom, | E       |
|            | installed in a computer room    | J.          | xpected |
|            | with controlled access,         | Smedinghoff |         |
|            | sufficient power (both          |             |         |
|            | conventional and protected),    | 12-2007     |         |
|            | and environmental controls      |             |         |
|            | (CRX-NW-490, CRX-NW-500, and    |             |         |
|            | CRX-NW-510).                    |             |         |
+------------+---------------------------------+-------------+---------+
| CXR-HO-240 | Central nodes shall have a      | D.Finstrom, | E       |
|            | hardware support call list.     | J.          | xpected |
|            |                                 | Smedinghoff |         |
|            |                                 |             |         |
|            |                                 | 1-2008      |         |
+------------+---------------------------------+-------------+---------+
| CXR-HO-250 | Central nodes shall have a      | D.Finstrom, | C       |
|            | hardware support contract or    | J.          | ritical |
|            | adequate spares and a failover  | Smedinghoff |         |
|            | plan.                           |             |         |
|            |                                 | 12-2007     |         |
+------------+---------------------------------+-------------+---------+
| CXR-HO-260 | Central data storage and        | D.Finstrom, | E       |
|            | databases shall use hot         | J.          | xpected |
|            | swappable, redundant and        | Smedinghoff |         |
|            | scalable disk arrays.           |             |         |
|            |                                 | 12-2007     |         |
+------------+---------------------------------+-------------+---------+
| CXR-HO-270 | Critical (required for control  | D.Finstrom, | E       |
|            | system availability) central    | J.          | xpected |
|            | nodes shall have redundant      | Smedinghoff |         |
|            | power supplies.                 |             |         |
|            |                                 | 12-2007     |         |
+------------+---------------------------------+-------------+---------+
| CXR-HO-280 | A file backup system shall be   | D.Finstrom, | C       |
|            | provided for use by central     | J.          | ritical |
|            | nodes.                          | Smedinghoff |         |
|            |                                 |             |         |
|            |                                 | 12-2007     |         |
+------------+---------------------------------+-------------+---------+
| CXR-HO-290 | All control system data from    | D.Finstrom, | C       |
|            | central nodes shall be backed   | J.          | ritical |
|            | up.                             | Smedinghoff |         |
|            |                                 |             |         |
|            |                                 | 1-2008      |         |
+------------+---------------------------------+-------------+---------+
| CXR-HO-295 | Failed critical central         | D.Finstrom, | Desired |
|            | hardware shall utilize          | J.          |         |
|            | automatic failover.             | Smedinghoff |         |
|            |                                 |             |         |
|            |                                 | 1-2008      |         |
+------------+---------------------------------+-------------+---------+

##  Hardware Requirements for the Client Nodes

Client node hardware is the hardware executing only high-level
applications and is determined by the user. If a client node is unable
to execute high-level applications, they will be able to run the
application from a central node \[CXR-AI-30\]. Control rooms contain
client nodes with expanded display capabilities.

+------------+---------------------------------+-------------+---------+
| **No.**    | **Requirement**                 | **Source**  | **Pri   |
|            |                                 |             | ority** |
+------------+---------------------------------+-------------+---------+
| CXR-HO-300 | Control room client nodes shall | D.Finstrom, | E       |
|            | be capable of running multiple  | J.          | xpected |
|            | screen displays.                | Smedinghoff |         |
|            |                                 |             |         |
|            |                                 | 12-2007     |         |
+------------+---------------------------------+-------------+---------+
| CXR-HO-310 | Control room client nodes shall | D.Finstrom, | E       |
|            | have a hardware knob.           | J.          | xpected |
|            |                                 | Smedinghoff |         |
|            |                                 |             |         |
|            |                                 | 1-2008      |         |
+------------+---------------------------------+-------------+---------+

## Operating Systems

Operating system requirements cover for all three tiers of
functionality: low level, central nodes and client nodes.

##  Operating Systems for Low Level

+------------+---------------------------------+-------------+---------+
| **No.**    | **Requirement**                 | **Source**  | **Pri   |
|            |                                 |             | ority** |
+------------+---------------------------------+-------------+---------+
| CXR-HO-400 | The operating systems for low   | D.Finstrom, | Desired |
|            | level nodes shall comply with   | J.          |         |
|            | the Fermilab Strong             | Smedinghoff |         |
|            | Authentication Policy.          |             |         |
|            |                                 | 12-2007     |         |
+------------+---------------------------------+-------------+---------+
| CXR-HO-410 | As described by the Fermilab    | D.Finstrom, | Desired |
|            | Policy on Computing, the        | J.          |         |
|            | operating systems for low level | Smedinghoff |         |
|            | nodes shall be reasonably       |             |         |
|            | recent and supported versions   | 12-2007     |         |
|            | for which a Fermilab security   |             |         |
|            | configuration baseline exists.  |             |         |
+------------+---------------------------------+-------------+---------+
| CXR-HO-420 | The operating systems for low   | D.Finstrom, | Desired |
|            | level nodes shall support       | J.          |         |
|            | remote monitoring of system     | Smedinghoff |         |
|            | information (CXR-LL-320).       |             |         |
|            |                                 | 1-2008      |         |
+------------+---------------------------------+-------------+---------+
| CXR-HO-430 | The operating systems for low   | D.Finstrom, | Desired |
|            | level nodes shall support       | J.          |         |
|            | portable APIs such as pthreads  | Smedinghoff |         |
|            | (CXR-LL-280).                   |             |         |
|            |                                 | 1-2008      |         |
+------------+---------------------------------+-------------+---------+

## Operating Systems for Central Nodes

+------------+---------------------------------+-------------+---------+
| **No.**    | **Requirement**                 | **Source**  | **Pri   |
|            |                                 |             | ority** |
+------------+---------------------------------+-------------+---------+
| CXR-HO-500 | The operating systems for       | D.Finstrom, | E       |
|            | central nodes shall comply with | J.          | xpected |
|            | the Fermilab Strong             | Smedinghoff |         |
|            | Authentication Policy.          |             |         |
|            |                                 | 12-2007     |         |
+------------+---------------------------------+-------------+---------+
| CXR-HO-510 | As described by the Fermilab    | D.Finstrom, | E       |
|            | Policy on Computing, the        | J.          | xpected |
|            | operating systems for central   | Smedinghoff |         |
|            | nodes shall be reasonably       |             |         |
|            | recent and supported versions   | 12-2007     |         |
|            | for which a Fermilab security   |             |         |
|            | configuration baseline exists.  |             |         |
+------------+---------------------------------+-------------+---------+
| CXR-HO-520 | The operating systems for       | D.Finstrom, | Desired |
|            | central nodes shall support     | J.          |         |
|            | remote monitoring of system     | Smedinghoff |         |
|            | information.                    |             |         |
|            |                                 | 1-2008      |         |
+------------+---------------------------------+-------------+---------+
| CXR-HO-530 | The operating systems for       | D.Finstrom, | Desired |
|            | central nodes shall support     | J.          |         |
|            | portable APIs such as pthreads. | Smedinghoff |         |
|            |                                 |             |         |
|            |                                 | 1-2008      |         |
+------------+---------------------------------+-------------+---------+
| CXR-HO-540 | On central nodes, automated     | D.Finstrom, | Desired |
|            | operating system installation   | J.          |         |
|            | tools such as Kick start shall  | Smedinghoff |         |
|            | be used.                        |             |         |
|            |                                 | 1-2008      |         |
+------------+---------------------------------+-------------+---------+
| CXR-HO-550 | Scientific Linux Fermi shall be | D.Finstrom, | Desired |
|            | the preferred operating system  | J.          |         |
|            | for central nodes.              | Smedinghoff |         |
|            |                                 |             |         |
|            |                                 | 12-2007     |         |
+------------+---------------------------------+-------------+---------+
| CXR-HO-560 | The operating systems for       | D.Finstrom, | Desired |
|            | central nodes shall support     | J.          |         |
|            | random number generation.       | Smedinghoff |         |
|            |                                 |             |         |
|            |                                 | 1-2008      |         |
+------------+---------------------------------+-------------+---------+

##  Operating Systems for Client Nodes

+------------+--------------------------------+-------------+---------+
| **No.**    | **Requirement**                | **Source**  | **Pri   |
|            |                                |             | ority** |
+------------+--------------------------------+-------------+---------+
| CXR-HO-600 | The operating systems for      | D.Finstrom, | E       |
|            | client nodes shall comply with | J.          | xpected |
|            | the Fermilab Strong            | Smedinghoff |         |
|            | Authentication Policy.         |             |         |
|            |                                | 12-2007     |         |
+------------+--------------------------------+-------------+---------+
| CXR-HO-610 | As described by the Fermilab   | D.Finstrom, | E       |
|            | Policy on Computing, the       | J.          | xpected |
|            | operating systems for client   | Smedinghoff |         |
|            | nodes shall be reasonably      |             |         |
|            | recent and supported versions  | 12-2007     |         |
|            | for which a Fermilab security  |             |         |
|            | configuration baseline exists. |             |         |
+------------+--------------------------------+-------------+---------+
| CXR-HO-620 | Clients running Linux shall    | D.Finstrom, | Desired |
|            | use Scientific Linux Fermi.    | J.          |         |
|            |                                | Smedinghoff |         |
|            |                                |             |         |
|            |                                | 12-2007     |         |
+------------+--------------------------------+-------------+---------+
| CXR-HO-630 | The operating systems for      | D.Finstrom, | C       |
|            | client nodes shall support X   | J.          | ritical |
|            | Windows.                       | Smedinghoff |         |
|            |                                |             |         |
|            |                                | 12-2007     |         |
+------------+--------------------------------+-------------+---------+

# Networks

## Project X Network Overview

The Network shall be designed to support four distinct networks
including separate networks for the commissioning and operation of the
accelerator. The design should consist of a Controls network, DMZ
network (Demarcation Zone), Development network and General network. The
design shall supply secure network access for specific individuals via
authenticated gateways in the DMZ network to the Controls network. This
would include and encourage AAA access (authentication, authorization
and accounting) for users in other Fermi divisions and collaborators at
sites throughout the internet. The Development network shall allow for
testing an implementation of new devices, architecture, etc without
interfering with either the Controls or site network. The General
network shall accommodate desktops and laptops with authentication and
authorization as prescribed by site policy. Each of these networks shall
allow for necessary bandwidth, network protocols, VLANs and subnets,
secure authentication and authorization, ACLs, firewalls, redundancy,
cable plant, QoS, IPv6 and future technology changes.

  ------------- ----------------------------------- ------------ --------------
  **No.**       **Requirement**                     **Source**   **Priority**

  CXR-NW-10     The Network shall provide and       D. Stenman   Critical
                support a separate dedicated        1-2008       
                Controls network for accelerator                 
                controls                                         

  CXR-NW-20     The Network shall provide a DMZ     D. Stenman   Expected
                network for authenticated gateway   1-2008       
                access to Controls Network                       

  CXR-NW-30     The Network shall provide a         D. Stenman   Expected
                Development network that isolates   1-2008       
                development activities but allows                
                access to site and internet                      
                services, subject to network                     
                policies                                         

  CXR-NW-40     The Network shall support a General D. Stenman   Expected
                network for desktop, laptop and     1-2008       
                domain services                                  

  CXR-NW-45     The Network shall support AAA       D. Stenman   Expected
                access for intra Division personnel 1-2008       
                and collaborators throughout the                 
                internet.                                        
  ------------- ----------------------------------- ------------ --------------

![](media/image4.jpeg){width="6.0in" height="4.6305555555555555in"}

*Figure 1. The Four network modules*

## The Controls Network 

The Controls network shall be physically separate from the DMZ,
Developmental and General networks via dedicated infrastructure using
both fiber and copper cable plant along with separate distribution and
access network switches.

-   The Controls network shall have a Firewall for select traffic with
    default deny inbound and outbound except for selected services.

-   Authenticated access to the Controls network will be possible via
    gateway devices in the DMZ, including VPN (network based) and
    bastion hosts (login based).

-   Critical network services, such as NTP, DNS, KDC and W2k Domain
    controllers shall have instances located in the Controls network to
    maintain usability when isolated from the other networks.

-   A single point of disconnection shall be provided to enable total
    isolation of the Controls network from external network
    disturbances.

The Controls network shall be populated by network devices assigned
static IP addresses in the Class B space of 131.225.x.x

-   The third number in the dotted decimal notation shall be provided by
    Computing Division as requested by the AD Network Group, such as
    131.225.146.0 to 131.225.146.255)

-   The third and fourth set of numbers in the dotted decimal notation
    shall then be assigned by the AD Controls group. The third set of
    addresses shall refer to subnets having related functionality or
    geography.

-   AD Controls shall have an option to specify strategic address
    allocation for network diagnostic equipment, routers and switches

-   All Controls network addresses shall be in one CIDR block (able to
    be fully specified in the format 131.225.x.y/z where 0\<=x\<=255,
    0\<=y\<=255 and 16\<z\<32.).

  -------------- -------------------------------- -------------- --------------
  **No.**        **Requirement**                  **Source**     **Priority**

  CXR-NW-50      The Controls network shall be    D. Stenman     Critical
                 physical separate with a         1-2008         
                 dedicated cable plant and                       
                 network devices                                 

  CXR-NW-60      The Controls network shall have  D. Stenman     Critical
                 a firewall with default deny     1-2008         
                 inbound and outbound except for                 
                 select services                                 

  CXR-NW-70      Authenticated access to the      D. Stenman     Critical
                 Controls network shall be via    1-2008         
                 gateway devices in the DMZ                      
                 network, including both a VPN                   
                 and kerberized bastion hosts.                   

  CXR-NW-80      The Controls network shall be    D. Stenman     Critical
                 physically isolated by way of a  1-2008         
                 single point of disconnect.                     

  CXR-NW-90      Static IP addresses shall be     D. Stenman     Expected
                 assigned to devices in subnets   1-2008         
                 related to geography and                        
                 functionality.                                  

  CXR-NW-100     Critical network services such   T. Zingelman   Expected
                 as NTP, DNS, KDC and W2K Domain  1-2008         
                 controllers shall have instances                
                 located in the Controls network                 

  CXR-NW-110     All devices connected to the     D. Stenman     Expected
                 Controls network will have a     1-2008         
                 registered system administrator                 
                 responsible for them                            

  CXR-NW-120     All Controls network addresses   T. Zingelman   Desired
                 shall be in one CIDR block (able 1-2008         
                 to be fully specified in the                    
                 format 131.225.x.y/z)                           
  -------------- -------------------------------- -------------- --------------

## The DMZ Network

The DMZ network shall provide the method to access the Controls network.

-   There shall be a Kerberized bastion host and a VPN server in the DMZ
    that provide account authentication and allow login or network
    access for individuals according to Lab strong authentication
    policy.

-   There shall be a real-time distributed controls system gateway
    server in the DMZ network that will provide software running outside
    the Controls subnets with access to specific control and monitor
    points within the Controls network.

-   The real-time distributed controls system server shall recognize a
    subset of Lab User IDs from specific hosts and authorize them remote
    program access to the Controls network.

+-------------+----------------------------------+-----------+---------+
| **No.**     | **Requirement**                  | *         | **Pri   |
|             |                                  | *Source** | ority** |
+-------------+----------------------------------+-----------+---------+
| CXR-NW-122  | Only those devices in the DMZ    | D.Stenman | C       |
|             | network shall have access to the |           | ritical |
|             | Controls network.                | 1-2008    |         |
+-------------+----------------------------------+-----------+---------+
| CXR-NW-124  | There shall be a Kerberos and    | D.Stenman | C       |
|             | VPN server in the DMZ network    |           | ritical |
|             | for user authentication.         | 1-2008    |         |
+-------------+----------------------------------+-----------+---------+
| CXR-NW-126  | There shall be a real-time       | D.Stenman | E       |
|             | distributed controls system      |           | xpected |
|             | gateway server in the DMZ        | 1-2008    |         |
|             | network.                         |           |         |
+-------------+----------------------------------+-----------+---------+
| CXR-NW-128  | The real-time distributed        | D.Stenman | E       |
|             | controls system server shall     |           | xpected |
|             | recognize a subset of Lab User   | 1-2008    |         |
|             | IDs from specific hosts.         |           |         |
+-------------+----------------------------------+-----------+---------+

## The Development Network

The Network shall support a Development network to allow for engineering
and testing of components to be used in the Controls network.

-   The Development network shall isolate development activities from
    the other subnets, therefore not interfere with normal activities on
    the Controls network or AD and site-wide Fermi networks.

-   Network devices in the Development network shall be assigned static
    IP addresses and the Mac address, System Administrator, Primary User
    and location registered accord to Lab policy.

-   The Development network shall be accessible through secure channels
    to network devices, desktop and laptop computers used by the AD
    Controls Group, while also allowing for access to resources on the
    Fermi network and the internet.

The AD Controls Group shall be able to add a reasonable number of net
devices to the Development network, which will not be accessible from
the internet except through secure channel or have access to any service
outside the Fermi network.

-   The Development network shall contain a development server,
    accessible from all devices on the development subnet.

-   The Development server shall provide TFTP service (not visible
    outside the development network), NFS mount service, development
    tools (debuggers, compilers, etc), and any other software necessary
    for the Controls Group.

  ------------- ---------------------------------- ------------ --------------
  **No.**       **Requirement**                    **Source**   **Priority**

  CXR-NW-130    The Development network shall      D. Stenman   Expected
                isolate activities from other      1-2008       
                subnets                                         

  CXR-NW-140    All Development network nodes      D. Stenman   Expected
                shall have static assigned IP      1-2008       
                addresses, and be registered                    
                according to Lab policy                         

  CXR-NW-150    The Development network shall be   D. Stenman   Expected
                accessible through secure channel  1-2008       
                from Controls Group computers.                  

  CXR-NW-160    The Development network shall have D. Stenman   Expected
                a development server, accessible   1-2008       
                via secure channel by Controls                  
                Group and offering development                  
                services.                                       
  ------------- ---------------------------------- ------------ --------------

## The General Network

The General network shall offer secure access for development,
commissioning and general computing services, following Lab strong
authentication policy. The General network includes Static and DHCP
network addresses, WiFi access, Printing services, domain login,
personal home directory storage, WWW access and email. VoIP and Video
data streaming should also be included using QoS to insure network
priority.

-   General network shall have access to Fermi network and internet.

-   Static IP addresses shall be assigned desktops, printers and
    servers.

-   DHCP addressing shall be available for laptops.

-   The General network shall have support for QoS.

  ------------- ---------------------------------- ------------ --------------
  **No.**       **Requirement**                    **Source**   **Priority**

  CXR-NW-170    Fermilab strong authentication     D. Stenman   Critical
                policy shall apply to all network  1-2008       
                attached devices in the General                 
                network                                         

  CXR-NW-180    Static IP addresses shall be       D. Stenman   Expected
                assigned to desktops, printers and 1-2008       
                servers in the General network                  

  CXR-NW-190    DHCP addressing shall be available D. Stenman   Expected
                for laptops in the General         1-2008       
                network.                                        

  CXR-NW-200    The General network shall have     D. Stenman   Desired
                support for QoS.                   1-2008       
  ------------- ---------------------------------- ------------ --------------

## Acceptable Failure Rate and Impact 

Redundancy or immediate failover of key core and backbone network
resources shall be present in The Network, such as central router,
firewall, DNS, NTP, Kerberos. On-site spares shall be present which
involves manual replacement of access network equipment. Maintain of
these live spares shall consist of all network devices, including
backbone, distributed and access switches/routers.

  ------------- ---------------------------------- ------------ --------------
  **No.**       **Requirement**                    **Source**   **Priority**

  CXR-NW-210    Redundant firewall, border router, D. Stenman   Critical
                DNS server, NTP server, Kerberos   1-2008       
                server and W2K Domain server shall              
                be provided.                                    

  CXR-NW-220    7/24 hardware/software maintenance D. Stenman   Critical
                shall be provided for critical     1-2008       
                core routers and backbone switches              

  CXR-NW-230    On-site hot spares shall be        D. Stenman   Critical
                available to replace distribution  1-2008       
                and access network devices.                     
  ------------- ---------------------------------- ------------ --------------

## Monitoring and response

All network devices and services shall be monitored via a central
management station. A Management VLAN shall be configured for The
Network to enable secure login, software upgrade, traffic monitoring and
logging of network appliances. Allow for automated notification of
network degradation. Network problems shall be coordinated with the MCR
and a designated call list shall be provided for off-hour response.
Search for node location per switch port and visibility of network port
statistics shall be provided for users.

  ------------- ---------------------------------- ------------ --------------
  **No.**       **Requirement**                    **Source**   **Priority**

  CXR-NW-240    Network devices shall be managed   D. Stenman   Critical
                from a central server through a    1-2008       
                dedicated VLAN                                  

  CXR-NW-250    There shall be an automated        D. Stenman   Expected
                notification of network            1-2008       
                degradation                                     

  CXR-NW-260    Network problems shall be          D. Stenman   Expected
                coordinated with the MCR and a     1-2008       
                designated call list for off-hour               
                response                                        

  CXR-NW-265    Search for node location and port  D. Stenman   Expected
                statistics within switched network 1-2008       
                shall be provided for users                     
  ------------- ---------------------------------- ------------ --------------

## Physical Layout and Network Model

The Controls network shall be completely self-contained. Specifically,
it shall be able to perform all control system functions and provide all
services without a physical connection to any other network.

Infrastructure shall follow the TIA/EIA-568 standard hierarchical cable
system architecture using single mode fiber for backbone and
distribution layer, and copper for access of most attached devices.
Single mode fiber allows for 1 Gigabit (1000BASE-X) or 10 Gigabit
uplinks (10GBASE) while copper accommodates common 1 Gigabit interface
(1000BASE-T). Required is a comprehensive calculation of the number of
network attached devices, bandwidth/timing needs, distances from service
buildings, tunnels, Main Control Room, Data Center, and any specific
protocol requirements or priorities. 1U switches shall be used for the
access layer and network chassis for the distribution layer. Physical
separation of the four networks dictates individual switches and fiber.
Design shall resist the flat design model. Maintain a hierarchical
design that allows for isolation of critical systems, network/computing
security, distribution of higher or lower capacity sub-networks,
independent subsystem commissioning and network protocol or traffic
configuration.

The Controls network shall be centered in the AD Computer Room and
connect all areas of the AD accelerator facility.

-   All Controls network nodes shall have the ability to communicate
    with any other node in the Controls network.

-   Each device shall have a primary Ethernet connection on a specific
    subnet.

-   Some devices may desire a secondary Ethernet connection on a
    different subnet from their primary one.

-   No wireless access devices or nodes in the Controls network

-   Terminal service and power management shall also be available on
    dedicated subnets of the Controls network.

There shall be physical connection network taps located at specific
points in the accelerator area and wireless access points temporarily
available.

-   Only roll-around computers and laptops registered and/or configured
    by the AD network group shall have access in the accelerator area.

-   Wireless access points pre-configured by the AD network group shall
    be provided exclusively in the General net to allow restricted
    wireless access in the accelerator area.

There shall be uniform speed and duplex for connections within and
between all networks.

-   All network devices in the Controls and DMZ networks shall have the
    ability to communicate at speeds up to 1000 Mbps, full duplex,
    preferably on copper media except where distance or RF interference
    are an issue.

-   All network devices in the Development network shall have the
    ability to communicate at speeds up to 1000 Mbps, preferably on
    copper media except where distance or RF interference are an issue.

-   Connections to the Controls network from the DMZ shall have the
    ability to communicate at speeds up to 1000 Mbps.

Subnet Requirements; there shall be a set of VLANs (virtual networks or
broadcast domains) available on the Controls network to provide an
organized structure and isolate specific functions which have bandwidth
or timing requirements.

-   All subsystems shall have the ability to belong to a separate
    dedicated VLAN/subnet or broadcast domain.

-   There shall be a Network Management VLANs for dedicated network
    services.

  -------------- --------------------------------- ------------- --------------
  **No.**        **Requirement**                   **Source**    **Priority**

  CXR-NW-270     The Network cable system shall be D. Stenman    Critical
                 of TIA/EIA-568 Hierarchical       1-2008        
                 design using single mode fiber or               
                 better for the backbone and                     
                 Category 6e or better for access                
                 attached nodes                                  

  CXR-NW-280     The cable plant shall have        D. Stenman    Critical
                 individual cable and network      1-2008        
                 devices for the Controls network                
                 to ensure isolation from DMZ,                   
                 Development and General networks                

  CXR-NW-290     The Network shall have physical   D. Stenman    Expected
                 connection network taps located   1-2008        
                 at specific points in the                       
                 accelerator area.                               

  CXR-NW-295     There shall be no wireless access D. Stenman    Expected
                 devices or nodes in the Controls  1-2008        
                 network                                         

  CXR-NW-300     The General Network shall have    D. Stenman    Expected
                 wireless access points            1-2008        
                 temporarily available for the                   
                 accelerator tunnels and areas in                
                 addition to the permanent access                
                 points                                          

  CXR-NW-310     All subsystems shall have the     D. Stenman    Expected
                 ability to belong to a separate   1-2008        
                 dedicated VLAN/subnet or                        
                 broadcast domain                                

  CXR-NW-320     All Controls network nodes shall  D. Stenman    Expected
                 have the ability to communicate   1-2008        
                 with each other                                 

  CXR-NW-330     The only 'portable' devices which D. Stenman    Critical
                 shall be connected to the         1-2008        
                 Controls network are those that                 
                 have been securely configured by                
                 the network group                               

  CXR-NW-340     All network devices shall be      D. Stenman    Critical
                 capable of 1000 Mbps, full duplex 1-2008        
                 communication on all ports                      

  CXR-NW-350     All network devices shall be      T. Zingelman  Expected
                 capable of IPv6 operation         1-2008        

  CXR-NW-360     All network edge connections      D. Stenman    Expected
                 shall be via copper               1-2008        

  CXR-NW-370     All network distribution          D. Stenman    Expected
                 connections shall be via fiber    1-2008        

  CXR-NW-380     There shall be Network Management D. Stenman    Expected
                 VLANs                             1-2008        
  -------------- --------------------------------- ------------- --------------

## Network Security

The Controls network shall be fire walled with default deny inbound and
outbound except for selected services.

-   VPN, real-time distributed controls system gateway and Bastion Hosts
    shall be in the DMZ network to allow authenticated inbound traffic
    through the firewall.

-   Controls VPN shall have authentication time limited network access.

-   Bastion Hosts shall have Kerberized login as per Fermi strong
    authentication policy.

-   Bastion Hosts shall have time limited logins.

-   Bastion Hosts shall have SSH port forwarding allowed.

-   Bastion Hosts shall have NFS mounts of selected inside disk to allow
    kerberized FTP access (FTP shall be blocked at Firewall).

There shall be ACLs on particular subnets and/or VLANs to further limit
access for sensitive devices and ones that cannot conform to all
provisions of strong authentication.

Network devices shall reside on secure Network Management VLANs and
require either authentication login using Kerberos or individual Radius
user accounts.

There shall be an emergency disconnect at division border to ensure
Accelerator operation regardless of site or internet traffic storms.

Cyber protections shall provide security without disruption to
accelerator operations.

-   Patching and anti-virus services shall be available for OSs and
    Applications of all network attached devices, including network
    routers, switches and access points.

```{=html}
<!-- -->
```
-   Scanning of The Network for standard network services/ports,
    adherence to critical system patches and anti-virus shall be
    tolerated by all network attached nodes.

An inventory of all systems on the network shall be maintained, to
include OS, hardware, MAC address, IP address, sysadmin and primary user

-   Any changes in registered IP and MAC address shall have automated
    notification.

+--------------+------------------------------+-------------+---------+
| **No.**      | **Requirement**              | **Source**  | **Pri   |
|              |                              |             | ority** |
+--------------+------------------------------+-------------+---------+
| CXR-NW-400   | There shall be Access        | D. Stenman  | E       |
|              | Control Lists on subnets and |             | xpected |
|              | VLANs as required to provide | T.          |         |
|              | isolation in addition to the | Zingelman   |         |
|              | firewall.                    |             |         |
|              |                              | 1-2008      |         |
+--------------+------------------------------+-------------+---------+
| CXR-NW-410   | VPN, a real-time distributed | D. Stenman  | E       |
|              | controls system gateway and  |             | xpected |
|              | Bastion host shall have time | T.          |         |
|              | limited login.               | Zingelman   |         |
|              |                              |             |         |
|              |                              | 1-2008      |         |
+--------------+------------------------------+-------------+---------+
| CXR-NW-420   | There shall be an emergency  | D. Stenman  | E       |
|              | disconnect at division       |             | xpected |
|              | border.                      | T.          |         |
|              |                              | Zingelman   |         |
|              |                              |             |         |
|              |                              | 1-2008      |         |
+--------------+------------------------------+-------------+---------+
| CXR-NW-430   | Cyber protections shall      | D. Stenman  | E       |
|              | provide security scanning    |             | xpected |
|              | and patching without         | T.          |         |
|              | disruption to accelerator    | Zingelman   |         |
|              | operations.                  |             |         |
|              |                              | 1-2008      |         |
+--------------+------------------------------+-------------+---------+
| CXR-NW-440   | An inventory of all systems  | D. Stenman  | C       |
|              | on The Network shall be      |             | ritical |
|              | maintained, to include OS,   | T.          |         |
|              | hardware, MAC address, IP    | Zingelman   |         |
|              | address, sysadmin and        |             |         |
|              | primary user.                | 1-2008      |         |
+--------------+------------------------------+-------------+---------+
| CXR-NW-450   | Any changes in registered IP | D. Stenman  | C       |
|              | and MAC address shall have   |             | ritical |
|              | automated notification.      | T.          |         |
|              |                              | Zingelman   |         |
|              |                              |             |         |
|              |                              | 1-2008      |         |
+--------------+------------------------------+-------------+---------+
| CXR-NW-460   | Network devices shall reside | D. Stenman  | C       |
|              | within Management VLANs with |             | ritical |
|              | secure authentication.       | T.          |         |
|              |                              | Zingelman   |         |
|              |                              |             |         |
|              |                              | 1-2008      |         |
+--------------+------------------------------+-------------+---------+

##  Remote Network Monitoring

Network devices shall implement RMON, a flow-based monitoring and
analyzing client/server model. The RMON2 agents will include MIB legacy
groups of RMON1 (such as host statistics, top users, alarms, SNMP traps,
etc) and the extended groups of RMON2.

-   Network Statistics

-   Alarms

-   Hosts Statistics and top Hosts

-   Network-Layer Host

-   Network-Layer Matrix

-   Application-Layer Host

-   Application-Layer Matrix

-   Probe configuration

-   Protocol Directory and Distribution

  -------------- -------------------------------- ------------ --------------
  **No.**        **Requirement**                  **Source**   **Priority**

  CXR-NW-470     RMON shall be implemented to     D. Stenman   Desired
                 monitor and analyze Ethernet     1-2008       
                 packets                                       

  CXR-NW-480     RMON2 shall be included with its D. Stenman   Desired
                 extended MIB groups to add       1-2008       
                 support for network and                       
                 application layer                             
  -------------- -------------------------------- ------------ --------------

##  Data Center

The AD Computer room, XGC-108, shall expand to include additional
network equipment, Controls servers, Front Ends, Database servers, and
file servers.

Available conventional power shall be expanded to include additional
central service nodes, Controls database servers, Front Ends, etc.
Amount of expansion depends on watts per unit device.

Available UPS power shall be expanded to include additional central
service nodes, Controls database servers, Front Ends, etc. Amount of
expansion depends on watts per unit device.

Air flow and temperature and humidity control shall be increased
according to level of heat load per square foot within Computer Room.

  -------------- -------------------------------- ------------ --------------
  **No.**        **Requirement**                  **Source**   **Priority**

  CXR-NW-490     Conventional power in the        D. Stenman   Critical
                 computer room shall be expanded  1-2008       
                 according to increase of watts                
                 per unit device                               

  CXR-NW-500     UPS power in the computer room   D. Stenman   Critical
                 shall be expanded according to   1-2008       
                 increase of watts per unit                    
                 device                                        

  CXR-NW-510     Air flow and                     D. Stenman   Critical
                 temperature/humidity controls in 1-2008       
                 the computer room shall be                    
                 expanded to accommodate increase              
                 of heat load per square foot                  
                 within Computer Room.                         
  -------------- -------------------------------- ------------ --------------

# References

\[1\] Project X web site <http://projectx.fnal.gov/>

\[2\] Patrick, Jim "ACNET Control System Overview" Beams Document 1762,
February 17, 2005,
<https://beamdocs.fnal.gov/AD-private/DocDB/ShowDocument?docid=1762>

\[3\] McGinnis, Dave "Project X Overview", October 2007

\[4\] Carwardine, John et. al., "ILC Reference Design Report",
\"Requirements and Technical Challenges\" (3.12.2) , January 2007,
<https://docdb.fnal.gov/ILC-private/DocDB/ShowDocument?docid=371>

\[5\] Hendrickson, Linda, "Feedback Systems for ILC",

<http://docdb.fnal.gov/ILC-public/DocDB/ShowDocument?docid=166>

\[6\] Phinney, Non "Feedback Studies for ILC",
<http://docdb.fnal.gov/ILC-public/DocDB/ShowDocument?docid=12>

\[7\] Larson, Ray "Diagnostic Interlock Layer",
<http://docdb.fnal.gov/ILC-public/DocDB/ShowDocument?docid=49>

\[8\] Allen, C.K. et. al. "A Novel Online Simulator for Applications
Requiring a Model Reference",
<http://www-linac.kek.jp/seminar/2005/Allen-NovelSim-Icalepcs2003.pdf>

\[9\] Galambos, J. et. al, "Application Programming",
<http://neutrons.ornl.gov/APGroup/appProg/xal/talks/ASAC_March04.pdf>

\[10\]Church, Mike et. al, "ILCTA/NML Controls Requirements",
<http://docdb.fnal.gov/ILC-public/DocDB/ShowDocument?docid=325>

[^1]: \* A device may also have one or multiple aliases, per CXR-CS-55.

[^2]: \* Note that the Data Logging Service may interpret and alter the
    payload when the data is returned to clients; see \[4.4.1\].

[^3]: \* Time sequential group, see \[4.2.1\].

[^4]: \* A Web Application is a server-side component for a web browser,
    but as this technology becomes ubiquitous, Web Applications are
    viewed as an individual class of applications.

[^5]: † Without a graphical user interface.