From: Giuseppe Mornacchi [Giuseppe.Mornacchi@cern.ch]
Sent: Tuesday, July 23, 2002 5:12 PM
To: Saul Gonzalez; Bob Dobinson
Cc: serguei.kolos@cern.ch; beniamino.di.girolamo@cern.ch; Benedetto
Gorini; reiner.hauser@cern.ch
Subject: RE: FW: AWG ideas



 Hi, here are a few ideas to contribute to launching the discussions.

 regards, giuseppe


 The "original" mandate of the working group as presented at the TDSG reads:


	Responsible for the coordination of the global TDAQ architecture, i.e.:

		- identification and specification of the major system elements
		- specification of their performance requirements
		- definition of their relationships and interfaces
		- addressing the system wide requirements (GIWG)

        Mode of operation
		- the work shall evove from an analysis of the current architectural solutions (internal review)
		- the working group will maintain a tight working connection with the sub-systems
		- meetings open to all TDAQ will be organised regularly


 
 This is more or less our starting point. Out of this I give you my opinions on:

	
	Purpose of the wg.
		
		- to coordinate the definition of the TDAQ architecture for the TDR (june 2003)
			major (to be defined) building blocks
			specify their requirements (functional, performance, etc.)
			define boundaries between building blocks
			define interfaces between building blocks

		- to address system wide TDAQ aspects

	Scope

		- major (to be defined) hardware and software components: definition & requirements
		- boundaries & interfaces between components
		- external dependencies (such as dependence on software not "produced" TDAQ as suggested by Saul)
		- operational aspects 
		- general cost/performance optimisations (????)
		- ......
	
	Not in scope

		- implementation in general
		- internal of components (e.g. the architecture may defined that there is a "ROS", its
		  functional/performance requirements but it has nothing to say about how it is done
		  internally)
		- ????

	Objectives:

		- The main objective is to provide an architectural definition for the TDR
		- deliverables etc. to be defined

	Mode of operation

		Coordination, information flow (as suggested by Bob), acting as a catalyst (as suggested by Saul)
		are keywords which characterise how the wg should operate (in addition to being useful and
		not interfering with the work of the others). May be we will need some initial "choral"
		work, for instance to work out (sort of reverse engineering) the current architecture and
		arrive at a starting point for concrete interaction with the tdaq sub-systems. Then we
		could act as "organisers" of common work between sub-systems (e.g. analysis of an existing
		interface between two components) and providers of information (via meetings which could
		be dedicated to a particular topic). Probably in the discussion I may be able to explain
		myself a bit better...



	

		My own list of things we could "do":

		1) define what are the parameters and standard values of interest to the tdaq architecture,
		   (e.g. # RODs, fragment size/ROD, ROI distribution etc.) and collect their values in a
		   document (to be regularly updated). 

		2) Starting from the internal review, extract the curretn tdaq architecture:

			identify the major components (e.g. the ROS, the RoIB, DFM, networks, etc.)
			identify their relationships: in particular the interfaces between components
			document the current architecture
			develop a "parametrised" description of the architecture (excel program?) which
			could also be used as a costing model. This is not a performance model, nor
			a validation model.

		   this should be the basis for further work. For example (with the people involved
		   in the sub-systems) one could attach to the components their requirements (functional,
		   performance, reliability, etc.), one could foster collaboration between sub-systems
		   (or between developers in a sub-systems) to better define/modify interfaces and 
		   boudaries, etc. I.e. evolve the architecture towards a satisfactory one.

		3) we could work with the people involved in sub-systems to individuate what are
	           the software (or hardware) blocks which could be rationalised (the typical example
		   is a buffer manager)

		4) the wg could launch and coordinate an effort to develop operational use cases for
	           the system (including malfunctioning, e.g. as suggested by Bob what happens if the
		   power goes off)

		5) identify commonalities in the use of the online software (e.g. supervision of farms,
		    access to data bases) and foster collaboration between sub-systems to arrive at
		   common solutions.

  
		plus all the other suggestions....