For a piece of equipment to be integrated into the EuXFEL control environment the equipment’s interfaces to the service groups involved need to be specified. Only once the Equipment Requirement Document (in the following ERD) is approved and integration work started, is the related equipment regarded as “under integration”. Since only supported equipment can be part of the CRD (Component Requirement Document), the approval of the ERD is a prerequisite and, if not present, will delay CRD approval. All new equipment requires an ERD.

Workflow:

The Equipment Requirement Document (ERD) records interfacing decisions made whilst passing through the following steps:

The requester initiates the ERD request by emailing erd-request@xfel.eu whereupon the requester will be contacted by email. Which ERD contact depends on the information specified in the email request template. The process of filling in the form is performed by the requester with help from the contact and may require the requester to provide additional information (manuals, operation requirements, etc.) to clarify whether the equipment has to be controlled and/or monitored by PLC, FPGA or directly by Karabo, whether interlock IO is required, and whether interfaces need to be clarified for the other service groups.
If no requirement is seen for the other service groups, then the ERD can be completed by EEE and/or CTRL quickly. Should requirements exist then the services concerned must review the equipment interface.
When completed, the ERD will be sent to DATA department groups as well as to SRP and TS (electrical safety) for approval. This step is important as a backstop for those groups who were initially not considered to have interface requirements.
Before the actual integration work can start and the equipment is seen as “under integration”., it has to be evaluated, if the estimated effort for all involved groups exceeds the threshold for which a formal MB project request and approval is required.

Interface tracking:

The ERD contains preliminary classification and interface integration checklists (checkbox panels) which are used to record interfacing decisions. Additional service group interface clarification text can be added in the special comments from experts for integration space.

Roles:

Requester – makes the initial request and provides additional information and implementation details during the ERD process.

Service groups – service group members responsible for evaluating the interface requirements

Lifetime:

Ideally there should be a 1:1 relationship between a piece of equipment and an ERD as the functionality defined in the interface definitions should not change. In order to reduce the risk of significant changes requested later, a board of stake holders will be formed during the ERD writing process to collect possible further requirements, to reach a potentially complete integration. However, this does not imply, that all features have to be implemented from the very beginning. If at any time the supported functionalities should be modified, a modified ERD should be submitted and re-evaluated.

Preliminary classification checklist¶

Direct integration through: ☐ PLC ☒ Karabo ☐ MicroTCA ☐ ToBeClarified

Communication channels present: ☐ IO-signals ☐ RS232/RS485 ☐ EtherCAT ☐ Ethernet (GigE) ☐ Ethernet (10G)

☐ USB-2 ☒ USB-3☐ PCIe ☐ Modbus ☐ IEEE-488 ☐ CAN

Board of stake holders and deadline statement¶

To be filled by Data Department

Role / Expertise	Group	Person
Author&Coord ERD process	EEE	Nicola Coppola
PLC FW developer&tester	EEE	NN
EET Coordinator	EEE	Joern Reifschlaeger
FPGA Expert/Coordinator	EEE	Bruno Fernandes
EDS Coordinator	EEE	Janna Eilers
CTRL Expert/Coordinator	CTRL	Giovanetti/ S.Hauf
ITDM Expert/Coordinator	ITDM	Janusz Szuba
External Requester	ChooseWP
Internal Requester	ChooseWP
	ChooseWP

**Deadline for the integration is: YYYY/MM/DD **

Integration interface checklist¶

To be filled by Data Department

PLC control (write) channels: ☐ IO ☐ Serial ☐ EtherCAT ☐ Ethernet ☐ Modbus ☐ CAN PLC monitor (read) channels: ☐ IO ☐ Serial ☐ EtherCAT ☐ Ethernet ☐ Modbus ☐ CAN Non-PLC control (write) channels: ☐ IO ☐ Serial ☐ EtherCAT ☐ Ethernet ☐ IEEE-488 Non-PLC monitor (read) channels: ☐ IO ☐ Serial ☐ EtherCAT ☐ Ethernet ☐ IEEE-488 Configuration by: ☐ PLC ☐ Non-PLC ☒ Display/Console ☐ Vendor tool Interlock requirements: ☐ PLC interlock source (Condition) ☐ PLC interlock target (action) FW, SW and Karabo interface requirements: ☒ use exisiting f/w and s/w: Astrotech integration (to be verified) ☐ develop new f/w and s/w: ________________ ☐ EEE + CTRL pairing set up ☐ new Gui widgets Equipment requires: ☒ System library/Specific Operating System: Astrotech integration ☐ Licenses ______________________, to be acquired by _________________	EEE-PLC & CTRL
Equipment requires: ☐ System library/Specific Operating System: ___________________ PLC f/w requirements: if ☐ new f/w block is required, indicate which in SW/FW requirements ☐ PLC Library: __________________	EEE-PLC
Trigger interface: ☒ETA train ☐ MTCA train ☐ ETA pulse ☐ MTCA pulse MTCA digitizer interfaces: ☐FastADC ☐ ADQ14 ☐ Other: MTCA interfaces: ☐10G ☐ Other: ________________________________ ______________ FPGA requirements: ☐new f/w development	EEE-FPGA
☐ Single function macro needed ☐ Function macro needed ☐ Typical needed	EEE-EET
DA requirements: ☐extra s/w development	DA
IT server s/w: ☐non-standard control server ☐ external libraries ☐ special kernel ☐ /dev driver IT special hardware: ☐PCIe ☐ PoE switch ☐ unmanaged switch ☒ Other: USB –> fibre range exenders DAQ requirements: ☐high storage ☐ 10GE☐Other:	ITDM
A test system is required ☒ A test system is available ☐ A demo test system can be organized ☒ by SCS A test system/demo test system is needed for long period ☐	All
TS requirements: ☐Chiller ☐Power ☐ Other:	TS
SRP safety issues present: ☐ :	SRP
Ticked OFF when resp. group processed checklist: ☐ PLC ☐ EET ☐ EDS ☐ FPGA ☐ Synch ☐ CTRL ☐ DAQ ☐ IT ☐ DA ☐ TS ☐ SRP	All

Special comments from experts for integration¶

Integration is preferred to happen by Astrotech, as for other Andor products. Possibly this works out of the box with the the integration we have from them, but would need to be tested.

If additional development is needed, SCS is to contact Astrotech for integration, and CTRL will follow up.

Equipment description¶

Marana is Andor’s high performance sCMOS camera platform for Astronomy and Physical Sciences, featuring 95% Quantum Efficiency (QE) and market-leading vacuum cooling to -45 °C. The platform offers solutions for large field of view and high-speed imaging/spectroscopy.

Controller connectors (overview)¶

#	Connector Name	Connector Type	Quantity	Possible group which uses it
1	POWER		1	EEE-EETF
2	TTL	Sub D, adapter to BNC exists	1	EEE-FE
3	USB 3.0		1	CTRL-ICI
4	Cooling water		1	TS
5

Connection overview (also mechanical)¶

Electrical connection¶

Please add from the manual

Karabo Details (properties or commands)¶

These are listed and explicitly explained in the respective implementation documentation which can be found under implementation document and in the link section.¶

Device features and possible use diagram¶

As a user I would like to be able to power the camera
As a user I would like to be able to acquire images from the camera into the DAQ
As a user I would like to be able to configure the integration time
As a user I would like to be able to configure the image binning
As a user I would like to be able to configure the image size
As a user I would like to be able to configure the trigger timing
…

Resource estimation for integration work

Task	Service	Sequenc eNr	TaskNr	Other groups involve d
Provide test setup	SCS	1	1	ITDM, CTRL
Astrote ch impleme nt Camera interfa ce	Externa l	2	1	CTR;
Impleme nt Karabo device	CTRL	3	1
Setup trigger s	EEE-FE	3	2	SCS?
Test system operati on	CTRL	4	1	SCS, ITDM

Overall FTE requirements estimated: 0 FTEs

Overall investments estimated: 0 k€

Links¶

Notes¶

[1]	^{, a,b,c,d} To be validated by ERD-pickup person

[2]	Other example: PT G25 400.

[3]	In the best of cases, there should be only 1 task ID

[4]	^{, a,b,c,d} To be validated by ERD-pickup person

[5]	Other example: PT G25 400.

[6]	In the best of cases, there should be only 1 task ID