WIP

Much like the Mechatronics Procurement Grades, this document aims to specify a graduated approach to third-party or outside vendors/partners building systems that will be accepted for integration into the LCLS control system.

It attempts to capture the following:

  1. Integration levels
    1. A higher level means the following:
      1. Increased levels of LCLS/SLAC autonomy in support, maintenance and modification
      2. Closer adherence to the LCLS-defined architectures/design templates for a given subsystem type (vacuum, motion, etc.)
      3. Increased support from LCLS during the design, build and test phase of the system
      4. More likely that the outside party will have to learn/adopt a new platform/design
      5. Future contracts with the third-party will incur less startup overhead
      6. Increased desirability and value to ECS
    2. A lower level means the following:
      1. More third-party autonomy in the design, fewer LCLS-dictated requirements on implementation 
      2. The system is treated more as a black box: LCLS controls team will/can not support future modification, or may only support it to a limited extent
  2. The impact of ongoing support for a system that is not implemented according to the LCLS control system architectures
  3. The overarching requirement for interface definition

Grades

Level 1

Third-party system exists outside of the LCLS control system and is not planned to be integrated.

Level 2

Complete third-party design autonomy, limited to no LCLS support for maintenance, modification, or issues with implementation. System interfaces to the EPICS control system by some standard or defined interface. (See Appendix A)

Level 3

Vendor uses ECS supported hardware & software platforms, but implements their own code-base. Interface may or may not be EPICS.

Level 4

Third party uses ECS supported platforms, design templates and codebase. Third party works closely with ECS to implement, test, and commission system.


Required Interface Definition

This interface should be defined and confirmed by the third-party and SLAC to at least 80% complete prior to finalizing any formal contract.

What is it?

A table of process variable names annotated with their respective data types and a description of purpose/functionality.

Ideally, this table would clarify what control and readback points would be available from the system being integrated.

Example

Via Modbus TCP

Readback NameTypeDescription
TankPressureINTPressure of the tank, read by <some gauge>, radix of 4
SystemStatusWORD

Bitmap of system status:


Description
1AOK
2Busy
3Error
WavelengthREALCalculated wavelength based on <device 1> and <device 2>


Control NameTypeDescription
DriveOutputINTPercentage of drive output
ChangeGasBOOLInitiate gas change sequence (rising edge)

Additional control/automation process flow diagrams.

Appendix A: List of preferred software interfaces

It is the 21st century and no one should have to endure anything other than a nice TCP socket established over a well-defined/adopted link standard like Ethernet. If there is time to develop a custom protocol, there is time to implement a standard like Modbus.

The following interfaces are considered acceptable, and are roughly in order of preference:

  1. EPICS/Channel Access
  2. Modbus/TCP
  3. Modbus/RTU
  4. SNMP/TCP

Unacceptable interfaces

The following interfaces will not be accepted:

  • Custom protocol over TCP or anything else
  • Serial: RS-485/232 (excluding Modbus)
  • Board-level serial interfaces (SPI, I2C)
  • Custom bit-bashing (TTL)
  • Boolean or analog electrical signaling


  • No labels

1 Comment

  1. Add interface sections for

    • Energy (pneumatics, electricity)
    • Cooling
    • Timing/event system
    • Auxiliary interface
    • Logging
    • Machine protection