apco/csaa ans 2.101.1-‐2008 alarm monitoring company to

www.apcointl.org

APCO/CSAA ANS 2.101.1-2008

Alarm Monitoring Company to Public Safety Answering Point (PSAP) Computer-Aided Dispatch (CAD) External Alarm Interface Exchange

Alarm Monitoring Company to PSAP CAD External Alarm Interface Exchange

APCO/CSAA ANS 2.101.1-2008

Standard written by The APCO/CSAA Alerts Working Team

Approved January 5, 2009 by APCO International Standards Development Committee (SDC)

Approved January 15, 2009 by The American National Standards Institute (ANSI)

Abstract: This standard will provide detailed technical data to software providers who support CAD Systems or alarm monitoring applications concerning the common data elements and structure that shall be utilized when electronically transmitting a new alarm event from an alarm monitoring company to a PSAP. The standards package includes process flow examples that are necessary during the handoff of new events, new event responses, and updates to working events between the alarm monitoring company and the PSAP.

Keywords: 9-1-1, alarm, alarm monitoring, alarm monitoring software, burglar alarm transfer, central station, central station alarm, computer-aided dispatch (CAD), data transfer, data sharing, direct alarms, electronic alarms, emergencies, emergency, emergency data, emergency response, external alarm interface, external alarm data, fire alarm transfer, interoperability, medical alarm transfer, NIEM, public safety answering point (PSAP), public safety communications, technology and Telecommunicator.

APCO International 351 North Williamson Blvd, Daytona Beach, Florida 32114 USA

No part of this publication may be reproduced in any form without prior written permission. For more information, contact [email protected].


Foreword* The Association of Public-Safety Communications Officials (APCO) International is the worlds oldest and largest professional organization dedicated to the enhancement of public safety communications. APCO International serves the professional needs of its 15,000 members worldwide by creating a platform for setting professional standards, addressing professional issues and providing education, products and services for people who manage, operate, maintain, and supply the communications systems used by police, fire, and emergency medical dispatch agencies throughout the world.

The 2008-2009 APCO International Board of Officers:

Chris Fischer, President

Richard Mirgon, President Elect

William Carrow, First Vice President

Gregg Riddle, RPL, Second Vice President

APCO International Executive Staff:

George S. Rice, Jr., Executive Director

Mark Cannon, Deputy Executive Director

APCO International standards are developed by APCO committees, projects, task forces, workgroups, and collaborative efforts with other organizations coordinated through the APCO International Standards Development Committee (SDC). Members of the committees are not necessarily members of APCO. Members of the SDC are not required to be APCO members. All members of APCOs committees, projects, and task forces are subject matter experts who volunteer and are not compensated by APCO. APCO standards activities are supported by the Comm Center & 9-1-1 Services Department of APCO International.

For more information regarding APCO International and APCO standards please visit: www.apcointl.org www.apcostandards.org

*The Foreword is informative and not a part of the ANS


APCO American National Standards (ANS) are voluntary consensus standards. Use of any APCO standard is voluntary. This standard does not imply that there are no other standards pertaining to this topic. All standards are subject to change. All APCO ANS are required to be reviewed no later than every five years. The designation of an APCO standard should be reviewed to ensure you have the latest edition of an APCO standard, for example:

APCO ANS 1.101.1-2008 = 1 Operations, 2 Technical, 3 Training

APCO ANS 1.101.1-2008 = Unique number identifying the standard

APCO ANS 1.101.1-2008 = The edition of the standard, which will increase after each revision

APCO ANS 1.101.1-2008 = The year the standard was approved and published, which may change after each revision.

The latest edition of an APCO standard cancels and replaces older versions of the APCO standard. Comments regarding APCO standards are accepted any time and can be submitted to [email protected], if the comment includes a recommended change, it is requested to accompany the change with supporting material. If you have a question regarding any portion of the standard, including interpretation, APCO will respond to your request following its policies and procedures. ANSI does not interpret APCO standards, they will forward the request to APCO.

APCO International adheres to ANSIs Patent Policy. Neither APCO nor ANSI is responsible for identifying patents for which a license may be required by an American National Standard or for conducting inquiries into the legal validity or scope of any patents brought to their attention.

No position is taken with respect to the existence or validity of any patent rights within this standard. APCO and the Central Station Alarm Association (CSAA) are the entities that may authorize the use of trademarks, certification marks, or other designations to indicate compliance with this standard.

Permission must be obtained to reproduce any portion of this standard and can be obtained by contacting APCO Internationals Comm Center & 9-1-1 Services Department. Requests for information, interpretations, and/or comments on any APCO standards should be submitted in writing addressed to:

APCO SDC Secretary, Comm Center & 9-1-1 Services APCO International 351 N. Williamson Blvd Daytona Beach, FL 32114 USA [email protected]


Acknowledgements*

At the time this standard received ANS designation, the APCO Standards Development Committee (SDC) and Consensus Body had the following membership:

Carol Adams, RPL Chair Stafford County (VA) Sheriff Office

Joe Gallelli, Vice Chair Zetron

Dr. Barry Cox Institute of Emergency Preparedness (JSU)

Nellie De Los Santos Tiburon

Rick Denos GE Security

Debbie Gailbreath Sarasota County (FL) Sheriffs Office

Alan Harker Spillman Technologies

Frank Kiernan Meriden (CT) Emergency Communications

Jim Mollohan Georgia Technology Authority

Daniel Morelos Tucson (AZ) Airport Authority

Anita Ostrowski Vector Security

Pam Petrow Central Station Alarm Association

William Rendina Valor Systems

Julie Righter Lincoln (NE) Emergency Communications 9-1-1

Lex Rutter GeoComm Inc.

Bradford S. Smith American Medical Response

Sherry Taylor Indianapolis Fire Department Communications Division

Gary Thomas County of Union (NC)

Mike Walsh Integraph Corporation

Gordon Vanauken L. Robert Kimball & Associates

Amanda Byrd, Secretary The Association of Public-Safety Communications Officials (APCO) International

*The Acknowledgments are informative and not a part of the ANS

InformationExchangePackageDocumentation(IEPD)

ExchangeName ExternalAlarmInterfaceExchange

Version 3.0

Date 090908

SponsoringProjectorInitiative

PublicSafetyDataInteroperability(PSDI)Project

FundingSource(s) BJA

EffortManagedBy APCOInternational,IJISInstitute

StandardsUsed NIEM2.0

DescriptionStatement

ThepurposeofthisExternalAlarmInterfaceExchange3.0documentationistoprovideastandardizeddataexchangefortheelectronicallytransmittedalarminformationbetweenanAlarmMonitoringCompanyandaPublicSafetyAnsweringPoint(PSAP).

Page 2 of 30

ContentsOverview* ....................................................................................................................................... 3Purpose* ..................................................................................................................................... 3Versioning* ................................................................................................................................. 3ChangeLog(upgradefrom2.0to3.0)* ...................................................................................... 3Sponsor/Project* ........................................................................................................................ 3Sponsor* ..................................................................................................................................... 4Background/History* .................................................................................................................. 5

IEPD................................................................................................................................................ 9StandardsandCodesUtilized ..................................................................................................... 9LogicalDataRequirementsModel.............................................................................................. 9PhysicalDataRequirementsModel............................................................................................ 9ComponentMappingSpreadsheet(CMT) ................................................................................ 10ExchangeSchema...................................................................................................................... 10Methodology*........................................................................................................................... 11Timeline*................................................................................................................................... 11ImplementationRecommendations ......................................................................................... 11Supported Exchanges................................................................................................................ 15

Exchange Model ................................................................................................................... 15Exchange Detail .................................................................................................................... 21

XML Validation*...................................................................................................................... 22Appendix 1: City of Richmonds Context and Process Flow Diagrams* .................................... 23Appendix 2: Glossary* ................................................................................................................. 30

*SectionsnotedwithanasteriskareofferedforinformationalpurposesonlyandnotpartofthisAmericanNationalStandard(ANS).

Page 3 of 30

Overview*

PurposeThepurposeoftheAPCO/CSAAANS2.101.12008,alsoknownasAlarm3.0,documentationistoprovideastandarddataexchangeforelectronicallytransmittinginformationbetweenanAlarmMonitoringCompanyandaPublicSafetyAnsweringPoint(PSAP).TherearethreeprimaryusesforthisIEPD:

Initialnotificationofanalarmevent BidirectionalupdateofstatusbetweenanalarmmonitoringcompanyandthePSAP Bidirectionalupdateofothereventsbetweenanalarmmonitoringcompanyanda

PSAP

VersioningDate Version APCOANSSeptember15,2006 2.0(GJXDM3.0.3) N/ASeptember9,2008 3.0(NIEM2.0) N/AJanuary15,2009 Updateofthisoverview

documentperAPCOANSprocessgrammaticalissuesonlynoversionnumberchange

APCO/CSAAANS2.101.12008

ChangeLog(upgradefrom2.0to3.0)1. MappingswerechangedfromtheGlobalJusticeModel(GJXDM)totheNational

InformationExchangeModel(NIEM)2.0.2. TwoelementswereaddedbasedonlessonslearnedfromimplementingAlerts2.0.

a. BuildingSensorDetailsText:freetextfieldusedtoindicateinformationspecifictoabuildingsensorifavailable.

b. SourceIPAddress:usedtoverifyandvalidatethesourcealarmmonitoringcompany.

3. ThenameoftheInformationExchangePackageDocument(IEPD)wasupdatedforclarity(fromExternalAlerttoExternalAlarm).

Sponsor/ProjectThisefforttoupgradetheExternalAlarmExchangeIEPDwassponsoredbythePublicSafetyDataInteroperability(PSDI)Program,fundedbytheBureauofJusticeAssistance(BJA)andcomanagedbyAPCOInternationalandtheIJISInstitute.TheoverallPSDIProgramisanticipatedtoencompassmultipleprojects,andisfocusedonadvancingstandardsbasedinformationsharingtosupporttheemergencycommunications

Page 4 of 30

domainspolice,fire,andEMSandotherrelevanthomelandsecuritydomains.Thegoalofthisprojectistoimprovetherealtimeinformationsharingcapabilitiesintheemergencyresponseenvironment.Thisincludesdevelopmentofhighvalueinformationexchanges(IEPDs)relatedtoLocalCommunicationCenters/PSAPs.TheProjectCommitteeiscomposedof16representativesfromAPCOInternational,LawEnforcement,FireServices,EMS,Industry,EmergencyManagement,Transportation,andBJA.Atthetimeofthiswriting,thecommitteemembersare:Status Name Agency/Company Role/Representing

Member BillHobgood CityofRichmondVA Communications

Member BarbaraThornburg NENACommitteeResourceManager(NENA) Communications

Member ArtMeacham CaddoParishCommunicationsDistrictLA Communications

Member JimSlater MAExecutiveOfficeofPublicSafety LawEnforcement

Member DaveMulholland UnitedStatesParkPolice LawEnforcement

Member CharlesWerner InternationalAssociationofFireChiefs(IAFC) FireServices

Member JimSmalley NationalFireProtectionAssociation(NFPA) FireServices

Member KevinMcGinnis NationalAssociationofStateEMSOfficials(NASEMSO) EmergencyMedicalServices

Member MacNeilCross Chief(Ret),NewYorkCityFD EmergencyMedicalServices

Member ErnieBlair Int'lAssocofEmergencyManagers(IAEM) EmergencyManagement

Member JonathanSpanos,PhDNationalEmergencyManagementAssoc.(NEMA) EmergencyManagement

Member WayneGisler HarrisCounty/HoustonTranStar,HoustonTX Transportation

Member BillKellett(Chair) Microsoft Industry

Member DavidFinchum BIOkeyInternational Industry

Member LindaHill TheArcherGroup Industry

Member AlanHarker SpillmanTechnologies Industry

Backup CalvinHarvey HarrisCountyTollRoadAuthority(TX) Transportation

SponsorRepresentative

ChrisTraver BJA ProjectSponsor

APCOPM StephenJ.Wisely APCOInternational ProjectSupport

APCOSupport AmandaByrd APCOInternational ProjectSupport

IJISPM ScottParker IJISInstitute ProjectSupport

SponsorThisprojectisfundedbytheBureauofJusticeAssistancesEdwardByrneMemorialDiscretionaryGrantsProgram.BJAisacomponentoftheOfficeofJusticeProgramsoftheU.S.DepartmentofJustice.ThemissionoftheBJAistoprovideleadershipandservicesingrantadministrationandcriminaljusticepolicydevelopmenttosupportlocal,state,andtribaljusticestrategiestoachievesafercommunities.OneoftheBJA'sgoalsistoimprovethefunctioningofthecriminaljusticesystem.Toachievethesegoals,BJAprogramsemphasizeenhancedcoordinationandcooperationoffederal,state,andlocalefforts.(http://www.ojp.usdoj.gov/BJA)

Page 5 of 30

ProjectManagementTheIJISInstituteisanonprofitcorporationfundedmostlythroughgrantsfromDOJsOfficeofJusticePrograms,BureauofJusticeAssistance(BJA).TheInstituteassistsnationalscopeeffortsrelatedtoinformationsharinginjusticeandpublicsafety.TheInstitutecomprisesamembershipofapproximately200companiesactiveinsupplyinginformationtechnologyproductsandservicestojusticeandpublicsafetyagencies.TheIJISInstituteachievesitsmissionofadvancinginformationsharingthroughthedevelopmentandendorsementofstandards,andbyprovidingassistancetolocal,tribal,andstateagencies.(www.ijis.org)TheAssociationofPublicSafetyOfficials(APCO)Internationalhasastrongcadreofseniormanagementexecutives,technicalstaff,andanenthusiasticcommitteestructurethatisperfectlypositionedtosupporttheIJISInstituteandaffiliatedorganizationstoundertakeandsuccessfullycompletetheobjectivesofthisproject.APCOhasalonghistoryofprovidingleadershipinamyriadofpublicsafetyprojectsandinitiatives.Throughthe70plusyearhistoryofAPCOithasbeenattheforefrontofprojectsdedicatedtothesafeguardingofourcitizensandimprovingpublicsafetycommunications.APCOsqualifiedstaffchampionsprojectswithgoalstostandardizeprocesses,procedures,andservices.(www.apcointl.org)SubcontractorTheIJISInstituteissuedaRequestforProposal(RFP)toitsmembershipforthetechnicalworkforthiseffort.ItwasawardedtoWaterholeSoftwareInc.WaterholecreatedallthetechnicalartifactscontainedintheIEPDandcontributedsignificantlytothisoverviewdocument.(www.waterholesoftware.com)WorkGroupSpecialrecognitionshouldbegiventothefollowingpersonswhoputforthmuchtimeandenergyonthiseffort:

BillHobgood,CityofRichmondVA AaronGorrell,WaterholeSoftware PamPetrow,CentralStationAlarmAssociation(CSAA) StephenWisely,APCOInternational ScottParker,IJISInstitute

Background/History

APCOInternationalestablishedtheCADtoCADInterconnectivityProject,Project36,inAugust2000toexploretheinterconnectivitybetweendifferentComputerAidedDispatch(CAD)systems.InAugust2004,APCOInternationalencouragedtheexpansionandspinoffofProject36withtheinclusionofvoiceanddataexchangebetweenPSAPsandthirdpartycallcenteroperatorssuchasCentralStationAlarmAssociation(CSAA)membercompanies.TheAPCO

Page 6 of 30

InternationalBoardofOfficersassignedtheexpandedversionofthisdataexchangedevelopmentprogrambetweenPSAPsandCSAAmembercompaniestoanewThirdPartyCallCenterGroup,whichincludedtheCSAA.

APCOInternationalandtheCSAAformerlyannouncedonJanuary4,2005apartnershiptojoinforcestodevelopanexchangethatwillbeconsistentlyusedbyCADprovidersandCentralStationAlarmCompaniesforPSAPstoincreaseefficiencyanddecreaseerrors.

ThefirstbetasiteselectedfortheinitialtestprojecttoconducttestsbetweenPSAPsandaCentralAlarmMonitoringStationmembercompanyovertheInternetwasYorkCounty,Virginia,DepartmentofFire&LifeSafety,EmergencyCommunicationsDivision.VectorSecuritywasselectedastheCSAAmembercompanytoparticipateintheelectronicalarmexchange.OnOctober22,2004,thefirstdatatemplatewassuccessfullycompletedfollowingthiscollaboration.TheXMLstandardwasusedforthisinitiative.

AnAlertsWorkingTeamwasformedandmetinDaytonaBeach,FloridainFebruary2006tobegintheExternalAlert2.0IEPDdevelopment.ThisworkingteamwasformedbytheIJISPublicSafetyTechnicalStandardsCommittee(IPSTSC)tocreateexternalalertsandrequestsforserviceIEPDsusingtheGJXDMstandard.

Followingatwoyeardevelopmenteffortwhichincludedextensivetesting,theAlarmInterfaceExchange2.0betweenYorkCounty&VectorSecuritywentliveonJuly15,2006.TheinitialexchangeincludedonlyBurglarandHoldUpalarms.TheexchangewasconductedviatheInternetwithallnecessarysecurityinplaceatVectorSecurityandYorkCounty.AwebservicewasimplementedbyGESecurity.InordertoprotecttheCADSystemfromvulnerabilityandexposuretotheInternet,amiddlewareapplicationwascreatedtoallowaserversittingonYorkCountysdemilitarized,alsoknowasdemarcation,zone(DMZ)toberesponsibleforalltrafficbetweentheCADSystemandthealarmcompany.TheaverageturnaroundtimefromthetimethatthealarmcompanyoperatortransmittedthealarmtothePSAPuntilthefinalAcceptorRejectwas45seconds.ItisthepolicythateachalarmmonitoringcompanyoperatorwouldinitiateacalltothePSAPifnoresponsewasreceivedwithin45seconds.

TheCityofRichmondsPoliceDivisionofEmergencyCommunicationsauthorizedadevelopmentpartnershipwithYorkCountysincebothlocalitieswereusingthesameCADSystem.ThispartnershipincludedAPCOandtheCSAA.APCOandtheCSAAwereanxioustocollectasmuchdataaspossiblesurroundingtheoutcomeofthealarmexchangeinterfaceandrequestedthattheCityofRichmondparticipateinthepilot.ThealarminterfaceexchangewentlivebetweentheCityofRichmondandVectorSecurityonAugust4,2006usingthebusinessprocessflowdescribedabove.TheinitialphaseofthepilotwassosuccessfulthatFireandMedicalalarmsbecamepartofthepilotonOctober24,2006.

OnSeptember11,2007,theCityofRichmondimplementedanewIntergraphCADSystemtoreplacetheCADsystemthathadbeenwritteninhouseandutilizedfor27years.Intergraph

Page 7 of 30

wastaskedtocontinuewiththealarminterfaceexchangeseamlessly.Thisendeavorwassuccessful.

Inthespringof2007,discussionsbeganwithNlets(theInternationalJusticeandPublicSafetyNetwork),APCO,theVirginiaStatePolice,andVectorSecuritytostudythefeasibilityofroutingallalarminterfaceexchangetransactionsviaaVirtualPrivateNetwork(VPN)arrangementbetweenVectorSecurityandNlets.NletshasallofthenecessarysecurityinplaceandaprivatecircuittoeachstateincludingtheStateofVirginia.Allpartiesagreedtoperformaproofofconceptandthenecessarysecurityandnetworkaddresstranslation(NAT)ruleswereputintoplace.OnNovember27,2007,allalarminterfaceexchangetrafficbetweenVectorSecurityandthetwoVirginiaPSAPsbeganbeingroutedthroughNletsandtheStateofVirginiaswitch.

OnFebruary18,2008,theExternalAlert2.0schemawasimplementedattheCityofRichmondbringingthepilottoanothermilestoneinachievingconformancewiththeGlobalJustice(GJXDM)model.GESecurityimplementedanenhancementtostreamlinethedeliveryofalarmdatatothePSAP.

BecauseofthesecuretransmissionpathviaNletsandtheStateofVirginiaswitch,vulnerabilityandexposuretotheInternetisnolongeranissue.ThemiddlewarecontinuestofacilitatetrafficbetweenthePSAPsandthealarmcompany,butnolongerneedstoresideontheDMZ.ThenewaverageturnaroundtimefromthetimethatthealarmcompanyoperatortransmittedthealarmtothePSAPuntilthefinalAcceptorRejectis15secondsorless.

Afterbeinginoperationfortwoyears,over4,500alarmexchangeshavebeentransmittedbetweenVectorSecurityandthetwoVirginiaPSAPs.Thebenefitresultingfromthese4,500exchangesinclude:

1. 4,500fewertelephonecallstothetwoPSAPs,eliminatingtheneedforthealarmmonitoringcompanyoperatortoconversewiththePSAPcalltaker.

2. EliminationofmiscommunicationbetweenthealarmcompanyoperatorandthePSAPcalltaker.

3. Adecreaseinresponsetimestoalarmrelatedcallsforservicewithanincreaseinlawenforcementapprehensionsmade,firesmorequicklyextinguished,andlivessaved.

The2005AlertsWorkingTeamincludedthefollowingparticipants:

Name Agency/Company

HollyBarkwellHolland FireMonitoringTechnologies

JerryCowser VectorSecurity

PamPetrow VectorSecurity

BruceWeissmann GESecurity

AdamEurich DiceCorporation

BillCade APCO/CommCenter&911Services

MartinMoody APCO/CommCenter&911Services

Page 8 of 30

AlanHarker SpillmanTechnologies

RandySyth SungardTHE

AaronGorrell URLIntegration

VivekMisra URLIntegration

SuzetteMcLeod IJISInstitute

NeilKurlander AsynchronousSolutions

HeatherRuzbasan IACP/LEITSC

MattSnyder IACP

TomSteele DelawareDHS

AlanKomenski Bellevue,Washington

StephenWisely OnondagaCo911

JimCox PortOrangePublicSafety

DavidWagner

DevelopmentandImplementationPilotPhaseParticipants:

Name Agency/Company Role

D.TerryHallYorkCountyEmergencyCommunications

YorkCountyChampion

ChiefStephenP.Kopczynski YorkCounty/Fire&LifeSafety YorkCountySponsor

ChiefAndreParker RichmondPoliceDepartment CityofRichmondExecutiveSponsor(2004)

ChiefRodneyMonroe RichmondPoliceDepartment CityofRichmondExecutiveSponsor(20052008)

GeneJ.Doody CityofRichmond ChiefInformationOfficer

Capt.LindaD.Samuel RichmondPoliceDepartment CityofRichmondChampion(20042007)

Capt.WilliamC.Smith RichmondPoliceDepartment CityofRichmondChampion(20072008)

BruceWeissmann GESecurity FormerGESecurityProjectManager(20042006)

RickDenos GESecurity EngineeringManager(20072008)

BillHobgood CityofRichmond,DITProjectManagerforthePSAPs/AuthoroftheLegacyCADSystems

JimGarner CityofRichmond,DIT SeniorSystemsEngineer/AuthoroftheMiddleware

MarkBuckland CityofRichmond,DIT SystemsDeveloper

JohnHoltz CityofRichmond,DIT SystemsDeveloper

PamPetrow VectorSecurity VicePresident,Vector/CSAARepresentative

AnitaOstrowski VectorSecurity AssistantVicePresidentVector/VectorLiaison

JerryCowser VectorSecurity NetworkEngineer

BillCade APCOInternational 911TechnicalServicesProjectCoordinator

StephenJ.Wisely APCOInternational TechnicalServicesManager

ScottParker IJISInstitute ProjectManager

ChrisSchuessler VirginiaStatePolice NetworkEngineeringSupervisor

AnnetteShaffer VirginiaStatePolice NetworkEngineer

JohnJDDinbokowitz Nlets WANAdministrator

RussBrodie Nlets SeniorProjectManager/NletsIntegration

FrankMinice Nlets OperationsDirector

BonnieLocke Nlets DirectorofProgramManagement

NathanHieger GESecurity SystemsDeveloper

Page 9 of 30

Capt.ThomasTurner VirginiaStatePolice CJISDivisionCommander

Lt.PatrickPeteFagan VirginiaStatePolice CJISRepresentative

IEPD

StandardsandCodesUtilized ExternalAlert2.0wasusedasthebaselinesetofrequirements. Nocodelistswerecreatedaspartofthisdevelopmenteffort

LogicalDataRequirementsModelThelogicaldomainmodelcapturesdatarequirementsfromauserperspective.ItismeanttovisuallydescribethedatarequirementsofanIEPD.ThemodeldiagramisavailableintheSupportDocumentationfolder(LogicalModel.jpg).

Figure 1 - Logical Data Requirements Model

PhysicalDataRequirementsModelThephysicalmodelorganizestheinformationinthewaythatitwillbeimplementedusingaparticularstandard(NIEM2.0).Inessence,thephysicalmodelallowstheimplementertonotonlycommunicatethephysicalstructureoftheIEPD,butalsotoplanforhowtheywillmapthedatarequirementstotheprescribedstandard.ThediagramisavailableintheSupportingDocumentationfolder(PhysicalModel.jpg).

Page 10 of 30

Figure 2 - Physical Data Requirements Model

ComponentMappingSpreadsheet(CMT)TheCMTisaMicrosoftExcelfilethatcrossreferencesthedatarequirementsintheexchangetothespecificelementswithineitherNIEMorthelocallyextendedfile.ThefileisavailableintheSupportingDocumentationfolder(ExternalAlarm3.0Mappings.xls).

ExchangeSchemaFileType Location DescriptionNIEM2.0SchemaSubset

/schema/niem/ AsubsetofNIEM2.0thatincludesonlythoseelementsfromNIEMthatarerequiredforthisIEPD

DocumentSchema /schema/apcoalarm/3.0/externalalarm.xsd

Containsthedocumentroot

ExtensionSchema /schema/apcoalarm/3.0/externalalarm.xsd

ThelocallydefinedelementsnecessarytomeetthebusinessrequirementsidentifiedinthisIEPD

Wantlist /schema/wantlist.xml AlistofelementsandtypesusedinNIEM2.0InstanceDocument /schema/xml/ Foursampleinstancedocumentsdemonstratinguseof

theIEPDareincluded.Seetheexchangeinformationsectionbelowfordetailonhoweachinstancedocumentcorrespondstoaparticularscenario.

Stylesheet /schema/xml/alarm_stylesheet.xsl

Whenusedinconjunctionwithaninstancedocument,astylesheetrepresentstheinformationinawaythatismoremeaningfultoasubjectmatterexpert.

Page 11 of 30

Methodology*Version3.0oftheExternalAlarmInterfaceExchangeIEPDstartedbyusingthebaselinerequirementspreviouslyidentifiedfortheAlert2.0exchange.ThefollowingmethodologywasusedinthedevelopmentoftheExternalAlarmInterfaceExchange3.0IEPD:

1. CreateinitiallogicaldatamodelbasedonAlert2.0requirements.2. MeetwithSubjectMatterExperts(SMEs)toidentifymissingelementsandclarify

definitionsofsomeelements.3. Createphysicalmodelbasedondatarequirementsandspecifiedstandard.4. MapelementsidentifiedinphysicalmodelanddistributemappingstoSMEsfor

feedback.5. CreateSchemaSubsetbasedonmappings.6. CreateDocument/Extensionschemabasedonmappings.7. CreateXMLInstancedocuments.8. CreateXSLStylesheet.

Timeline*1. June2008:Receivedfeedbackfromimplementingorganizationregardingtheiruseof

Alarm2.0elements.2. July10,2008:MetwithSMEstoreviewtheirspreadsheetdescribinghowtheywould

useAlert2.0dataelementsfortransmitinformation.Identifiedtwoadditionalelementsasindicatedinthechangelogabove.

3. July18,2008:MeetingwithSMEstoreviewlogicaldatarequirementsmodel.4. July22,2008:FinalizedatarequirementsforAlarm3.0IEPD.5. July30,2008:MappingsaredistributedtotheSMEgroupandfeedbackisincorporated

intotheIEPD.6. August4,2008:InitialIEPDcompletedinreviewbySMEGroup.7. August27,2008:IEPDcompleted.

ImplementationRecommendations

1. Rulesandproceduresbywhichalarmmonitoringcompaniesmayberequiredeitherbypolicyorlocalordinance(s)toattemptcontactwithsomeoneatthealarmsitepriortothedeliveryofanelectronicalarmexchangetothePSAPwillnotchangeandtheprocessisunaffectedbythisIEPD.

2. Implementationsitesshouldconsiderincludingthefollowingperformancemeasurestofocusprojectgoalsandtomeasureimplementationsuccess.

a. NumberoftelephonecallsfromalarmmonitoringcompaniestothePSAP(Isthereareduction?)

b. Overallprocessingtimeforalarmbasedcallsforservice(Isthereareduction?)

Page 12 of 30

c. NumberoferrorsindeliveryandprocessingofalarmandcallsforservicebyeliminatingvoicedeliveryandPSAPcalltakerCADreentry(Hasthenumberdecreased?)

d. ProgresstowardastandardforinterfacesbetweenalarmmonitoringcompaniesandPSAPstoreducecrossagencyandcrossproviderdataexchangedevelopmenttimeandcost(Anymeasurablesavingsoftimeandcost?)

3. AlarmsandrequestsforservicewillbetransmittedtoPSAPspernormalproceduresevenwhenacatastrophicevent(e.g.hurricane)ormassalarmingevent(e.g.windorelectricalstorm)makesaPSAPchoosenottorespond.ThisplacesthePSAPsincontroloffilteringrequestsandprovidesforhistoricalinformationinitsCADorfrontendprocessingengine.

4. FusionCenterand/orotherDepartmentofHomelandSecurity(DHS)informationneedswillbemetviatheCADandorPSAPsystemsandprocesses.TheseneedswilllikelynotbemetdirectlybycreatingexchangesbetweenthealarmmonitoringcompaniesandtheseDHSsystems.

5. TheAlarmInterfaceExchangeincludesthreeprimarymessagetypes:a. NewAlarmeventb. PSAPsResponsetoaNewAlarmeventc. Updatemessagesinitiatedbyeitherentitytotheotherthatprovideadditional

informationaboutthealarmeventThisIEPDdoesnotincludeanyothermessagetypewithinthescopeofthisproject.Forexample,alarmoperatorsandPSAPmemberscannotsendeachotheramessageunlessthereisanactiveevent.AllmessagesthatreferenceanactiveeventmustbeformulatedusingtheUpdatemessagetype.

6. Alarmmonitoringcompanieswillnottakeownershipofindicatinghighriskortargetlocationssincenostandardcriteriaofwhatconstitutesahighriskortargetpropertycurrentlyexists.ItisbelievedthatmostPSAPsandCADSystemswillprovidesuchfunctionalityandownership.Askingalarmmonitoringcompaniestoaddthisinformationcouldcauseaconflictofinterestandwouldlikelycreateconfusion.

7. SomePSAPsmayphaseinfunctionalityassociatedwithautomatedalarmmonitoringcompanyexchangesintotheirCADorfrontendinterface.Forinstance,thePSAPmayinitiallywishtorevieweveryexchangeandrequirecalltakeracceptancebeforeCADdownloadingandthenbegintosupportautomaticacceptanceforcertaintypesofalarmsovertimeastrustandcomfortbuilds.Note:theprocessofcalltakeracceptancewasbypassedatbothoftheVirginiapilotsitesandoptimizedtoreduceresponsetimestothemaximumdegreepossible.ThebypassingofthecalltakeractionduringthispilotprovedhighlysuccessfulwhilemeetingtherequirementsofbothPSAPs.

8. NENAstandardswillbeutilizedforaddressingsincethesestandardsaretypicallyutilizedbyPSAPsandCADS.

9. Generalimplementationguidelinesandsuggestions:a. Eachparticipatingalarmmonitoringcompanyshouldassignaliaisonto

coordinateimplementationbothinternallyandexternallywiththePSAPandthealarmmonitoringsoftwareprovider.

Page 13 of 30

b. EachparticipatingPSAPshouldassignaliaisontocoordinateimplementationbothinternallyandexternallywiththealarmmonitoringcompanyandthePSAPsCADsystemprovider.

c. ResponseplansthatdictatewhichemergencyserviceswillrespondtoaneventandhowmanyFirstResponderswillrespondtoaneventarebusinessdecisionsofthePSAPandnotwithinthescopeofthisIEPD.

d. OnceanexchangehasbeendevelopedendtoendbytheCADproviderandthealarmmonitoringsoftwareproviderandisreadyfortesting,itisrecommendedthatthealarmmonitoringcompanytriggeranAddressValidationrequestforeachalarmaddresswithinthePSAPsjurisdiction.ThiswillfacilitatetheidentificationofproblemaddressesthatneedtobemassagedorreassignedtoadifferentPSAP.

e. AlarmmonitoringcompaniesshouldimplementaprocedurewheretheaddressforanewalarmsubscriberispassedthroughtheAddressValidationprocesswiththePSAPatthetimethatthealarmsubscriptionisaddedtothealarmmonitoringcompanysdatabase.

f. AlarmmonitoringcompaniesmustimplementaproceduretocallthePSAPifanacknowledgementisnotreturnedfromthePSAPwithinxnumberofseconds.ThisisapolicydecisionthatshouldbeestablishedpriortotheimplementationofanynewexchangesbetweenanalarmmonitoringcompanyandaPSAP.

g. Wheneverpossible,alarmmonitoringcompaniesshouldincludethelatitudeandlongitudeofthealarmsiteaddressintheiralarmcustomerdatabasesothatthegeocoordinatesareincludedintheelectronicexchangedelivery.CADprovidersshouldconfiguretheCADsystemstovalidateanaddressbasedonthefollowingorder:

i. Bystreetaddressifastreetaddressispresentii. Bygeocoordinatesifgeocoordinatesarepresent,andifnostreet

addressispresentorifthestreetaddresscannotbevalidatediii. Byintersectioniftwocrossstreetsareprovided,andifnostreetaddress

ispresentandnogeocoordinatesarepresent.Thisshouldbeararesituation.

h. ThePSAPandthealarmmonitoringcompanywilldecideontheeventtypesthatwillbetransmitted.AstandardlistofeventtypesisprovidedinthisIEPD.

i. ThePSAPwillworkwiththeCADsystemprovidertodecidehoweachdataelementsentbythealarmcompanywillbemappedtothecallforservicerecord.

10. Thefollowingalarmorrequestforserviceexchangerejectionreasonsarerecommended;

a. ClosedinCAD(forsupplementalexchanges)b. InvalidAddress(whereaddressdataand/orgeographiccoordinatesdonot

reconcilebetweensystems)c. InvalidData(exchangecontainserroneousdataand/ordoesnotcontain

requiredfieldelements).RejectresponsesfromthePSAPshouldincludethespecificdataelementinerrorandthereasonindetailwhythatdataelementis

Page 14 of 30

beingrejectedasinvalid.Examplesmayincludebutarenotlimitedtothefollowing:

i. TheAlarmEventTypeTextismissingornotavalidtypeofalarmii. TheCalltoPremisesTextfieldismissingandisamandatoryfieldiii. TheMonitoringAlarmCompanyEventNumberismissingandais

mandatoryfieldiv. TheActivityCategoryTextfieldismissingornotvalidv. TheAlarmMonitoringCompanyOrganizationNameismissingandisa

mandatoryfieldvi. TheAlarmMonitoringCompanyCallBackTelephoneNumberismissing

ornot10digitsanditisamandatoryfieldd. IncorrectJurisdiction(customer/locationnotcoveredbyreceivingPSAP)e. UnauthorizedCustomerExceeded(forsituationswhenbusinessrulesapply

wheretheeventlocationhasexceededfalsealarms)f. UnauthorizedCustomerNoPermit(forsituationswhenbusinessrulesapply

wherethejurisdictionmaintainsanalarmpermitregistrybutnoalarmpermitcanbefoundintheregistryfortheeventlocation)

g. Diverted(wherePSAPisnotacceptingcertainalarmtypes,locations,etc?duetocatastrophiceventorotherPSAPdrivenreason)

11. AlarmstriggeredbasedonRadioFrequencyIdentifier(RFID)dataelementswillrequireadditionaldefinitionandresearch.ThesetypealarmsarenotconsideredwithinscopeofthisInformationExchangePackage(IEP)release.

12. DataelementssuchasPatientNameorIncarceratedPersonNamemaybeincludedinfreetextnotessectionversushavingapredefinefieldsinceRFIDandDefibrillatorAlarmsarestillevolving.

13. (CRITICALNOTE)OncetheinitialnewalarmrecordissentbytheAlarmMonitoringCompany,allsubsequentUpdatetransmissionstothePSAPmustutilizetheelementname.MostPSAPsdoNOTwantcertainfieldsupdatedautomaticallybyanexternalsourcesuchasanupdatetotheaddress.Automaticupdatestoanaddresscouldtriggeradifferentresponseplan.Instead,thisIEPDhasprovidedasinglethreadforallUpdatestobesenttotheCADsystem.ItisexpectedthattheCADSystemwilladdtheUpdatetothecallforserviceasanadditionalCommentorNotethatwillbeseenbytheradiooperator.ItshallbetheradiooperatorsresponsibilitytorevieweachCommentsentasanUpdatemessagebytheAlarmMonitoringCompanyandprocesstheUpdateaccordingly.ExamplesofanUpdatemayinclude:

a. ARequesttoCanceltheEventb. Anestimatedtimeofarrival(ETA)forthekeyholderc. Anindividualonthepremisesofthealarmsitewhohasbeencontactedbutdoes

notknowtheproperpasscoded. Achangetooneormoredataelementsoriginallysentasacomponentwithin

thenewcallevente. Othernoteworthyitems

Page 15 of 30

14. WhileTelematicsdatatransmissionisnotaprimarypurposeofthisexchange,theexchangecansupportsomebasicTelematicsdata.

SupportedExchanges

ExchangeModelTheExchangeModeldiagramislocatedintheSupportingDocumentationfolder(ExchangeModel.jpg).

Figure 3 - External Alarm Process Model

Page 16 of 30

Case Scenario Samples

1 Exchange MedicalAlertinfo

ExamplesofTriggeringEvents

AllergicReaction BreathingProblem Burn ChestPain/HeartProblem Choking DiabeticProblem Fall Seizure OtherLifeThreateningProblems

SampleScenario(s)

Anelderlypersonlivingalonesubscribestoanalarmmonitoringserviceandwearsadevicethatallowstheindividualtotriggerasignaltothealarmcompanywhenexperiencingalifethreateningmedicalproblem.Theindividualbeginstoexperiencechestpains(orencountersanyoneofthetriggeringeventslistedabove)andactivatesthedevice.ThealarmmonitoringcompanyreceivesanotificationsignalthataMedicalAlarmhasbeenactivated.Thesoftwareapplicationandtheassociateddatabaseutilizedbythealarmmonitoringcompanyindicatestheproper911PSAPresponsibleforthedispatchofFirstResponderpersonneltothepremisesaddressassociatedtothealarm.ThealarmcompanyoperatorinitiatestheelectronictransmissionofMedicalAlertinformationtothecorrect911PSAP.Datatransmittedtothe911PSAPincludesthealarmcompanyseventnumber,addressofthealarmsubscriber,thetypeofalarm,detailedinformationaboutthepremises,anddetailedinformationabouttheindividualthatwillassistFirstRespondersinlocatingthepremisesandbefamiliarwiththepatientshistorybeforetheirarrival.Uponreceiptofthisdata,the911PSAPsComputerAidedDispatch(CAD)SystemvalidatestheaddresswithinthePSAPsjurisdictionandcreatesaCallforService.FirstRespondersareimmediatelydispatchedtothepremises.SensitiveinformationabouttheindividualtypicallywillbesenttotheFirstRespondersmobiledatacomputer(MDC).TheCADSystemtransmitsanelectronicacknowledgementtothealarmcompanythatreferencesthealarmcompanyseventnumberandincludesthePSAPseventnumber(s)andanindicationthattheCallforServicehasbeensenttothedispatchqueuetobedispatchedtoEmergencyFirstResponders.AdditionalinformationrelatingtotheeventmaybeoriginatedbythealarmcompanyorthePSAPandtransmittedtotheotherentityelectronically.

SampleBusinessRule(s)

Dependingongoverninglawsofthejurisdictionaffected,oroperatingproceduresofthealarmcompany,thealarmcompanymayattempttoreachsomeoneatthepremisesbeforeinitiatingtheelectronicexchange.

IfanaddresscannotbevalidatedandLatitude/Longitudecoordinatesarepresentinthedataexchange,theCADSystemwillattempttovalidateusinggeocoordinates.

Iftheaddressandgeocoordinates(ifpresent)cannotbevalidated,anelectronicRejectionmessagewillbereturnedbythePSAPtothealarmcompany.Thealarmcompanyoperatorisexpectedtotakeactionaccordingtoalarmcompanyprocedures.

FirstRespondersdispatchedmayincludeEMSplusacombinationofFireand/orLawEnforcementdependingonlocalPSAPagencyprocedures,

SensitiveinformationabouttheindividualtypicallymaybesenttotheFirstRespondersmobiledatacomputer(MDC).

Page 17 of 30

2 Exchange FireAlarminfo


Smoke/HeatDetector ManualPullStation Sprinkler/WaterflowDetector

SampleScenario(s)

Afirebeginsinsideastructureandisspottedbyanindividual.Theindividualpullsthemanualpullstationtosummonthefiredepartmentandsoundanalarmforotherstoevacuate.Asignalistransmittedtothealarmcompany.

Afirebeginsinsideastructureandcausesthesprinklersystemtoactivate.Asprinkler/waterflowactivationsignalistransmittedtothealarmcompany.

Afirebeginsinsideastructureandissensedbyasmokeorheatdetector.Asignalistransmittedtothealarmcompany.

AnalarmmonitoringservicereceivesasignalthataFireAlarmhasbeenactivatedviaoneofthetriggerexamplesabove.Thesoftwareapplicationandtheassociateddatabaseutilizedbythealarmmonitoringcompanyindicatestheproper911PSAPresponsibleforthedispatchofFirstResponderpersonneltothepremisesaddressassociatedtothealarm.ThealarmcompanyoperatorinitiatestheelectronictransmissionofFireAlarminformationtothecorrect911PSAP.Datatransmittedtothe911PSAPincludesthealarmcompanyseventnumber,addressofthealarmsubscriber,thetypeofalarmincludingthetriggeringmethod,anddetailedinformationaboutthepremisesincludingcommercialversusresidential,detaileddirections,andhazardousmaterialsstoredatthefacility,etc,thatwillassistFirstRespondersinlocatingthepremisesandbeingfamiliarwithanydangersthatcouldbepresentedtotheFirstRespondersupontheirarrival.Uponreceiptofthisdata,the911PSAPsCADSystemvalidatestheaddresswithinthePSAPsjurisdictionandcreatesaCallforService.FirstRespondersareimmediatelydispatchedtothepremises.TheCADSystemtransmitsanelectronicacknowledgementtothealarmcompanythatreferencesthealarmcompanyseventnumberandincludesthePSAPseventnumber(s)andanindicationthattheCallforServicehasbeensenttothedispatchqueuetobedispatchedtoEmergencyFirstResponders.AdditionalinformationrelatingtotheeventmaybeoriginatedbythealarmcompanyorthePSAPandtransmittedtotheotherentityelectronically.AnotificationfromCADtoTrafficwebsitesandIntelligentTransportationSystemscouldbesentwhentheamountofrespondingfireapparatusissignificantandtrafficintheareaoftheemergencycouldbeaffected.


Dependingongoverninglawsofthejurisdictionaffected,oroperatingproceduresofthealarmcompany,thealarmcompanymayattempttoreachsomeoneatthepremisesifthepremisestypeisRESIDENTIALbeforeinitiatingtheelectronicexchange.



FirstRespondersdispatchedmayincludeFireplusacombinationofEMSand/orLawEnforcementdependingonlocalPSAPagencyprocedures,Lawenforcementcouldbetypicallydispatchedfortrafficandcrowdcontrolpurposes.

Page 18 of 30

3 Exchange GasDetectorAlarminfo


NaturalGasDetector CarbonMonoxideDetector

SampleScenario(s)

Anaturalgaspipebreaksinsideofastructureandtriggersanaturalgasdetectoralarmsignal.

Theventonafurnacebecomesclogged,causescarbonmonoxidetobuildupinsideofastructure,andsubsequentlytriggersacarbonmonoxidealarmsignal.

AnalarmmonitoringservicereceivesasignalthataGasDetectorAlarmhasbeenactivatedviaoneofthetriggerexamplesabove.Thesoftwareapplicationandtheassociateddatabaseutilizedbythealarmmonitoringcompanyindicatestheproper911PSAPresponsibleforthedispatchofFirstResponderpersonneltothepremisesaddressassociatedtothealarm.ThealarmcompanyoperatorinitiatestheelectronictransmissionofGasDetectorAlarminformationtothecorrect911PSAP.Datatransmittedtothe911PSAPincludesthealarmcompanyseventnumber,addressofthealarmsubscriber,thetypeofalarmincludingthetriggeringmethod,anddetailedinformationaboutthepremisesincludingcommercialversusresidential,detaileddirections,andhazardousmaterialsstoredatthefacility,etc.,thatwillassistFirstRespondersinlocatingthepremisesandbeingfamiliarwithanydangersthatcouldbepresentedtotheFirstRespondersupontheirarrival.Uponreceiptofthisdata,the911PSAPsCADSystemvalidatestheaddresswithinthePSAPsjurisdictionandcreatesaCallforService.FirstRespondersareimmediatelydispatchedtothepremises.TheCADSystemtransmitsanelectronicacknowledgementtothealarmcompanythatreferencesthealarmcompanyseventnumberandincludesthePSAPseventnumber(s)andanindicationthattheCallforServicehasbeensenttothedispatchqueuetobedispatchedtoEmergencyFirstResponders.AdditionalinformationrelatingtotheeventmaybeoriginatedbythealarmcompanyorthePSAPandtransmittedtotheotherentityelectronically.AnotificationfromCADtoTrafficwebsitesandIntelligentTransportationSystemscouldbesentwhentheamountofrespondingfireapparatusissignificantandtrafficintheareaoftheemergencycouldbeaffected.





FirstRespondersdispatchedmayincludeFireplusacombinationofEMSand/orLawEnforcementdependingonlocalPSAPagencyprocedures,Lawenforcementcouldbetypicallydispatchedfortrafficandcrowdcontrolpurposes.

Page 19 of 30

4 Exchange BurglarAlarminfo


BurglarAlarm TamperAlarm(Someonetamperingwithequipment)** RestoreSignal(AlarmRestoredbutnoprioralarmreceived)** PhoneLineFailure(Someonehaspossiblycutphoneline)** Open/CloseSignal(Someonedisarmingsystemwithoutpermission)** Reset/Cancel(Someonedisarmingsystemwithoutpermission)**

**Notnecessarilyatriggeringeventinallinstancesandmayresultinacustomer/contactonlynotificationbythealarmcompany.Theresponsestothese"supervisory"signalswillvarygreatlybyalarmcompanyandmayresultinthePSAPnotbeingcontacteddependentupontheoutcomeofthecustomercontactbythealarmcompany.

SampleScenario(s)

Aresidenceisbrokenintoandthesuspectsmovementisdetectedbyamotiondetector.

Someoneisattemptingtodisablethepremisesalarmequipment.

Thealarmcompanyreceivesanalarmrestoremessagebutnoprioralarmwasreceived.

Someoneattemptstocutthetelephoneline.

Someoneattemptstodisarmthealarmsystemwithoutthepropersecuritycode.

Analarmmonitoringservicereceivesasignalthatanalarmhasbeenactivatedviaoneofthetriggerexamplesabove.Thesoftwareapplicationandtheassociateddatabaseutilizedbythealarmmonitoringcompanyindicatestheproper911PSAPresponsibleforthedispatchofLawEnforcementFirstResponderpersonneltothepremisesaddressassociatedtothealarm.ThealarmcompanyoperatorinitiatestheelectronictransmissionofBurglarAlarminformationtothecorrect911PSAP.Datatransmittedtothe911PSAPincludesthealarmcompanyseventnumber,addressofthealarmsubscriber,thetypeofalarmincludingthetriggeringmethod(motiondetector,glassbreakage,etc)andspecificlocationofthetriggeringdevice(reardoor,fronthall,etc),anddetailedinformationaboutthepremisesincludingcommercialversusresidential,detaileddirections,andhazardousmaterialsstoredatthefacility,etc,thatwillassistLawEnforcementFirstRespondersinlocatingthepremisesandbeingfamiliarwithanydangersthatcouldbepresentedtotheFirstRespondersupontheirarrival.Uponreceiptofthisdata,the911PSAPsCADSystemvalidatestheaddresswithinthePSAPsjurisdictionandcreatesaCallforService.LawEnforcementFirstRespondersareimmediatelydispatchedtothepremises.TheCADSystemtransmitsanelectronicacknowledgementtothealarmcompanythatreferencesthealarmcompanyseventnumberandincludesthePSAPseventnumber(s)andanindicationthattheCallforServicehasbeensenttothedispatchqueuetobedispatchedtoLawEnforcementFirstResponders.AdditionalinformationrelatingtotheeventmaybeoriginatedbythealarmcompanyorthePSAPandtransmittedtotheotherentityelectronically.Additionalinformationmayconsistofacancellationrequestfromthealarmcompany,informationaboutthekeyholderfromthealarmcompany,statuschangesbyrespondingLawEnforcementofficers,andsituationfoundinformationasdenotedbytheLawEnforcementOfficer(s)onscene.





Page 20 of 30

5 Exchange Holdup/Panic/DuressAlarm(Robberyinprogress)info


HoldupAlarm Panic/DuressAlarm

SampleScenario(s)

AjewelrystoreisbeingrobbedandastoreemployeemanagestotriggerapushbuttonsignalingdevicetoinitiateaHoldupalarm.

AhomeinvasionoccursandthehomeownermanagestotriggerasignalingdevicetoinitiateaPanic/Duressalarm.

Analarmmonitoringservicereceivesasignalthatanalarmhasbeenactivatedviaoneofthetriggerexamplesabove.Thesoftwareapplicationandtheassociateddatabaseutilizedbythealarmmonitoringcompanyindicatestheproper911PSAPresponsibleforthedispatchofLawEnforcementFirstResponderpersonneltothepremisesaddressassociatedtothealarm.Thealarmcompanyoperatorinitiatestheelectronictransmissionofalarminformationtothecorrect911PSAP.Datatransmittedtothe911PSAPincludesthealarmcompanyseventnumber,addressofthealarmsubscriber,thetypeofalarm,anddetailedinformationaboutthepremisesincludingcommercialversusresidential,detaileddirections,andhazardousmaterialsstoredatthefacility,etc,thatwillassistLawEnforcementFirstRespondersinlocatingthepremisesandbeingfamiliarwithanydangersthatcouldbepresentedtotheFirstRespondersupontheirarrival.Uponreceiptofthisdata,the911PSAPsCADSystemvalidatestheaddresswithinthePSAPsjurisdictionandcreatesaCallforService.LawEnforcementFirstRespondersareimmediatelydispatchedtothepremises.TheCADSystemtransmitsanelectronicacknowledgementtothealarmcompanythatreferencesthealarmcompanyseventnumberandincludesthePSAPseventnumber(s)andanindicationthattheCallforServicehasbeensenttothedispatchqueuetobedispatchedtoLawEnforcementFirstResponders.AdditionalinformationrelatingtotheeventmaybeoriginatedbythealarmcompanyorthePSAPandtransmittedtotheotherentityelectronically.Additionalinformationmayconsistofacancellationrequestfromthealarmcompany,additionaldetailsconcerningtheeventfromthealarmcompany,statuschangesbyrespondingLawEnforcementofficers,andsituationfoundinformationasdenotedbytheLawEnforcementOfficer(s)onscene.





PSAPsgenerallywilltreatanalarmnotificationasaHoldupAlarmifthepremisestypeisCommercial.OtherwisetheeventtypeisgenerallytreatedasaPanic/Duressalarmwhenthepremisestypeisresidential.

Page 21 of 30

ExchangeDetailID ExchangeDescription RepresentativeInstance1 TheAlarmMonitoringCompanyreceivesanalarmnotificationandmayattempttomakecontactwith

someoneatthealarmsiteifrequired(dependingonalarmtype,locallaws,businessprocessrules,etc).IftheAlarmMonitoringCompanyoperatordeterminesthatthePSAPmustbenotified,theoperatorwillinitiateanExternalAlarmInterfaceExchangetothePSAP.Uponreceiptofthenewalarmtransaction,thePSAPsmiddlewareapplicationrespondstothetransactionwithanACKcharacterattheIPlevelandthenpassesthenewalarmdatatotheCADSystem.Ifthemessageistruncatedormalformed,themiddlewareapplicationreturnsaNACKcharacter,alsoknownasNAKtothealarmservice.

/schema/xml/scenario1_new_alarm.xml

2 UponreceiptofnewalarmdatabythePSAP,thePSAPsCADsystemtakesownershipofthedataandisresponsiblefortheattempttoprocessthenewalarmdataasacallforservice.TheCADwillattempttovalidatetheaddressprovidedandensurethatmandatoryelementshavebeenprovided.Ifthisprocessissuccessfulandthecriteriontogenerateacallforservicehasbeenmet,theCADwillassembleacallforservicerecordandthengenerateanAcceptresponsetobepassedbacktotheAlarmMonitoringCompany.TheoperatorwhotriggeredthealarmexchangetothePSAPreceivestheAcceptresponsefromthePSAPwithinsecondsoftheoriginaltransmissionandisawarethatacallforservicehasbeenplacedinthependingcallqueuefordispatchtoPublicSafetypersonnel.ThemiddlewareapplicationatthePSAPthatsendsthisAcceptmessagetothealarmserviceexpectsnothinginreturn.

/schema/xml/scenario2_accepted.xml

3 UponreceiptofnewalarmdatabythePSAP,thePSAPsCADsystemtakesownershipofthedataandisresponsiblefortheattempttoprocessthenewalarmdataasacallforservice.TheCADwillattempttovalidatetheaddressprovidedandensurethatmandatoryelementshavebeenprovided.Ifthisprocessisnotsuccessfuland/orthecriteriontogenerateacallforservicehasnotbeenmet,theCADwillgenerateaRejectresponsetobepassedbacktotheAlarmMonitoringCompany.CADSystemsmayalsobeprogrammedtoRejectallnewalarmeventswhenthePSAPisoverwhelmedsuchasahurricanesituationandisrefusingallalarmeventrequests.TheoperatorwhotriggeredthealarmexchangetothePSAPreceivestheRejectresponsefromthePSAPwithinsecondsoftheoriginaltransmissionandisawarethattherequestedcallforservicehasbeenrejectedbythePSAPandthereasonwhy.Theoperatorwillinvokebackupprocedures,identifythereasonfortherejection,andtakeappropriateactionbycallingthePSAPviatelephone.ThemiddlewareapplicationatthePSAPthatsendsthisRejectmessagetothealarmserviceexpectsnothinginreturn.

/schema/xml/scenario3_rejected.xml

4 AsvariousstatuseschangeduringtheeventatthePSAPlevel,theCADSystemmaysendanUpdatetransactiontotheAlarmMonitoringCompany.ExamplesthatcantriggeranUpdatemessageatthePSAPlevelmayoptionallyinclude:(1)theDispatchofFirstResponderstothealarmsite,(2)ArrivalofFirstRespondersatthealarmsite,(3)ClearingofFirstRespondersfromthealarmeventincludingadisposition(ifany),and(4)anynotesaddedbytheradiooperatororfieldpersonnelduringthecourseoftheevent.ThemiddlewareapplicationatthePSAPthatsendsthisUpdatemessagetothealarmserviceexpectsnothinginreturn.

/schema/xml/scenario4_update_from_psap.xml

5 AftertheinitialnewalarmeventhasbeentriggeredbytheAlarmMonitoringCompanyandAcceptedbythePSAP,theAlarmMonitoringCompanymayencounteradditionalinformationrelatedtotheeventthatmustbesharedwiththePSAP.TheAlarmMonitoringCompanyoperatorcansendadditionalinformationtothePSAPintheformofanUpdatemessage.ExamplesofanUpdatemayinclude:(1)aRequesttoCanceltheEvent,(2)anestimatedtimeofarrival(ETA)forthekeyholder,(3)anindividualonthepremisesofthealarmsitewhohasbeencontactedbutdoesnotknowtheproperpasscode,(4)achangetooneormoredataelementsoriginallysentasacomponentwithinthenewcallevent,and(5)othernoteworthies.Note:AllUpdatesincludingchangestooneormoredataelementsmustutilizetheelementnameasdemonstratedintheexamplescenarioinstancetoholdtheUpdatedinformation.MostPSAPsdoNOTwantcertainfieldsupdatedautomaticallybyanexternalsourcesuchasanupdatetotheaddress.Automaticupdatestoanaddresscouldtriggeradifferentresponseplan.Instead,thisIEPDhasprovidedasinglethreadforallUpdatestobesenttotheCADsystem.ItisexpectedthattheCADSystemwilladdtheUpdatetothecallforserviceasanadditionalCommentorNotethatwillbeseenbytheradiooperator.ItshallbetheradiooperatorsresponsibilitytorevieweachCommentsentasanUpdatemessagebytheAlarmMonitoringCompanyandprocesstheUpdateaccordingly.UponreceiptoftheUpdatemessagefromtheAlarmMonitoringCompany,thePSAPsmiddlewareapplicationrespondstothetransactionwithanACKcharacterattheIPlevelandthenpassestheUpdatemessagetotheCADSystem.Ifthemessageistruncatedormalformed,themiddlewareapplicationreturnsaNACKcharacter,alsoknownasNAKtothealarmservice.TheCADSystemmustassembleanUpdateResponsemessageusingthesameformatastheUpdatemessagebutwithanindicatorintheStatusfieldofUPDAcceptorUPDRejecttoindicatethattheCADhaseitherAcceptedorRejectedtheUpdate.ThemiddlewareapplicationatthePSAPthatsendsthisUpdateResponsemessagetothealarmserviceexpectsnothinginreturn.

/schema/xml/scenario5_update_from_alarm.xml

6 Forfutureimplementationconsideration,BuildingSensoralertssentviaaCommonAlertProtocol(CAP)messagecanbeaccommodatedwiththisIEPD.

/schema/xml/scenario1_new_alarm.xml

Page 22 of 30

XMLValidation*The image below is a screen print indicating that Altova XML Spy 2007 was used to ensure that the IEPD met XML validation requirements.

Figure 4 - Validation Screen Image

Page 23 of 30

Appendix1:CityofRichmondsContextandProcessFlowDiagrams*ThesediagramsweredevelopedbytheCityofRichmondduringtheirimplementationoftheExternalAlarmInterfaceExchangeandareprovidedhereassupportingdocumentation.

ProcessNumber

EVENTS/PROCESSES

1 NotifyPSAPofnewalarmcall1.1 SendeventinformationtoPSAPMiddlewareapplication2 Acknowledgenewcallnotification2.1 Sendacknowledgementfornewcallnotification(ACK/NACK)3 PSAPMiddlewareApplicationProcessXMLdataandsendstoCAD3.1 MiddlewareparsesXMLfieldstovalidateformatbutDoesNotAltertheData3.2 XMLfileisforwardedtoCADSystem4 VerifyCallAddressandValidateMandatoryfields4.1 CADprocessesfileandextractscalladdress4.2 CADverifiescalladdressagainstaddressdatabase4.3 Ifaddressdoesnotverify,orifoneormoremandatoryfieldsaremissing,sendstatusupdatetoAlarmCompany(Process

6)5 ForwardcalltoDispatchQueue(s)5.1 CADmakescalldataavailabletodispatchpersonnel5.2 Dispatchpersonnelreviewcall5.3 Dispatchpersonneldispatchcalltoappropriateagenciesandfirstresponderpersonnel6 NewEventresponse6.1 CADgeneratesastatusindicatingiftheNewEventwasacceptedasavalideventandifsogeneratesanewCADevent6.2 CADsendsdetailsofnewCADevent(ifvalid)orreasonforrejectiontoPSAPMiddlewareapplication6.3 PSAPMiddlewareapplicationsendsNewEventstatustotheappropriateAlarmMonitoringCompany7 UpdateCallStatus(OriginatesfromCADortheAlarmCompany)7.1 CADgeneratesstatusupdatesbasedeitherdispatcher/fieldunitinputORtheAlarmMonitoringCompanyprovides

Page 24 of 30

additionalinformationabouttheeventtothePSAP7.2 CADsendsstatusupdatetothePSAPMiddlewareApplicationortheAlarmMonitoringApplicationsendsastatusupdateto

thePSAPmiddlewareapplication7.3 ThePSAP'sMiddlewareApplicationforwardstheupdatetotheCADSystemiftheoriginatorofthemessageistheAlarm

MonitoringCompany,orwillsendtheupdatetotheAlarmMonitoringCompanyiftheoriginatorofthemessageisthePSAP

7.4 UponreceiptofanUpdatemessagefromtheAlarmMonitoringCompanyviatheMiddlewareApplication,theCADSystemwillsendanUpdateAcknowledgementtotheAlarmMonitoringCompanyviatheMiddlewareapplication

Page 25 of 30

Page 26 of 30

PSAP CAD application validate call address

Addressdatabase

CAD process to Extract, validate call

address, and Validate Mandatory Fields

CAD system

Call data

Call address Verifyresults

Verifyresults

Address isValid and Mandatory

Fields are Valid

See Flow_Responseprocess drawing

Address validationError and/or Mandatory

Fields are Invalid

See Flow_Dispatch

process drawing

9/9/2008City of RichmondDIT Public Safety Team

External Alarm Interface Exchange Process Flow

External Alarm Interface Exchange - Process Flow

Page 27 of 30

Page 28 of 30

Bi-Directional Update Status Flow

CAD system

CAD Fire/Police dispatch workstations

Updates to alarm call status PSAP Middleware

application

StatusUpdate(s)

Networkshare

StatusUpdate(s)

StatusUpdate(s)

9/9/2008City of RichmondDIT Public Safety Team

External Alarm Interface Exchange Process Flow

External Alarm Interface Exchange - Process Flow

Application used by various Alarm Companies.

Each AlarmCompany will create/update/

host its own application/server

Note:

Raw TCP messaging between the Middleware application and CAD is an alternative to using a network drive share.

Page 29 of 30

Page 30 of 30

Appendix2:GlossaryAPCO ........AssociationofPublicSafetyCommunicationsOfficialsInternationalBJA............BureauofJusticeAssistanceCAD...........ComputerAidedDispatchCMT..........ComponentMappingSpreadsheetCSAA.........CentralStationAlarmAssociationDMZ..........Ademilitarized(alsoknownasdemarcation)zone,basedonmilitaryusageofthe

termbutmoreappropriatelyknownasademarcationzoneorperimeternetwork,isaphysicalorlogicalsubnetworkthatcontainsandexposesanorganization'sexternalservicestoalarger,untrustednetwork,usuallytheInternet.ThepurposeofaDMZistoaddanadditionallayerofsecuritytoanorganization'sLocalAreaNetwork(LAN);anexternalattackeronlyhasaccesstoequipmentintheDMZ,ratherthanthewholeofthenetwork

DOJ ...........DepartmentofJusticeEMS ..........EmergencyMedicalServicesETA ...........EstimatedTimeofArrivalGJXDM......GlobalJusticeXMLDataModelIEPD ..........InformationExchangePackageDocumentationIJIS ............IJISInstituteMDC .........MobileDataComputerNENA ........NationalEmergencyNumberAssociationNIEM.........NationalInformationExchangeModelNlets .........InternationalJusticeandPublicSafetyNetworkPSAP .........PublicSafetyAnsweringPointPSDI ..........PublicSafetyDataInteroperabilityprojectRFID ..........RadioFrequencyIDentificationSME ..........SubjectMatterExpertXML ..........eXtensibleMarkupLanguageXSL............ExtensibleStylesheetLanguage(atechnicalartifactwithintheIEPD)


Notes

351 N. Williamson Blvd. Daytona Beach, FL 32114 USA

www.apcointl.org

APCO-CSAA-ANS2-101-1web.pdfAPCO/CSAA ANS 2.101.1-2008AbstractKeywordsAcknowledgementsForeword

IEPD coverpageTable of ContentsOverviewPurposeVersioningChange LogSponsor/ProjectBackground/History

IEPDStandards and Codes UtilizedLogical Data Requirements ModelPhysical Data Requirements ModelComponent Mapping SpreadsheetExchange SchemaMethodologyTimelineImplementation Recommendations

Supported ExchangesExchange ModelCase Scenario SamplesExchange Details

XML ValidationAppendix 1: City of Richmond's Context and Process Flow DiagramsAppendix 2: GlossaryNotes

apco/csaa ans 2.101.1-‐2008 alarm monitoring company to

Documents