Mobile based Security management system

1. CCTV Central Monitoring
System
Submitted by:
Mr. Mahesh Kumar
CTO
mahesh@sdlglobe.com
www.sdlglobe.com
Date of Submission:
, 2014

2. Our Understanding
Overview
There will be a team of observers in the central monitoring unit who shall be assigned and monitoring the surveillance cameras for
specific number of stores. The number of cameras for all the stores and their IP address will assigned to the specific observers. If there
are any incidents found by the observer while monitoring, they should be able to trigger an alert through the application and alert the
corresponding store managers.
SDL remote video monitoring system is an ultimate management tool for any retail shops, especially for the chain stores.
Scope
This document covers the scope of the project for CCTV central monitoring system. The client requires a
software application which can convert the existing analog videos into digital format which shall be
continuously monitored by a team of observers. The client presently has 54 different store locations where
the cameras have been installed. The observers need to access all the videos in one location. The observers
should be able send alerts for any incidents observed to local store managers. Workflows to setup the
reporting items, assigning observers for each location and alerts for incidents have to incorporated into the
software. Our understanding for the various features required for this application are given below:

3. The top management can employ CCTV and DVR system in most of its shops for central management. They can monitor the instant
video of each shops simply on his office computer through the phone line, Internet or mobile network connection.
The top management in office can perform simultaneous multi-store monitoring. They can also monitor up to 16 locations of each
store wherein only a unit of Video Recording Server connecting to 16 cameras and alarm systems is installed. Upon alarm occurrence,
immediate video recording and alarm dial-back can be run automatically by remote CCTV and DVR system. The recorded pre- and post-
alarm video inside video recording server can be used for visual alarm verification.
Main Features:
 Simultaneous monitoring on a number of stores and let the managers to have a thorough understanding on the business
operation and security
 Allocation of staff's duties and manpower
 Alarm system connection: allow instant video recording and auto-alarm dial-back
 Programmable video recording: monitor and record each store's real-time video
 Compatible with telemetry systems: keep track of each store from different angles
Remote CCTV system offers the users with fast, real-time, reliable and efficient remote visual monitoring and alarm verification solution.
Its main features include:
 Auto-alarm dial-back and visual verification upon alarm occurrence
 Highlighted image transmission for verification
 Alarm logs for easy reference
 Simultaneous multiple-site monitoring
 Password protection to avoid unauthorized usage
 Reliable operation with self diagnosis and recovery
Whenever there is alarm event, on-duty staff in the alarm centre can view the live image on the computer by controlling the
pan/tilt/zoom of the cameras before making any follow-up actions. In addition, the entire event starting from pre-alarm video to post-
alarm video can also be recorded. Police can then make use of the entire recorded video to undergo in-depth investigation.
Mobile: Mobile monitoring solution enables managers to view real time video with a mobile phone through 3G and GPRS data network
while they are not physically in office. This let managers handle the real situations of their offices at anywhere in anytime with ease
and convenience.
Surveillance DVR Remote Access iPhone / iPad App Setup

4. DVRs are remotely accessible on iPhone and iPad using the Mobile CMS iOS application (To be developed and designed by us). The app
will allow users to view all cameras connected to their DVR live from the app and view all the alarms as per the parameters preset in
the system.
Mobile APP Product features: (Assumptions)
 Arming and disarming of the alarm panel via app
 Status of the alarm panel can be accessed worldwide
 Individual zones can be switched on or off
 Wireless power sockets can be manually switched
 Log files (event logs) can be called up, allowing you to shed light on all events and alarms that have occurred, with sorting
function
 Alarms can be deactivated and are also displayed in the app
 The app can optionally be password protected in order to prevent unauthorized access
 The HD version for iPad with completely adapted user interface
 Up to three control panels can be managed at once
 Wizards for simplified control panel and camera setup
 Universal app: buy it once and use it for both the iPhone and iPad
 Saving of camera snapshots on your mobile device
 Push notification to your iPhone and iPad
Role Based Access
 The application should allow users to be added and the roles to be defined.
 Each user will be assigned different access levels – Observers and managers
 The observers in the central monitoring unit should be able to send alerts of any incidents to managers at the corresponding
locations.
 The number of cameras in every store and the departments in which they have been installed should be captured.
 They should be able to send alerts for any incidents in their corresponding stores. The managers should be able to view reports
in the corresponding stores.
 The Admin role will be able to view all the reports and assign user levels for each role.
Setup Reporting Items
 For all the stores there will be user level access given for observers and managers.
 They should be able to set up the reporting items for their corresponding stores.
 View reports for the reporting items in each store.

5.  Masters can be created to add new reporting items.
 Observers’ team monitoring all the stores shall be able to view the reporting items of the assigned stores.
Reports & Alerts
 Reports and alerts should be provided at every store level.
 The application should be configurable to trigger the type of alerts for the corresponding incidents.
 The central monitoring system should be able to view reports at each store level.
 Any incident should automatically trigger an alert to the central monitoring system.
Key Points
1) Allocation of Observer To Stores -- No. of Cameras -- IP Address
2) To all Stores --- Reporting Items setup
3) App alerts should show if any incident is reported by the observer
4) Observer/ Stores manager -- Roles will be created.
5) User level stores allocation for managers to receive alerts and view reports
6) Observer – User id level stores allocation to be done
7) Admin Role will be able to do all of both.

6. Security Management System
Stores ID location address
Responsible
Manager
Stores
number
Manager
Number
User defined
fields :4 or 5
Allocation of
Observer To Stores
-- No. of Cameras --
IP Address
Stores --- Reporting
Items setup
Camera IP address
-- person details
Reporting items --- App Alert Call 911 Call Manager
Call
owner
Call
Stores
Stores timing times y
work delay times y
Theft internal times y
external times y
Uniform y
Employee
Drugs y
Customer
Service y
Emergency fire y
power
outage y
Camera y
IT issues y
Accident y
Fuel Spill y
Unlawful
activity y
Damage y

7. Employee
Personal
Usage y
Personnel
Shortage
No. of
days
continuous
then send
the
snapshot y
Fight y
Store Closure
No. of
times
closed /
No. of
Hours
closed y
Sales outside
Counter y
Sales in
Parking lot y
Bullet proof
door lock y
Weapon y
Stores
Cleanliness y
Using Stores
Merchandise y
Note:
1. App alerts should show if any incident is reported by the observer
2. Observer/ Stores manager -- Roles will be created.
3. User level stores allocation for managers to receive alerts and view reports
4. Observer – User id level stores allocation to be done
5. Admin Role will be able to do all of both.

8. System Requirement
‐ Microsoft Windows XP with SP2 / Windows Vista / Windows 7 / Windows Server
2003 / Windows Server 2008
‐ Display adapter with 256 MB memory or above
‐ 4 GB system memory
‐ 1 TB free hard disk space

9. ‐ Microsoft DirectX 9.0c or above
‐ Microsoft .NET Framework 4.0 or above
Technical Documentation
INTRODUCTION
1.1 Purpose
This software design document describes the architecture and system design of the Mobile Client Query Application and is
intended to inform stakeholders of the details of the design and the design process.
1.2 Scope
The main objective for this project is to provide a mobile application, the Mobile Client Query Application, to our Client, on the
Android platform, that will assist inspectors by providing functionality to update item data in the field. The Mobile Client Query
Application will empower inspectors with the ability to view and update data about the items they are inspecting while they are in
the field, thus reducing office time to digitize their findings and upload them. To accomplish those goals the project will also
include a central server that hosts the database, processes data requests, and has a graphical user interface to access the
server/database directly.

10. 2. SYSTEM ARCHITECTURE
2.1 Architectural Design

11. The Mobile Client Query Application is broken down into two major subsystems, the mobile client and the server. The two
subsystems will interact with each other by using a server/client model. The server will store all of the data, including but not
limited to: the database of item information, login information, and error logging information. The client will send and receive data
to and from the server to view or edit information about the items. Mobile clients and web clients will also send error logging
information to the server, however, this information will only be visible via the web client with the right permissions.
The subsystems will use XML messaging to communicate. Each subsystem will be capable of converting requests into XML
messages and parsing the XML messages back into usable data.
By using these design pattern, multiple mobile clients and web clients can access the data and each subsystem can be updated or
switched out without affecting the other subsystems.
2.2 Decomposition Description
Figure 2.2 - This logical view depicts the decomposition of each subsystem into components and how the components interact with each other.

12. The mobile client subsystem is divided up into a three layered architecture, it has a user interface, application, and device layer.
Each layer has its own interface that other layers can use to interact with it. The user interface layer contains an observer object
and updates its data, using data from the observable application layer, via the observer pattern. The application layer handles
threads, logs, and converts messages from the user interface layer into XML messages and sends them to the device layer. The
device layer handles the interactions with the hardware, all the features of the phone necessary for the application, including but
not limited to: wifi, gps, and ports to send and receive data to and from the server. Each layer is also a component that can be
individually updated or replaced as long as the interface remains the same.
The server subsystem contains a web client component, server manager component, database component, and communication
component. The web client component is a simple desktop application that connects to the server and follows the same rules for
communication as the mobile client, it sends and receives XML messages. The server manager component handles the threads,
message parsing, and database queries. The database component stores all of the data for the system. The communication
component handles the ports and the sending and receiving of messages.
2.3 Design Rationale
The server/client model was chosen due to its ability to store all of the data in a central place and allow access to multiple system
simultaneously. This design also allows supports the use of multiple types of clients, which is especially important as the system
already contains two different clients.
This design has a few issues and trade-offs associated with it. Since all of the data is stored in a central location, if something
happens to that server then all of the clients will lose connection and permanent data lose can occur. However, by having all of the
data in a central location, it is cheaper and simpler to manage.
The design also hinges on network access. If there is no network access available, the client systems will not be able to send or
receive any data. This is acceptable as the projected size of the database will exceed the space limits on almost all of the clients. In
addition, syncing databases between large numbers of clients is unfeasible.
The layered and component architectures were chosen as they both support principles of maintainability, portability, flexibility,
testability, reusability, and interoperability. The system can be ported to different platforms by changing the device component to
match the hardware the system will be ported to. This swapping feature also allows for easier maintenance and updates to the
system, replacing a single component rather than re-downloading the entire application. This architecture enhances
interoperability by using interfaces to communicate between components, thus increasing cohesion.

13. 3. COMPONENT DESIGN
3.1 Component Description
3.1.1 Mobile Client Subsystem
Figure 3.1 - The detailed design of the User Interface component.

14. Figure 3.2 - The detailed design of the Application component.
Figure 3.3 - The detailed design of the Device component.

15. Figure 3.4 - The detailed design of the Messaging component.

16. 3.2 Data Dictionary
The information domain of our system consists of the different types of information about commercial cargo items. Our contact
described a list of data types which has been added to a central database. The data stored in our central database is queried by
the server which receives messages from the web-app and the Android app. The data is organized by tables in a relational
database.
 Additional Notes - lets users add any additional information about the item to the database.
 Analytic Scores - up to 5 analytic scores that let users.
 Client Number - ALPHA-NUMERIC item name.
 Consignee - Company having item shipped.
 Current Destination - Current item location.
 Fused Score - Averaged analytic score.
 Hazmat Code - Codes to relate to any unstable or concerning contents.
 Manifest Description - What is in the item.
 Password - Security code
 Previous Port - Shows the previous location of the item.
 Shipper - Information on who was shipping the item.
 State of Client - Set the item to normal or anomalous.
 TransPort - Up to the last 5 previous locations.
 User Name - Save usernames to allow access.
4. HUMAN INTERFACE DESIGN
4.1 Overview of User Interface
The user interface has been designed to be similar to the standard android interface, a black background with white text was
chosen as our standard because the ease of visibility and ability to read. The flow of the interface has been designed around the
idea of searching for items, updating information, and displaying the returned. After displaying the information returned an
option will be available at the bottom of the list to edit information about that item and save that new information. After selecting
save information from the update information screen it will take you back to the item information screen and display the new
information that was changed about that item.

17. 4.3 Screen Objects and Actions
 Buttons - Clickable boxes that allow data manipulation and screen changes.
 Text Boxes - Allows user to input any ALPHA-NUMERIC characters in order to search for items and change information.
 Radio Buttons - Circular buttons that allow a single item in a group to be selected.
 Spinner - Generated drop down list of defined items that allow one to be selected.
5. REQUIREMENTS MATRICIES
Mobile Client Requirements
MCR-01 MCR-02 MCR-03 MCR-04 MCR-05 MCR-06 MCR-07
User Interface X X X X X X
Application X X X
Device X
Server Requirements
(Web Client Requirements)
WCR-01 WCR-02 WCR-03 WCR-04
User Interface
(web client)
X X X
Server Manager
Database
Communication

18. Server Requirements
(Database Requirements)
SDR-01 SDR-02 SDR-03 SDR-04 SDR-05 SDR-06 SDR-07
User Interface
(web client)
Server Manager
Database X X X X X X
Communication
The current builds design supports the alerts features. However, the current implementation does not support that
feature due to time constraints.

19. 6. PLATFORM BASED DESIGN PATTERNS
iPHONE DEVELOPMENT STACK

20. iPHONE DEVELOPMENT:SDK
Four distinctive framework API’s
Cocoa Touch Layer
Media Layer
Core Services Layer
Core OS Layer
IDE
Xcode
Interface Builder
iPhone Simulator
On phone application development
iPHONE DEVELOPMENT: INTERFACE BUILDER / XCODE
Design for graphical, event-driven applications
Pallet of GUI widgets to use in your views.
Drag and drop widgets onto views
Links between objects can be created graphically
MVC pattern designed here
Graphically declare hooks into a program
Produces Nib Files
iPHONE DEVELOPMENT: DESIGN PATTERNS
Delegation
Don’t Subclass

21. Method calls are messages
[Object Message]
Both are dynamic
Managed Memory
Auto release
iPHONE DEVELOPMENT: APPLICATION LIFE CYCLE

22. iPHONE DEVELOPMENT: SECURITY MODEL
Originally all applications ran as root
Not a whole lot better now
All apps run as “mobile” user
Survived this year’s Pwn2Own
Security based on delivery mechanism
All applications must be delivered through the iTunes App Store
Requires apple approval and testing
$99 App Store
$299 Enterprise
Digitally signed by developer
iPHONE DEVELOPMENT: FUTURE
iPhone OS 3.0
In app purchases
Accessory APIs
Peer to Peer connectivity
New Game Kit
iPod library access
Embedded maps
Copy & Paste
Video

23. ANDROID DEVELOPMENT: THE STACK

24. ANDROID DEVELOPMENT: APPLICATION OVERVIEW
Packaged in one .apk file
Each application lives in its “own phone”
Its own Linux process
Its own JVM
Its own “file system”
Component based architecture
Activities
Services
Broadcast receivers
Content providers
Manifest file provides information about components
ANDROID DEVELOPMENT: ACTIVITIES
A visual interface for one task a user will attempt
Each activity gets a window to draw in.
Similar to a controller, takes view objects to display in the window
Views can nest within each other
Application can designate one activity as first

25. ANDROID DEVELOPMENT: SERVICES
Background process
No UI
Example: Media player
Can connect (bind) to a service
Currently running
Or by starting it
Once bound can communicate through predefined interface
Media Player: start, stop..
ANDROID DEVELOPMENT: BROADCAST RECEIVERS / CONTENT PROVIDERS
Broadcast Receivers
Event listeners
No UI
Can broadcast events
On event execute activity or display notification
Content Providers
Opens specific part of an applications data
Uses Content Resolvers
Not called directly
Returns a cursor object

26. ANDROID DEVELOPMENT: INTENTS
Contains the target object, the target method, and a URI of data to act on
Activates components
Aside from content providers
Intent can call startActivity, startService, sendBroadcast
ANDROID DEVELOPMENT: SECURITY
Sand Box
Without explicit permission can’t get outside
Each application can control what gets exposed
Permissions are declared at install time and can’t change
App signing
Digitally signed by developer

27. ANDROID DEVELOPMENT: ACTIVITY LIFE CYCLE

28. Board: +91-80-49531111 Private & Confidential www.sdlglobe.com
Contact Us
Our Location:
SmartDrive Labs Technologies India Pvt. Ltd.
# 521, 4thMain, 4th Block,
HBR Layout, Bangalore – 560 043
Karnataka, India.
Sales Enquires:
Mr. Mahesh K Parvathareddy
mahesh@sdlglobe.com
http://www.sdlglobe.com
Business Partnerships:
Ms. Vani Sathvik
vani@sdlglobe.com
http://www.sdlglobe.com/