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 up- dates 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].
Alarm Monitoring Company to PSAP CAD External Alarm Interface Exchange
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
Alarm Monitoring Company to PSAP CAD External Alarm Interface Exchange
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]
Alarm Monitoring Company to PSAP CAD External Alarm Interface Exchange
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
ExamplesofTriggeringEvents
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.
SampleBusinessRule(s)
Dependingongoverninglawsofthejurisdictionaffected,oroperatingproceduresofthealarmcompany,thealarmcompanymayattempttoreachsomeoneatthepremisesifthepremisestypeisRESIDENTIALbeforeinitiatingtheelectronicexchange.
IfanaddresscannotbevalidatedandLatitude/Longitudecoordinatesarepresentinthedataexchange,theCADSystemwillattempttovalidateusinggeocoordinates.
Iftheaddressandgeocoordinates(ifpresent)cannotbevalidated,anelectronicRejectionmessagewillbereturnedbythePSAPtothealarmcompany.Thealarmcompanyoperatorisexpectedtotakeactionaccordingtoalarmcompanyprocedures.
FirstRespondersdispatchedmayincludeFireplusacombinationofEMSand/orLawEnforcementdependingonlocalPSAPagencyprocedures,Lawenforcementcouldbetypicallydispatchedfortrafficandcrowdcontrolpurposes.
Page 18 of 30
3 Exchange GasDetectorAlarminfo
ExamplesofTriggeringEvents
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.
SampleBusinessRule(s)
Dependingongoverninglawsofthejurisdictionaffected,oroperatingproceduresofthealarmcompany,thealarmcompanymayattempttoreachsomeoneatthepremisesbeforeinitiatingtheelectronicexchange.
IfanaddresscannotbevalidatedandLatitude/Longitudecoordinatesarepresentinthedataexchange,theCADSystemwillattempttovalidateusinggeocoordinates.
Iftheaddressandgeocoordinates(ifpresent)cannotbevalidated,anelectronicRejectionmessagewillbereturnedbythePSAPtothealarmcompany.Thealarmcompanyoperatorisexpectedtotakeactionaccordingtoalarmcompanyprocedures.
FirstRespondersdispatchedmayincludeFireplusacombinationofEMSand/orLawEnforcementdependingonlocalPSAPagencyprocedures,Lawenforcementcouldbetypicallydispatchedfortrafficandcrowdcontrolpurposes.
Page 19 of 30
4 Exchange BurglarAlarminfo
ExamplesofTriggeringEvents
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.
SampleBusinessRule(s)
Dependingongoverninglawsofthejurisdictionaffected,oroperatingproceduresofthealarmcompany,thealarmcompanymayattempttoreachsomeoneatthepremisesbeforeinitiatingtheelectronicexchange.
IfanaddresscannotbevalidatedandLatitude/Longitudecoordinatesarepresentinthedataexchange,theCADSystemwillattempttovalidateusinggeocoordinates.
Iftheaddressandgeocoordinates(ifpresent)cannotbevalidated,anelectronicRejectionmessagewillbereturnedbythePSAPtothealarmcompany.Thealarmcompanyoperatorisexpectedtotakeactionaccordingtoalarmcompanyprocedures.
Page 20 of 30
5 Exchange Holdup/Panic/DuressAlarm(Robberyinprogress)info
ExamplesofTriggeringEvents
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.
SampleBusinessRule(s)
Dependingongoverninglawsofthejurisdictionaffected,oroperatingproceduresofthealarmcompany,thealarmcompanymayattempttoreachsomeoneatthepremisesbeforeinitiatingtheelectronicexchange.
IfanaddresscannotbevalidatedandLatitude/Longitudecoordinatesarepresentinthedataexchange,theCADSystemwillattempttovalidateusinggeocoordinates.
Iftheaddressandgeocoordinates(ifpresent)cannotbevalidated,anelectronicRejectionmessagewillbereturnedbythePSAPtothealarmcompany.Thealarmcompanyoperatorisexpectedtotakeactionaccordingtoalarmcompanyprocedures.
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)
Alarm Monitoring Company to PSAP CAD External Alarm Interface Exchange
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
Top Related