Elevator Destination Dispatch Security (DDE)

Section 28 35 00
Elevator Destination Dispatch Security (DDE)

Status: Draft Version 1 – Consultant Ready
Basis Of Design: BluB0X BluSKY
Coordinated With:
• Division 14 – Conveying Equipment
• Division 28 – Electronic Safety And Security

Part 1 – General

1.1 Summary
A. This section defines the requirements for a secure, identity-centric Elevator Destination Dispatch (DDE) Security System in which elevator car assignment is determined prior to car entry based on authenticated passenger intent.
B. Security authorization shall be evaluated before dispatch, ensuring that only permitted destination floors are presented and dispatched.
C. This specification applies exclusively to deterministic destination dispatch systems.
Two-button relay and hybrid elevator security models are addressed in separate specifications.

1.2 Purpose And Intent
A. Provide secure, high-throughput vertical transportation for multi-tenant and enterprise buildings.
B. Integrate identity, access control, elevators, analytics, and diagnostics into a single deterministic model.
C. Remain OEM-agnostic, resilient, and future-proof.
D. Preserve elevator safety, code compliance, and operational continuity.

1.3 Definitions
• DDE: Destination Dispatch Elevator
• Dispatch Interface: Any kiosk, Person Reader, turnstile terminal, or mobile interface initiating dispatch
• Floor Stop: Logical security object representing a destination floor
• Floor Matrix: Policy engine defining inter-floor access rules
• Connected State: Security and DDE fully communicating
• Disconnected State: Loss of communication between security and DDE

Part 2 – System Description

2.1 Destination Dispatch Model
A. Dispatch shall be deterministic, using:
• Identity
• Origin floor
• Authorized destination floors
• System state and traffic conditions
B. Elevator motion control and life-safety systems remain under elevator OEM control.

2.2 Scope Of Control
The DDE security system shall support:
• Lobby dispatch kiosks
• Upper-floor dispatch kiosks
• Turnstile-integrated dispatch
• Person Reader dispatch
• Mobile dispatch
• In-car destination terminals (where applicable)

Part 3 – Architecture, Resilience, And Redundancy

3.1 Redundant DDE Security Processing
A. All DDE security processors, integration servers, boards, or computing platforms shall be fully redundant.
B. Redundancy shall include:
• DDE security processors
• Dispatch integration services
• Network interfaces
C. Redundant components shall operate in automatic failover mode without operator intervention.

3.2 Single-IP OEM Constraint And Failover
A. Where elevator OEMs require communication from only one IP address, the system shall present a single, fixed IP address to the DDE system at all times.
B. Redundancy shall be achieved via:
• Network-level IP failover
• Dynamic IP ownership transfer between redundant processors
C. The elevator system shall never observe an IP address change during failover.
D. Failover events shall be logged, diagnosable, and testable.

3.3 Failover Performance
A. Failover shall occur within a defined threshold suitable for continuous elevator operation.
B. Elevator safety shall never be impacted during failover.
C. Dispatch may revert to configured fallback behavior if required.

Part 4 – Integration Modes And Credential Support

4.1 Dual Card-Reader Connectivity Models
The system shall support both:

A. Reader Connected To Security System
• Reader connected to access control
• Authorization performed by security system
• Authorized destinations transmitted to DDE

B. Reader Connected To Elevator System
• Reader connected to DDE
• Credential data forwarded to security system
• Authorization returned to DDE

Both models may operate concurrently.

4.2 Universal Credential Support
The DDE system shall support any credential, including:
• Facial recognition
• Voice recognition
• Name or identity lookup
• PINs
• QR codes
• Mobile credentials
• Apple Wallet credentials
• Google Wallet credentials
• Bluetooth credentials
• All common proximity card formats

Credential processing shall be policy-driven.

4.3 Visitor Credentials
A. Visitor credentials shall be supported, including:
• Pre-registered credentials
• QR-based credentials
• Temporary mobile credentials

B. Visitor credentials shall support:
• Default floor assignment
• Transfer floor logic
• Automatic expiration

Part 5 – Dispatch Interfaces And DDE Kiosks

5.1 DDE Kiosks – General
A. DDE kiosks shall be intelligent dispatch terminals, not passive button panels.
B. DDE kiosks shall be deployable:
• In lobbies
• On upper floors
• Integrated into turnstiles

5.2 Functional Parity With Person Readers
A. DDE kiosks shall provide full functional parity with Person Readers for all dispatch-related capabilities.
B. Capability shall not vary based on physical form factor.

5.3 Multi-Modal Identity
DDE kiosks shall support:
• Biometric recognition
• Voice interaction
• PIN entry
• QR scanning
• Mobile credentials
• Proximity credentials

5.4 Natural Language And Touchless Interaction
A. Users may request elevators using natural language.
B. Touchless operation shall be supported for hygiene and accessibility.

5.5 Turnstile-Integrated Dispatch
A. Turnstile kiosks shall:
• Authenticate identity
• Capture destination intent
• Initiate dispatch concurrently with entry

B. Dispatch shall coordinate with anti-passback and tailgating logic.

5.6 Intercom And Visitor Assistance
A. Kiosks shall support integrated intercom:
• Two-way audio
• Two-way video (where equipped)

B. Operators may assist dispatch remotely.

Part 6 – Floor Matrix And Dispatch Logic

6.1 Floor Matrix – Policy Engine
A. A Floor Matrix shall define:
• Which floors are accessible from each dispatch interface
• When floors are public or secured
• Offline behavior

B. Floor stops shall be treated as security objects.

6.2 Schedules And Offline Behavior
A. Schedules shall define secured vs public floors.
B. Offline behavior shall be explicitly configurable and auditable.

6.3 Default And Transfer Floor Logic
A. The system shall support:
• Default floor assignment
• Default floor override
• Transfer floor logic (multi-stage dispatch)

B. Identities may have multiple default floors based on:
• Location
• Kiosk type
• Visitor vs employee context

Part 7 – Operator Control And Monitoring

7.1 Real-Time Elevator Control
Operators shall be able to:
• Lock floors
• Unlock floors
• Temporarily release floors
• Apply schedules and overrides

7.2 Access Modes
Per-floor access modes shall include:
• Card only
• PIN only
• Card + PIN
• Card or PIN
• Two-card (escort) mode

7.3 Credential Simulation
Authorized operators may simulate credentials for testing without moving cars.

Part 8 – Diagnostics And Commissioning

8.1 DDE Diagnostics Tool
A. Built-in diagnostics shall provide:
• Real-time protocol monitoring
• System, bank, and converter views

8.2 Simulated Dispatch Testing
Diagnostics shall support:
• Simulated card swipes
• Default floor simulation
• Identity search and testing

8.3 Remote Troubleshooting
Diagnostics shall support commissioning and troubleshooting without on-site access.

Part 9 – Eventing, Audit, And Compliance

9.1 Dispatch Events
All dispatch actions shall log:
• Identity
• Origin
• Destination
• Assigned car
• Dispatch method
• Timestamp

9.2 Floor Matrix And Control Events
All configuration and override changes shall be logged and auditable.

Part 10 – Safety And Code Compliance

A. Elevator OEM safety systems shall always take precedence.
B. Security systems shall never impede emergency operation.

Part 11 – Acceptable Manufacturers

11.1 Basis Of Design
Managed through the Physical Security Management Platform with OEM-agnostic destination dispatch integration.

11.2 Acceptable Alternatives
Alternative systems shall meet all requirements of this specification.

End Of Section 28 35 00