Skip to main content

Cohérence des données en combinaison avec CODESYS Responsable de la communication

Important

Les informations de cette page concernent exclusivement les objets, les données et les méthodes publiés via le CODESYS aux éditeurs de Communication Manager (jeux de symboles IEC, modèles d'information OPC UA et configuration des symboles), et non au serveur OPC UA en général.

Le serveur OPC UA est un service qui s'exécute en arrière-plan de l'automate programmable. Les tâches du serveur OPC UA ont une priorité inférieure à celles des applications IEC. En raison des systèmes multitâches et multicœurs, les tâches du serveur OPC UA peuvent être interrompues par d'autres tâches. Il peut également arriver que les tâches IEC s'exécutent en parallèle avec les tâches du serveur OPC UA, ce qui peut entraîner des incohérences lors de la lecture ou de la modification des données. Ce chapitre a pour but de donner un aperçu des domaines dans lesquels la cohérence peut être garantie et des domaines dans lesquels elle ne le peut pas.

Accès aux données (lecture, écriture et échantillonnage)

Des données dont la cohérence est garantie

Tous les types de données scalaires d'une taille maximale de 8 octets sont lus et écrits de manière cohérente à partir des données IEC.

Données dont la cohérence n'est pas garantie

Cordes

Les chaînes sont lues et écrites caractère par caractère. Par conséquent, la cohérence d'une chaîne lue ou écrite ne peut être garantie.

Matrices

Les tableaux de lecture ou d'écriture sont gérés élément par élément. La logique de lecture ou d'écriture de base du type de données de base du tableau est utilisée. Si l'élément de base peut être traité de manière cohérente, tous les éléments du tableau seront également cohérents. Cependant, il n'est pas possible de garantir que les éléments du tableau déjà traités n'ont pas changé pendant le traitement du tableau complet.

Types de données structurées (STRUCT et FB)

lecture ou l'écriture des éléments d'une structure ou d'un bloc fonctionnel se fait élément par élément. Cela utilise la logique de lecture et d'écriture de base du type de données de base du membre. Si l'élément de base peut être traité de manière cohérente, le membre sera également cohérent. Cependant, il n'est pas possible de garantir que les membres déjà traités n'ont pas changé lors du traitement de la structure complète du bloc fonctionnel.

Combinaisons

Si des tableaux et des structures sont combinés, les règles ci-dessus s'appliquent au membre de structure ou à l'élément du tableau. La logique de lecture et d'écriture du type de données de base des éléments du tableau ou des membres de la structure est utilisée. Cela se traduit par le comportement général suivant :

  1. Valeurs de types de données simples (sauf STRING) et WSTRING) seront toujours cohérents, quel que soit l'endroit où ils sont placés.

  2. STRING et WSTRING leur cohérence n'est pas garantie.

  3. cohérence des structures et des réseaux n'est pas garantie. Cependant, les valeurs uniques qu'il contient sont cohérentes s'il s'agit d'un type de données simple.

Appels de méthode

Les paramètres d'entrée et de sortie (quels que soient le type de données, les tableaux ou les structures) sont transférés de manière cohérente depuis le serveur OPC UA vers l'appel de méthode ou depuis les sorties du rappel de méthode vers le serveur OPC UA. Ceci est garanti en utilisant la mémoire de pile du thread qui exécute l'appel de méthode. Cependant, la cohérence de l'accès aux données depuis le code des méthodes dans l'application IEC n'est pas garantie. Comme ces méthodes s'exécutent en même temps que les tâches des applications IEC, des mécanismes normaux de synchronisation de l'accès aux données peuvent être utilisés (par exemple, mutex, sémaphore

Dans cette section​: