Getting started with DCM - Schneider Electric EcoStruxture (Machine Advisor)

Introduction

The Schneider Electric EcoStruxure Machine Advisor can be used as a DCM dataserver. The following guide describes how to setup simulated functions and send data to the Machine Advisor cloud.

Prerequisites

• SiteManager Hardware with DCM capabilities
• The SiteManager firmware must be version 9.0 or higher.
• An active account on EcoStruxure Machine Advisor .

EcoStruxure Machine Advisor setup

1.1. Configure machine
Go to menu Fleet and select the machine you want to configure and click on the “Monitor” button.

Note the server url and authentication-header from the “monitor-configuration” screen:
Make sure you select the “Charlie” format and “HTTPs” as Transport.

DCM configuration

2.1. Add Machine Advisor server auth
Login to the SiteManager GUI and select DCM > Certificates. Click New to create a new entry.

Select “Schneider Electric Machine Advisor Authentication (Header2)” in the dropdown selection, and give et a name, fx “semaauth”. Click on the certificate and paste the content from the Header2 field obtained in section 1.2 Configure machine . Then, click save.

Click New and select “Schneider Electric Machine Advisor Server URL” in the dropdown selection, and give et a name, fx. “semaurl”. Click on the certificate button and paste the content from the Server field i n section 1.2 Configure machine . Then, click save.

You should now see two entries in the certificate storage:

2.2. Configure DCM
Go to menu DCM > Edit and add a Dataserver to the configuration. If you don’t have a running DCM configuration, refer to Appendix A – Example DCM configuration for a sample configuration using simulated values.

In the Dataserver object, you have to adjust the paramterers of the SemaServer object to match the entries you created earlier in section 2.1 Add Machine Advisor server auth

When are done adjusting the configuration, click “Save”. If the configuration is valid, the DCM will restart and use the newly created configuration.

Validate data being send to the Dataserver by observing the DCM > Status page > Details.

Look for the time of last successful communication and number of reported values. This will tell you when and how many values, the DCM has send data to the dataserver.

Appendix A – Example DCM configuration

Now it's time to learn more about the DCM config file and how to set it up for your devices:

JSON config file basic structure

{
"ConfigDescription": "Configuration for sending Simulation data to Schneider Electric Machine Advisor",
"ConfigName": "Sematest",
"CheckpointInterval": 600,
"Collectors": [
    {
        "CollectorName" : "sim",
        "CollectorDescription" : "DCM Internal Simulation Server",
        "Protocol"   : "Simulator",
        "SamplePoints" : [
            {
                "SampleName" : "counter",
                "SampleDescription" : "DCM simulation of counter",
                "SamplesSaved" : 300,
                "SampleDataType" : "uint32",
                "SimulatorData" : {
                    "SimulatorFunction" : "counter",
                    "SimulatorInitValue" : 20,
                    "SimulatorIncValue" : 2,
                    "SimulatorSampleInterval" : 2
                }
            }
        ]
    }
],
"DataServers": [
    {
        "DatasrvName" : "sema_advisor",
        "DatasrvProtocol" : "SEMA/REST",
        "ConnectRetryMax": 240,
        "ConnectRetryMin": 30,
        "SemaParams": {
            "URLName" : "semaurl",
            "AuthName" : "semaauth",
            "PushInterval" : 1
        }
    }
]
}

Limitations using Machine Advisor with DCM 

The SEMA use a basic HTTPS JSON post principle for data delivery, and thus have some limitations compared to other typical clouds, such as AWS, Azure, Cumulocity etc. where handshaking and other data integrity assurance measures are handled. The constraints of SEMA also restrict DCM to perform as designed in terms of assurance of data delivery and resilience against communication outages:

Summarized the constraints of SEMA that affect DCM are:

• All messages are replied with HTTP 204, regardless of whether a message is accepted or not. Thus data is silently dropped on error. (No flowcontrol).
• Limit of 256KB for a message, based on constraints of the Azure quota.
• Will not accept data older than 15 days in the past (UTC)
• Will not accept data more than 15 min in the future (UTC)
• Not more than 500 variables per message (further restricted for lower payment plans)
• Max 60 messages / minute per device
• The data format (called Charlie) allows for only 1 value/timestamp for each sample per message, and only samples with same "assetName".

The latter means 60 messages of the same sample per minute, but the same message cannot contain the same sample name in a message. This is due to SEMA using the JSON object type (instead of the appropriate JSON Array type), which specifies each samplename separately as a fieldname, which will make SEMA only use the last value of the same tag in the message. This is a design limitation of SEMA.

These limitations means that to mitigate the loss of data incurred, the DCM configuration must follow some rules:

1. Sample interval for any sample sent to Schneider Electric Machine Advisor must be 2 seconds or larger.
2. The pushinterval for a dataserver of type "SEMA/REST" must be set at 1 sec. (More precisely: Must be half of the smallest sample interval).

Since the rate limit is calculated on messages per minute (and not number of sample values), the way DCM pack the sample values into messages influences this calculation.

DCM's default configuration will set the "assertName" to the collector name of the samples in the message, so the more collectors are involved in the samples reported, the more messages are sent, thus lowering the delivery rate for samples. This can only be mitigated by increasing sample intervals.

There is also the possibility to use another "assetName", (fx. The Appliance Name) to make all samples group under the same "assetName", but it is unknown, how or if SEMA uses the "assetName" for anything else that a name prefix in the GUI.

Since the rigid rate limit does not account for connection outage, it can be very hard for DCM to ever "catch up" again after a network interruption, thus rendering the Store-and-Forward database less useful. Again this can be mitigated by increasing the sample intervals to leave room for DCM to "catch up".