The industrial assets (machines and systems) are connected to Azure through modules running on an Azure IoT Edge industrial gateway.
You can purchase industrial gateways compatible with IoT Edge. Please see our Azure Device Catalog for a selection of industrial-grade gateways. Alternatively, you can setup a local VM.
You can also manually create an IoT Edge instance for an IoT Hub and install the IoT Edge runtime following the IoT Edge setup documentation. The IoT Edge Runtime can be installed on Linux or Windows.
The Azure Industrial IoT deployment script will setup IoT Edge Layered Deployments for each Industrial Module. These Layered Deployments will be automatically applied to any IoT Edge instance that contains the following Device Twin JSON tags.
-
Go to the Azure Portal page and select your IoT Hub
-
Open the Device Twin configuration JSON under IoT Edge -> [your IoT Edge device] -> Device Twin
-
Insert the following
tags:
- For Linux, set the "os" property to "Linux":
...
},
"version": 1,
"tags": {
"__type__": "iiotedge",
"os": "Linux"
},
"properties":
...- For Windows (EFLOW), set the "os" property to "Windows":
...
},
"version": 1,
"tags": {
"__type__": "iiotedge",
"os": "Windows"
},
"properties":
...The tags can also be created as part of an Azure Device Provisioning (DPS) enrollment. An example of the latter can be found in /deploy/scripts/dps-enroll.ps1.
Layered deployments will make sure that your edge devices will always contain the modules that work with your platform deployment. This includes keeping module versions aligned with the platform version.
However, sometimes it is desirable to not have layered deployments manage your Gateway fleet. Instead you might want to manage the content of the edge gateway yourself. To prevent the platform from creating layered deployments on your IoT Edge Gateway, but still have the Gateway participate in the Platform, you can define a unmanaged tag in addition to the tags above, like so:
...
"tags": {
"__type__": "iiotedge",
// ...
"unmanaged": true
}
...This will cause that no modules are automatically deployed and thus you must deploy all modules using a module deployment manifest via Az, or Portal.
To continue deploying the 1.1 LTS modules to a 1.1 LTS IoT Edge gateway device until you are able to upgrade the device to 1.4, add a tag to your gateway device's twin with the name use_1_1_LTS and remove it once you have upgraded your edge gateway to 1.4 LTS. This operation can be automated using the az CLI. It should be done ahead of deploying the 2.8.4 release to Azure to avoid outages.
...
"tags": {
"__type__": "iiotedge",
// ...
"use_1_1_LTS": true
}
...IMPORTANT: Setting the tag to
falseor any other value has no effect. Once you upgrade your IoT Edge device to 1.4 you must remove the tag to ensure the 1.4 modules are deployed to it.
By default, the same Docker container image version tag from mcr.microsoft.com is deployed that corresponds to the corresponding micro-service's version.
If you need to point to a different Docker container registry or image version tag, you can configure the source using environment variables PCS_DOCKER_SERVER, PCS_DOCKER_USER, PCS_DOCKER_PASSWORD, PCS_IMAGES_NAMESPACE and PCS_IMAGES_TAG, for example in your .env file (which can also be set during deployment), then restart the edge management or all-in-one service.
To troubleshoot your IoT Edge installation follow the official IoT Edge troubleshooting guide
When device discovery operations fail on Linux gateways (where the discovery module by default is attached to the host network) make sure to validate the host network is available:
docker network ls
NETWORK ID NAME DRIVER SCOPE
beceb3bd61c4 azure-iot-edge bridge local
97eccb2b9f82 bridge bridge local
758d949c5343 host host local
72fb3597ef74 none null local