Difference between revisions of "LLRP ROSpec Controller"
From RifidiWiki
(New page: =ROSpec Controller= The ROSpec Controller is the component in the LLRP Reader that handles moving ROSpecs from state to state (disabled, inactive, active), starting and stopping ROSpecs an...) |
(→ROSpec Controller) |
||
| Line 13: | Line 13: | ||
:Triggers define when certain events (such as ROSpec start or stop) should happen. There are various kinds of triggers, such as time-based, GPI-based, or Tag observation-based. | :Triggers define when certain events (such as ROSpec start or stop) should happen. There are various kinds of triggers, such as time-based, GPI-based, or Tag observation-based. | ||
| − | =Problems with Current ROSpec Controller | + | =Problems with Current ROSpec Controller= |
| + | *'''AISpec is Runnable''' The AISpec is an active entity; it polls the Radio every 250 milliseconds for new tags. This not only wastes CPU time, but also adds complexity to the ROSpec, which has to manage a separate executor for each AISpec | ||
| + | *'''Triggers and Controllers are needlessly decoupled''' The Triggers and controllers use an Observer/Observable pattern with an intermediate object to communicate. For example, suppose a ROSpec has a duration trigger with a 10 second timer. When the timer goes to 0, the duration trigger will change a state variable (called the TriggerObservable) to false. The ROSpecController, which observes this state variable should stop when it changes. The idea was that the state variable would provide a consistent interface with which to start and stop ROSpecs and AISpecs. The problem is there are multiple kinds of triggers which all behave differently and require special needs. Code that should be in the Trigger is winding up in the ROSpec Controllers. In addition, the decoupled model makes debugging difficult because it is unclear as to which object is changing the state variable. | ||
| + | |||
| + | =Ideas for next iteration of ROSpecController= | ||
Revision as of 06:59, 28 May 2008
ROSpec Controller
The ROSpec Controller is the component in the LLRP Reader that handles moving ROSpecs from state to state (disabled, inactive, active), starting and stopping ROSpecs and AISpecs using Triggers, executing AccessSpecs, and sending RO_ACCESS_REPORTS back to the client. The main parts of the ROSpec Controller are:
- ROSpecController
- The class that maintains lists of currently added ROSpecs. It has methods that handler methods call to add, enable, start, disable, delete and get ROSpecs
- ROSpec
- The class that contains a list of AISpecs to execute. When active, steps through each AISpec in its list and executes them one at a time. The ROSpec finishes either when its stop trigger fires or when it has finished executing all AISpecs.
- AISpec
- The class that collects tag reads from the Radio according to some specific pattern (such as GEN2 tags on antenna 2). The AISpec finishes either when its stop trigger fires or when the ROSpec's stop trigger fires
- AccessSpec
- The AccessSpec controls more advanced operations on tags, such as writing IDs. Each time a new tag is seen by an AISpec, the AccessSpec checks to see if the tag matches a tag pattern. If it does match the pattern, then the the AccessSpec should perform the specified operation
- Triggers
- Triggers define when certain events (such as ROSpec start or stop) should happen. There are various kinds of triggers, such as time-based, GPI-based, or Tag observation-based.
Problems with Current ROSpec Controller
- AISpec is Runnable The AISpec is an active entity; it polls the Radio every 250 milliseconds for new tags. This not only wastes CPU time, but also adds complexity to the ROSpec, which has to manage a separate executor for each AISpec
- Triggers and Controllers are needlessly decoupled The Triggers and controllers use an Observer/Observable pattern with an intermediate object to communicate. For example, suppose a ROSpec has a duration trigger with a 10 second timer. When the timer goes to 0, the duration trigger will change a state variable (called the TriggerObservable) to false. The ROSpecController, which observes this state variable should stop when it changes. The idea was that the state variable would provide a consistent interface with which to start and stop ROSpecs and AISpecs. The problem is there are multiple kinds of triggers which all behave differently and require special needs. Code that should be in the Trigger is winding up in the ROSpec Controllers. In addition, the decoupled model makes debugging difficult because it is unclear as to which object is changing the state variable.
