LLRP ROSpec Controller - Revision history

Matt: Reverted edits by Amesycyxa (Talk); changed back to last version by Kyle

2010-11-26T19:43:30Z

Reverted edits by Amesycyxa (Talk); changed back to last version by Kyle

Amesycyxa at 23:14, 23 November 2010

2010-11-23T23:14:15Z

Kyle at 07:24, 28 May 2008

2008-05-28T07:24:36Z

Kyle at 07:18, 28 May 2008

2008-05-28T07:18:53Z

Kyle: /* Ideas for next iteration of ROSpecController */

2008-05-28T07:18:06Z

‎Ideas for next iteration of ROSpecController

Kyle: /* Ideas for next iteration of ROSpecController */

2008-05-28T07:17:39Z

‎Ideas for next iteration of ROSpecController

Kyle: /* Problems with Current ROSpec Controller */

2008-05-28T07:02:14Z

‎Problems with Current ROSpec Controller

Kyle: /* Ideas for next iteration of ROSpecController */

2008-05-28T07:01:10Z

‎Ideas for next iteration of ROSpecController

Kyle: /* ROSpec Controller */

2008-05-28T06:59:16Z

‎ROSpec Controller

Kyle: 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...

2008-05-28T06:35:36Z

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...

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 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

@@ Line 1: / Line 1: @@
 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:
@@ Line 27: / Line 19: @@
 *'''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 [[TagMemory|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 &lt;tt&gt;_ROSpec&lt;/tt&gt;, and the toolkit object is called &lt;tt&gt;ROSpec&lt;/tt&gt;. Currently, the _ROSpec is parsed in a handler method.  However it would be easer if &lt;tt&gt;_ROSPec&lt;/tt&gt; took in &lt;tt&gt;ROSpec&lt;/tt&gt; in its constructor.  In addition, it would be better if &lt;tt&gt;_ROSpec&lt;/tt&gt; had a &lt;tt&gt;toROSpec&lt;/tt&gt; method that would convert the internal object back into a toolkit object
+*'''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 <tt>_ROSpec</tt>, and the toolkit object is called <tt>ROSpec</tt>. Currently, the _ROSpec is parsed in a handler method.  However it would be easer if <tt>_ROSPec</tt> took in <tt>ROSpec</tt> in its constructor.  In addition, it would be better if <tt>_ROSpec</tt> had a <tt>toROSpec</tt> method that would convert the internal object back into a toolkit object
 =Classes for new ROSpecController=

@@ Line 1: / Line 1: @@
 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:
@@ Line 19: / Line 27: @@
 *'''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 [[TagMemory|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 <tt>_ROSpec</tt>, and the toolkit object is called <tt>ROSpec</tt>. Currently, the _ROSpec is parsed in a handler method.  However it would be easer if <tt>_ROSPec</tt> took in <tt>ROSpec</tt> in its constructor.  In addition, it would be better if <tt>_ROSpec</tt> had a <tt>toROSpec</tt> method that would convert the internal object back into a toolkit object
+*'''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 &lt;tt&gt;_ROSpec&lt;/tt&gt;, and the toolkit object is called &lt;tt&gt;ROSpec&lt;/tt&gt;. Currently, the _ROSpec is parsed in a handler method.  However it would be easer if &lt;tt&gt;_ROSPec&lt;/tt&gt; took in &lt;tt&gt;ROSpec&lt;/tt&gt; in its constructor.  In addition, it would be better if &lt;tt&gt;_ROSpec&lt;/tt&gt; had a &lt;tt&gt;toROSpec&lt;/tt&gt; method that would convert the internal object back into a toolkit object
 =Classes for new ROSpecController=

@@ Line 1: / Line 1: @@
 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:
@@ Line 21: / Line 20: @@
 *'''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 <tt>_ROSpec</tt>, and the toolkit object is called <tt>ROSpec</tt>. Currently, the _ROSpec is parsed in a handler method.  However it would be easer if <tt>_ROSPec</tt> took in <tt>ROSpec</tt> in its constructor.  In addition, it would be better if <tt>_ROSpec</tt> had a <tt>toROSpec</tt> method that would convert the internal object back into a toolkit object

← Older revision		Revision as of 07:18, 28 May 2008
Line 1:		Line 1:
−	~~=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:		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:

@@ Line 18: / Line 18: @@
 =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
+*'''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 [[TagMemory|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 <tt>_ROSpec</tt>, and the toolkit object is called <tt>ROSpec</tt>. Currently, the _ROSpec is parsed in a handler method.  However it would be easer if <tt>_ROSPec</tt> took in <tt>ROSpec</tt> in its constructor.  In addition, it would be better if <tt>_ROSpec</tt> had a <tt>toROSpec</tt> method that would convert the internal object back into a toolkit object

← Older revision		Revision as of 07:17, 28 May 2008
Line 18:		Line 18:

	=Ideas for next iteration of ROSpecController=		=Ideas for next iteration of ROSpecController=
−	*'''~~Make triggers runnable~~''' Instead of the ~~AISpec~~ being a runnable,	+	*'''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 <tt>_ROSpec</tt>, and the toolkit object is called <tt>ROSpec</tt>. Currently, the _ROSpec is parsed in a handler method. However it would be easer if <tt>_ROSPec</tt> took in <tt>ROSpec</tt> in its constructor. In addition, it would be better if <tt>_ROSpec</tt> had a <tt>toROSpec</tt> method that would convert the internal object back into a toolkit object

@@ Line 14: / Line 14: @@
 =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
+*'''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=
 *'''Make triggers runnable''' Instead of the AISpec being a runnable,

← Older revision		Revision as of 07:01, 28 May 2008
Line 18:		Line 18:

	=Ideas for next iteration of ROSpecController=		=Ideas for next iteration of ROSpecController=
		+	*'''Make triggers runnable''' Instead of the AISpec being a runnable,

← Older revision		Revision as of 06:59, 28 May 2008
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=