Description
This architectural
scenario describes a motion tracking application which creates a
Situation Awareness Picture – a graphic real-time presentation of
people, detected by the video cameras, on a site map. The application
includes 3 types of resource allocation challenges:
-
Inter organizational resource
allocation – in which different organizations, running separate video
monitoring systems, require computational resources in order to run the
application.
-
Pipe line process resource
allocation – in which each camera-detection triggers a set of analysis
processes which must run in a defined sequence in order to produce the
relevant data. The real-time dynamic nature of a video monitoring
system prevents running the application in batch mode.
-
DAG resource allocation – in this
stage a target separation process is applied to the detected objects,
in order to separate the different objects and depict a reliable
picture on the map. In order to minimize the computational demands, the
process is applied with increasing resolution only in areas where
objects where detected. This means that the number of resolution
increases and the number of processes is not set and dynamically
changes in reaction to the real-world situation and the camera
detection. The main requirement for the real time allocation of
resources is that the allocation decision will be made immediately when
a resource becomes available (or when new resource allocation request
is available). Let’s assume that we have many customers (applications)
that compute on a limited number of resources (although, from an
architectural point of view, the problem is similar for the opposite).
Whenever a request for a resource arrives, the auction shall take place
(based on all the requests that are currently waiting) and will result
in a new request queue. As soon as a resource is available, it will be
allocated to the top priority request (highest bid in the queue). A
similar mechanism shall be used if the resources are "waiting" for the
applications in which case the auction shall take place between the
resources. The "real time" aspect means that if an application arrives
with a high bid it will get the resource immediately without delay
(ignoring of course the time of the bid). The overall system can be
more complex, for example it may handle multiple types of resources,
include time limits for resources and application, support accounting,
etc. however, I think that this type of capabilities can be postponed
for future versions of the system. Regarding the registration issue, I
think that the application should perform a preliminary registration
during the initialization of the process. The request for resource
shall be based on that registration.
|
Front page
