automated police reports system city of pittsburgh march 5, 2007 presented to
TRANSCRIPT
Automated PoliceReports System
City of Pittsburgh
March 5, 2007
Presented to
• Introduction / Overview
• Objective - Constraints
• Technology
• Project Description
• Demo
• Final Thoughts
• Questions & Answers
Agenda
Introduction
• Automated Police Reports System eReporting system of all police paper work
• Currently deploying into Pittsburgh Police
• Mobile and Desktop versions Oracle & MSDE SQL Server
• Several technical and logistical obstacles Utilize off the shelve or develop new components
Overview
• Currently utilizing paper reports some automation via Word templates
• Pittsburgh needed an automated system Eliminate redundant paper work
• 3.0 report (incident) 2.0 report (arrest)• Share similar data (i.e. victim, actor)
More efficient • Officers spend large potion of shift paper work
Overview
• City of Pittsburgh Police Approximately 900 officers Approximately 300 cars
• CRIMES: Record Management System Prior to APRS; utilized paper reporting system Scanned reports into imaging system
Immediate availability for Command Staff Records room data entry of reports
Process Flow
Police Officer
Zone Clerk
Report
`
Imaging SQL Server
Zone Reports
Records Clerk
`
CRIMESOracle
All Reports
Other Zone Reports
Zones Scan reportsA set of index fields are keyed into system for queried retrieval
Applications
Imaging SQL Server
CRIMESOracle
Investigators
Command Staff
Police Officers
Image Retrieval
Mapping Applications
IMS / MO Query Applications
CRIMES
Report Forms• Investigative 3.0 Form (also called the Incident Report)• Offense 2.0 Form• Supplemental Form• Arrest Form• Warrant Arrest Supplement Field• Contact/Search/Seizure Form• Subject Resistance Form• Firearms• Weapon Discharge Form• Miranda Rights Form• Juvenile Referral Form• Missing Person Form• Use of Canine Form
APRS Objective
• Build new system to streamline process
• Remove duplication
• Improve accuracy
• Report generation from field
• Eliminate repetitive tasks
Phased Approach
• Phase I
APRS Desktop – Oracle
• Phase II
APRS Mobile – SQL Server
Remote Data Broker
Phased Approach
APRS Desktop Application
APRS MobileApplication
Remote Data Broker
Project Constraints
• Run on an air card not broad band network speeds
• Deal with hot spot / null zones must not require officer to wait for connection
• 300 cars / minimal access to Toughboxes upgrades and support
• Dynamic LOVs
Ideas?
Message Queues• A messaging protocol that allows applications running on disparate
servers to communicate in a failsafe manner. • A queue is a temporary storage location from which messages can
be sent• Enables communication across heterogeneous networks and
between computers which may not always be connected
Message Queues
Example Demo
Project Goals / Description
GoalRemove the need for a constant Oracle connection
Provide the ability for the application to receive updates
DescriptionDevelop Remote Data Broker for Oracle and SQL Server
Provide the ability for the application to receive updates
APRS Remote Data BrokerOffice (Server)
– Server Send Message API. – Server Web Service (dequeue message)– Server Dispatcher Daemon.– Server Message Processing DLLs.– Server-Side Queue Message Database.– Server Maintenance Tools.
Officer Laptop/MDT (Client) – Client Dispatcher Daemon– Client Send Message API.– Client Message Processing DLLs.– Client-Side Queue Message Database
Office (Server) Server Send Message API
QueueMDT 1
QueueMDT 2
QueueMDT 3
APRS Desktop Application
(Advance Queue)RDB API calls enqueues messages into queues
Office (Server) Server Web Service (dequeue message)
WEB Service
QueueMDT 1
QueueMDT 2
QueueMDT 3
(Advance Queue)
Web Service is calleddequeue (consume) message
APRS Client ApplicationClient
Dispatcher Daemon
Officer Laptop/MDT (Client) Client Dispatcher Daemon
Start Message Processing Dispatcher
Determine processing DLL based on Type
Pass Message to appropriate DLL for processing
DLL (1)
DLL (2)
DLL (n)
Instantiate initial objectThen call process function of DLL
DLL Catalog
Client Flow
WEB Service
Outgoing Queue
Incoming Queue
Outgoing queue monitored
asynchronously
User’s action will cause a message to be pushed to a local
outgoing queue
Advanced Queue
Client Dispatcher Daemon
Dispatch Daemon
&
Sending Messages
Office (Server) Server Dispatcher Daemon
Start Message Processing Dispatcher
Determine processing DLL based on Type
Pass Message to appropriate DLL for processing
DLL (1)
DLL (2)
DLL (n)
Instantiate initial objectThen call process function of DLL
DLL Catalog
APRS
Demo
Final Thoughts
