1. TM & DVS status 29/10/2004

2. TM requirements (June 98) UR TMGR-1: TM shall have the ability to execute individual tests. UR TMGR-2: TM shall run on all the platforms supported by the DAQ OnlineSW UR TMGR-3: Output from individual tests shall comply with POSIX standard 1003.3 Pass, Fail, Unresolved, Untested, Unsupported UR TMGR-4: Apart from POSIX conforming output, the TM shall not impose any other constraints on the individual tests UR TMGR-5: TM shall only be used to execute tests when the DAQ is not taken data ?RM usage? ?define test usability attribute? UR TMGR-6: TM package shall provide tools and facilities to create tests in an uniform way and to add them to the global set of tests

3. TM design (June 98) Each test is one process started by PMG TM_Repository schema TM_DynDB not implemented RM not used Only 2 classes: TM_Client and TM_Repository

4. TM_Client implementation ( online-01-00-00 ) Move to DVS?

5. TM_Repository requirements (august 2001) TM_R-1: It shall be possible to find in the configDB the tests which correspond to the specific DAQ component (if such test exists) TM_R-2: It shall be possible to associate a test with a class in the configDB. In this case it must be possible to find out the correct test parameters and identify the machine on which the test must be executed TM_R-3: It shall be possible to define a test for a specific instance of a particular class while all the other instances of this class are tested by the default test TM_R-4: It shall be possible to implement a test by more then one process, executed in sequential or parallel mode. Synchronization and test ordering mechanisms shall be provided by the schema. ×

6. TM_Repository design (august 01)

7. TM_Repository implementation (online-01-00-00)

8. Verification and Recovery common requirements (April 99) UR DS-1: DS shall work in 3 modes: –DS is not operational; –DS is operational and reports the DAQ status and diagnosis to the operator; –DS is operational and performs error recovery actions automatically UR DS-2: DS shall collect status and configuration information about all online subsystems via TDAQ components UR DS-3: DS shall allow the operator to change the level of detail for the DS output information presentation UR DS-4: Changes of the DAQ configuration shall not impose any changes in the DS implementation UR-DS-5: DS shall imply no changes to the implementation of other OnlineSW components except the cases in which it is establish by agreement with the developers as essential for the DS functionality UR DS-6: Other OnlineSW components shall not need the presence of the DS to be able to work UR DS-7: DS shall provide user interface for: Seeing the current DAQ system status and explained diagnosis Seeing current DS status Stopping and restarting the DS Changing the DS operational mode Updating the knowledge base Browsing log information ×

9. common requirements cont. UR DS-8: DS shall be able to run in step-by-step and replay mode UR DS-9: DS shall be able to work in a multi-partition environment ? simultaneous tests on the same component? UR DS-10: DS may be tested without DAQ presence ! except pmg presence UR DS-11: DS shall provide an API for the following: Accept incoming control requests Access the current DAQ system status information Access the DS status information UR DS-12: DS shall produce the following information either on request or an incident on DAQ system: Current DAQ status Diagnosis for the current DAQ status Explanation for the current diagnosis Possible recovery actions Recovery actions made before UR DS-13: DS shall log its activity and results for debugging and archiving purpose × dsa

10. Specific requirements (April 99) Verification UR DS-V-14: DS shall be able to examine any DAQ component (hw and sw) at different level of detail to determine its functional state UR DS-V-15: DS shall use the TestManager package to perform tests and gather the test results --------------------------------------------------------------------------------------------------------- Recovery UR DS-S-16: DS shall be available in all the phases of data taking session UR DS-S-17: DS may use DVS to perform DAQ checks for diagnosis purposes UR DS-S-18: DS may use RunControl and PMG or DAQ Supervisor to perform automated error recovery actions UR DS-S-19: DS shall recognize repeated failure to recover the DAQ system UR DS-S-20: DS shall be scalable to provide reasonable response time regardless of the size of DAQ system UR DS-S-21: DS shall stop gracefully and not affect the DAQ functionality in the case of internal problems ×

11. New requirements DVS (Oct. 2004) Possibility to specify dependencies between different objects in DB Access to individual test (in a sequence) for one component Should log the result of test session (to a file or db) Should present results of previous sessions (history of testing) Should be possible to define levels of complexity of tests Interactive tests

12. DVS design (April 99)

13. DVS interface design (April 99) × × ×

14. DVS implementation (online-01-00-00

15. Next: think about 1.a: Tests for Composite object 2.b: Synchronous tests between children 3.Access to individual test for a component 4.Levels of complexity of tests attribute: test_scope 1.Logging 2.Panel in Java for a Hardware Control Center (new proposal from Lvl1)