LLRP ROSpec Controller
From RifidiWiki
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.
Contents
- 1 Problems with Current ROSpec Controller
- 2 Ideas for next iteration of ROSpecController
- 3 Classes for new ROSpecController
- 4 Examples
- 4.1 ROSpec with null triggers and one AISpec with null triggers and reporting at end of ROSpec
- 4.2 ROSpec with null start trigger, duration stop trigger and AISpec with null Trigger and report at end of AISPec
- 4.3 ROSpec with periodic start trigger, null stop trigger. AISpec with duration stop trigger. reporting after N tags or end of AISpec
Problems with Current ROSpec Controller
- ROSpec is Runnable The ROSpec is an active entity; means that the Radio is polled every 250 milliseconds for new tags. This not only wastes CPU time, but also adds complexity to the ROSpec Controller
- 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
- Give control to Triggers Instead of the ROSpec being a runnable, the triggers should control the state changes of the ROSpec and the AISpec. This way the Radio is not polled. The AISpec can rely on the Tag Memory which keeps track of all the tags seen so far. When new tags are added to the memory, the AISpec can then check to see if an AccessSpec should be executed. A tag Observation trigger can keep track of how many tags have been seen if needed for a stop trigger or a notification trigger
- Pay attention to State transition It would help if explicit attention is paid to the transitions of ROSpecs from state to state.
- Allow objects to parse themselves Internal objects in the Rifidi LLRP reader are denoted by an underscore to differentiate them from the llrp-tk objects. For example, the internal Rifidi object is _ROSpec, and the toolkit object is called ROSpec. Currently, the _ROSpec is parsed in a handler method. However it would be easer if _ROSPec took in ROSpec in its constructor. In addition, it would be better if _ROSpec had a toROSpec method that would convert the internal object back into a toolkit object
