Köra OPC Publisher
Viktigt
När vi uppdaterar den här artikeln kan du läsa mer om det senaste innehållet i Azure Industrial IoT .
I den här artikeln beskrivs hur du kör ad debug OPC Publisher. Den tar också upp prestanda- och minnesöverväganden.
Kommandoradsalternativ
Programanvändningen visas med --help kommandoradsalternativet på följande sätt:
Current directory is: /appdata
Log file is: <hostname>-publisher.log
Log level is: info
OPC Publisher V2.3.0
Informational version: V2.3.0+Branch.develop_hans_methodlog.Sha.0985e54f01a0b0d7f143b1248936022ea5d749f9
Usage: opcpublisher.exe <applicationname> [<IoT Hubconnectionstring>] [<options>]
OPC Edge Publisher to subscribe to configured OPC UA servers and send telemetry to Azure IoT Hub.
To exit the application, just press CTRL-C while it is running.
applicationname: the OPC UA application name to use, required
The application name is also used to register the publisher under this name in the
IoT Hub device registry.
IoT Hubconnectionstring: the IoT Hub owner connectionstring, optional
There are a couple of environment variables which can be used to control the application:
_HUB_CS: sets the IoT Hub owner connectionstring
_GW_LOGP: sets the filename of the log file to use
_TPC_SP: sets the path to store certificates of trusted stations
_GW_PNFP: sets the filename of the publishing configuration file
Command line arguments overrule environment variable settings.
Options:
--pf, --publishfile=VALUE
the filename to configure the nodes to publish.
Default: '/appdata/publishednodes.json'
--tc, --telemetryconfigfile=VALUE
the filename to configure the ingested telemetry
Default: ''
-s, --site=VALUE the site OPC Publisher is working in. if specified
this domain is appended (delimited by a ':' to
the 'ApplicationURI' property when telemetry is
sent to IoT Hub.
The value must follow the syntactical rules of a
DNS hostname.
Default: not set
--ic, --iotcentral publisher will send OPC UA data in IoTCentral
compatible format (DisplayName of a node is used
as key, this key is the Field name in IoTCentral)
. you need to ensure that all DisplayName's are
unique. (Auto enables fetch display name)
Default: False
--sw, --sessionconnectwait=VALUE
specify the wait time in seconds publisher is
trying to connect to disconnected endpoints and
starts monitoring unmonitored items
Min: 10
Default: 10
--mq, --monitoreditemqueuecapacity=VALUE
specify how many notifications of monitored items
can be stored in the internal queue, if the data
can not be sent quick enough to IoT Hub
Min: 1024
Default: 8192
--di, --diagnosticsinterval=VALUE
shows publisher diagnostic info at the specified
interval in seconds (need log level info).
-1 disables remote diagnostic log and diagnostic
output
0 disables diagnostic output
Default: 0
--ns, --noshutdown=VALUE
same as runforever.
Default: False
--rf, --runforever publisher can not be stopped by pressing a key on
the console, but will run forever.
Default: False
--lf, --logfile=VALUE the filename of the logfile to use.
Default: './<hostname>-publisher.log'
--lt, --logflushtimespan=VALUE
the timespan in seconds when the logfile should be
flushed.
Default: 00:00:30 sec
--ll, --loglevel=VALUE the loglevel to use (allowed: fatal, error, warn,
info, debug, verbose).
Default: info
--ih, --IoT Hubprotocol=VALUE
the protocol to use for communication with IoT Hub (
allowed values: Amqp, Http1, Amqp_WebSocket_Only,
Amqp_Tcp_Only, Mqtt, Mqtt_WebSocket_Only, Mqtt_
Tcp_Only) or IoT EdgeHub (allowed values: Mqtt_
Tcp_Only, Amqp_Tcp_Only).
Default for IoT Hub: Mqtt_WebSocket_Only
Default for IoT EdgeHub: Amqp_Tcp_Only
--ms, --IoT Hubmessagesize=VALUE
the max size of a message which can be send to
IoT Hub. when telemetry of this size is available
it will be sent.
0 will enforce immediate send when telemetry is
available
Min: 0
Max: 262144
Default: 262144
--si, --IoT Hubsendinterval=VALUE
the interval in seconds when telemetry should be
send to IoT Hub. If 0, then only the
IoT Hubmessagesize parameter controls when
telemetry is sent.
Default: '10'
--dc, --deviceconnectionstring=VALUE
if publisher is not able to register itself with
IoT Hub, you can create a device with name <
applicationname> manually and pass in the
connectionstring of this device.
Default: none
-c, --connectionstring=VALUE
the IoT Hub owner connectionstring.
Default: none
--hb, --heartbeatinterval=VALUE
the publisher is using this as default value in
seconds for the heartbeat interval setting of
nodes without
a heartbeat interval setting.
Default: 0
--sf, --skipfirstevent=VALUE
the publisher is using this as default value for
the skip first event setting of nodes without
a skip first event setting.
Default: False
--pn, --portnum=VALUE the server port of the publisher OPC server
endpoint.
Default: 62222
--pa, --path=VALUE the enpoint URL path part of the publisher OPC
server endpoint.
Default: '/UA/Publisher'
--lr, --ldsreginterval=VALUE
the LDS(-ME) registration interval in ms. If 0,
then the registration is disabled.
Default: 0
--ol, --opcmaxstringlen=VALUE
the max length of a string opc can transmit/
receive.
Default: 131072
--ot, --operationtimeout=VALUE
the operation timeout of the publisher OPC UA
client in ms.
Default: 120000
--oi, --opcsamplinginterval=VALUE
the publisher is using this as default value in
milliseconds to request the servers to sample
the nodes with this interval
this value might be revised by the OPC UA
servers to a supported sampling interval.
please check the OPC UA specification for
details how this is handled by the OPC UA stack.
a negative value will set the sampling interval
to the publishing interval of the subscription
this node is on.
0 will configure the OPC UA server to sample in
the highest possible resolution and should be
taken with care.
Default: 1000
--op, --opcpublishinginterval=VALUE
the publisher is using this as default value in
milliseconds for the publishing interval setting
of the subscriptions established to the OPC UA
servers.
please check the OPC UA specification for
details how this is handled by the OPC UA stack.
a value less than or equal zero will let the
server revise the publishing interval.
Default: 0
--ct, --createsessiontimeout=VALUE
specify the timeout in seconds used when creating
a session to an endpoint. On unsuccessful
connection attemps a backoff up to 5 times the
specified timeout value is used.
Min: 1
Default: 10
--ki, --keepaliveinterval=VALUE
specify the interval in seconds the publisher is
sending keep alive messages to the OPC servers
on the endpoints it is connected to.
Min: 2
Default: 2
--kt, --keepalivethreshold=VALUE
specify the number of keep alive packets a server
can miss, before the session is disconneced
Min: 1
Default: 5
--aa, --autoaccept the publisher trusts all servers it is
establishing a connection to.
Default: False
--tm, --trustmyself=VALUE
same as trustowncert.
Default: False
--to, --trustowncert the publisher certificate is put into the trusted
certificate store automatically.
Default: False
--fd, --fetchdisplayname=VALUE
same as fetchname.
Default: False
--fn, --fetchname enable to read the display name of a published
node from the server. this will increase the
runtime.
Default: False
--ss, --suppressedopcstatuscodes=VALUE
specifies the OPC UA status codes for which no
events should be generated.
Default: BadNoCommunication,
BadWaitingForInitialData
--at, --appcertstoretype=VALUE
the own application cert store type.
(allowed values: Directory, X509Store)
Default: 'Directory'
--ap, --appcertstorepath=VALUE
the path where the own application cert should be
stored
Default (depends on store type):
X509Store: 'CurrentUser\UA_MachineDefault'
Directory: 'pki/own'
--tp, --trustedcertstorepath=VALUE
the path of the trusted cert store
Default: 'pki/trusted'
--rp, --rejectedcertstorepath=VALUE
the path of the rejected cert store
Default 'pki/rejected'
--ip, --issuercertstorepath=VALUE
the path of the trusted issuer cert store
Default 'pki/issuer'
--csr show data to create a certificate signing request
Default 'False'
--ab, --applicationcertbase64=VALUE
update/set this applications certificate with the
certificate passed in as bas64 string
--af, --applicationcertfile=VALUE
update/set this applications certificate with the
certificate file specified
--pb, --privatekeybase64=VALUE
initial provisioning of the application
certificate (with a PEM or PFX fomat) requires a
private key passed in as base64 string
--pk, --privatekeyfile=VALUE
initial provisioning of the application
certificate (with a PEM or PFX fomat) requires a
private key passed in as file
--cp, --certpassword=VALUE
the optional password for the PEM or PFX or the
installed application certificate
--tb, --addtrustedcertbase64=VALUE
adds the certificate to the applications trusted
cert store passed in as base64 string (multiple
strings supported)
--tf, --addtrustedcertfile=VALUE
adds the certificate file(s) to the applications
trusted cert store passed in as base64 string (
multiple filenames supported)
--ib, --addissuercertbase64=VALUE
adds the specified issuer certificate to the
applications trusted issuer cert store passed in
as base64 string (multiple strings supported)
--if, --addissuercertfile=VALUE
adds the specified issuer certificate file(s) to
the applications trusted issuer cert store (
multiple filenames supported)
--rb, --updatecrlbase64=VALUE
update the CRL passed in as base64 string to the
corresponding cert store (trusted or trusted
issuer)
--uc, --updatecrlfile=VALUE
update the CRL passed in as file to the
corresponding cert store (trusted or trusted
issuer)
--rc, --removecert=VALUE
remove cert(s) with the given thumbprint(s) (
multiple thumbprints supported)
--dt, --devicecertstoretype=VALUE
the IoT Hub device cert store type.
(allowed values: Directory, X509Store)
Default: X509Store
--dp, --devicecertstorepath=VALUE
the path of the iot device cert store
Default Default (depends on store type):
X509Store: 'My'
Directory: 'CertificateStores/IoT Hub'
-i, --install register OPC Publisher with IoT Hub and then exits.
Default: False
-h, --help show this message and exit
--st, --opcstacktracemask=VALUE
ignored, only supported for backward comaptibility.
--sd, --shopfloordomain=VALUE
same as site option, only there for backward
compatibility
The value must follow the syntactical rules of a
DNS hostname.
Default: not set
--vc, --verboseconsole=VALUE
ignored, only supported for backward comaptibility.
--as, --autotrustservercerts=VALUE
same as autoaccept, only supported for backward
cmpatibility.
Default: False
--tt, --trustedcertstoretype=VALUE
ignored, only supported for backward compatibility.
the trusted cert store will always reside in a
directory.
--rt, --rejectedcertstoretype=VALUE
ignored, only supported for backward compatibility.
the rejected cert store will always reside in a
directory.
--it, --issuercertstoretype=VALUE
ignored, only supported for backward compatibility.
the trusted issuer cert store will always
reside in a directory.
Vanligtvis anger du endast anslutningssträngen IoT Hub ägare vid den första körningen av programmet. Anslutningssträngen krypteras och lagras i plattformscertifikatarkivet. Vid senare körningar läser programmet anslutningssträngen från certifikatarkivet. Om du anger anslutningssträngen för varje körning tas enheten som skapas för programmet i IoT Hub enhetsregistret bort och återskapas.
Kör internt på Windows
Öppna projektet opcpublisher.sln med Visual Studio, skapa lösningen och publicera den. Du kan starta programmet i målkatalogen som du publicerade på följande sätt:
dotnet opcpublisher.dll <applicationname> [<IoT Hubconnectionstring>] [options]
Använda en egenbyggd container
Skapa en egen container och starta den på följande sätt:
docker run <your-container-name> <applicationname> [<IoT Hubconnectionstring>] [options]
Använda en container från Microsoft Container Registry
Det finns en fördefinierad container i Microsoft Container Registry. Starta den på följande sätt:
docker run mcr.microsoft.com/iotedge/opc-publisher <applicationname> [<IoT Hubconnectionstring>] [options]
Kontrollera Docker Hub för att se vilka operativsystem och processorarkitekturer som stöds. Om din OPERATIVSYSTEM- och CPU-arkitektur stöds väljer Docker automatiskt rätt container.
Kör som en Azure IoT Edge-modul
OPC Publisher är redo att användas som en Azure IoT Edge-modul. När du använder OPC Publisher som IoT Edge modul är de enda transportprotokoll som stöds Amqp_Tcp_Only och Mqtt_Tcp_Only.
Om du vill lägga till OPC Publisher som modul i din IoT Edge-distribution går du till inställningarna för IoT Hub i Azure Portal och utför följande steg:
Gå till IoT Edge och skapa eller välj din IoT Edge enhet.
Välj Ange moduler.
Välj Lägg till under Distributionsmoduler och sedan IoT Edge modul.
I fältet Namn anger du utgivare.
I fältet Bild-URI anger du
mcr.microsoft.com/iotedge/opc-publisher:<tag>Du hittar de tillgängliga taggarna på Docker Hub
Klistra in följande JSON i fältet Alternativ för containerskapande :
{ "Hostname": "publisher", "Cmd": [ "--aa" ] }Den här konfigurationen konfigurerar IoT Edge att starta en container med namnet publisher med hjälp av OPC Publisher-avbildningen. Värdnamnet för containerns system är inställt på utgivare. OPC Publisher anropas med följande kommandoradsargument:
--aa. Med det här alternativet litar OPC Publisher på certifikaten för de OPC UA-servrar som den ansluter till. Du kan använda alla OPC-Publisher kommandoradsalternativ. Den enda begränsningen är storleken på de alternativ för att skapa containrar som stöds av IoT Edge.Lämna de andra inställningarna som de är och välj Spara.
Om du vill bearbeta utdata från OPC-Publisher lokalt med en annan IoT Edge modul går du tillbaka till sidan Ange moduler. Gå sedan till fliken Ange vägar och lägg till en ny väg som ser ut som följande JSON:
{ "routes": { "processingModuleToIoT Hub": "FROM /messages/modules/processingModule/outputs/* INTO $upstream", "opcPublisherToProcessingModule": "FROM /messages/modules/publisher INTO BrokeredEndpoint(\"/modules/processingModule/inputs/input1\")" } }På sidan Ange moduler väljer du Nästa tills du når den sista sidan i konfigurationen.
Välj Skicka för att skicka konfigurationen till IoT Edge.
När du har startat IoT Edge på gränsenheten och Docker-containerutgivaren körs kan du kolla in loggutdata för OPC-Publisher antingen med hjälp
docker logs -f publisherav eller genom att kontrollera loggfilen. I föregående exempel ligger loggfilen ovanförd:\iiotegde\publisher-publisher.log. Du kan också använda verktyget iot-edge-opc-publisher-diagnostics.
Gör konfigurationsfilerna tillgängliga på värden
Om du vill göra IoT Edge modulkonfigurationsfiler tillgängliga i värdfilsystemet använder du följande alternativ för att skapa containrar. Följande exempel är en distribution som använder Linux-containrar för Windows:
{
"Hostname": "publisher",
"Cmd": [
"--pf=./pn.json",
"--aa"
],
"HostConfig": {
"Binds": [
"d:/iiotedge:/appdata"
]
}
}
Med dessa alternativ läser OPC Publisher noderna som ska publiceras från filen ./pn.json och containerns arbetskatalog är inställd /appdata på vid start. Med de här inställningarna läser OPC Publisher filen /appdata/pn.json från containern för att hämta dess konfiguration. Utan alternativet --pf försöker OPC Publisher läsa standardkonfigurationsfilen ./publishednodes.json.
Loggfilen med standardnamnet publisher-publisher.logskrivs till /appdata och CertificateStores katalogen skapas också i den här katalogen.
För att göra alla dessa filer tillgängliga i värdfilsystemet kräver containerkonfigurationen en bindningsmonteringsvolym. Bindningen d://iiotedge:/appdata mappar katalogen /appdata, som är den aktuella arbetskatalogen vid containerstart, till värdkatalogen d://iiotedge. Utan det här alternativet sparas inga fildata när containern startas nästa gången.
Om du kör Windows containrar är syntaxen för parametern Binds annorlunda. Vid containerstart är c:\appdataarbetskatalogen . Om du vill placera konfigurationsfilen i katalogen d:\iiotedgepå värden anger du följande mappning i HostConfig avsnittet :
"HostConfig": {
"Binds": [
"d:/iiotedge:c:/appdata"
]
}
Om du kör Linux-containrar i Linux är syntaxen för parametern Binds återigen annorlunda. Vid containerstart är /appdataarbetskatalogen . Om du vill placera konfigurationsfilen i katalogen /iiotedge på värden anger du följande mappning i HostConfig avsnittet :
"HostConfig": {
"Binds": [
"/iiotedge:/appdata"
]
}
Att tänka på när du använder en container
I följande avsnitt visas några saker att tänka på när du använder en container:
Åtkomst till OPC Publisher OPC UA-servern
Som standard lyssnar OPC Publisher OPC UA-servern på port 62222. Om du vill exponera den här inkommande porten i en container använder du följande kommando:
docker run -p 62222:62222 mcr.microsoft.com/iotedge/opc-publisher <applicationname> [<IoT Hubconnectionstring>] [options]
Aktivera namnmatchning mellancontainer
Om du vill aktivera namnmatchning inifrån containern till andra containrar skapar du ett användardefinierat Docker Bridge-nätverk och ansluter containern till det här nätverket med hjälp av --network alternativet . Tilldela även containern ett namn med hjälp av --name alternativet på följande sätt:
docker network create -d bridge iot_edge
docker run --network iot_edge --name publisher mcr.microsoft.com/iotedge/opc-publisher <applicationname> [<IoT Hubconnectionstring>] [options]
Containern kan nu nås med hjälp av namnet publisher av andra containrar i samma nätverk.
Få åtkomst till andra system inifrån containern
Andra containrar kan nås med hjälp av parametrarna som beskrivs i föregående avsnitt. Om operativsystemet där Docker finns är DNS aktiverat fungerar åtkomst till alla system som är kända för DNS.
I nätverk som använder NetBIOS-namnmatchning aktiverar du åtkomst till andra system genom att starta containern --add-host med alternativet . Det här alternativet lägger effektivt till en post i containerns värdfil:
docker run --add-host mydevbox:192.168.178.23 mcr.microsoft.com/iotedge/opc-publisher <applicationname> [<IoT Hubconnectionstring>] [options]
Tilldela ett värdnamn
OPC-Publisher använder värdnamnet för den dator som den körs på för generering av certifikat och slutpunkter. Docker väljer ett slumpmässigt värdnamn om ett inte anges av -h alternativet . I följande exempel visas hur du anger containerns interna värdnamn till publisher:
docker run -h publisher mcr.microsoft.com/iotedge/opc-publisher <applicationname> [<IoT Hubconnectionstring>] [options]
Använda bindningsmonteringar (delat filsystem)
I stället för att använda containerfilsystemet kan du välja värdfilsystemet för att lagra konfigurationsinformation och loggfiler. Om du vill konfigurera det här alternativet använder du -v alternativet docker run för i läget för bindningsmontering.
OPC UA X.509-certifikat
OPC UA använder X.509-certifikat för att autentisera OPC UA-klienten och servern när de upprättar en anslutning och för att kryptera kommunikationen mellan dem. OPC Publisher använder certifikatarkiv som underhålls av OPC UA-stacken för att hantera alla certifikat. Vid start kontrollerar OPC Publisher om det finns ett certifikat för sig självt. Om det inte finns något certifikat i certifikatarkivet och det inte är ett som skickas på kommandoraden skapar OPC Publisher ett självsignerat certifikat. Mer information finns i metoden InitApplicationSecurityAsync i OpcApplicationConfigurationSecurity.cs.
Självsignerade certifikat ger ingen säkerhet eftersom de inte är signerade av en betrodd certifikatutfärdare.
OPC Publisher innehåller kommandoradsalternativ för att:
- Hämta CSR-information för det aktuella programcertifikatet som används av OPC Publisher.
- Etablera OPC-Publisher med ett CA-signerat certifikat.
- Etablera OPC-Publisher med ett nytt nyckelpar och ett matchande CA-signerat certifikat.
- Lägg till certifikat i ett certifikatarkiv för betrodd peer eller betrodd utfärdare.
- Lägg till en CRL.
- Ta bort ett certifikat från certifikatarkivet för betrodda peer- eller betrodda utfärdare.
Med alla dessa alternativ kan du skicka in parametrar med hjälp av filer eller base64-kodade strängar.
Standardlagringstypen för alla certifikatarkiv är filsystemet, som du kan ändra med hjälp av kommandoradsalternativ. Eftersom containern inte tillhandahåller beständig lagring i filsystemet måste du välja en annan lagringstyp. Använd docker-alternativet -v för att bevara certifikatarkiven i värdfilsystemet eller på en Docker-volym. Om du använder en Docker-volym kan du skicka in certifikat med base64-kodade strängar.
Körningsmiljön påverkar hur certifikat bevaras. Undvik att skapa nya certifikatarkiv varje gång du kör programmet:
- Om du kör internt på Windows kan du inte använda ett programcertifikatarkiv av typen
Directoryeftersom åtkomsten till den privata nyckeln misslyckas. I det här fallet använder du alternativet--at X509Store. - Om du kör som Linux Docker-container kan du mappa certifikatarkiven till värdfilsystemet med docker-körningsalternativet
-v <hostdirectory>:/appdata. Det här alternativet gör certifikatet beständigt mellan programkörningar. - Kör som Linux Docker-container och du vill använda ett X509-arkiv för programcertifikatet, använd docker-körningsalternativet
-v x509certstores:/root/.dotnet/corefx/cryptography/x509storesoch programalternativet--at X509Store
Prestanda- och minnesöverväganden
I det här avsnittet beskrivs alternativ för att hantera minne och prestanda:
Kommandoradsparametrar för att styra prestanda och minne
När du kör OPC Publisher måste du vara medveten om dina prestandakrav och de minnesresurser som är tillgängliga på värden.
Minne och prestanda är beroende av varandra och båda beror på konfigurationen av hur många noder du konfigurerar för publicering. Kontrollera att följande parametrar uppfyller dina krav:
- IoT Hub skickar intervall:
--si - IoT Hub meddelandestorlek (standard
1):--ms - Kökapacitet för övervakade objekt:
--mq
Parametern --mq styr den övre gränsen för kapaciteten i den interna kön, som buffrar alla meddelanden om ändring av OPC-nodvärden. Om OPC Publisher inte kan skicka meddelanden till IoT Hub tillräckligt snabbt buffrar den här kön meddelandena. Parametern anger antalet meddelanden som kan bufferas. Om du ser att antalet objekt i den här kön ökar i dina testkörningar bör du undvika att förlora meddelanden genom att:
- Minska sändningsintervallet för IoT Hub
- Öka meddelandestorleken för IoT Hub
Parametern --si tvingar OPC-Publisher att skicka meddelanden till IoT Hub vid det angivna intervallet. OPC-Publisher skickar ett meddelande så snart meddelandestorleken som anges av parametern --ms har nåtts, eller så snart intervallet som anges av parametern --si har uppnåtts. Om du vill inaktivera alternativet meddelandestorlek använder du --ms 0. I det här fallet använder OPC Publisher största möjliga IoT Hub meddelandestorlek på 256 kB för att batchdata.
Med --ms parametern kan du skicka batchmeddelanden till IoT Hub. Det protokoll som du använder avgör om kostnaden för att skicka ett meddelande till IoT Hub är hög jämfört med den faktiska tiden för att skicka nyttolasten. Om ditt scenario tillåter svarstider när data matas in av IoT Hub konfigurerar du OPC Publisher att använda den största meddelandestorleken på 256 kB.
Innan du använder OPC Publisher i produktionsscenarier bör du testa prestanda- och minnesanvändningen under produktionsförhållanden. Du kan använda parametern --di för att ange intervallet i sekunder som OPC Publisher skriver diagnostikinformation.
Testmått
I följande exempeldiagnostik visas mått med olika värden för och --ms parametrar som --si publicerar 500 noder med ett OPC-publiceringsintervall på 1 sekund. Testet använde en OPC-Publisher felsökningsversion på Windows 10 internt i 120 sekunder. Det IoT Hub protokollet var MQTT-standardprotokollet.
Standardkonfiguration (--si 10 --ms 262144)
==========================================================================
OpcPublisher status @ 26.10.2017 15:33:05 (started @ 26.10.2017 15:31:09)
---------------------------------
OPC sessions: 1
connected OPC sessions: 1
connected OPC subscriptions: 5
OPC monitored items: 500
---------------------------------
monitored items queue bounded capacity: 8192
monitored items queue current items: 0
monitored item notifications enqueued: 54363
monitored item notifications enqueue failure: 0
monitored item notifications dequeued: 54363
---------------------------------
messages sent to IoT Hub: 109
last successful msg sent @: 26.10.2017 15:33:04
bytes sent to IoT Hub: 12709429
avg msg size: 116600
msg send failures: 0
messages too large to sent to IoT Hub: 0
times we missed send interval: 0
---------------------------------
current working set in MB: 90
--si setting: 10
--ms setting: 262144
--ih setting: Mqtt
==========================================================================
Standardkonfigurationen skickar data till IoT Hub var 10:e sekund, eller när 256 kB data är tillgängliga för IoT Hub att mata in. Den här konfigurationen lägger till en måttlig svarstid på cirka 10 sekunder, men har lägst sannolikhet att förlora data på grund av den stora meddelandestorleken. Diagnostikutdata visar att det inte finns några förlorade OPC-noduppdateringar: monitored item notifications enqueue failure: 0.
Intervall för konstant sändning (--si 1 --ms 0)
==========================================================================
OpcPublisher status @ 26.10.2017 15:35:59 (started @ 26.10.2017 15:34:03)
---------------------------------
OPC sessions: 1
connected OPC sessions: 1
connected OPC subscriptions: 5
OPC monitored items: 500
---------------------------------
monitored items queue bounded capacity: 8192
monitored items queue current items: 0
monitored item notifications enqueued: 54243
monitored item notifications enqueue failure: 0
monitored item notifications dequeued: 54243
---------------------------------
messages sent to IoT Hub: 109
last successful msg sent @: 26.10.2017 15:35:59
bytes sent to IoT Hub: 12683836
avg msg size: 116365
msg send failures: 0
messages too large to sent to IoT Hub: 0
times we missed send interval: 0
---------------------------------
current working set in MB: 90
--si setting: 1
--ms setting: 0
--ih setting: Mqtt
==========================================================================
När meddelandestorleken är inställd på 0 batchar OPC-Publisher internt data med den största IoT Hub meddelandestorlek som stöds, vilket är 256 kB. Diagnostikutdata visar att den genomsnittliga meddelandestorleken är 115 019 byte. I den här konfigurationen förlorar OPC-Publisher inga uppdateringar av OPC-nodvärden och har lägre svarstid jämfört med standardvärdet.
Skicka varje uppdatering av OPC-nodvärdet (--si 0 --ms 0)
==========================================================================
OpcPublisher status @ 26.10.2017 15:39:33 (started @ 26.10.2017 15:37:37)
---------------------------------
OPC sessions: 1
connected OPC sessions: 1
connected OPC subscriptions: 5
OPC monitored items: 500
---------------------------------
monitored items queue bounded capacity: 8192
monitored items queue current items: 8184
monitored item notifications enqueued: 54232
monitored item notifications enqueue failure: 44624
monitored item notifications dequeued: 1424
---------------------------------
messages sent to IoT Hub: 1423
last successful msg sent @: 26.10.2017 15:39:33
bytes sent to IoT Hub: 333046
avg msg size: 234
msg send failures: 0
messages too large to sent to IoT Hub: 0
times we missed send interval: 0
---------------------------------
current working set in MB: 96
--si setting: 0
--ms setting: 0
--ih setting: Mqtt
==========================================================================
Den här konfigurationen skickar för varje OPC-nodvärde ändra ett meddelande till IoT Hub. Diagnostiken visar att den genomsnittliga meddelandestorleken är 234 byte, vilket är litet. Fördelen med den här konfigurationen är att OPC Publisher inte lägger till någon svarstid. Antalet förlorade uppdateringar av OPC-nodvärden (monitored item notifications enqueue failure: 44624) är högt, vilket gör den här konfigurationen olämplig för scenarier med stora mängder telemetri som ska publiceras.
Maximal batchbearbetning (--si 0 --ms 262144)
==========================================================================
OpcPublisher status @ 26.10.2017 15:42:55 (started @ 26.10.2017 15:41:00)
---------------------------------
OPC sessions: 1
connected OPC sessions: 1
connected OPC subscriptions: 5
OPC monitored items: 500
---------------------------------
monitored items queue bounded capacity: 8192
monitored items queue current items: 0
monitored item notifications enqueued: 54137
monitored item notifications enqueue failure: 0
monitored item notifications dequeued: 54137
---------------------------------
messages sent to IoT Hub: 48
last successful msg sent @: 26.10.2017 15:42:55
bytes sent to IoT Hub: 12565544
avg msg size: 261782
msg send failures: 0
messages too large to sent to IoT Hub: 0
times we missed send interval: 0
---------------------------------
current working set in MB: 90
--si setting: 0
--ms setting: 262144
--ih setting: Mqtt
==========================================================================
Den här konfigurationen batchar så många uppdateringar av OPC-nodvärden som möjligt. Den maximala IoT Hub meddelandestorleken är 256 kB, vilket konfigureras här. Inget sändningsintervall har begärts, vilket innebär att mängden data som IoT Hub ska mata in avgör svarstiden. Den här konfigurationen har minst sannolikhet att förlora OPC-nodvärden och är lämplig för publicering av ett stort antal noder. När du använder den här konfigurationen kontrollerar du att ditt scenario inte har villkor där hög svarstid införs om meddelandestorleken på 256 kB inte nås.
Felsök programmet
Om du vill felsöka programmet öppnar du lösningsfilen opcpublisher.sln med Visual Studio och använder Visual Studio felsökningsverktyg.
Om du behöver åtkomst till OPC UA-servern i OPC-Publisher kontrollerar du att brandväggen tillåter åtkomst till den port som servern lyssnar på. Standardporten är: 62222.
Fjärrstyra programmet
Du kan konfigurera noderna som ska publiceras med hjälp av IoT Hub direktmetoder.
OPC Publisher implementerar några ytterligare IoT Hub direkta metodanrop att läsa:
- Allmän information.
- Diagnostikinformation om OPC-sessioner, prenumerationer och övervakade objekt.
- Diagnostikinformation om IoT Hub meddelanden och händelser.
- Startloggen.
- De sista 100 raderna i loggen.
- Stäng av programmet.
Följande GitHub-lagringsplatser innehåller verktyg för att konfigurera noderna för att publicera och läsa diagnostikinformationen. Båda verktygen är också tillgängliga som containrar i Docker Hub.
Använda en OPC UA-exempelserver
Om du inte har en riktig OPC UA-server kan du använda OPC UA PLC-exemplet för att komma igång. Det här exempel-PLC:et finns också på Docker Hub.
Den implementerar ett antal taggar som genererar slumpmässiga data och taggar med avvikelser. Du kan utöka exemplet om du behöver simulera ytterligare taggvärden.
Nästa steg
Nu när du har lärt dig hur du kör OPC Publisher är de rekommenderade nästa stegen att lära dig mer om OPC Twin och OPC Vault.