Best Practices for Developing Solutions > Connecting Devices
Connecting Devices
ThingWorx Kepware Server enables communication for industrial automation and the industrial IoT. It is often used in production systems in discrete process batch manufacturing, oil and gas production and distribution, building automation, energy production and distribution, and more.
A few scenarios were observed in ThingWorx 9.4 and earlier versions, and Kepware 6.15 and earlier versions, where Remote Properties marked as Read from Edge show UNKNOWN quality and do not reflect the latest values from the device. The following scenarios were observed.
Scenario
Description
Platform Restart
When the platform restarts, it cannot read the start values from edge for remote properties that are marked as Read from Edge. This is due to no active web socket connections.
Edge/Kepware reconnects after disconnection
When the Edge/Kepware reconnects after a connection loss, it attempts to bind. This follows the pattern of binding as mentioned in Platform Restart (scenario 1). This occurs because no edge properties are read in the workflow.
RestartThing Service or Save from Composer
In this use case, the Thing is first marked as stopped. This causes it to lose bindings with the edge endpoint.
During the RestartThing method the ThingWorx Platform first binds to the existing endpoint and calls the notifyPropertyUpdate method. This edge calls GetPropertySubscriptions to get information about remote properties and bindings. This call may not succeed since the Thing may not have started. Some properties may get updated as a result of the calling readPropertyValueFromEdge.
Cold Start of Kepware
When Kepware starts for the first time on a system, it has no information about the property binding. After startup, Kepware connects to the ThingWorx Platform and binds to RemoteThings. Kepware then tries to synchronize the state based on property details fetched from the ThingWorx Platform. At the same time, Kepware also starts to get data from Industrial devices/hardware (i.e., PLC, SCADA, or DCS systems, etc.) During which, the ThingWorx Platform attempts to read properties before Kepware fetches its value from device. This may result in Data with UNKNOWN quality.
Fix Provided
The solution involves introduction of a new synchronous fetch mechanism for getting the current value of remote properties as well as reorganizing internal service calls so that it is only invoked when the Thing is in Running state.
A new service SynchronizeModelState is introduced. This service will be used by ThingWorx Platform to send model information like property subscription, event subscriptions, and so on. This service expects the current property values from Edge in return. This service also resolves the Thundering herd problem which can happen when the ThingWorx Platform starts or restarts or Remote Thing restarts.
When Edge reconnects, a new websocket connection is being established and a bind request is received. In this solution, Edge waits for the bind response to be sent to the client, and then execute the synchronous call to fetch current properties as well as trigger asynchronous request. The reason to wait for the bind to complete is to prevent a cyclic call and to prevent bind from blocking.
Two new properties are added to track state of synchronization between ThingWorx Platform and edge device. These two properties will be set after successful synchronization of the state of edge device with platform. These properties will be reset when the thing starts or stops, or edge device disconnects.
IsInitialStateSynchronized(Boolean) – if edge device is currently in sync with ThingWorx Platform or not.
lastInitialStateSynchronized(DateTime) – last time edge device synchronized its state with ThingWorx Platform.
Was this helpful?