Building Graph Event Routing for Holistic Subsystem Management
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current building management systems lack dynamic, scalable, and adjustable solutions for holistic management of building systems, as discrete predefined controlling systems operate independently without knowledge of the building's overall state.
Innovation Solution
A cloud-based building system that receives events from building equipment, enriches them with contextual data, and provides enriched events to consuming applications, utilizing schema matching, graph projections, and change feeds to facilitate holistic management and communication across building subsystems.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If discrete predefined controlling systems are used for each building subsystem, then each subsystem can operate independently with simple control logic, but the system lacks holistic management capability and cannot dynamically adapt to building-wide conditions
Solution Approach 1:
The patent merges discrete building subsystems into a unified event-driven architecture where all subsystems (HVAC, lighting, security, etc.) are integrated through a central event processing platform. This allows independent subsystem operation to be maintained while simultaneously enabling holistic building management through shared event context and cross-subsystem communication.
Solution Approach 2:
The patent creates a universal building management platform that handles multiple subsystem types through a single event processing architecture. The system uses schema-based event validation, graph database projections, and configurable event routing to provide multi-functional capabilities across diverse building subsystems, enabling adaptability without sacrificing operational simplicity.
2Adaptability or versatility
If a centralized system integrates all building subsystems for holistic management, then dynamic and scalable solutions can be achieved, but the system complexity increases significantly
Solution Approach 1:
The patent segments the centralized building management system into modular components: event sources generate events, a schema registry validates event formats, a graph database stores contextual relationships, an event processing engine enriches and routes events, and consuming applications execute actions. This segmentation reduces overall system complexity by making each component independent and manageable while maintaining holistic management capability.
Solution Approach 2:
The patent introduces an event-driven intermediary layer that mediates between building subsystems and management applications. Events serve as standardized intermediaries carrying information between subsystems, while the event processing engine acts as a mediator that enriches events with contextual data from graph projections and routes them to appropriate consuming applications, simplifying system integration.
3Loss of information
If events are enriched with contextual data from graph projections, then consuming applications can operate with better contextual understanding, but the event processing time and computational resources increase
Solution Approach 1:
The patent performs preliminary actions by pre-computing and storing contextual relationships in graph database projections before events arrive. The graph database maintains pre-established relationships between building entities (spaces, devices, occupants), allowing the event processing engine to quickly retrieve relevant contextual data without performing complex queries at event processing time, thus reducing latency.
Solution Approach 2:
The patent implements dynamic event enrichment by configuring which graph projections are applied to specific event types. The system dynamically selects and applies only the relevant contextual data needed for each event, avoiding unnecessary data retrieval and processing. This dynamic approach balances information completeness with processing efficiency based on event-specific requirements.
4Reliability
If schema validation is performed on incoming events, then data quality and consistency are improved, but events with unknown schemas may be rejected or require additional processing
Solution Approach 1:
The patent implements a schema registry that provides feedback mechanisms for schema evolution. When new event types or formats are introduced, the system can register new schemas in the schema registry, allowing the validation process to adapt to new event formats. This feedback loop maintains data consistency for known events while enabling acceptance of new event schemas through registered definitions.
Solution Approach 2:
The patent enables parameter changes in event schemas through the schema registry, which stores and manages evolving event format definitions. The system can modify schema parameters (data types, required fields, validation rules) to accommodate new event types from emerging building subsystems or updated devices, maintaining reliability through structured validation while adapting to changing requirements.
Data Source
AI summary
A building system of a building including one or more memory devices having instructions thereon, that, when executed by one or more processors, cause the one or more processors to receive a command to perform an action for an entity. The instructions cause the one or more processors to identify a service configured to perform the action based on a building graph, the building graph including a plurality of nodes and a plurality of edges, wherein the plurality of nodes represent entities of the building, the service, and one or more other services, wherein the plurality of edges represent relationships between the entities and communication actions of the service with the one or more other services and cause the service to perform the action by causing the service to perform one or more communication actions with the one or more other services indicated by the building graph.