1. Automated Police Reports System City of Pittsburgh March 5, 2007 Presented to

2. Introduction / Overview Objective - Constraints Technology Project Description Demo Final Thoughts Questions & Answers Agenda

3. 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

4. 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

5. 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

6. Process Flow

7. Applications

8. 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

9. APRS Objective Build new system to streamline process Remove duplication Improve accuracy Report generation from field Eliminate repetitive tasks

10. Phased Approach Phase I APRS Desktop – Oracle Phase II APRS Mobile – SQL Server Remote Data Broker

11. Phased Approach

12. 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

13. Ideas?

14. 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

15. Message Queues Example Demo

16. Project Goals / Description Goal Remove the need for a constant Oracle connection Provide the ability for the application to receive updates Description Develop Remote Data Broker for Oracle and SQL Server Provide the ability for the application to receive updates

17. APRS Remote Data Broker Office (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

18. Office (Server) Server Send Message API

19. Office (Server) Server Web Service (dequeue message)

20. Officer Laptop/MDT (Client) Client Dispatcher Daemon

21. Client Flow Dispatch Daemon & Sending Messages

22. Office (Server) Server Dispatcher Daemon

23. APRS Demo

24. Final Thoughts

25. Questions & Answers Jamie Schultz jschultz@bthreesolutions.com www.bthreesolutions.com