Patent Application
20240176631
This application claims priority pursuant to 35 U.S.C. 119(a) to Indian Application No. 202211068696, filed Nov. 29, 2022, which application is incorporated herein by reference in its entirety.
The present system and approach relate to integrated building management systems such as heating, ventilating, and air-conditioning (HVAC), lighting systems, VRF, and electric and mechanical types of equipment.
The present disclosure may relate to an onboarding wizard, that may automatically scan the network for devices, points, history, alarms, and schedules. Automatically, everything may get added based on metadata information exposed over the BACnet driver. Users can review the items discovered by an automated process and remove them if any items are not necessarily needed. Wizard may register the cloud connector to cloud IoT for pushing the data. Wizard may also apply tagging for the points and equipment, automatically based on the tag dictionary. By default, a tag dictionary may have all equipment and tags available for HVAC applications. If users need any customization, they may do it once and it take changes for all other jobs. Users may review the tags automatically applied and adjust them needed. If everything is fine, then one may go ahead and perform a sync of the asset model generated in the gateway to the cloud.
The system may consist of a creation of bare minimum tagging and asset model creation in the gateway as part of gateway onboarding. This model may get published to a cloud supervisor and get stored in a model store. Once the model is available in the cloud, asset modelling feature may allow a user, with privileges, to enhance the model by adding extra context about points and equipment based on name and description of points, devices, and so forth. The term “context” may have a several meanings in the present specification, depending upon its usage and topic of application. It may refer to content of the subject matter or term at hand or context (i.e., background, setting, situation and/or so on) of the subject matter or term
Asset modelling may automatically suggest an enhancement to tagging and the asset model based on available context. Users may be allowed to review and adjust accordingly. Once reviewed, users can publish the changes back to the model. Users may review the changes in the supervisor virtually instantly and make sure that everything is done correctly. Any changes needed to be applied in the gateway may be sent as a system command to the gateway. Automatically, the gateway may adjust the entities for the asset modelling performed in the cloud.
The present system and approach relate to integrated building management systems such as heating, ventilating, and air-conditioning (HVAC), lighting systems, VRF, and electric and mechanical types of equipment. In today's world, many of the HVAC and building management system (BMS) projects, jobs would be spread across multiple geographical locations. In BMS projects, each job site may consist of BMS Supervisor which can be connected to the plant controller and unitary controllers to control different kinds of equipment in HVAC system. Meanings of acronyms may be inferred herein by their context and/or art of usage.
The system may relate to an onboarding wizard, that can automatically scan the network for devices, points, history, alarms, and schedules. Automatically everything may get added based on metadata information exposed over the BACnet driver. Users may review the items discovered by an automated process and remove them if any items are not necessarily needed. Wizard may register the cloud connector to cloud IoT for pushing the data. Wizard may also apply tagging for the points and equipment, automatically based on the tag dictionary. By default, a tag dictionary may have all equipment and tags available for HVAC applications. If users need any customization, they may do it once and it can take those changes for all other jobs. Users may review the tags automatically applied and adjust them needed. If everything is fine, then it may go ahead and perform a sync of the asset model generated in the gateway to the cloud.
The system may consist of a creation of bare minimum tagging and asset model creation in the gateway as part of gateway onboarding. This model may be published to a cloud supervisor and get stored in a model store. Once the model is available in the cloud, an asset modelling feature may allow a user, with privileges, to enhance the model by adding extra context about points and equipment based on name and description of points, devices, and so forth. Asset modelling may automatically suggest an enhancement to tagging and the asset model based on available context. Users will be allowed to review and adjust accordingly. Once reviewed, users may publish the changes back to the model. Users may review the changes in the supervisor virtually instantly and make sure that everything is done correctly. Any changes needed to be applied in the gateway may be sent as a system command to the gateway. Automatically, the gateway may adjust the entities for the asset modelling performed in the cloud.
The building management system may provide access and control to every area and process of your building infrastructure. Three types of BMS supervisor deployment landscape may exist based on the size and footprint of the site. This may include single site, multi-site, and cloud-based deployment models.
Following are issues that may exist in current BMS onboarding for getting a cloud supervisor setup. Users may need to manually setup the different drivers in the gateway. For e.g., in Niagara JACE, users should add and setup BACnet, Modbus, Fox driver, and/or so on.
A Fox driver may manually discover devices and add points, history, schedules, and alarms. During point adding, users may need to choose the point type and make it writable. This current manual onboarding steps for a site having 1500 points may take up to two to three days of work for a system integrator. Currently, onboarding steps should be done on the end customer site which adds extra money. There appears no consistent user experience across products from onboarding to getting the cloud supervisor running.
The system may be used across BMS projects such as a remote building manager, SaMBa supervisor, common supervisor, and so on. The system may solve simplified and intuitive methods for onboarding a gateway to a cloud supervisor. The gateway onboarding wizard may be optimized for a BACnet protocol. Gateway onboarding may also be performed by a non-Niagara expert.
There may be an onboarding wizard with automated onboarding of HVAC controllers to a cloud. It may discover and add items such as points, alarms, history, and schedules from controllers without any user intervention. There may be automated tagging of points and equipment, an intuitive and easy process for onboarding, and a reduction in onboarding time for a site.
How to make and use the present system and process may be noted. There may be a station running the JACE gateway. This may be a default station that has a service and UX wizard available for assisting the onboarding. The onboarding wizard may run through a series of steps. A first step is to select an environment subject to a General Data Protection Regulation or not subject to such an area. A second step may be a network configuration that will automatically verify internet connectivity once configured. Upon verifying Internet connectivity, a user may be prompted to continue with the wizard (BACnet protocol) or a Niagara expert mode (Workbench view for Modbus, Fox Protocol). Continuing with the Wizard, a third step is to configure a BACnet network. Once configured, the BACnet network may automatically scan the network for devices, points, history, alarms, and schedules. Automatically, everything may get added based on metadata information exposed over the BACnet driver. This may help in setting all configurations without a need for manual intervention thereby reducing the onboarding time. Users may review the items discovered by an automated process and remove them if any items are not needed. Once removed and marked, next time, it will not necessarily include the items.
A fourth step may be that the wizard registers the cloud connector to a cloud IoT for pushing data. The wizard may also apply tagging for the points and equipment automatically based on a tag dictionary. By default, the tag dictionary may have all equipment and tags available for HVAC applications. If users need any customization, they may do the customization once and take those changes of the customization for all other jobs.
A fifth step may be where users can review the tags automatically applied and adjust them if needed. If everything of a review is acceptable, then the wizard may go ahead and perform a sync of an asset model generated in the gateway to the cloud. The present system may be used across BMS projects such as remote building manager, SaMBa, Supervisor, Common Supervisor, and so forth.
The present system does have a software component. It may be a stack level: gateway/control for control, management, administration, operations and data consolidation applications, or a translation layer between a local environment and cloud enabling communication.
The system may have a software type connected/connectivity as an offering available through a cloud or a direct, remote connection (SaaS) or it may cover infrastructure enabling connected services (Sentience). It may use an IoT that is a stack level of a cloud having a secure, scalable infrastructure for collecting, aggregating and storing data, allowing connected “things” to communicate, offering/SaaS solution available, IaaS/PaaS, and data lakes.
The system may generate or capture data having a type of model based auto tagging point sync-up with a cloud. For instance, the data may be that of a HVAC sensor.
Systems and methods for remote asset modelling and tuning for a cloud supervisor may be noted. Critical subsystems of a building may include heating, ventilation and air-conditioning (HVAC) control, lighting control, systems energy management load shedding, UPS, elevator and escalator control systems, miscellaneous building systems including pumps, sumps, and so forth.
A BMS supervisor may save you money on operating costs while protecting your property, buildings and assets. The BMS supervisor may provide access and control of every area and process of your building infrastructure. Many of the BMS supervisors may have intuitive, easy to understand, easy to use, and effective graphics pages which make it easy for building maintenance staff to operate and maintain the site. Mainly end customers may interact with the BMS supervisor using points, history/trends, alarms and schedules.
There may be three types of BMS supervisor deployment landscapes that exist, based on the size and footprint of the site. They may include single site, multi-site and cloud based deployment models. In a single site, standalone deployment, a BMS supervisor may be installed on a premise in a customer location either as an embedded supervisor or installed on a PC, which will relate to controllers and field devices. In a large site, multi-site deployment may be a scalable solution for a data center and other big jobs in which data are maintained on a premise in a customer hosted or service provider hosted data center. In a cloud based deployment, a complete supervisor may be hosted in a cloud which will be connected to on premise systems in customer locations.
Following are the issues that may exist in the current BMS gateway onboarding for getting a cloud supervisor setup. Tagging may be used in a cloud supervisor for getting context about an asset model. During gateway onboarding, based on points and devices, points and equipment may get tagged. Based on these tags, the asset model may get created in a gateway and get pushed to a supervisor in the cloud.
Users should review the model and tags in the supervisor and adjust the tags in the gateway again and resync, once the changes done. Many times, this system tagging may take multiple rounds to and from changes which can take days. Users should be on site for performing these model changes. If any changes are needed or desired later, users should travel back to the site. Automated tagging, based on context of point names, description name, device name, description and so forth, may be only available in the gateway and not necessarily be possible to adapt in a cloud.
The present system may be used across BMS projects such as remote building manager, SaMBa supervisor, common supervisor, CEMS, and so forth. There may be automated tagging of points and equipment in the cloud. One may get context automatically from related entities such as a point and device name, description, and so on. The asset model may be easily enhanced by applying templates for a site which does not have any naming convention. There may be automatic adjustments of entities and relationships in the gateway when the asset model changes are done in a cloud. A process for adjusting the asset modelling from cloud may be intuitive and easy. Onboarding time for a site may be reduced.
A solution may consist of a bare minimum tagging and asset model creation in the gateway as part of gateway onboarding. This model may get published to a cloud supervisor and get stored in the model store. Once the model is available in the cloud, an asset modelling feature may allow a user, with privileges, to enhance the model by adding extra context about points and equipment based on name and description of points, devices, and so on.
Asset modelling may automatically suggest enhancement to tagging and an asset model based on available context. Users may be allowed to review and adjust accordingly. Once reviewed, users can publish the changes back to the model. Users may review the changes in a supervisor instantly and make sure that everything is done correctly. Any changes needed to be applied in the gateway may be sent as a system command to the gateway. Automatically, the gateway may adjust the entities for the asset modelling performed in the cloud. This approach may reduce the time needed in the site and it should be possible to load a site having up to 5,000 points within one hour compared to earlier multiple days of work needed for the same number of points.
The present system may be used across BMS projects such as remote building manager, SaMBa, supervisor, common supervisor, and so on.
All BMS controllers and south bound devices will be connected through a gateway to a Forge™ IOT and then to a cloud supervisor. In the cloud supervisor, there may be a service which will read data from a history and the gateway to show a single dashboard of virtually all points and related information. System architecture and design details may be noted.
A simple generic model in gateway may be built in following format.
{
“createdAt”: “2021-05-03T11:49:57.859+05:30”,
“createdBy”: “00000000-0000-0000-0000-000000000000”,
“id”: “d467f98c-1512-4e61-b804-47ba753e3cc7”,
“siteId”: “57ba1fbc-b299-481b-ba1a-91dc1bbdaa72”,
“updatedAt”: “2021-05-03T11:49:57.859+05:30”,
“updatedBy”: “00000000-0000-0000-0000-000000000000”
“createdAt”: “2021-05-03T11:49:50.080+05:30”,
“createdBy”: “00000000-0000-0000-0000-000000000000”,
“customAttributes”: {“gatewayType”: “{\“value\”:\“Niagara\”}”},
“ExternalId”: “4f9b3336-3dd0-4c02-b6b0-069f10a40775”,
“GatewayId”: “a6b7797c-7b9a-41d5-819d-678f6f3e4e9b”,
“SystemGuid”: “75e70ebf-0fb8-4036-9c89-a6bb2e5e1db6”
“id”: “4f9b3336-3dd0-4c02-b6b0-069f10a40775”,
“siteId”: “57ba1fbc-b299-481b-ba1a-91dc1bbdaa72”,
“updatedAt”: “2021-05-03T11:49:50.081+05:30”,
“updatedBy”: “00000000-0000-0000-0000-000000000000”
“createdAt”: “2021-05-03T11:49:49.397+05:30”,
“createdBy”: “00000000-0000-0000-0000-000000000000”,
“customAttributes”: {“gatewayType”: “{\“value\”:\“Niagara\”}”},
“ExternalId”: “a6b7797c-7b9a-41d5-819d-678f6f3e4e9b”,
“GatewayId”: “a6b7797c-7b9a-41d5-819d-678f6f3e4e9b”,
“SystemGuid”: “75e70ebf-0fb8-4036-9c89-a6bb2e5e1db6”
“id”: “a6b7797c-7b9a-41d5-819d-678f6f3e4e9b”,
“siteId”: “57ba1fbc-b299-481b-ba1a-91dc1bbdaa72”,
“updatedAt”: “2021-05-03T11:49:49.398+05:30”,
“updatedBy”: “00000000-0000-0000-0000-000000000000”
“createdAt”: “2021-05-03T11:49:50.878+05:30”,
“createdBy”: “00000000-0000-0000-0000-000000000000”,
“categories”:
“historyLocation”:
“{\“value\”:\“history$3a$2f$2fmobilesupdemo1$2fot1
—
first
—
floor
—
fcul$242e5$2420setp
oint\”}”,
“isWritable”: “{\“value\”:\“true1”}”,
“max Value”: “{\“value\”:\“25.00\”}”,
“minValue”: “{\“value\”:\“15.00\”}”,
“precision”: “{\“value\”:\“\”}”,
“stepSize”: “{\“value\”:\“1\”}”
“entityId”: “4f9b3336-3dd0-4c02-b6b0-069f10a40775”,
“entityType”: “Element”,
“GatewayId”: “a6b7797c-7b9a-41d5-819d-678f6f3e4e9b”,
“SystemGuid”: “75e70ebf-0fb8-4036-9c89-a6bb2e5e1db6”
“id”: “4cdab4d1-b9f4-4c5a-8acd-2efb8f9bb2a8”,
“updatedAt”: “2021-05-03T11:49:50.879+05:30”,
“updatedBy”: “00000000-0000-0000-0000-000000000000”
“createdAt”: “2021-05-03T11:49:51.016+05:30”,
“createdBy”: “00000000-0000-0000-0000-000000000000”,
“categories”:
“historyLocation”:
“{\“value\”:\“history$3a$2f$2fmobilesupdemo1$2ffcu1$242e5$2420occupancy$2420sen
sor\”}”,
“isWritable”: “{\“value\”:\“false\”}”,
“max Value”: “{\“value\”:\“\”}”,
“minValue”: “{\“value\”:\“\”}”,
“precision”: “{\“value\”:\“\”}”,
“stepSize”: “{\“value\”:\“1\”}”,
“summarySupports”: “{\“value\”:\“false\”}”
“entityId”: “4f9b3336-3dd0-4c02-b6b0-069f10a40775”,
“GatewayId”: “a6b7797c-7b9a-41d5-819d-678f6f3e4e9b”,
“SystemGuid”: “75e70ebf-0fb8-4036-9c89-a6bb2e5e1db6”
“id”: “924da9d5-3fd3-4bdc-afd4-9247762d38c9”,
“updatedAt”: “2021-05-03T11:49:51.016+05:30”,
“updatedBy”: “00000000-0000-0000-0000-000000000000”
“createdAt”: “2021-05-03T11:49:50.562+05:30”,
“createdBy”: “00000000-0000-0000-0000-000000000000”,
“customAttributes”: {
“categories”:
“historyLocation”:
“{\“value\”:\“history$3a$2f$2fmobilesupdemo1$2ffcu1$242e3$2420room$2420tempera
ture\”}”,
“isWritable”: “{\“value\”:\“false\”}”,
“maxValue”: “{\“value\”:\“\”}”,
“minValue”: “{\“value\”:\“\”}”,
“precision”: “{\“value\”:\“\”}”,
“stepSize”: “{\“value\”:\“1\”}”
“entityId”: “4f9b3336-3dd0-4c02-b6b0-069f10a40775”,
“GatewayId”: “a6b7797c-7b9a-41d5-819d-678f6f3e4e9b”,
“SystemGuid”: “75e70ebf-0fb8-4036-9c89-a6bb2e5e1db6”
“id”: “19b5ac25-3084-4ec1-a525-c38b9028656e”,
“updatedAt”: “2021-05-03T11:49:50.562+05:30”,
“updatedBy”: “00000000-0000-0000-0000-000000000000”
Generation of a building ontology model may be noted. The building ontology model may be used in most of a building is as shown. The ontology model may be built based on the building data in a model store.
Organization hierarchy may be looked at. a data model and each sub system including equipment information may be generated and stored in a data base. The overview of model schema may be stored in a model store. Automated equipment modeling may be looked at.
As to workflow, following is applicable.
Point tagging in a supervisor may be noted.
How to make and use the present system may be noted. The system may be used across BMS projects such as a remote building manager, SaMBa supervisor, common supervisor, and so on.
The following may be features of the present system.
A set of
Within services 24 may be a connection between calendar service 25 and an alarm configuration service 26. A connection may be from service 26 to sync service 28. A model service 27 may be connected to a model wrapper service 29. Within services 24, there should be an update of the needed entities sent as a part of a sync model. A message broker 31 may have a crud events connection with services 24, a site lock event connection to services 24, a site lock event connection from sync service 28 and a crud events connection to sync service 28. A brand specific tool 32 and a web browser 33 may be connected with sync service 28.
A read file connection may be between device communication service 34 and sync service 28 and model wrapper service 29. A file upload event connection is between message broker 35 and sync service 28. A connection may exist between device communication middleware 36 and message broker 35. Device communication middleware 36 may be connected with device communication service 34.
Model wrapper service 29 may have a model sync connection with model API 37 in EOM 39. A storage device 38 may be connected with model API 37 in EOM 39.
Middleware 36 may be a connection with IoT and services 41, for file upload event/system commands. A file upload/configuration update command connection may be between services 41 and gateway 42 and gateway 43. A connection may be between gateway 42 and web browser 33. Gateway 42 may have connections to controllers 44 and 45. Gateway 43 may have a connection to controller 46.
One may go first with a BACnet wizard option. Shown by block 53 revealing a BACnet gateway configuration using a BACnet protocol. If BACnet is shipped, these may be a dialogue box about the consequences of such decision which follows a dashed line to a block 56 representing a cloud connector. Going with BACnet at block 53 results in going to block 57 for BACnet discovery. A feature is the auto discovery. An output from a discovery block 57 may go cloud connector block 56. Features at block 56 may be a license summary and easy cloud registration. Block 58 is a summary indicating model based auto tagging, point sync-up with a cloud, and schedule management.
An alternate decision at symbol 54 may be a Niagara Expert Mode which may have a protocol of BACnet, Modbus or Fox. One may go into a dialogue box on a Niagara workbench. At decision symbol 61, a question may be whether the mode is configured or not. If an answer is yes at symbol 61, then cloud connector 56 with the above-noted features may be incurred. Following that, the summary 58 may occur with its above noted features.
If an answer at decision symbol 61 is no configuration, then a Niagara workbench in symbol 62 may apply starting with a manual device configuration at symbol 63. From symbol 63, discovery of symbol 64 may take place with a signal back to the wizard of cloud connection 56. An output from discovery at symbol 64 may go to a decision at symbol 67 for easy onboarding service to block 52 of the welcome screen.
A spatial element block 111 may be connected to node block 110. A connection may be made from element block 106 to spatial element block 111. A schedule resource block 112 may be connected to mode block 110, element block 106 and spatial element block 111. A connection from node 110 may be made to model store block 113. Model store 113 may store the model ID and create a gateway under the same to set the storage retention policies. A connection may proceed from property 108 to mode block 110 and to spatial element block 111. Mandatory properties in property block 108 are indicated in bold type and/or a dot at the end of the label.
Blocks to the right of diagram 105 may indicate various constants. Block 115 may list entity type of spatial element, element, node, alarm, property, and calendar. Block 116 may list spatial element types of building, building store and zone. Block 117 may list element types of device, equipment, gateway, smart IQ, thermostat, RTU, AHU, VAV, sensor, lighting and VRF. Block 118 may list data source types of measured, calculated and virtual. Block 119 may list a property type of a data point. Block 120 may list a signal direction type of input, output and control parameter.
As a line 135 from gateway 126 to itself, there may be a process system command and update of the model with new data. As a line 136 from gateway 126 to itself, there may be a monitor for further system commands for the next configured time, and if there are no more system commands coming, then a model sync may be initiated.
A sync service 138 may be noted. A line 139 up-dating a model may go from sync service 138 to model service 123. A line 140 may indicate to read model data, from sync service 138 to device comm service 124. A line 141 from device comm service 124 to MV day comm service 125, may indicate to read model data. A line 142 from MW day comm service 125 to symbol 143, may indicate read model data. A line 144 that runs from gateway 126 through symbol 143 may indicate a file upload, and go on to MW day comm service 125. A line 145 from MW day comm service 125 to sync service 138 may indicate to file the upload event.
To recap, an approach of an onboarding wizard may incorporate a first step configured to select an area or environment for application of a wizard, a second step configured for the wizard to automatically verify internet connectivity of a network, a third step configured to continue with the wizard to narrow the network within a protocol selected from a group comprising a BACnet protocol, a Niagara expert mode, Workbench view for Modbus, and Fox Protocol, a fourth step configured for the wizard to register a cloud connector to a cloud IoT for pushing data, and a fifth step configured to permit a user review tags automatically applied, and to adjust them as needed.
As an area or environment of application of the wizard may be to select a US or EU area or environment subject to a General Data Protection Regulation (GDPR) or select an area or environment not subject to the GDPR.
Upon verifying internet connectivity at the second step, a user may be prompted to continue with the wizard of the BACnet protocol, a Niagara expert mode, Workbench view for Modbus, or Fox Protocol.
Once configured after the third step, the specific network may automatically scan the network for devices, points, history, alarms, and schedules. Automatically, each scanned item may get added based on metadata information exposed over the specific network driver, which helps in setting configurations without a need for manual intervention thereby reducing the onboarding time. A user may review the items discovered by an automated process and remove any unneeded items. Once an item is removed, a subsequent review will not necessarily include the removed item.
The approach may further incorporate applying tagging for points and equipment automatically based on a tag dictionary. By default, the tag dictionary may have tags and equipment available for HVAC applications. If a user needs a customization, the user may do the customization once and take the change or changes of the customization for another job.
If the steps occur satisfactorily, then the wizard may go ahead and perform a sync of an asset model generated in the gateway to the cloud. The present approach may be used across building management system (BMS) projects of one or more items of a group comprising a remote building manager, small and medium building administrator (SaMBa), supervisor, and common supervisor.
A wizard based gateway onboarding to a cloud, may incorporate an environment of a designated social political area, and a network configured to automatically verify internet connectivity, and configured to automatically scan the network for items incorporating devices, points, history, plans and schedules. The items that are scanned may get added based on metadata information exposed over the network driver.
An item getting added may avoid a need for manual intervention.
The wizard based gateway onboarding to a cloud may further incorporate a cloud connection registered by the wizard to a cloud IoT for pushing data points and equipment tagged by the wizard based on a tag dictionary.
Automatically based on the tag dictionary, tags and equipment may be available for points and HVAC applications.
The wizard based gateway onboarding to a cloud may further incorporate reviewing tags automatically applied, and adjusting them as needed.
The wizard may perform a sync of an asset model generated in the gateway to the cloud.
A building management system (BMS) onboarding gateway process may incorporate gateway onboarding, and tagging used in a cloud supervisor for getting context about an asset model. During onboarding based on points and devices, points and equipment may get tagged. Based on tags, an asset model may be created in a gateway. The asset model may get pushed to a cloud supervisor. The asset model and tags in the supervisor may be reviewed. The tags may be adjusted in the gateway and resynced. A gateway's automatically adjusting entities for asset modeling performed in the cloud, may cause onboarding time to load a gateway to decrease by at least a magnitude.
Automated tagging based on context of point names, description names, device names, and description may be available in the gateway.
There may be automated tagging of points and equipment in the cloud.
Context may be obtained automatically from related entities selected from a group comprising point and device names, and descriptions. The asset model may be enhanced by applying templates for a site without a naming convention.
Automatic adjustments of entities and relationships in the gateway may occur when changes of the asset model are done in a cloud.
A minimum tagging and creation of the asset model in the gateway may be part of gateway onboarding. The asset model may be published to a cloud supervisor and get stored in the model store. When the asset model is available in the cloud, an asset modeling feature may allow a user with privileges to enhance the asset model by adding extra content about points and equipment based on name and description of points, and devices.
Asset modeling may automatically suggest enhancement to tagging and an asset model based on available context. Users may accordingly adjust review. Once reviewed, changes may be published back to the asset model. Changes may be reviewed immediately to assure virtually everything is correct. Any changes needed to be applied in the gateway may be sent as a system command to the gateway.
A gateway's automatically adjusting entities for asset modeling performed in the cloud, may cause onboarding time to load a gateway to decrease at least ten times, ninety percent, or other amount.
Any publication or patent document noted is hereby incorporated by reference to the same extent as if each publication or patent document was specifically and individually indicated to be incorporated by reference.
In the present specification, some of the matter may be of a hypothetical or prophetic nature although stated in another manner or tense.
Although the present system and/or approach has been described with respect to at least one illustrative example, many variations and modifications will become apparent to those skilled in the art upon reading the specification. It is therefore the intention that the appended claims be interpreted as broadly as possible in view of the related art to include all such variations and modifications.
| Number | Date | Country | Kind |
|---|---|---|---|
| 202211068696 | Nov 2022 | IN | national |
