page_type | description | languages | products | urlFragment | |||
---|---|---|---|---|---|---|---|
sample |
Industrial IoT - Sample OPC UA server that generates random data and anomalies. |
|
|
azure-iot-sample-opc-ua-server |
Implements an OPC-UA server with different nodes generating random data, anomalies and configuration of user defined nodes.
- After deployment, the OPC PLC server will be available at
opc.tcp://<NAME>.<REGION>.azurecontainer.io:50000
- See region limits
The following nodes are part of the PLC simulation:
- Alternating boolean
- Random signed 32-bit integer
- Random unsigend 32-bit integer
- Sine wave with a spike anomaly
- Sine wave with a dip anomaly
- Value showing a positive trend
- Value showing a negative trend
- Value having perodical good, bad and uncertain statuses (slow changing - 10s by default)
- Value having perodical good, bad and uncertain statuses (fast changing - 1s by default)
By default everything is enabled, use command line options to disable certain anomaly or data generation features. Additionally to those nodes with simulated data, a JSON configuration file allows nodes to be created as specified. Finally, the simulation supports a number of nodes of specific types that can change at a configurable rate.
The implementation is based on .NET Core so it is cross-platform and the recommended hosting environment is Docker.
There is no installation required.
A Docker container of the component is hosted in the Microsoft Container Registry and can be pulled by:
docker pull mcr.microsoft.com/iotedge/opc-plc:<See version.json>
The tags of the container match the tags of this repository and the containers are available for Windows and Linux.
If the module (application) is started with the argument --nodesfile then the specified JSON configuration file is loaded. Nodes defined in the JSON file will be published by the server. This enables another OPC-UA client application to set the state/value of the node. Please note that nodes specified in the JSON file are NOT part of the simulation. They remain visible in an unchanged state until an OPC UA client changes their status. The following command shows how to start the application on a Windows host:
dotnet opcplc.dll --at X509Store --nodesfile nodesfile.json
Here's a sample node configuration file:
{
"Folder": "MyTelemetry",
"NodeList": [
{
"NodeId": 1023,
"Name": "ActualSpeed",
"Description": "Rotational speed"
},
{
"NodeId": "aRMS"
},
{
"NodeId": "1025",
"Name": "DKW",
"DataType": "Float",
"ValueRank": -1,
"AccessLevel": "CurrentReadOrWrite",
"Description": "Diagnostic characteristic value"
}
]
}
- Folder: Defines the name of the folder under which the user specified nodes should be created. This folder is created below the root of the OPC UA server.
- NodeList: Defines the list of nodes, which will be published by the emulated server. Nodes specified in the list can be browsed and changed by OPC UA applications. This enables developers to easyly implement and test OPC UA client applications.
- NodeId: Specifies the identifier of the node and is required. This value can be a decimal or string value. Every other JSON type is converted to a string identifier.
- Name: The display name of the tag. If not set it will be set to the NodeId. (Optional)
- DataType: The OPC UA valid type. It specifies one of types defined by BuiltInType. If an invalid type is specified or if it is ommitted it defaults to 'Int32'. (Optional)
- ValueRank: As defined by type ValueRanks. If omitted it will be set to the value '-1' (Scalar). (Optional)
- AccessLevel: Specifies one of access levels defined by type AccessLevels. If an invalid access level is specified or if it is omitted it defaults to 'CurrentReadOrWrite'. (Optional)
- Description: Description of the node. If not set it will be set to the NodeId. (Optional)
A number of changing nodes can be simulated with the following options. The nodes are categorized into slow and fast only for convenience.
- sn: Number of slow nodes (default 1)
- sr: Rate in seconds at which to change the slow nodes (uint, default every 10 s)
- st: Data type for slow nodes (UInt|Double|Bool|UIntArray, case insensitive)
- fn: Number of fast nodes (default 1)
- fr: Rate in seconds at which to change the fast nodes (uint, default every 1 s)
- ft: Data type for fast nodes (UInt|Double|Bool|UIntArray, case insensitive)
- UInt: Increases by 1
- Double: Increases by 0.1
- Bool: Alternates
- UIntArray: 32 values that increase by 1
Sample start command on a Windows host:
dotnet opcplc.dll --pn=50000 --at X509Store --autoaccept --nospikes --nodips --nopostrend --nonegtrend --nodatavalues --sph --sn=25 --sr=10 --st=uint --fn=5 --fr=1 --ft=uint
Sample start command for Docker:
docker run --rm -it -p 50000:50000 -p 8080:8080 --name opcplc mcr.microsoft.com/iotedge/opc-plc:latest --pn=50000 --autoaccept --nospikes --nodips --nopostrend --nonegtrend --nodatavalues --sph --sn=25 --sr=10 --st=uint --fn=5 --fr=1 --ft=uint
The options sph
and sp
show and dump an OPC Publisher configuration file (default name: pn.json
) that matches the configuration. In addition, a web server hosts the file on a configurable port (wp
, default 8080): e.g. http://localhost:8080/pn.json
Additionally, you can set the configuration file name via the option spf
.
The option --ctb
adds a simple boiler to the address space.
Features:
- BoilerStatus is a complex type that shows: temperature, pressure and heater state
- Method to turn heater on/off
- When the heater is on, the bottom temperature increases by 1 degree/s, the top temperature is always 5 degrees less than the bottom one
- Pressure is calculated as 100000 + bottom temperature
The build scripts are for Azure DevOps and the container build is done in ACR. To use your own ACR you need to:
- Create a service connection called azureiiot to the subscription/resource group in which your ACR is located
- Set a variable called BUILD_REGISTRY with the name of your Azure Container Registry
Using <reporoot>/tools/scripts/build.ps1
you can also build with Docker Desktop locally. The sample below builds a debug container and is started at the root of the repository:
.\tools\scripts\build.ps1 -Path . -Debug
If you want to build using docker yourself, it is a bit more complicated, since the dockerfile used it generated by the scripts.
So first run the build.ps1 script
as above, then locate under <reporoot>/src/bin/publish
the dockerfile for your configuration and target runtime.
Next make your modifications and publish the opc-plc project of the solution in Visual Studio. Ensure that you have chosen "Self-Contained" as "Deployment Mode" and the
correct "Target runtime" in the Visual Studio Publish configuration. Next run docker build
command in the folder you published to using the dockerfile of your configuration and target runtime.
Doing it pure command line based in powershell is even simpler. Here an example for an linux-amd64 build:
.\tools\scripts\docker-source.ps1 .\src
docker build -f .\src\bin\publish\Release\linux-x64\Dockerfile.linux-amd64 -t iotedge/opc-plc .\src\bin\publish\Release\linux-x64
X.509 certificates:
- Running on Windows natively, you cannot use an application certificate store of type
Directory
, since the access to the private key will fail. Use the option--at X509Store
in this case. - Running as Linux Docker container, you can map the certificate stores to the host file system by using the Docker run option
-v <hostdirectory>:/appdata
. This will make the certificate persistent over starts. - Running as Linux Docker container using an X509Store for the application certificate, you need to use the Docker run option
-v x509certstores:/root/.dotnet/corefx/cryptography/x509stores
and the application option--at X509Store