Loading...
The URL can be used to link to this page
Your browser does not support the video tag.
Home
My WebLink
About
Res 016 - Sole Source - 911 CAD Interface
Deschutes County Board of Commissioners 1300 NW Wall St., Suite 200, Bend, OR 97701-1960 (541) 388-6570 - Fax (541) 385-3202 - www.deschutes.org AGENDA REQUEST & STAFF REPORT For Board Business Meeting of May 5, 2010 Please see directions for completing this document on the next page. DATE: 4/27/2010 FROM: Shawn Pray 9-1-1 (541) 388-0185 x2313 TITLE OF AGENDA ITEM: Consideration of Signature of Resolution 2010-016, Declaring Findings in Support of Sole Source Procurement for the Deschutes County 9-1-1 CAD -to -CAD Interface and Interoperability Project. PUBLIC HEARING ON THIS DATE? NO BACKGROUND AND POLICY IMPLICATIONS: The findings support sole source procurement for the CAD -to -CAD Interface and Interoperability Project to connect five regional 9-1-1 centers' computer-aided dispatch (CAD) systems together. The development of the required EIS, Inc. CAD interface will improve communications and interoperability among the 9-1-1 centers. FISCAL IMPLICATIONS: The cost of the agreement is $316,650.00. $314,580.00 will be paid using grant funds Deschutes County 9-1-1 received for the regional project. The remaining $2,070.00 will paid by the five 9-1-1 centers benefiting from the project. Deschutes County 9-1-1's CAD interface development and implementation costs will be borne by a partnering ODOT project, when completed will connect Deschutes County 9-1-1, the other five 9-1-1 centers referenced in the CAD -to -CAD Interface and Interoperability Project, and many other 9-1-1 centers. RECOMMENDATION & ACTION REQUESTED: Adoption of sole source procurement findings for the CAD -to -CAD Interface and Interoperability Project as required under ORS 279B.075 and signature of Resolution 2010-016. ATTENDANCE: Shawn Pray DISTRIBUTION OF DOCUMENTS: Shawn Pray, 9-1-1 (541) 388-0185 x2313 DESCHUTES COUNTY DOCUMENT SUMMARY (NOTE: This form is required to be submitted with ALL contracts and other agreements, regardless of whether the document is to be on a Board agenda or can be signed by the County Administrator or Department Director. If the document is to be on a Board agenda, the Agenda Request Form is also required. If this form is not included with the document, the document will be returned to the Department. Please submit documents to the Board Secretary for tracking purposes, and not directly to Legal Counsel, the County Administrator or the Commissioners. In addition to submitting this form with your documents, please submit this form electronically to the Board Secretary.) Date: 4/27/2010 Please complete all sections above the Official Review line. Department: Contractor/Supplier/Consultant Name: Contractor Contact: 4500 Thomas King 9-1-1 Executive Information Services, Inc. Contractor Phone #: (352) 236 - Type of Document: Resolution containing a contract for goods and services to be funded by grant monies previously approved by the Board of Commissioners. Goods and/or Services: The following goods and services will be provided by EIS, Inc.: CAD INTERFACE DEVELOPMENT: Custom development of the interface and exchange component to support Oregon specifications, as proposed in Schedule C and in accordance with the specifications in Schedule D, for CAD -to -CAD and CAD -to -State switch integration, modifications to Base PS.NET/CAD workstation to support the interface, and development of Gateway service application. SERVER HARDWARE: M2 Messaging Server consisting of: Quad Core AMD Opteron 2350, 2.0 GHz, 1 GHz HyperTransport; 4GB DDR, 667MHz, 4x1 GB Single Ranked DIMMs, SAS 6iR SAS Internal RAID adapter PCI -Express; Add-in SAS 6/iR SATA/SAS Controller RAID 1, Support 2 Cabled Hard Drives; (2) 146GB 15k RPM Serial -Attach SCSI 3Gbps 3.5 -in Cabled Hard Drives; Intel PRO 1000PT 1GbE Dual Port NIC, PCIe- 4, 16x DVD -ROM Drive, Internal, SATA; Electronic Documentation and OpenManage DVD Kit, Windows Server 2008, Standard Edition with 5 CALs, 3Yr Basic Hardware Warranty Repair: 5x10 NW -Only, 5x10 NBD Onsite. CAD MAPPING SOFTWARE: EIS, Inc. mapping software compatible with existing EIS, Inc. CAD software. CAD M2 ADAPTER: EIS, Inc. CAD adapter required to connect current on -premise EIS, Inc. CAD software to the server hardware described above. Background & History: Deschutes County 9-1-1 is seeking sole source procurement for the CAD -to -CAD Interface and Interoperability Project to connect five regional 9-1-1 centers' computer-aided dispatch (CAD) systems together through the attached resolution. The development of the required EIS, Inc. CAD interface will improve communications and interoperability among the 9-1-1 centers. Agreement Starting Date: 5/5/2010 Ending Date: Annual Value or Total Payment: $316,650 05/31/2011 4/27/2010 Z Insurance Certificate Received (check box) Insurance Expiration Date: 06/1/2010 Check all that apply: n RFP, Solicitation or Bid Process (l Informal quotes (<$150K) Exempt from RFP, Solicitation or Bid Process (specify — see DCC §2.37) Funding Source: (Included in current budget? ® Yes No If No, has budget amendment been submitted? n Yes n No Is this a Grant Agreement providing revenue to the County? J 1 Yes I< No Special conditions attached to this grant: This is a resolution containing a contract to utilize grant funds previously by the Board of Commissioners. Deadlines for reporting to the grantor: Addressed when grant was previously approved but for the contract with EIS, final reimbursement requests need to be submitted by May 31, 2011. If a new FTE will be hired with grant funds, confirm that Personnel has been notified that it is a grant -funded position so that this will be noted in the offer letter: Yes n No Contact information for the person responsible for grant compliance: Name: Shawn Pray Phone #: (541) 388-0185 x2313 Departmental Contact and Title: Phone #: (541) 388-0185 x2313 Department Director Approval: Shawn Pray, Supervisor Distribution of Document: Please send one original and one copy of the resolution, contract, and attachments to Shawn Pray at 9-1-1. Official Review: County Signature Required (check one): ❑ BOCC ❑ Department Director (if <$25K) ❑ Administrator (if >$25K but <$150K; if >$150K, BOCC Order No. Legal Review Date 4/27/2010 REVIEWED LEGAL COUNSEL For Recording Stamp Only BEFORE THE BOARD OF COUNTY COMMISSIONERS OF DESCHUTES COUNTY, OREGON A Resolution Declaring a Sole Source Procurement Approval for CAD -to -CAD Interface and Interoperability Project * * RESOLUTION NO. 2010-016 WHEREAS, ORS 279A.015 generally requires that all contracts for public improvements be let to the lowest possible bidder; and WHEREAS, Deschutes County has adopted the Model Rules of Public Contract Procedure, OAR 137, divisions 46-49 in Deschutes County Code 2.36.020; and WHEREAS, Deschutes County Code 2.36.030 designates the Board of County Commissioners ("Board") to act as the local contract review board; and WHEREAS, ORS 279B.075 and OAR 137.047-0275 authorize the Board, acting as the local review board, to award a contract for goods or services without competition when the local contract review board determines in writing that the goods or services, or class of goods or services, are available from only one source; and WHEREAS, based on findings in Exhibit A, attached and incorporated by reference, the Board finds that the CAD -to -CAD Interface and Interoperability upgrade is available only from Executive Information Services, Inc. ("EIS"); and WHEREAS, pursuant to OAR 137-047-0275, public notice of intent to award sole source contract was published in the Bulletin on March 3, 2010 and no protests have been received; and WHEREAS, because only one source is available to provide the necessary software, equipment and services, the Board intends to award the contract attached as Exhibit B to EIS, Inc.; therefore BE IT RESOLVED BY THE BOARD OF COUNTY COMMISSIONERS OF DESCHUTES COUNTY, OREGON, acting in its capacity as the local review board, as follows: Section 1. The Board adopts the findings in Exhibit A, attached and incorporated by reference. PAGE 1 OF 2 — RESOLUTION NO. 2010-016 Section 2. On May 5, 2010,.at 10:00 a.m., or shortly thereafter, depending on the public meeting agenda, the Board shall award and execute the contract with EIS, Inc., attached as Exhibit B and incorporated by reference. Dated this of , 20 BOARD OF COUNTY COMMISSIONERS OF DESCHUTES COUNTY, OREGON ATTEST: DENNIS R. LUKE, Chair ALAN UNGER, Vice Chair Recording Secretary TAMMY BANEY, Commissioner PAGE 2 OF 2 — RESOLUTION NO. 2010-016 EXHIBIT A to Resolution 2010-016 DESCHUTES COUNTY BOARD OF COMMISSIONERS Bend, Oregon DATE: April 27, 2010 TO: The Commissioners FROM: Shawn Pray, Supervisor and Andy Jordan, Interim Director SUBJECT: Findings in Support of a Sole -Source Procurement for CAD -to -CAD Interface and Interoperability Project. A. BACKGROUND The findings herein support authorizing the Deschutes County Board of Commissioners ("Board"), acting as the Local Contract Review Board, to allow a sole source procurement for the Deschutes County 9-1-1 CAD -to -CAD Interface and Interoperability Project, consisting of purchasing equipment, software and installation, from EIS, Inc. This project consists of integrating six (6) public service answering point ("PSAP") computer-aided dispatch ("CAD") systems over eight (8) Oregon counties, thereby improving emergency communications regionally. B. STATUTORY REQUIREMENTS ORS 279B.075 provides that sole -source procurements are exempt from the competitive bidding process when a person designated in writing by the director, board or state contracting agency with procurement authority under ORS 279A.050, determines in writing that the goods or services, or class of goods or services, are available from only one source and to negotiate and sign an agreement. The determination of a sole source must be based on written findings that may include: (a) That the efficient utilization of existing goods requires the acquisition of compatible goods or services; (b) That the goods or services required for the exchange of software or data with other public or private agencies are available from only one source; (c) That the goods or services are for use in a pilot or an experimental project; or available from only one source To the extent reasonably practical, the contracting agency shall negotiate with the sole source to obtain contract terms advantageous to the contracting agency. OAR 137-047-0275 requires at least seven (7) days public notice before award of the contract. The attached Exhibit A-1, Notice of Intent to Award Sole Source Contract for CAD -to -CAD Interface and Interoperability Project was published in The Bulleting on March 3, 2010. C. FINDINGS The following findings are in support of the exemption and in compliance with the statutory requirements described above. Deschutes County 9-1-1 currently owns and operates a Hitech Systems, Inc. CAD system. This system provides call and unit tracking capabilities for Deschutes County law enforcement, fire/EMS units and both 9-1-1 and non -emergency calls for service. The CAD -to -CAD Interface and Interoperability Project will connect together the five (5) PSAPs surrounding Deschutes County, who use EIS, Inc. CAD systems, allowing Deschutes County 9-1-1 to utilize a Hitech Systems -to -EIS interface, provided with funding from the Oregon Department of Transportation, thereby improving public safety communication among six (6) PSAPs and eight (8) Oregon counties. The infrastructure equipment and CAD software are proprietary to EIS, Inc. The CAD system in question includes EIS CAD M2 adapters, EIS -modified server equipment, EIS CAD mapping, and EIS CAD software. No other CAD vendor can provide compatible equipment or software for this system. Exhibit A-1 to Resolution 2010-016 NOTICE OF INTENT TO AWARD SOLE SOURCE CONTRACT For CAD -to -CAD Interface and Interoperability Project The Board of County Commissioners for Deschutes County, Oregon, will consider whether to award Executive Information Services, Inc. (EIS) the contract for the above - referenced project. The goods and services to be acquired are: EIS CAD M2 adapter, server equipment, EIS CAD mapping, EIS CAD interface development, licensing and installation. The Board of County Commissioners will decide whether the requirements to award the contract to EIS, Inc. based on sole source procurement are met. This notice is based upon Oregon Administrative Rule (OAR) 137-047-0275 Affected or aggrieved persons may protest the County's intent to award the contract as sole source procurement to the Board of County Commissioners of Deschutes County, Oregon at 1300 NW Wall St. Suite 200, Bend, OR 97701 within seven (7) days after the first publication date of this Notice of Intent to Award Sole Source Contract. The seven (7) day protest period will expire at 5:00 PM on Tuesday, March 9, 2010. Any protest must be in writing and must include: a detailed statement of the legal and factual grounds for the protest; a description of the resulting harm to the Affected Person; and the relief requested. If no timely protest is filed, this Notice of Intent to Award Contract becomes an Award of Contract without further action by the Board. Publication date: March 3, 2010 EXHIBIT B to Resolution 2010-016 EIS Contract DESCHUTES COUNTY 9-1-1 SERVICE DISTRICT CONTRACT FOR THE PURCHASE OF GOODS ("Contract") This Contract is between Deschutes County 9-1-1 Service District ("District") and Executive Information Services, a Nevada corporation ("EIS" or "Contractor"). This Contract is effective on the date it has been signed by all parties and all required District approvals have been obtained, including the approval of the Oregon Department of Emergency Management. This Contract expires on May 31, 2011. The parties may extend the term of this Contract. Contractor agrees to sell, and the District agrees to purchase, Goods and Services for the benefit of the District subject to the following terms and conditions: RECITAL This Contract is for the purchase and sale of the following: Computer -Aided Dispatch ("CAD") interface development, CAD software, CAD server hardware, installation and licensing. 1. DEFINITIONS. A. "Contractor Intellectual Property" means any intellectual property owned by Contractor and developed independently from Services. B. "Goods" means the goods specified in section 2. C. "IRS" means the Internal Revenue Service. D. "Open Source Elements" means any Work Product subject to any open source initiative certified license, including Work Product based upon any open source initiative certified licensed work. E. "Services" means the services, if any, that are incidental to the purchase of Goods and that Contractor is required to perform under section 2. F. "Specifications" means the specific attributes of Goods and Services described in section 3. G. "Third Party Intellectual Property" means any intellectual property owned by parties other than the District or Contractor. H. "Work Product" means all Goods and Services Contractor delivers or is required to deliver to the District pursuant to this Contract. I. "Receiving Agency" means any one of the five public safety answering points ("PSAPs") listed in Scheudle A. The parties hereby agree as follows: 11. Services and Standards of Performance EIS shall provide to the District all of the Services and deliverables described in and in the manner required by all of the following documents: Deschutes_County_9-1-1 _Contract_2Apr 10 Page 1 of 16 This Agreement Schedule A: EIS Pricing Proposal QT -442/3 REV 1, dated September 11, 2009 and Extension Schedule B: EIS Project Payment Terms Schedule C: PS.NET/M2 PDCC ODOT Integration CAD to CAD (EIS Project Proposal and Workplan) Schedule D: ODOT to OSP Connection Specification Schedule E: FY 2008 Homeland Security Grant Program (Application Instructions and Grant Guidance) All of the above are attached to and incorporated as part of this Contract for all purposes. In the case of conflicts between any of the provisions contained within any of the referenced exhibits/schedules, the following shall control in this order of priority: 1. Schedule E: FY 2008 Homeland Security Grant Program (Application Instructions and Grant Guidance) 2. This Agreement 3. Schedule A: EIS Pricing Proposal QT -442/3 REV 1, dated September 11, 2009 and Extension 4. Schedule B: EIS Project Payment Terms 5. Schedule C: EIS Project Proposal and Workplan 6. Schedule D: ODOT to OSP Connection Specification 2. REQUIRED GOODS, SERVICES, PRICING AND DELIVERY SCHEDULE. Contractor shall deliver to the District the following Goods and Services for the prices specified in this section 2. A. GOODS. i. Description and Quantity: CAD Interface Development and Documentation Price: $62,000 ii. Description and Quantity: As described in Schedule A, equipment for five (5) PSAPs Price: $188,250 ii. Description and Quantity: As described in Schedule A, two years of software license and support for five (5) PSAPs beginning one (1) calendar year after system testing and acceptance, in accordance with section 4.D. Price: $12,000 Deschutes_County_9-1- l_Contract_2Apr 10 Page 2 of 16 B. SERVICES. INSTALLATION: Contractor shall provide technical services and on-site installation to effect the CAD upgrade and deploy the developed CAD -to -CAD interface between the five (5) PSAPs in the EIS Pricing Proposal, attached Schedule A. TRAINING: Contractor shall provide training through a qualified authorized service representative of the manufacturer and shall train to the District's satisfaction the individuals identified by the District in the operation, adjustment, repair and maintenance of Goods delivered under this Contract. Contractor shall perform Services for a fixed price of $54,400. C. DELIVERY. i. Contractor shall deliver Goods to the District and shall perform Services, if any, at the addresses specified by the District in writing. ii. Contractor shall deliver Goods F.O.B. place of destination. Contractor shall retain the risk of loss of Goods until the District accepts Goods in accordance with section 4.D. iii. Contractor shall deliver Goods in accordance with the delivery schedule mutually agreed upon between Contractor, District and receiving agency in writing. iv. Contractor shall complete all Services. no later than May 31, 2011. If Contractor is unable to complete all services by May 31, 2011, Contractor will notify the District as soon as possible and negotiate a reasonable completion date for any remaining services. The District has funding restrictions applicable to the project described in the Funding Duration section of Schedule E. v. TRAINING DELIVERY SCHEDULE: Contractor, District and receiving agency will negotiate a delivery schedule for training that will specify the training date, time and location, while adhering to section iv above. 3. SPECIFICATIONS. Contractor shall deliver all Goods and Services specified in section 2 in accordance with this section 3. Contractor's failure to deliver Goods and Services in accordance with the provisions of this Contract is a material breach of this Contract. A. GENERAL PROVISIONS. i. NON-COMPLIANCE. If any Goods or component parts are recalled by a regulatory body or the manufacturer, or discovered by Contractor not to comply with applicable regulatory standards or the Specifications, Contractor shall immediately notify the District of the recall or non-compliance, and shall provide copies of the recall notice or notice of non-compliance, as applicable, and all other supporting documentation for the recall or non-compliance determination. The District may elect to (a) reject Goods in whole or in part, or (b) revoke its acceptance of Goods in whole or in part. If the District rejects Goods or revokes its acceptance of Goods, Contractor shall remove the particular Goods from the District's possession as provided in section 4.D.iv at no cost to the District and shall reimburse the District for all payments made for those Goods. Deschutes_County_9-1-1_Contract 2Apr10 Page 3 of 16 ii. STANDARD COMPONENTS. Unless specified otherwise in this section 3, Specifications, Contractor shall provide Goods with all components and accessories that the manufacturer lists as "standard" for Goods. iii. NECESSARY COMPONENTS. Unless specified otherwise in this section 3, Specifications, Contractor shall include all components, hardware and parts necessary for complete and proper assembly, installation and operation of Goods. iv. NEW AND UNUSED GOODS. Unless specified otherwise in this section 3, Specifications, Contractor shall deliver Goods that are new, unused and produced from current production inventory. Contractor shall provide Goods manufactured from only those components that the manufacturer offers in the manufacturer's current parts catalogue for Goods. B. DETAILED SPECIFICATIONS. CAD INTERFACE DEVELOPMENT: Custom development of the interface and exchange component to support Oregon specifications, as proposed in Schedule C and in accordance with the specifications in Schedule D, for CAD -to -CAD and CAD -to -State switch integration, modifications to Base PS.NET/CAD workstation to support the interface, and development of Gateway service application. SERVER HARDWARE: M2 Messaging Server consisting of: Quad Core AMD Opteron 2350, 2.0 GHz, 1 GHz HyperTransport; 4GB DDR, 667MHz, 4x1GB Single Ranked DIMMs, SAS 6iR SAS Internal RAID adapter PCI -Express; Add-in SAS 6/iR SATA/SAS Controller RAID 1, Support 2 Cabled Hard Drives; (2) 146GB 15k RPM Serial -Attach SCSI 3Gbps 3.5 -in Cabled Hard Drives; Intel PRO 1000PT 1GbE Dual Port NIC, PCIe-4, 16x DVD -ROM Drive, Internal, SATA; Electronic Documentation and OpenManage DVD Kit, Windows Server 2008, Standard Edition with 5 CALs, 3Yr Basic Hardware Warranty Repair: 5x10 NW -Only, 5x10 NBD Onsite. CAD MAPPING SOFTWARE: EIS, Inc. mapping software compatible with existing EIS, Inc. CAD software. CAD M2 ADAPTER: EIS, Inc. CAD adapter required to connect current on -premise EIS, Inc. CAD software to the server hardware described above. 4. TERMS AND CONDITIONS. A. PAYMENT. i. The District's Payment. The District shall pay Contractor for Goods delivered and Services performed at the prices and rates specified in section 2 and Schedule A. Contractor shall look solely to the District for payment of all amounts the District owes to Contractor. Contractor shall not be compensated by any department of the District other than the District for Goods delivered or Services performed. ii. If Contractor is a nonresident alien as defined in 26 USC § 7701(b)(1)(B), then Contractor shall, upon execution of this Contract, deliver to the District a completed and signed W-8 form, 8233 form, or W-9 form, as applicable, from the IRS, as evidence that the District is not required by 26 USC 1441 to withhold part of Contractor's payment. Such forms are currently available at http://www.irs.gov. The District may withhold payments to Contractor pending the District's receipt from Contractor of the applicable, completed and signed form. If the District does not receive the applicable, completed and signed form from Contractor, or if the IRS provides notice to the District that Contractor's information on the form provided is incorrect, the District will withhold as federal income tax 30% of all amounts the District owes to Contractor under this Contract. Deschutes_County_9-1-1 _Contract_2Apr 10 Page 4of16 iii. Funds Available and Authorized; Payments. Contractor understands and agrees that the District's payment of amounts under this Contract is contingent on the District receiving funding, appropriations, limitations, allotments or other expenditure authority at levels sufficient to allow the District, in the exercise of its reasonable administrative discretion, to make payments under this Contract. B. INVOICES. i. Contractor shall send invoices to the District no more often than monthly after the District's acceptance in accordance with section 4.D of Goods delivered under this Contract. Contractor shall send invoices to the District for completed Services no more often than monthly. ii. Contractor shall send all invoices to the District mailing address specified in section 7 or to any other address that the District may indicate in writing to Contractor. Contractor shall include in each invoice: a. The Solicitation number if any, the Contract number if any; b. The quantity of Goods ordered, the quantity of Goods delivered, the date Goods were delivered, the price per unit, if applicable; c. A detailed description of Services performed, including the name or names of the individuals who performed Services and prepared the deliverables to which the invoice applies, the dates Services were performed, all deliverables delivered during the period of the invoices, the rate or rates for Services performed, and the total cost of Services d. Itemization and explanation of all expenses for which Contractor claims reimbursement authorized under this Contract; and e. The total amount due, and the payment address. C. MOST FAVORABLE PRICES AND TERMS. Contractor represents and warrants that all prices, terms and benefits offered by Contractor under this Contract are equal to or better than the equivalent prices, terms and benefits being offered by Contractor to any other state or local governmental entity or commercial customer. i. If during the term of this Contract Contractor enters any contract, agreement or arrangement that provides lower prices, more favorable terms or greater benefits to any other state or local governmental entity or commercial customer, Contractor shall provide the same price or prices, terms and benefits to the District. The prices, terms and benefits shall be effective as of the date Contractor made the more favorable terms or greater benefits available to any other state or local governmental entity or commercial customer. This provision applies to comparable goods and services and to purchase volumes by the District that are not less than the purchase volumes of the state or local governmental entity or commercial customer that has received the lower prices, greater benefits or more favorable terms. ii. Section 4.C.i does not apply to Contractor's donations of comparable goods and services to charitable, nonprofit or governmental entities if the donations are recognized as donations and are deductible under the federal Internal Revenue Code. These donations are not considered contracts, agreements or arrangements with other state or local governmental entities or commercial customers for purposes of section 4.C.i. D. SYSTEM TESTING AND ACCEPTANCE: The Contractor shall perform configuration and connectivity tests at each deployment site listed in attached Schedule A, EIS Pricing Proposal. The District's acceptance of the EIS CAD-to- Deschutes_County_9-1-1_Contract_2Apr 10 Page 5 of 16 CAD Integration solution shall be based on successful completion of, and the District's approval of, the configuration and connectivity tests. E. OTHER REPRESENTATIONS AND WARRANTIES. All express and implied warranties that are applicable to goods under ORS Chapter 72 apply to Goods delivered under this Contract. Contractor represents and further warrants that: i. Contractor has the authority to enter into and perform in accordance with this Contract, and that this Contract, when executed and delivered, is a valid and binding obligation of Contractor that is enforceable in accordance with its terms; ii. All Goods delivered to the District are new, unused, current production models and are free from defects in materials, design and manufacture for one (1) year following completion of configuration and connectivity testing ("Warranty Period"). Contractor further represents and warrants that all Goods meet or exceed all Specifications; iii. All Goods delivered shall comply with all applicable federal health and safety standards. iv. Contractor has the skill and knowledge possessed by well-informed members of its industry, trade or profession and Contractor will apply that skill and knowledge with care and diligence and perform Services in a timely, professional and workmanlike manner in accordance with standards applicable to Contractor's industry, trade or profession; and v. Contractor is, and shall be at all times during the term of this Contract, qualified, professionally competent and duly licensed to perform Services. The warranties specified in this section 4.E are in addition to, and not in lieu of, any other warranties provided in this Contract. All warranties are cumulative and shall be interpreted broadly to give the District the greatest warranty protection available. F. MANUFACTURER WARRANTIES. At no charge to the District, Contractor shall transfer or cause the transfer of all manufacturers' warranties for Goods and component parts, if any, to the District for the District's benefit when Contractor delivers Goods to the District. If a conflict or inconsistency exists between a manufacturer's warranty and Contractor's warranty, the warranty that provides the greatest benefit and protection to State shall prevail. G. COMPLIANCE WITH APPLICABLE LAWS AND STANDARDS. i. Contractor shall comply with all federal, state and local laws, regulations, and ordinances applicable to this Contract or to Contractor's obligations under this Contract, as they may be adopted or amended from time to time. ii. The District's performance under this Contract is conditioned upon Contractor's compliance with the obligations intended for contractors under ORS 279B.220, 279B.225 (if applicable to this Contract), 279B.230 and 2796.235 (if applicable to this Contract), which are incorporated into this Contract by reference. Contractor shall, to the maximum extent economically feasible in the performance of this Contract, use recycled paper (as defined in ORS 279A.010(1)(gg)), recycled PETE products (as defined in ORS 279A.010(1)(hh)), and other recycled plastic resin products and recycled products (as "recycled product" is defined in ORS 279A.010(1)(ii)). H. MATERIAL SAFETY DATA SHEET. At the time Contractor delivers Goods to the District, Contractor shall provide to the District a "Material Safety Data Sheet" as defined by (OSHA) for any Goods delivered which may release or Deschutes_County_9-1-1_Contract_2Apr 10 Page 6 of 16 otherwise cause exposure to a hazardous chemical substance under normal conditions of use. Contractor shall properly label, tag or mark those Goods. I. RESERVED J. FORCE MAJEURE. Neither the District nor Contractor shall be responsible for any failure to perform or for any delay in the performance of any obligation under this Contract caused by fire, riot, acts of God, terrorism, war, or any other cause which is beyond the delaying or breaching entity's reasonable control. Contractor shall make all reasonable efforts to eliminate the cause of Contractor's delay or breach and shall, upon elimination of the cause, continue performing under this Contract. The District may terminate this Contract upon written notice to Contractor after reasonably determining that this delay or breach could likely prevent successful performance of this Contract. K. INSURANCE. Contractor shall obtain the insurance required under section 5 prior to performing under this Contract and shall maintain the required insurance throughout this duration of this Contract and all Warranty Periods. L. INDEPENDENT CONTRACTOR STATUS; RESPONSIBILITY FOR TAXES AND WITHHOLDING. i. Contractor shall perform all Services as an independent contractor. Although the District may (a) determine and modify the delivery schedule for Goods to be delivered and Services to be performed and (b) evaluate the quality of the completed performance, the District cannot and will not control the means or manner of Contractor's performance. Contractor is responsible for determining the appropriate means and manner of performing any Services required under this Contract. Contractor is not an "officer", "employee", or "agent" of the District as those terms are used in ORS 30.265, ii. If Contractor is currently performing work for the District, the State or Oregon or the federal government, Contractor by signature to this Contract declares and certifies that Contractor's performance under this Contract creates no potential or actual conflict of interest as defined by ORS 244 and that no rules or regulations of Contractor's employing state would prohibit Contractor's performance under this Contract. iii. Contractor shall pay or cause to be paid all federal and state taxes applicable to Contractor's compensation under this Contract, and the District will not withhold from Contractor's compensation any amount to cover Contractor's federal or state tax obligations unless Contractor is subject to backup withholding. Contractor is not eligible for any social security, unemployment insurance or workers' compensation benefits from Contractor's compensation under this Contract. M. INDEMNIFICATION. i. GENERAL INDEMNITY. CONTRACTOR SHALL DEFEND, SAVE, HOLD HARMLESS, AND INDEMNIFY THE DISTRICT, ITS OFFICERS, DIRECTORS, AGENTS AND EMPLOYEES FROM AND AGAINST ALL CLAIMS, SUITS, ACTIONS, LOSSES, DAMAGES, LIABILITIES, COSTS AND EXPENSES OF ANY NATURE WHATSOEVER ("CLAIMS") RESULTING FROM, ARISING OUT OF, OR RELATING TO THE ACTS OR OMISSIONS OF CONTRACTOR OR ITS OFFICERS, EMPLOYEES, SUBCONTRACTORS, OR AGENTS UNDER THIS CONTRACT. Deschutes_County_9-1- 1_Contract_2Apr 10 Page 7 of 16 ii. INDEMNITY FOR INFRINGEMENT CLAIMS. WITHOUT LIMITING THE GENERALITY OF SECTION 4.N.i, CONTRACTOR SHALL DEFEND, SAVE, HOLD HARMLESS AND INDEMNIFY THE DISTRICT, ITS OFFICERS, DIRECTORS, AGENTS, AND EMPLOYEES FROM AND AGAINST ALL CLAIMS, SUITS, ACTIONS, LOSSES, DAMAGES, LIABILITIES, COSTS, AND EXPENSES, INCLUDING ATTORNEYS FEES, ARISING OUT OF OR RELATING TO ANY CLAIMS THAT THE WORK, THE WORK PRODUCT OR ANY OTHER TANGIBLE OR INTANGIBLE ITEM DELIVERED UNDER THIS CONTRACT BY CONTRACTOR THAT MAY BE THE SUBJECT OF PROTECTION UNDER ANY STATE OR FEDERAL INTELLECTUAL PROPERTY LAW OR DOCTRINE, OR THE DISTRICT'S REASONABLE USE THEREOF, INFRINGES ANY PATENT, COPYRIGHT, TRADE SECRET, TRADEMARK, TRADE DRESS, MASK WORK, UTILITY DESIGN, OR OTHER PROPRIETARY RIGHT OF ANY THIRD PARTY ("INFRINGEMENT CLAIM"); PROVIDED, THAT THE DISTRICT SHALL PROVIDE CONTRACTOR WITH PROMPT WRITTEN NOTICE OF ANY INFRINGEMENT CLAIM. iii. THE DISTRICT SHALL REASONABLY COOPERATE IN GOOD FAITH, AT CONTRACTOR'S REASONABLE EXPENSE, IN THE DEFENSE OF CLAIMS AND INFRINGEMENT CLAIMS, AND CONTRACTOR SHALL SELECT COUNSEL REASONABLY ACCEPTABLE TO DISTRICT LEGAL COUNSEL TO DEFEND SUCH CLAIMS AND INFRINGEMENT CLAIMS AND SHALL BEAR ALL COSTS OF SUCH COUNSEL. THE DISTRICT MAY ELECT TO ASSUME ITS OWN DEFENSE WITH AN ATTORNEY OF ITS OWN CHOICE AND AT ITS OWN EXPENSE AT ANY TIME THE DISTRICT DETERMINES IMPORTANT GOVERNMENTAL INTERESTS ARE AT STAKE. SUBJECT TO THE LIMITATIONS NOTED ABOVE, CONTRACTOR MAY DEFEND SUCH CLAIMS AND INFRINGEMENT CLAIMS WITH COUNSEL OF ITS OWN CHOOSING PROVIDED THAT NO SETTLEMENT OR COMPROMISE OF ANY SUCH CLAIMS AND INFRINGEMENT CLAIMS SHALL OCCUR WITHOUT THE CONSENT OF THE DISTRICT, WHICH CONSENT SHALL NOT BE UNREASONABLY WITHHELD, CONDITIONED OR DELAYED. N. ASSIGNMENT OF ANTITRUST RIGHTS. i. CONTRACTOR IRREVOCABLY ASSIGNS TO THE DISTRICT ANY CLAIM FOR RELIEF OR CAUSE OF ACTION WHICH CONTRACTOR NOW HAS OR WHICH MAY ACCRUE TO CONTRACTOR IN THE FUTURE BY REASON OF ANY VIOLATION OF 15 U.S.C. § 1-15 OR ORS 646.725 OR ORS 646.730, IN CONNECTION WITH ANY GOODS OR SERVICES PROVIDED TO CONTRACTOR FOR THE PURPOSE OF CARRYING OUT CONTRACTOR'S OBLIGATIONS UNDER THIS CONTRACT, INCLUDING, AT DISTRICT'S OPTION, THE RIGHT TO CONTROL ANY SUCH LITIGATION ON SUCH CLAIM FOR RELIEF OR CAUSE OF ACTION. ii. CONTRACTOR SHALL REQUIRE ANY SUBCONTRACTORS HIRED TO PERFORM ANY OF CONTRACTOR'S DUTIES UNDER THIS CONTRACT TO IRREVOCABLY ASSIGN TO THE DISTRICT, AS THIRD PARTY BENEFICIARY, ANY RIGHT, TITLE OR INTEREST THAT HAS ACCRUED OR WHICH MAY ACCRUE IN THE FUTURE BY REASON OF ANY VIOLATION OF 15 U.S.C. § 1-15 OR ORS 646.725 OR ORS 646.730, IN CONNECTION WITH ANY GOODS OR SERVICES PROVIDED TO THE SUBCONTRACTOR FOR THE PURPOSE OF CARRYING OUT THE SUBCONTRACTOR'S OBLIGATIONS TO CONTRACTOR IN PURSUANCE OF THIS CONTRACT, INCLUDING, AT DISTRICT'S OPTION, THE RIGHT TO CONTROL ANY SUCH LITIGATION ON SUCH CLAIM FOR RELIEF OR CAUSE OF ACTION. O. EVENTS OF BREACH. i. Breach by Contractor. Contractor breaches this Contract if: Deschutes_County_9-1- 1_Contract_2Apr 10 Page 8 of 16 a. Contractor institutes or has instituted against it insolvency, receivership or bankruptcy proceedings, makes an assignment for the benefit of creditors, or ceases doing business on a regular basis; b. Contractor no longer holds a license or certificate that is required for Contractor to perform its obligations under this Contract and Contractor has not obtained the required license or certificate within fourteen (14) calendar days after delivery of the District's notice of breach or a longer period as the District may specify in its notice; or c. Contractor commits any material breach of any covenant, warranty, obligation or certification under this Contract, and Contractor fails to cure its breach within fourteen (14) calendar days after delivery of the District's notice of breach or within a longer period as the District may specify in its notice. ii. Breach by the District. The District breaches this Contract if: a. The District fails to pay Contractor any amount pursuant to the terms of this Contract, and the District fails to cure this failure within fourteen (14) business days after delivery of Contractor's notice of breach or within a longer period as Contractor may specify in its notice; or b. The District commits any material breach of its obligations under this Contract, fails to perform its obligations hereunder within the time specified or any extension thereof, and fails to cure its failure within fourteen (14) calendar days after delivery of Contractor's notice of breach or a longer period as Contractor may specify in its notice. P. REMEDIES. i. District's Remedies. If Contractor is in breach under section 4.O.i, then in addition to the remedies afforded elsewhere in this Contract, the District shall be entitled to recover for any and all damages suffered as the result of Contractor's breach of this Contract, including but not limited to direct, indirect, incidental and consequential damages, as provided in ORS Chapter 72. The District may, at its option, pursue any or all of the remedies available under this Contract and at law or in equity, including, but not limited to: a. Termination of this Contract under section 4.R.ii; b. Withholding all amounts Contractor has invoiced for Goods and Services that Contractor is obligated to but has failed to deliver or perform within any scheduled completion dates or has performed inadequately or defectively; c. Initiation of an action or proceeding for damages, specific performance, declaratory or injunctive relief; or d. Exercise of the right of setoff and withholding amounts otherwise due and owing to Contractor in an amount equal to the District's setoff right, without penalty. These remedies are cumulative to the extent the remedies are not inconsistent, and the District may pursue any remedy or remedies singly, collectively, successively or in any order whatsoever. If Contractor is found to not be in breach under section 4.O.i, the rights and obligations of the parties shall be the same as if this Contract was terminated pursuant to section 4.R.ii.a. ii. Contractor's Remedies. If the District terminates this Contract for convenience under section 4.R.ii.a, or if the District is in breach under section 4.O.ii and whether or not Contractor elects to exercise its right to terminate this Contract under section 4.R.iii, Contractor's sole remedy is a claim against the District for the unpaid price for any Goods delivered and accepted by the District Deschutes_County_9-1-1 _Contract_2Apr 10 Page 9of16 less any claims the District has against Contractor and is as follows for unpaid Services completed and accepted by the District: a. For Services compensable on an hourly basis, a claim against the District for unpaid invoices, hours worked but not yet invoiced, and authorized expenses for Services completed and accepted by the District less any claims the District has against Contractor. b. For deliverable -based Services, a claim against the District for the amount specified for completing the deliverable multiplied by the percentage of Services completed and accepted by the District, less previous amounts paid and the amount of any claims the District has against Contractor. If previous amounts paid to Contractor for Goods and Services exceed the amount due to Contractor under this section 4.P.ii, Contractor shall pay the excess amount to the District immediately upon written demand. Q. ATTORNEYS' FEES. Except for defense costs and expenses pursuant to section 4.M, neither the District nor Contractor is entitled to recover attorney's fees, court and investigative costs, or any other fees or expenses associated with pursuing a remedy for damages arising out of or relating to this Contract. R. TERMINATION. i. MUTUAL CONSENT. The Contract may be terminated at any time by mutual written consent of the parties. ii. The District: a. The District may, at its sole discretion, terminate the Contract for its convenience upon 30 days written notice to Contractor. b. The District may, in its sole discretion, terminate this Contract, immediately upon notice to Contractor, or at a later date as the District may establish in its notice, upon the occurrence of any of the following events: 1. The District fails to receive funding, appropriations, limitations, allotments or other expenditure authority at levels sufficient to allow the District, in the exercise of its reasonable administrative discretion, to make payments under this Contract; 2. Federal or state laws, regulations, or guidelines are modified or interpreted in a way that either the purchase of Goods or Services, or both, by the District under this Contract is prohibited, or the District is prohibited from paying for Goods or Services, or both, from the planned funding source; or 3. Contractor commits any material breach of this Contract. Contractor shall stop performance under this Contract as directed by the District in any written notice of termination delivered to Contractor under this section 4.S.ii. iii. CONTRACTOR. Contractor may terminate this Contract immediately upon written notice to the District, or at a later date as Contractor may establish in its notice, if the District is in breach under section 4.P.ii. Deschutes_County_9-1- 1_Contract_2Apr10 Page 10 of 16 S. INTELLECTUAL PROPERTY & OPEN SOURCE; TITLE TO GOODS. DEFINITION: "Work Product" means any and all "Work for Hire" deliverables as defined under the Provisions of the U.S. Copyright Act Title 17, United States Code, Section 101 specifically commissioned by the District from the Contractor and clearly stated as "Work for Hire" on the Contractor's statement of work defining the project issued pursuant to this Contract. i. New Works. All intellectual property rights in the Work Product created by Contractor under this Contract shall be the exclusive property of the District. All Work Product authored by Contractor under this Contract shall be deemed "works made for hire" to the extent permitted by the United States Copyright Act. To the extent the District is not the owner of the intellectual property rights in such Work Product, Contractor hereby irrevocably assigns to the District any and all of its rights, title, and interest in such Work Product. Upon the District's reasonable request, Contractor shall execute such further documents and instruments reasonably necessary to fully vest such rights in the District. Contractor forever waives any and all rights relating to such Work Product created under this Contract, including without limitation, any and all rights arising under 17 USC §106A or any other rights of identification of authorship or rights of approval, restriction or limitation on use or subsequent modifications. ii. Contractor Intellectual Property. If intellectual property rights in the Work Product are Contractor Intellectual Property, Contractor hereby grants to the District an irrevocable, non- exclusive, perpetual, royalty -free license to use, make, reproduce, prepare derivative works based upon, distribute copies of, perform and display the Contractor Intellectual Property, and to authorize others to do the same on the District's behalf. iii. Third Party Intellectual Property. To the extent Contractor has the authority, Contractor shall sublicense or pass through to the District all Third Party Intellectual Property. Contractor represents and warrants that it has provided written disclosure to the District of all Third Party Intellectual Property that must be independently licensed by the District to fully enjoy the benefit of the Work Product. If Contractor failed to provide such written disclosure, Contractor shall secure on the District's behalf and in the name of the District, an irrevocable, non-exclusive, perpetual, royalty -free license to use, make, reproduce, prepare derivative works based upon, distribute copies of, perform and display the Third Party Intellectual Property, and to authorize others to do the same on the District's behalf. iv. Open Source Approval and Notice. Any Open Source Elements in the Work Product must be approved in advance and in writing by the District. If the District approves the use of Open Source Elements, Contractor shall: a. Notify the District in writing that the Work Product contains Open Source Elements; b. Identify the specific portion of the Work Product that contain Open Source Elements; and c. Provide a copy of the applicable license for each Open Source Element to the District. v. Title to Goods. Title to Goods passes to the District in accordance with ORS 72.4010. T. ACCESS TO RECORDS. Contractor shall retain, maintain, and keep accessible all records relevant to this Contract ("Records") for six (6) years following Contract termination or full performance, the period required by applicable law following Contract termination or full performance, or until the conclusion of any audit, controversy or litigation arising out of or related to this Contract, whichever ending date is later. Contractor shall maintain all financial Records in accordance with generally accepted Deschutes County_9-1-1 _Contract_2Apr 10 Page 11 of 16 accounting principles. During this Record -retention period, Contractor shall permit the District, its duly authorized representatives, and the federal government access to the Records at reasonable times and places for purposes of examination and copying. U. NOTICES. All notices required under this Contract shall be in writing and addressed to the party's authorized representative. For the District, the authorized representative is the District contact person identified in section 8. Contractor's authorized representative is the contact person identified in section 7. Mailed notices are deemed received five (5) days after the post mark date when properly addressed and deposited prepaid into the U.S. postal service. Faxed notices are deemed received upon electronic confirmation of successful transmission to the designated fax number. Notices delivered by personal delivery are deemed received when delivered to the address specified for the receiving party's authorized representative. V. GOVERNING LAW. The Contract is governed by and construed in accordance with the laws of State of Oregon without regard to principles of conflicts of laws. To the extent not modified by the terms of this Contract, the Uniform Commercial Code as codified in ORS Chapters 71 and 72 governs Goods under this Contract. The applicability of the UN Convention on Contracts for the International Sale of Goods is hereby expressly waived by the parties, and it does not apply to this Contract. W. VENUE; CONSENT TO JURISDICTION. Any claim, action, suit or proceeding (collectively, "Proceeding") between the District and Contractor that arises from or relates to this Contract shall be brought and conducted solely and exclusively within the Circuit Court of the State of Oregon for Deschutes County; provided, however, if a Proceeding must be brought in a federal forum, then unless otherwise prohibited by law, it shall be brought and conducted solely and exclusively within the United States District Court for the District of Oregon. CONTRACTOR HEREBY CONSENTS TO THE IN PERSONAM JURISDICTION OF THESE COURTS AND WAIVES ANY OBJECTION TO VENUE IN THESE COURTS AND ANY CLAIM THAT THE FORUM IS AN INCONVENIENT FORUM. Nothing in these provisions shall be construed as a waiver of the District's sovereign or governmental immunity, whether derived from the Eleventh Amendment to the United States Constitution or otherwise, or a waiver of any defenses to Proceedings or jurisdiction based thereon. X. SURVIVAL: In addition to all provisions which by their nature extend beyond the Contract termination or full performance, the following provisions shall remain in effect beyond any Contract termination or full performance: sections 1, 3, 4.A, 4.D, 4.E, 4.F, 4.L, 4.M, 4.N, 4.0, 4.P, 4.Q, 4.R, 4.S, 4.T, 4.U, 4.V, 4.W, 4.X, 4.Y, 4.CC and section 5. Y. SEVERABILITY. If a court of competent jurisdiction declares any provision of this Contract to be illegal or otherwise invalid, the validity of the remaining terms and provisions shall not be affected, and the rights and obligations of the parties shall be construed and enforced as if this Contract did not contain the particular provision held to be invalid. Deschutes_County_9-1- 1_Contract_2Apr 1 0 Page 12 of 16 Z. SUBCONTRACTS; ASSIGNMENT; SUCCESSORS. i. SUBCONTRACTS. Contractor shall not enter into any subcontracts for any Services required under this Contract without the District's prior written consent. In addition to any other provisions the District may require, Contractor shall include in any permitted subcontract provisions to ensure that the District will receive the benefit of subcontractor's performance as if the subcontractor were Contractor with respect to sections 3, 4.E, 4.F, 4.J, 4.K, 4.L, 4.M, 4.N, 4.0, 4.P, 4.Q, 4.R, 4.S, 4.T, 4.U, 4.W, 4.X, and 4.AA. The District's consent to any subcontract shall not relieve Contractor of any of its duties or obligations under this Contract. ii. Contractor shall not assign, delegate or transfer any of its rights or obligations under this Contract without the District's prior written consent. The District's written consent does not relieve Contractor of any obligations under this Contract, and any assignee, transferee, or delegate is considered Contractor's agent. iii. The provisions of this Contract are binding upon, and inure to the benefit of the parties and their respective successors and permitted assigns, if any. M. MERGER CLAUSE; AMENDMENT; WAIVER. This Contract constitutes the entire agreement between the parties on the subject matter thereof. There are no understandings, agreements or representations, oral or written, not specified herein regarding this Contract. This Contract may be amended to the extent permitted by applicable statutes and administrative rules. For Anticipated Amendments, this Contract may be amended only in accordance with and to the extent provided in the Solicitation, if any, and this Contract, in accordance with OAR 125-246-0560. No waiver, consent or amendment of terms of this Contract shall bind either party unless in writing and signed by the District and Contractor, and all necessary approvals have been obtained. Waivers and consents shall be effective only in the specific instance and for the specific purpose given. The failure of the District to enforce any provision of this Contract shall not constitute a waiver by the District of that or any other provision. BB. THIRD PARTY BENEFICIARIES. The District and Contractor are the only parties to this Contract and are the only parties entitled to enforce the terms of this Contract. Nothing in this Contract gives, is intended to give, or shall be construed to give or provide any benefit or right not held by or made generally available to the public, whether directly, indirectly or otherwise, to third persons unless the third persons are individually identified by name herein and expressly described as intended beneficiaries of the terms of this Contract. The District is an intended beneficiary of the terms of this Contract. CC. COUNTERPARTS. This Contract may be executed in several counterparts, all of which when taken together shall constitute one agreement binding on all parties, notwithstanding that all parties are not signatories to the same counterpart. Each copy of this Contract so executed shall constitute an original. 5. INSURANCE A. REQUIRED INSURANCE. Contractor shall obtain the insurance specified in this section 5 prior to performing under this Contract and shall maintain it in full force and at its own expense throughout the duration of this Contract and all Warranty Periods. Contractor shall obtain the following insurance from insurance companies or entities that are authorized to transact the business of insurance and issue coverage in State and that are acceptable to the District. Deschutes_County_9-1-1_Contract_2Apr10 Page 13 of 16 i. WORKERS COMPENSATION. All employers, including Contractor, that employ subject workers who work under this Contract in State shall comply with ORS 656.017 and provide the required workers' compensation coverage, unless these employers are exempt under ORS 656.126(2). Contractor shall require each of its subcontractors, if any, to comply with, and shall ensure that each of its subcontractors, if any, complies with, these requirements. ii. COMMERCIAL GENERAL LIABILITY. Required by District ❑ Not required by District. Commercial General Liability Insurance covering bodily injury and property damage in a form and with coverages that are satisfactory to the District. This insurance shall include personal and advertising injury liability, products and completed operations liability. Coverage may be written in combination with Automobile Liability Insurance (with separate limits). Combined single limit per occurrence shall not be less than $533,000 for each job site or location. Each annual aggregate limit shall not be less than $1,066,700. iii. AUTOMOBILE LIABILITY INSURANCE: AUTOMOBILE LIABILITY. ® Required by District ❑ Not required by District. Automobile Liability Insurance covering all owned, non -owned, and hired vehicles. This coverage may be written in combination with the Commercial General Liability Insurance. Combined single limit per occurrence shall not be less than $533,000. iv. EMPLOYERS' LIABILITY. ❑ Required by District ® Not required by District. If Contractor is a subject employer, as defined in ORS 656.023, Contractor shall obtain employers' liability insurance coverage with combined single limit per occurrence of not less that $533,000, and annual aggregate limits of not less than $1,066,700. v. POLLUTION LIABILITY. ❑ Required by District ® Not required by District. Pollution Liability Insurance covering Contractor's liability for bodily injury, property damage and environmental damage resulting from either sudden or gradual accidental pollution and related cleanup costs incurred by Contractor, all arising out of Goods delivered or Services (including transportation risk) performed under this Contract. Combined single limit per occurrence shall not be less than $_, or the equivalent. Annual aggregate limit shall not be less than $. B. ADDITIONAL INSURED. The commercial general liability insurance and automobile liability insurance required under this Contract shall include the District, and its divisions, commissions, branches, officers and employees as Additional Insureds with respect to Contractor's performance obligations under this Contract. Contractor shall ensure that coverage is primary and non-contributory with any other insurance and self-insurance. Deschutes County_9-1-1_Contract_2Apr10 Page 14of16 C. "TAIL" COVERAGE. If any of the required liability insurance is on a "claims made" basis, Contractor shall either maintain either "tail" coverage or continuous "claims made" liability coverage, provided the effective date of the continuous "claims made" coverage is on or before the effective date of this Contract, for a minimum of 24 months following the later of i. The District's acceptance of all Goods in accordance with section 4.D, ii. The completion of all Services required under this Contract, or iii. The expiration of all warranty periods provided under this Contract. Notwithstanding the foregoing 24 -month requirement, if Contractor elects to maintain "tail" coverage and if the maximum time period "tail" coverage reasonably available in the marketplace is less than the 24 -month period described above, then Contractor shall maintain "tail" coverage for the maximum time period that "tail" coverage is reasonably available in the marketplace for the coverage required under this Contract. Contractor shall provide to the District, upon request, certification of the coverage required under this section 5.C. D. NOTICE OF CANCELLATION OR CHANGE. There shall be no cancellation, material change, potential exhaustion of aggregate limits or non- renewal of insurance coverage(s) without sixty (60) days' written notice from this Contractor or its insurer(s) to the District. Any failure to comply with the reporting provisions of this clause shall constitute a material breach of Contract and shall be grounds for immediate termination of this Contract by the District. No later that fourteen (14) calendar days following the effective date of any insurance policy renewals, Contractor shall deliver to the District all documentation evidencing renewal of the particular insurance policy renewed. E. CERTIFICATE(S) OF INSURANCE. Upon the District's request, Contractor shall provide to the District Certificate(s) of Insurance for all required insurance. The Certificate(s) must specify all entities and individuals who are endorsed on the policy as Additional Insured (or Loss Payees). Contractor shall pay for all deductibles, self- insured retention and self-insurance, if any. 6. RESERVED. 7. CERTIFICATIONS AND SIGNATURE OF CONTRACTOR'S AUTHORIZED REPRESENTATIVE. THIS CONTRACT MUST BE SIGNED IN INK BY AN AUTHORIZED REPRESENTATIVE OF CONTRACTOR. Deschutes_County_9-1- 1_Contract_2Apr 10 Page 15 of 16 The undersigned certifies under penalty of perjury both individually and on behalf of Contractor that: A. The undersigned is a duly authorized representative of Contractor, has been authorized by Contractor to make all representations, attestations, and certifications contained in this Contract and to execute this Contract on behalf of Contractor; B. The undersigned is authorized to act on behalf of Contractor and that Contractor is, to the best of the undersigned's knowledge, not in violation of any Oregon Tax Laws. For purposes of this certification, "Oregon Tax Laws" means a state tax imposed by ORS 401.792 to 401.816 (Tax For Emergency Communications), 118 (Inheritance Tax), 314 (Income Tax), 316 (Personal Income Tax), 317 (Corporation Excise Tax), 318 (Corporation Income Tax), 320 (Amusement Device and Transient Lodging Taxes), 321 (Timber and Forestland Tax), 323 (Cigarettes and Tobacco Products Tax), and the elderly rental assistance program under ORS 310.630 to 310.706; and any local taxes administered by the Department of Revenue under ORS 305.620. C. To the best of the undersigned's knowledge, Contractor has not discriminated against and will not discriminate against minority, women or emerging small business enterprises certified under ORS 200.055 in obtaining any required subcontracts. D. Contractor and Contractor's employees and agents are not included on the list titled "Specially Designated Nationals and Blocked Persons" maintained by the Office of Foreign Assets Control of the United States Department of the Treasury and currently found at http://www.treas.gov/offices/enforcement/ofac/sdn/t1lsdn.pdf; E. Contractor's Federal Employee Identification Number or Social Security Number specified below is correct; F. Contractor is bound by and will comply with all requirements, terms and conditions contained in this Contract and will provide Goods and Services in accordance with the Specifications; and G. Contractor _ is / one). See section 4.A.ii. is not a nonresident alien as defined in 26 USC § 7701(b)(1) (check Contractor (print Contractor's na : Executive Information Services, Inc. Authorized Signature: By (print name): /v/ir LT d/to Tcale rky Title: Pi La-s,,e 'NT - Date: 4//0pl� FEIN ID# or SSN# (required): 30--doy/7336 Contractor's Contact Person (Type or Print): /thvy4s 5, km" c- Contact Telephone Number: ( 352 ) 2 36-- 1/5-00 Contact Fax Number: ( y0 %) ! SO - 2( 4 Deschutes_County_9-1- 1_Contract_2Apr 10 Page 16 of 16 Contact E -Mail Address: Mailing Address: �% �✓ ,'�if oc, Deschutes_County_9-1- 1_Contract_2Apr 10 Page 17 of 16 th /e) 1>%1 j /oo 23 (/ ) 8. SIGNATURE DISTRICT'S AUTHORIZED REPRESENTATIVE. Deschutes County 9-1-1 Service District accepts Contractor's offer and awards this Contract to Contractor for Goods and Service described in this Contract. District's Contact Person: Shawn Pray Contact Telephone Number: (541) 388-0185 x2313 Fax Number: (541) 382-5767 E -Mail Address: shawnp@deschutes.org District Mailing Address: 63333 Hwy 20 #911, Bend, OR 97701 DATED this Day of 2010. BOARD OF COUNTY COMMISSIONERS OF DESCHUTES COUNTY, OREGON, ACTING AS THE GOVERNING BODY OF THE DESCHUTES COUNTY 9-1-1 SERVICE DISTRICT. DENNIS LUKE, Chair ALAN UNGER, Commissioner TAMMY BANEY, Commissioner ATTEST: Recording Secretary Deschutes_County_9-1-1_Contract_2Apr 10 Page 18 of 16 SCHEDULE A EIS PRICING PROPOSAL Contractors Pricing Proposal dated September 10, 2009, Revised January 14, 2010 price proposal number QT -442/3 REV 1 and Pricing Proposal extension letter dated March 1, 2010 names ProposalExtentionLetter.pdf is incorporated by reference into this Contract as Contract Schedule A. Deschutes_County_9-1-1_Contract 2Apr 1 0 March 1, 2010 Rick Silbaugh Deschutes County 9-1-1 Service District 63333 Highway 20 W., Bend, OR 97701 Mr. Silbaugh, Executive Information Services, Inc (EIS, INC.) will extend the expiration date of the pricing proposal number: QT -442/3 REV 1 for the Central Oregon CAD -to -CAD integration project. The original expiration date of March 14, 2010 has been extended through April 20th, 2010. If additional time is need to process the order please let us know. If you have any questions, concerns or require additional clarification, please do not hesitate to contact me. Thanks again for your assistance and support. Adam Missler adam@goeis.net Executive Information Services, Inc. Corporate Headquarters: 1396 NE 20th Ave. Suite 100 Ocala, FL 34470 http://www.goeis.net (856) 701-6107 Telephone (206) 201-6107 Fax (877) 347-9273 X42 Toll Free Sales (208) 580-0400 HelpDesk Executive Information Services, Inc. • 1396 NE 20th Ave. Suite 100. Ocala, FL 34470 • Phone: (856) 701-6107 • WWW.goeis.net Executive Information Services, Inc. 1396 NE 20th Ave. Suite 100 - Ocala - FL - 34470 - Phone: (856) 701-6107 Agency: Central Oregon CAD -to -CAD integration Address: Via/ Deschutes County Address: Contact: Rick Silbaugh Telephone: (541) 388-0185 x2306 Proposal Number: QT -442/3 REV 1 Proposal Creation Date: September 11, 2009 Proposal Revision: January 14, 2010 Proposal Expiration Date: March 14, 2010 Prepared By: A. Missler ne d Interface Development - Project Services Jefferson County Communications Crook County Communications Tri -County Communications Klamath County Communications Lake County Communications Optional: Additional Sites Hood River County Communications Wasco County Communications Software Licensing $31,000.00 $31,000.00 $37,800.00 $31,000.00 $37,800.00 Services $62,000.00 $14,810.00 $14,810.00 $14,810.00 $14,810.00 $14,810.00 $168,600.00 $136,050.00 SUB -TOTAL $304,650.00 SYSTEM TOTAL $304,650.00 2nd Year Support 3rd year support $6,000.00 $6,000.00 PROJECT TOTAL $316,650.00 Software Licensing $31,000.00 $31,000.00 Services $14,810.00 $14,810.00 2nd Y Support ,200.00 ,200.00 $1,200.00 $1,200.00 $6,000.00 - Pricing does not include applicable state and local tax. - Includes Site License for the above listed software unless otherwise specified. - EIS's terms are Net 30. - Pricing includes shipping charges. - Quote only covers products and services listed herein. Quote is valid only through the expiration date indicated herein. No feature, function or characteristic not described herein is implied. - All software and hardware purchased from EIS includes one (1) year standard warranty/support/maintenance from date of delivery. - Second Year Standard Maintenance is available @ 15% of the System and Software Pricing. Confidential Statement: The information contained in this document is confidential and intended only to be viewed by the recipient listed above. If you are not the intended recipient (please forward to correct re- cipient) you are herby notified that any distribution or copying of this document is strictly prohibited. If you have received this document in error, please contact the sender listed above and destroy the document. Page 1 of 6 Executive Information Services, Inc. 1396 NE 20th Ave. Suite 100 - Ocala - FL - 34470 - Phone: (856) 701-6107 Agency: Central Oregon CAD -to -CAD integration Address: Via/ Deschutes County Address: Contact: Rick Silbaugh Telephone: (541) 388-0185 x2306 SRVH2 11 Proposal Number: QT -442/3 REV 1 Proposal Creation Date: September 11, 2009 Proposal Revision: January 14, 2010 Proposal Expiration Date: March 14, 2010 Prepared By: A. Missler !,%IT Development & Documentation $62,000.00 A. Custom Development of the interface and exchange component to support Oregon specifications for CAD to State switch integration. B. Modifications to Base PS.NET/CAD workstation to support interface C. Development of Gateway service application CAD Fully Configured Dispatch System VPN Over internet PDCC Switct M2 Server w/ o PDCC interface service module PS.NET Database Server PS.NET CAD Application Server PS.NET Map Application Server PS.NET MDC Controller • General System Architecture Oregon PDCC Interface 9/10/2009 Firewall Component Breakdown 1. New M2 Gateway Server (Hardware) 2. New M2 Gateway Application 3. New interface service module 4. Modifications to CAD Application Server and CAD Workstation to Support CFS Transfers Executive Information Services, Inc. 1396 NE 20th Ave. Suite 100 - Ocala - FL - 34470 - Phone: (856) 701-6107 Agency: Central Oregon CAD -to -CAD integration Address: Via/ Deschutes County Address: Contact: Rick Silbaugh Telephone: (541) 388-0185 x2306 Jefferson County Communications M2AX M2CAD XXXX XXXX SRVH2 SRV5 SRVH7 M2 Switch License CAD M2 adapter CAD Upgrade Software Server Hardware Technical Services Travel & Per Diem On -Site Installation & Training Crook County Communications M2AX M2 Switch License M2CAD XXXX XXXX SRVH2 SRV5 SRVH7 CAD M2 adapter CAD Upgrade Software Server Hardware Technical Services Travel & Per Diem On -Site Installation & Training Tri -County Communications M2AX M2 Switch License M2CAD XXXX CADAM XXXX SRVH2 SRV5 SRVH7 CAD M2 adapter CAD Upgrade Software CAD Mapping Software Server Hardware Technical Services Travel & Per Diem On -Site Installation & Training Klamath County Communications M2AX M2 Switch License M2CAD XXXX XXXX SRVH2 SRV5 SRVH7 CAD M2 adapter CAD Upgrade Software Server Hardware Technical Services Travel & Per Diem On -Site Installation & Training iTr e �-ygct� Proposal Number: QT -442/3 REV 1 Proposal Creation Date: September 11, 2009 Proposal Revision: January 14, 2010 Proposal Expiration Date: March 14, 2010 Prepared By: A. Missler 44 44 Site Site Site Machine Site Site Site Site Site Machine Site Site Site Site Site Site Machine Site Site Site Site Site Machine Site Site $25,000.00 $6,000.00 NC $3,930.00 $2,680.00 $2,800.00 $5,400.00 $25,000.00 $6,000.00 NC $3,930.00 $2,680.00 $2,800.00 $5,400.00 $25,000.00 $6,000.00 NC $6,800.00 $3,930.00 $2,680.00 $2,800.00 $5,400.00 $25,000.00 $6,000.00 NC $3,930.00 $2,680.00 $2,800.00 $5,400.00 $45,810.00 $45,810.00 $52,610.00 $45,810,00 Executive Information Services, Inc. 1396 NE 20th Ave. Suite 100 - Ocala - FL - 34470 - Phone: (856) 701-6107 ° Agency: Central Oregon CAD -to -CAD integration Address: Via/ Deschutes County Address: Contact: Rick Silbaugh Telephone: (541) 388-0185 x2306 Lake County Communications M2AX M2 Switch License M2CAD CAD M2 adapter XXXX CAD Upgrade Software CADAM CAD Mapping Software XXXX Server Hardware SRVH2 Technical Services SRV5 Travel & Per Diem SRVH7 On -Site Installation & Training Ord ms ���' Wasco County Communications M2AX M2 Switch License M2CAD CAD M2 adapter XXXX CAD Upgrade Software XXXX Server Hardware SRVH2 Technical Services SRV5 Travel & Per Diem SRVH7 On -Site Installation & Training Proposal Number: QT -442/3 REV 1 Proposal Creation Date: September 11, 2009 Proposal Revision: January 14, 2010 Proposal Expiration Date: March 14, 2010 Prepared By: A. Missler Site Site Site Site Machine Site Site • Site Site Site Machine Site Site $25,000.00 $6,000.00 NC $6,800.00 $3,930.00 $2,680.00 $2,800.00 $5,400.00 $25,000.00 $6,000.00 NC $3,930.00 $2,680.00 $2,800.00 $5,400.00 Hood River County Communications M2AX M2 Switch License Site $25,000.00 M2CAD CAD M2 adapter Site $6,000.00 XXXX CAD Upgrade Software Site NC XXXX Server Hardware Machine $3,930.00 SRVH2 Technical Services Site $2,680.00 SRV5 Travel & Per Diem Site $2,800.00 SRVH7 On -Site Installation & Training $5,400.00 $52,610.00 $45,810.00 $45,810.00 Estimated Hardware Total $3,930.00 I Executive Information Services, Inc. 1396 NE 20th Ave. Suite 100 - Ocala - FL - 34470 - Phone: (856) 701-6107 • Agency: Central Oregon CAD -to -CAD integration Address: Via/ Deschutes County Address: Contact: Rick Silbaugh Telephone: (541) 388-0185 x2306 4.0 Proposal Number: QT -442/3 REV 1 Proposal Creation Date: September 11, 2009 Proposal Revision: January 14, 2010 Proposal Expiration Date: March 14, 2010 Prepared By: A. Missler 040 0 PowerEdge T605 Quad Core AMD OpteronTM 2350, 2.0GHz, 1 Ghz HyperTransport 4GB DDR2, 667MHz, 4x1 GB Single Ranked DIMMs SAS 6iR SAS internal RAID adapter, PCI -Express Add-in SAS 6/iR SATA/SAS Controller RAID 1,Support 2 Cabled Hard Drives (2) 146GB 15k RPM Serial -Attach SCSI 3Gbps 3.5 -in Cabled Hard Drive Intel PRO 1000PT 1 GbE Dual Port NIC, PCIe-4 16x DVD -ROM Drive, Internal, SATA Electronic Documentation and OpenManage DVD Kit Operating System: Windows Server® 2008, Standard Edition, Includes 5 CALs Hardware Support Services: 3Yr Basic Hardware Warranty Repair: 5x10 HW -Only, 5x10 NBD Onsite Ins on Technical Services - Server Configuration Executive Information Services, Inc. 1396 NE 20th Ave. Suite 100 - Ocala - FL - 34470 - Phone: (856) 701-6107 ,44 44,444 • 744 Agency: Central Oregon CAD -to -CAD integration Address: Via/ Deschutes County Address: Contact: Rick Silbaugh Telephone: (541) 388-0185 x2306 Proposal Number: QT -442/3 REV 1 Proposal Creation Date: September 11, 2009 Proposal Revision: January 14, 2010 Proposal Expiration Date: March 14, 2010 Prepared By: A. Missler Notes to Pricing 1. This proposal is submitted to the Agency by Executive Information Services, Inc. This proposal will expire as noted in the expiration date or 90 days from proposal creation date, unless extended by Executive Information Services, Inc. 2. Unless contractually negotiated otherwise, system price is based on a payment schedule of twenty five (25) percent upon contract execution, balance of hardware price on date of delivery, and balance of contract price upon delivery of individual components. 3. All prices are FOB Destination. Sale prices quoted are exclusive of any state, local, use, or other applicable taxes. Hardware prices do not include shipping charges which will be added to the invoice. 4. Software pricing quoted is for a fully paid license for specified use on a networked computing system within the contract agency and is supplied subject to execution of a separate licensing and non -disclosure agreement which prohibits distribution, re -sale, or other disclosure outside of contracting agency. Full site licensing is included for the agency and there are no restrictions on the number of deployed workstations or users of the system within the agency. 5. All computing hardware, operating systems, database management systems, facility modifications, communications circuits, and network components not expressly provided in this proposal are the responsibility of the Agency. 6. Installation includes application software installation on user supplied computing platform, all table configuration, end- user training, network configuration, and similar activity. Installation also includes general network design consulting, network configuration, and installation and/or configuration of operating system software; including the Windows operating system and Microsoft SQL Server database management system. Agency is responsible for insuring that personnel are available and free of regular duty assignments during scheduled training periods. Training will require approximately 8 hours per person. 7. All software includes a 12 month warranty from date of regularly scheduled use in the Department. This is implemented as a normal service contract, which provides unlimited telephone consulting, minor software, updates, and periodic on-site visits for remedial maintenance and follow up training and consulting. Optional service packages are available, including full facilities management with dedicated on-site systems personnel. SCHEDULE B EIS Project Payment Terms 25% Total Project Upon Contract Execution Hardware: 100% of Balance Upon Delivery Software: 100% of Balance Upon Delivery Customized Development: 100% of Balance Upon Delivery Service: 100% of Balance Upon Delivery of Service Deschutes_County_9-1-1 _Contract_2Apr 10 SCHEDULE C PS.NET/M2 PDCC ODOT Integration CAD to CAD (EIS Project Proposal and Workplan) Contractors Proposal dated September 10, 2009, named RegionalDataSharingOverview_ODOTvM2Switch.pdf is incorporated by reference into this Contract as Contract Schedule C. Deschutes_County_9-1- l_Contract_2Apr 10 PS.NET/M2 PDCC ODOT Integration CAD to CAD Project Overview September 10, 2009 The information in this document is provided for planning purposes only. The software described in this document is furnished under a license agreement or non -disclosure agreement. Executive Information Services reserves the right to change specifications without notice. Licensed users are granted permission to reproduce this manual for internal use only. Distribution to third parties is expressly prohibited. Correspondence regarding this publication should be directed to: Executive Information Services, Inc. 1396 NE 20th Ave. Suite 100 Ocala, FL 34470 Phone: 856\701-6107 FAX: 206\201-6107 Internet Mail: sales@goeis.net Copyright © 2009 Executive Information Services, Inc. All rights reserved Table of Contents Executive Information Services, Inc 1 PS.NET CAD Interface with ODOT PDCC 1 ODOT CAD Integration - Executive Summary 1 Generalized Statement of Work 3 General Considerations 4 M2 Switch Capability Overview 5 M2 Mode: Local Exchange Manager 6 M2-to-PDCC data exchange project 7 Local Data Systems (CAD): 7 M2 Regional Switch Services: 7 Web Service: 7 Existing System Upgrades: 8 Basic Network (LAN and WAN) Infrastructure: 8 M2 CAD -to -CAD Features 10 M2 Standard Messages 10 Implementation 12 Estimated Project Timeline: 12 PDCC Integration — General Overview PS.NET CAD Interface with ODOT PDCC ODOT CAD Integration - Executive Summary The impetus for this project centered on providing a real time CAD -CAD data exchange built on the existing PDCC between the current EIS 197 corridor agencies and other participating PDCC communications centers; with particular emphasis on active call exchange and agency activity status monitoring. The project is intended to include the dispatch centers serving the central Oregon public safety agencies, including those counties immediately bordering Deschutes County; Klamath County, Lake County, Jefferson County, Crook County, along with the other EIS CAD agencies covering Wheeler, Sherman, Gilliam (Tri -County Communications) and possibly the incorporation of the new dispatch centers including Hood River and Wasco County. The goal of the project is to provide an integrated mechanism within the PS.NET CAD system to support the integration to the PDCC and to provide the additional services in a manner that improves the dispatcher's environment. The project is based on establishing a connection to the State of Oregon's PDCC ESB for the purpose of real time, request based data sharing that incorporates a defined set of CAD-to-PDCC data exchanges and messaging capabilities. General transactions include; Incident information messages, Unit Information and generalized user -to - user messaging. The integration proposal provided by EIS, Inc. is based on the interface specifications provided by Online Business Systems dated September of 2007, including; 1. Message Architecture Specification V2.5 Final.doc 2. ESB -CAD Connection Specification - FINAL 09072005.doc 3. OSP_TOC_Connection_Specs_Final_550.doc 4. KeyPoints2.doc CAD Fully Configured Dispatch System VPN Over Internet PS.NET Database Server PS.NET CAD PS.NET Map Application Server Application Server General System Architecture Oregon PDCC Interface 9/10/2009 PS.NET MDC Controller PDCC Switchi M2 Server w/ PDCC interface service module Firewall Component Breakdown 1. New M2 Gateway Server (Hardware) 2. New M2 Gateway Application 3. New interface service module 4. Modifications to CAD Application Server and CAD Workstation to Support CFS Transfers Executive In n Services, Inc Page 1 1 PDCC Integration — General Overview EIS, Inc. is proposing the implementation of the base EIS M2 data switch to manage the exchange of data between the participating agency and the PDCC ESB. The M2 switch has been specifically developed to support extensible CAD to CAD communications over a variety of communication protocols and messaging formats. The M2 switch currently supports PS.NET CAD to CAD integration between the current (and future) EIS users, and can fully supports integration with the PDCC system via pluggable interface service module. The concept behind this project would be the implementation of the base M2 switch in each participating agency, appropriate upgrades to the existing agency level CAD systems to support the enhanced capabilities, along with the development of a new M2 PDCC interface service module. It is envisioned that a dedicated EIS M2 switch would be installed at each of the participating communication centers with data access controlled by the local agency. It is understood that interconnectivity between the sites and the PDCC would be provided through existing WAN communication links (if available) or via the public internet utilizing VPN connections (low cost and reasonably secure). Each agency level switch could be either connected to the PDCC directly, or routed through a PDCC gateway switch located at one of the participating EIS agency's. Once the communications have been established and configured, each dispatch center will be able to push, publish or pull information in accordance with the capabilities supported by the PDCC or based in internal agency policy. It is understood that the PDCC ESB utilizes simple xml messages with XML Soap Headers based on the IEEE 1512 standard. Standard Messages include; 1. Operator to operator messaging. 2. Request/reply messages to enable, Calls for Service with Accept/Reject replies and Request Incident List or Incident details from the partner. The CFS (call for service) message is the message that will be sent between Call Centers, carrying with it information about an incident. For the scope of this project, the data elements used in a CFS message are re -used to provide the functionality for several sub -types of messages. These message types are: CFS Transfer This is the message sent when a Call Center first decides to transfer an incident to one or more PSAPs. CFS Update The CFS Update Message is used to send additional information for a CFS that has already been transferred. The data elements are the same as the initial CFS transfer although the data sent in those elements may differ significantly. CFS Accept or Reject The response to a CFS Transfer or CFS Update will come in the form of either an Accept (receiving Call Center accepts the CFS Transfer or Update) or a Reject (receiving Call Center does not accept it). CFS Information Only When a message needs to be sent to one or more PSAPs, but the data being sent does not need to be acknowledged, or is of lower priority than a CFS Transfer, the information only sub -type can be used. Of the CFS data elements, only the Remarks element is required. A flag is used to indicate to the CAD system that there is no requirement for a user to acknowledge or reject this message Executive Information Services, i nc. Page 1 2 PDCC Integration — General Overview 3. Publish and Subscribe messages to enable partners to monitor New, Update and Close operations on partner system incidents. 4. System messages to enable heartbeat and error notification functions. Generalized Statement of Work Within this proposal we have attempted to address and summarize the base components required for the implementation of the M2 regional switching system and the specific CAD-to- PDCC transactions required to meet project objectives —and to keep these systems within budgetary limits of the available grant funding. EIS is proposing to provide the anticipated set of services, software and hardware to implement the proposed solution within the existing Oregon EIS CAD user agencies. The proposed project will include the upgrade of the existing dispatching systems, the implementation of new EIS M2 message switching technology, and the development of a PDCC specific interface (Service Module). The interface to PDCC will be developed to specifically manage communications with the State PDCC switch and will be built on the PS.NET/M2 switching platform. This will include a new transaction control service, protocol management component and web services specifically designed to support the requisite transaction to the PDCC. These components will be implemented as a standardized M2 switch component within each agency. Specific modifications will be added to the CAD workstation software, CAD Application Server to manage user interaction with the new call management/exchange features. New user commands will be added to the CAD workstations to provide the users with a set of accessible functions specific to the State Interface. Selection of these commands will initiate a related set of screens/forms/functions to allow the user to interact with the State switch functions (e.g transfer calls, accept calls, update call information, etc.). The proposed systems include the following: 1. The installation of the PS.NET/M2 switch at each of the participating agencies 2. The configuration of the M2 switch to support the standard CAD -to -CAD and CAD-to-PDCC transactions. 3. Upgrade of all existing PS.NET/CAD users to the latest release of the CAD system with the remote transaction user interface components. 4. Development of a new M2 interface service module supporting the PDCC communication and message formatting standards. 5. Server Hardware to support the new M2 Switch software (if required) 6. Installation of all systems and software by EIS engineers 7. Complete on-site training of all users of the system by EIS personnel. 8. First year 7X24, annual on-going support services included in the base cost. 9. Complete site licensing of all software. This means additional workstations can be added in the future at no additional licensing costs. The proposed software systems include the initial year of support services direct from EIS. This initial on-going support is designed to fully cover the start-up period and help insure that the systems work optimally throughout the enterprise. Executive I n fo r m ration S e ry ce s, Inc. Page 1 3 PDCC Integration — General Overview General Considerations • It is understood that the current ODCC does not yet support the dynamic addition of new partner agencies to the ESB, and that future enhancements are being developed to support expansion. Any modifications to the PDCC required to support the addition of new users/dispatch centers to the system will be the responsibility of the PDCC, including connectors, routing logic, security configurations, etc. • It is understood that at this time the connection links between the agency dispatch center and the PDCC switch have not been fully established that a The proposed interface will be developed based on the specifications provided. It is further understood that the connectivity approach selected by the State for connection into the PDCC will be a VPN connection over the public internet. As such no specific agency level architectural changes will be required. • EIS will support the communication protocol and XML message formats required by the exchanges as specified in the interface documents. EIS will develop a customized version of the endpoint being developed for ODOT in order to support the standard format required by the existing message exchanges. • No system will have access to functions in the remote CAD system. All data access is read-only and accessed through the PDCC ESB. E xer. u t i ve I n f o s Seryiceiii, Inc Page 4 PDCC Integration — General Overview M2 Switch Capability Overview M2 is an advanced, distributed message switch tailored to meet the requirements of distributed public safety systems. In effect, it acts as a "service bus" for public safety messages and can forward or relay messages across the net in a broad range of network topologies and transports. The core message switch itself is extremely high performance with automatic queuing and message caching. Pluggable outboard "processor" modules provide additional services such as printing, security, interfacing, etc. The PS.NET/M2 Switch facilitates real-time information sharing and active data exchanges among multiple agencies at local, regional, and state levels. The switch provides services far beyond simple inquiry capabilities, and fully supports active data exchange, updating and indexing. The M2 switch can support integration into all of the EIS systems application modules, spanning CAD, Records, Jail, Civil and mobile digital components. For the purposes of the central Oregon CAD project, switch functionality will be configured for CAD -CAD exchanges only, and base inquiry functionality into RMS. M2 is designed as a multi -node switch, and provides both the communications and the security functions at a site level. Specific features include; 1. Communications between nodes is bi-directional and FIPS 140-2 encrypted (on acceptable platforms). 2. Data transmission between nodes utilizes highly efficient serialized binary objects. 3. Each M2 Node performs its own localized services for connected computers. a. Logging b. Security checking for all incoming and outgoing service requests c. Interfacing services to state gateways, third party systems, etc. d. Routing and message delivery e. Paging f. Printing 4. Addressing on M2 can be discreet or "function". Functional addressing simplifies message routing across distributed systems. 5. Security can be enforced at the local level. 6. Users are authenticated at their "home" node. 7. Credentials can be passed across the network to other (agencies). 8. Each passing node (i.e. the other site) can enforced "rights" on the authenticated credentials. For example, a user is authenticated in Agency A. Agency A passes credentials, including assigned roles, to Agency B with a "query" request. Agency B has the ability to assign specific rights allowing or denying the agency A user to make the query. 9. Each node provides logging and audit functions and acts as a message level "firewall" for the local site. The M2 service transcends traditional "Middleware (n tier)" inquiry applications and provides capabilities far beyond the typical disassociated inquiry layer promoted by current third party vendors. The underlying communications technology inherent in M2 extends the data access components of the core PS.NET systems, and operates as a fully integrated interagency communications application, specifically designed to support real time data sharing at an enterprise level. M2 is a fully integrated data exchange and messaging sub -system, not simply an inquiry based middleware component that simply query's remote databases and returns raw data. Executive Information S e r v; c e s, Pa to I 5 PDCC Integration — General Overview The M2 switch can be implemented in one of two modes; as either a "Localized Exchange Manager" or as a "Centralized Exchange Switch". For the purposes of the Central Oregon Project, it is believed that the Local Exchange Manager provides the appropriate solution supporting the County and regional communications centers. M2 Mode: Local Exchange Manager The "Local Exchange Manager" approach provides a distributed communication mechanism and is the ideal solution when the participating agencies require localized control over their data, and/or if communication lines connecting the agencies are unreliable. Each subscribing agency installs the switch components (software and hardware) locally, and each agency configures their own set of business rules related to their data, and the data that can be accessed from other participating agencies. While the M2 switch provides a high level of system to system access, within this model the subscribing agency retains full control over their data, and can determine what information will be made available and to whom. Each participating agency fully controls access to their information, and the local administrative staff determines the level of data to be provided to the regional system. Regional Network Local Databases (CAD, RMS, JMS, Warrants, FI, etc) Agency Level M2 Switch Other regional M2 Switch Simple Entity Relationship Agency Level M2 Switch Other regional M2 Switch Executive Information Services , i n c . Pa Local Databases (CAD, RMS, JMS, Warrants, FI, etc) ge 6 PDCC Integration — General Overview M2-to-PDCC data exchange project Within this summary we have attempted to define a high level project scope and to detail the services required to interface the current PS.NET systems and to provide the components necessary to support the PDCC interface. The proposed upgrade, extension and enhancement of the existing systems will build upon the existing installations and provide an enterprise infrastructure that facilitates the sharing of critical information across jurisdictions. This proposed sub -system is specifically architected to meet regional information systems requirements of standard PS.NET CAD -to -CAD integration and the specific requirements associated with the CAD-to-PDCC project. The PS.NET applications capitalize on the Service Oriented Architecture (SOA) design to provide unparalleled flexibility and scalability. Within this model, local systems can be extended to support the PDCC exchanges while maintaining local system control. This architecture is built utilizing open systems standards and incorporates industry standard hardware and software. Local Data Systems (CAD): Each participating agency maintains their own locally controlled CAD system under agency control. These local systems will be connected to the PDCC through the PS.NET/M2 regional gateway server installed at each site. The M2 gateway servers act as local communication portals which provide a highly secure data sharing capability. The PS.NET M2 switch allows each site to determine what information will be made available to the remote agencies based on the specific remote request. Through the default regional communication capability and the provided PDCC interface, the partnering agencies will have the option of sharing real time data including, calls for service information, unit status, and client to client messaging between dispatching centers. M2 Regional Switch Services: Each participating agency will be configured with a local PS.NET/M2 regional switch server. The switch server deliverable will include a server class CPU and specialized PS.NET M2 application software. The M2 server(s) will provide a secure, controlled data access point into the local CAD databases, and will protect the hosting agencies and the County network from outside intrusion. The M2 gateways will be configured with the data access and data dissemination rules, and will allow the agencies to explicitly determine what information is accessible by external agencies. The M2 switch will be integrated with the agency's existing databases and message switching capabilities, and through the PDCC web service requests, effectively opens a portion of the local CAD data to be shared with participating agencies. With the implementation of the PDCC data exchange interface the participating agency's will be capable of exchanging real time CAD information between communications centers. The M2 software can be implemented on a dedicated server or added to the existing MatriX server if suitable. Incoming and outgoing data requests will be serviced by the M2 switching & queuing capabilities based on the nature of the request. Data Transactions will be routed to remote systems via M2 to M2 transactions, and returns will be collated and transmitted to the user as they are received by the system. Web Service: M2 was specifically designed to support pluggable interfacing service modules at any node to perform translations for third party systems. As such a flexible system footprint is established, and EIS can easily "customize" these system nodes to support integration with any third party system, such as the Oregon PDCC. The interface service modules Executive Inforrer;Servces, 17 PDCC Integration — General Overview can support a wide variety of communication/transaction protocols, including; WEB services, IP sockets, message queues, file transfers, etc. The selection of the appropriate interface service module would be based on the preferences of the participating vendors. Utilizing the pluggable interface service module EIS will develop the interface in accordance with the published PDCC interface specifications and provide a common, standardized message transaction based service to support the common set of CAD transactions. Since the interface supports bi-lateral communications, the system will support transaction management capabilities within the core interface. In support of the CAD transaction EIS prefers providing the interface as either a socket based interface or via a standardized web services. The Web service approach establishes a flexible, standardized data interface that is vendor neutral and capable of supporting requests from any authorized external system. The basis of web services is to be able to publish system data utilizing a uniform communication mechanism that is fully platform independent, therefore creating a common interface capable of exchanging data between different applications and different platforms. The web service interface is based on the standard Web services platform utilizing XML data formats over a HTTP communication protocol. XML provides a language which can be used between different platforms and programming languages and still express complex messages and functions. The standard Web services platform includes SOAP (Simple Object Access Protocol), UDDI (Universal Description, Discovery and Integration) and WSDL (Web Services Description Language) Existing System Upgrades: The project includes the upgrade of existing system components, the installation of new system capabilities, and the configuration of the M2 regional gateways. The system will be configured in such a manner that its operations are consistent with both the local data policy and PDCC operating protocol. Operational CAD information will be shared in real-time and incorporate the current situational information shared between related Communications Centers as described in the PDCC message formats. Within the project, EIS will upgrade the existing PS.NET CAD applications currently utilized by the agency to the latest release of application software. The upgrades will ensure that the agency will be operating a version of the software that is capable of supporting the regional exchange functions and the specific commands related to the PDCC project. All agencies will receive upgraded CAD software, and for those agencies not currently utilizing the AM CAD components, EIS will upgrade the existing CAD system to the new Phase II AM CAD application capable of integrating with the regional information system. The upgrades will include the standard enhancements to the existing E-9-1-1 compliant GIS CAD. EIS will include the required installation and training services as required in the context of this pricing proposal. EIS will include costs associated with anticipated hardware, computer operating systems and database licensing required to support the upgrades. Basic Network (LAN and WAN) Infrastructure: The applications utilize industry standard computing platforms and can be installed on a broad range of hardware and network topologies to provide highly efficient, low cost systems for smaller agencies and can scale to support fault tolerant clustered configurations capable of servicing the largest agencies. The basic architecture can be implemented to minimize system faults and can fully support Exec u t i v e I r f c, r rn a t i u n S e rvices, Inc. Pa PDCC Integration — General Overview distributed operations in multi-user and regional systems. This allows regional systems to share information without giving up local, operational and budgetary control. The proposed system is capable of operating on the site's existing networks and can support most Wide Area Network (WAN) communications topologies. This helps protect the investment in existing systems and provides a common platform and operational environment that will server to further improve productivity minimize training time, and lower initial and ongoing system costs. Executive Information Services will provide a full range of implementation services designed to optimize these applications and minimize the problems associated with major technological changes. These services include: Pre -installation consulting Full system implementation User training Post installation consulting and start up support Executive inforrns,t€ian Services inc, Pare ( 9 PDCC Integration — General Overview M2 CAD -to -CAD Features Real Time CAD to CAD/PDCC Integration: Through the M2 switch participating agency's can access, transfer, collaborate and monitor active events in neighboring dispatching centers. These capabilities will greatly improve inter -center dispatching communications and greatly enhance those events that require multi -center cooperation. With the addition of the M2 sub -system, the PS.NET/CAD has been expressly designed to facilitate regional operations and to integrate better with regional mobile data systems. In addition to user interface and other functionality changes, the system provides the following regional capabilities. a) Allows interconnection to other CAD systems with real time data exchanges. b) Allows any connected CAD system to monitor the status of resources and events on other active CAD systems. c) Allows any connected CAD system to generate events and route them to alternate systems for handling d) Allows auto or manual generation of shared events such as auto and mutual aid calls. Dispatch & Communications Agency Level M2 Switch Agency 1. Dispatcher can access status monitor and active call information from any other M2 supported CAD system. Agency's can transfer active events to neighboring agency for dispatch and management on command. Agency #1 ESB s; Simple Entity Relationship 2/12/2009 ) M2 Regional Information Exchange Agency #2 Agency 2. Dispatcher can accept call transfer and assume responsibility for the call. Agency Level M2 Switch Dispatch & Communications Local Databases (CAD, RMS, JMS, Warrants, FI, etc) Existing PDCC Server Base M2 Standard Messages 1. Operator to operator messaging. Provides a non -call related textural messaging capability between dispatchers. Supports person-to-person and person -to -group communication capabilities, dependant on the routing capabilities of the PDCC. Does not track receipt of message, and there is no requirement for a user to acknowledge or reject this message. Executive Information Services, Inc. Page 1 10 PDCC Integration — General Overview 2. Calls For Service (CFS). The basic call information request that will be sent between Call Centers, carrying with it information about an incident. Provides a detail overview of the active call, including; call details, geo information, names, vehicles, premise information and all unit activity associated with the event. Calls for service detail record can be pushed or pulled in association with specific transaction requests depending on the localized settings. Request/reply messages to enable, Calls for Service with Accept/Reject replies and Request Incident List or Incident details from the partner. CFS Transfer This is the message sent when a Call Center first decides to transfer an incident to one or more PSAPs. Provides a mechanism for the controlling agency to duplicate an active call and send call information to another PSAP. Used primarily if a multi- agency/jurisdictional response is required or a cross boundaries response is required. The transfer function will generate a new call for service at the receiving communications center, and will keep the originating call active within the originating center. The receiving agency must acknowledge acceptance of the call for the transfer to be completed. CFS Update The CFS Update Message is used to send additional information for a CFS that has already been transferred. The data elements are the same as the initial CFS transfer although the data sent in those elements may differ significantly. The Call For Service Update Message is used to send additional information in the form of time stamped comments for a CFS that has already been transferred and accepted. Depending on operational policy, the update message receiving process may be configured differently between agencies. CFS Accept or Reject The universal communications acknowledgement between dispatchers for any transaction requiring user acceptance. The response to a CFS Transfer or CFS Update will come in the form of either an Accept (receiving Call Center accepts the CFS Transfer or Update) or a Reject (receiving Call Center does not accept it). CFS Information Only When a message needs to be sent to one or more PSAPs, but the data being sent does not need to be acknowledged, or is of lower priority than a CFS Transfer, the information only sub -type can be used. Of the CFS data elements, only the Remarks element is required. A flag is used to indicate to the CAD system that there is no requirement for a user to acknowledge or reject this message 3. Publish and Subscribe messages to enable partners to monitor New, Update and Close operations on partner system incidents. 4. System messages to enable heartbeat and error notification functions. x e c u t i v e Information Services, Inc. Page I 11 PDCC Integration — General Overview Implementation Estimated Project Timeline: The estimated implementation timeline would be based on the specific needs of each of the participating EIS agencies along with the availability of the PDCC ESB to support the connection. Each existing agency would require upgrades to both the application software and underlying database to support the M2 exchanges. As such, EIS project staff will evaluate the current PS.NET deployment at each agency to specifically identify the required upgrade tasks and will develop with the agency an upgrade implementation plan. This plan will be specific for each agency and will be tailored to minimize disruption to daily operations. Due to the modular nature of the system upgrades, EIS can utilize a phased approach whereas the M2 Switch is installed and the basic agency CAD system is prior to implementing the PDCC interface module. It is anticipated that the completed installation will be achieved between 6-12 months from contract inception. The general process is as follows; Project Start — Issuance of award and Purchase Order to Executive Information Services, Inc. Within 60 days following the receipt of Agency Purchase Order, EIS will prepare the required resources to begin the implementation process. Following the 60 day period the proposed implementation timeline will proceed generally as follows. General Task 1: Project Coordination and Organization. Kick-off Meeting with all involved parties from the regional agencies to review the project goals and implementation plan. Discussion of overall project, project elements and project needs assessment. Meeting addresses the overall objectives of the regional project, defines the basic implementation approach, and identifies the project management structure. General Task 2: Functional Needs Assessment. Project needs assessment and goal development. The end results would include a detailed outline and implementation action plan for the regional system. The involved parties would develop a specific hardware list and purchase responsibilities (meaning who needs to purchase what equipment). This would be a collaborative effort performed by the involved agencies and EIS installation staff. General Task 3: Development of the M2 interface service module for PDCC. Develop, Test and document the application software module supporting the interface and transaction management to the Oregon State PDCC based on the referenced data standards. General Task 4: Agency Upgrade planning. Agency level project needs assessment and goal development (current customer). EIS project group reviews the current installation, configuration and hardware available within each current PS.NET client agency. The end results would include a detailed outline and implementation action plan for the upgrade of the existing installation to conform to the requirements of the regional system. The involved parties would develop a specific hardware list and purchase responsibilities (meaning who needs to purchase what equipment). This would be a collaborative effort performed by the involved agency and EIS installation staff. General Task 5: Upgrade Installation and Delivery. Provide on-site services pursuant to the implementation plan to upgrade the existing PS.NET systems in use throughout the region to support the M2 system. Including the latest release application software, database reconfiguration services, data migration, CAD upgrades to support GIS compliant CAD, RMS interfacing with Regional system. General Regional Query would be deployed at this time. Executive Intc r rn a ti un S e ry Inc Page ( 1 2 PDCC Integration — General Overview General Task 6: Installation and Delivery of the M2 interface service module. Provide on-site services pursuant to the implementation plan to upgrade the existing PS.NET systems in use throughout the region to support the M2 system. Including General Task 7: Acceptance and Testing. Completes system deployment, certifies system as ready for use and transitions into Warranty period for new systems and equipment. New components incorporated into On-going Maintenance Contract with the participating agencies. *Time line is subject to discussion, review and further development, as are the elements offered in this proposal. Executive I sto rm ti o n S e rvices, i n c. P e. I 13 SCHEDULE D ODOT to OSP Connection Specification ODOT's publishes interface specification dated 9/26/2007, named OSP_TOC_Connection_Specs_Final_550.doc and prepared by Online Business Systems, Inc. is incorporated by reference into this Contract as Contract Schedule D. Deschutes_County_9-1-1_Contract 2Apr10 nsne BUSINESS SYSTEMS Oregon Department of Transpo P 50 ODOT to OSP Connection Specification All systems go Prepared for: Oregon Department of Transportation Prepared by: Online Business Systems One World Trade Center, 121 Salmon Street S.W. 11th Floor, Portland, Oregon 97204 9/26/2007 11:18:00 AM, Online Business Systems , Deleted: 5/2512007 8:50:00 AM TABLE OF CONTENTS 1.0 Introduction 6 1.1 Abstract 6 1.2 Revision History 6 1.3 Related Documents 6 2.0 Application Architecture 2.1 Business Processes to Message Set Cross Reference 2.1.1 Get List of Online Operators 2.1.2 Operator to Operator Messaging 2.1.3 Manage Events 2.1.4 Synchronize External Events 2.1.5 Send and Receive Event from External Agency 2.1.6 Monitor External Events 2.1.7 Heartbeat 2.1.8 Get List of Valid Endpoints 2.2 Operator to Operator Messaging 2.2.1 Scenario: Get List of Online OSP Operators 2.2.2 Narrative 2.2.3 Scenario: Get List of Online TOCS Operators 2.2.4 Narrative 2.2.5 Scenario: Operator to Operator Messaging 2.2.6 Narrative 2.3 Manage Events 2.3.1 Scenario: TOCS Publishes Event 2.3.2 Narrative 2.3.3 Scenario: OSP Publishes Event 2.3.4 Narrative 2.4 Synchronize External Events 2.4.1 Scenario: TOCS Updates a Shared Event 2.4.2 Scenario: OSP Updates a Shared Event 2.4.3 Narrative 2.5 Send and Receive Events from External Agency 2.5.1 Scenario: Receive Event for External Agency 2.5.2 Narrative 2.5.3 Scenario: Send Event to an External Agency 2.5.4 Narrative 2.6 Monitor External Events 2.6.1 Scenario: Request All Open Events 2.6.2 Narrative 7 7 7 7 7 8 8 8 9 9 9 9 9 10 10 11 11 12 13 13 14 14 14 15 16 16 17 17 18 18 19 19 20 20 ODOT-OSP Connection Specification Online BUSINESS SYSTEMS 2.6.3 Scenario: Request Incident Details 21 2.7 Get List of Valid Endpoints 21 2.7.1 Scenario: TOCS Requests List of Valid Endpoints 21 2.7.2 Narrative 22 2.7.3 Scenario: OSP Requests List of Valid Endpoints 22 2.7.4 Narrative 22 2.8 Heartbeat 23 2.8.1 Scenario: TOCS Heartbeat to OSP 23 2.8.2 Narrative 23 2.8.3 Scenario: OSP Heartbeat to TOCS 24 2.8.4 Narrative 24 2.9 Request and Grant Handoff 24 2.9.1 Scenario: TOCS Request Handoff to OSP 24 2.9.2 Narrative 25 2.9.3 Scenario: OSP Request Handoff to TOCS 25 2.9.4 Narrative 26 2.10 Alternate Paths 26 2.10.1 Scenario: Endpoint cannot connect to ESB 26 2.10.2 Narrative 27 2.10.3 Scenario: Endpoint does not receive acknowledgment from the ESB 27 2.10.4 Narrative 27 2.10.5 Endpoint does not receive expected 1512 response message 28 2.10.6 Narrative 28 3.0 Message Architecture 29 3.1 Message Sets 29 3.1.1 Close Incident Event (CIE) 29 3.1.2 Grant Handoff (GHO) 29 3.1.3 Incident Description (IDX) 29 3.1.4 New Incident Event (NIE) 29 3.1.5 Request Handoff (RHO) 30 3.1.6 Merge Incident Event (MIE) 30 3.1.7 Request Information (RIN) 30 3.2 Message Patterns 30 3.2.1 Request 30 3.2.2 Response 30 3.2.3 Broadcast Message 30 3.2.4 Acknowledgement 30 3.2.5 Fault 31 4.0 Technical Architecture 32 4.1 Assumptions 32 4.2 Requirements 33 4.2.1 Business Requirements 33 4.3 Technical Requirements 34 4.4 Service Architecture 35 4.4.1 Service Components 35 4.5 Communication Between Components 36 4.5.1 Public Interfaces 37 ODOT-OSP Connection Specification ii Online OUSINES5 SYSTEMS 4.5.2 Expected WSDL Definitions 37 4.5.3 Distributing WSDL Files 38 4.5.4 SOAP 38 4.5.5 Canonical Messages as SOAP Payload 39 4.6 Endpoint Architecture 39 4.6.1 Static Model 40 4.6.2 Narrative 40 4.6.3 Sequence: TOCS connects to endpoints WS and posts a message 42 4.6.4 Narrative 43 4.6.5 Sequence: TOCS messages processing by TocsMessageManager 43 4.6.6 Narrative 44 4.6.7 Sequence: ESB connects to endpoints WS and posts a message for TOCS 44 4.6.8 Narrative 45 4.6.9 Sequence: ESB messages processing by EsbMessageManager 45 4.6.10 Narrative 46 4.6.11 Sequence: MessageTracker Initialization Process 46 4.6.12 Narrative 47 4.6.13 Sequence: MessageTracker Shutdown Process 47 4.6.14 Narrative 47 4.6.15 Sequence: No ACK received within specified timeout 48 4.6.16 Narrative 48 4.6.17 Message Request/Response Tracking 48 4.7 Enterprise Service Bus Architecture 49 4.7.1 ESB Components 49 4.7.2 Narrative 49 4.7.3 Get Endpoints Service Interface 50 4.8 Quality of Service 51 4.9 Logging 51 4.9.1 TOCS Endpoint Logging 52 4.9.2 ESB Audit Logging 53 4.9.3 Notification & Error Handling 53 4.10 Security 54 4.10.1 Secure Socket Layer (SSL) 54 4.10.2 System Authentication 54 4.10.3 User Authentication 54 4.10.4 Payload Encryption 54 4.10.5 Quality of Trust 55 5.0 Software Development environment 56 5.1 Microsoft .Net 56 5.2 Development Standards 56 5.2.1 Coding Standards 56 5.2.2 Unit Testing Standards 56 5.3 Development Tools 57 6.0 Technical Environment 58 6.1 Application Server 58 6.2 Physical Configuration 58 6.3 Network 58 ODOT-OSP Connection Specification iii Online CUSIIJESS SYSTCMS 6.4 Operating Standards and Procedures 58 7.0 Traceability 60 7.1 Assumptions 60 7.2 Decision Points 61 7.3 Business Requirements 61 7.4 Technical Requirements 63 8.0 Terminology 66 9.0 Appendix A: ODOT to OSP Security Implementation 68 10.0 Appendix B: Enterprise Logging Library 76 10.1 Introduction 76 10.2 Overview 76 10.3 TraceListeners 77 10.4 Original Method 77 10.5 Enterprise Library Application Blocks 78 10.6 Using the Exception Handling & Logging Block 79 11.0 Appendix C: Adding New Partners 82 11.1 Purpose 82 11.2 Overview 82 12.0 Appendix D: Unit Task Cross Reference 83 ODOT-OSP Connection Specification iv Online 8USINGS': SYSTE Confidentiality Statement On!in se Businessvea ueof o Systemsregon Departmenthasprepared this of Transportation.,se proposalconsubmissiontntsmay This n fodt° r.ee tproposal heopis emee s e .11 e sPubrP tsteandhe .a a strictlywritten euCONFIDENTIAL basis' Thi.s 1.)r°°s°1orduals or tused for ' ur Use s iuoclutistclosed orr divulge to a other parties ,v1 ODOT-OSP Connection Specification v Online BUSINESS SYSTEMS INTRODUCTION 1.1 Abstract The Purpose of this document is to describe the requirements for the connection between the ODOT TOCS system and the OSP PSSI CAD system. 1.2 Revision History Version. Descri''tion Initial Release Materiall Com'&tete Draft 1.0 2.0 1.3 Related Documents TOCS_Phase 1 Connectivity_V1 IGS -OSP Exhibit A TOCS 1, Business Analysis and Requirements IEEE -1512, Standard 'for Incident Management Message sets for use by. Emergency Management Centers, draft rev 3/3/05 ".tion The ODOT-TOCS Statement of Work ODOT/OSP System Requirements for the TOCS Integration project. This document will be itemized and extended. The ODOT design and requirements document for the TOCS application. The current draft version of the IEEE -1512 specification, which defines the structure of, the messages in this document. ODOT-OSP Connection Specification 6 Online BUSINESS SYSTEMS APPLICATION ARCHITECTURE The following Scenarios define the business scope for this project and are required to be supported by the ESB, the custom end points, and the CAD systems. It is not the intent of this section to dictate operational details of the overall system beyond identifying the integration business scenarios that are required to be supported by ODOT and OSP. Assumption Description AS01 While it is expected that integration with other agencies will happen in the future, the first agency ODOT is integrating with is OSP. The ODOT to OSP integration is the only integration in scope for this project. IEEE Standard 1512 Compliance The Message Sets discussed in these Business Processes will conform to the IEEE 1512 DRAFT Version of the P1512 (Combined Volumes) IEEE Standard for Common Incident Management Message Sets for Use by Emergency Management Centers - Working draft (vol 1,2,3,4) revision # 44 dated 10/27/2006, with local extension used whenever required. The Message Sets described in the following sections conform to named Message Sets within the IEEE Standard 1512 specification. 2.1 Business Processes to Message Set Cross Reference See Section 3.2 for a description of the message sets listed here. 2.1.1 Get List of Online Operators Get List of Online Operators uses the following message sets: • Request Information (RIN) • Incident Description (IDX) 2.1.2 Operator to Operator Messaging Operator to Operator Messaging uses the following message sets: • Incident Description (IDX) 2.1.3 Manage Events Manage Events uses the following message sets: ODOT-OSP Connection Specification 7 Online sr • New Incident Event (NIE) • Update Incident Event (custom message)(UIE) • Incident Description (IDX) for a summary of an event • Incident Description (IDX) for the complete detail of an event. • Grant Handoff (GHO) if the event meets the OSP auto create criteria. 2.1.4 Synchronize External Events Cross-referenced events are updated between ODOT and OSP with the following messages: • Update Incident Event (custom message) (UIE) With Incident Description summary • Merge Incident Event (MIE) With Incident Description summary • Close Incident Event (CIE) With Incident Description full details. • Request Information (RIN) — If an event meets the OSP auto create criteria, OSP will send a request for the complete event record. • Incident Description (IDX) — complete incident record • Grant Handoff (GHO) — If an event meets the OSP auto create criteria, OSP will send a Grant Handoff message acknowledging the creation of the event in the OSP CAD system. • New Incident Event (NIE) With Incident Description summary 2.1.5 Send and Receive Event from External Agency Send and Receive Event from External Agency uses the following message sets: • Request Handoff (RHO) • Grant Handoff (GHO) • Incident Description (IDX) — complete incident record 2.1.6 Monitor External Events Monitor External Events uses the following message sets: • Request Information (RIN) • Incident Description (IDX) • Grant Handoff (GHO) • New Incident Event (NIE) ODOT-OSP Connection Specification 8 <7771e BUSINESS SYSTEMS Comment (RWB1j : Replaces Request All Open Events 2.1.7 Heartbeat The Heartbeat Message uses the following message sets: • Request Information (RIN) • Incident Description (IDX) 2.1.8 Get List of Valid Endpoints Get List of Valid Endpoints uses the following message sets: • Request Information (RIN) • Incident Description (IDX) with a list of addresses 2.2 Operator to Operator Messaging This business process implements the following TOCS Unit task: UT 900.04 Screen to Screen Messaging 2.2.1 Scenario: Get List of Online OSP Operators TOCS TOCS Endpoint E$3 OSP Request Information (RIN) Request Information (RIN) Request Information (RIN) > 1> - T- ACK IncidIncident ent Description (IDX) Incident Description (IDX) Incident Description (IDX) ACK 2.2.2 Narrative 1. TOCS sends a Request Information message to the TOCS Endpoint via web services. The Request Information message has been extended to request online operators. 2. The TOCS Endpoint forwards the message to the ESB via web services. ODOT-OSP Connection Specification 9 Online BUSINESS SYSTEMS 3. The ESB acknowledges receipt of the message by sending a message via web services to the TOCS Endpoint. 4. The ESB routes the message to the appropriate ESB web service endpoint for OSP. 5. OSP receives the message and creates a list of OSP operators currently online. 6. OSP send an Incident Description message, containing the list of operators, to the ESB via web services. 7. The ESB acknowledges receipt of the message by sending a message via web services to OSP. 8. The ESB routes the message to the appropriate ESB web service endpoint for the TOCS Endpoint. 9. The TOCS Endpoint routes the message to TOCS. 2.2.3 Scenario: Get List of Online TOCS Operators OSP ESB TOCS Endpoint TOCS Request Information (RIN) i Request Information (RIN) 1 Request Information (RIN) > >1 >1 ACK Incident Description (IDX) ( 2.2.4 Narrative Incident Description (IDX) i Incident Description (IDX) ACK 1. OSP sends a Request Information message to the ESB via web services. The Request Information message has been extended to include a request for online operators. 2. The ESB acknowledges receipt of the message by sending a message via web services to OSP. 3. The ESB routes the message to the appropriate web service end point for the TOCS Endpoint. ODOT-OSP Connection Specification 10 Online CUSIIFCSS SYSTEMS 4. The TOCS Endpoint sends the message to TOCS via web services. 5. TOCS receives the message and creates a list of TOCS operators currently online. 6. TOCS sends an Incident Description message, containing the list of operators, to the TOCS Endpoint via web services. 7. The TOCS Endpoint sends the Incident Description message to the ESB via web services. 8. The ESB acknowledges receipt of the message by sending a message via web services to the TOCS Endpoint. 9. The ESB routes the message to the appropriate ESB web service endpoint for OSP. 2.2.5 Scenario: Operator to Operator Messaging The ODOT TOCS Operators communicate with each other and with OSP Operators via a form of instant messaging. Messages are exchanged between operators currently online and can be sent to one or more operators or to all operators system -wide. Messages can be sent to operators at external systems, as well. TOCS TOCS Endpoint ESB OSP Incident Description (IDX) i Incident Description (IDX) 1 Incident Description (IDX) ACK Incident Description (IDX) Incident Description (IDX) m Incident Description (IDX) ACK 2.2.6 Narrative 1. A TOCS operator composes a message to another operator. 2. TOCS sends the message to the TOCS Endpoint via web services. 3. The TOCS Endpoint sends the message to the ESB via web services. 4. The ESB acknowledges receipt of the message by sending a message via web services to the TOCS Endpoint. 5. The ESP routes the message to the appropriate ESB web service endpoint. ODOT-OSP Connection Specification 11 Online BUSINESS SYSTEMS 6. OSP receives the message and displays it for the receiving operator. 7. If the addressee is no longer logged in to the receiving system, the receiving system, identified as 'System', sends a message to the sender with notification that the addressee is no longer online. 8. The sender has the option of sending messages to other operators or cancel the operation. 2.3 Manage Events The Manage Events business process includes the following unit tasks: • UT 1210.02 Enter Event (If created as active or pending) • UT 1210.04 Create Event (If created as active or pending) • UT 1210.02 Update Event (If update from potential or planned status to active or pending status) • UT 1210.05 Re -open Event (If re -open to active or pending status) This is a Publish and Subscribe pattern. The Manage Events scenario occurs on an ongoing basis. As events are created as 'pending' or 'active', updated from `inactive' or `closed' to an 'active' status, or copied from existing events in TOCS or PSSI CAD, the event is sent to the ESB for broadcast to the other agency. No response is expected from the external agencies, this is a broadcast message only. If an event meets the auto -create filter criteria for the receiving system, the receiving system can sent a Request for Information message to the sending system to request event details. In the case of OSP, if an event message meets the auto create criteria, a Grant Handoff message is sent to ODOT, accepting the event, when the event is moved into a `pending' or `active's status in the OSP CAD system. The reason for this is because the OSP CAD system cannot distinguish between an automatically created event or a Call For Service event. Assumption Description AS02 When an event is opened or changed to `pending' or `active'_ status in TOCS, the event is sent to the ESB. AS03. When an event is opened or changed to 'pending' or `active` status in PSSI CAD, the event is sent to the ESB. ASO4 While this document suggests that "all open events" will be exchanged between agencies - we assume that ODOT will reach agreement with all participating agencies that may result in the filtering of events at the end point. It is the responsibility of the end- point CAD systems to provide - or not provide - the agreed to events. Business rules to filter events will NOT occur on the ESB. ODOT-OSP Connection Specification 12 Online BUSINESS SYSTEMS Assumption Description` ODOT and OSP:willhave an agreement of event what. constitutes ,a changed• 2.3.1 Scenario: TOGS Publishes Event TOCS TOCS Endpoint New Incident Event (NIE) ESB New Incident Event (NIE) OSP New Incident Event (N E) {O }Close Incident Event (CIE) ACK Close Incident Event (CIE) {OR} :Update Incident Event (UIE) ACK Update Incident Event (UIE) ACK Close Incident Event (CIE) Update Incident Event (UIE) 1 2.3.2 Narrative 1. An event is opened, updated, or closed in TOCS. 2. If the event is new, TOCS sends a New Incident Event message to the TOCS Endpoint via web services. If the event is closed, TOCS sends a Close Incident Event message to the TOCS Endpoint via web services. If the event is updated, TOCS sends a Update Incident Event message to the TOCS Endpoint via web services. 3. The TOCS Endpoint sends the message to the ESB via web services. 4. The ESB acknowledges receipt of the message by sending a message via web services to the TOCS Endpoint. 5. The ESB routes the message to the appropriate web service endpoints. 6. The ESB sends the message to OSP. ODOT-OSP Connection Specification 13 Online cUS N SS SYSTEMS 7. If the new or updated incident summary matches the OSP auto create criteria, OSP will request additional details regarding the incident as discussed in the Request Incident Details scenario. 2.3.3 Scenario: OSP Publishes Event OSP ESB New Incident Event (NIE) {OR} < ACK Close Incident Event (CIE) ACK > {OR} Update Incident Event (UIE) ACK > TOCS Endpoint TOCS New Incident Event (NIE) i New Incident Event NIE) >1 >1 T Close Incident Event (CIE) Close Incident Event (CIE) > Update Incident Event (UIE) > T Update Incident Event (UIE) > 2.3.4 Narrative 1. An event is opened, updated, or closed in OSP. 2. If the event is new, OSP sends a New Incident Event message to the ESB via web services. If the event is closed, OSP sends a Close Incident Event message to the ESB via web services. If the event is updated, OSP sends an Update Incident Event message to the ESB via web services. 3. The ESB acknowledges receipt of the message by sending a message via web services to OSP. 4. The ESB routes the message to the appropriate web service endpoints for the TOCS Endpoint. 5. The TOCS Endpoint sends the message to TOCS via web services. 6. if the new or updated incident summary matches the TOCS auto create criteria, TOCS will send a request for incident details as discussed in the Request Incident Details scenario. 2.4 Synchronize External Events The Synchronize External Events business scenario includes the following unit tasks: ODOT-OSP Connection Specification 14 Online BUSINESS SYSTEMS • UT 1230.02 Update Event - if active or pending status • UT 1230.05 Relate Event - if active or pending status • UT 1230.08 Combine Events- if active or pending status • UT 1230.03 Close Events-- if active or pending status • UT 1240.05 Synchronize Shared Events This business scenario represents the expected behavior when ODOT and OSP have events in their system that cross-references events in the other agency's system. For example, a new event is entered into the OSP CAD system, that event is broadcast to TOCS according to Section 2.3, Manage Events. If ODOT has determined that the external event requires an event be created in TOCS, either automatically or through monitoring of external events, the OSP event id will be cross- referenced with the TOCS event and the two events will be considered shared. 2.4.1 Scenario: TOCS Updates a Shared Event TOCS TOCS Endpoint ESB 'Update Incident Event (UIE)' Update Incident Event (UIE) OSP Update Incident Event (UIE) {OR} ;Update Incident Event (UIE) ACK Update Incident Event (UIE) Grant Handoff (GHO) New Incident Event (NIE) Grant Handoff (GHO) < New Incident Event (NIE) {O�} ' Close Incident Event (CIE) Close Incident Event (CIE) {OR} ;Merge Incident Event (MIE) ACK Merge Incident Event (MIE) ACK Narrative Update Incident Event (UIE) Grant Handoff (GHO) ACK New Incident Event (NIE) ACK Close Incident Event (CIE) Merge Incident Event (MIE) 1. A shared event is updated or closed, or two or more shared events are merged into a single event, in TOCS. ODOT-OSP Connection Specification 15 Online OUSINCSS SYSTEMS r 2. If the event is updated, TOCS sends an Update Incident Event message to the TOCS Endpoint via web services. If two or more events are merged, TOCS sends a Merge Incident Event message to the TOCS Endpoint. The Merge Incident contains the cross-referenced (pedigree) list to identify the merged incidents and also identifies the incident that has become the active incident. If the event is closed, TOCS sends a Close Incident Event message to the TOCS Endpoint. 3. The TOCS Endpoint sends the message to the ESB via web services. 4. The ESB sends a message to the TOCS Endpoint, acknowledging receipt of the message. 5. The ESB sends the message to OSP via web services. 6. If the Update Incident Event message sent to OSP meets OSPs auto -create criteria, OSP sends a Grant Handoff message and a New Incident Event message to the ESB via web services. 7. The ESB sends a message to OSP via web services acknowledging receipt of the messages. 8. The ESB sends the Grant Handoff message and the New Incident Event message to the TOCS Endpoint via web services. 9. The TOCS Endpoint sends the Grant Handoff and the New Incident Event message to TOCS via web services. 2.4.2 Scenario: OSP Updates a Shared Event OSP ;< {OR} Eat TOCS Endpoint TOCS Merge Incident Event (MIE) 1 Merge Incident Event (MIE) i Merge Incident Event (MIE) >1 >1 ACK Close Incident Event (CIE) ACK {OR} Update Incident Event (UIE) ACK 2.4.3 Narrative Close Incident Event (CIE) Close Incident Event (CIE) Update lncident Event (UIE) Update Incident Event (UIE) ODOT-OSP Connection Specification 16 pnline BUSU2ESS SYSTEMS 1. A shared event is updated or closed, or two or more shared events are merged into a single event, in the OSP CAD system. 2. If the event is updated, OSP sends an Update Incident Event message to the ESB via web services. If two or more events are merged into a single event, OSP send a Merge Incident Event message to the ESB via web services. The Merge Incident contains the cross-referenced (pedigree) list to identify the merged incidents and also identifies the incident that has become the active incident. If an event is closed, OSP sends a Close Incident Event message to the ESB via web services. 3. The ESB sends an acknowledgement message to OSP via web services. 4. The ESB sends the message to the TOCS Endpoint via web services. 5. The TOCS Endpoint sends the message to TOCS via web services. 2.5 Send and Receive Events from External Agency This business process includes the following Unit Tasks: • UT 1230.07 Redirect an Event: an event is sent to the external partner for hand-off. The event is closed in the TOCS system with a disposition code of 11 -"Refer to another agency" • UT 1240.04 Send Event to External Agency: This is a Call for Service which creates a relationship between the sending and receiving agency events which is tracked by means of cross- referenced event ID's. • UT 1240.03 Receive Event from External Agency: An event is received as a call for service (or redirection) from a partner agency. This is a Request and Reply pattern. The Send and Receive Event from External Agency scenario occurs when OSP sends a message specifically addressed to the ODOT TOCS or ODOT sends a message specifically addressed to OSP. This particular flow is the most unique in terms of business rules which apply to the reply message. Current agency and OSP plans are for the reply (Grant Hand-off) message to be sent after an operator has reviewed the Request Hand-off event/incident record. This means that the time-out rules are specific to this type of message. 2.5.1 Scenario: Receive Event for External Agency ODOT-OSP Connection Specification 17 Online UUSIP SS SYST[MS OSP ESB TOCSEndooint TOCS Request Handoff (RHO) 1 Request Handoff (RHO) i Request Handoff (RHO) it >I it ACK Grant Handoff (GHO) Grant Handoff (GI -10) ` Grant Handoff (GHO) 2.5.2 Narrative 1. OSP identifies an event it wishes to send to ODOT. 2. OSP sends a Request Handoff Message (RHO) to the ESB via web services. The Request Handoff Message has been extended to hold the Incident Description (IDX) message and sub - messages that pertain to the event or events that OSP wishes to hand off. 3. The ESB acknowledges receipt of the Request Handoff Message by sending a message via web services to OSP. 4. The ESB routes the message to the appropriate ESB web service endpoint for the TOCS Endpoint. 5. The TOCS Endpoint sends the message to TOCS via web services. 6. TOCS receives the Request Handoff Message and sends a Grant Handoff Message (GHO) to the TOCS Endpoint via web services. 7. The TOCS Endpoint sends the Grant Handoff Message (GHO) to the ESB via web services. 8. The ESB acknowledges receipt of the Grant Handoff Message by sending a message via web services to the TOCS Endpoint. 9. The ESB routes the message to the appropriate ESB web service endpoint for OSP. 10. OSP receives the Grant Handoff Message and processes it according to internal business rules. 2.5.3 Scenario: Send Event to an External Agency ODOT-OSP Connection Specification 18 Online BUSIUESS SYSTEMS TOCS TOCS Endpoint ESB OSP Request Handoff (RHO) Request Handoff (RHO) Request Handoff (RHO) >1 ACK Grant Handoff (GHO)i < Grant Handoff (GHO) Grant Handoff (GHO) ACK 2.5.4 Narrative 1. ODOT identifies an event it wishes to send to OSP. 2. TOCS sends a Request Handoff Message (RHO) to the TOCS Endpoint via web services 3. The TOCS Endpoint sends the message to the ESB via web services. 4. The ESB sends an acknowledgement message to the TOCS Endpoint via web services. 5. The ESB routes the message to the appropriate endpoint for OSP. The ESB sends the message to OSB via web services. 6. OSP receives the Request Handoff Message (RHO). 7. An OSP operator determines the best course of action regarding the event and either accepts or rejects the requested handoff. 8. OSP sends the Grant Handoff Message (GHO) to the ESB via web services. The message will have a status of accepted or rejected based on the operator's decision. 9. The ESB sends an acknowledgment message to OSP for receipt of the Grant Handoff Message (GHO). 10. The ESB sends the message to the TOCS Endpoint via web services. 11. The TOCS Endpoint sends the message to TOCS. 2.6 Monitor External Events This business process includes the following unit tasks: • UT 1240.02 Monitor External Events: Allows operators to view pending and active events in the external system. Note: closed and partial/potential events are not available for external access. ODOT-OSP Connection Specification 19 Online OUSI NESS SYSTEMS • UT 1240.01 Create Event from External Event: When an operator views an external event they have the option to create a TOCS event based on the external event data. • UT 1210.01 Create Event Automatically: When events are received as New or Updated events from the external partner and match business rules in the TOCS a Request for the full incident description is made and when received it is used to automatically create an event in TOCS that is based on the external event data. This is a Request and Reply pattern. The Request All Open Events scenario represents a request for event data from one endpoint to the other. The typical exchange of event information to/from ODOT/TOCS is supported by the Monitor External Events business scenario. 2.6.1 Scenario: Request All Open Events This is done when the operator wishes to view the external agency's external events. A batch of event summaries are returned by the external agency and these summary event descriptions are used to populate a list view. TOCS TOCS Endpoint Request Information (RIN) ESB Request Information (R N) OSP Request Information (R N) ACK Incident Description (IDX) / Incident Description (IDX) Incident Description (IDX) ACK 2.6.2 Narrative 1. The TOCS system sends a Request Information (RIN) message to the TOCS Endpoint via web services. The Request Information message can include filter strings to communicate specific filters to the receiving partner. 2. The TOCS Endpoint sends the message to the ESB via web services. 3. The ESB acknowledges receipt of the message by sending a message via web services to the TOCS Endpoint. 4. The ESB routes the message to the appropriate ESB web service endpoint. 5. The ESB web service endpoint sends the message to OSP. 6. OSP receives the web service message. ODOT-OSP Connection Specification 20 Online EUSIi2ESS SYSTEMS 7. OSP processes the message to determine what events to return. 8. OSP creates a batch Incident Description message (IDX) and sends it to the ESB via web services. The batch Incident Description message is an Incident Description message that contains summaries of events as multiple Description Report sub messages. 9. OSP sends the batch Incident Description message (IDX) to the ESB via web services. 10. The ESB acknowledges receipt of the message by sending a message via web services to OSP. 11. The ESB routes the message to the appropriate ESB web service endpoint for the TOCS Endpoint. 12. The TOCS Endpoint sends the message to TOCS. 13. TOCS receives the batch Incident Description message and processes it according to internal business rules. 2.6.3 Scenario: Request Incident Details When an operator, or the TOCS system, selects a specific event from the list of summary event descriptions and chooses to view the details of the individual event a request message is sent to the external partner to return the full incident description for a specific event. The event details can then be used to create copies of the external event as a TOCS event. This is the same flow as Request All Open Events with the difference being that the request (RIH) message includes a specific event ID that is being requested and the reply (IDX) message contains the full incident record including radio traffic and unit assignment data. 2.7 Get List of Valid Endpoints A list of valid end points represents the agencies that can communicate on the ESB. This list is maintained external the ESB but can be accessed via the ESB. 2.7.1 Scenario: TOCS Requests List of Valid Endpoints ODOT-OSP Connection Specification 21 Online OUSINCSS SYSTEMS TOCS ESB Request Information (RIN) ACK retrieve endpoint list Incident Description (IDX) 2.7.2 Narrative 1. TOCS sends a Request Information message to the ESB via web services. The Request Information message has been extended to include a request for valid endpoints. 2. The ESB acknowledges receipt of the message by sending a message via web services to TOCS. 3. The ESB retrieves the list of valid endpoints and sends an Incident Description message to TOCS via web services. The Incident Description message contains a list of valid endpoints. 2.7.3 Scenario: OSP Requests List of Valid Endpoints OSP Request Information (RIN) ACK Incident Description (IDX) 2.7.4 Narrative retrieve endpoint list 1. OSP sends a Request Information message to the ESB via web services. The Request Information message has been extended to include a request for valid endpoints. 2. The ESB acknowledges receipt of the message by sending a message via web services to OSP. ODOT-OSP Connection Specification 22 Cjniine 913SMESS SYSTEMS 3. The ESB retrieves the list of valid endpoints and sends an Incident Description message to OSP via web services. The Incident Description message contains a list of valid endpoints. 2.8 Heartbeat A heartbeat in the context of this architecture is the process of sending a message to a recipient. If a response is received, the sender knows the other end is up and active. In the normal course of activity with this system, a heartbeat is implied every time ODOT or OSP sends a message and gets a response. Further, the heartbeat is testing each step of the process. A message sent from ODOT, gets an acknowledgement from the ESB, which tells ODOT that the ESB is up, and when ODOT gets the expect response message, ODOT knows that the system at OSP is up and functioning as well. Given all of that, the volume of message traffic between ODOT and OSP is expected to be low. Several hours may pass without a message exchange. The Heartbeat scenario occurs on a regular, configurable time period to ensure the receiving endpoint is active and able to receive requests and send responses. 2.8.1 Scenario: TOCS Heartbeat to OSP TOGS. ESB Heartbeat Message OSP Heartbeat Message ACK Heartbeat Response Heartbeat Response ACK 2.8.2 Narrative 1. TOCS sends a Heartbeat message to the ESB via web services. 2. The ESB acknowledges receipt of the Heartbeat message by sending a message via web services to TOCS. 3. The ESB routes the message to the ESB web services endpoint for OSP. 4. OSP receives the Heartbeat message and sends a Heartbeat Response message to the ESB via web services. 5. The ESB acknowledges receipt of the Heartbeat Response message by sending an message via web services to OSP. ODOT-OSP Connection Specification 23 Online ,VSIMS5 SYSTEMS 6. The ESB routes the message to the ESB web services endpoint for TOCS 7. TOCS receives the Heartbeat Response message and processes it according to its internal business rules. 2.8.3 Scenario: OSP Heartbeat to TOCS OSP ESB Heartbeat Message TOCS Heartbeat Message Heartbeat Response • Heartbeat Response ACK 2.8.4 Narrative 1. OSP sends a Heartbeat message to the ESB via web services. 2. The ESB acknowledges receipt of the Heartbeat message by sending a message via web services to OSP. 3. The ESB routes the message to the ESB web services endpoint for TOCS. 4. TOCS receives the Heartbeat message and sends a Heartbeat Response message to the ESB via web services. 5. The ESB acknowledges receipt of the Heartbeat Response message by sending an message via web services to TOCS. 6. The ESB routes the message to the ESB web services endpoint for OSP 7. OSP receives the Heartbeat Response message and processes it according to its internal business rules. 2.9 Request and Grant Handoff In the event an agency wishes to Handoff a particular incident to another agency then a Request for handoff will be sent. A Grant Handoff message, stating whether the agency accepts or rejects the incident, will then be sent as a response. 2.9.1 Scenario: TOCS Request Handoff to OSP ODOT-OSP Connection Specification 24 online BUSINESS SYSTEMS TOCS ESB OSP Request Handoff Message Request Handoff Message ACK Grant Handoff Message Grant Handoff Message ACK 2.9.2 Narrative 8. TOCS sends a Request Handoff message to the ESB via web services. 9. The ESB acknowledges receipt of the Request Handoff message by sending a message via web services to TOCS. 10. The ESB routes the message to the ESB web services endpoint for OSP. 11. OSP receives the Request Handoff message and sends a Grant Handoff Response message to the ESB via web services. 12. The ESB acknowledges receipt of the Grant Handoff Response message by sending a message via web services to OSP. 13. The ESB routes the message to the ESB web services endpoint for TOCS 14. TOCS receives the Grant Handoff Response message and processes it according to its internal business rules. 2.9.3 Scenario: OSP Request Handoff to TOCS ODOT-OSP Connection Specification 25 CsMine QUSINESS SYSTEMS OSP ESB TOCS Request Handoff Message i Request Handoff Message 1 ACK > 3 Grant Handoff Message Grant Handoff Message ACK 2.9.4 Narrative 8. OSP sends a Request Handoff message to the ESB via web services. 9. The ESB acknowledges receipt of the Request Handoff message by sending a message via web services to OSP. 10. The ESB routes the message to the ESB web services endpoint for TOCS. 11. TOCS receives the Request Handoff message and sends a Grant Handoff Response message to the ESB via web services. 12. The ESB acknowledges receipt of the Grant Handoff Response message by sending a message via web services to TOCS. 13. The ESB routes the message to the ESB web services endpoint for OSP 14. OSP receives the Grant Handoff Response message and processes it according to its internal business rules. 2.10 Alternate Paths The following scenarios occur when the normal message flow, as defined by the previously described business scenarios, has been interrupted. 2.10.1 Scenario: Endpoint cannot connect to ESB The endpoint cannot connect to the ESB. ODOT-OSP Connection Specification 26 Online BUSINESS SYSTEMS TOCS Endpoint ESB connect > JiK email to administrator Email log error condition SOAP Fault 2.10.2 Narrative 1. The endpoint fails to connect to the ESB. 2. The Endpoint sends an ACK(Negative) to application. 3. The endpoint logs the failed attempt. 4. The endpoint sends an alert email to the system administrator. 5. The endpoint sends a SOAP Fault message to the application. 2.10.3 Scenario: Endpoint does not receive acknowledgment from the ESB The endpoint is connected to the ESB but does not receive acknowledgement that the message was received on the ESB. Endpoint Eat Request Message Log error condition email to adminstrator Email 2.10.4 Narrative ODOT-OSP Connection Specification 27 Online „ BUSINESS SYSTEM 1. The Endpoint sends a request message to the ESB. 2. The Endpoint does not receive an acknowledgement message from the ESB. 3. The Endpoint sends an ACK(Negative) to application. 4. The Endpoint logs the error condition. 5. The Endpoint sends an alert email message to the system administrator regarding the error condition. 6. The Endpoint sends a SOAP Fault message to the application regarding the error condition. 2.10.5 Endpoint does not receive expected 1512 response message In this scenario, the endpoint has sent a 1512 request message to the ESB and is expecting a 1512 response message. The endpoint does not receive the response message in a timely manner. Endpoint ESB Request Message Endpoint Request Message ACK X Operator Message Log error condition Operator Message ACK email to adminstrator Email 2.10.6 Narrative 1. The Endpoint sends a message to the ESB and receives an acknowledgement message. 2. The Endpoint does not receive the expected response message after a configurable period of time. 3. The Endpoint logs the error condition. 4. The Endpoint sends an alert email to the system administrator regarding the error condition. 5. The Endpoint sends a SOAP Fault to the application regarding the error condition. ODOT-OSP Connection Specification 28 online BUSINESS SYSTEMS MESSAGE ARCHITECTURE 3.1 Message Sets The following message sets represent the set of IEEE 1512 Message Sets identified as in scope for this project. The message set descriptions are taken from the IEEE 1512-2000 specification. 3.1.1 Close Incident Event (CIE) The CIE message shall be used to close an incident event from the perspective of the issuing agency. 3.1.2 Grant Handoff (GHO) The Grant Hand Off message shall be used to reply to a Request Handoff (RHO) message with an acceptance or rejection of the hand off and any conditional data required to be exchanged. A rejection option allows the agency to decline a hand off if this procedure is allowed. By attaching conditional information, items such as a tracking number can be used for auditing purposes. 3.1.3 Incident Description (IDX) The Incident Description (IDX) is the generally -applicable message for all incident -related exchange of data. This message is designed to provide the common text, or "white board," that all involved centers can work with in managing the incident. While the message is quite large, it simply provides a set of standard elements and a structure for communication, with the expectation that no one local implementation is apt to make use of all of the data elements. Beyond that, local implementations can provide for "change only" content in messaging, where the only things communicated in a single IDX transmission are the changed fields. The registration provisions of the 'Header' provide the means to have those updates continually modify the IDX at every involved center consistently. This message can contain all detail about a specific event or a summary of multiple events. The summary form is used when an operator is requesting all open events, the detail when a request is made for a specific event detail. 3.1.4 New Incident Event (NIE) The New Incident Event message shall be used to declare and broadcast to other centers that a new incident event has been verified, and shall be identified with the number then being published with the message, at least within the numbering system of the issuing center. ODOT-OSP Connection Specification 29 C7nline CU>RFESS SYSTEMS This message will include a summary Incident Description message and any cross-referenced event data in the form of a pedigree list. 3.1.5 Request Handoff (RHO) The Request Hand Off message shall be used to directly contact a single center that the requesting center desires to hand off an incident to that center. Please note that this does not imply that the requesting center is relinquishing responsibility for the event in all cases. While that may occur, sending a Request Hand Off message is used to inform another center of the event. This message will include a full incident description and any cross- referenced event data in the form of a pedigree list. 3.1.6 Merge Incident Event (MIE) The Merge Incident Event message shall be used to communicate to any affected Call Centers that the sending center has merged two or more incidents into a single incident. 3.1.7 Request Information (RIN) The Request Information message shall be used to request all types of information about an incident or about the properties of the receiving center. A request concerning a specific incident of interest specifies that incident by sending either the reference ID number(s) for the incident (or involved resources), or by sending a set of filter values used to select events that match the requested criteria. It shall result in an IDX message being sent. 3.2 Message Patterns A defined set of SOAP messages will be used for all communication. Each message type will correspond to specific aspects of the message exchange patterns discussed in section 2, Business Scenarios. At a high level, the following SOAP message types will exist: 3.2.1 Request A SOAP message that defines a request of some nature and is intended to result in one or more responses. 3.2.2 Response A SOAP message containing response data for a prior request and is sent as a result of a SOAP request. 3.2.3 Broadcast Message A SOAP message sent independently of any request. 3.2.4 Acknowledgement ODOT-OSP Connection Specification 30 online EUSINESs SYSTEMS A SOAP message sent to acknowledge the acceptance of a prior message. 3.2.5 Fault A SOAP message sent to communicate a fault or error condition. ODOT-OSP Connection Specification 31 online UUSIti[SS SYSTEMS TECHNICAL ARCHITECTURE This solution set represents the technical approach for the incoming and outgoing communications between the PDCC Enterprise Service Bus (ESB), ODOT, and the various agencies ODOT will communicate with, including the Oregon State Police (OSP). The ESB will expose several Web Service access points to all agencies. These will be specified in a document literal WSDL defining multiple operations. The operations will correspond to the business scenarios outlined in the Business Scenarios section of this document. This architecture specifies that all communication between the ESB and the agencies is based on a web services model. This means that the ESB will act as a Web Service Host for incoming messages from the agencies, as well as a web service client for outgoing messages being sent to an external agency. 4.1 Assumptions Assumption', Description AS06 ODOT TOCS is a .Net 2.0 application that is not continuously available. This refers to the architecture of TOCS that implies that it is not deployed across redundant hardware to minimize downtime. L.EDS Data will not be sent in messages. All confidential data must stay confidential and it is the, responsibility of the endpoint systems, TOCS and PSSI CAD, to keep that data confidential. Web services (HTTP and SOAP) are the preferred endpoint implementation to integrating with TOCS. The solution shall utilize the Portland Dispatch Center Consortium; (PDCC)! Enterprise Service Bus (ESB) for message routing and delivery While the initial implementation shall support messages between ODOT and OSP, the custom endpoints must support receiving messages from other agencies without failure, even if no processing is done with those messages in, this initial implementation. All transformation between endpoint -specific codes, such as event type or call type, and 1512 -specific codes will take place within the custom endpoint implementation. The TOCS system will provide the TOCS Endpoint with fully formed 1512 messages. The TOCS Endpoint should have the ability to transform the message as needed, such as in the case ODOT-OSP Connection Specification 32 Online BUSINESS SYSTEMS Assunipti"o n Dscriptior�,_ AS13 AS14 that the 1512 specification has been updated. PSSI will own °everything up to the E The .NET framework will be utilized in the implementations. he TOCS application wi AS15 AS17 The PSSI OIS will expose its web service via an endpoint URL. he TOCS Endpoint will expose its we service to TOGS via a endpoint URL 4.2 Requirements The requirements represent the "what" of the system. 4.2.1 Business Requirements These business requirements represent the soft, or business -oriented, requirements the system is required to meet. Requirement Description Integration between TOCS, OSP and others will utilize the PDCC ESB infrastructure. plementations must 3C, and OASIS No system will have access to All data access is read-only. NFRO4 The TOCS interface to OSP will enable the transfer: of inciden' records between OSP CAD and :',ODOT,.TOCS . NFRO5 The TOCS interface to OSP will enable authorized TOCS access to specific OSP incidents. bide by: relevant standards, such as:IEEE functions in the remote CAD system. NFRO6 The TOCS interface to OSP will enable access to TOCS Incidents.. NFRO7 The TOCS interface to OSP will enable authorized TOCS users read data access to all OSP radio traffic attached to a call or unit. NFRO8 The TOCS interfae to OSP will enable' all OSP CAD users read access of all TOCS radio traffic that isattached to an incident or unit. Radio traffic will be a text transcript not an audio recording. NFR10 TheTOCS interface to OSP will enable redirection of incidents between traffic `centers and OSP. Authorized TOCS users shall be able to select and create TOCS copies of incidents from OSP CAD. all OSP CAD users rea ODOT-OSP Connection Specification 33 Online EUS1NC$S SYSIE MS Requirement Description. NFR12.' NFR13 Authorized TOCS users shall be ableto send incidents to OSP CAD TOCS incidents that are redirected to OSP CAD will include all radio traffic attached to the incident at the time the incident was sent. NFR14 OSP CAD users shall be able to select and: create OSP AD copies of incidents from ODOT TOCS.. OSP CAD users shall be able incidents to ODOT TOCS. NFR16 For incidents that are copied from OSP CAD, TOCS will make all OSP radio traffic attached to that incident 'read only" within the TOCS NFR15 to send (or reopen and redirect TOCS will provide geo-based' incident' locations. NFR17 NFR18 Incidents within both systems will have the capability to be related to other incidents within both TOCS and OSP CAD. NFR19 The TOCS system shall support an incident having multiple related incident numbers. The TOCS system shall main related to a TOCS incident. The TOCS system shall include the TOCS incident number as a related incident number on all TOCS incidents copied to OSP CAD. NFR22 The TOCS system shall provide, a method of identifying the: type of relationship of the related incident numbers. NFR23 The TOCS connection to OSP shall include automatic updates for shared incidents, aiin ill OSP CAD incident numbers NFR24 The TOCS system shall automatically send an incident to OSP CAD. when ODOT staff is in distress (as currently indicated by 12-98 and 12-99 codes): The TOCS interface to OSP CAD will support 'Screen to Screen" messaging functionality between TOCS users and OSP CAD users. 4.3 Technical Requirements The technical requirements enumerate specific, low -level requirements of the system. While the business requirements can be enumerated as a single group, the technical requirements are enumerated in this section and in the following sections as required. Requirement Description`, TRO 1 TRO2 TRO3 The TOCS Endpoint will be able to receive external events that have been published. The Endpoints will be able to publish information .for external CAD.. systems. Message exchanges between two endpoints will be asynchronous. ODOT-OSP Connection Specification 34 Online OUSLNESS SYSTEMS Requ�rem�n�i escri tion TRO4 Messages placed on the ESB will be synchronous. Messages;'>will receive an acknowledgement response.. from the ESB in the same TRO5 Messages sent throu.gh• the TOCS _Endpoint will only ;_besent one time. The TOCS Endpoint will wait for the acknowledgement response from the ESB as noted in TR04. If the sending times out or an exception is received, the TOCS Endpoint will not attempt to resend the message. Failure, to dispatch a message must result In an error condition that would. be known to the CAD system. Howthe error is handled is the responsibility of the CAD system. The TOCS Endpoint will not store messages. If a message cannot be sent first try, the TOCS Endpoint will not attempt to resend. It will be the responsibility of the CAD operator to make additional attempts. TRO8 An exchange must be able to;timeout if the exchange does not complete after a fixed period of time. Since this architecture is web service -based, this is an HTTP timeout. An HTTP timeout can occur on the TOCS Endpoint as well as on the PDCC ESB, The time out period shall be configurable. For the TOCS Endpoint, this is configured on the underlying Microsoft IIS server. For the PDCC ESB, this is configured in the Sonic Management Console for the HTTP Acceptor. Please refer to the P705U document for configuration details. All services are to share the same priorities in handling an exchange, thus message order is. important. TRO6 TRO9 TRIO; 4.4 Service Architecture The underlying service architecture for the ODOT to external agency connection assumes a strong decoupling from the PDCC Enterprise Service Bus that will be used as a transport layer between ODOT and the external agencies. Rather than hook directly to the bus in a traditional approach, custom endpoints will be developed to act as 'on -ramps' to the ESB. By developing these decoupled endpoints, ODOT will have the ability to connect directly to the external agency via their custom end point should the ESB be unavailable for any reason. 4.4.1 Service Components ODOT-OSP Connection Specification 35 BUSINESS SYSTEMS Comment [R S2] : There is a distinction between a connection time out vs. a response time out. In a connection time out, the Endpoint should attempt to send a message This diagram shows each high level component in the service architecture. Each component within this architecture is a black box. While this is self-evident from the diagram above regarding the ESB, it must be stated that the custom endpoint is not tightly integrated with the TOCS application. Component TOCS The application Description', TOCS End Poin ESB OSP Interoperability server(OIS) OSP PSSI CAD currently under development at ODOT. TOCS and custom endpoint will both reside on the same physical server. The custom endpoint that;will interact with TOCS and the ESB, receiving messages from ODOT TOCS to be placed on the ESB and receiving messages from the ESB to be send to TOCS. This endpoint will be responsible for any TOCS- specific business logic and message transformation, The. custom endpoint and the TOCS application both reside on, the same physical server. The Enterprise Service Bus (ESB) will act as a transport layer, providing services such as reliable messaging, message auditing, and message logging. The ESB will reside on its own set of servers, The OIS will be responsible for establishing and maintaining communications to the :OSP CAD. Communication between the CAD server and the 05 will be via TCP/IP sockets. The OSP PSSI CAD system will connect to the ESB via standard web services. OSP PSSI CAD resides within its own server at OSP. 4.5 Communication Between Components The TOCS Endpoint communicates with the TOCS application and the PDCC ESB via web services. Web services act as a thin public interface layer between black box components. The medium of communication with web services is fully formed XML documents. ODOT-OSP Connection Specification 36 Inline eusiaessSYST Ms 4.5.1 Public Interfaces The definition of each component's public interface is provided through the mechanism of a Web Service Definition Language (WSDL) file. A WSDL defines an XML format for describing the public interface as a set of endpoints that operate on messages that contain either document -oriented or procedure -oriented information. In the design architecture discussed in this document, each component will provide a WSDL file to the other components that will send messages to it. Therefore: ■ The TOCS application will provide a WSDL to the TOCS Endpoint so that the TOCS Endpoint can communicate with the TOCS application. • The TOCS Endpoint will provide a WSDL to the TOCS application so that the TOCS application can send messages to the TOCS Endpoint. • The TOCS Endpoint will provide a WSDL to the PDCC ESB so that the ESB can send messages to the TOCS Endpoint. • The PDCC ESB will provide a WSDL to the TOCS Endpoint so that that TOCS Endpoint can send messages to the PDCC ESB. • The PDCC ESB will provide a WSDL to the OSP Interoperability Server (OIS) so that the OIS can sent messages to the PDCC ESB. ■ The OIS will provide a WSDL to the PDCC ESB so that the PDCC ESB can send messages to the OIS. 4.5.2 Expected WSDL Definitions The .NET framework provides a rich toolset from which web service proxy classes can be created from a well -formed and valid WSDL file. These tools free up the developer from having to write the web services transport layer, allowing him to concentrate on the more important domain specific code such as the Endpoint or the TOCS application. Nevertheless, certain expectations regarding the web service communication are required to be met: The WSDL shall specify: ■ The wsdl:types element shall specify xml schema that represent any xml elements as a payload. For example, the following wsdl fragment defines a ReceiveMessage message element that is defined as 'anyType'. This will guarantee that the defined set of 1512 XML messages can be sent through the web service. <wsdl:types> <xsd•schema targetNamespace="http://pddc.gov/services/ReceiveMessage"> <xsd: element name "ReceiveMessage"!type-"xsd:anyType"/> </xsd: schema> ODOT-OSP Connection Specification 37 Online CUSIN ESS SYSTEMS </wsdl:types> ■ The WSDL Binding specifies a style of document. For example: <wsdl:binding name="RecieveMessageBinding" type="impl: ReceiveMessagelmpl"> <soap:binding style="document"` transport="http://schemas.xmisoap.org/soap/http"/> <wsdl:operation name="echo"> <soap:operation oapAction="http:-//pt100424:8080/pssi/services/EchoService/Request"/> <wsdl:input name="receiveMessageRequest"> <soap:body use -"literal"/> </wsdl:input> <wsdl:output name="receiveMessageResponse"> <soap:body use="literal"/> </wsdl:output> </wsdloperation> </wsdl:binding>' Beyond the above two requirements, the message or operation names are immaterial to the implementation of the TOCS Endpoint. So long as the WSDL is well -formed and valid, web service proxy classes can be created in .NET to support the public interface defined in the WSDL. Requirement Description TR11 TR12' WSDL Documents should be created whenever possible for all serviceinterfaces used between two or more systems. The WSDL defines the complete message syntax requirements The WSDL version that will be used is 1.2 and is defined by namespace http //www.w3.org/2003/03/wsdi 4.5.3 Distributing WSDL Files The TOCS Endpoint will expose its WSDL to the TOCS application with the following URL: http://<production-domain-server>/endpoint/tocs.asmx?WSDL It is expected that the TOCS application will publicly expose the WSDL that defines its web service on a known and accessible URL. It is expected that the OIS server will publicly expose the WSDL that defines its web service on a known and accessible URL. 4.5.4 SOAP The mechanism of exchange between each web service will be SOAP. SOAP is a lightweight, XML -based, protocol for the exchange of information in a decentralized, distributed environment such as the one defined in this architecture. ODOT-OSP Connection Specification 38 Online BUSINESS SYSTEMS The payload for the SOAP message will be a 1512 XML message, as defined in the ODOT Message Architecture document. Requiirement es��tto TR13 A SOAP envelope is required to support alt web service standards and will be defined by a WSDL 41'I service interfaces between two or more systems will use .2 envelope toprovide an interoperable message structure. TR15 All service interface SOAP bodies will use Document styles. Documents are naturally more process -centric and better suited for SOA TR1 TI TR17 All service.interface'SOAP envelopes will be°;encoded_using Li era encoding; ODOT will use SOAP v1.2 defined by the SOAP namespace http://www.w3.org/2003/05/soap-envelope 4.5.5 Canonical Messages as SOAP Payload A canonical message is a standard message format between endpoints and is considered a SOA and web services best practice. The canonical message format for this architecture is defined by the subset of IEEE 1512 XML messages identified in section 3.0, Message Architecture, and further defined in the ODOT Message Architecture document. Requirement Description TR18 A subset of the XML data schema for the IEEE 1512 (Common Incident Management Message Sets (IMMS)), draft revision 3/3/05, will be supported. TR19' TR20 All 1512 messages shall be accepted by an Endpoint Agent,, without error, regardless of whether the message itself is processed. 1512 Data Frames and Data Elements will be used whenever possible over a local extension. If no 1512 Data Frame or Data Element is applicable to the data, then a local extension will be used. TR21 TR22 If a;� 512' message request has` a specific 1 it should be used for the response The TOCS Endpoint shall receive 1512 messages directly from TOCS fully formed and valid. 4.6 Endpoint Architecture The TOCS Endpoint application is a composite of several classes, each with specific duties to support the overall function of processing IEEE - 1512 messages to and from TOCS. ODOT-OSP Connection Specification 39 ©reline BUSINESS SYSTEMS This design represents the core classes that make up the Endpoint. The web service proxy classes that would be generated from a wsdl file are NOT shown here because those proxy classes are dependent on an file that is external to this design. The following diagrams and narratives describe these components in detail. 4.6.1 Static Model : inte rfacesIEn dpoi ntLi sten er +ProcessMessage(in XmlDocument element) : void esb web service MessageTracker -Instance : MessageTracker -Acks : AckList +Append() +Delete() +OnTimeout() +Init() +Shutdown() MessageTransformer J Transform() nall» einterfacesI MessageTransformer +Transform() 4.6.2 Narrative “call” OdotBase -±Loga tocs web service +ProcessMessage(in XmlDocument element) : void cab OdotEndpoint TocsListener : I EndpointListener EsbListener : IEndpointListener recall» MessageManager +Instance : MessageManager -Messages: MessageQueue -Sender : IMessageSender +EnqueueTocsMessage() +EnqueueEsbMessage() -Ink) -Shutdown() +EngeueMessage() #ProcessMessage() Q TocsMessageManages -Transformer : IMessageTransformer -ParseTackableMessages(): void -TrackableMessage(): bool 1 1 EsbSender +Send() : bool “call” EsbMessageManager TimeedOutMsgs : MessageQueue -MessageTimeoutHandler() -MessageSendErrorHandler() TocsSender Send() : bool by :interfaces IMessageSender +Send() : bool ODOT-OSP Connection Specification 40 Online CU$1ttE5S SYSTEMS The endpoint class structure is represented by the following classes: OdotEndpoint This class represents the endpoint with just a few methods to initialize and shutdown all the components included in the endpoint, as well as methods invoked by instances of the IEndpointListener interface, which are implementations of web services that accept incoming data. IEndpoinfListener This interface defines a single method ProcessMessage() that is called when posting to a web service. Any client attempting to connect to the web service will have to invoke ProcessMessage and pass input data as <xsd:any>, which is represented as an XmlDocument class in .NET. The default web service, esb.asmx and tocs.asmx, implement this interface, accept incoming data and should be called by the ESB and TOCS respectively. IMessageSender This interface enables the endpoint to route incoming messages to their recipients. A component implementing this interface is a class that actually sends a message to the ESB or TOCS after internal processing done by the endpoint. There are two default implementing classes, EsbSender and TocsSender, which send processed messages to the ESB and TOCS respectively. The WSDL for a given external web service endpoint will be used to define proxy classes that will then be used by classes that implement the IMessageSender interface. These proxy classes will be used specifically within the Send method to deliver the message to the external web service. The Send() method takes an OdotMessage object, which is merely a wrapper around a 1512 XML document. The OnError() method is a callback handler method which utilizes the native .NET methods for processing errors. IMessageTransformer This interface defines what logic is necessary to perform a message transformation. The implementation of this interface can be configured to be used by the endpoint for all TOCS outgoing messages. The default implementation of this interface, MessageTransformer, is responsible for message transformation via XSLT when sending messages to the ESB. By default, this transformation is disabled. To enable it, specify a path to the file containing the XSLT as a value for the 'transformXsltFile' key in the web.config file. MessageManager This is an abstract class that implements most of the logic required by TocsMessageManager and EsbMessageManager, which are concrete ODOT-OSP Connection Specification 41 Online f1USINCS5 SYSTHMS implementation classes to manage messages for the TOCS and the ESB, respectively. MessageManager provides logic for multithreaded access from the outside by OdotEndpoint and internal threaded logic to process incoming messages and send them to their respective recipients. TocsMessageManager This is a concrete subclass of MessageManager and is responsible for messages originating in TOCS, their processing using an instance of IMessageTransformer, sending a message to the ESB, and communicating with an instance of MessageTracker to enable error handling and logging. EsbMessageManager This is a concrete subclass of MessageManager and is responsible for messages coming from the ESB, delivering the message to TOCSS, and communicating with an instance of MessageTracker to enable error handling and logging. MessageTracker This component is responsible for tracking outgoing and incoming messages and making sure that the responses arrive within a specified timeout period. When a message response is not available within a pre -defined timeout, EsbMessageManager is notified. The timeout period mentioned here is defined within the Web.config file for the TOCS Endpoint application. The time out value is associated with a given message type, so that only those message types listed are tracked. To define which messages should be tracked, add the messages as a value in the 'trackableMessages' key in the web.config. The value for this key is a comma -separated list of message types. To specify a time out value for each message type, separate the message type and the sdesired time out with a semi -colon. The message type specified here should be the root node of the message to be tracked. When messages are tracked, a message ID is placed in an in -memory queue. The queue is persisted to a serialized file whenever the endpoint is shut down, either manually or unexpectedly. 4.6.3 Sequence: TOCS connects to endpoint's WS and posts a message This diagram defines a sequence of events happening when TOCS sends a message to the ESB via the Endpoint. The receipt of messages happens in a separate processing thread from the send of the messages. This thread separation decouples the sending and receiving of messages so that the processing of received messages is not reliant on the processing of sent messages. ODOT-OSP Connection Specification 42 online BUSINESS SYSTEMS TocsListener TOCS calls WS • OdotEndpoint EnqueueTocsMessage TocsMessageManager EnqueueMessage Adds new message to a queue 4.6.4 Narrative 1. TOCS posts a message to the Endpoint via the Endpoint's web service, TocsListener, which is an implementation of the IEndpointListener interface. 2. The TocsListener passes the message to the OdotEndpoint. 3. The OdotEndpoint passes the message to the TocsMessageManager. 4. The TocsMessageManager add the new messages to the message queue. 4.6.5 Sequence: TOGS messages processing by TocsMessageManager This diagram defines a sequence of events that happen when a message appears in the internal processing queue of the TocsMessageManager. The sending of messages happens in a separate processing thread from the receipt of messages. This thread separation decouples the sending and receiving of messages so that the processing of received messages is not reliant on the processing of sent messages. ODOT-OSP Connection Specification 43 ( online BUSIPoC55 SYSTCMS TocsMessageManager IMessageTransformer Picks up a message from a queue Transform L Transformed message SendToEsb IMessageSender Adds message to be tracked MesssageTracker Enqueues message ack Saves to a data store 4.6.6 Narrative 1. TocsMessageManager picks up a message from the internal processes queue. 2. Based on how the Endpoint is configured, TocsMessageManager may or may not call an instance of IMessageTransformer to transform the message. 3. TocsMessageManager passes the message to an instance of IMessageSender, which is responsible for sending the message to the ESB. 4. Once the IMessageSender responds that the message is on the the ESB, TocsMessageManager calls MessageTracker and hands it details of the message. 5. The MessageTracker will then track the message and make sure the response arrives within the predefined timeout based on message type. 4.6.7 Sequence: ESB connects to endpoint's WS and posts a message for TOCS This diagram defines a sequence of events that happen when the ESB sends a message to TOCS via the Endpoint. ODOT-OSP Connection Specification 44 online BUSINESS SYSTEMS EsbListener ESB calls WS OdotEndpoint EnqueueEsbMessage EsbMessageManager EnqueueMessage Adds new message to a queue 4.6.8 Narrative 1. The ESB posts a message to the Endpoint via the Endpoint's web service, EsbListener, which is an implementation of the IEndpointListener interface. 2. The EsbListener passes the message to the OdotEndpoint. 3. The OdotEndpoint passes the message to the EsbMessageManager. 4. The EsbMessageManager adds the new message to the message queue. 4.6.9 Sequence: ESB messages processing by EsbMessageManager This diagram defines a sequence of events that happen when a message appears in the internal processing queue of EsbMessageManager. ODOT-OSP Connection Specification 45 (Online BUSINESS SYSTEMS EsbMessaaeManager MesssageTracker .;, Picks up a message from a queue Remove tracked message 1 Send IMessageSender Removes message ack Updates data store Send to TOCS 4.6.10 Narrative 1. EsbMessageManager picks up a message from the internal queue. 2. EsbMessagManager calls the MessageTracker to stop tracking the message. 3. Message Tracker removes the message tracking entry from its internal list of pending ACKs and removes the message tracking entry from the associated datastore. 4. Concurrently, the EsbMessageManager sends the message to the IMessageSender. 5. The IMessageSender sends the message to TOCS. 4.6.11 Sequence: MessageTracker Initialization Process This diagram describes the MessageTracker initialization process. The MessageTracker is initialized when the Endpoint is first started and in the case when the Endpoint has gone down for whatever reason. The MessageTracker is a singleton class. ODOT-OSP Connection Specification 46 ( Online BUSINESS SYSTEMS MessageTracker Data Store Get saved acks Saved acks Remove timedout acks from the list Add valid acks to the active list Start monitoring acks 4.6.12 Narrative 1. The MessageTracker retrieves all saved ACKs from the datastore. 2. The MessageTracker removes all expired entries. 3. The MessageTracker adds the remaining, valid, entries to its internal list for monitoring. 4.6.13 Sequence: MessageTracker Shutdown Process This diagram describes the MessageTracker shut down process. MessageTracker Stop monitoring Clear active list Clear data store 4.6.14 Narrative ODOT-OSP Connection Specification 47 ( Online BUSINESS SYSTEMS 1. When the MessageTracker receives a shutdown notice, the MessageTracker stops monitoring for the ACKs in its internal list. 2. The MessageTracker clears its internal list. 3. The MessageTracker clears the data store. 4. The MessageTracker exits. 4.6.15 Sequence: No ACK received within specified timeout This diagram describes the process the MessageTracker goes through when one or messages are considered overdue. MessageTracker EsbMessageManager Get timed out acks Fire OnTimeout event HandleAckTimeout Send error message IMessageSender Send to TOCS 4.6.16 Narrative 1. The MessageTracker wakes up on the signal that one or more messages are overdue. 2. The MessageTracker picks up timed out ACKs and notifies EsbMessageManager that some ACKs are overdue. 3. The EsbMessageManager processes the ACKs and creates error messages. 4. The IMessageSender sends the error messages to TOCS. 4.6.17 Message Request/Response Tracking Each Request message being send through the Endpoint will have a message ID associated with it. This message ID will be a GUID, a ODOT-OSP Connection Specification 48 Online EVSitiEs5 SYSTEMS globally unique ID. When the Endpoint receives the message from TOCS, it will store this GUID and use it to track whether a response has been received within a configurable time period. The GUID will be placed in the SOAP header for easy accessibility by the Message Tracker component of the Endpoint. 4.7 Enterprise Service Bus Architecture The Enterprise Service Bus is a messaging framework application which uses common services over a JMS transport layer to send and receive data. The PDCC ESB will be used for this implementation. The following diagram shows the expected set of ESB services. 4.7.1 ESB Components This diagram shows each ESB service in relation to the expect flow of messages from one external endpoint, such as the TOCS Endpoint, to another, such as the OIS. 4.7.2 Narrative The ESB structure is represented by the following Sonic ESB artifacts and services. External Agency This represents an external agency connecting to the ESB, such as TOCS, with the TOCS Endpoint, or OSP, with the OIS. HTTP Acceptor The HTTP Acceptor represents the external facing connection point to the ESB using the HTTP protocol. An HTTP Acceptor allows external clients to connect to an ESB without the use of the Java Message Service (JMS). The HTTP Acceptor exposes a standard URL to a client, such as http(s): //odot.state.or. us:5501/odot. Content -based Router ODOT-OSP Connection Specification 49 online BUSIES5 SYSTEMS The Content -based Router is a service which reads the content of a message to determine where the message should be sent within the ESB. It reads the messages and determines the message destination bases on a configurable set of matching rules. In this architecture, if the message is determined to be a request for the latest set of Endpoints, the message is routed to the Current Endpoint service, which would retrieve the endpoint list and send it to a web service endpoint for the requesting agency. If the message is determined to be a standard 1512 message, the message is routed to the Audit Service for auditing and then to the Web Service endpoint for the receiving agency. Audit Service The Audit Service receives the message and logs it to a file and then sends the message onto the web service endpoint. Web Service Endpoint The Web Service endpoint handles all outbound communication to an external agency. As the name suggests, communication is via web services. There is a web service endpoint for each external agency. Current Endpoints The Current Endpoints service receives a Get Endpoints message from the Content -based Router. The Current Endpoints service retrieves the current list of endpoints stored in the ESB and forwards the list, as a message, to the requesting agencies Web Service Endpoint. Note that this is a different flow that sending messages from one agency endpoint to another, when a current list of endpoints is requested, this service forwards the message back to the requesting agency via that agency's web service endpoint. 4.7.3 Get Endpoints Service Interface The list of current endpoints will be stored on the ESB. A custom ESB service, Current Endpoints, will be created to retrieve the list when it receives a request to do so. Endpoints List The list of endpoints is an xml document of all current endpoints. The xml document will be stored on the ESB in the Sonic File System, or SonicFS, which is a file -based storage mechanism internal to the ESB. Adding or updating the list of endpoints will be through the Sonic Management Console or SMC, which provides a mechanism for importing files into the SonicFS. Please refer to the P7O5U for instructions on how to add the file to the SonicFS. XML Data Model The following is an•example of the endpoints list: ODOT-OSP Connection Specification 50oniine CUSIf7ESS SYSTEMS 2,,<EndpointList> <Endpoint> <code>OSP</code' > <name>Oregon State Police</name> <url>https//state. or.us<url> </Endpoint> <Endpont> <code>WCCCA</code> <name>WashngtonlCounty Communication <url>http://wccca.state.or.us<url> </Endpoint> <Endpont> <code>WSP</code> <name>Washington'State'Police</name> <url>http:/wsp.state.wa.us<url> </Endpoint> </EndpointList> Center Agency</name> Get Endpoints Request message The Get Endpoints Request message is the Request Information message from the IEEE -1512 specification with a local extension called GetListOfEndpoints. Please refer to the Message Architecture document for specifics. Get Endpoints Response message The Get Endpoints Response message is the Incident Description (IDX) message with a local extension containing the list of current endpoints. Please refer to the Message Architecture document for specifics. 4.8 Quality of Service Reliable messaging is provided by the ESB through the SOA best practice concept of Quality of Service (QoS). By specifying that the message must be delivered EXACTLY ONCE, the ESB will continue to attempt to deliver the message until it has been delivered or a preconfigured number of retries has been exceed or a timeout has been reached. If the message could not be delivered, the ESB will send a notification to that effect back to the sender. Quality of Service is defined on the ESB. Specifically, each endpoint is configured with the desired QoS and ESB connection. An ESB connection defines the specific Sonic MQ broker to be used when delivering and sending messages. The specifics of how this is set up is out of scope fort this document, please refer to the P705U, TOGS Endpoint Operations Manual, for more information on configuring the PDCC ESB 4.9 Logging Logging is fine-grained historical and analytical information primary for debugging and problem solving. Requirement 1 Description ODOT-OSP Connection Specification 51 Online BUSINESS SYSTEMS IFormatted: French (erance ) IrFormatted: French (France) Formatted: French (France) Comment [RWB3] : This is just an assumption of the name of the P705U. Requirement Description TR23 TR24 TR26 The TOCS Endpoint shall log message exchanges. The Microsoft Enterprise Library will be used to support logging', ithin the TOCS Endpoint. Logging will be persisted to the standard logging tables defined by, the Microsoft Enterprise Library. The following data will, be extracted from the SOAP Envelope and / or SOAP Payload (1512 message) o Date Sender agency. code Destination agency. code Incident ID lessage ID TR27Logging of the message content will always occur with a level equivalent to WARNING or FAIL.' TR28 Logging of the message content at a given logging level willbe configurable and based on storage capabilities. The Logging configuration is maintained by the Microsoft. Enterprise Librax_ configuration tool The Logging tables will be deployed to the data store used by the TOCS application.Or, tt an alternate data store to be determined by (:)DOT development beam if the size or performance of ti e logging, tool merits separate sto TR30 The PDCC ESB. shall enable logging of messages via an audit service on the ESB. This service shall be configurable to allow for the logging of the full message when desired TR29 4.9.1 TOCS Endpoint Logging Logging on the TOCS Endpoint is enabled through the use of the Microsoft Enterprise Library. Logging configuration is done via the Enterprise Library Configuration GUI which is packaged with the Enterprise Library. The Enterprise Library Configuration GUI allows a user to define the logging categories, such as Audit, Error, Debug, and Exception and the Logging listeners for the categories. Listeners are classes that react to a log message being written to a give log level within the TOC Endpoint. The supported listeners at this time are: • Database Trace Listener, which writes the log message to the database configured for the listener. The Enterprise Library Configuration tool allows the user to define the database connection properties for this listener. ODOT-OSP Connection Specification 52 online EUS UiESS SYSTEMS • Flat file Trace Listener, which writes the log message to the specified log file. • Email Trace Listener, which sends a configurable email to a specified set of email recipients. Please refer to the P705U document for details on how to configure all aspects of logging on the TOCS Endpoint. 4.9.2 ESB Audit Logging Logging on the ESB is done via an Audit ESB service. Configuring this service is done via the Sonic Management Console (SMC). With the SMC, a user can configure the name and location of the audit log as well as whether the full message contents are logged. Please refer to the P705U for details on how to configure the PDCC ESB Audit service. 4.9.3 Notification & Error Handling Notification is the process of alerting the appropriate personnel or process when a business condition or rule is met so that immediate action can be taken to resolve the issue. Email notifications will be sent to a predetermined list of administrators whenever a specific error or warning condition occurs. Requirement Description` TR31 Email shall be used for notification to specified email addresses in addition to any error messages sent to the TOCS application. TR32 The Microsoft Enterprise Library configuration tool will. be used to, configure email notification. Configuration of email includes specifying the SMTP server and; the email address to which notifications will be sent. TR33 An email notification shall be sent when the Endpoint cannot connect to the ESB. TR34 An email notification shall be sent when a system acknowledgement is not received from the ESB. A system acknowledgement is provided each time the. Endpoint sends a message to the ESB. TR35 An email notification shall be sent when an expected response method is not received by the Endpoint within a given time interval. TR36 The email notificationshall include the following information'. • Date. • . Time • Sender agency code Recipient agency code Incident ID Process or Component that had the error ODOT-OSP Connection Specification 53 Online BUSINESS SYSTEMS Requirement Description: 1essage text stating the nature of theerror notification" 4.10 Security ODOT TOGS System 128 bit, FIPS compliant encryption (RSA with AES 128 CBC SHA) 4.10.1 Secure Socket Layer (SSL) Communication between components resident on different physical servers will be via Secure Socket Layer (SSL) over HTTP. Secure Socket Layer is a transport -level security mechanism which uses Public Key Infrastructure to encrypt packet data. Each component will be configured with a standard X.509 certificate. The certificate will be created using a 128 bit, FIPS compliant cipher suite (RSA with AES 128 CBC SHA). 4.10.2 System Authentication Given the Asynchronous Request - Reply message patterns used between each component, a certificate will be installed in the: • TOCS Endpoint • ESB • OSP PSSI CAD application 4.10.3 User Authentication No user authentication and authorization service is necessary between ODOT and OSP. Authentication is handled at the protocol level with SSL. 4.10.4 Certificates ODOT will need to procure 2 certificates. The first is for the Endpoint and the Second is for the ESB connector that the endpoint will use. If ODOT is purchasing the certificates on behalf of OSP/PSSI, 2 additional certificates will be required (1 for the ESB and 1 for the PSSI endpoint to connect). ODOT-OSP Connection Specification 54 Online BUSINESS SYSTEMS A certificate authority such as Verisign can be used to request a certificate. For OBS to use it, it should be in pkcsl2 format, or alternatively, ODOT could get a public and private key pair from the certificate authority and request that the public key be given in pkcs7 format and the private key in pkcs8 format. In either case, OBS will need to know the password or passphrase used to generate the private key. 4.10.5 Payload Encryption The SOAP messages will not be encrypted. 4.10.6 Quality of Trust With the PDCC ESB server installed in a secure server, an implicit level of trust exists between ODOT, the PDCC ESB, and OSP. Once a message reaches the ESB, it is guaranteed to be in a protected environment. With SSL in use on the ODOT and OSP side, a message can travel from the message producer to the message consumer securely. ODOT-OSP Connection Specification 55 Online BUSINESS SYSTEMS SOFTWARE DEVELOPMENT ENVIRONMENT The current solution architecture for this project utilizes web services and custom endpoint agents to decouple the endpoint systems from the transport layer of the ESB. Many built-in services of the ESB, such as dynamic and content -based routing, are not used. The following section describes some disadvantages of the current approach versus a SOA -based approach that leverages the ESB architecture to a greater degree. 5.1 Microsoft .Net Microsoft .NET is a software development platform for the implementation of desktop and server applications. The .NET framework provides many technologies that are specifically designed at the development of enterprise applications. Although the .NET platform provides many different development languages, the language of choice for the project will be C#. The latest version of the Microsoft .NET framework is version 3.0 which was released in November 2006. The latest version improves on many of the technologies in the previous 1.1 version of the framework. Along with the release of the framework there was also a new release of the Visual Studio Development IDE (Visual Studio 2005). The improvements in thick client GUI development as well as the C# development language improvements will be particularly useful for the IPS project. 5.2 Development Standards 5.2.1 Coding Standards All code written will conform to the IDesigns C# Coding Standards Guide and the TOCS Design and Construction Guidelines Draft document, both under separate cover. Where there are conflicts in standards between the two documents, the TOCS Design and Construction Guidelines Draft document will take precedence. 5.2.2 Unit Testing Standards The project is using test driven development as a development best practice and as such it is important that there be standards around the test classes. The following outlines the standards: • All test classes will be named for the class they are testing. The naming convention will be ClassNameTest. ODOT-OSP Connection Specification 56 Online BUSItFESS SYSTEMS • All test methods will specify the expected behavior that they are testing. The naming convention will be ShouldExpectedBehavior. • All constructor dependencies should be interfaces 5.3 Development Tools The Developer will utilize the following tools and software: Took/ Prodltfa •Purpose'. Dior .In U Visual Studio 2005 .NET .NET Development Environment Professional Edition /w MSDN Team Foundation Server Version control system SQL SERVER 2005 Development environment as PSSI DB Developers Edition Internet Information Server Hosting Web Services 6.0 Note: This document will be updated as software versions change. ODOT-OSP Connection Specification 57 Online BUSINESS SYSTEMS TECHNICAL ENVIRONMENT 6.1 Application Server The application server will host the Endpoint Web Service application using the latest version of the .NET Framework (v2.0) and will expose the application interface via web services. The application server will be running the Windows Server 2003 operating system. The application server will also run Internet Information Services 6.0 with ASP .NET 2.0 in order to host the Endpoint web services. 6.2 Physical Configuration The physical environment stack for testing and production is shown in these diagrams: Test Environment SSaIem TOC- 31 Wndows Server 2003 Standard Edition SP1 .NET Framework 3.0 TOGS Test Harness and ESB End Point USalemRev 13 ESB Firewall (Edge Apple ce) 167.131.74. 1 User Acceptance Environment / Production User Workstation Windows XP Pro Test Namess GUI S -Salem TOC -131 W ndows Server 2003 Standard Edition SP1 .NET Framework 3.0 TOGS Test Harness and ESB End Point Sonic Enterprise Service Bus 167.13 .84.10:4500 167.13 .84.11:4500 167.131.84.12.4500 167.131.84.13:4500 U-SalemRev 13 ESB Firewall (Edge Apple ce) 167.131.74. 1 So io Enterprise Service Bus 167.13 .84.104500 167.13 .84.11:4500 167.13 .84.12.4500 167.131.84.13:4500 OSP Firewall (Shared with PDCC using port separation) OSP OIS Sery r OSP PSSI CAD OSP Firewall (Shared with PDCC using ort separation OSP 010 Sery r OSP PSSI CAD 6.3 Network Both Endpoints will be deployed within the ODOT WAN. The primary location will be the C-4 building. 6.4 Operating Standards and Procedures ODOT-OSP Connection Specification 58 online BUSINESS SYSTEMS The User Acceptance and Production environments will be managed by ODOT Tech Management. Online will deliver installation scripts and instructions. ODOT-OSP Connection Specification 59 Online PU>Ifi ESS SY TRACEABILITY Traceability provides the ability to track important items such as Use Cases, Requirements, and Design Features through the various phases of the project. 7.1 Assumptions Assumption Description ASO1 AS02 AS03 While it is expected that integration with other agencies will happen in the future, the first agency ODOT is integrating with is OSP. The ODOT to OSP integration is the only integration in scope for this project. When an event the ESB. When an event is opened or changed in PSSI CAD, the event is sent to the ESB. s opened„or changed in TOCS, the event is sent to ASO4 While: this document suggests that "all open events be be exchanged between agencies - weassume that ODOT will reach agreement with all participating agencies that may result in the filtering of events at the end point. It is the responsibility of the end-point CAD systems to provide - or not provide :;- the agreed to events. Business rules to filter events will NOT occur on the ESB. ODOT and OSP will have an agreement of what constitutes a changed event. ASO6 ODOT .TOCS :is a .Net. 2.0 applicationthat is not continuously available. This refers to the architecture of TOCS that implies that t is' not deployed across redundant hardware to minimize downtime. LEDS Data will not be sent in messages. All confidential data must stay confidential and it is the responsibility of the endpoint systems, TOCS and PSSI CAD, to keep that data confidential. Web services (HTTP and SOAP) are the preferred endpoint implementation to integrating with TOGS. AS09 The solution shall utilize the Portland Dispatch Center Consortium (PDCC) Enterprise Service Bus (ESB) for message routing and delivery. AS10 While the initial implementation shall support messages between ©DOT and OSP, the custoni endpoints must support receiving messages from other agencies without failure, even if no processing AS05 AS07 ASO8 ODOT-OSP Connection Specification 60 oniine BUSINESS SYSTEM is done with those messages in this initial iniplernentation. S11 All transformation between endpoint -specific codes, such as event A type eoomr call endpoint implementation. lamnpdiel-m5la2nt-astpieocnif.ic codes_ willdtianktewpitlhacfeuiwiYitfhoirnmtehde AS12 T°CSsssaygsetse.mTbweilrlepsrnooviudlde tbheenTo°nCeSedtnfopr Endpoint of 1512me AS13 TA°sCtaSgisni3g database, set up by pssI CAD, will be used as ecific data to 1512 -specific data by the TOCSEndpoint, an An intermediary between the endpoint and the PSSI CAD .system. 'inbox' table and 'outbox'.will be used. The endpoint will place received messages in the inbox table for PSSI CAD, and read the outbox table to send messages to the ESB. A514 The .NET frameworj< will be idllizeciiri flupc) thee implementations. AS15 The TOCS application will expose its web service via an endpoint URL. AS16 The PSSI 015 will expose its web service viaan endpoint U11.1-, AS17 The TOCS Endpoint will expose its web service to TOCS via an endpoint URL 7.2 Decision Points DP01 Is there a need to restrict messages by type and recipient? This would be a modification of the existing Monitor External Events business scenario in that the sending endpoint would control who the recipient of the message will be. Will this be implemented via a content -based router or through endpoint to endpoint messaging? If endpoint to endpoint, will this be maintained on the ESB or at the custom endpoint? Is this a phase 1 requirement? 0P02 What is the message structure for sending Radio Traffic? DP03 What is the message structure for location of incidents? DP04 Is Tow functionality going away? DP05 Will a new less chatty incident description (IDX) Message be used? DP06 Does ODOT have a x509 certificate that they want the endpoint to use. 7.3 Business Requirements Requirement Description NFRO1 Integration between TOCS, OSP and others will utilize the PDCC ODOT-OSP Connection Specification 61 Online BUSINESS SYSTEMS Requirement Description. ESB infrastructure. NFRO2 Implementations must abide by relevant standards, such as IEEE, NFRO3 No system will have access to functions in the remote CAD system. All data access is read-only. NFRO4 The TOCS interface to OSP will enable the transfer of incident records between OSP CAD and ODOT TOCS. NFRO5 The TOCS interface to OSP will enable authorized TOCS users read access to specific OSP incidents. NFRO6 The TOCS interface to OSP will enable all OSP CAD users read access to TOCS Incidents. NFRO7 The TOCS interface to OSP will enable authorized TOCS users read data access to all OSP radio traffic attached to a call or unit. NFRO8 The TOCS interface to OSP will enable all OSP CAD users read access of all TOCS radio traffic that is attached to an incident or unit NFRO9 Radio traffic will be a text transcript not an audio recording. NFR10 The TOCS interface to OSP will enable redirection of incidents between traffic centers and OSP. NFR11 Authorized TOCS users shall be able to select and create TOCS copies of incidents from OSP CAD. Authorized TOCS users shall be able to send incidents to OSP CAD NFR13 TOCS incidents that are redirected to OSP CAD will include all radio traffic attached to the incident at the time the incident was sent. NFR14 OSP CAD users shall be able to select and create OSP CAI) copies of incidentsfrom ODOT TOCS. NFR15 OSP CAD users shall be able to send (or reopen and redirect) incidents to ODOT TOCS. NFR16 For incidents that are copied from OSP CAD, TOCS will make all OSP radio traffic attached to that incident "read only" within the TOCS system. NFR17 TOCS will provide geo-based incident locations. For incidents that are copied (or reopened and redirected) from OSP CAD, TOCS will make all OSP radio traffic attached to that incident "read only" within the TOCS system. NFR18 Incidents within both systems will have the capability to be related to other incidents within both TOCS and OSP CAD. NFR19 The TOCS system shall support an incident having multiple related incident numbers. NFR20 The TOCS system shall maintain all OSP CAD incident numbers related to a TOCS incident. ODOT-OSP Connection Specification 62 Online Requiretnent E)escrit)tion NFR21 The TOCS system shall include the TOCS incident number as a related incident number on all TOCS incidents copied to OSP CAD. NFR22 The TOCS system shall provide a method of identifying the type of relationship of the related incident numbers. NFR23 The TOCS connection to OSP shall include automatic updates for shared incidents. NFR24 The TOCS system shall autorriatically send an incident to OSP CAD when ODOT staff is in distress (as currently indicated by 12-98 and 17.99 cnr1cs'. NFR25 The TOCS interface to OSP CAD will support "Screen to Screen" messaging functionality between TOCS users and OSP CAD users. 7.4 Technical Requirements Requiren-ient Description •• • TF201 The TOCS Endpoint will be able to receive external events that have been published. The Endpoints will be able to publish information for external CAD systems TRO3 Message exchanges between two endpoints will be asynchronous. TRO4 Messages placed (.34'1 the ESB will be synchronous. Messages will receive an acknowledgement response from the 68 in the same TRO5 Messages sent throw the TOCS Endpoint will only be sent one time. Once the message reaches the PDCC ESB, messages may be cached to guarantee delivery in case the ESB goes down. TR06 Failure to dispatch a message must result in an error condition that would be known to the CAD system. How the error is handled is the responsibility of the CAD system. TRO7 TbehethTeOrCeS Endpoint will not store mess,.fageehas.eIxfcamnegseesnotsdagoecannot be attempts. sentfirst stpryo'n thesibi responsibility CoSf tEndpoint livoperatoril not attempt thatottemmapkte taodrdei stieorinda'l It twill An exchange mustbe period ed able etdof time' to t TR°8 complete after a fixhall be configurable.priorities in handling an l TTRROiog TAhnesetirmvieout suatpreeiotrosdshare the . same exchange, thus message order is important. TR11 WSDL Documents should be created whenever possible for all service interfaces used between two or more systems. The WSDL defines the complete message syntax requirements TR12 The WSDL version that will be used is 1.2 and is defined by the ODOT-OSP Connection Specification 63 Online -- BUSINCS5 SYSTCMS Description TR13 A SOAP envelope is required to support aU web service standards and will be defined by a WSDL TR14 All service interfaces between two or more systems will use a SOAP envelope to provide an interoperable message structure. TR15 Alt service interface SOAP bodies will use Document styles. Documents are naturally more process -centric and better suited for SOA TR16 All service interface SOAP envelopes will be encoded using Literal encoding TR17 ODOT will use SOAP vl.2 defined by the SOAP namespace uttp://eww.w3.or9/2003/05/uvae-eovezvpe TR18 A subset of the XML data schema for the IEEE 1512 (Common Incident Management Message Sets (IMMS)), draft revision 3/3/05, will be supported, TR19 All 1512 messages shall be accepted by an Endpoint Agent, without error, regardless of whether the message itsetf is processed. TR20 1512 Data Frames and Data Elements will be used whenever possible over a local extension. If no 1512 Data Frame or Data Element is applicable to the data, then a local extension will be TR21 If a 1512 message request has a specific 1512 message response, it should be used for the response. TFt22 The TOCS Endpoint shall receive 1512 messages directly from TOCS fully formed and valid. TR23 The TOCS Endpoint shall log message exchanges. TR24 The Microsoft Enterprise Library will be used to support logging within the TOCS Endpoint. TR25 Logging will be persisted to the standard togging tables defined by the Microsoft Enterprise Library. TR26 The following data will be extract)ed from the SOAP Envelope an or SOAP Payload (1512 message . +vuDoo� • Time • Sender agency code • Destination agency code • Incident ID • Message ID TK27 Logging of the message content will always occur with a logging level equivalent to WARNING or FAIL. ODOT-OSP ConnectioSpecification 64 -000no BUSINESS SYSTEMS Requirement Descrip#ion''. TR28 Logging of the message content ata given loggipg,level will be configurable and based on storage capabilities. The Logging configuration 'is maintained by the Microsoft Enterprise Library configuration tool, TR29 The Logging tables will be deployed to the data store used by the TOCS application. l R30' Email shall be used for notificationto specified email addresses in addition to any error messages, sent to the TOCS application TR31 The Microsoft Enterprise Library configuration tool will be used to configure email notification. Configuration of email includes specifying the SMTP server and the email address to which notifications will be sent. TR32 TR33 TR34 TR35 be sent when the Endpoint cannot An email notification shall. connect to the ESB. An email notification shall be sent when a system acknowledgement is not received from the ESB. A system acknowledgement is provided each time the Endpoint sends a message to the ESB. An email notification shall be sent when an expected response method is not received by the Endpoint within a given time inter 1 The email notification shall include the following information: • - Date • Time • Sender agency code • Recipient agency code • Incident ID Process or Component that had the error Message text stating the nature of the error notification rva ODOT-OSP Connection Specification 65 Online ,. MJMNESS SYSTEMS TERMINOLOGY The following is a list of the commonly used abbreviations, acronyms and their respective definitions Term Architecture Asynchronous BPM Choreography.. Composition Coordination Coupling 'EDA Governance Loose Coupling etamodel Definition The fundamental organization of a system embodied by its components, their relationships to each other and to the environment and the principles guide its design and evolutions (IEEE P1471/D5.3) Message transmission which has the behavior of no response Business Process Modeling is a method to model or configure new business functionality Interactions between independent processes Turning fine-grained atomic services into course -grained business services Defining the relationships between two or more services The level of common knowledge necessary in a distributed computing exchange Event Driven Architecture is an approach to distributed computing where events trigger asynchronous messages that are sent between independent software components that need not have any information about each other. In computing, an enterprise service bus refers to a software architecture construct, implemented by technologies found in a category of middleware infrastructure products usually based on Web services standards, that provides foundational services for more complex service-oriented architectures via an event -driven and XML -based messaging engine (the bus). An enterprise service bus generally provides an abstraction layer on top of an Enterprise Messaging System that allows integration architects to exploit the value of messaging without writing code. Contrary to commonly used EAI brokers which are usually implemented as a monolithic stack in a hub and spoke architecture, the foundation of an enterprise service bus is built of base functions broken up into their constituent parts, with distributed deployment where needed, working in harmony, as necessary (Source: Wikipedia) The policy model that describes the security, monitoring, auditing, etc, of an SOA. Could be internal policies or regulations such as the Sarbanes-Oxley Act. A desired feature of services this allows two services to interact without being aware of one another and that changing one service does not break the other service. A Model of Models ODOT-OSP Connection Specification 66 online BUSIti ESii SYSTMS :Terni -Vi,, Definition,111112113fill:2,Eggirgis,„, Metadata Data about data Model Orchestration Composing services using a logical flow. Can be long running or a simple workflow RemoteRPC Procedure CalI is the traditional approach to distributed computing that represerits distributed resources as local entities Service Loosely coupled interfaces to functionality that communicates via messages. Services are the fundamental abstraction behind SOA SLA Service Level Agreement - requirements of the infrastructure and services. Includes reliability and availability SOA Service Oriented Architecture: An approach to building and managing distributed computing infrastructures that consider IT resources as Services available and discoverable on a network. (ZapThink) SOAP SOAP, formerly an acronym of Simple Object Access Protocol, is a light -weight protocol originally designed by Microsoft and IBM for exchanging messages between computer software, typically in the form of software component. The word object implies that the use should adhere to the object-oriented programming paradigm. Source wikipedia [en.wikipedia.orgi SOE Service -Oriented Enterprise is a mature SOA where IT resources and services are available, on demand to the business SOI Service -Oriented Integration is leveraging the Service -Oriented Architecture to achieve integration. Integration is a by-product of the SOA. SOM Service -Oriented Management is a runtime operations function of a SOA. Are the services available and running, are the right consumers accessing the right services, are you meeting the required Quality of Service SOP Service -Oriented Process is a corripositions of services that are themselves, services Synchronous Message transmission that has the behavior of waiting for the response. Transaction A reliable relationship between two or more services WSDL Web Services Description Language - a Web Services contract language WeD Services Standards based interfaces to software functionality XSD An XML Schema Definition (XSD) is an instance of a W3C XML Schema. An XSD defines a type of XML document in terms of constraints upon what elements and attributes may appear, their relationship to each other, what types of data may be in them, and other things. It can be used with validation software in order to ascertain whether a particular XML document is of that type, and to produce a Post -Schema Validation Infoset. Source wikipedia fen.vvikipedia.org] ODOT-OSP Connection Specification 67 Online BUSINESS SYSTEMS APPENDIX A: ODOT TO OSP SECURITY IMPLEMENTATION The appendix discusses the steps necessary to setup SSL on the TOCS Endpoint server. 1.0 Set Up SSL on a Web Server Applies to: • Internet Information Services (IIS) 5.0, 5.1, and 6.0 • Microsoft@ Windows 2000 Server'' and Windows Server 2003 Summary: A Web server must be configured for SSL in order to support https connections from client applications. This How To shows you how to configure SSL on a Web Server Secure Sockets Layer (SSL) is a set of cryptographic technologies that provides authentication, confidentiality, and data integrity. SSL is most commonly used between Web browsers and Web servers to create a secure communication channel. It can also be used between client applications and Web services. Note Ensure that Microsoft Certificate Services (required if you need to generate your own certificates) are installed on the certification authority (CA) machine. 2.0 Generate a Certificate Request This procedure creates a new certificate request, which can be sent to a Certificate Authority (CA) for processing. If successful, the CA will send you back a file containing a validated certificate. To generate a certificate request 1. Start the IIS Microsoft Management Console (MMC) snap -in. 2. Expand your Web server name and select the Web site for which you want to install a certificate. 3. Right -click the Web site, and then click Properties. 4. Click the Directory Security tab. 5. Click the Server Certificate button within Secure communications to launch the Web Server Certificate Wizard. ODOT-OSP Connection Specification 68E�nline INESS SYSTEMS Note If Server Certificate is unavailable, you probably selected a virtual directory, directory, or file. Go back to Step 2 and select a Web site. 6. Click Next to move past the welcome dialog box. 7. Click Create a New Certificate, and then click Next. 8. The dialog box has the following two options: • Prepare the request now, but send it later This option is always available. • Send the request immediately to an online certification authority This option is available only if the Web server can access one or more Microsoft Certificate servers in a Windows 2000 Server or Windows Server 2003 domain configured to issue Web server certificates. Later on in the request process, you are given the opportunity to select an authority from a list to send the request to. 9. Click Prepare the request now, but send it later, and then click Next. 10. Type a descriptive name for the certificate in the Name field, type a bit length for the key in the Bit length field, and then click Next. The wizard uses the name of the current Web site as a default name. It is not used in the certificate but acts as a friendly name to help administrators. 11. Type an organization name (such as Contoso) in the Organization field and type an organizational unit (such as Sales Department) in the Organizational unit field, and then click Next. Note This information will be placed in the certificate request, so make sure it is accurate. The CA will verify this information and will place it in the certificate. A user browsing your Web site will want to see this information in order to decide if they should accept the certificate. 12. In the Common name field, type a common name for your site, and then click Next. Important The common name is one of the most significant pieces of information that ends up in the certificate. It is the DNS name of the Web site (that is, the name that users type in when browsing your site). If the certificate name doesn't match the site name, a certificate problem will be reported when users browse to the site. If your site is on the Web and is named www.contoso.com, this is what you should specify for the common name. If your site is internal and users browse by computer name, enter the NetBIOS or DNS name of the computer. 13. Enter the appropriate information in the Country/Region, State/province, and City/locality fields, and then click Next. 14. Enter a file name for the certificate request. ODOT-OSP Connection Specification 69 Online 0.U5INES5 SYSTEMS The file contains information similar to the following. - ---BEGIN NEW CERTIFICATE REQUEST--= MIIDZjCCAs8CAQAwgYoxNjAOBgNVBAMTLW1penJvY2tsYXBOb3Aubm9ydGhhbWVyA... — -END NEW CERTIFICATE REQUEST— This is a Base 64 encoded representation of your certificate request. The request contains the information entered into the wizard and also your public key and information signed with your private key. This request file is sent to the CA. The CA then uses your public key information from the certificate request to verify information signed with your private key. The CA also verifies the information supplied in the request. After you submit the request to a CA, the CA sends back a certificate contained in a file. You would then restart the Web Server Certificate Wizard. 15. Click Next. The wizard displays a summary of the information contained in the certificate request. 16. Click Next, and then click Finish to complete the request process. The certificate request can now be sent to a CA for verification and processing. After you receive a certificate response from the CA, you can continue and install the certificate on the Web server, once again by using the IIS Certificate Wizard. 3.0 Submit a Certificate Request This procedure uses Microsoft Certificate Services to submit the certificate request generated in the previous procedure. To submit a certificate request 1. Use Notepad to open the certificate file generated in the previous procedure and copy its entire contents to the clipboard. 2. Start Internet Explorer and navigate to http:// hostname/CertSrv, where hostname is the name of the computer running Microsoft Certificate Services. 3. Click Request a Certificate, and then click Next. 4. On the Choose Request Type page, click Advanced request, and then click Next. 5. On the Advanced Certificate Requests page, click Submit a certificate request using a base64 encoded PKCS#10 file, and then click Next. ODOT-OSP Connection Specification 70 Online BUSMUSSYSTEGIS 6. On the Submit a Saved Request page, click in the Base64 Encoded Certificate Request (PKCS #10 or #7) text box and press CTRL+V to paste the certificate request you copied to the clipboard earlier. 7. In the Certificate Template combo box, click Web Server. 8. Click Submit. 9. Close Internet Explorer. 4.0 Issue the Certificate To issue the certificate 1. Start the Certification Authority tool from the Administrative Tools program group. 2. Expand your certificate authority, and then select the Pending Requests folder. 3. Select the certificate request you just submitted. 4. On the Action menu, point to All Tasks, and then click Issue. 5. Confirm that the certificate is displayed in the Issued Certificates folder, and then double- click it to view it. 6. On the Details tab, click Copy to File, and save the certificate as a Base -64 encoded X.509 certificate. 7. Close the properties window for the certificate. 8. Close the Certificate Authority tool. 5.0 Install the Certificate on the Web Server This procedure installs the certificate issued in the previous procedure on the Web server. To install the certificate on the Web server 1. Start Internet Information Services, if it's not already running. 2. Expand your server name and select the Web site for which you want to install a certificate. 3. Right -click the Web site, and then click Properties. 4. Click the Directory Security tab. 5. Click Server Certificate to launch the Web Server Certificate Wizard. 6. Click Process the pending request and install the certificate, and then click Next. 7. Enter the path and file name of the file that contains the response from the CA, and then click Next. 8. Examine the certificate overview, click Next, and then click Finish. ODOT-OSP Connection Specification 71 ( Online DUSINC$S SYSTCMS A certificate is now installed on the Web server. 6.0 Configure Resources to Require SSL Access This procedure uses Internet Services Manager to configure a virtual directory to require SSL for access. You can require the use of SSL for specific files, directories, or virtual directories. Clients must use the HTTPS protocol to access any such resource. To configure resources to require SSL access 1. Start Internet Information Services, if it's not already running. 2. Expand your server name and Web site. (This must be a Web site that has an installed certificate.) 3. Right -click a virtual directory, and then click Properties. 4. Click the Directory Security tab. 5. Under Secure communications, click Edit. 6. Click Require secure channel (SSL). Client's browsing to this virtual directory must now use HTTPS. 7. Click OK, and then click OK again to close the Properties dialog box. 8. Close Internet Information Services. 7.0 Configure the Web Service Virtual Directory to Require SSL Your Web service runs on Internet Information Services (IIS) and relies on IIS to provide SSL support. To use IIS to configure your Web service's virtual directory for SSL 1. On the Web service host computer, start IIS. 2. Navigate to the <WebService> virtual directory. 3. Right -click <WebService>, and then click Properties. 4. Click the Directory Security tab. 5. Under Secure communications, click Edit. If Edit is unavailable, it is likely that a Web server certificate is not installed. 6. Select the Require secure channel (SSL) check box. 7. Click OK, and then OK again. ODOT-OSP Connection Specification 72 Online BUSIt<ESS SYSTEMS 8. In the Inheritance Overrides dialog box, click Select All, and then click OK to close the <WebService> properties dialog box. This applies the new security settings to all subdirectories in the virtual directory root. 8.0 Test the Web Service Using a Browser This procedure ensures that the Web server certificate is valid and has been issued by a Certification Authority (CA) that is trusted by the client computer. To call the Web service using SSL from Internet Explorer 1. Start Internet Explorer on the client computer and browse (using HTTPS) to the Web service. For example: https://WebServer/<VirtualDirectory>/<WebService>.asmx; The Web service test page should be displayed by the browser. 3. If the Web service test page is displayed successfully, close Internet Explorer and go to Procedure 9, "Develop a Web Application to Call the Serviced Component." 4. If the Security Alert dialog box, as illustrated in Figure 1, is displayed, click View Certificate to see the identity of the issuing CA for the Web server certificate. You must install the CA's certificate on the client computer. This is described in Procedure 9, "Install the Certificate Authority's Certificate on the Client Computer." 5. Close Internet Explorer. Information you exchange with this site cannot be viewed or changed by others. However, there is a problem with the site s security certificate. The security certificate was issued by a companyYou have not chosen to trust. Vie" the certificate to determine tehether';, you want to trust the certifying authority. The security certificate date is valid. The security certificate has a valid name matching the name of the page you are trying to view. Figure 1. Security Alert dialog box ODOT-OSP Connection Specification 73 Online BUSINESS SYSTEMS 9.0 Install the Certificate Authority's Certificate on the Client Computer This procedure installs the issuing CA's certificate on the client computer as a trusted root certificate authority. The client computer must trust the issuing CA in order to accept the server certificate without displaying the Security Alert dialog box. If you use Microsoft Certificate Services as a CA within your Windows domain Perform this procedure only if your Web server certificate was issued by a Microsoft Certificate Services CA. Otherwise, if you have the CA's .cer file, go to Step 8. 1. Start Internet Explorer and browse to http:// hostname/certsrv, where hostname is the name of the computer where Microsoft Certificate Services that issued the server certificate is located. 2. Click Retrieve the CA certificate or certificate revocation list, and then click Next. 3. Click Install this CA certification path. 4. In the Root Certificate Store dialog box, click Yes. 5. Browse to Web service using HTTPS. For example: https: //WebServer/<VirtualDirectory>r/<WebService>. asmx The Web service test page should now be correctly displayed by the browser, without a Security Alert dialog box. You have now installed the CA's certificate in your personal trusted root certificate store. To be able to call the Web service successfully from an ASP.NET page, you must add the CA's certificate to the computer's trusted root store. 7. Repeat Steps 1 and 2, click Download CA certificate, and then save it to a file on your local computer. 8. Now perform the remaining steps, if you have the CA's .cer certificate file. 9. On the taskbar, click Start, and then click Run. 10. Type mmc, and then click OK. 11. On the Console menu, click Add/Remove Snap -in. 12. Click Add. 13. Select Certificates, and then click Add. 14. Select Computer account, and then click Next. 15. Select Local Computer: (the computer this console is running on), and then click Finish. 16. Click Close, and then OK. ODOT-OSP Connection Specification 74 Online BUSINESS SYSTEMS 17. Expand Certificates (Local Computer) in the left pane of the MMC snap -in. 18. Expand Trusted Root Certification Authorities. 19. Right -click Certificates, point to All Tasks, and then click Import. 20. Click Next to move past the Welcome dialog box of the Certificate Import Wizard. 21. Enter the path and filename of the CA's .cer Ole. 22. Click Next. 23. Select Place all certificates in the following store, and then click Browse. 24. Select Show physical stores. 25. Expand Trusted Root Certification Authorities within the list, and then select Local Computer. 26. Click OK, click Next, and then click Finish. 27. Click OK to close the confirmation message box. 28. Refresh the view of the Certificates folder within the MMC snap -in and confirm that the CA's certificate is listed. 29. Close the MMC snap -in. ODOT-OSP Connection Specification 75 Online BUSINESS SYSTEMS APPENDIX B: ENTERPRISE LOGGING LIBRARY 10.1 Introduction The following is the text of an article on the Microsoft Enterprise Library. 10.2 Overview The patterns & practices Enterprise Library is a library of application blocks designed to assist developers with common enterprise development challenges. Application blocks are a type of guidance, provided as source code that can be used "as is," extended, or modified by developers to use on enterprise development projects. This release of Enterprise Library provides similar functionality to the previous releases for the .NET Framework 1.1; however, Enterprise Library has been redesigned to use the new capabilities of the .NET Framework 2.0. Enterprise Library -January 2006 contains the following general purpose application blocks: • Caching Application Block. With this application block, developers can incorporate a local cache in their applications. • Cryptography Application Block. With this application block, developers can incorporate hashing and symmetric encryption in their applications. • Data ccess Application Block. With this application block, developers can incorporate standard database functionality in their applications. • Exception Handling Application Block. With this application block, developers and policy makers can create a consistent strategy for processing exceptions that occur throughout the architectural layers of enterprise applications. • Logging Application Block. With this application block, developers can include standard logging functionality in their applications. • Security Application Block. With this application block, developers can incorporate authorization and security caching functionality in their applications. Enterprise Library also includes a set of core functions, including configuration, instrumentation, and object builder services. These functions are used by all other application blocks." The Enterprise Library 2.0 Logging Application Block makes logging various application events in your winform and web applications a snap. Before we dig into implementation specifics of the Logging Application Block, we first need to understand the importance and role of TraceListeners. ODOT-OSP Connection Specification 76 Online US1tiC$5 SYSTEMS 10.3 TraceListeners The heart of the Enterprise Library 2.0 Logging Application Block is its TraceListeners, which are essentially the conduit for which event messages get to their intended destinations. Enterprise Library 2.0 provides the following TraceListeners: • Database TraceListener • Email TraceListener • Flat File TraceListener • Formatter Event Log TraceListener • Msmq TraceListener • System Diagnostics TraceListener • WMI Trace Listener The usefulness of each TraceListener is fairly obvious. You would use the Database TraceListener to log trace messages to a database. The Email TraceListener is for sending trace messages via email. You get the idea. All of the Enterprise Library 2.0 TraceListeners derive from the base TraceListener Class that is a part of the .NET 2.0 Framework. 10.4 Original Method The TraceListeners in the Logging Application Block work similar to the TraceListeners in the .NET 2.0 Framework. If we use the Flat File TraceListener as an example, its use is not much different than the TraceListener Class it derives from - the TextWriterTraceListener Class in System.Diagnostics. One can use the TextWriterTraceListener Class to output trace information to a text file with some really simple code: // Create a. log- ti.7.e Stream logFile = File.Create ("Tr- ceO:Lput;. .c;q") ; // Create the TextWriterTraceListener TextWriterTraceListener listener = new TextWriterTraceListener(logFile); // Add the listener to the list of Trace. Listeners.Add(listener); // Output. the message Trace.Write("Sy log message"); // Flush the output. Trace. Flush(); aceListeners The code above programmatically adds a new TextWriterTraceListener to the Trace Class' Listener Collection which means that any messages sent via ODOT-OSP Connection Specification 77 Online BUSINESS SYSTEMS Trace.Write or Trace.WriteLine will now also be logged to our log file, TraceOutput.Iog. However, nobody is going to write such code, because your app.config or web.config class allows you to define TraceListeners in it without touching a bit of code. This allows you to add and remove TraceListeners used by your application by manipulating your configuration file without changing a single line of code: <configuration> <system.diagnostics> <trace autoflush="false" indentsize="4"> <listeners> <add name="_ gFileL_. _ene_" type=S ss.a-.Dia7rosCi:s...xV; ri er:.raeTistexer" initializeData="TraceOu.nput ._og" /> </listeners> </trace> </system.diagnostics> </configuration> In the configuration snippet above, we have essentially defined a new TraceListener, LogFileListener, that outputs trace messages to our same log file, TraceOutput.log. The code in our application has now been abstracted from where the trace information is being saved and has been reduced to: // Output the message Trace .Write ("Mv log message") ; // Flush the cutr� Trace. Flush(); 10.5 Enterprise Library Application Blocks The new Exception Handling Application Block that ships with the Enterprise Library 2.0 has undergone huge improvements since the release of the old Exception Management Application Block. To use this block effectively, you need to absorb three main concepts: Exception Handling is the process of doing something with an exception when the exception is detected by your code. Exception Logging is the process of logging an exception, which might include sending formatted exceptions to the event log or sending an email message. The exception handling block makes use of the Logging and Instrumentation application block for this purpose. Exception Policies allow you to control exception handling and logging behaviors using external configuration files instead of baking such rules into your code. In other words, you can define the exception handling in a policy file and then change the behavior to accommodate the differing exception -handling needs during testing, debugging, and production scenarios without changing your code. ODOT-OSP Connection Specification 78 online BUSINESS SYSTEMS Using the exception handling block, there are three things you can do when you detect an exception in your code: You can wrap the exception in a new exception to add new context information or detail. The original exception is still available through the InnerException property when the new exception is propagated up the call stack. You can replace the exception with a new exception. You typically do this when you don't want the details of the original exception to be propagated across an application boundary. You can log the exception. Of course, you can do this in combination with wrapping or replacing the exception, or you can log the original exception and propagate the original up the call stack. 10.6 Using the Exception Handling & Logging Block After installing the Enterprise Library, you can start writing code against the Exception Handling Block. To use the exception handling block successfully, follow these steps: • Add reference to Microsoft.Practices.EnterpriseLibrary.Common.dll • Add reference to Microsoft. Practices. EnterpriseLibrary. ExceptionHandling. dll • Add reference to Microsoft. Practices. EnterpriseLibrary. ExceptionHandling. Logging. dll To catch unhandled exceptions in the web service add a Global Application File ( Global.asax) to the website: Enter the following code into Application_Error: <%@ Application Language="C:;#" %> <%@ Import Namespace="Microsoft.Prac'ices.EnterpriseLibrary.Loggin " <script runat="ser.ver"> void Application_Error(object sender, EventArgs e) { HandleException(e.Exception, "Unhandled Policy"); } </script> Enter the following code into the Global.asax: public static void HandleException(Exceptior: ex, string policy) { Boolean rethrow = false; try { ODOT-OSP Connection Specification 79 online COSINESS SYSTEMS policy); Rethrow = Exception _'o icy.HandleException(ex, } catch (Exceot:i_on innerEx) { Throw ex; } if (rethrow) { } Throw ex; } Once I create the Web Service in Visual Studio 2005, I immediately open up the Enterprise Library Configuration Tool and use it to open the existing web.config file. Using only the tool, I then add the logging application block configuration section to web.config, remove all the defaults, and replace them with a simple FlatFile TraceListener that catches all events. The Logging Application Block has a Special Source, called All Events. Hooking a TraceListener to this event guarantees you will receive all events not being filtered. Since we have no filters, we get all events. These events get logged to the FlatFile TraceListener, which points to a log file at the root of my website, called trace.log ( default name ). ODOT-OSP Connection Specification 80 Online BUSINESS SYST[MS ',file Action :'Help '=- Enterprise. Library Configuration i c.ldevlodotldocsr tocs phase 2\completed. Eij Data Access Application Block i -t=' Connection Strings 1.ts Connection String 'frDatabase 1 Server Integrated Security Custom. Provider Mappings Exception Handling Application Block i7-3 Exception Policy 'NeS Exception c:.® Logging Handler q'r Notify Policy '..� Exception • 4 Logging Handler Logging Application Block Lt. Filters t.. Category Sources Notify Email TraceListener >, Log -€yT FlatFile TraceListener Special Sources •P Logging Errors: & Warnings lJnprocessed Category A' All Events .i. Trace Listeners • Database Trace Listener Email TraceListener FlalFile TraceListener s"tis> Formatters 't LogFile -�, Email _8 General deliverablestdrattsi AddCategorySteredProcedure Formatter Name TraceOulputOptions WrlteLogS toredPrecedureNarne AddCategory Connection String (none) Database Trace Listener None WriteLog ` Databaselnatance Gets or sets the database instance to use, ContigurationErryas '. Name Y Probed;:.De Remove carrent nodes e nett Figure 1: Enterprise Library Configuration Tool ODOT-OSP Connection Specification 81 Online 555155555 SYSTEMS 11.1 Purpose IX C: ADDING NEW PARTNERS The purpose of this appendix is to provide an example of the scope of work that would be required to add new partners into the existing architecture or the PDCC/ODOT Enterprise Service Bus (ESB). 11.2 Overview Although the current PDCC architecture as well as he proposed ODOT solution are both design to maximize both horizontal and vertical scalability, they do not yet support the dynamic addition of new partner to the ESB. In order to add new partners, certain configuration changes must be made to allow the partners to participate in the message exchanges supported by both the PDCC. In general, the steps required to add new partners include: • A new partner must have the ability to connect to the PDCC architecture. This may require communication or network infrastructure changes by the new partner as well as the PDCC. • Each new partner must have the ability to support the message formats required by the exchanges. This will require any new partner to either "speak" these formats natively, or use a customized version of the endpoint being developed for ODOT to support the translation from their native format into the standards based format required by the existing message exchanges. • A connector must be configured on the ESB for the new partner. Because most exchanges consist of two-way communication, the ESB must be configured with the new partners connection information and vice versa. • Routing logic on the ESB must be updated to support the new partner. This is a minor update to the Content Based Routing logic that is currently deployed to the ESB. • An updated list of valid partners must be distributed to all partners. There is an existing message exchange on the ESB that supports this requirement. ODOT-OSP Connection Specification 82 jnline BUSINESS SYSTEMS APPENDIX D: UNIT TASK CROSS REFERENCE The following matrix matches the business scenarios discussed in Section 2.0 to the ODOT Unit Tasks: SCOPE OF THE INTERFACE Unit Task Description E E 0 E E 0 f ¥ q \�\ ql . ?� 2 � \ G 2� ? 0 1X 0_— O §« '�S • � m2 16 0 \EL_ C " e 01 ■ »__ X202 / E <�� (21- @ / E O 202 r®E� • (l0N\f {�\ / / f ƒ e a CO CO ODOT-OSP Connection Specification a)c rn0.) :.. X,_r0 0 O E m ,"...> ,_ .-, a) c -p ;? 0 0co O> w V O c to 10 VICO a) 47 11 th a) L R s_ c o L a) u c'c'�ocnm0� .�.- L >— c.0 MI u�-c0R3ra 02,Ea) c 0 c J w c o w w M• O R co W oo o - O • >u G > u Vtn ) _v Qce c" 0a) '. a) 1 u ni E a a°' O 0 C D fQ O 0 O 4" • N a� E 0 W a) 0) u) m a)a) z2 c ui o •N 'u c Mw U m � 0 O ;s- U 0 • >`C c (0 o° c 3 —m) � L c4-' o� > a E m a) 4-, O E a) QJ -0 >,(13 E, Mr m°) O E -o S- C°)w o CU Oov 01 y k L N d c U O c c � -a v c - o wn > O .u.0 ave a) E 0 a a 0 0 E E X 0 0) QJ z ui N C N • >a)3 a) a) - a) aic=c pro'- 03 c v -2m c i:' o o a L - E c • �ac > • c L 0 u o E '6vai>o w 02 MM a),., �O cn c c ) E °4, o4,c ���ca) CO r0.0 vi a>) L O a a 7 71- ••,1 - CO ODOT-OSP Connection Specification 4.0 0 c 0) 0 0 w 41) a) a N fN a) n3 a) C a) V 0) tit 4- a) O N 2 (I) C - a a) ▪ Ea)c • E 7,-, E. a) (na) a) E p1 c6.,'> 4E' 4g C >" O a) a) O cCQ)-o�,n L CL °1� Z ) o (i)- -D • C j a) N cn m • 47, U V) C a) a) O M aT a-• n3 > •- L i U C C U C N C N N �U>-)�L CO 7 �0E a) u) (TsE • 0...c t o L O 0. a 0) 111:' w N r t!) kO co .-Z co 0 Lfl tO c 13 a) U L C E E c 0 c� rc▪ s 0 a I N N CU rn m a) 0 •V H .0 � a., cp C w C aC)acUCW.,L 2a), a) CU O a) 0 B V,-UCF N 0 - w- 0.0 U C C a) (ti C 10 • a) j3 w .,., a) - a, 10 • C CU Ca) >, c0 a) a) a) -fl ;—, U - V Q) U) a) _?• N a) a) >,> 2-o 2 (6.0 U 00(1)00-,, •� i U N a) 03 U > • N a) a) o to o L a) C a) ,c.6_,,,-0.0,.) N • .,_i c c N u)— (004,00 Lt„_ECci (ti )a) ,oaa))3cu000C> n3 L n3 a N CO ODOT-OSP Connection Specification 0 O a) a) ▪ 0 N X > c O a) a_ O 3 0 0 U - a . 0 _ tn5 ro c O O L a) 73 z O N N a) 71 a) ro raV)a)01 _O .> U ) U 4 U U a) ro(43 U O v� � E a) • L aO rsiti OF - a) u) 0 o co o�E�ov� O vcCU $Era " 0 H U > O ▪ 04 o) c0 0 (00_J c c o - V)0 c 7 a) a) N -• 0 C5. "0(7 L 1-• -iHz 7Nc. fp Q a) U pyv : N N L O U O c ._ c m 'c a) U) w- U - o cn a1) aci0 Q7 r :l.,o C12, oca,0Q)oa)) L6j` v�4 C "ooa� ���cErcoO�� E���v�� o L L �W > c m c c? m c 4- 4-, tZ � ��Emii.���Yooa)mo.>o c��°��� L cw o o 8� CU m 4_ > 0 - ms- -C av c c --4.t/) ,_, vow v u oIa� o m fl a�� i � cO L E E-�O= I - (I) n• oon coccn''�o'�ai �o� .�.+°� ° LTDC f6ao-> t- C v c • v c ra 'c c c •L L h g c wx c.0 0 V) ,' Qi c"+'a)L4-'�Ev�'i>,�m �E °.,�a)-o.0 ▪ .)c - - a)coL c is L�>— _ U.t:;:$3.c 'c r.,' �a)�ro,.,a)flEg)co oo .�, �.. a� a>i ro0 c°1o�t�n °'a a E rca E axi•. _<0 ��c ° ro U m in ce L .,. .' o Q t 9-113 n10 ipi (n ODOT-OSP Connection Specification u u Uf o CU 6" 4j 0 cso w G) fC N W N Ln a) E 0 W c a) 1 -1-1 O . t0 Lf) w0 d' d' l0 ,--I Q L y rN1 N (n ,Ln -I l0 lO Unit Task Description v 0 v 0 .p cnp0cZ c =0_ C d '�CO . 0 ra • o O • ro N 0 L > ▪ H U 4- 0 O d fl > a) na V = Cu) @ It • O • •-6 o"— ✓ • 4 o 4 c▪ X c c a (1) .. C7 0 u .I 1 (f) .0 Y2 O N CU O h u v 0 0 •CcCCOa) � > a)O rn>-� ra0N11) ramoo' O 0 C (1) V rp V .• c ,-1 .t_lL r6 u C cw o E C+ O 0 0 O 0 .t.' L (j) 'r'' (1) O ) C O c -o .t.' • a) i' a) `+-- C r4 p >. E = rn V4.0 V B a-+ N U �O +-, C a) O Ol, co o ro res ESL—oro®0a>i®a) C 0 a - U n i 0 .> O -CIC ro ro 4.0 4 (n O 4-, C -a L U a) °a.�� u c0 > Z„ U) O V a) C L a) - 0 c> O N a) r0 O u C (n ris 1:3C • 6 - 1-13 N C .(„pc a,(1) s-p 0 a) a) rp 4_, N N 4-, m▪ @'-'�(1)�0°_-•r)—'> tri o u c'"'� c Ego ra a) E a- m C a 0 (1) E;°+�Q v (.>; (% u cn ro +� a) �v v 0 0D E (1) >- O 6 a) C rL0 _C p .- O E _C c c o_ a,, 0• _C N p • N o> O c Q u) C -0 O >< 0a>)a)rco0cuoa"c U V a-' a) 4' U) (n f6 (6 x O 0 L o 0 u 0 a ii v o Q vi O co U rp �O "O ro a"C-+ N O 4) 0. > a) NU = u CO a"' CZ w � �O N � 6 - C CZ N rd C O U) C (9 UJ (1112110 L C O a) ro• > (I) o Q u c0 CI) rn O 0 a. a r -I M CO ODOT-OSP Connection Specification V (1) 4 0 u c — -o L (a)» c�?c c�,o o c fl c S w ▪ • e4 a aO cn a► cn v i 44J C c �, CU > >— c > E Lu w '( ▪ D E }I .4-.' 44'L w w w U c o� L L L.0 O — - d' oo AN1Lry 1- .1.. I lO 0 '.0 L() sta x 0 +.' C L C O 2 03Q) c vra U to so C 174 (a CI) a-+w_c C 7 .0 3 0 Q 'O Q) O O o -0 C (0 4) 0 2 .ai O cn ) 0 C L .� V O v .0 C a) < j (n a')~ E >v(o Ems; L c E v C c E C O OU'5 OO O > L Q. Jam.+ U_ c U_ U no E >- Oni>C O o c c D-0 • > E Q • Q E E c ami o E�—?• EEa) Q 0 0 Q) C O o>u a) •5 oo O d' oo co c1 tr 0) L > o — U -'0) v .i c zv= U (I) 'a c 0 ACX tri O o>�-o .a (0 -o U 13 -O a..' C > O C 0 O -O U a-' O CU N > o a) -c a) (o U O V.4 -C QOM L V 0.0 C Q c 0_ 4? -3 E(O j—> C o� O Q) U N > � 0o N . Q) (6 < (0 L (/) 44' c 0U E Q) o c c QL 0 (o UO(6 To ra0 Ln W ODOT-OSP Connection Specification a) I L.O. EF IO- U�piO 2 L 1 L d-�-Q.(..'c U N O X C 1) Q L N r -I '.0 W d' d A u) L % n3 C O'0 c --0) >�zX(a(1) 0 u U cri as O a) 0 w- (p 1) u .0 u) ZU O. ._ >, O ) V C O "- C (OE C 'C p 1 E -o -a -a a) C 0 U O m N t/I O" . y_SH(r) Q E O Ec U LI) ,-i co o Ln 00 O '.0 No Messages 0 O c O 5' w_0 N 0-1 No Messages 0_ C (f) O_ 0 '-' !-> O 7173 no 0_ c U U u 0 0 E' j ( OL ,,,,,•Uo Ea ;a°' N .0 a-+ .0 a) NrC-id't-C+ 16 (6 O U C) C O C 0•a) -c (n 4-, o v I— >,L. O U 0.O (04.4— a) y a)O Ln 0 O f'- a) a) V N C no U~ C (CS 0p(13v(oa)-ooO.0 ++ if)nowE0ruu_oa-' a V f6 V ID Q.o of C O C C O -0 C O. O 'C L] O U U O 1 (I) UU a) n3 X N .D O c a) O .Hca3wc n3 nu nO (r) AI {0) N C 4-)C O O C (0 V U) H (J)a) c F > , 0 ._ 0) -,-.) tev > a) 0 '0 > L Q o) 0 i— (p O L (0 U O .E oma aa) is a, 3° a) abv0a)EL) )WLa)a) E CL) u) 0 0 Z N f 0 c : c 0 0 Q a)0 Eco a) 0 N C (a O L Q L O a) 0= U >.4-4 a) O U . U v) U 0 > F- a) C(c) U 0 0)U .- L > a)(0 4,cEa)- C 0 r6 0- -C (M¢0) o 0 0 0 0. 0. (1) N 0 'sa 0 a) ;° O ns RS O C 4-4 0 E C U A. C O C U W o V) J L � O � a) 0. O V) cn U °) V no 0 c no N 00 ODOT-OSP Connection Specification d y 0) z 3'3 E c o ▪ O v O I_ 0i v- (� i jroc u_ o U • U O o o O4-4 O- a- U O LU• > N v U O - U Q N V _0 > • a_+ > •— 0 N cno co c 0 '0. o E v c X o o 0 O H = 0 1, > c 0, 'C a„)• c = U t @ y c v >OLa)E O O z X L 0 ce 0 > > W W t) (L) 13) E ft?) o (1) Ui N Ack back from ESB CO rn N N 01 N 41 2 O • 0 a+ CO Q E E L U O N C H n c N 0 a' T.; c z 0 z ODOT-OSP Connection Specification SCHEDULE E FY 2008 Homeland Security Grant Program Application Instructions and Grant Guidance Deschutes_County_9- 1 - 1_Contract_2Apr 10 FY 2008 Application Instructions and Grant Guidance HOMELAND SECURITY GRANT PROGRAM OREGON EMERGENCY MANAGEMENT www.oregon.gov/OMD/OEM Mailing address: P.O. Box 14370 Salem, OR 97309-5062 Location address: 3225 State Street Salem, OR 97301 Application Due Date: 5:00 PM, Thursday, July 31, 2008 Table of Contents Introduction 1 Consolidation of Law Enforcement Terrorism Prevention —Oriented Activities 1 Federal Funding Priorities 1 HSPD-5 National Incident Management System (NIMS) 3 HSPD-8: National Preparedness 3 National Response Framework 4 Implement the National Infrastructure Protection Plan (NIPP) 4 FY 2008 Appropriations and Available Funds 4 Funding Distribution 5 Duration of Funding 5 Eligibility 5 Training Requirements 6 Exercise Requirements 6 Match Requirement 8 Supplanting 8 Application Due Date 8 Application Evaluation 9 State Homeland Security Program (SHSP) 10 Planning 10 Training 12 Exercise 13 Equipment 14 Personnel 14 Management and Administration 15 Law Enforcement Terrorism Prevention -Oriented Activities 16 Organizational 16 Planning 16 Training 17 Exercise 18 Equipment 18 Personnel 18 Management and Administration 18 Citizen Corps Program 19 Planning 19 Organizational 20 Training 21 Exercise 22 Equipment 22 Personnel 23 Management and Administration 23 Application Overview 24 Priorities for Funding 24 Application Contents 25 Part 1: Cover Sheet 25 Part 2: NIMS Compliance Form 26 Part 3: Project Justification Form 26 Part 4: Budget 30 Part 5: Appendices 30 Part 6: Regional Project — Base Contribution Form 30 Unallowable Costs 31 Suspension or Termination of Funding 31 Reporting and Reimbursements 32 Federal Conditions 33 Procurement Standards 37 Base Funding Distribution Table 38 Sample Budget 39 Overview of Allowable Costs 40 Planning 41 Organizational 41 Equipment 42 Training 43 Exercise 43 Management and Administrative (M&A) 44 Unauthorized Program Expenditures 44 FY 2008 Homeland Security Grant Program Application Introduction This year the Homeland Security Grant Program (HSGP) is again semi -competitive. Each state will receive a baseline allocation of 0.375 percent of the total allocation available nationwide with the remainder competitively distributed based on risk (threat, vulnerability, and consequence) and anticipated effectiveness. Consolidation of Law Enforcement Terrorism Prevention -Oriented Activities Per the 9/11 Act and FY 2008 Consolidated Appropriations Act, FY 2008 HSGP will not contain a separate line -item Law Enforcement Terrorism Prevention Program (LETPP). As is clear in this year's three overarching Homeland Security Grant Program (HSGP) priorities, a significant need for law enforcement terrorism prevention exists, particularly in the area of Improvised Explosive Device (IED) attack deterrence, prevention, and protection capabilities. As a result, States are required to ensure that at least 25 percent of their SHSP award funds are dedicated towards law enforcement terrorism prevention -oriented planning, organization, training, exercise, and equipment activities. Federal Funding Priorities Funding priorities for this year continue and further narrow the focus through risk-based funding and the capability -based planning process that DHS began three years ago. FY 2008 HSGP will focus on three objectives as its highest priorities. These three objectives are: 1. Measuring progress in achieving the National Preparedness Guidelines. 2. Strengthening improvised explosive device (IED) attack deterrence, prevention, and protection capabilities. 3. Strengthening preparedness planning. 1. Measuring Progress in Achieving the National Preparedness Goal. FEMA will continue in FY 2008 to tie together the established priorities and objectives of the National Preparedness Guidelines with efforts to further establish target capabilities, conduct joint federal -State assessments, and make adjustments to better ensure that our investment is yielding measurable improvements in our nation's preparedness. 2. Strengthening IED Attack Deterrence, Prevention, and Protection Capabilities. This provision aligns with the National Priority to Strengthen CBRNE Detection, Response, and Decontamination Capabilities as outlined in the National Preparedness Guidelines. The priority supports the policy outlined in Homeland Security Presidential Directive 19 "Combating Terrorist Use of Explosives in the United States" (HSPD-19) by emphasizing the need for States and Urban Areas to take a more proactive approach to reducing the threat of a terrorist explosive attack. Oregon Emergency Management 1 FY 2008 Homeland Security Grant Program Application 3. Strengthening Preparedness Planning This provision aligns with the National Priority to Strengthen Planning and Citizen Preparedness Capabilities as outlined in the National Preparedness Guidelines and supports the Planning Annex to HSPD-8 "National Preparedness." State and local jurisdictions must engage in comprehensive national and regional planning processes that seek to enhance emergency management capabilities through strengthened national and regional relationships and the allocation of resources toward preparedness planning. FY 2008 State Homeland Security Program (SHSP) The State Homeland Security Program (SHSP) is a core assistance program that provides funds to build capabilities at the State and local levels and to implement the goals and objectives included in State Homeland Security Strategies and initiatives in the State Preparedness Report. Activities implemented under SHSP must support terrorism preparedness by building or enhancing capabilities that relate to the prevention of, protection from, or response to terrorism in order to be considered eligible. However, many capabilities which support terrorism preparedness simultaneously support preparedness for other hazards. Subgrantees must demonstrate this dual -use quality for any activities implemented under this program that are not explicitly focused on terrorism preparedness. Use of SHSP funds must be consistent with, and supportive of, implementation of the State Homeland Security Strategy and State Preparedness Report. Linkages between specific projects undertaken with SHSP funds and strategic goals and objectives will be highlighted through regular required reporting mechanisms, including the Biannual Strategy Implementation Report (BSIR). FY 2008 Citizen Corps Program (CCP) Oregon's allocation of FY 2008 CCP funds is $217,269. Federal allocations were determined using the USA Patriot Act formula with the balance distributed on a population -share basis. The Citizen Corps Program is not part of the Federal competitive award process. However, even though the CCP is non-competitive at the Federal level, it will still be competitively awarded at the State level and must be included in your application. The Citizen Corps mission is to bring community and government leaders together to coordinate the involvement of community members in emergency preparedness, planning, mitigation, response, and recovery. The FY 2008 CCP funds provide resources for States and local communities to: 1) bring together the appropriate leadership to form and sustain a Citizen Corps Council; 2) develop and implement a plan or amend existing plans to achieve and expand citizen preparedness and participation; 3) conduct public education and outreach; 4) ensure clear alerts/warnings and emergency communications with the public; 5) develop training programs for the public, for both all -hazards preparedness and volunteer responsibilities; 6) facilitate citizen participation in exercises; 7) implement volunteer programs and activities to support emergency responders; 8) involve citizens in surge capacity roles and responsibilities during an incident in alignment with the Emergency Support Functions and Annexes; and 9) conduct evaluations of programs and activities. Oregon Emergency Management 2 FY 2008 Homeland Security Grant Program Application HSPD-5: National Incident Management System (NIMS) The Department of Homeland Security (DHS) created the National Incident Management System (NIMS) as required under Homeland Security Presidential Directive (HSPD)-5. NIMS provides the framework for organizations to work together to prepare for, protect against, respond to, and recover from the entire spectrum of all -hazard events. To be eligible to receive FY 2008 HSGP funding, applicants must meet NIMS compliance requirements. Local and tribal governments are considered to be in full NIMS compliance if they have adopted and/or implemented the FY 2005, FY 2006 and FY 2007 compliance activities, as determined by the National Incident Management System Capability Assessment Support Tool (NIMSCAST). Additional information on achieving compliance is available through the FEMA National Integration Center (NIC) Incident Management Systems Division at: http:I/www.foma.gov/emergency/nims/. For FY 2008, the NIMSCAST will be the required means to report NIMS compliance. All subgrantees will be required to submit their compliance assessment via the NIMSCAST by September 30, 2008. Additionally for FY 2008, applicants are required Federally to have the necessary staff attend and complete ICS 300 by September 30, 2008, and must certify that they will comply with this requirement at the time application is made. Applicants in the State of Oregon are also required to have the necessary staff attend and complete ICS 400 by September 30, 2008, unless other arrangements for a reasonable extension are made between the applicant and the NIMS Point of Contact (POC) for the State of Oregon. Applicants must certify that they will comply with this requirement at the time of application. For additional information on NIMS requirements, please contact the State NIMS POC: Lonni Nicoll Domestic Preparedness Planner Oregon Emergency Management 503-378-2911 ext. 22233 Inicoll@oem. state. or. us. HSPD-8: National Preparedness On March 31, 2005, DHS issued the Interim National Preparedness Goal (the Goal) that establishes a vision for National Preparedness including National Priorities. The Target Capabilities List (TCL) identifies 37 capabilities integral to nationwide all -hazards preparedness, including acts of terrorism. Additional information about HSPD-8 can be found at: httpl/www.ojp.usdoj.gov/odp/assessmentslhspd8.htm. Oregon Emergency Management 3 FY 2008 Homeland Security Grant Program Application National Response Framework (NRF) The National Response Framework is a guide that details how the Nation conducts all -hazards response — from the smallest incident to the largest catastrophe. This document establishes a comprehensive, national, all -hazards approach to domestic incident response. The Framework identifies the key response principles, as well as the roles and structures that organize national response. It describes how communities, States, the Federal Government and private -sector and nongovernmental partners apply these principles for a coordinated, effective national response. In addition, it describes special circumstances where the Federal Government exercises a larger role, including incidents where Federal interests are involved and catastrophic incidents where a State would require significant support. It lays the groundwork for first responders, decision -makers and supporting entities to provide a unified national response. Additional information about the NRF can be found at: http://www.fema.govIemergencyhyft Implement the National Infrastructure Protection Plan (NIPP) The National Infrastructure Protection Plan and supporting Sector -Specific Plans (SSPs) provide a coordinated approach to critical infrastructure and key resources (CI/KR) protection roles and responsibilities for federal, state, local, tribal, and private sector security partners. The NIPP sets national priorities, goals, and requirements for effective distribution of funding and resources which will help ensure that our government, economy, and public services continue in the event of a terrorist attack or other disaster. More information about the NIPP can be found at: httpl/www.dhs.govIxprevprot/programs/ediforial 0827.shtm. FY 2008 Appropriations and Available Funds The Implementing Recommendations of the 9/11 Commission Act of 2007 (hereafter "9/11 Act") and FY 2008 Consolidated Appropriations Act, FY 2008 HSGP set aside: • $862,900,000 for State Homeland Security Program (SHSP) grants. • $781,600,000 for Urban Areas Security Initiative (UASI) grants. Oregon's share of the FY 2008 appropriation is a combination of two components: a baseline allocation of $3,235,875 and a risk- and need -based allocation as determined by a risk score and competitive peer -review process of the State's application. Final allocations for each State and Urban Area will not be announced until approximately August 1, 2008. Similar to previous years, 80 percent of the SHSP allocations must benefit local units of government. There is no minimum pass-through requirement for CCP. Oregon Emergency Management 4 FY 2008 Homeland Security Grant Program Application Funding Distribution This year the State will provide funding to each county based on a two part formula comprised of a standard county base allocation and a population based allocation. Of the 80 percent required to support local capabilities, 5 percent will be awarded for tribal projects, the remaining funds will be allocated based on population (60 percent), and as a standard county base (40 percent). Funds received by the State above the Federal base allocation will be used to support regional projects (involving more than one county) and will be awarded through a competitive peer -review process. For a base funding breakout see page 39. Duration of Funding Successful applicants will be awarded a grant for a period of 32 months commencing approximately October 1, 2008 and ending May 31, 2011. Proposed projects must be completed within the 32 -month period of performance. Projects that cannot be completed by May 31, 2011 will not be selected for funding. Eligibility Eligible applicants include local and tribal units of government; and only these agencies are eligible to receive a direct award. As defined in the Conference Report accompanying the DHS Appropriations Act of 2008, the term "local unit of government" means "any county, city, village, town, district, borough, parish, port authority, transit authority, intercity rail provider, commuter rail system, freight rail provider, water district, regional planning commission, council of government, Indian tribe with jurisdiction over Indian country, authorized Tribal organization, Alaska Native village, independent authority, special district, or other political subdivision of any State." Eligibility for Urban Areas Security Initiative (UASI) Jurisdictions Oregon jurisdictions defined in the Portland urban area/Urban Areas Security Initiative Grant program (City of Portland, Multnomah County, Washington County, Clackamas County, and Columbia County) are eligible to apply for SHSP and CCP funds. Oregon Emergency Management 5 FY 2008 Homeland Security Grant Program Application Training Requirements All training under the grant programs must be coordinated through the Domestic Preparedness Training Coordinator at Oregon Emergency Management (OEM): Jim Adams Domestic Preparedness Training Coordinator Oregon Emergency Management 503-378-2911 ext. 22232 jadams@oem.state.or.us Coordination of training, including verification that the training is allowable, must be completed after training awards are announced and before training funds are obligated. Failure to follow this process may result in denial of reimbursement requests. Grant recipients may, in most cases, use these funds to pay for training and training related costs. The target audience for training courses includes emergency preparedness, prevention and response personnel, emergency managers, and public/elected officials within the following disciplines: fire service, law enforcement, emergency management, emergency medical services, hazardous materials, public works, public health, health care, public safety communications, governmental administrative, cyber security, and private security providers. The homeland security training program can include training for citizens in awareness, preparedness, prevention, response skills, and volunteer activities. This training should be coordinated through state and local Citizen Corps Councils. Exercise Requirements Exercises conducted with FEMA support and using HSGP funding must be: • Managed and executed in accordance with the Homeland Security Exercise and Evaluation Program (HSEEP). HSEEP Volumes 1-111 contain guidance for exercise design, development, conduct, evaluation and improvement planning. HSEEP Volume IV provides sample exercise materials and HSEEP Volume V: Prevention Exercises, contains guidance and recommendations for designing, developing, conducting, and evaluating prevention focused exercises. All volumes can be found at: http://hseep.dhs.gov. • NIMS compliant. More information is available online at the NIMS Integration Center (NIC) Incident Management Systems Division httpJ/www.fema.gov/emergency/nims/index.shtm. Exercise Scenarios Scenarios used in HSGP-funded exercises must be based on the State's/Urban Area's Homeland Security Strategy and plans. Acceptable scenarios for exercises include: chemical, biological, radiological, nuclear, explosive, cyber, agricultural and natural or technological disasters. Exercise scenarios must be catastrophic in scope and size, as defined by the National Response Framework and should align with a national planning scenario. Oregon Emergency Management 6 FY 2008 Homeland Security Grant Program Application The scenarios used in HSGP-funded exercises must focus on validating existing capabilities and must be large enough in scope and size to exercise multiple tasks and warrant involvement from multiple jurisdictions and disciplines and non-governmental organizations. Exercise scenarios should also be based on the Multi-year Training and Exercise Plan. Exercise Evaluation All exercises must be performance-based and evaluated. An After -Action Report/Improvement Plan (AAR/IP) must be submitted to OEM, following every exercise, regardless of type or scope. AAR/IPs must conform to the HSEEP format, should capture objective data pertaining to exercise conduct, and must be developed based on information gathered through Exercise Evaluation Guides (EEGs) found in HSEEP Volume IV. All applicants are encouraged to use the Lessons Learned Information Sharing System, w.LL1S.gov, as a source for lessons learned and to exchange best practices. Draft AAR/IPs must be provided to OEM within 30 days following completion of each exercise (see HSEEP Volume IV for sample AAR/IP template). Final AAR/IPs must be submitted to OEM within 60 days for submission to FEMA. AAR/IPs must be submitted to OEM in electronic format with a printed copy optional. Role of Non -Governmental Entities in Exercises Non-governmental participation in all levels of exercises is strongly encouraged. When/where applicable nongovernmental entities should be included in the planning, conduct, and evaluation of an exercise. Local jurisdictions are encouraged to develop exercises that test the integration and use of non-governmental resources provided by non-governmental entities, defined as the private sector and private non-profit, faith -based, community, volunteer and other non-governmental organizations. Planning Exercise Requirement Any agency using Homeland Security funds for the purpose of creating/updating a plan (EOP, annex, SOP, etc.) must conduct an exercise within the performance period of the grant to evaluate the plan. The exercise must be facilitated and documented through the HSEEP process and documentation must be submitted to the OEM Exercise Coordinator. For additional assistance with exercise requirements contact: Doug Jimenez Domestic Preparedness Exercise Coordinator Oregon Emergency Management 503-378-2911 ext. 22248 djimenez@oem.state.or.us Oregon Emergency Management 7 FY 2008 Homeland Security Grant Program Application Match Requirement There is no match requirement for the State Homeland Security Program or Citizen Corps Program. However, there is the potential for future grant programs to be impacted by cash match requirements as early as FY 2009. Supplanting Federal funds may not supplant, replace, or offset State or local funds, but will be used to supplement the amount of funds that, in the absence of Federal funds, would be made available for purposes consistent with the Homeland Security Grant Program. Application Due Date One original and nine copies (10 total) of the application must be received by Oregon Emergency Management no later than 5:00 PM, Thursday, July 31, 2008. Applicants are fully responsible for the timely delivery of grant applications to OEM. Late applications, facsimile copies, or post due date modifications to meet minimum qualifications will not be accepted. Mailing and Hand -Delivery Addresses Oregon Emergency Management Phone: 503-378-2911 US Mail P.O. Box 14370 Salem, OR 97309-5062 UPS/FedEx/Hand Delivered 3225 State St., Room 115 Salem, OR 97301 Oregon Emergency Management FY 2008 Homeland Security Grant Program Application Application Evaluation OEM will conduct a review of applications to determine whether the proposal meets the application minimum qualifications. Competitive regional projects will be reviewed by representatives from the statewide Domestic Preparedness Working Group. The group will conduct a comprehensive, fair, and impartial evaluation of the responses received to this solicitation. The applicant's failure to comply with the instructions or to submit a complete proposal will result in it being deemed non-responsive. Applications may be deemed non- responsive for the following reasons: 1. Late applications. Applications must be received (not post -marked) by 5:00 PM Thursday, July 31, 2008. 2. Missing or incomplete Cover Sheet(s) or Project Justification form(s). 3. Missing or incomplete project budgets. 4. Projects inconsistent with the identified investment areas. 5. No evidence of NIMS compliance (NIMS form not completed/submitted). Only those applications meeting eligibility criteria and determined to be responsive to the minimum qualifications will be considered for further evaluation. The grant award recommendations will be forwarded to the Director of Oregon Emergency Management and the Adjutant General, who will make final award decisions. Oregon Emergency Management will notify applicants on or about September 15, 2008 with final award decisions. Funding decisions will be based on: 1. Overall response to the Project Justification form. Specifically, how well distinct and holistic projects were identified and how closely projects were aligned with the State's Strategy, State's Preparedness Report and the projects identified within the State's Investment Justifications. 2. How well the Project Justification supports the project and demonstrated need for the request. 3. Whether proposed projects are able to be implemented within the grant award period. 4. Whether projects will be sustained after grant funding expires. Oregon Emergency Management 9 FY 2008 Homeland Security Grant Program Application State Homeland Security Program (SHSP) Use of SHSP funds must be consistent with and supportive of implementation of the State Homeland Security Strategy. Linkages between specific projects undertaken with SHSP funds and strategic goals and objectives will be highlighted through regular required reporting mechanisms, including the Biannual Strategy Implementation Report (BSIR). The FY 2008 Homeland Security Grant does not include a separate funding stream for Law Enforcement Terrorism Prevention activities; however, at least 25 percent of the SHSP funding must support these activities. Allowable law enforcement activities are listed later in the guidance. Planning The State may facilitate all contracts for planning -related services that are identified in grant applications. Applicants who wish to receive funding for eligible planning projects that are facilitated by the State must agree to allow the state to maintain any approved funding for contract services as allowed by the FY 2008 guidance. If the State chooses to facilitate planning contracts, an agreement will be prepared for the subgrantee to sign authorizing the State to maintain the funding and facilitate the contractor/consultant portion of the proposed project. These funds will be earmarked from the 80 percent local share of the FY 2008 allocation. To ensure consistency among planning products, the State will facilitate an RFP process in which the subgrantee will participate and assist with the creation of a scope of work, review, and approval of service providers. Subgrantees will also assist in the review of reports, overall project direction, and financial review. Agencies receiving HSGP funds to create a plan (EOP, annex, SOP, etc.) must validate the plan through no less than a table top level exercise. The exercise must be conducted within the performance period of the grant, facilitated and documented through the HSEEP process, and submitted to the OEM Exercise Coordinator. Agencies must provide information in the project narrative and milestones indicating the scale and schedule of the exercise. If the agency chooses, they may request HSGP funds to support the exercise. These funds would be directly awarded to the agency. Questions regarding planning exercise requirements should be directed to the OEM Exercise Coordinator, Doug Jimenez (see additional information on pages 6-7). Other planning funds such as grant administration, travel, workshops, meetings, etc., may be provided directly to the applicant based on the proposed projects. Planning Related Costs SHSP funds may be used for a range of homeland security planning activities. Additional planning examples can be found in the Homeland Security Allowable Planning Guide at: http://www.fema.gov/pdf/government/grant/hsgp/fyO8 hsgp allowplanning.pdf. Oregon Emergency Management 10 FY 2008 Homeland Security Grant Program Application Following are some examples of allowable planning activities: Developing and implementing homeland security support programs and adopting DHS national initiatives including but not limited to the following: • Costs associated with the implementation and adoption of HSPD-8 initiatives. • Costs associated with the implementation and sustainment of NIMS. • Establishment or enhancement of mutual aid agreements. • Development of communications and interoperability protocols and solutions. • Development of related critical infrastructure terrorism prevention activities including: planning for enhancing security during heightened alerts, during terrorist incidents, and/or during mitigation and recovery. • Public information/education: printed and electronic materials, public service announcements, seminars/town hall meetings, web postings coordinated through local Citizen Corps Councils. • Citizen Corps activities in communities surrounding critical infrastructure sites, including Neighborhood Watch, Volunteers in Police Service, and other opportunities for citizen participation. • Evaluating Critical Infrastructure Protection (CIP) security equipment and/or personnel requirements to protect and secure sites. • CIP cost assessments, including resources (financial, personnel, etc.) required for security enhancements/deployments. Develop and enhance plans and protocols, including but not limited to: • Develop or enhance emergency operations plans and operating procedures. • Develop terrorism prevention/deterrence plans. • Develop plans, procedures, and requirements for the management of infrastructure and resources related to HSGP and implementation of State or Urban Area Homeland Security Strategies. • Develop public/private sector partnership emergency response, assessment, and resource sharing plans. • Develop or update local or regional communications plans. • Develop plans to support and assist specialized jurisdictions, such as port authorities and rail and mass transit agencies. • Develop or enhance continuity of operations and continuity of government (COOP/COG) plans. • Develop or enhance existing catastrophic incident response and recovery plans to include and integrate Federal assets provided under the National Response Plan. Develop or conduct assessments, including but not limited to: • Conduct point vulnerability assessments at critical infrastructure/key resource (CI/KR) sites and develop remediation/security plans. • Conduct cyber risk and vulnerability assessments. • Conduct assessments and exercises of existing catastrophic incident response and recovery plans and capabilities to identify critical gaps that cannot be met by existing local and state resources. • Identification of specific catastrophic incident response and recovery projected needs. Oregon Emergency Management 11 FY 2008 Homeland Security Grant Program Application Training FY 2008 SHSP funds may be used to enhance the capabilities of local and tribal emergency preparedness and response personnel through development of a State homeland security training program. Training Related Areas • Establishment of support for, conduct of, and attendance at preparedness training programs within existing training academies/institutions, universities, or junior colleges. Preparedness training programs are defined as those programs related to prevention, protection, response, and/or recovery from natural, technical, or manmade catastrophic incidents, supporting one or more Target Capabilities in alignment with national priorities as stated in the Goal. Examples of such programs include, but are not limited to, CBRNE terrorism, critical infrastructure protection, cyber security, and citizen preparedness. • Training to support enterprise -wide homeland security planning, to include participation from non-governmental entities. • Training to support the National Infrastructure Protection Plan. • Training in interoperable communications. • Training to support regional collaboration, to include non-governmental entities. • Training to support intelligence fusion and information sharing activities. • Training to support citizen preparedness and citizen volunteer support through Citizen Corps Councils. Training Related Costs Funds used to develop, deliver, and evaluate training, including costs related to administering the training, planning, scheduling, facilities, materials and supplies, reproduction of materials, and training specific equipment. Overtime and Backfill costs associated with attending or teaching FEMA sponsored and/or approved training courses and programs are allowed. These costs are allowed only to the extent the payment for such services is in accordance with the policies of the state or unit(s) of local government and has the approval of the state or the awarding agency, whichever is applicable. In no case is dual compensation allowable. That is, an employee of a unit of government may not receive compensation from either their unit or agency of government AND from an award for a single period of time (e.g., 1:00 pm to 5:00 pm), even though such work may benefit both activities. Further, overtime costs associated with employees who participate in training in a teaching role for which they are compensated are not allowed. Travel costs (e.g., airfare, mileage, per diem, hotel) are allowable as expenses by employees who are on travel status for official business related to approved training. Hiring of Full or Part -Time Staff or Contractors/Consultants to support training -related activities. Payment of salaries and fringe benefits must be in accordance with the policies of the State or unit(s) of local government and have the approval of the State or awarding agency, whichever is applicable. In no case is dual compensation allowable. Oregon Emergency Management 12 FY 2008 Homeland Security Grant Program Application Certification/Recertification of Instructors is an allowable cost. States are encouraged to follow the FEMA Instructor Quality Assurance Program to ensure a minimum level of competency and corresponding levels of evaluation of student learning. This is particularly important for those courses that involve training of trainers. Training Workshops and Conferences. Grant funds may be used to plan and conduct training workshops or conferences to include costs related to planning, meeting space and other meeting costs, facilitation costs, materials and supplies, travel and training plan development. Supplies. Supplies are items that are expended or consumed during the course of the planning and conduct of the training project(s) (e.g., gloves, tape, non-sterile masks, etc.). Other Items. These costs include the rental of space/locations for planning and conducting training, badges, etc. Note: additional training requirements are listed on page 6. Exercise Exercise Related Costs Funds used to design, develop, conduct, and evaluate an exercise. Includes costs related to planning, meeting space and other meeting costs, facilitation costs, materials and supplies, travel, and documentation. Self -Sustaining Exercise and Evaluation Program. Includes costs related to developing and maintaining a self-sustaining State Homeland Security Exercise and Evaluation Program modeled on the national HSEEP, including HSEEP awareness seminars, exercise training courses, and AAR/IP tracking. Hiring of Full or Part -Time Staff or Contractors/Consultants. Full or part-time staff may be hired to support exercise -related activities. The services of contractors/consultants may also be procured to support the design, development, conduct, and evaluation of exercises. Overtime and Backfill. Overtime and backfill costs associated with the design, development, and conduct of exercises are allowable expenses. Payment of overtime expenses will be for work performed in excess of the established work week (usually 40 hours) related to the planning and conduct of the exercise. Travel. Travel costs (e.g., airfare, mileage, per diem, hotel) are allowable as expenses by employees who are on travel status for official business related to the planning and conduct of the exercise. Supplies. Supplies are items that are expended or consumed during the course of the planning and conduct of the exercise (e.g., gloves, tape, non-sterile masks, and disposable protective equipment). Oregon Emergency Management 13 FY 2008 Homeland Security Grant Program Application Other Items. These costs include the rental of space/locations for exercises, planning, and conduct, rental of equipment (e.g., portable toilets, tents), food, refreshments, gasoline, exercise signs, badges, etc. Note: Additional exercise requirements are listed on pages 6-7. Equipment Funds for equipment must be used to enhance the capabilities of state and local emergency response agencies. State agencies and local units of government may acquire advanced levels of responder equipment from 21 approved equipment categories. SHSP Equipment Categories 1. Personal Protective Equipment (PPE) 2. Explosive Device Mitigation and Remediation Equipment 3. CBRNE Operational and Search and Rescue Equipment 4. Information Technology 5. Cyber Security Enhancement Equipment 6. Interoperable Communications Equipment 7. Detection Equipment 8. Decontamination Equipment` 9. Medical Supplies and Limited Pharmaceuticals 10. Power Equipment 11. CBRNE Reference Materials 12. CBRNE Incident Response Vehicles 13. Terrorism Incident Prevention Equipment 14. Physical Security Enhancement Equipment 15. Inspection and Screening Systems 16. Agricultural Terrorism Prevention, Response, and Mitigation Equipment** 17. CBRNE Response Watercraft 18. CBRNE Aviation Equipment** 19. CBRNE Logistical Support Equipment 20. Intervention Equipment 21. Other Authorized Equipment **not allowable for law enforcement Additional information on allowable equipment is provided at www.rk5.mipLorg. Personnel Program funds may be used to support the hiring of full or part-time personnel to conduct program activities that are allowable under the FY 2008 HSGP (i.e., planning, training program management, exercise program management, etc). Oregon Emergency Management 14 FY 2008 Homeland Security Grant Program Application Management and Administration (M&A) No more than three percent of the total amount allocated to the subgrantee (local or tribal government) may be used for administrative purposes. M&A Related costs • Hiring of full- or part-time staff or contractors/consultants to assist with the management of HSGP, implementation of the State Homeland Security Strategy, application requirements, and compliance with reporting and data collection requirements. • Development of operating plans for information collection and processing necessary to respond to requests for information. • Travel expenses. • Overtime and backfill costs. • Meeting -related expenses. • Acquisition of authorized office equipment including personal and laptop computers, printers, LCD projectors, and other equipment or software, which may be required to support the implementation of the Homeland Security Strategy. • Recurring fees/charges associated with certain equipment, such as cell phones and faxes during the period of performance of the grant program. • Leasing and/or renting of space for newly hired personnel during the period of performance of the grant program. Oregon Emergency Management 15 FY 2008 Homeland Security Grant Program Application Law Enforcement Terrorism Prevention -Oriented Activities In FY 2008 the law enforcement terrorism prevention and protection -oriented activities will focus on providing resources to law enforcement and public safety communities (working with their private partners) to support critical terrorism prevention activities and collaborating with non -law enforcement partners, other government agencies, and the private sector. Although other prevention activities continue to be allowable, the priority for FY 2008 is: 1. Measuring progress in achieving the National Preparedness Guidelines. 2. Strengthening improvised explosive device (IED) attack deterrence, prevention, and protection capabilities. 3. Strengthening preparedness planning. Law Enforcement -Oriented Authorized Program Expenditures The broad parameters of the historical LETPP program are still allowable under SHSP and UASI. These include the following activities: • Information sharing and analysis. • Threat recognition. • Terrorist interdiction. • Overtime expenses consistent with a State Homeland Security Plan, including for the provision of enhanced law enforcement operations in support of Federal agencies. • Establishing, enhancing, and staffing, with appropriately qualified personnel, State, local, and regional fusion centers. • Paying salaries and benefits for personnel, including individuals employed by the grant recipient on the date of the relevant grant application, to serve as qualified intelligence analysts. Organizational Law enforcement -oriented funds may be used for the following organizational activities: • Overtime for information, investigative, and intelligence sharing activities. • Reimbursement for select operational expenses associated with increased security measures at critical infrastructure sites incurred during periods of DHS declared alert. • Hiring of new staff positions/contractors/consultants for participation in information/intelligence analysis and sharing groups or fusion center activities. Planning For examples of allowable planning activities please refer to the SHSP planning section and the Homeland Security Allowable Planning Guide at: http://www.fema.gov/pdf/government/grant/hsgp/fy08 hsgp_allowplanning.pdf. Oregon Emergency Management 16 FY 2008 Homeland Security Grant Program Application Training Law enforcement -oriented funds may be used for a range of law enforcement terrorism prevention related training activities to enhance the capabilities of State and local personnel, including, but not limited to the following: • Participation in DHS approved intelligence analyst training: States wishing to develop or sponsor intelligence analyst courses for a national audience should submit courses to OEM for review and approval. • Limited participation in non -FEMA approved intelligence analyst training: States may send students to attend non -approved intelligence analysis courses for up to three offerings. If your agency is interested in this type of course, contact the OEM Training Coordinator, Jim Adams (see page 6). Note: A certificate of completion of all intelligence analyst training must be on file with the SAA and must be made available to Preparedness Officers upon request. • Building information sharing capacities (especially among law enforcement, non -law enforcement, other government agencies, and the private sector). • Methods of target hardening. • Facility law enforcement security personnel, to include facilities, vessels and ports. • CBRNE, agriculture, and cyber threats. • History of terrorism and social environments contributing to threats. • Surveillance and counter -surveillance techniques. • Privacy, civil rights, and civil liberties regulations, policies, procedures, and protocols. • Critical Infrastructure Protection training, to include identifying/assessing critical infrastructure assets, vulnerabilities, and threats. • Cyber/agriculture/food security threats recognition and protective measures training. • Cultural awareness training for community engagement activities and undercover operations related to terrorist organizations. • Languages, such as Arabic, Urdu, or Farsi, which are spoken by known terrorists and terrorist organizations. • Joint training with other homeland security entities (e.g., U.S. Secret Service, CBP). • Use of interoperable communications equipment. • Collection, analysis, mapping, integration, and dissemination of geospatial data and imagery. • Geospatial database use, design, development, and management training. • Volunteer participation to support law enforcement and community policing activities related to increased citizen awareness of terrorism activities, to include the Volunteers in Police Service and Neighborhood Watch programs. Training Related Costs Allowable training related costs include: Funds used to develop, deliver, and evaluate training, overtime and backfill, travel, hiring of full or part-time staff or contractors/consultants, certification/recertification of instructors, training workshops and conferences, and supplies. Additional detail for each of these allowable costs is provided in the SHSP training section. Note: additional training requirements are listed on page 6. Oregon Emergency Management 17 FY 2008 Homeland Security Grant Program Application Exercise Law enforcement -oriented funds may be used to design, develop, conduct, and evaluate terrorism prevention -related exercises, including the following: • Exercises to evaluate the effectiveness of information sharing plans, policies, procedures, and protocols. • Exercises to evaluate NIMS implementation. This includes costs associated with exercising components of the NIMS. • Exercises to evaluate facility and/or vessel security protection. • Exercises to evaluate area maritime security protection. • Exercises to evaluate threat recognition capabilities. • Exercises to evaluate cyber security capabilities. • Exercises to evaluate agricultural/food security capabilities. • Exercises to evaluate prevention readiness and techniques. • "Red Team" (force on force) exercises. • Interoperable communications exercises. • Critical infrastructure vulnerability, protection, and/or attack exercises. Where practical, these exercises should involve the public sector, non-governmental partners, trained citizen volunteers, and the general public. State and local governments should work with their Citizen Corps Councils to include volunteers from programs such as Volunteers in Police Service, Neighborhood Watch, and the general public. Exercise Related Costs Allowable exercise related costs include: Funds used to design, develop, conduct, and evaluate an exercise, developing and maintaining a self-sustaining exercise and evaluation program, overtime and backfill, travel, hiring of full or part-time staff or contractors/consultants, and supplies. Additional detail for each of these allowable costs is provided in the SHSP exercise section. Note: Additional exercise requirements are listed on pages 6-7. Equipment Allowable law enforcement -oriented equipment is similar to the allowable equipment for SHSP. See the SHSP Equipment Categories section for details as well as the Authorized Equipment List (AEL) on the RKB web page https://www.rkb.us/. Personnel See SHSP Personnel section (page 14). Management and Administration (M&A) See SHSP M&A section (page 15). Oregon Emergency Management 18 FY 2008 Homeland Security Grant Program Application Citizen Corps Program (CCP) The FY 2008 Citizen Corps Program (CCP) funds provide resources for local and tribal communities to: • Bring together the appropriate leadership to form and sustain a Citizen Corps Council. • Develop and implement a plan or amend existing plans to achieve and expand citizen preparedness and participation. • Conduct public education and outreach. • Ensure clear alerts/warnings and emergency communications with the public. • Develop training programs for the public, for both all -hazards preparedness and volunteer responsibilities. • Facilitate citizen participation in exercises. • Implement volunteer programs and activities to support emergency responders. • Involve citizens in surge capacity roles and responsibilities during an incident in alignment with the Emergency Support Functions and Annexes. • Conduct evaluations of programs and activities. All grant recipients must register their Citizen Corps Council on the Citizen Corps website, .citizencorps. o, and manage their program and contact information listed on the site. Expenditures must advance the Citizen Corps mission to have everyone participate in hometown security through preparedness, training, and volunteer service. In addition to HSGP funding, state and local governments are encouraged to consider all sources of funding, including private sector funding, to leverage existing materials, to pursue economies of scale and economies of scope in pursuing this mission, and to make expenditures that benefit multiple programs. Planning Integrating non-governmental entities into the planning process is critical to achieve comprehensive community preparedness. To meet this important objective, HSGP funds may be used to support the following: • Establishing and sustaining membership to serve as Citizen Corps Councils. • Assuring that State and local government homeland security strategies, policies, guidance, plans, and evaluations include a greater emphasis on government/non-governmental collaboration, citizen preparedness, and volunteer participation. • Developing and implementing a community preparedness strategy for the local and tribal jurisdictions. Oregon Emergency Management 19 FY 2008 Homeland Security Grant Program Application Public education/outreach Citizen Corps Councils may develop or reproduce public education and outreach materials to: • Increase citizen preparedness (to include the DHS Ready Campaign materials); • Promote training, exercise, and volunteer opportunities; and • Inform the public about emergency plans, evacuation routes, shelter locations, and systems for public alerts/warnings. Public education and outreach materials should incorporate special needs considerations, to include language, content, and method of communication. Allowable expenditures include: • Media campaigns: PSAs, camera-ready materials, website support, newsletters, etc. • Outreach activities and public events: booth displays, event backdrops or signs, displays and demonstrations, and informational materials such as brochures/flyers. • Promotional materials: pins, patches, magnets, clothing/headwear. All materials must include the national or jurisdiction's Citizen Corps logo, tagline and website or the Ready logo, tagline, and website and comply with logo standards. For additional information go to: https://www.citizencorps.gov/pdf/logoguide.pdf. Citizen participation - Volunteer programs and disaster response support Citizen support for emergency responders is critical through year-round volunteer programs and as surge capacity in disaster response. Citizen Corps funding may be used to establish, enhance or expand volunteer programs and volunteer recruitment efforts for Neighborhood Watch/USAonWatch, Community Emergency Response Teams (CERT), Volunteers in Police Service (VIPS), Medical Reserve Corps (MRC), and Fire Corps; for the Citizen Corps Affiliate Programs and Organizations; and for jurisdiction specific volunteer efforts. Examples include: • Recruiting, screening, and training volunteers (e.g., background checks). • Retaining, recognizing, and motivating volunteers. • Purchasing, maintaining, or subscribing to a system to track volunteers (in compliance with applicable privacy laws), to include identification and credentialing systems, and to track volunteer hours. • Evaluating volunteers. Organizational Organization activities supported with CCP funding are limited to the development and support of citizen surge capacity response deployments. Oregon Emergency Management 20 FY 2008 Homeland Security Grant Program Application Training Training funded with these grants can include all -hazards safety, such as emergency preparedness, basic first aid, life saving skills, crime prevention and terrorism awareness, school preparedness, public health issues, mitigation/property damage prevention, safety in the home, Tight search and rescue skills, principles of NIMS/ICS, community relations, volunteer management, serving people with disabilities, pet care preparedness, any training necessary to participate in volunteer activities, any training necessary to fulfill surge capacity roles, or other training that promotes individual, family, or community safety and preparedness. Funding for CERT training includes the delivery of the CERT basic training to volunteers, supplemental training for CERT members who have completed the basic training, and the CERT Train -the -Trainer training. The training must include the topics, be instructor -led and classroom -based, using lecture, demonstration, and hands-on practice throughout. Note that the Independent Study course, "Introduction to CERT" (IS 317) may not be substituted for delivery of basic training consistent with the 20 -hour CERT curriculum. There is no cap on the number of deliveries local jurisdictions may conduct of the CERT basic training, the CERT Train -the -Trainer, Campus CERT Train -the -Trainer, or Teen CERT Train -the -Trainer courses. Training should be delivered with specific consideration to include all ages, ethnic and cultural groups, persons with disabilities, and special needs populations at venues throughout the community, to include schools, neighborhoods, places of worship, the private sector, non- governmental organizations, and government locations. Jurisdictions are also encouraged to incorporate non-traditional methodologies such as the Internet, distance learning, home study, and to leverage existing training provided via educational/professional facilities. Pilot courses and innovative approaches to training citizens and instructors are encouraged. Instruction for trainers and training to support the Citizen Corps Council members in their efforts to manage and coordinate the Citizen Corps mission is also an allowable use of the FY 2008 Citizen Corps Program funding. Training Related Costs • Instructor preparation and delivery time (to include overtime costs). • Hiring of full or part-time staff or contractors/consultants to assist with conducting the training and/or managing the administrative aspects of conducting the training. • Quality assurance and quality control of information. • Creation and maintenance of a student database. • Rental of training facilities. • Printing course materials to include instructor guides, student manuals, brochures, certificates, handouts, newsletters and postage (although preference is for an electronic newsletter with email addresses as part of the database unless the individuals or areas to be served have limited access to electronic communications). • Course materials specific to the subject matter, such as bandages, gloves, fire extinguishers, mannequins, etc. • Outfitting trainees and volunteers with program related materials and equipment, e.g. issuing CERT kits, credentials/badges, identifying clothing. Oregon Emergency Management 21 FY 2008 Homeland Security Grant Program Application Exercise Exercises specifically designed for, or that include participation from, non-governmental entities and the general public are allowable activities and may include testing public warning systems, evacuation/shelter in-place capabilities, family/school/business preparedness, and participating in table -top or full scale emergency responder exercises at the local, State, or national level, to include the Top Officials Exercise (TOPOFF). Exercise Related Costs Costs associated with the design, development, and conduct of exercises specifically designed for non-governmental entities and/or the general public to support the citizen/volunteer component of emergency responder exercises, to include recruiting, preparing, tracking, supporting, and debriefing citizens regarding their role in the exercise. Exercises should ensure that citizens, including citizens with disabilities, and special needs populations, participate in all phases of emergency responder exercises, to include planning, implementation, and after -action review. Exercises conducted with FEMA support (grant funds or direct support) must be managed and executed in accordance with the HSEEP. The HSEEP Volumes contain guidance and recommendations for designing, developing, conducting, and evaluating exercises. HSEEP Volume IV provides sample exercise materials. All four volumes can be found at the HSEEP website: http://hseep.dhs,gov. Note: Additional exercise requirements are listed on pages 6-7. Equipment Any equipment purchased with CCP funding must be used for specific preparedness or volunteer training or by volunteers in carrying out their response functions. CCP funding is not intended for equipment to be used by uniformed emergency responders, except to support training for citizens. Examples of equipment used to support training for citizens includes such items as burn pans or sample volunteer response kits. CCP Equipment Categories 1. Personal Protective Equipment (PPE) 2. CBRNE Operational and Search and Rescue Equipment 3. Information Technology 4. Cyber Security Enhancement Equipment 5. Interoperable Communications Equipment 6. Medical Supplies and Limited Pharmaceuticals 7. Power Equipment 8. CBRNE Incident Response Vehicles 9. CBRNE Logistical Support Equipment 10. Other Authorized Equipment Additional information on allowable equipment is provided at: ww.rkb.mipt org. Oregon Emergency Management 22 FY 2008 Homeland Security Grant Program Application Personnel Hiring, overtime, and backfill expenses are allowable only to perform programmatic activities allowable under existing guidance. Management and Administration (M&A) See SHSP M&A section (page 15). Oregon Emergency Management 23 FY 2008 Homeland Security Grant Program Application Application Overview Applicants are required to submit a collaborative countywide or larger regional response to this application. Only ONE application will be accepted from each county. To the greatest extent possible, applicants should begin pursuing a regional response to this application. Future applications for grant funding may require the submission of a regional, rather than a countywide, response. Similarly tribal agencies should only submit one application per tribe. Oregon Emergency Management will subgrant awards to eligible individual agencies once the application has been approved; however, for purposes of this application process you are required to submit one coordinated application. Priorities for Funding The only eligible projects are those that implement the State's four investment areas. The four investment areas are: 1. Interoperable Communications 2. Emergency Preparedness Planning 3. CBRNE Detection/Response 4. Citizen Preparedness In accordance with grant program guidance intended to streamline efforts in obtaining resources that are critical to building and sustaining capabilities to achieve the National Preparedness Goal and implement State and Urban Area Homeland Security Strategies, priorities for funding include projects that integrate planning, training, and exercises in addition to equipment procurement. Applicants are strongly encouraged to develop a holistic approach in identifying distinct projects. For FY 2008, funding priority will be given to projects that have thoughtfully integrated planning, training, and exercise needs in addition to equipment requests. Consistently denied equipment items include: • SCBAs requested by fire departments. • Explosive Device Mitigation equipment for personnel outside of FBI approved bomb squads. • Equipment and software intended for general use (i.e., not CBRNE specific) or equipment already required by virtue of the occupation (i.e. bulletproof vests for law enforcement, turn out gear for fire). • Equipment not supported or well documented in the Project Justification. Oregon Emergency Management 24 FY 2008 Homeland Security Grant Program Application Application Contents A completed application will consist of up to six parts (four required and two optional). All forms can be accessed through the OEM web page at: http://www.oregon.gov/OMD/OEM/index.shtml. Part 1 — Required: Cover Sheet(s) for the county submitting agency and each agency that will directly receive funds. Part 2 — Required: NIMS compliance form(s) from each agency requesting or benefiting from funding. Part 3 — Required: Maximum of four Project Justifications completed in the required format: up to three project justifications for SHSP and one project justification for CCP may be submitted. If not submitting a CCP project justification, the maximum amount of project justifications that may be submitted is three. The project justification form may be downloaded from the Oregon Emergency Management website at: http://www.oregon.gov/OMD/OEM/index.shtml. Part 4 — Required: Detailed line item budget for each Project Justification. A sample budget is provided with these instructions. Part 5 — Optional: Appendices - applications may include up to two pages of appendices per Project Justification. Part 6 — Optional: Regional Project - Base Contribution form (only complete if offering your grant funds to another county) - must be completed if a county actively participating in a regional project is requesting their portion of the grant funds be awarded to another county for the purpose of executing the regional project. A county may not request their funds be given to another county without providing supporting documentation in the project justification showing they will directly benefit from the project. Parts one, two, three and six of the application must be completed on the forms provided and may not exceed the given space for each question. The detailed budget(s) must include, at a minimum, the information shown in the sample. You must provide one original and nine copies (10 total) of the submitting county's (master) Cover Sheet, additional agency cover sheets, completed NIMS Compliance Form(s), up to four Project Justifications, detailed budgets for each project, appendices (if applicable), and regional project base contribution form (if applicable). Part 1: Cover Sheet The Cover Sheet provides identifying information and must be completed in full and placed at the beginning of the application. An electronic sheet is available for completion. A master Cover Sheet must be completed by the submitting county agency and included with the original application and nine copies. Cover Sheets must also be completed for each additional agency that will directly receive funds. Oregon Emergency Management 25 FY 2008 Homeland Security Grant Program Application Part 2: NIMS Compliance Form Local and tribal entities are required to become fully compliant with the FY 2005, FY 2006, FY 2007, and FY 2008 NIMS requirements by September 30, 2008. Each agency requesting or benefiting from funding must complete a NIMS compliance form, and must meet each of the requirements as stated on the form to be eligible for the FY 2008 grant funds. For additional information on NIMS requirements, please contact the State NIMS POC, Lonni Nicoll. • Check the box next to each NIMS action your organization has completed. • The NIMS compliance form must be signed and dated by the authorized agency official. • If the agency cannot verify compliance with all listed NIMS requirements, they will not be eligible to receive or benefit from the FY 2008 funding. Part 3: Project Justification Form You must prioritize projects for funding. Given limited funding, your prioritization assists review board members in the review and evaluation process. A Project Justification form must be completed for each proposed project. No more than four projects may be submitted per county/regional or tribal application. All proposed projects must be completed by May 31, 2011 and support specific, State Investment Areas as well as goals and objectives in the State Homeland Security Strategy and/or Urban Area Homeland Security Strategy. Project Priority # Identify the priority number for this project. County/Tribe Agency Identify the agency or tribe submitting the application. Project Title Assign each project a unique title that succinctly describes the project. Project Phase Identify in the dropdown field if this project is "new" or "ongoing" (continuation from a previous grant year). Regional Project (multi -county) Identify in the dropdown field if the project is regional (involves more than one county). Question 1: Choose a project type. Check the box next to the one description that best suits this project. Oregon Emergency Management 26 FY 2008 Homeland Security Grant Program Application Question 2: Provide a summary description of the current state of this project, its objectives, and any outcomes that will be completed prior to the receiving FY 2008 HSGP funds. Include in this description whether this is a new project or a project in maintenance/sustainment. Describe the capability gap(s) this project is intended to address. • Response should include a description of the current state (baseline or starting point) of the project at the beginning of the FY 2008 HSGP period of performance. • Discuss project objectives expected to be accomplished over the FY 2008 HSGP period of performance. • Include all accomplishments and outcomes to date (only relevant for ongoing Investments) Any accomplishments to date would include major milestones, outcomes achieved, purchases, training, or other implementation steps that have been or will be started and/or completed before the application of FY 2008 HSGP funds. If this is a new Investment, indicate that as a new Investment, there are no accomplishments to date. • Identify the capability gap this project is intended to address. Question 3: List up to four National Priorities this project primarily supports. From the dropdown field, choose the National Priority that best supports this project. • Up to four National Priorities may be chosen, but only one is required. Question 4: Check the box for the primary Target Capability this project supports. For the Target Capability selected, provide an explanation of how it is supported by this project. • Identify the primary Target Capability that is most significantly and directly supported by the project. • In the space provided, explain how the selected target capability is supported by the project. Question 5: Explain how this project will support the implementation of at least one of the four State investment areas, and the achievement of goals and objectives from the State Homeland Security Strategy. The State Strategy and investments can be found on the OEM web page at: http://www.oregon.gov/OMD/OEM/plans train/grant info.shtml. • From the dropdown field choose the primary investment area this project supports. • In the space provided explain how the project supports the chosen investment area. • Identify which State investment area this project relates to, and what specific area of the investment will be accomplished or furthered by this project. • Explain how the project supports the achievement of the identified goals/objectives from the State and/or Urban Area Homeland Security Strategy. Oregon Emergency Management 27 FY 2008 Homeland Security Grant Program Application Question 6: Clearly identify how this project is supported by the current countywide/regional plans such as communications or CBRNE/terrorism response. • Applicants proposing to purchase interoperable communications equipment must certify that they have an implementation plan for the equipment that includes governance structures, policies, procedures, training, and planned exercises to ensure key elements of planning, governance, and training are addressed before the communications equipment is procured. • Applicants interested in enhancing or creating radio communications capabilities must clearly identify that they have a written and promulgated communication strategy and plan. Jurisdictions without a written and promulgated plan will not be provided funding for communications equipment. • Describe how this project and the requested equipment are consistent with an existing communications, CBRNE/terrorism, emergency operations, or other approved plan. Question 7: Discuss the collaboration strategy for implementation of this project. What relationships exist, or will be establish, with other regions and jurisdictions (inter- and intra -State) within or beyond the geographic area of this project. Discuss when and how you will engage stakeholders from those regions in specific support of this project. Consider if you will need to engage entities and stakeholders from other regions/areas to successfully implement this project. • Identify the collaboration processes and communication strategies already in place with other regions and jurisdictions. • Discuss who you will reach out to, who you have already reached out to, why those individuals/groups were selected, and why/how they will benefit from this project. • Explore possible/existing collaboration and coordination strategies, and the timeline for engaging those external stakeholders. Question 8: What outputs and outcomes will indicate this Investment is successful at the end of the FY 2008 HSGP period of performance? • Identify measurable outputs that lead to the outcomes described. • Describe the tangible outcomes that will indicate the project has been successful. • Outcomes described should demonstrate progress toward the overall objective of the project, and include outcomes expected during the FY 2008 HSGP period of performance as well as those expected at the conclusion of the FY 2008 HSGP period of performance • Describe how these outcomes will mitigate risks. Output— Outputs are the goods and services produced by using project resources. Outputs can be represented in units of quantifiable products, such as the number of portable radios purchased, or as activities performed, such as exercises and training courses. Additional sample outputs have been listed below: Number of people trained. Quantity of medications available. Number of agencies served by an interoperable gateway. Oregon Emergency Management 28 FY 2008 Homeland Security Grant Program Application Outcome— Outcomes describe the intended impact of the project on the preparedness environment (i.e., the changes resulting from the outputs). This often includes the ways in which the project has enhanced or developed the agency's capability or capacity to serve the public. Sample outcomes include: • Increased ability to administer medications in the event of an emergency. * Increased operational coordination among responders. * Cost savings to the jurisdictions. Question 9: Explain the long-term approach to sustaining the capabilities created or enhanced by this project, or explain why this Investment will not be sustained? • Describe plans for maintaining the capabilities developed by the project, including: * Any additional sources of funding to be used, other than Homeland Security Grants. * Future plans or milestones for sustaining the project, if any. • If the project will not be maintained/sustained long-term, describe why. Provide an explanation of how the requested FY 2008 HSGP funding is sufficient for the implementation and sustainment of the project. Question 10: Provide the total estimated cost for the FY 2008 HSGP period of performance for this project by completing the following table: • Enter the dollar amount requested for this specific project in each category of funding (planning, training, etc.) and from each grant source (SHSP/LE, CCP). For each solution area that has an associated FY 2008 HSGP funds request, provide a brief summary of the planned expenditures (including personnel). • Describe appropriate activities, services, or products for each applicable solution area. • Describe how the requested HSGP funds will be used specifically towards this project. Question 11: Provide a high-level timeline, including milestones and dates, for the implementation of this project. Possible areas for inclusion are: stakeholder engagement, planning, major acquisitions/purchases, training, exercises, and process/policy updates. Space is provided for up to 7 milestones, but not all 7 may be necessary for the response. Limit responses to high-level milestones that are critical to this project. • Identify milestones that are relevant only to this project, only to FY 2008 HSGP funds, and only to the award period. • Include major tasks and dates for all milestones. Oregon Emergency Management 29 FY 2008 Homeland Security Grant Program Application Part 4: Budget Each project identified in your application must have its own unique budget. At a minimum, each project budget must contain all of the information shown in the sample budget included with these instructions. Equipment costs should be itemized to the greatest extent practicable. The FY 2008 Authorized Equipment List (AEL) is available at www.rk.mipt.org. For equipment costs include: • The equipment category (PPE, Interoperable Communications, CBRNE Logistical Support, etc.). • The specific equipment broken down by item and AEL reference number, unit cost, and quantity. • Which agency and discipline will receive the equipment (law enforcement, fire, HazMat, public works, public health, emergency management, etc.). Identify the quantity allocated for each agency and/or discipline that will receive the equipment. • Training that will be completed on the equipment. If requesting equipment specific training, please include the AEL number of 21GN-00-TRNG. For training costs, the budget must: • Specify the name of the course. • Specify how many participants will attend the training (by discipline and function). • Include a line -item breakdown of expenses (facility rental, materials, instructor fees, etc.). For organizational, planning, and exercise costs the budget must include a line -item breakdown including the following expenses: personnel, contractual services, travel, supplies, rent and utilities, etc. For management & administrative (M&A) costs, limit expenses to no more than three percent of the total project budget. Detail what the M&A costs will be used for (overtime/backfill, staff to manage grant, travel, recurring fees, etc.). Part 5: Appendices Appendices are not required. Applicants that elect to submit additional items to support their projects may provide up to two pages of appendices per Project Justification form. Items that may be submitted as Appendices include: MOUs, maps/charts, plans, policies/procedures, letters of support, etc. Part 6: Regional Project - Base Contribution form (optional - only complete if offering your grant funds to another county) • Must be completed if a county actively participating in a regional project is requesting their portion of the grant funds be awarded to another county for the purpose of executing the regional project. • A county may not request their funds be given to another county without providing supporting documentation in the project justification showing they will directly benefit from the project. • May only designate one county to receive contributed funds. Oregon Emergency Management 30 FY 2008 Homeland Security Grant Program Application Unallowable Costs Federal limitations prohibit the use of grant funds for: • Land acquisition. • General purpose vehicles (squad cars, executive transportation). • General -use software, general use computers and related equipment other than for allowable administrative activities. • Weapons and ammunition. • Vehicle licensing fees. • Construction and renovation is generally prohibited. Construction and renovation shall be strictly limited and allowable when it is a necessary component of a security system at critical infrastructure facilities. • Hiring of public safety personnel for the purpose of fulfilling traditional public safety duties. • Activities unrelated to the completion and implementation of the Homeland Security Grant Program. • Other items not in accordance with the AEL or previously listed allowable costs. Unallowable Exercise Costs • Reimbursement for the maintenance and/or wear and tear costs of general use vehicles and emergency response apparatus. The only vehicle cost that is reimbursable is fuel/gasoline and mileage. • Equipment that is purchased for permanent installation and/or use, beyond the scope of exercise conduct (e.g., electronic messaging signs). • Repair or replacement of equipment damaged or lost during an exercise. Suspension or Termination of Funding Oregon Emergency Management may suspend or terminate funding, in whole or in part, or impose other measures for any of the following reasons: • Failing to make satisfactory progress toward the goals, objectives, or strategies set forth in the Project Justification. • Failing to follow grant agreement requirements or standard or special conditions. • Proposing or implementing substantial plan changes to the extent that, if originally submitted, the project would not have been selected for funding. • Failing to submit required reports. • Filing a false certification in this application or other report or document. Before taking action, Oregon Emergency Management will provide the subgrantee with reasonable notice of intent to impose measures and will make efforts to resolve the problem informally. Oregon Emergency Management 31 FY 2008 Homeland Security Grant Program Application Reporting and Reimbursements Biannual Strategy Implementation Reports (BSIR)/Progress Reports Applicants will be required to submit two types of reports: 1) semi-annual narrative progress reports that contain specific information regarding the activities carried out under the FY 2008 Homeland Security Grant Program and how they address the goals and objectives of the State or UASI Homeland Security Strategy, and 2) web -based aggregate level data information on project implementation entered into an electronic web -based template. These reports are captured via the Biannual Strategy Implementation Report (BSIR). Requests for Reimbursement Reimbursements will only be made for actual expenses. Reimbursements will be made on a semi-annual basis unless otherwise agreed between OEM and the subgrantee. All requests for reimbursement must include supporting documentation to substantiate claimed expenses. Accurate and clear expenditure information will be required before reimbursement is made. Reimbursements are made only for equipment purchased and/or services performed during the grant period. Payments will be withheld if any BSIR is outstanding. Reporting Due Dates The Biannual Strategy Implementation Report (BSIR), semi-annual progress reports (PR), and Requests for Reimbursement (RFR) are due on the following dates: Note: Requests for Reimbursement (RFR) may be submitted more frequently than the dates listed, but not less frequently. Repos ni ergo ate= Due , iue 10/1/08 - 12/31/08 1/15/09 BSIR/PR 7/1/08 - 12/31/08 2/2/09 RFR 1/1/09 - 6/30/09 7/15/09 BSIR/PR 1/1/09 - 6/30/09 7/31/09 RFR 7/1/09 - 12/31/09 1/15/10 BSIR/PR 7/1/09 - 12/31/09 2/1/10 RFR 1/1/10 - 6/30/10 7/15/10 BSIR/PR 1/1/10 - 6/30/10 8/2/10 RFR 7/1/10 - 12/31/10 1/18/11 BSIR/PR 7/1/10 - 12/31/10 1/31/11 RFR /1 0/' na RFR. Oregon Emergency Management 32 FY 2008 Homeland Security Grant Program Application Federal Conditions Drug -Free Work Place, Debarment, and Lobbying Subgrantees must agree to certain conditions required by federal law. These conditions include: maintenance of a drug-free workplace; prohibition against allowing persons debarred or suspended from receiving grant funds; and prohibition from using funds for lobbying Members of Congress. Compliance with Federal Civil Rights Laws and Regulations The subgrantee is required to comply with Federal civil rights laws and regulations. Specifically, the subgrantee is required to provide assurances as a condition for receipt of Federal funds that its programs and activities comply with the following: • Title VI of the Civil Rights Act of 1964, as amended, 42. U.S.C. 2000 et. seq. — no person on the grounds of race, color or national origin will be excluded from participation in, be denied the benefits of, or be otherwise subjected to discrimination in any program or activity receiving Federal financial assistance. More information can be found at httpllusinfo.state.gov/usa/infousallaws/majoriaw/civilrl 9. htm. • Section 504 of the Rehabilitation Act of 1973, as amended, 29 U.S.C. 794 — no qualified individual with a disability in the United States, shall, by reason of his or her disability, be excluded from the participation in, be denied the benefits of, or otherwise be subjected to discrimination in any program or activity receiving Federal financial assistance. More information can be found at http://www.section508.gov/index.cfrn?FuseAction=Content&ID=1 5. • Title IX of the Education Amendments of 1972, as amended, 20 U.S.C. 1681 et. seq. — discrimination on the basis of sex is eliminated in any education program or activity receiving Federal financial assistance. More information can be found at http://www.usdolgov/crt/contoord/titleix.htm. • The Age Discrimination Act of 1975, as amended, 20 U.S. C. 6101 et. seq. — no person in the United States shall be, on the basis of age, excluded from participation in, denied the benefits of or subjected to discrimination under any program or activity receiving Federal financial assistance. Subgrantees must comply with all regulations, guidelines, and standards adopted under the above statutes. The subgrantee is also required to submit information, as required, to the DHS Office for Civil Rights and Civil Liberties concerning its compliance with these laws and their implementing regulations. Services to Limited English Proficient (LEP) Persons Recipients of FEMA financial assistance are required to comply with several Federal civil rights laws, including Title VI of the Civil Rights Act of 1964, as amended. These laws prohibit discrimination on the basis of race, color, religion, natural origin, and sex in the delivery of services. National origin discrimination includes discrimination on the basis of limited English proficiency. To ensure compliance with Title VI, recipients are required to take reasonable steps to ensure that LEP persons have meaningful access to their programs. Meaningful access may entail providing language assistance services, including oral and written translation, where necessary. The grantee is encouraged to consider the need for language services for LEP persons served or encountered both in developing their proposals and budgets and in conducting their programs and activities. Reasonable costs associated with Oregon Emergency Management 33 FY 2008 Homeland Security Grant Program Application providing meaningful access for LEP individuals are considered allowable program costs. For additional information, see hftp://www.iep.gov. Integrating Individuals with Disabilities into Emergency Planning Section 504 of the Rehabilitation Act of 1973, as amended, prohibits discrimination against people with disabilities in all aspects of emergency mitigation, planning, response, and recovery by entities receiving financial from FEMA. In addition, Executive Order #13347, entitled "Individuals with Disabilities in Emergency Preparedness" signed in July 2004, requires the Federal Government to support safety and security for individuals with disabilities in situations involving disasters, including earthquakes, tornadoes, fires, floods, hurricanes, and acts of terrorism. Executive Order 13347 requires the federal government to, among other things, encourage consideration of the needs of individuals with disabilities served by State, local, and tribal governments in emergency preparedness planning. FEMA has several resources available to assist emergency managers in planning and response efforts related to people with disabilities and to ensure compliance with Federal civil rights laws: • Guidelines for Accommodating Individuals with Disabilities in Disaster: The Guidelines synthesize the array of existing accessibility requirements into a user friendly tool for use by response and recovery personnel in the field. The Guidelines are available at httpl/www.fema.govloerfreferencel. • Disability and Emergency Preparedness Resource Center: A webbased "Resource Center" that includes dozens of technical assistance materials to assist emergency managers in planning and response efforts related to people with disabilities. The "Resource Center" is available at http://www.disabilitypreparedness.gov. Lessons Learned Information Sharing (LLIS) resource page on Emergency Planning for Persons with Disabilities and Special Needs: A true one-stop resource shop for planners at all levels of government, non-governmental organizations, and private sector entities, the resource page provides more than 250 documents, including lessons learned, plans, procedures, policies, and guidance, on how to include citizens with disabilities and other special needs in all phases of the emergency management cycle. LLIS.gov is available to emergency response providers and homeland security officials from the local, state, and federal levels. To access the resource page, log onto hftp://www.LLIS.gov and click on Emergency Planning for Persons with Disabilities and Special Needs under Featured Topics. If you meet the eligibility requirements for accessing Lessons Learned Information Sharing, you can request membership by registering online. Freedom of Information Act (FOIA) FEMA recognizes that much of the information submitted in the course of applying for funding under this program or provided in the course of its grant management activities may be considered law enforcement sensitive or otherwise important to national security interests. While this information under Federal control is subject to requests made pursuant to the Freedom of Information Act (FOIA), 5. U.S.C. §552, all determinations concerning the release of information of this nature are made on a case-by-case basis by the FEMA FOIA Office, and may likely fall within one or more of the available exemptions under the Act. The applicant is encouraged to consult its own State and local laws and regulations regarding the release of Oregon Emergency Management 34 FY 2008 Homeland Security Grant Program Application information, which should be considered when reporting sensitive matters in the grant application, needs assessment and strategic planning process. The applicant may also consult FEMA regarding concerns or questions about the release of information under State and local laws. The subgrantee should be familiar with the regulations governing Sensitive Security Information (49 CFR Part 1520), as it may provide additional protection to certain classes of homeland security information. Compliance with the National Energy Conservation Policy and Energy Policy Acts. In accordance with the FY 2008 DHS Appropriations Act, all FY 2008 grant funds must comply with the following two requirements: • None of the funds made available shall be used in contravention of the Federal buildings performance and reporting requirements of Executive Order No. 13123, part 3 of title V of the National Energy Conservation Policy Act (42 USC 8251 et. Seq.), or subtitle A of title I of the Energy Policy Act of 2005 (including the amendments made thereby). • None of the funds made available shall be used in contravention of section 303 of the Energy Policy Act of 1992 (42 USCI 3212). Environmental and Historic Preservation Compliance. FEMA is required to consider the potential impacts to the human and natural environment of projects proposed for FEMA funding. FEMA, through its Environmental and Historic Preservation (EHP) Program, engages in a review process to ensure that FEMA -funded activities comply with various Federal laws including: National Environmental Policy Act, National Historic Preservation Act, Endangered Species Act, and Executive Orders on Floodplains (11988), Wetlands (11990) and Environmental Justice (12898). The goal of these compliance requirements is to protect our nation's water, air, coastal, wildlife, agricultural, historical, and cultural resources, as well as to minimize potential adverse effects to children and low-income and minority populations. The subgrantee shall provide any information requested by FEMA to ensure compliance with applicable Federal EHP requirements. Any project with the potential to impact EHP resources (see Section E.8) cannot be initiated until FEMA has completed its review. Grantees may be required to provide detailed information about the project, including the following: location (street address or map coordinates); description of the project including any associated ground disturbance work, extent of modification of existing structures, construction equipment to be used, staging areas, access roads, etc.; year the existing facility was built; natural, biological, and/or cultural resources present in the project vicinity; visual documentation such as site and facility photographs, project plans, maps, etc; and possible project alternatives. For certain types of projects, FEMA must consult with other Federal and state agencies such as the U.S. Fish and Wildlife Service, State Historic Preservation Offices, and the U.S. Army Corps of Engineers, as well as other agencies and organizations responsible for protecting natural and cultural resources. For projects with the potential to have significant adverse effects on the environment and/or historic properties, FEMA's EHP review and consultation may result in a substantive agreement between the involved parties outlining how the grantee will avoid the effects, minimize the effects, or, if necessary, compensate for the effects. Because of the potential for significant adverse effects to EHP resources or public controversy, some projects may require an additional assessment or report, such as an Environmental Oregon Emergency Management 35 FY 2008 Homeland Security Grant Program Application Assessment, Biological Assessment, archaeological survey, cultural resources report, wetlands delineation, or other document, as well as a public comment period. Subgrantees are responsible for the preparation of such documents, as well as for the implementation of any treatment or mitigation measures identified during the EHP review that are necessary to address potential adverse impacts. Subgrantees may use HSGP funds toward the costs of preparing such documents and/or implementing treatment or mitigation measures. Failure of the subgrantee to meet Federal, State, and local EHP requirements, obtain applicable permits, and comply with any conditions that may be placed on the project as the result of FEMA's EHP review may jeopardize Federal funding. Oregon Emergency Management 36 FY 2008 Homeland Security Grant Program Application Procurement Standards General — Agencies must follow the same policies and procedures used for procurement from non -Federal funds, in accordance with the appropriate OMB Circular (OMB Circular A-110 or OMB Circular A-102). Standards — Subgrantees must use their own procurement procedures and regulations, provided that the procurement conforms to applicable Federal laws and standards. Adequate Competition — All procurement transactions, whether negotiated or competitively bid and without regard to dollar value, shall be conducted in a manner so as to provide maximum open and free competition. All sole -source procurements in excess of $100,000 must receive prior written approval from Oregon Emergency Management. Non-competitive Practices — The subgrantee must be alert to organizational conflicts of interest or non-competitive practices among contractors that may restrict or eliminate competition or otherwise restrain trade. Contractors that develop or draft specifications, requirements, statements of work, and/or Requests for Proposals (RFP) for a proposed procurement shall be excluded from bidding or submitting a proposal to compete for the award of such procurement. Any request for exemption must be submitted in writing to Oregon Emergency Management. Sole Source Procurement (Non -Competitive) All non -state procurement transactions must be conducted in a manner that provides, to the maximum extent practical, open and free competition. However, should a subgrantee elect to award a contract without competition, sole source justification may be necessary. Justification must be provided for non-competitive procurement and should include a description of the program and what is being contracted for, an explanation of why it is necessary to contract noncompetitively, time constraints, and any other pertinent information. Subgrantees must obtain approval from Oregon Emergency Management. Justification for Non -Competitive Procurement (Sole -Source Justification) The following outline provides the recommended format for subgrantees to use when pursuing sole source procurement. Paragraph 1: • A brief description of the program and what is being contracted Paragraph 2: • Explanation of why a non-competitive contract is necessary, to include the following: • Expertise of the contractor • Management • Responsiveness • Knowledge of the program • Experience of personnel Oregon Emergency Management 37 FY 2008 Homeland Security Grant Program Application Paragraph 3: • Time Contracts • When contractual coverage is required and why • Impact on program if dates are not met • How long would it take another contractor to reach the same level of competence? (Equate to dollars if desired) Paragraph 4: • Uniqueness of the vendor, product, services to be procured, or work to be performed Paragraph 5: • Other points that should be covered to make a convincing case Paragraph 6: • A declaration of how this action is in the best interest of the agency Oregon Emergency Management 38 SHSP Distribution by Population, County Base, & Region Census 2000 Total FY08 40% County Dist. Award $983,700 Geographic area Ore • on Total population 3,421,399 Total FY08 60% Population Dist. Award $1,475,565 Baker County 16,741 0.49% 7,220 $ 27,325 $ 34,545 Benton County 78.153 2.28% $' 33,705 27,325 $ 61,030 Clackamas County 338,391 9.89% 145,940 27,325 $ 173,265 Clatsop County Columbia County 35,630 43,560 1.04% $ 15,366 $; 1.27% 18,786 27,325 27,325 $' 42,691 $ 46,111 Coos County 62,779 1.83% 27,075 27,325 $' 54,400 Crook County 19,182 0.56% 8,273 27,325 $ 35,598 Curry County 21,137 0.62% $ 9,116 27,325 36,441 Deschutes County 115,367 3.37% 49,755 27,325 77,080 Douglas County 100,399 2.93% 43,300 $'r 27,325 70,625 Gilliam County 1,915 0.06% 826 27,325 28,151 Grant County 7,935 0.23% 3,422 $ 27,325 30,747 Harney County 7,609 0.22% 3,282 $ 27,325 30,607 Hood River County 20,411 0.60% $' 8,803 27,325 $ 36,128 Jackson County Jefferson County Josephine County 181,269 19,009 75,726 5.30% 0.56% 2.21% 78,177 8,198 32,659 27,325 27,325 27,325 $ 105,502 35,523 $ 59,984 Klamath County 63,775 1.86% $ 27,505 $ 27,325 $i 54,830 Lake County 7,422 0.22% 3,201 27,325 $ 30,526 Lane County 322,959 9.44% $ 139,284 $` 27,325 $. 166,609 Lincoln County 44,479 1.30% 19,183 27,325 $ 46,508 Linn County 103,069 3.01% $ 44,451 $' 27,325 $' 71,776 Malheur County 31,615 0.92% 13,635 $ 27,325 $ 40,960 Marion County 284,834 8.33% $" 122,842 27,325 $ 150,167 Morrow County 10,995 0.32% 4,742 $ 27,325 $ 32,067 Multnomah County 660,486 19.30% $' 284,851 27,325 $ 312,176 Polk County 62,380 1.82% 26,903 27,325 54,228 Sherman County, 1,934 0.06% $' 834 $ 27,325 $ 28,159 Tillamook County 24,262 0.71% 10,464 $ 27,325 37,789 Umatilla County 70,548 2.06% $i 30,426 $' 27,325 $I 57,751 Union County 24,530 0.72% 10,579 $ 27,325 37,904 Wallowa County 7,226 0.21% 3,116 $' 27,325 30,441 Wasco County 23,791 0.70% 10,260 $ 27,325 37,585 Washington County 445,342 13.02% $' 192,065 $ 27,325 $ 219,390 Wheeler County 1,547 0.05% 667 $ 27,325 $ 27,992 Yamhill County 84,992 2.48% $ 36,655 $ 27,325 $ 63,980 Total Base Award Distribution 100.00% $ 1,475,565 $ 983,700 2,459,265 Distribution by Region Region 1 $ 447,689 Region 2 $ 831,422 Region 3 $ 493,560 Region 4 $ 391,572 Region 5 $ 295,022 Total $ 2,459,265 5% for Tribal Projects = $129,435 Total FY08 Allocated 80% Funds (95% Population and Base, 5% Tribal) = $2,588,700 39 4) x a� 2Cl) � / LL N LL o W c /11 O ▪ N M W .12 LLJ c JL CL o con V + E O 1- d 0 N Law Enforcement 2 i.L Fire (7) HazMat (3) LL Law Enforcement c a 0 N 0. 0 LE 0 2 W O W J O W —J 5 - LE 0 O) 0 d CO N 0 LL } X 0 LL X c c O 0 LL. W 0 LL 0 LL W 0 d O U d' c , 2 X 2 W N >- X 2 W A" 0 c a) 0) E W X a) 0 L. X t3 .4- yO Fo V O O O 0 t[) En O O O 0 M O O Lf) ti fR O O co En O O O 50 O O 0 50 50 N Eft tC co 0 _0, E°- 0 0 O M En R N r O O O 0 0 O O M 0 0 0 0 O O M E9 N 0 O F 0 0 0 0 O 0 0 O O R u, 4- O d' EF). 0 tF ft 0 0 CO Eft c p O O O 6R} O O N O 0 u) N 69- 0 co En O O 0 11.6 r O O 4 - co 0 N 141 N Cr) O AEL Reference Number 06CP-01-PORT 06CP-01-MOBL 06CC-03-SATB 01 AR -03 -PAPA 03SR-01-ABAG 02PE-01-BSUT E Portable Radios Mobile Radios Satellite phones z 0 0 d Air lifting system EOD Bomb Suit Equipment Category tl) C O U E E O 0 (�. Q O a) c c 0 o U E E O 0 a) N N 0 O N O U E E O 0 0 a) 0 O c CBRNE Search and Rescue Explosive Device Mitigation 4- .0 N 0 0. W 0 N 0 0. W 4- 0. 0. 0 co 0 (0 a Hire a contractor for EOP FEMA Conference (travel / per diem) Planning Subtotal 0 'lC F L 0 E z` 0 14, 0 N Item/Expense ui a) 70 5 0) v vi U ato L6 5 E co -0 15 co U L Travel and overtime Travel and overtime Training Course ICS 300/400 AWR-160 WMD Awareness WMD HazMat Evidence Collection O N 0 Training Subtotal OT/Backfill for full scale exercise (50 FTE - LE) Exercise Subtotal 'j U 0 c5555 0 0. .0 N 0 O ' a+ L r N - •E a c d N R' cv Recurring fee for satellite phones (12 months) M&A Subtotal PROJECT TOTAL FY 2008 Homeland Security Grant Program Application FY 2008 HSGP Authorized Program Expenditures Allowable Planning Costs HSGP funds may be used for the following types of planning activities: (LE = Law enforcement oriented activities) Public education and outreach Develop and implement homeland security support programs and adopt on • oin • DHS national initiatives Develop and enhance plans and protocols Develop or conduct assessments Establish, enhance, or evaluate Citizen Corps -related volunteer programs Hiring of full- or part-time staff or contractors / consultants to assist with planning activities (not for the purpose of hiring public safety personnel fulfillin• traditional •ublic safet duties Conferences to facilitate planning activities Materials required to conduct planning activities Travel/per diem related to planning activities Overtime and backfill costs (IAW operational Cost Guidance) Other projects areas with prior approval from FEMA Allowable Organizational Activities HSGP funds may be used for the following organizational activities: Allowable Organizational Activities N 4 Overtime for information, investigative, and intelligence sharing activities u • to 25% of the allocation Reimbursement for select operational expenses associated with increased security measures at critical infrastructure sites, incurred during periods of DHS -declared Alert u • to 25% of the allocation Hiring of full- or part-time staff or contractors for emergency management activities Hiring of new staff positions/contractors/consultants for participation in information/intelligence analysis and sharing groups or fusion centers activities (limited to 25% of the allocation) Note: HSGP is not intended as a hiring program and funds may not be used to support the hiring of sworn public safety officers or to supplant traditional public safety positions and responsibilities. Oregon Emergency Management 41 FY 2008 Homeland Security Grant Program Application Allowable Equipment Costs This table highlights the allowable equipment categories for HSGP. A comprehensive listing of the FY 2008 Authorized Equipment List (AEL) may be downloaded from the Responder Knowledge Base (RKB) at httpJlwww.rkb.mipt.org. Allowable Equipment Cost Categories Personal Protection Equipment (PPE) Explosive Device Mitigation and Remediation Equipment CBRNE Operational Search and Rescue Equipment Information Technology Cyber Security Enhancement Equipment Interoperable Communications Equipment Detection Equipment Decontamination Equipment Medical Supplies and Limited Pharmaceuticals Power Equipment CBRNE Reference Materials CBRNE Incident Response Vehicles Terrorism Incident Prevention Equipment Physical Security Enhancement Equipment Inspection and Screening Systems Agricultural Terrorism Prevention, Response, and Mitigation Equipment CBRNE Response Watercraft CBRNE Aviation Equipment CBRNE Logistical Support Equipment Intervention Equipment Other Authorized Equipment Oregon Emergency Management 42 FY 2008 Homeland Security Grant Program Application Allowable Training Costs HSGP may be used for the following training activities: Overtime and backfill funding for emergency preparedness and response personnel attending FEMA -sponsored and approved training classes Overtime and backfill expenses for part-time and volunteer emergency response personnel participating in FEMA training Training workshops and conferences Full- or part-time staff or contractors/consultants Travel Supplies Tuition for higher education Other Items 111111 111111111 IEEE IEEE MEE MEE Note: HSGP is not intended as a hiring program and funds may not be used to support the hiring of sworn public safety officers or to supplant traditional public safety positions and responsibilities. Allowable Exercise Costs HSGP funds may be used for the following exercise activities: Allowable Exerciserelated Costs Design, develop, conduct and evaluate an exercise Exercise planning workshop Full- or part-time staff or contractors/consultants Overtime and backfill costs for personnel participating in FEMA exercises Implementation of HSEEP Travel Supplies Other Items Note: HSGP is not intended as a hiring program and funds may not be used to support the hiring of sworn public safety officers or to supplant traditional public safety positions and responsibilities. Oregon Emergency Management 43 FY 2008 Homeland Security Grant Program Application Allowable Management and Administrative (M&A) Costs HSGP funds may be used for the following M&A costs. Allowable M&A Costs' Hiring of full- or part-time staff or contractors/consultants to assist with the management of the respective grant program application requirements, compliance with reporting and data collection re. uirements. Leasing or renting of space for newly hired personnel during the period of performance of the • rant pro • ram P 11111111 Development of operating plans for information collection and processing necessary to respond to FEMA data calls 151151151 Overtime and backfill costs 111111151 Travel 151151151 Meeting related expenses 111151151 Authorized office equipment 11111111 Recurring expenses such as those associated with cell phones and faxes during the •eriod of •erformance of the •rant grogram 111111111 Unauthorized Program Expenditures HSGP funds may not be used for the following activities: Expenditures for items such as general -use software (word processing, spreadsheet, graphics, etc), general -use computers and related equipment (other than for allowable M&A activities, or otherwise associated preparedness or response functions), general -use vehicles, licensing fees, wea•ons and ammunition. Construction and Renovation Activities unrelated to the completion and implementation of the grant Other items not in accordance with the AEL or previously listed as allowable costs. 01 Oregon Emergency Management 44