ATLAS TDAQ Architecture WG. Notes of the meeting of 24-07-02

											GMO 25.07.02





 Present: Beniamino di Girolamo, Bob Dobinson, Saul Gonzalez, Benedetto Gorini, Reiner Hauser,
          Serguei Kolos, Giuseppe Mornacchi


 
 - Purpose of the WG:

	1) to coordinate the definition of the TDAq architecture for the TDR
	2) to address system wide TDAQ issues

 - What is in the scope of the wg and what is not should be carefully defined. Examples:

	in scope:
		definition of major elements (with functional, performance, etc. requirements)
		relationhips, boundaries, interfaces
		external dependencies
		operational aspects
		cost model
		completeness of documentation
		suggest measurements to be done on test beds/vertical slices
		.....

	not in scope:
		definition/organisation of test beds & vertical slices
		implementation in general
		internal design of major components
		.....
		

 - Deliverables: we should wait to define deliverables when we have a clear understanding of the
                 situation.

 - Mode of operation: 

	- a first phase to construct (out of the current system) the current tdaq architecture:

		- main components (hw and/or sw) (e.g. the ROS, the L2SV, the control system)
		- relationships & interfaces
		- TDAQ parameters (input, numbers associated to components)

	  this could be done starting from the RODs, following the path of the data and by
	  complementing the existing documentation with informal discussions with the people
	  responsible for the components. Multiple view of the system (dataflow view, control
	  view, etc.) should be considered.
	  The main deliverables of the first phase (on a time scale to be decided)

		- parameters document (containing numbers about #channels, RODs, event fragment sizes,
		  RoI distributions, etc.)

		- summary of the current architecture (in some form of a document or documents)


	- a second phase (the majority of the activity of the wg) with the objective of 

		- individuating problems, unresolved issues (in particular as regards the
		  interfaces betwee components), global issues. Prioritize them.
		- raising the problem and making sure that sub-systems address it (via one, or more
		  members of the wg, involved with the sub-systems)
		- integrating the solution (worked out by the sub-systems) into the tdaq architecture
		  description

 	the wg does not provide solutions, although individual members will likely participate to the
	definition of the solution. it raises problems and suggests actions

	Problems, issues, prioritization, formulation of actions and the result of these latter will be 
	discussed in regular open meetings.

	generally the wg will act as a catalyst between the tdaq systems and sub-systems.

	notes of the meetings will be drafted by giuseppe and distributed timely.
	an open mailing list and a web site, containing pointers to the activity of the wg (documents,
	notes, etc.), will be defined.


 - How to proceed:

	- giuseppe will draft notes of this meetings (here they are) by end of the week

	- giuseppe will draft a 1/2 page document summarising the purpose, scope and mode of operation
	  of the wg. To be submitted to the TDAQ mgt team the week of August 5th. We should also aim at
	  a vis-a-vis discussion with the mgt team that same week. (Draft doc. by monday 29/07)

	- giuseppe will merge together the proposals distributed by the wg members via e-mail (by end of
	  the week).

	- beniamino has accepted offline to coordinate the collection of the parameters

	- wg members will suggest (by the end of next week) "interesting documents" to be read by the wg

		Benedetto for the ROS
		Beniamino for the ROD
		Serguei for online
		Bob for data collection
		Saul for HLT