Uruchamianie wydawcy OPC
Ważne
Chociaż aktualizujemy ten artykuł, zobacz Azure Industrial IoT (Azure Industrial IoT ), aby uzyskać najbardziej aktualną zawartość.
W tym artykule opisano sposób uruchamiania Publisher OPC debugowania reklam. Dotyczy to również kwestii związanych z wydajnością i pamięcią.
Opcje wiersza polecenia
Użycie aplikacji jest wyświetlane przy użyciu --help opcji wiersza polecenia w następujący sposób:
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.
Zazwyczaj określasz parametry połączenia właściciela IoT Hub tylko w pierwszym uruchomieniu aplikacji. Parametry połączenia są szyfrowane i przechowywane w magazynie certyfikatów platformy. W późniejszym czasie aplikacja odczytuje parametry połączenia z magazynu certyfikatów. Jeśli określisz parametry połączenia w każdym uruchomieniu, urządzenie utworzone dla aplikacji w rejestrze urządzeń IoT Hub zostanie usunięte i utworzone ponownie.
Uruchamianie natywnie na Windows
Otwórz projekt opcpublisher.sln z Visual Studio, skompiluj rozwiązanie i opublikuj go. Aplikację można uruchomić w katalogu docelowym opublikowanym w następujący sposób:
dotnet opcpublisher.dll <applicationname> [<IoT Hubconnectionstring>] [options]
Korzystanie z kontenera utworzonego samodzielnie
Skompiluj własny kontener i uruchom go w następujący sposób:
docker run <your-container-name> <applicationname> [<IoT Hubconnectionstring>] [options]
Używanie kontenera z Microsoft Container Registry
W Microsoft Container Registry dostępny jest wstępnie utworzony kontener. Uruchom go w następujący sposób:
docker run mcr.microsoft.com/iotedge/opc-publisher <applicationname> [<IoT Hubconnectionstring>] [options]
Sprawdź Docker Hub, aby zobaczyć obsługiwane systemy operacyjne i architektury procesora. Jeśli architektura systemu operacyjnego i procesora CPU jest obsługiwana, platforma Docker automatycznie wybiera odpowiedni kontener.
Uruchamianie jako modułu usługi Azure IoT Edge
Publisher OPC jest gotowy do użycia jako moduł usługi Azure IoT Edge. W przypadku używania Publisher OPC jako modułu IoT Edge jedynymi obsługiwanymi protokołami transportu są Amqp_Tcp_Only i Mqtt_Tcp_Only.
Aby dodać Publisher OPC jako moduł do wdrożenia IoT Edge, przejdź do ustawień IoT Hub w Azure Portal i wykonaj następujące kroki:
Przejdź do IoT Edge i utwórz lub wybierz urządzenie IoT Edge.
Wybierz pozycję Ustaw moduły.
Wybierz pozycję Dodaj w obszarze Moduły wdrażania, a następnie IoT Edge moduł.
W polu Nazwa wprowadź wartość publisher.
W polu Identyfikator URI obrazu wprowadź
mcr.microsoft.com/iotedge/opc-publisher:<tag>Dostępne tagi można znaleźć na Docker Hub
Wklej następujący kod JSON w polu Opcje tworzenia kontenera :
{ "Hostname": "publisher", "Cmd": [ "--aa" ] }Ta konfiguracja konfiguruje IoT Edge do uruchamiania kontenera o nazwie publisher przy użyciu obrazu Publisher OPC. Nazwa hosta systemu kontenera jest ustawiona na wydawcę. Publisher OPC jest wywoływana przy użyciu następującego argumentu wiersza polecenia:
--aa. Dzięki tej opcji OPC Publisher ufa certyfikatom serwerów OPC UA, z którymi nawiązuje połączenie. Można użyć dowolnych opcji wiersza polecenia OPC Publisher. Jedynym ograniczeniem jest rozmiar opcji tworzenia kontenera obsługiwanych przez IoT Edge.Pozostaw inne ustawienia bez zmian, a następnie wybierz pozycję Zapisz.
Jeśli chcesz przetworzyć dane wyjściowe Publisher OPC lokalnie przy użyciu innego modułu IoT Edge, wróć do strony Ustawianie modułów. Następnie przejdź do karty Określanie tras i dodaj nową trasę, która wygląda podobnie do następującego kodu JSON:
{ "routes": { "processingModuleToIoT Hub": "FROM /messages/modules/processingModule/outputs/* INTO $upstream", "opcPublisherToProcessingModule": "FROM /messages/modules/publisher INTO BrokeredEndpoint(\"/modules/processingModule/inputs/input1\")" } }Po powrocie na stronę Ustawianie modułów wybierz pozycję Dalej, dopóki nie osiągniesz ostatniej strony konfiguracji.
Wybierz pozycję Prześlij, aby wysłać konfigurację do IoT Edge.
Po uruchomieniu IoT Edge na urządzeniu brzegowym i uruchomieniu wydawcy kontenera platformy Docker możesz sprawdzić dane wyjściowe dziennika OPC Publisher przy użyciu polecenia
docker logs -f publisherlub sprawdzając plik dziennika. W poprzednim przykładzie plik dziennika znajduje się powyżejd:\iiotegde\publisher-publisher.log. Możesz również użyć narzędzia iot-edge-opc-publisher-diagnostics.
Udostępnianie plików konfiguracji na hoście
Aby pliki konfiguracji modułu IoT Edge były dostępne w systemie plików hosta, użyj następujących opcji tworzenia kontenera. Poniższy przykład dotyczy wdrożenia przy użyciu kontenerów systemu Linux dla Windows:
{
"Hostname": "publisher",
"Cmd": [
"--pf=./pn.json",
"--aa"
],
"HostConfig": {
"Binds": [
"d:/iiotedge:/appdata"
]
}
}
Dzięki tym opcjom OPC Publisher odczytuje węzły, które powinny zostać opublikowane z pliku./pn.json, a katalog roboczy kontenera jest ustawiony na /appdata podczas uruchamiania. Za pomocą tych ustawień Publisher OPC odczytuje plik /appdata/pn.json z kontenera, aby uzyskać jego konfigurację.
--pf Bez opcji Publisher OPC próbuje odczytać domyślny plik ./publishednodes.jsonkonfiguracji .
Plik dziennika o nazwie publisher-publisher.logdomyślnej jest zapisywany w /appdata katalogu , a CertificateStores katalog jest również tworzony w tym katalogu.
Aby udostępnić wszystkie te pliki w systemie plików hosta, konfiguracja kontenera wymaga woluminu instalacji powiązanej. Powiązanie d://iiotedge:/appdata mapuje katalog /appdata, który jest bieżącym katalogem roboczym podczas uruchamiania kontenera, do katalogu d://iiotedgehosta . Bez tej opcji żadne dane plików nie są utrwalane po następnym uruchomieniu kontenera.
Jeśli używasz kontenerów Windows, składnia parametru Binds jest inna. Podczas uruchamiania kontenera katalog roboczy to c:\appdata. Aby umieścić plik konfiguracji w katalogu d:\iiotedgena hoście, określ następujące mapowanie w HostConfig sekcji :
"HostConfig": {
"Binds": [
"d:/iiotedge:c:/appdata"
]
}
Jeśli używasz kontenerów systemu Linux w systemie Linux, składnia parametru Binds jest ponownie inna. Podczas uruchamiania kontenera katalog roboczy to /appdata. Aby umieścić plik konfiguracji w katalogu /iiotedge na hoście, określ następujące mapowanie w HostConfig sekcji :
"HostConfig": {
"Binds": [
"/iiotedge:/appdata"
]
}
Zagadnienia dotyczące korzystania z kontenera
W poniższych sekcjach wymieniono niektóre kwestie, które należy wziąć pod uwagę podczas korzystania z kontenera:
Dostęp do serwera OPC Publisher OPC UA
Domyślnie serwer OPC Publisher OPC UA nasłuchuje na porcie 62222. Aby uwidocznić ten port przychodzący w kontenerze, użyj następującego polecenia:
docker run -p 62222:62222 mcr.microsoft.com/iotedge/opc-publisher <applicationname> [<IoT Hubconnectionstring>] [options]
Włączanie rozpoznawania nazw międzykontenerowych
Aby włączyć rozpoznawanie nazw z poziomu kontenera do innych kontenerów, utwórz użytkownika definiującą sieć mostka platformy Docker i połącz kontener z tą siecią --network przy użyciu opcji . Przypisz również kontenerowi nazwę przy użyciu opcji w --name następujący sposób:
docker network create -d bridge iot_edge
docker run --network iot_edge --name publisher mcr.microsoft.com/iotedge/opc-publisher <applicationname> [<IoT Hubconnectionstring>] [options]
Kontener jest teraz dostępny przy użyciu nazwy publisher innych kontenerów w tej samej sieci.
Uzyskiwanie dostępu do innych systemów z poziomu kontenera
Inne kontenery można uzyskać za pomocą parametrów opisanych w poprzedniej sekcji. Jeśli system operacyjny, na którym jest hostowana platforma Docker, jest włączony system DNS, uzyskiwanie dostępu do wszystkich systemów, które są znane dns działa.
W sieciach korzystających z rozpoznawania nazw NetBIOS włącz dostęp do innych systemów, uruchamiając kontener z opcją --add-host . Ta opcja skutecznie dodaje wpis do pliku hosta kontenera:
docker run --add-host mydevbox:192.168.178.23 mcr.microsoft.com/iotedge/opc-publisher <applicationname> [<IoT Hubconnectionstring>] [options]
Przypisywanie nazwy hosta
Publisher OPC używa nazwy hosta maszyny uruchomionej na potrzeby generowania certyfikatu i punktu końcowego. Platforma Docker wybiera losową nazwę hosta, jeśli nie jest ustawiona -h przez tę opcję. W poniższym przykładzie pokazano, jak ustawić wewnętrzną nazwę hosta kontenera na publisher:
docker run -h publisher mcr.microsoft.com/iotedge/opc-publisher <applicationname> [<IoT Hubconnectionstring>] [options]
Korzystanie z instalacji powiązanych (współużytkowany system plików)
Zamiast korzystać z systemu plików kontenera, można wybrać system plików hosta do przechowywania informacji o konfiguracji i plików dziennika. Aby skonfigurować tę opcję, użyj -v opcji docker run w trybie instalacji powiązanej.
Certyfikaty OPC UA X.509
OPC UA używa certyfikatów X.509 do uwierzytelniania klienta I serwera OPC UA podczas nawiązywania połączenia i szyfrowania komunikacji między nimi. OPC Publisher używa magazynów certyfikatów utrzymywanych przez stos OPC UA do zarządzania wszystkimi certyfikatami. Podczas uruchamiania OPC Publisher sprawdza, czy istnieje certyfikat dla siebie. Jeśli w magazynie certyfikatów nie ma certyfikatu i nie jest on przekazywany w wierszu polecenia, Publisher OPC tworzy certyfikat z podpisem własnym. Aby uzyskać więcej informacji, zobacz metodę InitApplicationSecurityAsync w pliku OpcApplicationConfigurationSecurity.cs.
Certyfikaty z podpisem własnym nie zapewniają żadnych zabezpieczeń, ponieważ nie są podpisane przez zaufany urząd certyfikacji.
Publisher OPC udostępnia opcje wiersza polecenia:
- Pobierz informacje o csr bieżącego certyfikatu aplikacji używanego przez Publisher OPC.
- Aprowizuj Publisher OPC przy użyciu certyfikatu podpisanego przez urząd certyfikacji.
- Aprowizuj Publisher OPC przy użyciu nowej pary kluczy i zgodnego certyfikatu podpisanego przez urząd certyfikacji.
- Dodaj certyfikaty do magazynu certyfikatów zaufanego elementu równorzędnego lub zaufanego wystawcy.
- Dodaj listę CRL.
- Usuń certyfikat z magazynu certyfikatów zaufanych wystawców lub zaufanych elementów równorzędnych.
Wszystkie te opcje umożliwiają przekazywanie parametrów przy użyciu plików lub ciągów zakodowanych w formacie Base64.
Domyślnym typem magazynu dla wszystkich magazynów certyfikatów jest system plików, który można zmienić przy użyciu opcji wiersza polecenia. Ponieważ kontener nie zapewnia magazynu trwałego w systemie plików, musisz wybrać inny typ magazynu. Użyj opcji Platformy Docker -v , aby utrwały magazyny certyfikatów w systemie plików hosta lub na woluminie platformy Docker. Jeśli używasz woluminu platformy Docker, możesz przekazać certyfikaty przy użyciu ciągów zakodowanych w formacie Base64.
Środowisko uruchomieniowe wpływa na sposób utrwalania certyfikatów. Unikaj tworzenia nowych magazynów certyfikatów za każdym razem, gdy uruchamiasz aplikację:
- Uruchamianie natywnie na Windows nie można użyć magazynu certyfikatów aplikacji typu
Directory, ponieważ dostęp do klucza prywatnego kończy się niepowodzeniem. W tym przypadku użyj opcji--at X509Store. - Uruchomione jako kontener platformy Docker systemu Linux można mapować magazyny certyfikatów do systemu plików hosta przy użyciu opcji
-v <hostdirectory>:/appdatauruchamiania platformy Docker. Ta opcja sprawia, że certyfikat jest trwały w ramach uruchamiania aplikacji. - Uruchomione jako kontener platformy Docker systemu Linux i chcesz użyć magazynu X509 dla certyfikatu aplikacji, użyj opcji
-v x509certstores:/root/.dotnet/corefx/cryptography/x509storesuruchamiania platformy Docker i opcji aplikacji--at X509Store
Zagadnienia dotyczące wydajności i pamięci
W tej sekcji omówiono opcje zarządzania pamięcią i wydajnością:
Parametry wiersza polecenia umożliwiające sterowanie wydajnością i pamięcią
Po uruchomieniu Publisher OPC należy pamiętać o wymaganiach dotyczących wydajności i zasobach pamięci dostępnych na hoście.
Pamięć i wydajność są współzależne, a obie zależą od konfiguracji liczby węzłów skonfigurowanych do opublikowania. Upewnij się, że następujące parametry spełniają twoje wymagania:
- interwał wysyłania IoT Hub:
--si - IoT Hub rozmiar komunikatu (ustawienie domyślne
1):--ms - Pojemność kolejki monitorowanych elementów:
--mq
Parametr --mq steruje górną granicą pojemności kolejki wewnętrznej, która buforuje wszystkie powiadomienia o zmianie wartości węzła OPC. Jeśli Publisher OPC nie może wysyłać komunikatów do IoT Hub wystarczająco szybko, kolejka buforuje powiadomienia. Parametr ustawia liczbę powiadomień, które mogą być buforowane. Jeśli liczba elementów w tej kolejce rośnie w przebiegach testów, należy unikać utraty komunikatów:
- Zmniejsz interwał wysyłania IoT Hub
- Zwiększanie rozmiaru komunikatu IoT Hub
Parametr --si wymusza Publisher OPC do wysyłania komunikatów do IoT Hub w określonym interwale. OPC Publisher wysyła komunikat natychmiast po osiągnięciu rozmiaru komunikatu określonego --ms przez parametr lub natychmiast po osiągnięciu interwału określonego --si przez parametr. Aby wyłączyć opcję rozmiaru komunikatu, użyj polecenia --ms 0. W tym przypadku OPC Publisher używa największego możliwego rozmiaru komunikatu IoT Hub 256 kB do danych wsadowych.
Parametr --ms umożliwia wysyłanie komunikatów wsadowych do IoT Hub. Używany protokół określa, czy obciążenie wysyłania komunikatu do IoT Hub jest wysokie w porównaniu z rzeczywistym czasem wysyłania ładunku. Jeśli twój scenariusz umożliwia opóźnienie podczas pozyskiwania danych przez IoT Hub, skonfiguruj Publisher OPC, aby używać największego rozmiaru komunikatu 256 kB.
Przed użyciem Publisher OPC w scenariuszach produkcyjnych przetestuj wydajność i użycie pamięci w warunkach produkcyjnych. Można użyć parametru --di , aby określić interwał w sekundach, że OPC Publisher zapisuje informacje diagnostyczne.
Testowanie pomiarów
Poniższa przykładowa diagnostyka pokazuje pomiary z różnymi wartościami parametrów --si i --ms publikując 500 węzłów z interwałem publikowania OPC wynoszącym 1 sekundę. Test używał debugowania OPC Publisher kompilacji na Windows 10 natywnie przez 120 sekund. Protokół IoT Hub był domyślnym protokołem MQTT.
Konfiguracja domyślna (--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
==========================================================================
Domyślna konfiguracja wysyła dane do IoT Hub co 10 sekund lub gdy do pozyskiwania jest IoT Hub dostępna 256 kB danych. Ta konfiguracja dodaje umiarkowane opóźnienie około 10 sekund, ale ma najniższe prawdopodobieństwo utraty danych z powodu dużego rozmiaru komunikatu. Dane wyjściowe diagnostyki pokazują, że nie ma utraconych aktualizacji węzła OPC: monitored item notifications enqueue failure: 0.
Stały interwał wysyłania (--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
==========================================================================
Gdy rozmiar komunikatu jest ustawiony na 0, OPC Publisher wewnętrznie partie danych przy użyciu największego obsługiwanego rozmiaru komunikatu IoT Hub, czyli 256 kB. Dane wyjściowe diagnostyki pokazują, że średni rozmiar komunikatu wynosi 115 019 bajtów. W tej konfiguracji Publisher OPC nie traci żadnych aktualizacji wartości węzła OPC i w porównaniu z wartością domyślną ma mniejsze opóźnienie.
Wyślij każdą aktualizację wartości węzła OPC (--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
==========================================================================
Ta konfiguracja wysyła dla każdej wartości węzła OPC zmianę komunikatu na IoT Hub. Diagnostyka pokazuje, że średni rozmiar komunikatu wynosi 234 bajty, co jest małe. Zaletą tej konfiguracji jest to, że Publisher OPC nie dodaje żadnych opóźnień. Liczba utraconych aktualizacji wartości węzła OPC (monitored item notifications enqueue failure: 44624) jest wysoka, co sprawia, że ta konfiguracja jest nieodpowiednia dla scenariuszy z dużą ilością danych telemetrycznych do opublikowania.
Maksymalna liczba partii (--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
==========================================================================
Ta konfiguracja wsaduje jak najwięcej aktualizacji wartości węzła OPC. Maksymalny IoT Hub rozmiar komunikatu to 256 kB, który jest skonfigurowany w tym miejscu. Nie zażądano interwału wysyłania, co oznacza, że ilość danych dla IoT Hub do pozyskiwania określa opóźnienie. Ta konfiguracja ma najmniejsze prawdopodobieństwo utraty wartości węzła OPC i jest odpowiednie do publikowania dużej liczby węzłów. Jeśli używasz tej konfiguracji, upewnij się, że scenariusz nie ma warunków, w których wprowadzono duże opóźnienie, jeśli rozmiar komunikatu o rozmiarze 256 kB nie zostanie osiągnięty.
Debugowanie aplikacji
Aby debugować aplikację, otwórz plik rozwiązania opcpublisher.sln z Visual Studio i użyj narzędzi debugowania Visual Studio.
Jeśli musisz uzyskać dostęp do serwera OPC UA w Publisher OPC, upewnij się, że zapora zezwala na dostęp do portu, na którym nasłuchuje serwer. Domyślny port to: 62222.
Zdalne sterowanie aplikacją
Konfigurowanie węzłów do publikowania można wykonać przy użyciu IoT Hub metod bezpośrednich.
Publisher OPC implementuje kilka dodatkowych IoT Hub wywołań metod bezpośrednich do odczytu:
- Informacje ogólne.
- Informacje diagnostyczne dotyczące sesji, subskrypcji i monitorowanych elementów OPC.
- Informacje diagnostyczne dotyczące komunikatów i zdarzeń IoT Hub.
- Dziennik uruchamiania.
- Ostatnie 100 wierszy dziennika.
- Zamknij aplikację.
Następujące repozytoria GitHub zawierają narzędzia do konfigurowania węzłów do publikowania i odczytywania informacji diagnostycznych. Oba narzędzia są również dostępne jako kontenery w Docker Hub.
Korzystanie z przykładowego serwera OPC UA
Jeśli nie masz rzeczywistego serwera OPC UA, możesz rozpocząć pracę przy użyciu przykładowego sterownika OPC UA PLC . Ten przykładowy sterownik PLC jest również dostępny w Docker Hub.
Implementuje on szereg tagów, które generują losowe dane i tagi z anomaliami. Możesz rozszerzyć przykład, jeśli chcesz symulować dodatkowe wartości tagów.
Następne kroki
Teraz, gdy wiesz już, jak uruchomić Publisher OPC, zalecane są następne kroki, aby dowiedzieć się więcej o bliźniaczej reprezentacji OPC i magazynie OPC.