Overview
BarkIDS (or just IDS, Intruder Detection System) is an OSGi application (which are called bundles) that provides an intrusion detection system to the user, based on digital video cameras.
The system has several video cameras attached to the OSGi residential gateway, which can be either local cameras or network cameras. There is a remote control center (called IDSCC, IDS Control Center) which is the responsible for receiving the intrusion alarms when a movement is detected at any camera. The control center can also request an image or a video stream from a determined camera to be sent to the user terminal (called MMID, Multimedia Mobile Information Device), which has to have multimedia support. In addition the IDSCC can request information and remotely configure some aspects of the IDS.
The following figure outlines the system's appearance:
Use Cases
Analyzing the given system's overview, we define six use cases for this application:
As the reader can deduce, the first use case is the submittal of the notification of intrusion (which includes: the name of the originating camera, the date and a JPEG image where the movement was detected) to the IDSCC.
The second use case represents the SIP call establishment and RTP video sent to the MMID.
The third use case occurs when the IDSCC requests an image of a particular camera and the IDS sends it back in JPEG format.
The next use case defines an initalization sequence between the IDSCC and the IDS in which the IDS (that knows the IDSCC address in advance) sends to the IDSCC its URL where the latter can communicate with the former, and the IDSCC replys with a unique identificator assigned to this IDS.
The fifth use case, included in the initialization sequence of the previous use case, represents a request of information sent to the IDS, which replys with an array of strings with a defined format.
Finally, the last use case considers the remote configuration of the IDS from the IDSCC. As it is defined, two things can be configured: the alarm sound (on or off) and the detection responsiveness (four modes allowed: NORMAL, RELAXED, PANIC and OFF).
For the implementation of the communications between the IDS and the IDSCC involved in all use cases excepting the second (UC2: Control Call), webservices technology will be used, AXIS specifically. In the communications between the MMID (or the IDSCC acting as SIP proxy) and the IDS, SIP (Session Initiation Protocol) will be used for the call establishment and RTP for the video transmission. For the SIP portion, JAIN-SIP with NIST's implementation will be used in particular and JMF for RTP transmissions.
The following diagram shows the technologies used:
General architecture
BarkIDS application is composed of five modules:
- Detection module: it processes the video stream from the cameras, looking for any movement. When the beggining or the end of a movement is detected, it throws an event to the main module.
- Multimedia Call module: it receives and processes incoming SIP calls. When a call is established it sends out the video of the selected camera over the net using RTP.
- Webservices module: this module has two parts: a client side and a server side. The client side is used to accede the webservices offered by the IDSCC, and the server side is used to offer the IDS' webservices.
- Sound module: it plays an alarm sound (a barking dog) when the Main module requests it.
- Main module: this is the core of the application. It controls the initialization and destruction of all the other modules and it is also the responsible of the communications between them.
The following UML diagram shows the main relationships between modules and their interfaces:
When a movement is detected at the detection module (first use case), it sends a detection event to the main module so that it can play the sound using the sound module and inform the IDSCC through the webservices module (client side).
If the IDSCC requests an image from a camera (third use case), queries the application about its general state (fifth use case) or wants to configure the application (sixth use case), the main module will receive the corresponding request from the webservices module (server side) and will process it so that the webservices module can send the requested information or the configuration result back to the IDSCC.
When a MMID starts a SIP call (second use case), the multimedia call module processes it and sends out a RTP stream with the video of the selected camera, using the main module to obtain it.
Concerning the fourth use case, it defines an initialization sequence between the application (IDS) and the control center (IDSCC) than must be done when the IDS is started. This sequence is started from the main module and uses the webservices module (client side) to communicate with the IDSCC.
General class diagram
The UML diagram of all classes involved in the aplication looks like this:
There is a more detailed view of the application's design and implementation at the Full project report (in spanish).
Deployment
BarkIDS depends on other three OSGi bundles:
- JMF bundle: a bundle exporting all Java Media Framework resources.
- AXIS bundle: a bundle exporting all AXIS resources,
- or Telvent AXIS bundle: this is a OSGi bundle that provides a generic AXIS webserver where register any service. The choice is made by the configuration of the application.
- SIP Service bundle: a bundle which exports a generic SIP service. It can be downloaded with the main application.
The following UML deploy diagram shows its dependeces and contained packages:
