Loading...
2010-2606-Resolution No. 2010-016 Recorded 5/10/2010REVIE E LEGAL COUNSEL DESCHUTES COUNTY OFFICIAL RECORDS Q 20JOE2606 NANCY BLANKENSHIP, COUNTY CLERK 1rJ p COMMISSIONERS' JOURNAL see 05/!0/a1v WWW Hn 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 1.37, 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 1.37.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 I of 2 — RESOLUTION NO. 2010-016 Section 2. On May 5, 2010,.at 1.0: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 5 � of 20 /0 BOARD OF COUNTY COMMISSIONERS ATTEST: r Recording Secretary PAGE 2 of 2 — RESOLUTION NO. 2010-016 OF DESCHUTES COUNTY, OREGON DENNIS R. LUKE, hair exvt" 6(�� ALAN UNGER, Vice Chair TAMMY B , Commissi er 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 27913.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 KCvnCywu LEGAL CO)IJN,SEI. DESCHUTES COUNTY 8-14 UR'VICE DISTRICT CONTRACT FOR THE PURCHASE OF GOODS 4" Conbw'7 This Contrad is between Deschutes County 9.1-1 Service District ("District") and Executive Information Services, a Nevada corporation ("EIS" or "Contraclon. This Contrail is effective on the date it has been signed by all parties and all required District approvals have been obtained, inclWing the approval of the Oregon Department of Emergency Management. This Contract expires on May 31, 2011. The parties may extaxd 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 teems and conditions: RECITAL This Contract is for the purchase and sale of tree following: Computer -Aided Dispatch ("CAD") interface development, CAD software, CAD server hardware, installation and licensing. I. DEFINITIONS. A. "Contractor Intellectual Property' means any intellectual property owned by contractor and developed indbpenderrtly from Services. B. "Goods" means the goods specified in section 2. C. "IRS" means the Internal Revenue Service. D. *Open Source EWnenW means any Work Product subject to any open source in tiativve certified license, including Work Product based upon any open source initiative certiW licensed work. E. "Services" means the services, if any, that we 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 Producr means all Goods and Services Contractor depvers 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 foil ms: 11. Services and 3tandafrds of Peg onronee EIS shell provide to the [strict all of the Services and deliverables described in and in the manner "ired by all of the following documents: DMMPup I of 16 panty 9.1.1 -Ca att_2ApriU 'Ifti Der 2.010--`P j 0 1 o � r P Gw 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 QT442/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,280 ii. Description and Quantity: As described in Schedule A, two years of software license and support for five (S) PSAPs beginning one (1) calendar year after system testing and acceptance, in accordance with section 4.0. Price: $12,000 Deschutes County_9-1-1_Contract_2Apr10 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 $64,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. Mschutes_Counq_9 I-I_Contract Mprl0 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 htt :// i v. 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. Deschutcs_County_9-1-1 _Contract_2Apr 10 Page 4 of 16 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.1) 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.1. 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-I_Contract 2Apr10 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 manufacturers 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 2798.220, 2798.225 (if applicable to this Contract), 2798.230 and 2798.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 QRS 279A.010(1)(hh)), and other recycled plastic resin products and recycled products (as "recycled product" is defined in QRS 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_2Apr10 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 Contracbor'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 _Counq _9-1-1 _Con tract_Mpr 10 Page 7 of 16 ii. INDEMNITY INFEINGEMENT.QLBMS. 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_2Apr10 Pap 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 Districts 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. Districts Remedies. If Contractor is in breach under section 4.0.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 Districts 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 singty, collectively, successively or in any order whatsoever. If Contractor is found to not be in breach under section 4.0A, the rights and obligations of the parties shall be the same as if this Contract was terminated pursuant to section 4.R.H.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.0.4 and whether or not Contractor elect$ to exercise its right to terminate this Contract under section 4.R.iii, Contractors sole remedy is a claim against the District for the unpaid price for any Goods delivered and aid by the District Deschutes_ County_9-1-1_Contract Mpr10 Page 9 of 16 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. 0. 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. L MUTUAL CONSENT. The Contract maybe 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_2Aprl0 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. AN 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, tide, 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 Districts 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 Districts 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 (8) 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 ah financial Records in accordance with generally accepted Deschutes ,�County_9-1-1_ContrW 2Apr10 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 S. 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, 41, 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 10 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.1., 4. M, 4. N, 4.0, 4.12, 4.Q, 4.11, 4.S, 41, 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 Contractoes 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. AA. 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-248-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 heli 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. Dcschutes_County_*I-1_Convact 2Apri0 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 QRS 658.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_94-1_Contract 2Apr10 Page 14 of 16 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. CERT11FICATION3 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 IS 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:/(M.Ig@s.00v/offices/enforcement/gJpG sdeaI1„gain.ndf: 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 / is not a nonresident alien as defined in 26 USC § 7701(b)(1) (check one). See section 4.A.ii. Contractor (print Contractor's na : Exe utive Information Services, Inc. Authorized Signature: By (print name); ' j�QVneznr Title: Date: g FEIN ID# or SSN# (required): C—dCy/rJG Contractor's Contact Person (Type or Print):_ _T&a&Q1. , .Lim& Contact Telephone Number: (3SZ 1 Contact Fax Number: ( yo 7 t . A*,a � -e. ?-T- Deschutes — Coun”- I - - - Deschutes_Coun"-1- I_Contract_2Apr 10 Page 16 of 16 Contact E -Mail Address: Mailing Address: ko 0 c 4 4 , r -L. 3(/970 Deschutes County_9-1-1_Contract_2Apr10 Page 17 of 16 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: shawnpodeschutes.org District Mailing Address: 63333 Hwy 20 #911, Bend, OR 97701 DATED this � Day of 2010. BOARD OF COUNTY COMMISSIO ERS OF DESCHUTES COUNTY, OREGON, ACTING AS THE GOVERNING BODY OF THE DESCHUTES COUNTY 9-1-1 SERVIC DISTRICT. D9NNI +SLUKE�Chairr ALAUN ER, Commissioner ATTEST: TAMMY 1 EY, Co issioner (kh&: �A�-I� Recording Secretary E)mbutes_County_9-1.1_Contract 2Apr10 Page 18 of 16 SCHEDULE A EIS PRICING PROPOSAL Contractors Pricing Proposal dated September 10, 2009, Revised January 14, 2010 price proposal number OT -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_Contract_2Apr10 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 20'1% 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@goels.net Executive Information Services, Inc. Corporate Headquarters: 1396 NE 20th Ave. Suite 100 Ocala, FL 34470 http://www.goels.net (856) 701-6107 Telephone (206)201-6107 Fax (877) 347-9273 X42 Toll Free Sales (209) 580-0400 HelpDesk Executive Information Services, Inc. a 1396 NE 20th Ave. Suite 100- Ocala, FL 34470 9 Phone: (856) 701-6107 • WWW.Soeis.net Executive Information Services, Inc. 1396 NE 20th Ave. Suite 100 - Ocala - Fl. - 34470 - Phone: (856) 701-6107 PRICING PROPOSAL Agency: Central Oregon CAD -to -CAD integration Proposal Number: QT -442/3 REV 1 Address: Via! Deschutes County Address: Proposal Cresllon D@W. September 11, 2009 Proposal Rw skm January 14, 2010 Contact: Rick Silbaugh Proposal Expirallon Dale: March 14, 2010 Tslephorm (541) 388-0185 x2306 P WM Ey: A. Missler 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 Communions Saftwars LicapMQ $63,000.00 $31,000.00 $14,610.00 $31,000.00 $14,810.00 $37,600.00 $14,810.00 $31,000.00 $14,810.00 $37,800.00 $14,610.00 168 .00 $136,050.0.01 SUB -TOTAL MaGM00 ISYSTIEM TOTAL�4 6fi0 2nd Year Support $6,000.00 3rd year support $6,000.00 PROJECT TOTAL $316,650. $31,000.00 $14,810.00 $31,000.00 $14,810.00 Pricing does not include appkcable stale and local tax. - kiek des Site License for the above listed software unless otherwise specified. - ElTs tens aro Net 30. Pricing includes shipping charges. Quote only covers products and services listed herein. Quote is valid only through the expiration dots 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 @ I Wo of the System and Software Pricing. f snlldsrrgal Stlrlsrasrrt: The inforwrwpnn =:= In tats docuawrrl Is � end inWxW only M be viewed by Vw raei fto leled Www N you are not the h amlad (pleow tionr o to correct re- cipisnt) you ars herby noWled that any dkk trtlan or copybrp of title dwono d ie sft* pmhMft d. N you how received docwrwM in error, contact #0 sender Nsled abvw end the dacwnorM. 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 Proposal Number: QT 442/3 REV 1 Proposal Creation ate: September 11, 2009 Ate: Proposal Revlatpl: January 14, 2010 Contact: Rick Silbaugh Proposal Expiration Date: March 14, 2010 Tok$ft w: (541) 388-0185 x2906 Prepared By: A. Missler SRVM2 Development & Documentation 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 $62,000.00 Executive Information Services, Inc. 1396 NE 20th Ave. Suite 100 - Ocala - FL - 3"70 - Phone: (856) 701-6107 J plc Jefferson County Communications M2AX M2 Switch License Site $25,000.00 WCAD 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,500.00 SRVH7 On -Site Ire Udialion & Training Site $5,400.00 Crook County Communications M2AX M2 Switch License Site $25,000.00 M2CAD CAD M2 adapter site $6,000.00 XXXX CAD Upgrade Software She 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 Installadon & Training Site $5,400.00 Tri -County Communications M2AX M2 Switch License Site $25,000.00 M2CAD CAD M2 adapter Site $6,000.00 XXXX CAD Upgrade Software Site NC CADAM CAD Mapping Software Site $6,800.00 XXXX Server Hardware Machine $3,930.00 SRVH2 Technical Services Site $2,680.00 SRV5 Travel & Per Diem Site $2,860.00 SRVH7 On -Site Instalation & Training $5,400.00 Klamath County Communications M2AX M2 Switch LICerlse 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 $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 «. Its as, g.g . M2 Switch License Agency: Central Oregon CAD -to -CAD integration Proposal Number: OT -442/3 REV 1 Address: Via/ Deschutes County Proposal Creation Dat*. September 11, 2009 Address: Propossl Revision: January 14, 2010 Contact: Rick Sllbaugh Proposal Expiration Data: March 14, 2010 Telephone: (541) 388-0185 x2306 Prepared By: A. Wssler Lake County Communications $52,610.00 M2AX M2 Switch License site $25,000.00 M2CAD CAD M2 adapter Site $6,000.00 XXXX CAD Upgrade Software Site NC CADAM CAD Mapping Software Site $6,800.00 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 Wasco 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 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 $45,810.00 $45,810.00 Executive Information Services, Inc. 1396 NE 20th Ave. Sufte 100.Ocala - FL - 34470 - Phone: (856) 701-6107 A wwy: Central Oregon CAD -to -CAD Integration Address: Vla/ Deschutes County Ad*om* p►opoes! Number: OT442/3 REV 1 Proposal Croollm Date: September 11, 2009 Proppsal Illovislon: January 14, 2010 Cordon: Rick SNbsugh Proposal Expiration pole: Manch 14, 2010 Tdoptrone. (541) 388-0185 x2306 Prepared By: A. Missler Powar[djPTAGS Quad Core AMD OpteronTM 2330, 2.QGHz. 1 Ghz HyperTranspoA 4GB DDR2, 667Wiz, 4x1GB Single Ranked DIMMs SAS OR SAS internal RAID adapter, PCI -Express Add-in SAS BAR SATA/W Conboller RAID 1,Support 2 Cabled Hard Drives (2) 146GB 15k RPM Sedal-Af4ch SCSI 3Gbps 3.5 -in Cabled Hard Drive Intel PRO 1000PT 1GbE Dual Port NIC, PCI" 16x DVD -ROM Drive, Internal, SATA Electronic Documentation and OpenManage DVD Kit Operall" system: Windows Sarver0 2008, Standard Edition, Includes 5 CAU 1 k"dware support sarviass: 3Yr Basle Hardware Warranty Repai 5x10 HW -Only, 5x10 NBD Onsite Techni al Services - Server Configwfation Esthnated Hardware Total $3,930.00 Executive Information Services, Inc. 1396 NE 20th Ave. Suite 100 - Ocala - PL - 34470 - Phone: (856) 701-6107 iPRICING PROPOSAL ..■ Agency: Central Oregon CAD -to -CAD Integration Proposal Number: QT -442/3 REV 1 Address, Via/ Deschutes County Address: Contact: Rids Silbaugh Telephone: (541) 388-0185 x2306 Proposal Creation Date: September 11, 2008 Proposal PhrAslon., January 14, 2010 Proposal ExpWatlon Dale: March 14, 2010 Prepared By: A. MhWer 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. S. 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-1TContract_2Apr10 E 103 14 e111, 463 PS.NETIM2 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. Nschutcs_County_94-I_Contract_2Apr10 PS.NET/M2 PDCC ODOT Integration CAD to CAD Pr*d Ouer4ww SMUOMW 1Q, 2M The &formation in this document is provided for planning purposes only. The software described in this document is furnished under a license agreement or non-dWwwe 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: Execudw Information Services, Inc. 1396 NE 20th Ave. Suite 100 Ocala, Fl 34470 Phone: 856\701-6107 FAX: 206\201-6107 Internet Mall: saksogoeis.net COPYt'M O 2' Inafthfe WormAlm Services, Inc. AM d0ft reserved Table of Contents Executive Information Services, Inc.......................................................................................................1 PS.NET CAD Interface with ODOT PDCC.................................................................................................1 ODOTCAD Integration - Executive Summary ..........................................................................................1 raneralized Statement of Work.............................................................................................................3 GeneralConsiderations 4 ......................................................................................................................... M2Switch Capability Overview................................................................................................................. 6 M2 Mode: Local Exchange Manager.....................................................................................................6 M2»to-PDCC data exchange project..........................................................................................................7 LocalData Systems (CAD): .....................................................................................................................7 M2Regional Switch Services: ................................................................................................................. 7 WebService.........................................................................................................................................7 pgrades:..................................................................................................................... Existing System Upgrades: .............................................................. I ......................................................8 Basic Network (LAN and WAN) Infrastructure: ........................................................................................8 M2CAD -to -CAD Features.........................................................................................................................10 M2Standard Messages.......................................................................................................................14 Implementation........................................................................................................................................12 EstimatedProject Timeline: ................................................................................................................. 12 PDCC Integration — General Overview JOSPAET 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 POCC 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 0907200S.doc 3. OSP TOC_Connection_Specs_Final_550.doc 4. KeyPolnts2.doc Executive Information Services, Inc. Page i A 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, Inc. 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.NE7/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. S. 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. 4. 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 Information Services, 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. Executive Information Services, Inc. Page 1 4 POCC 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. S. 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 paws credentials, including assigned roles, to Agency 8 with a "quem' request. Agency 8 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 PSMET 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 Services, Inc. page 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. Agency UVM M18witch A1.0, Executive Information Services, Inc. Page 1 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 PSMET 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. vocal 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. M12 Regional Switch Seffvkes: 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 A 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 Information Services, Inc. Page 1 7 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 soivlao and capable of supporting requests from any authorized external system. The basis of web lU 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 Y 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 15tb�r+rrswq w de e fer f'►n�vf�rr 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 polity 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 Executive Information Services, Inc. P a & e 1 3 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 wHI 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 Information Services, Inc. Page 1 51 PDCC Integration — General Overview M2 CAD -to -CAD Features Ileal Time CAO 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. Agency Level Agency 02 U2'$retch ';• r� Agency L Dispatcher can accept call transfer and aaaeme its call. icy for Agency 1. Dispatcher can access ststw monitor and acdve call infarmadon from any other MS supported CAD system. Agency's can transfer attire weds to neighboring ageney far dispatch and management on command. Agency #1 M2 Standard Messages uispamn a .0011 co mmWk tloms L RxMting PDCC Server Base 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 I 10 Local Databaps Agency Level{q a' (CAD, aMs, .lsts, wananns, IIa2 Switch fl, ste) RxMting PDCC Server Base 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 I 10 PDCC Integration — General Overview 2. Calla 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 activtty 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 polity, 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 Inlermaden 0* 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. Executive Information Services, Inc. Page 1 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 ESS 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 Orpnixation. 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 pian 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 Information Services, Inc. Page 1 12 PDCC Integration — General Overview General Task b: Installation and Delivary of the M2 krterfwa servke 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 Tesding. 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 Information Services, Inc. Page 1 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- I_Contract_2Apr 10 Oregon Department of Transportation P550S ODOT to OSP Connection Specification Prepared for: Or"= DapsrMmA of Tranapartaftm Prepared by: O#dko Busirass Systems One World Trade Center, 121 Salmon Street S.W. 11th Floor, Portland, Oregon 97204 srlsnoor It -V. o a�......................... n.z.�.a: goer swoons AI-,I''systems o� . . .. ... 'Rl- 90 "�M \ \ l TABLE OF CONTENTS 1.0 Introduction ....................................................................................................................... 6 1.1 Abstract ..... ................................................ ..................................................................... I....... 6 1.2 Revision History......................................................................................................................6 1.3 Related Documents................................................................................................................6 2.0 Apptkation Architecture................................................................................................ 7 2.1 Business Processes to Message Set Cross Reference..........................................................7 2.1.1 Get List of Online Operators.....................................................................................7 2.1.2 Operator to Operator Messaging.............................................................................7 2.1.3 Manage Events........................................................................................................7 2.1.4 Synclwonize External Events....................................................................................8 2.1.5 Send and Receive Event from External Agency.......................................................8 2.1.6 Monitor External Events........................................................................................... 8 2.1.7 Heartbeat.............................................................................................................9 2.1.8 Get List of Valid Endpoints.......................................................................................9 2.2 Operator to Operator Messaging...........................................................................................9 2.2.1 Scenario: Get List of Online OSP Operatars............................................................9 2.2.2 Narrative...................................................................................................................9 2.2.3 Scenario: Get List of Online TOCS Operators........................................................10 2.2.4 Narrative .................................................................................................................10 2.2.5 Scenario: Operator to Operator Messaging............................................................11 2.2.6 Narrative.................................................................................................................11 2.3 Manage Events.....................................................................................................................12 2.3.1 Scenario: TOCS Publishes Event. .......................................................................... 13 2.3.2 Narrative................................................................................... ........................13 2.3.3 Scenario: OSP Publishes Event.............................................................................14 2.3.4 Narrative.................................................................................................................14 2.4 Synchronize External Events................................................................................................14 2.4.1 Scenario: TOGS Updates a Shared Event.............................................................15 2.4.2 Scenoio: OSP Updates a Shared Event................................................................16 2.4.3 Narrative.................................................................................................................16 2.5 Send and Receive Events from External Agency.................................................................17 2.5.1 Scenario: Receive Event for External Agency........................................................17 2.5.2 Narrative.................................................................................................................18 2.5.3 Scenario: Send Event to an External Agency.........................................................18 2.5.4 Narrative.................................................................................................................19 2.6 Monitor External Events........................................................................................................19 2.6.1 Scenario: Request AN Open Events............................:..........................................20 2.6.2 Narrative.................................................................................................................20 ODOT-OSP Connection Specification I onnn. WfNl�ti MnatA 3.0 M"M*ArcftitKWM.....................................................................................................29 3.1 Message Soft .................................................................................................................:.....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(ME)....................................................................................30 3.1.7 Request InfMation(RIN)......................................................................................30 3.2 Message Patlems.................................................................................................................30 3.2.1 Requwt..................................................................................................................30 3.2.2 Raponse...............................................................................................................30 3.2.3 Broadcast Message................................................................................................30 3.2.4 Adum4edgement..................................................................................................30 3.2.5 Fault .......................................................................................................................31 4.0 Techn" Arch* d+re.................................................................................................... 32 4.1 2.6.3 Scenario: Request Incident Details........................................................................21 2.7 Get List of Valid Endpoints...................................................................................................21 4.3 2.7.1 Scenario: TOCS Requests list of Valid Endpol►*.................................................21 Service Archileclum..............................................................................................................35 2.7.2 Narrative.................................................................................................................22 4.5 2.7.3 Scenario: OSP Requests list of Va§d Erndpokft...................................................22 4.5.1 Public Interfaces.....................................................................................................37 2.7.4 NarraWe.................................................................................................................22 2.8 Heartbeat..............................................................................................................................23 2.8.1 Scenario: TOCS Heartt�t to OSP........................................................................23 2.8.2 Narrative.................................................................................................................23 2.8.3 Scenario: OSP Heartbeat to TOCS........................................................................24 2.8.4 NarraGve.................................................................................................................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 Scemb: OSP Request Handoff to TOGS.............................................................25 2.9.4 Narrative.................................................................................................................26 2.10 Allemate Pal ts.....................................................................................................................26 2.10.1 Scenario: Endpoint cannot connect to ESB............................................................26 2.10.2 Narrative.................................................................................................................27 2.10.3 Scenairio: Endpoint does not receive acknowbdWnent born the ESB .................... 27 2.10.4 Narrative.................................................................................................................27 2.10.5 Endpoint does not receive expected 1512 response messape .............................. 28 2.10.6 Narnadw.................................................................................................................28 3.0 M"M*ArcftitKWM.....................................................................................................29 3.1 Message Soft .................................................................................................................:.....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(ME)....................................................................................30 3.1.7 Request InfMation(RIN)......................................................................................30 3.2 Message Patlems.................................................................................................................30 3.2.1 Requwt..................................................................................................................30 3.2.2 Raponse...............................................................................................................30 3.2.3 Broadcast Message................................................................................................30 3.2.4 Adum4edgement..................................................................................................30 3.2.5 Fault .......................................................................................................................31 4.0 Techn" Arch* d+re.................................................................................................... 32 4.1 Assumptlorre.........................................................................................................................32 4.2 Requirwnw>m.......................................................................................................................33 4.2.1 Business Requirem...........................................................................................33 4.3 Technical Requirernents.......................................................................................................34 4.4 Service Archileclum..............................................................................................................35 4.4.1 Service Components..............................................................................................35 4.5 Corntowim" Between Carnpor..................................................................................36 4.5.1 Public Interfaces.....................................................................................................37 ODOT-OSP Conrmlon SpKificaloi Onri�nM se sranrs 5.0 Sot`tmre Development environment............................................................................. 4.5.2 Expected WSDL Definitions...................................................................................37 Mlcrosoft .Net.......................................................................................................................56 4.5.3 Distriwbuting WSDL Files..........................................................................................38 Development Standards.......................................................................................................56 4.5.4 SOAP.....................................................................................................................38 5.2.1 Coding Standards...................................................................................................56 4.5.5 Canonical Messages as SOAP Payload................................................................39 56 4.6 Endpoint Architecture........................................................................................................... 39 6.0 Technical Environment................................................................................................... 4.6.1 Static Model............................................................................................................40 Application Server.................................................................................................................58 4.6.2 Narrative.................................................................................................................40 6.3 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 Tor•.aM wsageManager ......................43 4.6.6 Nam..................................................................................................................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 specilled 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 Notikation & 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 Sot`tmre Development environment............................................................................. 56 5.1 Mlcrosoft .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 Contiguratbn..........................................................................................................58 6.3 Network....................................................................................................................I........... 58 ODOT-OSP Connection Spedicabon N onunr ws�rus srmws 6.4 Operating SWmandsand PnmMduMw..................... ............ ...................... ................... ..N8 7.0 TraceaWlity Go 7\1 Amm�p�ws......................................................................................................................... �� Dmm�mnFoh�/......................................................................................... 817.2 7.3 Businmwssm/ 74 Technical RmWroam*..................... ................. ................... ..................... .................... nu 8.0 Teradnology...................................... ~......................................... ........... ...................... fill 9.0 Appendix A: O0OT to OSP 3ecuft Implementation^~�~~~~~~^~~~~^~~~~~~~~~~~68 10.0 Appendix 0: Enhwoss Logging Ubmary................................................. ~.... ~.............. 76 10.1 Intmdumdw......................................................................................................... ................ /n 10.2 OwmWNmm......................................... ...... .............................................................................. 'w 10.3 TnacoUslanus...................................................................................................................... '' 104 OriglnW&dul... .......................... ..................................................................................... 7/ 10.5 EntuprimmLNmMAPPWAmmBImCkS................................................................................... /w 10.6 Using the Exce*n HNmding&Logging ftd.................................................................... /w 11J0 Appendix C: Adding Now PartnNrs........~����~....^..... ..........~~~~^~...~~~~~^~«2 11.1 Purpose ................................... ........................................................................................... nu 11.2 OwarAex............................................................................................................................... ou QDQi-0SP WWOCOM smalca 1 v Iin� ,. eus�aesssrsnsu INTRODUCTION 1.1 Absbvd The Purpose of this document is to describe the requirements for the connection between the ODOT TOCS system and the OSP PSSI GAD system. 1.2 Revision gory 1.0 Initial Release 'i7Jl .�.'�.: �r?�a'cv.. 45,: � fare-.,.�2 �i�?�.ri'�,y§�:..� ... • ': u � �.: `� ,�<< ... 1.3 Related Documents ODOT-OSP Connection Spwkab n 6 Dnxn. ruswas. srmrs 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. AS01 While it, is expected that integration with other agencies will happen In the future, the first agency ODOT 1s, .integrating with is OSP. The PP0,T,to.OSP Integration is the only iptegration 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 Ust 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 Gmnecbw SpBa ailim 7 onllm- ru��wss a..ToMx • 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 (GHQ) if the event meets the OSP auto create criteria. Carie•• i7�1>�i s Replaces. ,. 21.4 Synchronize External 04Pq ReeluEst Ail, Opeci 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 ExWnal Everts Monitor External Events uses the following message sets: • Request Inbrmation (RIN) • Incident Description (IDX) • Grant Handoff (GHO) • New Incident Event (NIE) OWT-OSP Caracom Spedlicalim 8 onpnr fUf4llff frsHNf 2.1.7 Heartbeat The Heartbeat Message uses the following message sets: • Request Information (RIN) • Incident Description (IDX) 2.1.8 Gat List of Valid Endpoints Get Ust 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 i(SCS EndeeintEM ID�] Request Worma km (RIN) Request Informstion (RIN) Request Inkmwoon (RIN) ----_ACK I I i I Inddem Description (IDX) i Incide t Description (IDX) _ Incident Description (IDX) ACK 1 _.------------- 1 � I I 1 1 1 1 1 I I 1 1 I I 1 I I I I I I I 1 I I I 1 1 1 2.2.2 Narrative 1. TOGS 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 Spedlieaflon 9 online wsxlcss srsnMs 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. S. 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 TOGS Endpoint routes the message to TOCS. 2.23 Scsnario: Got List of Onikw TOCS OperAm E Regw�t kHgmntion (RUN7 n,wW Woanepen (RUN) -. Request hODMWIbn (RIN) ` ACK I�,rT.:MOU; 2.2.4 Nuradve Desa#ftm (IOX) i I Inditm Desaip M (lox) ACK I. 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 Conrlt> *n SPSUk lion ioonNne SUSIUM SYMMS 4. The TOGS 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 TOGS 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 TOGS Endpoint. 9. The ESB routes the message to the appropriate ESB web service endpoint for OSP. 2.25 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. 4 EEW:1 EME incident Description (IDX) Inck*4 Descrlptl1(IDX) IndderK Description (IDX) ACK r r i Incident Description (IDX) i Incident Description (IDX) Incident Descripion (lux) U, ACK r r r r i i 2.26 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 TOGS Endpoint. 5. The ESP routes the message to the appropriate ESB web service endpoint. ODOT-0SP Connedw SWftatlon 11 oni1ne susn�ass srsrasns 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. 23 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 `dosed' to an `active' status, or copied from existing events in TOGS 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. AS02 When an event is opened. or changed to 'pending' or'active status in TOGS, 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 Nqr occur on ,the ESB. ODOT-OSP Connection Spediicakm 12 Onui evwau srznM: ' �M r G.�,..4M F .,14.�. �.i;r¢,*:,f,.✓.'iy rw. :°,.� ;� :1�,.....,.' N 2.3.9 Scenario: TOGS Publishes Event New IncidentEvent (NIE) i New Incident Event (NIE) New Incident Event (NIE) ACKlu --------------------- � f i (0 )Close Incident Event (CIE) : Clow Incident Event (CIE) Close Incident Event (CIE) ; ACK --------------------- f i !Update Incident Event (UIE)i Update Incident Event (UIE) Updab Incident Event (UIE) ACK if --------------------- T --_----- ------ i i 2.3.2 Narrative 1. An event is opened, updated, or dosed 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, TOGS 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. S. The ESB routes the message to the appropriate web service endpoints. 6. The ESB sends the message to OSP. ODOT-OSP Connedim Specification 13 online ,. nrs�NasssrsraMs 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 Scenaiafio: OSP Publishes Event LinTOC$ Endnaiot E1= Naw Incident Evart (ME) , Now Incident Event (NI) , New hleide t Event (NIE) , `I U-- -__ ACK------------ {OR} clan In;*W" Event (CIE) ACK ------------------- (OF� UIx1eN Incident Event (U# @) ACK ------------------- Close Inddant Event (CIE) CIO" Mdd&d Evert (CIE) Updde Inddent Event (UM ; UpdMe Inddant Event (UIt7 2.3.4 Narrative 1. An event is opened, updated, or dosed 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 dosed, 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 TOGS 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, TOGS will send a request for incident details as discussed in the Request Incident Details scenario. 2.4 Synchronia External Events The Synchronize Extemal Events business scenario includes the following unit tasks: 000T-0SP Cmwckm SPWCWM 14 onaarm • 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 Update Incident Event (UIE), Update Incident Event (UIE) , Update Incident Event (UIE) ACK ------------------- jUpdate Incident Event (UIEX Update InddeM Event (UIE) Grant Handolf (GHO) I I, Grant HanbNf (GHO) New Incident Event (NIE)1 1. New Incident Event (NIE) {QF}Close Incident Event (CIE) i Close Incident Event (CIE) ACK '-------------------- (OR) Vne _________________(gR,Vne incidentEvent (MIE)i Merge Incident Event (MIE) ACK i i Update Incident Event (UIE) i Grart Handoff (GHO) ACK ----------------- New Incident Event (NIE) ACK ----------------- Close Inddent Evert (CIE) i Marga Incident Event (MIE) i Narrative 1. A shared event is updated or closed, or two or more shared events are merged Into a single event, in TOGS. ODOT-OSP Connection Specification 15 Orr)I,M p1 IXLS6 SYMMS 2. If the event Is updated, TOGS 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 dosed, TOCS sends a dose 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. S. 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 TOGS Endpoint via web services. 9. The TOGS Endpoint sends the Grant Handoff and the New Incident Event message to TOGS via web services. 2A2 St*nado: OSP Updatn a Shand Eve it ETOCS i Mage InddW Evvt (MIE) i Maps Incident Event (MIE) i Merge Incident EvarM (MIE) U--------ACK-------- (C. } Cion Incid" Evart (CIE) i ACK ------------------- Update Incident Event (L16) ACK --- ---------- 2.4.3 Narra&* Claes InddeM Event (CIE) CIMe Incident Ewd (CIE) Update Inddod Event (LIE) i llpdete Incident Evert (lNE) ODOT-OSP CmIeciion SpWkakon 16 onMe 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. The ESB sends an acknowledgement message to OSP via web services. 4. The ESB sends the message to the TOCS Endpoint via web services. S. 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 dosed In the TOGS 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.&1 Scenario: Receive Event for External Agency ODOT-OSP Connwim SpadkAon 17 onilne ... Wt1/W 6%'rlfuF Requed HW" (RHO) Regwg Handoff (RHO) Raquast Handoff (RHO) i ACK (hark H1 X10 (GHO) r Grant HW Wf (OHO) i Gr" Haedoff (GHO) 2.5.2 Narradve 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. S. 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. S. 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. ib. OSP receives the Grant Handoff Message and processes it according to internal business rules. 2.5.3 Scanuio: Send Everd to an External A9Wq ODOT4W CWrA %M Spedficalim 18 Online wswrss srmw TOCS Endo nt Request Handoff (RHO) - Request Handoff (RMO) i Request Hendon (RHO) ACK Tr---- --- , Grant Handoff (GHO) i Grant Handoff (GHO) Grant Handoff (GHO) J LJ Li ------ ACK --- 2.x.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. S. 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. S. 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 TOGS. 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. 0DOT-08P Connection Speftalbn 19 cynline ; • 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.&1 Scenario: Request AN 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. R•�MM In►am�tlor► (RNAI RtgL" left.."m (Ft R"uat 10mr M (RIN) i Y `rte----------------- . hddWA 0••a"W (IDX) i , Inc" 1 Daa"W ODX) I L In0$n t DaWWM (10X) ACK--- - 2A2 Narrative The TOGS system sends a Request Information (RIN) message to the TOGS 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. S. The ESB web service endpoint sends the message to OSP. 6. OSP receives the web service message. ODOT-0SP Connedion Spsdecs m 20 onlpM WfNNiS fPlnMi i. 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 TOGS 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. 17 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-0SP Connection SWillcatim 21 onitna KUVMS SYSUMS 1= 1: M �Fj 1 Request tr�famstlon (RIA) i ' ____ACK ----- Incklod Dssaip M (IDX) n reVW a endpoint list 2.7.2 NwrOve I. TOGS 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 � Request InlormsMan (RIA) ACK mldm axlpeirR list -Incident Descriplim (IDX) 2.7.4 Nafradve 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-0SP Cm -"w SPt>GftWOn 22 onNn� .. fVfMMff ff4ffMf 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.8A Scenario: TOCS Heartbeat to OSP TOCS I 17�1 i Heartbeat Message i Heartbeat Message i ACK --------------- i i i 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 Conneclim *o kation 23 ,. eonus• us�Mesx swreMs 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. 2M Scenario: OSP Heartbeat to TOGS ACK -------------- Hesrl*M Response Hsxmed Response i 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 TOGS. 4. TOCS receives the Heartbeat message and sends a Heartbeat Response message to the ESB via web services. S. The ESB acknowledges receipt of the Heartbeat Response message by sending an message via web services to TOGS. 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. 28 Requed 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 Comeclim SpedkWon 24 online euarosssrsrars Request HAndoR Massage i Request Hrndoff Mtrsssp ACK -------------- Grant Handoff Message i i i 2.9.2 Narrative S. 9. 10. 11. 12. 13. 14. Grant Handoff Message ACK ----------------- TOCS sends a Request Handoff message to the ESB via web services. The ESB acknowledges receipt of the Request Handoff message by sending a message via web services to TOCS. The ESB routes the message to the ESB web services endpoint for OSP. OSP receives the Request Handoff message and sends a Grant Handoff Response message to the ESB via web services. The ESB acknowledges receipt of the Grant Handoff Response message by sending a message via web services to OSP. The ESB routes the message to the ESB web services endpoint for TOCS 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 ObOT-0SP Connection Specification 25 Online BUSMISS SYSTEMS i i Rfgwft HandoR Mpffpf Requat Handoff Maiefgf i ACK Gnat HandpR Mffffee 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 TOGS. 11. TOGS 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 TOGS. 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. 210 Altemats 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 ESS The endpoint cannot connect to the ESB. ODOT-0SP Caned ion SpsCikAM 26 ongne wwwss:ranrt Connect emal to adminWator , 109 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. Request Message ACK X < , , ACK , Log error condition i emau to adminstratar 2.10.4 Narrative ODOT-0SP Connedion Specikation 27 Online lIASNlSi SYSTQMS 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. S. 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.0 Endpoint does not receive expected 1012 response maeage In this scenario, the endpoint has sent a 1S12 request message to the ESB and Is expecting a 1512 response message. The endpoint does not receive the response message in a timely manner. Request Meseepe i Request MosUye---------------- ' ACK X Operator OpereW Mneepe ACK i Log error cordtim email to �r 2.10.6 Narrative I. 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. S. The Endpoint sends a SOAP Fault to the application regarding the error condition. ODOT-OSP Cmned m Spe icalm 28 online 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-0SP Connechm SWIlicalimn 29 online .��....,....s This message will include a summary Incident Description message and any cross-referenced event data in the form of a pedigree list. 3.1.8 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 Gwent 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 Infornmiion (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 Mage Pattens 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.21 Request A SOAP message that defines a request of some nature and Is Intended to result in one or more responses. 3.22 Response A SOAP message containing response data for a prior request and is sent as a result of a SOAP request. 3.23 Broadcast Message A SOAP message sent independently of any request. 3.2.4 Acknowledgement ODOT-OSP Conneclim SPK*A" 30 online flA{INLfi N'fYyMf A SOAP message sent to acknowledge the acceptance of a prior message. 3.25 Fault A SOAP message sent to communicate a fault or error condition. ODOT-OSP Connection Specification 31 onllne eusu�esssrsra�n 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 Most for Incoming messages from the agencies, as well as a web service client for outgoing messages being sent to an external agency. 4.1 Anuffrftw Aso ODOT TOGS is.a Aet 2.Q application that Isnot continuously available. This refers to the architectureof7OCS that iniplhis'.that' it is .not deployed across redundant hardware to. minimiza downtime. ............... ...... AS08 Web services (HTTP and SOAP) are the preferred endpoint Implementation to integmating with TOGS. AS10 While the initial implementation shall swpport messages.. between. '. ODOT and. OSP, the *" endpoints must support receiving messacies.from other agencies. without.f llure, even if no processing Is done with those messages inthis Initial implementation. AS12 The TOGS systern will provide the TOPS, Endpoint with fully formed 1512;messages. The TOCSS Endpoint should have the ablilty to transform the messwe as needed: such as in the case ODOT-OSP Comm SpKilica lm 32 ;O Mn wsa�ss srsnsn . that the 1.512 specification has been updated I AS14 The NET framework will be utilized In the endpoint I implementations. AS16 The PSSI QIS will e*pose 1tg web service via art endpoink'.VRL. 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. I NFR01 Integration between TOGS, OSP.and others will utilize the PRCC ESB infrastructure I NFR03 No system will have access to functions In the remote "CAD system. I All dataaccess sread-only. NFR05 The TOCS interface to OSP will enable authorized TOGS users read . access to specific OSP incidents. NFR07 The TOCS interface to OSP will enable authorized. TOCS users read, I data access tp.all OSP radio traffic attached to a call or unit. NFR091 Radia traffic will be a text transcript not an audlo recording: 1 NFRI1 -_ Authorized.TOCS users shall be able to select and create TOCS copies of inddents from OSP CAD. ODOT-OSP Connection Specification 33online NFR13 TOCS incidents that are redirected to OSP CADW11 Include all radio I traffic attached to the.etiIncident at thme the incident weer sent NFR15 OSP CAD users shall be able t:o send "(or reopen and redirect) I incidents to ODOT TOGS NFR17 TOCS will provk* geo-based:inddeOt locations. NFR19 The T= system shall support an Incident having multiple related ryl incident numbers. J NFR21 The TOCS system shell Include the TOGS incident number as a , I related frreldent number on all TOCS incident$ coplod to OSP CAD: 11 NFR23 The TOGS conneM9n..to OSP shall includta automatic updates for I shared incidents. NFR25 The:TOCS interface. to OSP.CAD will!suppbaE "Screen to;Screen' messaging functionality between TOCS users and OSP CAD users. 4.3 Technical Re"inna is 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. T'R01 The TOGS Endpoint will be able to recelve external events that have ; been published TR03 Messne,exchanges between..two endpoints will be. asynchronous.: ODOT-OSP CMMd IOn Spedti Mdm 34 online wMwutssY.-S EXIT-' 7T'fTiM IT,7 ZI 7 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 oniin• �uflMtfS LriTiMf co p Aix wfi There is `a dlstinctian' between a tonr►ecbon tlme out:vs. a response .itme out, in' a ConnectioR time out, the Elvdp61nt should attebpt to pend a merge L Mow HTTPs l 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. TOCS The applicetian currently under development at.,ODOT. T%S`and -custom endpoint will bat)i reside on the same pt rslcal server. ESB The Enterprise, Service Bus (ESB) will act as a transport layer, providing servkes such as 'eliable:messaging, message auditing, and,messa9e laggingThe ESB will reside -on its own set of servers: OSP PSS1 CAO The OSP PSSI CAD system will .connect to tate ESP via standard web services. OSP'. PSSi CACI resides within its owh ;server at OSP. 4.5 Communicatim Betww Components The TOCS Endpoint communicates with the TOGS 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. ODOT4W Connwdw Spsdikalim 36onpn• l:NLss MUM 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. is 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: Is The wsdi: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. ODOT-0SP Connection SpedBcafim 37 onnnr MANUA MUMS C''/W SCjl...tn?�5�; • The WSDL Minding specifies a style of document. For example: 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. TR11 WSDL Document. should o 'rreated whenever possible. for all .. . service interfaces usied:between two or more systems:. The WSDL defines the complete. message syntax requirements 443 DIWIbuftS WSDL Me The TOCS Endpoint will expose its WSDL to the TOCS application with the following URL: http: // a production -domain -server> / mWpoW/toco.asnm?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. 444 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 Conmcft *dfi AOM 38 oniin. GU%Wu6 S9fn/df The payload for the SOAP message will be a 1512 XML message, as defined in the ODOT Message Architecture document. U3 A SOAP envelope Is required to support all web service standards and will be defined by a WSDL TRIS All service Interface50AP bodies will use Document styles. Documents are: naturally more process -centric and better suited for SOA TELT ODOT will use SOAP v1.2 defined by the SOAP namesRace `h�tp.://wws�..w�•..org<2043/pS./'snap-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. R1$ A subset of the XML data schema for the IEEE .1..512 (Common Incident Management.Message Sets (IMhti5 1, daft revision 3/3/QS,' wilt be supported TR20 1512.Data Frames and Data Elements,will be used whenever Possible over a local extension. If no 151ZDato Frame or Data Element Is applicable to thedata, then a local extension will be ;:used. TR22 The.`r©CS Endpoint.shall recelve 1512 m: essages 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 TOGS. ODOT-OSP Connedim Specification 39 oniin4 LUfIX6SS fVz. 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.&1 tic Model MW aonaocunrlf�Nmanp:� eM w+s rrNer roe, wM urekA NmlDoelruent �l«nl+n1) : vwd «cw» i I_-_________- sea* 4.6.2 NwrOve alrune�: M.eap.Mrwgrr � _..--- sNIdK:IAiMM11Ct8erld�r - „-_----_J TOC40r w ODOT-OSP Con mdw Spuftadon 40 onHn�l The endpoint class structure is represented by the following classes: OdofEndpobt 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 IEndpointLlstener Interface, which are implementations of web services that accept incoming data. lEncO*d stener 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 axsd: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. IMessage.SWKW 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 handier method which utilizes the native .NET methods for processing errors. 1M"Sapeir8nafoMW 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 TOGS 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. SW This is an abstract class that implements most of the logic required by TocsMessageManager and EsbMessageManager, which are concrete ODOT-0SP Connection Speak4w 41 online eusneus smells 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. T 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. 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. Measagsiiackar 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 TOGS 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 sdeslred 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.&3 Sequence: TOGS connect to eindpolnfs WS and posts a ine"s This diagram defines a sequence of events happening when TOGS 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 decoupies the sending and receiving of messages so that the processing of received messages is not reliant on the processing of sent messages. ODQT-0SP Cmxiec5on Sped COM 41 oniln• SN"I s MUM Tee�ll_Iefener I 1 1 1 1 I TOCS calls Ws ----------------- ruquwueTocsMsssape EnqumwMassaps Adds rww menapA to A Wmm 4.6.4 Narrative 1. TOCS posts a message to the Endpoint via the Endpoint's web service, TocsUstener, which is an implementation of the IEndpointUstener interface. 2. The TocsUstener 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: TOCS 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 Spedficafion 43 on�fnM 0 Som b i dW aloes 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. S. 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 pos% a message for TOCS This diagram defines a sequence of events that happen when the ESB sends a message to TOGS via the Endpoint. ODOT-OSP Conno*n Spwftd m 44 online BbMessaaeMauW ESO COS WS � EnqueueEsbM9uape , Adds naw meeeeps to a queue 4.8.8 Narrative 1. The ESB posts a message to the Endpoint via the Endpoint's web service, EsbUstener, which Is an Implementation of the IEndpointUstener interface. 2. The EsbUstener 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.8.9 Sequence: ESB messages processing by EsbMessegeManager This diagram defines a sequence of events that happen when a message appears in the internal processing queue of EsbMessageManager. ODOT-OSP Connection Spec &abm 45 C-onilne aWHIM sn"Ms --, wdn up a mnaapa k m a gLwm vaexw MMOMpa sand Bono" rns�epa adc I updOm data dwo Sold b TOCS 4.6.10 Narrative I. EsbMessageManager picks up a message from the internal queue. 2. EsbMessagManager calls the Messa"Tracker 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. S. The IMessageSender sends the message to TOCS. 4.6.11 Sequeww M"mSeTrseker IMWIbalbn Process This diagram describes the MessageTracker Initialization process. The MessageTracker is Initialized when the Endpoint Is 19rst started and In the case when the Endpoint has gone down for whatever reason. The MessageTracker Is a singleton class. ODOT-W Cannedw Speallulim 46 Onlin; eusutllS;YfiiMf Got saved acts � Saved acks -------------- Remove --- -Remove Omedout asks from the HO 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. t t t t t Stop monitoring i i i i Clear scow list i Clear data store 4.6.14 Narrative ODOT-OSP Connection Specification 47 onttoe BUSiXlSS SYST-9. 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.8.18 Sequence: No ACK received within specined timeout This diagram describes the process the MessageTracker goes through when one or messages are considered overdue. Gd *Md OW MM F" OnTIMOMA Owd N i i i HOWWA&TWfAKMA Said em mMspn F'A-111 111** 4.8.18 N9uradve 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.8.17 Message RequeWltespanse 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-0SP Cwd*cdm SPWWAIM 48 0" mss amu. 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 oanf9gurable 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. Ae+dIt Swrvke The Audit Service receives the message and logs it to a file and then sends the message onto the web service endpoint. ftb Swvko En*oW 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. Cwmnt En*ob* 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 Gat Endpohft Service Interlue 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 P705U for instructions on how to add the rile to the SonIeFS. XML Daft omw The following is an- example of the endpoints list: ODOf-OSP Cwned ion SpedfiCalim 50 onu;w wsMus srsraws Get Endpoints Rew mt mmage The Get Endpoints Request message is the Request Information message from the IEEE -1512 specification with a local extension called GetUstOfEndpoints. Please refer to the Message Architecture document for specifics. Get Endpolnts 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 ESS 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. . 1�tted: French _•.•._...1 %axance? Vo4. French e ... *oswr�ttrtd: French [Franc 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, T005 Endpoint Operatbns Manual,..for._more. information on..._config.uring„the. - cw�rit tom] : This is PDCC ESB just , assumptbrt of the name of the P7650: 4.9 Logging Logging Is fine-grained historical and analytical Information primary for debugging and problem solving. Description WOT-OSP Connection Speftadon 51 oniinr Yl1SiNlSf fYfllMf The TOGS. Endpoint shall log, message, exdianges. 1 TR25 Lagging. will. be persisted to, the standard Bogging tables defined by the Mkxosoft:Errterprise Library TR27 Logging , e message content will always occur with a logging I f level, eq*#ier to WARNING or FAIL.. to 4.9A TOGS EndpoW L099MO 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 read 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. lu$mn MUMS • 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 P70SU document for details on how to configure all aspects of logging on the TOCS Endpoint. 4.9.2 ESS 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 P70SU for details on how to configure the PDCC ESB Audit service. 4.9.3 No#katlon & 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. ODOT-OSP Conneclim Specikalbn 53 online Bus"IM SYSTAMS 4.10 Security 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.1 System AuthenScation 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 Authendeaitlon No user authentication and authorization service is necessary between ODOT and OSP. Authentication is handled at the protocol level with SSL. 4.10.4 Certifk" 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 Caviectim SpedflCadpn 54 onYnr suswess srsnNs A certificate authority such as Verisign can be used to request a certificate. For OBS to use It, it should be In pkcs12 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 MOT and OSP side, a message can travel from the message producer to the message consumer securely. ODOT-OSP CMneCbM SIMkadM 55 online tvs�nest trtrews 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. Fri=:Y 11=AiJ" 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 Developer nt standards 5.11 Coding Standards All code written will conform to the IDesigns CS Coding Standards Guide and the TOCS Design a" Construction AuldallnOS Draft document, both under separate cover. Where there are conflicts in standards between the two documents, the TOGS Design and Construction Guidelines Draft document will take precedence. 8.22 Unit Tilting 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 Cwnecliw S*ftafim 560;n • All test methods will specify the expected behavior that they are testing. The naming convention will be Shoul dExpected6ehavior. • All constructor dependencies should be Interfaces 5.3 Development Tools The Developer will utilize the following tools and software: Note: This document will be updated as software versions change. ODOT-OSP Cmneclm SpKiACNbn 57 onllnn sut�cs srsnMs TECHNICAL ENVIRONMENT 6.1 Applkallon Sarver 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 Phys" Conflgwradon The physical environment stack for testing and production Is shown in these diagrams: Ted Enyb murt 0—,� U t 0, U""� O/F FInrY ON OM /.nvr O//F//I CAD 9-/-hM Torlt YMIMIwi.e.N111/W Udr1..Mlry if Bair 6+apdr. 198rY.wtl 167.191.M/kK0/ /CrCC W" pal etrndad 94*4 on 167.131A4.11:1M ART PWW"/A/ 1/7.1/1.Y1./1 Ia.191.M.12tl40 TOCK T.rf "r aM SrEft 167.131AAIMM Usw ACCSPW a/ EnWmmwa I Production 14, 0, &� %6 . tArrvabr./en//.W.TO� VANI�mo.ts1 U-C.N1111Tw f9 /aJe iwMpw /aMIwM NMMrN7VM Tadll. MN /r [i &" NVFr.rwrk&e Q1ft*i Ap) 11" 13"IABN 167.191.71.11 Z131./A.17.M TOC/T.d"r 167.191."1&& 0/ aN EW FM Few 6.3 Network IN 0—,� U t 0, U""� O/F FInrY ON OM /.nvr O//F//I CAD /CrCC W" pal Both Endpoints will be deployed within the OOT WAN. The primary location will be the C-4 building. 6.4 Operating Standards and Procedures ODOT-08P COnnedm SPSAMM 58online wnMOUPMW t 0, U""� O/F FF.adl 0/F 0169.r.r WP I//1 CAO pOCC wiw/ rat Both Endpoints will be deployed within the OOT WAN. The primary location will be the C-4 building. 6.4 Operating Standards and Procedures ODOT-08P COnnedm SPSAMM 58online wnMOUPMW The User Acceptance and Production environments will be managed by MOT Tech Management. Online will deliver installation scripts and instructions. ODOT-OSP Connection Specification 59 onun. 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 AS01 While lt..is expected that integration ,with other agencies WHO pperr in the suture, :the first agency ODUT is integrating with Is DSP. The. ODOT to OSP;integration is the only integration in scope for this project. AS03 When an event is opened or changed In PSSY CAD.; the event 1s sent to the ESB AS05 ODOT and OSP will have an agreement of what constitutes,.a changed event, A$07 " LEDS Data will not be sent:in messages. All confidential data must stay confidential and it Is the..responsibiiity of the endpoint systems, TOCS and PSSI CAD, 0 keep that. data confidential. AS09 The solution shall utilize the Portland Dispatch Center. Consortium (PDCC) Enterprise Service Bus (ESB) for message routino'and delivery. ODOT-OSP CancUon SPKMcadm 60 bnanM wurrss srsraw as.: eve ent A511 ;All transformation, between.endpoint-specific co es, suc type or call type, and 1512-specil9c.codes will take place within the custom endpoint implementation AS13 A staging database F set up:by PSS.. CAD; will be used as an Intermediary between the endpoint and the PSSI CAD system. An `Inbox'table and "outbox' will be used. The endpoint will ;place received messages in the inbox table for PSSI CAS, and read the outbox table':to send messages to the ESB. ': ASIS The TOGS application will expose its web service'uia an endpoint URL. AS17 'The TOGS Endpoint will expose its web service to TOGS via an endpoint URL 7.2 Decision Points DPP03 What is the message structure 'for location, of .incidents? EPOS Will a new less chatty incident description (IDX) Message be,:used? y xt as v rF yyrYr+ N` OR 7.3 Business Requirements ReqUirement Description NFRo1 , Integration between TOGS, OSP and others will utilize the PDCC ODOT-OSP Connection Spec katbn 61 online MMINMF6 SYMllMS ESB ;infraSCructure. NFRO3 No system wilt have access to functions, in tie remote CAD System. I All data access is read-only. NFROS The TOCS Interface to OSP will enable authorized T005 users read access to specific OSP incidents. NFR07 The TOCS Interface to OSP will enable authorized TOCS users. read data access to all OSP radio traffic attached to a call or unit. NFR09°^ V Radlctrafflc will be a;tei�t:transcript nok an audio recording. NFR11 Authorized TOGS users shall. be able to select and create TOCS capias of Incidents from OSP CAD, NFR13 TOGS incidents that ,are redirected to OSP CAD will induda all radio, traffic attached to the Incident at the time the Incident 1wassent. NFR15 `OSP;:CAD users.`sholl,tw able to send (or reopen. and redirect) Incidents to :ODOT TOCS NFR17 TOCS will provide goo -based. Incident locations. For Incidents that are copied (or reopened and redirected) ftom OSP CAO. TOCS will make all OSP <radip traffic attached to that incident "read only" within the TOCS system. NFR19 The.TOCS system sh-alt support an incident having multiples related. incident numbers. OOOT-OSP Cone ipn SpGdit W 62 onlirw wurffs friY/Mf 7.4 Technical Requirements T1101 The TOCS Endpoint will be able to receive external events that have been published. TR0.3 Message exchanges between to synchronous. TROS Messages sent throw the TOCS Endpoint will only,be sent,one tlrne. Once the message reaches the PDCC ESB, messages may be cached to guarantee delivery In case the ESB goes`down. TR07 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 responsibillty of the CAD operator to snake additional attempts, TR09 The time out period shall be configurable. T1t1:1 WSDL Documents.should be.created;whenever possible for. all service Interfaces used: between,two;or more systems. The WSDL definesthe complete message syntax requirements' ODOT-0SP Connection Sped lication 63 dnnna CUSOM SYMIAS TR13 A SOAP envelope Is aqui fed. to support all web service standards I and will. be defined by,a WSOL . TR15 All service Interface SOAP bodies. will use Document styles; Documents are naturally more pmcess-centric and better suited tar SOA TR17 ODOT will use SOAP vl 2 defined by the SOAP namespace. http /Jarww.w3.org/2003/•Q5/soap-envelgpe TR19 All 1552 messages shall be accepted by an i?ndpoint Agent, without 1 error, regardless of whether the.message itself Is processed. TR21 It a 1512 message request :has a .specifi.c..151.2 message response, It should be;usW for tare response. TR23 The TOCS Endpoint shall log rnessage,poianges. = I TR25 Logging will lige persisted to the standard logging tables defined by, I the Microsoft Enterprise Library. TR27 Logging of the message content will always occur with a loggin level equivalent to WARNING or FAIL. OOO7-OSP Cann CNM Specilia" 64 onlin.m ws�ssa�.0 TR29 The Logging tables will be deployed to the date store used by the; TOGS application. TR3,1 The Microsoft. Enterprise Library configuration tool will be used to. configure email notification. Configuration of emali includes specifying the SMTP server and the email address to which notiftcations will be sent., T'R33. .. An: email .notificationshall. be.sent when a:`system acknowledgement. is .not recelved.from.tthe ESB. A`system acknowledgement Is provided each time the Endpoint sends a message, to the,,ESB. OQOT-OSP Connection SPKftatlon 65 onlin. Nlfllllff fY4TlMf TERMINOLOGY The following is a list of the commonly used abbreviations, acronyms and their respective definitions Architecture 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:`P14711D5.3) BPM Businass Process. Modeling is a method to.`model ;or configure new ,". business functionality Composition Turning fine-grained atomic services into qursewgrained business services . Coupling The level of common knowledge necessary in adistributed comoutina exchange Loose. Coupling. + -A desired feature of services this allows two services.to interact without being aware of one another and that changing one service does ",break the other service ODOT-OSP Connection SpedACeINDn 66online MlSWESSOMMf ODOT-0SP Connection Spedcaibn 67 onlinr lUR91!!!l191IM! APPENDIX A: ODOT TO OSP SECURITY IMPLEMENTATION The appendix discusses the steps necessary to setup SSL on the TOGS Endpoint server. i.0 Set Up UL on a Web Server Applies tars Internet Information Services (IIS) 5.0, 5.1, and 6.0 Microsoft® Windows 2000 Server'" and Windows Server 2009 Sumnwaryr A Web server must be configured for SSL In order to support https connections from client applications. This Wow To shows you how to configure SSL on a Web Server Secure Sockets Layer (SSL) Is a set of cryptographic technologies that provides authentication, confidentiailty, 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 GrtMwrM 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 valklated certificate. To aemrera- • cortlilknes request 1. Start the 11S 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-cilck the Web site, and then click prepertles. 4. Click the 11111160H Snurity tab. S. Click the Serum CertMrste button within Seeure coo mhunleatk"M to launch the Web Server Certificate Wizard. MOT -OSP ConnKlion SpeeftWon 68 OnNne tusrwss •r�tiFW Nato If Sarver Certificate Is unavailable, you probably selected a virtual directory, directory, or file. Go back to Step 2 and select a Web site. 6. Glick Next to move past the welcome dialog box. 7. Click Cream a Now Certificate, and then click Next. S. 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. Mer on In the request process, you are given the opportunity to select an authority from a list to send the request to. 9. Click Prepero 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 flit hrngth 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 Organisation field and type an organizational unit (such as Sales Department) In the OrgaMsadenal unk field, and then click Next. Nob 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 Net9IOS or DNS name of the computer. 13. Enter the appropriate information In the Country/Region, Stab/province, and City/locality fields, an4 then click Next. 14. Enter a file name for the certificate request. ODOT-OSP Connection SpedficOm 69 on" wsnussfrsnMs The file contains Information similar to the following. --- 3EGIN NEW. CERTIFICATE :REQUEST---__.: MII•DZjCCAs8CAQAwgYoxNjAGBgNVBAMTLWIpenJ�Y2tsXXBOb3Aubm9ydGhhlDVVVJL END :NEW CERTIFICATE REQUEST... -_W_ This is a fuse 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 foe 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. Ater 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. is. ack Mout The wizard dupiays a summary of the information contained In the ceftificate request. 16. Cock now. and then click rkdek 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 11S Certificate Wizard. 3.0 sumirw a cordsme Nt6gaaad This procedure uses Microsoft Certificate Services to submit the certificate request generated In the previous procedure. To autlaett a artiAeato requeet 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 navlgste to http:// hostneme/CertSrv, where hostname is the name of the computer running Microsoft CerbflcMm Services. 3. Click Requoat a Cerallic elo, and then click Next. 4. On the C wa Requ" Typo page, click Advonced re*wgk, and then click Noxi. S. On the Adv wmf CwW1cW a Re*m is page, click Subm t a cortift4e roquoat wlnp a boa m*4 armaoda I P%t$ 10 tIM, and then dick next. ODOT-O$P Corradw SpeCi Sft 70 onNne ssrmws 6. On the Submit a Saved Request page, click in the Bare64 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. dick Submit. 9. Close Internet Explorer. 4.0 Issue the Certificate To Issue the certificate 1. Start the Certification Authority tool from the Administrative Toob 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 dick Issue. S. 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 FIN, 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 CertMcate on the Web Server This procedure Installs the certificate issued in the previous procedure on the Web server. To Install the certHicate 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 -dick the Web site, and then dick Properties. 4. Click the Directory Security tab. S. 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. B. Examine the certificate overview, click Next, and then click Finish. MOT -MP Calmeclim Spekificallm 71 <0 Imams online A certificate Is now Installed on the Web server. 6.0 CorMOure Resources to Require SOL ACtese This procedure uses Internet Services Manager to configure a virtual directory to requke 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 cortApwe ressurces to require SSL access 1. Start Internet Informatlon Services, if ICs not already running. 2. Expand your server name and Web site. (This must be a Web site that has an installed certificate.) 3. Right -dick a virtual directory, and then dick Properties. 4. Click the airettoy Secur" tab. 5. Under Seewe commisolicathum, dick ML 6. Click RegWre eeewe filer" (SOL). talent's browsing to this virtual directory must now use H1TPS. 7. Click OK, and then dick OK again to dose the prepertles dialog box. 8. Gose Internet information Services. 7.0 CWW*Ae the Web Sww" YirtwM Wrubivy to M*afe SSL Your Web service runs on Internet Information Services (IIS) and relies on IIS to provide SSL support. To uee IIS to ow1w ome row Web tterviee'e vlet" d o ec"ry for SSL 1. On the Web service host computer, start IIS. 2. Navigate to the -cVftM ereleea virtual directory. 3. Right -click -cW@b@ mAeea, and then dick prepertiw. 4. Click the dlreceery Oecniit-, tab. 5. Under Secure , dick ROL If Rolle is unavailable, It Is likely that a Web server certificate is not In"Ied. 6. Select the Regtdre eeawe chancel (SOL) check box. 7. Click OK, and then OK again. ODOT-OSP Cmmdoe Sped "ft 72 oalim a. In the Inherkance Overrides dialog box, click Select All, and then dick OK to dose the <Web$orvkaa 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 c&N the Web service using SSL from Internet Explorer 1. Start Internet Explorer on the client computer and browse (using H1TPS) to the Web service. For example: 2. htt:ps //Webserver/[Virtu&iDireatory>/<Web$erv">.ssmx 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 Securky Alen dialog box, as Illustrated in Figure 1, Is displayed, click View CertYicata 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." P2 Close Internet Explorer. Figwre 1. Security Alert dlalog box =T -OSP Connection Spedkatbn 73 onlinr MAINUS SIMMS 9.0 Inman the cerwafte Arby's Cert ftilis an the CN&A Caanpubw 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 Seeurlty Alert dialog box. It raw we Mlcreselt Cert llik* w lervicwa me a CA vdtMM Vow NNndews dentein 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 S. 1. Start Internet Explorer and browse to http:// hostnarne/certsm, where hostnsme Is the name of the computer where Microsoft Certificate Services that issued the server certificate Is located. 2. Click het►feve d w CA crrtliflefte or cerdilkaft revocation NO, and then click Neon. 3. Click UNUM thM CA cortiNggon poh. 4. In the Meet Cortillnb Store dialog box, dick Yoe. 5. Browse to Web service using HTTPS. For example: 6. httpss//NebServer/cWktimWD6m%l"s / Y#gb$ervleoa.aamx 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, dick Download CA eall(Icab, 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 SUM and then click Vim. 10. Type rnr4e, and then dick OK. 11. On the C vele menu, dick Add/Itenwvo Snep4n. 12. Click Add. 13. Select CertiAciNee, and then dick Add. 14. Select Centpeter am*unt, and then dict Next. 15. Select L"at Cernpwten (the ownputer the censele is rurally* o4), and then dick :1400. 16. Click CMlse, and then OK. ODOT-OSP Connexion Speftafim 74 Onllna Witplff fY114M{ 17. Expand CwUf crates (Local Computer) in the left pane of the MMC snap -In. 18. Expand Trusted Root Certification Authorities. 19. Right -click Certfflcatm, point to AN Tasks, and then dick Import. 20. Click Next to move past tate Welcome dialog box of the Certificate Import Wizard. 21. Enter the path and filename of the CA's .cer file. 22. Click Next 23. Select place all certiFlgtss in the following store, and then pick grows*. 24. Select Show physical storm. 25. Expand Trusted Root Certification Authorities within the list, and then select Local Computer. 26. Click OK, dick Next, and then dick Finish. 27. Click OK to close the confirmation message box. 28. Refresh the view of the Certhlestm folder within the MMC snap -in and confirm that the CA's certificate Is listed. 29. Close the MMC snap -In. ODOT-OSP Connection 5pedkafion 75 t7niln� WSiMESS SYSTEMS APPENDIX B: ENTERPRISE LOGGING LIBRARY 10.1 Inhvdution The following is the text of an article on the Microsoft Enterprise Ubrary. 10.2 Overview The patterns s 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 Ubrary-January 2006 contains the following general purpose application blocks: • CacMne AppNsatkan skack. With this application block, developers can Incorporate a local cache In their applications. • Crypiloprophy AppNeation Mock. With this application block, developers can incorporate hashing and symmetric encryption in their applications. • ApoirAtim Almk. With this application block, developers can incorporate standard database functionality In their applications. • Exception liandNng Appillieation 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. • Lemke AppNcatilon lllock. With this application block, developers can Include standard logging functionality In their applications. • Security Applicatlon slick. With this application block, developers can Incorporate authorization and security caching functionality in their applications. Enterprise Ubrary also includes a set of core functions, including configuration, Instrumentation, and object builder services. These functions are used by all other application blocks." The Snt6erprlee L,ibfsiry 2.0 L.oggins AppNc tion sock makes logging various application events in your winform and web applications a snap. Before we dig into implementation specifics of the Lodi Application slack, we first need to understand the Importance and role of Tracolobdenem. ODOT-OSP CWnP%M SpedlkWM 75 onlim 10.3 1'raceUsteners The heart of the Enterprise Library 2.0 Logging Applkattion 1310dt is its TraceLlsteners, which are essentially the conduit for which event messages get to their Intended destinations. Enterprise Ubrary 2, provides the following TraceLlsteners: • Database TraceUstener • 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 Ubrary 2.0 TraceUsteners derive from the base TraceListener Class that is a part of the .NET 2.0 Framework. 10.4 Original Method The TraceLlsteners In the Logging Application Block work similar to the TraceLlsteners in the .NET 2.0 Framework. If we use the Fish File TracsUstener as an example, its use is not much different than the TraceListener Class it derives from - the TextWritenTraceLlstener Class in System.Diagnostles. One can use the TextWriterTrucaUstener Class to output trace information to a text file with some really simple code: // Create a .log file Stream logFile = File.Create("Traceotttput.log"); // Create the TextWriterTraceL.istene.-r TextWritexTraceListener .listener = new TextWriterTraceListener(logFile); // Add the listener to the list of Trace'Listeners Trace.Listeners.Add(listener); // Output the message Trace.Write("My log message"); // Flush the output. Trace.Flush(); The code above programmatically adds a new TextWriterrragUstener to the Trace Class' Listener Collection which means that any messages sent via ODOT-OSP Connection *dlicalian 77 online euxxicxa mens Trace.Wrlte or Trace.WriteUne will now also be logged to our log Nle, Tra*O%dPuLW9. However, nobody is going to write such code, because your aMcoMtp or web.=ntiv class allows you to delle Trach stoners in it without touching a bit of code. This allows you to add and remove Traceusteners 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•"LogFileListener" type-"System.Diagnostics.TextWriterTraceListeaer" initlalizeData-"Traceoutput.log" /> </listeners> </trace> </system.diagnostics> </configuration> In the configuration snippet above, we have essentially defined a new Traceustener► L*gFN*Lk ~, that outputs trace messages to our same log file, TracefttpuLW9. 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("M,y log message"); // Flush the output. Trace.Flush O ; 10.5 Enterprise Ubrary ApOkWon Socks 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 SpeAcOm 78 onRn; 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. EnterpriseUbrary.Common.dll + Add reference to Microsoft. Practices. Ent erpnseLibrary. ExceptionHandiirig. dll • Add reference to Mkrosoft. Practices. EnterpriseUbrary. 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 Namespaces"Microsoft.Practices.EnterpriseLibrary.Logging" <script runat-"se.rver."> void Application_Error(object sender, Ev'entArgs e) { HandleException(e.Exception, "Unhandled Policy"); </script> Enter the following code into the Global.asax: public static void HandleException(Exception ex, string policy) { Boolean rethrow - false; try { OUOT-OSP Ca>nection Specification 79 onlin* policy); Rethrow = ExceptionPolicy.HandleException(ex, ) catch (Exception innerEx) { Throw ex; if (rethrow) { Throw ex; Once I create the web Service in Visual Studio 2005, I immediately open up the Enterprise Library Configuratiao TQgl and use it to open the existing web.confip 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 FlatRie TraceListe ne that catches all events. The LaWnp Application Block has a Special Somm, called AN Ewnts. 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 FlaWle TraceListener, which points to a log file at the root of my website, called tramkp ( default name ). ODOT-MP CMWJ(n 3pKftadon 80 onMn� rus�ss arsnu Fi4wo is f"wprbo Library amftw um Tool ODOT-0SP Connan Sgec atbn 81 cMil WSiKns SYMMS 11.1 Purpose Q 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 ESS 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-0SP 0" Specilkadon 82 oniin* W V Z W w W W W WE U) 0) 0 oc Q Y. w - a z M Z a W V a oc W k W I -- W 2 ImA v ch W � g W W �c r/C Y1 a fV r+ 0 N `R Ln �o g a O Ln to z20 p W v te(, atj ua r�H �' IV 7 y�N�' on $ N 7 Q = �x a .r ImA v ch �c r/C Y1 a fV 0 C ------------ ,u n E fir. 1 W�,4, Jy� tu t (10 g N all h N • . v. AD Vl i� 111YYYyyy���111 i101 �Ste F � (/� 7 m � w � ` ar • A /�' 4c r J! 1 ro 0' q ~ 10, V to 1A t? ww W ltd. t,. t iyeyyy � 8 to - IE N r„ to RN R a�w a SCHEDULE E FY 2008 Homeland Security Grant Program Application Instructions and Grant Guidance Dcschutes_County_9-I-1_Contract Mpr10 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-5082 Location address: 3225 State Street Salem, OR 97301 Application Due Date: 5:00 PM, Thursday, July 31, 204$ 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 FundingDistribution.......................................................................................................... .5 Durationof Funding................................................................................................................5 Eligibility...................................................................................................................................5 TrainingRequirements............................................................................................................6 ExerciseRequirements...........................................................................................................6 MatchRequirement.................................................................................................................8 Supplanting.................................................................................................... ...........8 ApplicationDue Date...............................................................................................................5 ApplicationEvaluation............................................................................................................9 State Homeland Security Program(SHSP)...........................................................................10 Planning............................................................................................................................10 Training.............................................................................................................................12 Exercise..................................................................................................... Equipment.........................................................................................................................14 Personnel..........................................................................................................................14 Management and Administration....................................................................................15 Law Enforcement Terrorism Prevention -Oriented Activities.............................................16 Organizational...................................................................................................................16 Planning............................................................................................................................16 Training.............................................................................................................................17 Exercise.............................................................................................................. Equipment.........................................................................................................................18 Personnel..........................................................................................................................18 Management and Administration....................................................................................18 CitizenCorps Program..........................................................................................................19 Planning............................................................................................................................19 Organizational..................................................................................................................20 Training.............................................................................................................................21 Exercise............................................................................................................ Equipment.........................................................................................................................22 Personnel..........................................................................................................................23 Management and Administration....................................................................................23 ApplicationOverview............................................................................................................24 Prioritiesfor Funding............................................................................................................24 ApplicationContents.............................................................................................................25 Part1: Cover Sheet..........................................................................................................25 Part2: NiMS Compliance Form.......................................................................................26 Part 3: Project Justification Form...................................................................................26 Part4: Budget...................................................................................................................30 Part5: Appendices...........................................................................................................30 Part 6: Regional Project — Base Contribution Form.......................................................30 UnallowableCosts.................................................................................................................31 Suspension or Termination of Funding...............................................................................31 Reporting and Reimbursements..........................................................................................32 FederalConditions................................................................................................................33 ProcurementStandards..........................•.............................................................................37 Satre Funding Distribution Table..........................................................................................38 SampleBudget........................................................................................................................39 Overviewof Allowable Costs................................................................................................40 Planning............................................................................................................................41 Organizational..................................................................................................................41 Equipment.........................................................................................................................42 Training.............................................................................................................................43 Exerciso............................................................................................................................43 Management and Administrative (M&A) .........................................................................44 Unauthorized Program Expenditures..................................................................................44 FY 2008 Homeland Securlt 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 Secu Granttnram 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 loyal 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 pubic, 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 Itrnerpency went 2 FY 3008 Homeland Security Grant Proram A Ilcatlon 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 2008 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: httpJ/www. Tema. goy/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 lnlcoll@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: http.11www.ojp.usdoj.goy/odp/assessments/hspd8.htm. Oregon Emergency Management 3 FY 2008 Homeland Secuft grant ftsram Aeelicallon National Response Framework (NRF) The Nat/octal 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.1 www.fema.gov/emergency/nrf/. 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 (Cl/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: http.lAbvww.dhs.gov/xprevprotlprogramsleditoria/ 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: • $882,900,000 for State Homeland Security Program (SHSP) grants. • $781,800,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 Ml anegewwd 4 FY 2008 Homeland Securky 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 8 FY 2008 Homeland SecuEU Grant Pmjram AMU 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 publicielected 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 -III 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.11hseep.dhs.gov. • NIMS compliant. More information is available online at the NIMS Integration Center (NIC) Incident Management Systems Division http.lAvww.Tema.gov/emergencylnimsrindex.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. drpon W.maWWeoy mans""WA 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 Mufti -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, www.LLIS.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 !!Lurh Grant P ram 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 2005. 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 Nand -Delivery Addresses Oregon Emergency Management Phone 503.378-2911 U§ Mail UEUMMMaW QgILUred P.O. Box 14370 Salem, OR 97309-5062 3225 State St., Room 113 Salem, OR 97301 or"W 8maarncyy A�reaaenarM T s FY 2008 Homeland Secu 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 2009 Honwland Secwlty Grant 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 pian 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. PlannMg 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:l www.fema.gov/pdflgovernment/grenVhsgp/fy08 hsgp allowplanning.pdf. Arson arc► Marnew"m 14 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 rernediation/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 71 FY 2408 Homeland Secu Grant PTom AE211cation 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-govemmental 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 dewfop, dW wr, and evaluate training, including costs related to administering the training, planning, scheduling, facilities, materials and supplies, reproduction of materials, and training specific equipment. Owrdme and Backf it 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 govemment 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. Trawl 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. Hirings of Felt or PAr&T/nie Staff or ComtractwWConsuftnts to support Wining -related activities. Payment of salaries and frim 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. Onvon anwoemy 11 - U FY 2008 Homeland Security Grant Program Application Ceriificadon/Recer0cation 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 ti. Exercise Exercise Related Costs Funds used to design, develop, conduct and evaluate an exercise. Includescosts 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 Secu Grant ram AEglicatlon 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 Rages 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.rkb.mipt.org. Pel' OM61 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 20108 HSGP (i.e., planning, training program management, exercise program management, etc). orapan enoy N WGIGMmtt 14 FY 2008 Homeland Security Grant Program Ap llcation 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 S"uft Grant ETgrarn AE20cation Law Enforcement Terrorism Prevention-)riented 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 QED) 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. • Overtire 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 ©HS 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/hsgpffy08 hsgp allowplanning.pdf. O neon Emergency Managomm 14 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 En orgency Management 17 FY 2008 Homeland Secu 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 agriculturaftod 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 exemlse taquimmsnts are llstad 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 RKS web page https.1Avww.rkb.us1. 171,171 7. See SHSP Personnel section (page 14). Management and Administration (M&A) See SHSP M&A section (page 15). or"On SMOMOMY Man4own" 1s FY 2008 Homeland Security Grant Pro Oram 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, www.citizencorps.gov, 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 ame►aency Management 19 FY 2008 Hon Wnd Secuft Gmnt fturam A Ikation Public educatfoWoutroach 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.lAvww.citizencorps.gov/pdf/logc guide.pdf. Cittzon pardelpedon - Volunteer programs and disaster rosponse 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 (YIPS), 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. Organizagonal Organization activities supported with CCP funding are limited to the development and support of citizen surge capacity response deployments. onvon 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, light 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 speck 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, credentialsibadges, identifying clothing. Oregon Emergency Management 21 FY 2008 Homeland Security Grant Prouram Aogllcation 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 tabletop 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 exorcise requirements aro lisW 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 bum 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: www.rkb.mipt.org. ©non Emargoncy Marmosment 22 FY 2008 Homeland Socu Grant PTgram 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 Secuft Grant Program Appllcaftn 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, tum out gear for fire). • Equipment not supported or well documented in the Project Justification. Oregon Emergency Mwwgon*M 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/DEM/index. shtmL Part 1 — Required: Cover Sheet(s) for the county submitting agency and A&0 agency that will 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 &aQb additional agency that will directly receive funds. Oregon Emergency Management 25 directly receive funds. Part Z — Required: NIMS compliance form(s) from 1Uh agen 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.l 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 &aQb additional agency that will directly receive funds. Oregon Emergency Management 25 FY 3008 Homeland Security Gant 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. f'ub 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. big more than four REQiWA Mgy be submitted per couWyJOtgigOal gr . 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 = description that best suits this project Oregor 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 lilftarlly 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 g it mare 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: hffp,(/www.Maon.aov/OMD/QEM/ IanI traajag=t,lnfo.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 A kation Question 6: Clearly Identify how this project Is supported by the current countywkkdregional 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 MUM clearly identify that they have a written and promulgated communication strategy and plan. Jurisdictions without a written and promulgated plan will RW 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 it 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. ©►uout-- 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. Orrpon 8narpa�ey Abnaeeeneet 26 FY 2008 Homeland Securit 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. N 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. Umit 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 En gency Management 29 FY 2008 Homeland Seco 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.rkb.mipt.org. For equipment costs include: • The equipment category (PPE, Interoperable Communications, CBRNE Logistical Support, etc.). • The s 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 21GN4WTRNG. 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 organizaftnal, 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 3: 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 E. mm int 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 Emeryeney Management 31 FY 20019 Homeland Sec Grant P ram ApplkAftn Reporting and Reimbursements Biannual Strategy Implementation Reports (BSIRW"gress 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 far equipment purchased and/or services performed during the grant period. Payments will be withheld if any BSIR is outstanding. Reporting Duo 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. Oregon EMMSOnalr UWUgennWd 32 FY 2008 Homeland Security Grant Program Apelication 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 http://Usinfo. state. gov/usa/infousa/laws/majorlaw/civilr19.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.cfm7FuseAction=Content&ID=15. • 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. usdoj. gov/crdcor/coord/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 Vl, 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 Securitv Chant Program Application providing meaningful access for LEP individuals are considered allowable program costs. For additional information, see http://www.lep.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 http://www. Tema. gov/oer/reference% 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 DisabAities 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 http://www.LLlS.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 Ir►formation 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 InfomYiation Act (FOIA), 5. U.S.C. §352, 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 fail 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 rebase of Oregon Y 1111 0 i 1014 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 goveming 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 USC13212). 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 AlMlIcation 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 FEIMA'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 191il-AgUrcein excess Qf SIQ0,0Q 'e r e 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 3008 Homeland Security Grant to.22m A cation 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 S: • 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 anwgo y Management 38 SHSP Distribution by Population, County Base, & Region Distribution bf Region R 1 1 Total FYOS 40% County Dist. Award 284x"1351 & Census 2000 $ U.Z.-.7 Polk Coun !y 0 $983,700 - Region 5 $ 26903 Geographic Total population Total FY08 60% Population Dist. Award area Ore qMOL 3,421.399 $1,475,565 Tillamook Coun % of Population I County Base 37,789 �".24,262 County Population Population Base Award 0.72% Award 10,579 Total Baker Coum 16,741 0.49% $ 71220 $ 27,325 $ 34,546 7 23,791 700 "1 g4w Clackamas County 338,391 9.89% $ 145,940 $ 27,325 $ 173,265 =CoUtt................ tip= 2:19'390 Wheeler Coun Columbia County 43,560 1.27% 667 18,786 $ 27,325 $ 46,111 d6 d29 32 Crook CouEU 19,182 0.56% $ 8,273, $ 27,325 $ 35,598 2,459,265, Deschutes County 115,367 3.37% 49,756 $ 27,325 $ 77,080 7 Z, `7,0, 625. Gilliam County 1,915 0.06% $ 826 $ 27,325 $ 28,151 55r"Oi! 71, '2 47 HarnV Coun V 7,609 0.22% 3,282 $ 27,325, $ 30,607 *oori Hid 20,41.1 UAL t3.2 -5, 30j Jackson Coun !y 181,269 5.30% $ 78 177 $ 271325 $ 106,502 Jefferson' Josephine County 75,726 2.21% $ 32,659 $ 27325 $ 59,984 ;Klamath CouF W7 '36s Lake County 7g422 0,22% 3.201 27,325 30,526 27'325'' Lincoln Coun y 44,479 1.30% $ 19,183 $ 27,325 $ 46 508 7 0 7;1 77 6, Malheur Coun 31,615 0.92% 13 63527,325 $ 40960 Ou* Morrow Cou 10,995 0.32% $ 4,742 $ 27,325 $ 32,067 Distribution bf Region R 1 1 "7.089 284x"1351 & 431,422 - $ U.Z.-.7 Polk Coun !y 0 1,82%. Region 5 $ 26903 $ 27,3 5 54,228 Tillamook Coun 0.71% $ 10464 27,325 $ 37,789 �".24,262 Union County 24 530 0.72% $ 10,579 27 325 37,904 0 W.410WO 'Coumfy'6" 7440.' Wasco Coun !X 23,791 0.70% $ 101260 27.325 371685 2:19'390 Wheeler Coun 1,547 0.05% 111 667 $ 27325 $ 27,992 Ya, hiN Co 0&0 Total Bass Award Distribution 1 100.00% 1,475,565 $ 983,700 $ 2,459,265, Distribution bf Region R 1 1 "7.089 Region 2 431,422 - Region 3 $ 493,560 Rftg!2n 4 $ 42, AN Region 5 $ 295,04; Total t$ 2,459,24.5. 5% for Tribal ProJocts, a $129,435 Total FYOS Allocated 80% Funds (95% Population and Base, 5% Tribal) z $2,588,700 !E I a 2�y14 Lir o. CL Wt Wt 0 o m J � Lill � a� M M _ 4LCL. � w O off W wr :. W �� 7 LL LL �Ni � 3 ��pi r��i M r M y N " N �^ NM ~ 40 f! p N N r r 0991 9 nbk� 1 N W v t� I -M W Sd O o y} � i FY 2008 Homeland Security Grant ram 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 onwing 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 fulfilling traditional public safety d ties ✓ ✓ ✓ 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 ✓I ✓ ✓ Allowable Organizational Activities HSGP funds may be used for the following organizational activities: 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 "on* and Svc Grant ram A Beaton Allowable Equipment Cost: 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 http.//www.rkb.mipt.org. Oregon Emergency Noweemud 42 Personal Protection Equipment (PPE) ✓ ✓ ✓ Explosive Device Mit anon and Remediation Equkwnent ✓ ✓ CBRNE Operational Search and Rescue Equipment ✓ ✓ ✓ Information Technol ✓ ✓ ✓ 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 ✓ ✓ Ins n and Screenin2 S ✓ ✓ A ricuitural Terrorism Prevention, Response, and Mitigation Equipment ✓ CBRNE Response Watercraft ✓ ✓ CBRNE Aviation Equipment ✓ CBRNE LoglsWl Support Equipment ✓ ✓ ✓ Intervention EquipTent. ✓ ✓ Other Authorized Equipment ✓ ✓ ✓ Oregon Emergency Noweemud 42 IFtY 2008 Homeland SecurityGrant PTgrarn Application Allowable Training Costs HSGP may be used for the following training activities: 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 Design, develop, conduct and evaluate an exercise P ✓ P Exercise planning workshop Overtime and backfill funding for emergency preparedness and response personnel attending FEMA -sponsored and approved training classes ✓ ✓ Full- or part-time staff or contractors/consultants 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 ✓ ✓ ✓ 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 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 RY 20M Homeland Grant ram Application Allowable Management and Administrative (MBCA) Costs HSGP funds may be used for the following M&A costs. Unauthorized Program Expenditures HSGP funds may not be used for the foilowing 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, Construction and Renovation ✓ I✓ I✓ Activities unrelated to the completion and implementation of the grant I ✓ I ✓ I ✓ Other item not in accordance with the AEL or previously listed as I '/ I ✓ I ✓ I allowable costs. Oregon Eme�Y ii;WgffW* 44 '� ✓ Hiring -6715X- 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 reaulrements. ✓ Development of operating plans for information collection and processing necessary to respond to FEMA data calls ✓ ✓ ✓ Overtime and backfill costs ✓ ✓ ✓ Travel ✓ ✓ ✓ Meeting related expenses ✓ ✓ ✓ Authorized office equipment ✓ ✓ ✓ Recurring expenses such as those associated with cell phones and faxes during the pgood of performance of the rant program ✓ ✓ ✓ Leasing or renting of space for newly hired personnel during the period of rformance of the grant pENrarn ✓ ✓ ✓ Unauthorized Program Expenditures HSGP funds may not be used for the foilowing 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, Construction and Renovation ✓ I✓ I✓ Activities unrelated to the completion and implementation of the grant I ✓ I ✓ I ✓ Other item not in accordance with the AEL or previously listed as I '/ I ✓ I ✓ I allowable costs. Oregon Eme�Y ii;WgffW* 44