How does BrightCore compare with the conventional and exiting solutions?
Some vendors are representing established silo structures. Moreover, we were not able to locate a lot of offering of the free open development kit. Therefore, an independent developer who generally develops universal independent applications usable regardless of the protocol structure in the automation and IoT eco-system cold use BrightCore as one of the interfaces to the underlying networked devices regardless of application protocol used. Furthermore, we were not able to locate anyone with Multiprotocol Commissioning tool with simply open integration space to all of these application protocols, third-party applications, and multi-facility environment.
Gateway approach in talking remotely to the buildings obscures what is really happening at the level of facility network. The networks stay closed as if behind a curtain, and if any problem were at the communication layer, it would be seen when something definitely goes wrong. Therefore, it is not possible to address the root cause; rather the result of malfunction is addressed. However, this approach is always more expensive than treating the root cause. By contrast, BrightCore opens space for Dynamic Fault Detection at both levels, process as well as the network communication level. One of the BrightCore main properties is allowing the control managers to enter the system remotely, at the device level. As the need arises, the control managers can conduct the necessary distance diagnostics in all of the protocols regardless of the facility location... By contrast, other approaches are generally again locking mechanisms for vertical silos automation vendors, just in bigger scale. Any third party application is hardly available at the open market.