NNEW MMEXICO SSTATEWIDE TTRAFFIC RRECORDS SSYSTEM
DDEPARTMENT OF IINFORMATION TTECHNOLOGY (D(DOIT)IT) IIMPACT DDOCUMENT EXECUTIVE SPONSORS
DEPARTMENT OF TRANSPORTATION
RHONDA G. FAUGHT, P.E., CABINET SECRETARY
PATRICIO GUERRERORTIZ, DEPUTY SECRETARY TRANSPORTATION PLANNING & DESIGN
MUFFET FOY CUDDY, DIVISION DIRECTOR TRANSPORTATION PLANNING DIVISION
ROBERT ASHMORE, CHIEF INFORMATION OFFICER
MICHAEL R. SANDOVAL, DIRECTOR TRANSPORTATION PLANNING DIVISION
BUSINESS OWNER
SANDRA MARTINEZ, PROGRAM DIRECTOR, TRAFFIC SAFETY BUREAU PROJECT MANAGER
VICTOR BERG, BENCY & ASSOCIATES
ORIGINAL PLAN DATE: FEBRUARY 25, 2008
REVISION DATE: FEBRUARY 25, 2008
REVISION: 1.0 NETWORK IMPACT The size of the all of the combined TRACS databases throughout the state will be approx 50 Gigabytes each year. Current actual size is projected at 25 GB with an extra 25 GB for growth, capacity planning, productivity improvements, more citations and the like. This number is based on 13304 traffic citations, 117 crashes and 493 DWI Citations in the DASO TRACS production database (312mb) and projected out to 1 million citations, 55,000 DWIs and 70,000 Crashes yearly, plus additional space added for growth or unexpected results. It’s roughly 75 times the current DASO Tracs Database size. 50 GB of data is a little less than 1 GB of network traffic per week and approx 142 MB per day of network traffic. Subsets of this data will be passed from the Distribution Server to Courts, MVD, DOT. The amount of data is TBD based on detail data requirements for each of these groups, but is projected to be 142 MB per day or less. Total network traffic for the Distribution Server, both input and output, is projected at 284 MB per day. There is no way to determine peak usage because 1) there is no tracking of this data currently at each LEA and 2) each LEA has major differences from municipality to municipality, size of police force, size of different shifts, etc. The STRS Report Server is a bit more difficult to project because of the additional data that may be capture and reported upon. A small list of data that may be captured by the report server is: LEA Traffic Data Court Dispositions/Abstracts MVD Driver History MVD Notice or Revocation Hearing Results DOT Roadway Data Division of Government Research Analysis
This information will be provided after project certification and project staffing. NETWORK DIAGRAM Firewall requirements is based on who owns the system and can be a dedicated commercial firewall/router or software installed on a PC behind a router. This also assumes an Intrusion detection system, either as part of the firewall or a separate system itself. A full description of this diagram is in the STRS architecture plan. The STRS data exchange will use a push technology to move data from Law Enforcement TRACS to the Distribution Server and from the Distribution Server to the receiving State Departments and Agencies. The officer uses TRACS on a laptop in the police car. All of the forms issued by the officer are stored on the laptop until transferred to the Law Enforcement TRACS Server. Each Law Enforcement Agency has a TRACS Server that stores all of the data from all of the officer’s laptops. The officer uses the end-shift keys on laptop’s keyboard to initiate a file transfer from the laptop to the TRACS Server. The transferred files contain all of the data accumulated during the officer’s shift. When the data is stored in the TRACS Server database, database triggers on the TRACS Server Database initiate the process of transferring data from the TRACS Server to the Distribution Server using Change Data Capture. Change Data Capture (CDC) is a mechanism for identifying new or changed data within a database and transfers only new or changed data from a source data store to a target data store. CDC immediately invokes the local Tracs Server Agent to initiate a secure connection to the Distribution Server Agent using OpenSSL technology. Data is transferred through this encrypted connection, which dynamically opens firewall ports and closes them upon completion. Both Source and Target Agents are deployed as web services. Each Law Enforcement TRACS Server has its own Agent which communicates with a single Distribution Server Agent. Once the data is successfully stored on the Distribution Server, CDC is initiated once again to transfer that data immediately to the Court Systems (AOC, Metropolitan Court or Municipal Courts), MVD, DOT or a Record Management System based on the type of data received from the TRACS Server.
REQUIREMENTS
HARDWARE Dual Application Servers, possibly Quad Application Servers, 2 for Windows and 2 for Linux Dual Database Servers Dual Report Servers Router/Firewall boxes (one for DMZ, one for Secured Network) OR Dual PCs (one for DMZ, one for Secured Network) with Firewall software installed. Possibly two more PCs for Intrusion Detection Systems, if Firewall doesn’t come with IDS built in.
SECURITY DMZ or more open port access required for Application/Report Servers Secured Network (very limited port access) for database servers Firewalls and Intrusion Detection System in place for DMZ and Secured Network SSL for encrypted data transfers OpenSSL for dynamic opening and closing of ports during data exchanges
SOFTWARE Oracle Application Express or equivalent TRACS Software Oracle Data Interchange or equivalent Crossflo Systems or equivalent for National Information Exchange Model Mapping Enterprise Service Bus Report/Business Intelligence Software
OPERATING SYSTEMS Oracle Application Server or Tomcat Windows, and possibly, Linux Java Development Kit OpenSSL
APPLICATION STRS Support Portal STRS Analytic and Report System Distribution Import and Export Web Services
HOSTING 24x7 clean power Generators and UPS Raised Floors
HOSTING OF SYSTEM Currently there is not a designated housing location for the STRS Distribution Center system. The most like candidates for housing the system are: 1) DoIT, 2) DOT, and 3) DPS. DOT will administer the system, wherever it is located. Since there is no system in production yet, there are no migration requirements. The location for housing the system will be discussed in meeting with DoIT.
DOIT COLLABORATION Department of Transportation CIO has requested a technical discussion with DoIT to collaborate the function of STRS Distribution Center and the potential impact on DoIT. Meeting date and time for this meeting is currently pending on DoIT schedule. ARCHITECTURE DIAGRAM
Enterprise Service Bus
Tesuque APD DPS DASO RRDPS SFPD Tribal Police
TRACS Change Data Capture
Export Web Services
NIEMS 2.0 Compliant XML (Crash, DWI, Citations)
Import Web Services
Statewide Distribution Server STRS Support Intergration STRS Distribution Database Database
Export Web Services
NIEMS 2.0 Compliant XML (Crash, DWI, Citations)
Import Web Services
Contested Citations, DWI All (based on RMS) PA, DWI Crash
Metro AOC Muni RMS MVD DOT
Export Web Services
NIEMS 2.0 Compliant XML (Crash, DWI, Citations, Abstracts, Dispositions, Drivers History)
Import Web Services
Statewide Analytic & Reporting System
STRS Data Warehouse All the traffic forms issued to the defendant at a single point of time are linked together as a single incident, using dispatch (or case) number. If subsequent investigation leads to further issuances to the same defender, these are tracked using a new dispatch (or case) number. Citations, DWI Citations and Criminal Complaints are sent to the Court System. Crash Reports are sent to the Department of Transportation. Penalty Assessments, Warnings and Notice of Revocation are sent to the Motor Vehicle Department. The Distribution Server Database maintains a copy of ALL data process by the server. The purpose of the data is to reconcile Law Enforcement with Courts, DOT and MVD and possibly to be used as a data backup in the event of a disaster. The STRS Support Portal maintains TRACS Codes and Translations used to integration TRACS with the State Departments and Agencies. The STRS Analytic and Reporting System maintain aggregated data & dimensions for TRACS Data, DOT Data plus other potential data providers. All data exchanges use a Service Oriented Architecture (SOA) using the National Information Exchange Model XML standards.
BACKUP STRATEGY Full Backups will occur weekly. Daily backups will occur incrementally. Weekly and daily backups will be maintained on disk, with a retention policy of 3 months In addition, once a month, data is copied to media and moved offsite. Oracle Recovery Manager will be used in conjunction with Oracle Archiving to enable full recovery of data in the event of a failure, corruption or disaster.
DISASTER RECOVERY Monthly backups to media, moved off-site, will be used to recover in the event of a major catastrophe. All software, operating systems and data will be copied to media.
BUSINESS CONTINUITY In the event of a disaster to the Distribution Server, the LEA’s will revert to paper processing and send citations, crashes and DWIs via US Mail to their respective destinations. Business Operations will not be impeded.
OPERATIONAL RECOVERY PLANNING Depending on extent of disaster, offsite media will be used as the base for recovery, with an attempt to recover as much as data as possible up to the point of failure. Once the system is restored, processes will be restarted. This will send LEA data built up during system downtime and processed in paper format, plus any new data, to the Distribution Server and the Distribution Server will send the data to Courts, MVD and DOT. All citations, crashes and DWI’s already processed as paper during system downtime will be rejected by the target systems. New data will be processed electronically as normal. In the event of a complete failure, without adequate data recovery, full data synchronization will occur between LEA and Distribution Server so that ALL data, including all history, will be transferred from each LEA to the Distribution Server, bringing the Server back up to date. In addition, ALL data will be passed to Courts, MVD and DOT with duplicates being rejected. This is a worst case scenario.