Dear Friends,
I am glad to see that the discussion about the important
issue of security in disaster simulators has been started.
Here, I would like to express another part of my opinion
about this issue and suggest some ways towards developing
secure simulators and making the current simulators more
secure.
One issue arising while a simulator developer tries to
design a secure simulation scheme is 'fairness' which I
would like to define as 'the state of a simulator being
suitable for a Rescue Simulation competition'. To achieve
a more formal definition, let's see a simulated phenomenon
as a stochastic process (to be more specific a HMM) from
the viewpoint of a Rescue agent. A simulator is said to
be 'fair' if there is a way (at least theoretically) for
the agent to model this stochastic process with a small
pre-defined error ratio. The other requirement for being
fair is 'reproducability' i.e. there should be a set of
internal parameters that if set fixed would result in
exactly similar simulated behaviour from the simulator.
We will see that 'fairness' is somehow in a trade-off with
'security' but both can be achieved if certain principles
are taken care of by simulator developers. As an appendix to
this discussion, I would like to show that in addition to
not being so 'secure', the current version of MiscSimulator
even fails to achieve the goal of 'reproducability' and as
a result 'fairness'.
The first step towards developing a secure simulator is
to avoid developing fully deterministic behaviour. Here,
we have two alternatives:
* Keeping the deterministic behaviour but setting it up
based on a set of parameters which are transparent to
the agent. The simulator developer should be careful
not to use parameters which reserve no chance for the
agent to estimate, thus violating the 'fairness' property.
Also, the potential of reverse-engineering introduces
the need for not keeping the values of this parameters
fixed. In other words, teams should know that these
parameters may vary from one simulation to another.
* Modelling and implementing the simulated phenomenon as
a stochastic process. In a stochastic process, a certain
internal state may not always result in a certain behaviour
but there is a determined probability for each potential
behaviour to happen in each state. Here again, the developer
should take into account the 'fairness' property while
designing the scheme but the agent developer should also
note that 'THE ULTIMATE AND EXACT SOLUTION FOR MODELLING
A DISASTER SIMULATOR MAY NOT EXIST BUT MANY APPROXIMATE
SOLUTIONS ARE AVAILABLE'. This is exactly the case in
the real world. The experience of dealing with real-world
phenomena shows that any physical rule can be violated in
certain conditions so in the case of rescue agents dealing
with disasters, they should preserve a backup strategy
for the case something nearly impossible (I mean with
a very low probability in the modelled stochastic process)
happens. On the other hand, rescue agents, after assessing
an estimate for the possibilities of different behaviours
from the environment, should keep more attention to the
more possible behaviours and as a result should make
themselves more prepared for dealing with them.
I am personally in favor of this solution. Here are some
suggestion towards making a 'secure' yet 'fair' simulator:
- Constraint Modelling: There are always some constraints
that are to be satisfied in a process. As an example,
assume a Fire-Simulator having the constraint 'a burning
building of area 'a' cannot spread fire to a neighbor
building of area 'b' with b > 2a'. These kind of
constraints should not be imposed directly and in the
binary form. Instead, there should be a probability
for a constraint-violating phenomenon to happen that
is proportional to the inverse of the degree of its
violating that constraint.
- Internal Parameters: Agents should have direct access
to the values of all the parameters that are time-varying
in a single simulation. At least, the initial values for
these kind of parameters should be given to the agents
and the task of estimating the successive values of these
parameters can be put on the shoulders of agents. Here,
by 'parameters' I mean the set of 'mutually-independent'
parameters not all of them.
- Value Representation: The values for some of the parameters
are better to be represented in a quantized/Fuzzy/Symbolic
form for the use of agents. An example is the value of
'fieryness' which is a quantized representation of the
original value in the fire simulator. Here, the simulator
developer should dedicate considerable effort on assessing
an acceptable precision for these kind of representations.
Now, here are my suggestions towards securing ResQ-FireSimulator.
I am myself a volenteer for implementing them:
* The initial value of 'fuel' for each building is initially
set to a summation of three terms:
$ fuel(b) = fuel_d(b) + fuel_r(b) + fuel_s(b) $
where $fuel_d(b)$ is its deterministic fuel which can be
exactly computed by the agent (the current formula that is
used in the FireSimulator), $fuel_r(b)$ is a gaussian
random noise with mean of zero and variance equal to
$ \cfrac{1}{k}Mean_b(fuel_d(b)) $ where 'k >> 1' is a preset
constant, and finally $fuel_s(b)$ is the situation-based
amount of fuel in the building. Using this parameter, a
fuel distribution file is added to the set of files defining
a disaster situation which contains the amount of fuel in
the buildings based on what is inside them. This also
gives us the flexibility to design situations in which there
are certain areas that can burn very fast but there are some
that burn and spread fire very slowly.
* The initial value of 'fuel' for each building be given as
a property to the agents (agents must get close to the
buildings to sense this property) but not in an exact
form. Something like 5 to 10 levels of quantization would
be enough.
* Most (may be all) of the hard-constraints be transformed to
the soft-constraint form.
* The behaviour of temperature and fire spread for a building
of low area should become more undeterministic. As we reach
bigger buildings the behaviour should become more deterministic.
And I would like to add the point that implementing the above
changes are only very easy because of the great effort dedicated
by members of ResQ-Freiburg to design and implement an extensible
and configurable software.
OK! These were my suggestions. What do you think?
Now, let's see why I have argued that the current version of
MiscSimulator is not a fair simulator. As you may know,
MiscSimulator, as one of its tasks at each step, updates the
values of damage and HP for all ALIVE buried civilians. These
values are updated based on a formula that uses random values
generated by the class 'Dice' which itself uses the pseudo-
random number generator of C (rand() function). OK! Here's
the flaw: This kind of simulation is not reproducable. It's
strategy-dependent i.e. The strategy of a team may change
its behaviour in an incorrect way. Let's have an example:
Suppose the scenario in which there are four civilians C1,
C2, C3, C4 each being buried in a building which is far
from the others. We know that the pseudo-random number generator
generates values for computing damages of these buried civilians
in the order C1->C2->C3->C4. Now, consider two teams A and B
start working in this situation. Team A goes for rescuing C1
while Team B goes for rescuing C2. Team A rescues C1 earlier
and transfers C1 to refuge. From this time, we have the pseudo-
random number generator only generating values for C2->C3->C4
while for team B we have it generate values for C1->C2->C3->C4.
Yes! It is exactly the same as reinitializing their generators
with different seeds. From now, the successive states of C3
for the case of team A will be different from the corresponding
states of C3 for the case of team B while we are certain that
what the agents have done up to now should not affect C3, C4,
or any other civilians. Whether this change in the state is
in favor of A or B, we do NOT know. It depends on their
strategy and the initial value of random seed.
This was an instructing sample for incorrect usage of rand()
function and in general 'global' pseudo-random number
generators. This mistake, in other applications, may cause
a random generation strategy which aims to produce random
numbers of a certain distribution, to generate a random
population belonging to a different one. Of course, this
can be simply fixed by implementing a local instance-based
random generator and assigning each civilian a local instance
of random generator.
Regards,
Arash Rahimi
_______________________________________________
robocup-rescue-s mailing list
robocup-rescue-s@mailman.cc.gatech.edu
https://mailman.cc.gatech.edu/mailman/listinfo/robocup-rescue-s
Received on Thu Feb 02 16:53:31 2006
This archive was generated by hypermail 2.1.8 : Thu 02 Feb 2006 - 15:53:31 GMT