2.3 Modeling Characteristics in the DSN Domain
2.3.7 Conflicts, Constraints and Resolution
Many of the more interesting aspects of organizational models revolve around the limits or constraints that are imposed on the system, and what happens when those limits are approached or exceeded. ODML models can represent both hard and soft constraints. The former include conditions which the designer has deemed untenable, while the latter are usually characteristics that degrade more gradually, and may be tolerated by the system.
Hard constraints may be modeled using constraint fields. A constraint is defined with a target, a relational operator, and an expression. To verify the constraint, both the target and the expression are evaluated to produce numeric values, which are then compared with the provided operator. The constraint is considered satisfied if the resulting relation is true, and unsatisfied if otherwise. Because a valid organi- zation must contain only satisfied constraints, these constraints are considered hard, or strict conditions that must be met. I mentioned earlier how a constraint on the sensors controlled field in the agent ensured a one-to-one mapping between sensors and agents. Similar constraints could be added to set an upper bound on average expected RMS, a limit on local work load, or a maximum number of agents in the organization. Although our sensors were hard-wired, a battery-driven sensor network could also be modeled by adding a suitable constraint to the agent. In this case, communication rates, action rates or the passage of time could decrement a battery constant. A constraint placing a lower bound on the battery would ensure that the unit met an expected minimum performance.
Soft constraints have a more subtle effect on the system. They are not explic- itly modeled using the constraint field. Instead, we represent them using equations that affect performance in response to other attributes. For example, in the sector manager, excessive communication load can delay directory service responses. This is modeled with adirectory delay field, which is then used to determine the values for
1 < node type = " t r a c k _ m a n a g e r " >
2 ...
3 < c o n s t a n t name = " d i r e c t o r y _ d e l a y " > f o r a l l a v g ( s m _ r e l a t i o n s . d i r e c t o r y _ d e l a y ) < / c o n s t a n t >
4 < c o n s t a n t name = " r e q u e s t e d _ m e a s u r e m e n t _ r a t e " > env . m e a s u r e m e n t _ r a t e * 4.0^ min (0 , v e l o c i t y * 1000 * ( ( env . n u m _ s e n s o r s / ( r e q u e s t e d _ s e n s o r s * org .
t o t a l _ t a r g e t s ) ) - 1.9) ) > (1 - ( v e l o c i t y / a v e r a g e _ s e c t o r _ p a t h ) * ( d i r e c t o r y _ d e l a y + m i g r a t i o n _ d e l a y /2) ) < / c o n s t a n t >
5 < / n o d e >
6
7 < node type = " s m _ t m _ r e l a t i o n " >
8 < p a r a m > o r g a n i z a t i o n : o r g , t r a c k _ m a n a g e r : t m , s e c t o r _ m a n a g e r : s m < / p a r a m >
9 ...
10 < !- - D i r e c t o r y D e l a y - ->
11 < c o n s t a n t name = " d i r e c t o r y _ d e l a y " > 3 0 0 0 < / c o n s t a n t >
12 < c o n s t a n t name = " p e r _ m e s s a g e _ d e l a y " > 0 < / c o n s t a n t >
13 < m o d i f i e r name = " d i r e c t o r y _ d e l a y " op = " + " > sm . c o m m u n i c a t i o n _ l o a d * 1000 * p e r _ m e s s a g e _ d e l a y < / m o d i f i e r >
14 < / n o d e >
Figure 2.16. A portion of the ODML specification that estimates the delay in directory responses that is experienced by a track manager. Thesm tm relationnodes determine the individual delays for each sector manager, while the track manager uses these values to estimate a worst case delay that is used to reduce the requested measurement rate.
delays incurred by sector directory queries and tracking task migration. Increases in those values will eventually increase the RMS error by slowing the rate at which the track manager acquires new sensor information.
The portions of model code which reflect this are shown in Figure 2.16. This is represented in the model by using a modifier to increase the directory delay in each sm tm relation by a value proportional to the sector manager’s communication load (line 13). The maximum directory delay observed by the track manager is then used to calculate the requested measurements rate. Therefore, although there is no fixed, arbitrary limit on sector manager load, excessive load will still degrade the system’s performance. A breaking point, at which the performance level has become untenable, can still be modeled using a hard constraint governing the value in question.
Soft constraints are also used to model the competition for sensors by track man- agers, as outlined in Section 2.2.2.4. The s tm relation in Figure 2.11 notifies each sensor of the requested measurement rate that will be asked of it. If the requested
rate exceeds the sensor’s capabilities, theactual measurement rategiven to the man- ager will be correspondingly limited. This will negatively affect the expected RMS error. Modifiers from multiple, competing managers requesting a sensor’s time will each increment the requested measurement rate. If the sensor’s measurement rate is exceeded, each manager’sactual measurement ratewill be reduced to some fraction of the possible rate proportional to what was asked for. This is accomplished as follows:
s tm.RM rate = tm.RM rate
s.RM rate ←−+ s tm.RM rate (modifier) s.AM rate = min(s.RM rate, env.M D−1) s.AM ratio = s.AM rate/s.RM rate s tm.AM rate = s tm.RM rate×s.AM ratio
tm.AM rate = s tm.AM rate
RM refers to requested measurement, AM to actual measurement, and M D to the expected duration of a measurement. So, although there is no set limit on the number of track managers, a “tragedy of the commons”-like degradation in quality can be predicted from overuse [192]. This same scheme can also be used to model notions of authority, autonomy and priority [6]. If multiple agents have disparate authority over another, then those differences can be reflected in the amount of utility they derive from that relationship. For example, if multiple track managers each had different authority over a particular sensor, then their relative levels of authority would determine the proportion of time that sensor would spend on their tracking tasks:
s tm.RM rate = tm.RM rate
s.AM priority ←−+ s tm.RM priority (modifier) s.AM rate = env.M D−1
s tm.AM rate = min(s tm.RM priority× s.AM rate/s.AM priority, s tm.RMrate)
tm.AM rate = s tm.AM rate
In the current model, all track managers implicitly have the same priority or level of authority, but as was discussed in Section 2.3.6, adding this type of heterogeneity among managers would can be accomplished in ODML.