Unified API Routing for Multi-Manufacturer Elevators, Escalators, and Gates
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current elevator and escalator APIs are manufacturer-specific, requiring users to develop and maintain multiple systems for different manufacturers, leading to complex, time-consuming, and expensive integrations, and limiting maintenance capabilities across competitor equipment.
Innovation Solution
A unified application programming interface (API) system that translates and processes requests and responses between different elevator, escalator, and access gate systems, allowing integration and control through a single interface regardless of manufacturer.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If manufacturer-specific APIs are used for elevator and escalator systems, then each manufacturer can control their own equipment, but users must develop and maintain multiple different solutions for different manufacturers, increasing device complexity and integration difficulty
Solution Approach 1:
The patent introduces a universal API gateway or intermediary layer that sits between external systems and multiple manufacturer-specific elevator/escalator systems. This gateway translates and routes requests to the appropriate manufacturer's API, allowing external systems to interact with different manufacturers through a single standardized interface without needing to implement multiple different solutions
Solution Approach 2:
The patent creates a universal API framework that can handle requests for multiple manufacturers and equipment types (elevators, escalators, access gates) through a single interface. This universal API performs multiple functions by dynamically routing to different provider-specific implementations based on the target system identification
2Adaptability or versatility
If multiple manufacturer-specific APIs are implemented, then integration with different equipment is possible, but the integration process becomes complex, time-consuming and expensive
Solution Approach 1:
The universal API gateway acts as a pre-configured intermediary that handles all communication protocols and translation logic. Integrators no longer need to spend time learning and implementing multiple different API protocols for different manufacturers, as the gateway abstracts these complexities away and provides a single standardized interface
Solution Approach 2:
The patent implements preliminary configuration where the universal API gateway is pre-programmed with knowledge of multiple manufacturer-specific protocols and translation rules. This preliminary setup eliminates the need for time-consuming real-time integration work, as the gateway is already configured to handle various manufacturer formats before the integration process begins
3Adaptability or versatility
If manufacturers provide maintenance services for competitor equipment, then service coverage is expanded, but control and data reception becomes challenging due to unknown communication protocols
Solution Approach 1:
The universal API gateway serves as an intermediary that maintenance personnel can use to communicate with equipment from any manufacturer. The gateway handles protocol translation and data format conversion, so maintenance staff only need to know a single standardized interface while the gateway manages the complexity of communicating with different manufacturer protocols
Solution Approach 2:
The patent creates a standardized copy or abstraction layer of the manufacturer-specific protocols through the universal API gateway. This standardized interface copies the functionality of multiple manufacturer APIs while simplifying the interaction model, allowing maintenance personnel to access competitor equipment through a familiar, consistent interface without needing to learn each manufacturer's specific protocol
Data Source
AI summary
An arrangement, a people conveyor and/or an access gate system and a method for handling people conveyor and/or access gate system application programming interface requests, includes receiving a request through a primary people conveyor and/or access gate system application programming interface, determining the target system of the request, based on the identified target system of the request being a first provider people conveyor and/or access gate system, sending the request, e.g. without processing, to an application programming interface of the first provider people conveyor and/or access gate system, and based on the identified target system of the request being a second or further provider people conveyor and/or access gate system, processing the request and sending the processed request to an application programming interface of the second or further provider people conveyor and/or access gate system and/or a controlling interface of the second or further provider people conveyor and/or access gate system.