CSSeqArchitecturalDesignSpecification

The following UML diagrams should serve as documentation for the current design of the CSSequencer class package. Moreover I added some flow charts (download below) to explain the thread mechanism of the CSDuT class.

The scenarios, shown below, describe how threads are used within the CSDuT class to control the execution of multiple sequences without interfering each other if they access the same hardware resources and therfore the same device processes. The first example shows one DuT starting two threads that access different device processes --> both threads running in parallel without blocking each other.

The next diagram describes the same scenario but now both threads try to lock the same objects. One of the two gets the lock, the lock querry of the other is ignored by the proxy but it is saved. After running the sequence of the first thread and unlocking its proxies, the second thread is activated by the proxies that and now executes its sequences(scenario A) if it did not timeout (scenario B) before.
This locking mechanism also works for multiple DuT objects running multiple threads or parallel running sequencers that start DuT objects which lock the same device processes, as shown in the last sequence diagram:



Looking at the locking mechanism the execution order of threads that lock the same proxy objects is determined by their order of locking the proxies. In the current implementation this order can not be influenced. All objects are started in serial, but the time of locking can vary and therefore the order of getting the lock from the proxies is not determined. If it is necessary to have influence on the locking procedure one has to come up with a rule that should manage the order in which DuT objects lock their processes. One possibility might be that a central object collects all locks, searchs for all overlapping objects and therefor calculates the best order of locking the proxies. Another more simple solution is that all DuTs are started in serial and they also lock their proxies one after another. In this case one would have influence on the execution order by simply defining the order of starting the sequences.

All scenarios mentioned above describe the execution of elementary sequences that are configured hard coded in a "DuT" class inherited by CSDuT. This virtual class stores which and how processes are addressed in a sequence. Moreover it handles the execution of multiple sequences by starting threads and managing the lock mechanism by calling the proxy objects in a sequence. Mainly the CSDuT class serves as interface between any BaseProcess or especially the CSProxy class and the sequencer itself.

A test step is defined as a non-interruptable unit of DuT sequences that can run in parallel or serial depending on the device processes that are addressed. The general function of a sequencer is to execute several test steps and to provide possibilities to create a logic for executing them. The first approach on a sequencer is described by the state diagram below. It is just executing a list of test steps in serial and saving their results. What is missing is a intelligent control mechanism that includes typical structural elements like loops, branches or switch operations for controlling the execution order of test steps:

-- MaximilianKugler - 06 Apr 2006