Differences between Axeda Platform and ThingWorx Platform (eMessage Agents)
The following table highlights the major differences between Axeda Platform and ThingWorx Platform:
|
Axeda
|
ThingWorx
|
|---|---|
|
The Axeda Platform is edge-driven.
|
The ThingWorx Platform is platform-driven.
|
|
Axeda eMessage agents (Axeda Gateway and Axeda Connector) poll their target platform. The platform must wait until the asset contacts it before messages can be delivered to the agent asset.
|
Assets are considered to be contactable, without their having to poll the platform first.
|
|
Alarms
|
Alarms become properties with subscriptions.
|
|
Events
|
Events become properties with subscriptions
|
|
Expression rules
|
Properties of events that have subscriptions
|
|
Custom objects created using Groovy
|
JavaScript for developing applications
|
|
Axeda Console applications
|
ThingWorx Apps, including ThingWorx Asset Advisor
|
|
Extended applications (Java SDK, REST Web Services)
|
JavaScript, ThingWorx Composer, and ThingWorx Mashup Builder. ThingWorx Platform has a Java API and REST Web Services. There is an SDK for developing extensions for the platform.
|
To learn how to migrate your Axeda agents, contact your PTC representative. The following sections provide additional details about the differences between Axeda Platform and the eMessage Connector/ThingWorx Platform behaviors:
Mapping Axeda Terms to ThingWorx Terms
The following table maps some basic Axeda Platform terms to their ThingWorx and Axeda Compatibility Extension (ACE) equivalents, as appropriate. It also provides a brief description of each term.
Axeda | ThingWorx | ACE or RAE | Description |
|---|---|---|---|
Model | Thing Template | AxedaBaseModel Thing Template | Represents an abstract class of Things, as in “models” of vehicles. |
Asset | Thing | Axeda.Asset Thing Shape | Represents an actual device or implementation, as in the case of applications created using Axeda Builder for eMessage agent projects or written using a ThingWorx Edge SDK. |
Connector Agent | No equivalent | AxedaStandaloneModel Thing Template | The Axeda Connector agent for standalone assets. |
Gateway Agent | No equivalent | AxedaEmessageGatewayModel Thing Template and Axeda.EmessageGatewayModel Thing Shape | Represents an abstract device through which other devices are managed and through which they communicate with the Axeda Platform or with an eMessage Connector and a ThingWorx Platform. |
Managed Asset (behind a gateway) | No equivalent | AxedaManagedModel Thing Template and Axeda.Managed Thing Shape | Represents an abstract device that is managed by an Axeda Gateway agent and does not directly communicate with Axeda Platform or with an eMessage Connector and a ThingWorx Platform. |
Axeda Global Access Server | GASRemoteAccessProvider Thing — created when GAS registers with the platform. | GASModel Thing Template (ACE) RemoteAccessServer and RemoteAccessProvider Thing Shapes (RAE) | GAS is a server external to the Axeda or ThingWorx Platform that offloads remote session processing from the platform. |
The following diagrams depict the interaction and relationships among these entities. The first diagram shows a standalone Axeda agent (Axeda Connector) in ThingWorx through the ACE. The second diagram shows an Axeda Gateway device with managed devices. In these diagrams, the RemoteThingWithTunnelsAndFileTransfers is the ThingWorx Thing Template for remote devices whose agents (or applications) perform file uploads and downloads). This Thing Template provides two essential properties, isConnected (whether the device is communicating with ThingWorx) and lastConnected (the date and time that the device last communicated with ThingWorx).
Standalone Axeda Agent
Axeda Gateway Agent
Agent Registration
Agent registration is the same with Axeda Platform and eMessage Connector. The Axeda Platform completely ignores the time from the registration attribute and uses the current time to set the registration time. As of v.1.1.0, the eMessage Connector also ignores the registration timestamp specified by the agent and uses the current timestamp on the eMessage Connector computer to set the First Registration and Latest Registration properties.
Messages Destined for Axeda eMessage Agents
Messages destined for Axeda eMessage agents (“egress” messages) are not guaranteed to be delivered in the same order in which they were issued to the agent from ThingWorx. In addition, egress messages are not acknowledged to the ThingWorx platform. SOAPStatus updates are not used to acknowledge back to the ThingWorx Platform. Instead, they are dropped when the Axeda eMessage agent sends them back to the eMessage Connector.
Information in the Status Message
eMessage XML is incomplete and does not send specific information back to the agent in the status message. This did not appear to cause issues with the Axeda agents that were tested; it is just a difference between the Axeda Platform and the eMessage Connector.
Use of Identifiers
While ThingWorx supports the use of configurable identifiers for AlwaysOn Edge devices, eMessage Things cannot use this type of identifier. In Axeda, the “identifiers” for all assets are the unique combination of model number and serial number. In ThingWorx, these identifiers are defined in the properties, modelNumber and serialNumber. The eMessage Connector looks up an Axeda asset by looking for the model number and serial number that are passed in by an eMessage agent.
 | The eMessage Connector rejects any message, both from the ThingWorx platform (egress message) or from the agent (ingress message) for a Thing that has an identifier set. The Connector also generates an event on the Connection Services Hub, called UserError, when a message is detected for a Thing with an identifier |
SCM Download Instructions, Compression, and Permissions
By default, Axeda Platform uses tar.gz to archive and compress files in SCM Download packages before downloading the package. If desired, compression can be disabled through the SCM UI. The archiving of the file on Axeda Platform results in the extraction at the agent preserving the permissions assigned to the file before it was added to the tar.gz archive.
ThingWorx SCM does not provide an option to compress a file before download for Download Instructions. The result of downloading an uncompressed file to an Axeda agent is that read and write access are provided only to the user context of the user who started the agent.
If you need to retain the permissions to a file that you are downloading via an SCM package from a ThingWorx Platform, manually compress that file before adding it to the package. Then, when adding the Download instruction, select the Agent should uncompress this file after downloading check box.
Auto-Creation of Models, Assets, and Data Items
The default behavior of Axeda Platform is to automatically create models, assets, and data items when Axeda eMessage agents register with the Axeda Platform for the first time. ThingWorx Platform does not support this functionality.
Data Items
In ThingWorx, what Axeda calls “data items” are referred to as “properties”. If you are developing an application and want to test if data items are being received, go to the Properties page for the Thing that represents your asset. To write a new value to an existing property on the ThingWorx Platform, eMessage Connector uses the UpdateSubscribedPropertyValues service. This services processes updates for properties that are bound to the Thing representing the Axeda agent sset in ThingWorx.
Since data items are automatically created in Axeda Platform but not in ThingWorx, the UpdateSubscribedPropertyValues service logs an error to the Application Log and generates a notification event called PropertyWriteError if the target Thing or property (data item) does not exist in ThingWorx when a property write is attempted. The event provides the following information:
• name — the name of the data item (property) as a STRING
• time — the date and time that the property was sent (DATETIME)
• value — the value of the property (VARIANT)
• quality — the quality of the value (STRING)
You need to subscribe to this event to receive the notification.
Axeda Platform supports the type of a data item changing dynamically during its lifetime. ThingWorx does not support this change automatically. Instead, you need to change the definition of the property whose type you want to change.
In Axeda Platform writes of multiple data items, where one data item fails, cause the whole batch to fail. ThingWorx Platform does not behave in the same way - any failed writes cause only that property to fail.
The following table lists some scenarios related to ingress messages containing values for data items, individually or as a group, from two to multiple devices. It contrasts the behaviors of Axeda Platform to those of eMessage Connector and ThingWorx Platform in response to these messages.
Scenario | Axeda Platform Behavior | eMessage Connector / ThingWorx Behavior |
|---|---|---|
Registration and pre-provisioning. Two devices send in values for data items. The first device does not exist/has not registered. | Axeda Platform does not require any pre-provisioning of assets to accept ingress. However, a registration message must be the first communication from an agent. A status of 1 is returned. The values of the data items of the second device are written. Since this message is not a registration message, the data values of the first device are not written. | Registration is not required prior to accepting ingress in ThingWorx. However, the Thing must exist in the ThingWorx platform before the eMessage Connector can handle messages from it. eMessage Connector returns a status of 0. The values for the data items (properties) of the second device are written. |
Multiple devices in an eMessage message. The message contains a data item that is not configured on a device. | Axeda does not require pre-configuration of data items to accept values. A status of 0 is returned. The new data item is written to the device. All other devices are processed. | ThingWorx rejects a property write if the property does not exist on a Thing (device). eMessage Connector does not accept data items that do not exist on the Thing, so it drops the invalid data item and processes the others. . |
Invalid data type for one data item in a group of data items sent to the ThingWorx Platform. | Returns a status of 0. The invalid data item takes on a ? value. All other values are written. | In ThingWorx, it is not possible to write a value if a data item/property has an invalid value. In the same way as Axeda Platform, eMessage Connector writes the valid properties, but not the invalid one. The Connector generates an event, ProtocolError, and sends it to the Connection Services Hub. |
The value of one data item in a group of data items does not match the existing data type (on the ThingWorx platform). | Returns a status of 0. The data item with a mismatched type takes on the newly supplied type. All other values are written. | ThingWorx does not accept a data item with a type that differs from the type currently set on the corresponding property. eMessage Connector rejects the newly supplied type for the data item/property. |
Any ingress comes in with a blank name in one message, followed by additional messages for other devices. | Discards all messages for the device. Any messages for the other devices are processed. Returns a status of 0, with the change that any devices that encountered issues will have a separate status that includes the model and serial number. For successful messages, a single status of 0 is returned. | ThingWorx accepts blank values for properties (in an infotable). eMessage Connector writes with the values it receives and does not receive any notice that a failure occurred. This behavior includes alarms and events, which would cause a similar failure in Axeda, In ThingWorx, the alarm or event with a blank name is written. |
A file is uploaded by AssetA. AssetB uploads a file with the same name. What happens? | Saves different copies of the same file. | During file uploads, the ThingWorx Platform places files in a directory whose name is based on the name of the Thing that represents the asset. Therefore, a file from one asset will notoverwrite a file of the same name from another asset. However, if an asset uploads a file multiple times, the file for that asset is overwritten each time. |
Alarms and Events
Alarms and Events are inherent properties of assets on Axeda Platform. In ThingWorx they are simply represented as properties that are defined in the rows and columns of an entity called an infotable.
Historical values are collected by those properties being logged. Axeda Platform rejects an alarm or event that contains invalid information (a blank name for example). The eMessage Connector accepts an alarm or event that has a blank name as a property in an infotable because, in ThingWorx, properties of the Base Type INFOTABLE have no restriction against blank values.
 | Axeda Platform rejects an alarm or event message that has any illegal values (like the name field being blank). Currently, ThingWorx will write the blank value to the alarm field. |
In Axeda, an Alarm can have an associated file to be uploaded with the alarm through the use of the Asc/Ur xml fragment. Alarms are limited to a single associated file upload and with support for the parent Asc tag, file uploads from Alarm messages should function no differently than a normal upload request.
Ping Rate
In Axeda, every agent must perform a “ping” at a specified rate to let the Enterprise Server know that it is still online and able to connect to the server for purposes of send data item values and receiving data, files, and packages in egress messages. In ThingWorx, remote devices connect to the ThingWorx Platform, bind to it, updated property values on the Thing that represents the device, and receive egress data and events from the ThingWorx Platform. The device can then unbind and disconnect.
The “duty cycle” concept in the ThingWorx Platform and ThingWorx Edge SDKs allow developers to ensure a minimum amount of guaranteed connection time in a given period for their devices. For example, if the duty cycle of a device were set to 25 percent of every hour, the device is guaranteed to be connected to ThingWorx for at least 15 minutes of every hour. Those 15 minutes may or many not be consecutive, but in an hour’s time, the device will have been intermittently connected for at least 15 minutes to reconcile the difference between ping and a ping rate versus “bound time” per duty cycle, the Axeda Compatibility Extension (ACE) provides ThingWorx Thing Templates and Thing Shapes that allow Axeda customers to represent their Axeda eMessage agents on the ThingWorx Platform and track the lastConnected time of each Axeda device (lastConnected is a property defined in the Thing Templates for Axeda devices).