View - HEPHY

system. Each subsystem maintains its own configuration information, identifying eachconfiguration with a unique key. The global configuration of the trigger system isthen defined by a so-called TSC key, which simply aggregates configuration keys forall subsystems involved. The subsystem level of abstraction is also appropriate for usein the TestCell - while testing for data-taking would in principle be better served bydirectly relying on the global configuration keys in order to eliminate another errorsource, the creation of a new TSC key requires significant organizational overheadand so is not suitable for the development use cases. Subsystem keys are more easilycreated because the responsibility is more localized.Thus, all the existing tests require selection of both a GT and a GMT key from theconfiguration database. Configuration is performed before every test by sending therespective TS command to the cells (Configure for the GT and GmtConfigureFromDBfor the GMT). Relying on the cells for hardware access also guarantees that testsdo not accidentally interfere with data taking since the GT cell refuses to change itsconfiguration while a run is active.The actual execution of test cycles is implemented in the GT cell, using a differentcommand for each test type (FinorTest, PatternTest, InterconnectionTest). Sincesimulation data also has to be loaded into the GMT for the function tests, a separatecommand GmtLoadPatterns exists there. After initial experience showed that sendingthe whole pattern content as command parameters was slow (pattern data for an entireorbit is about 2.5 MB) and all the cells have access to a common file system, it wasdecided to use the file system for communication of larger data sets (pattern testoutput and pattern data). This means that the sub-cell commands get file systempaths for their input and output files.When a test is executed in the TestCell, an instance of the associated test operationis created and driven through a predefined set of state transitions. Figure 5.7 showsthe interactions in the case of a GT/GMT Function Test.5.3.4 PersistenceTest specifications and test results need to be stored persistently across cell restarts.Storing this information in the OMDS database was not considered adequate becausetest results generate large amounts of mostly unstructured data that are better storedin the file system. Consequently, the cell itself implements a simple persistence systemcalled a DirectoryStorage. This system manages a collection of named items, each ofwhich contains a single layer of named attributes. This interface is sufficiently generalto allow replacement of the underlying storage implementation without affecting theuser code.In the current implementation, each DirectoryStorage object manages one underlyingfile system directory. Items are mapped to subdirectories, and attributescorrespond to files in these subdirectories. Since attribute values are stored in textform inside the attribute files, the contents are easily accessible for both human andprogrammatic editing. The specifics of translating between the DirectoryStorageformat and the object representation have to be implemented by the appropriate65