s71500 Communication Function Manual FR-FR FR-FR

Communication
Avant-propos
Guide de la documentation
Descriptions fonctionnelles 1
2
SIMATIC Vue d'ensemble du produit
Services de communication 3
S7-1500, ET 200MP, ET 200SP,
ET 200AL, ET 200pro, 4
ET 200eco PN Communication PG
Communication
Communication IHM 5
Description fonctionnelle
Open User Communication 6
Communication S7 7
Couplage point à point 8
Communication OPC UA 9
Attribution d'adresses via
DHCP 10
Routage 11
Ressources de liaison 12
Diagnostic et suppression
des défauts 13
Communication avec le
système redondant 14
S7-1500R/H
Industrial Ethernet Security

avec CP 1543-1 15
05/2021
A5E03735816-AJ
Mentions légales
Signalétique d'avertissement
Ce manuel donne des consignes que vous devez respecter pour votre propre sécurité et pour éviter des dommages
matériels. Les avertissements servant à votre sécurité personnelle sont accompagnés d'un triangle de danger, les
avertissements concernant uniquement des dommages matériels sont dépourvus de ce triangle. Les
avertissements sont représentés ci-après par ordre décroissant de niveau de risque.
DANGER
signifie que la non-application des mesures de sécurité appropriées entraîne la mort ou des blessures graves.
ATTENTION
signifie que la non-application des mesures de sécurité appropriées peut entraîner la mort ou des blessures
graves.
PRUDENCE
signifie que la non-application des mesures de sécurité appropriées peut entraîner des blessures légères.
IMPORTANT
signifie que la non-application des mesures de sécurité appropriées peut entraîner un dommage matériel.
En présence de plusieurs niveaux de risque, c'est toujours l'avertissement correspondant au niveau le plus élevé
qui est reproduit. Si un avertissement avec triangle de danger prévient des risques de dommages corporels, le
même avertissement peut aussi contenir un avis de mise en garde contre des dommages matériels.
Personnes qualifiées
L’appareil/le système décrit dans cette documentation ne doit être manipulé que par du personnel qualifié pour
chaque tâche spécifique. La documentation relative à cette tâche doit être observée, en particulier les consignes
de sécurité et avertissements. Les personnes qualifiées sont, en raison de leur formation et de leur expérience, en
mesure de reconnaître les risques liés au maniement de ce produit / système et de les éviter.
Utilisation des produits Siemens conforme à leur destination
Tenez compte des points suivants:
ATTENTION
Les produits Siemens ne doivent être utilisés que pour les cas d'application prévus dans le catalogue et dans la
documentation technique correspondante. S'ils sont utilisés en liaison avec des produits et composants d'autres
marques, ceux-ci doivent être recommandés ou agréés par Siemens. Le fonctionnement correct et sûr des
produits suppose un transport, un entreposage, une mise en place, un montage, une mise en service, une
utilisation et une maintenance dans les règles de l'art. Il faut respecter les conditions d'environnement
admissibles ainsi que les indications dans les documentations afférentes.
Marques de fabrique
Toutes les désignations repérées par ® sont des marques déposées de Siemens AG. Les autres désignations dans ce
document peuvent être des marques dont l'utilisation par des tiers à leurs propres fins peut enfreindre les droits de
leurs propriétaires respectifs.
Exclusion de responsabilité
Nous avons vérifié la conformité du contenu du présent document avec le matériel et le logiciel qui y sont décrits.
Ne pouvant toutefois exclure toute divergence, nous ne pouvons pas nous porter garants de la conformité
intégrale. Si l'usage de ce manuel devait révéler des erreurs, nous en tiendrons compte et apporterons les
corrections nécessaires dès la prochaine édition.
Siemens AG A5E03735816-AJ Copyright © Siemens AG 2013 - 2021.

Digital Industries Ⓟ 04/2021 Sous réserve de modifications Tous droits réservés
Postfach 48 48
90026 NÜRNBERG
ALLEMAGNE
Avant-propos
Objet de cette documentation

Cette description fonctionnelle donne une vue d'ensemble des possibilités de communication
offertes par les CPU, les modules et processeurs de communication et les systèmes PC des
systèmes SIMATIC S7-1500, ET 200MP, ET 200SP, ET 200AL, ET 200pro et
SIMATIC Drive Controller. Cette description fonctionnelle traite de la communication
asynchrone orientée liaison.
La documentation aborde dans le détail les points suivants :
• Vue d'ensemble des services de communication
• Propriétés des services de communication
• Vue d'ensemble des activités de l'utilisateur servant à mettre en place les services de
communication
Connaissances de base requises

Pour bien exploiter les informations contenues dans la présente description fonctionnelle, les
connaissances suivantes sont nécessaires :
• Connaissances générales en technique d'automatisation
• Connaissances du système d'automatisation industriel SIMATIC
• Connaissances dans l'utilisation de STEP 7 (TIA Portal)
Domaine de validité de la documentation

La présente documentation sert de documentation de base pour tous les produits des
systèmes SIMATIC S7-1500, ET 200MP, ET 200SP, ET 200AL et ET 200pro. Les
documentations produits se basent sur la présente documentation et la complètent.
Communication
3 Description fonctionnelle, 05/2021, A5E03735816-AJ
Avant-propos
Nouveautés dans la description fonctionnelle Communication, édition 05/2021, par rapport à

l'édition 11/2019
Quelles sont les nouveautés ? Quels sont les avantages pour le client ? Où se trouvent les informations ?
Sécurité améliorée pour la com- • Possibilité d'identification univoque de Communication PG/IHM sécurisée
munication PG/IHM dans SIMATIC (Page 97)
chaque API sur la base de certificats indivi-
duels
• Protection supplémentaire de la confidentiali-
té par cryptage de la communication
• Protection des données de configuration API
par mots de passe individuels
Security Wizard pour des nou- • Configuration simple et rapide des nouveaux Protection des données de configu-
veaux mécanismes de sécurité de ration confidentielles (Page 64)
mécanismes de sécurité de l'API en une seule
l'API
opération
• Informations d'aide à la sélection des para-
mètres adaptés à votre cas d'application
Gestion de certificats par OPC UA • Mise à jour de certificats en cours d'exécution Gestion des certificats avec Global
(Global Discovery Server, GDS) Discovery Server (GDS) (Page 193)
• Prise en charge de listes de certificats révo-
qués (CRL)
• Protection d'accès pour gestion de certificats
Transmettre les messages de la • Grâce aux souscriptions, les clients peuvent Mettre à disposition des alarmes sur
CPU à des clients OPC UA le serveur OPC UA (Page 296)
s'abonner aux messages CPU comme "Alarms
and Conditions" du serveur OPC UA de la CPU.
• Les alarmes de programme avec variables
sont fournies par le serveur OPC UA
• Les alarmes avec obligation d'acquittement
peuvent être acquittées par le client OPC UA
(désactivable)
• Une avalanche de messages est signalée
comme "Overload" et les clients peuvent utili-
ser la méthode Refresh pour recharger les
messages.
Communication
Avant-propos
Affectation dynamique de la Utilisation de la CPU dans des réseaux informa- Attribution d'adresses via DHCP
configuration réseau par DHCP tiques grâce aux fonctions suivantes : (Page 376)
• Intégration de la CPU dans un réseau existant
sans configuration manuelle supplémentaire
de l'interface réseau
• Demande des paramètres réseau pour la CPU
selon RFC 2131 par un serveur DHCPv4
(adresse IP et masque de sous-réseau, adresse
IP de routeur par défaut et d'autres para-
mètres réseau facultatifs comme les adresses
de serveur DNS et NTP)
L'adressage basé sur le nom avec • La CPU peut obtenir les adresses de serveur DHCP avec DNS (Page 380)
DNS
DNS de la CPU via DHCP
• La CPU peut recevoir le nom d'hôte et le nom
de domaine d'un serveur DHCP pour les appli-
cations réalisées avec OPC UA ou (Secure)
OUC
• La CPU peut transmettre au serveur DHCP les
noms d'hôtes ou de domaines qui sont cou-
plés au serveur DNS pour une synchronisation
dynamique (Dynamic DNS)
• Le client NTP de la CPU peut communiquer
par nom avec le serveur NTP
• Les paramètres réseau peuvent être écrits
avec la nouvelle instruction "CommConfig",
par ex. paramètres d'adresse IP, serveur DNS,
hôte et nom de domaine
Communication
Description fonctionnelle, 05/2021, A5E03735816-AJ 5
Avant-propos
Quelles sont les nouveautés dans la description fonctionnelle Communication, édition 11/2019,
par rapport à l'édition 10/2018 ?
IP Forwarding Accès aisé depuis le niveau conduite jusqu'au IP Forwarding (Page 396)
niveau terrain pour la configuration et le paramé-
trage d'appareils, p. ex. via PDM ou navigateur
Web.
Extension du serveur OPC UA Pour les CPU S7-1500 à partir de la version de Chap. Communication OPC UA
firmware V2.8 et TIA Portal version 16, vous pou- (Page 159)
vez profiter des extensions suivantes du serveur
OPC UA intégré avec une licence Runtime corres-
pondante :
• Diagnostic amélioré : l'utilisateur d'OPC UA
reçoit des informations sur l'état du serveur
OPC UA par l'intermédiaire de messages dans
le tampon de diagnostic, d'une catégorie OPC
UA dans la zone en ligne et de diagnostics de
TIA Portal et d'un affichage amélioré des res-
sources de liaison.
• Comportement au téléchargement : Le ser-
veur OPC UA n'exécute un redémarrage en
mode RUN lors d'un téléchargement à partir
de TIA Portal que si les données récemment
chargées ont une incidence sur le jeu de don-
nées du serveur OPC UA.
• Modélisation de l'interface serveur : des inter-
faces de serveur peuvent désormais aussi être
modélisées dans TIA Portal, ou les spécifica-
tions OPC UA Companion peuvent être éga-
lement importées et mappées sur le jeu de
données de l'API.
Description de la communication Vous obtenez des informations sur les spécificités Chap. Communication avec le sys-
avec le système redondant de la communication avec le système redondant tème redondant S7-1500R/H
S7-1500R/H S7-1500R/H (Page 424)
Extension du domaine d'applica- Les fonctions que vous connaissez du système Manuel système Système redondant
tion de la description fonction- d'automatisation SIMATIC S7-1500 ont été mises S7-1500R/H
nelle au système redondant S7- en œuvre pour le système redondant S7- (https://support.industry.siemens.co
1500R/H 1500R/H. m/cs/ww/fr/view/109754833)
Communication
Avant-propos
OPC UA Companion Specification OPC UA Companion Specification permet de Chap. Configurer une interface ser-
spécifier des méthodes de manière homogène et veur OPC UA-Server (Page 254)
non propriétaire. Grâce à ces méthodes spéci-
fiées, vous pouvez intégrer plus aisément des
appareils de fabricants différents dans l'installa-
tion et dans des processus de production.
Liaison sécurisée à un serveur de Vous pouvez établir une liaison sécurisée à un Chap. Secure OUC par e-mail
messagerie via l'interface de la serveur de messagerie sans matériel supplémen- (Page 93)
CPU taire.
Communication sécurisée via Vous pouvez établir des liaisons TCP sécurisées Chap. Secure OUC avec Modbus TCP
Modbus TCP entre un client Modbus TCP et un serveur Modbus (Page 92)
TCP.
Serveur OPC UA OPC UA sont des normes d'architecture unifiée Chap. Communication OPC UA
pour l'échange de données, indépendantes des (Page 159)
plateformes de système d'exploitation.
OPC UA utilise des mécanismes de sécurité inté-
grés sur différents systèmes d'automatisation, par
ex. pour l'échange de données, au niveau de
l'application, pour la légitimation de l'utilisateur.
Le serveur OPC UA met à disposition de nom-
breuses données :
• Valeurs de variables AP auxquelles les clients
sont autorisés à accéder
• Types de données de ces variables AP
• Informations sur le serveur OPC UA lui-même
et sur la CPU
Cela permet aux clients d'avoir une vue d'en-
semble de la gestion des variables et de lire ou
d'écrire des valeurs.
Secure Open User Communica- Échange de données sécurisé avec d'autres appa- Chap. Secure Open User Communi-
tion reils. cation (Page 77)
Maniement de certificats dans Vous pouvez gérer des certificats dans STEP 7 Chap. Gestion de certificats avec
STEP 7 pour les applications suivantes : STEP 7 (Page 50)
• Serveur OPC UA
• Secure Open User Communication
• Serveur Web de la CPU
Désactiver SNMP pour la CPU Vous pouvez désactiver SNMP pour la CPU. Ceci Chap. Désactivation de SNMP
peut être judicieux dans certaines conditions, par (Page 109)
ex. quand les directives de sécurité de votre ré-
seau n'autorisent pas SNMP.
Communication
Avant-propos
Conventions
STEP 7 : ce manuel utilise l'expression "STEP 7" comme synonyme de "STEP 7 à partir de V12
(TIA Portal)" pour désigner le logiciel de configuration et de programmation.
Par "CPU S7-1500", on entend les modèles de CPU S7-1500F, S7-1500T, S7-1500TF,
S7-1500C, S7-1500R/H, S7-1500pro, ET200S, le contrôleur logiciel S7-1500 ainsi que
SIMATIC Drive Controller.
La présente documentation comprend des illustrations des appareils décrits. Les illustrations
peuvent différer dans le détail de l'appareil livré.
Tenez compte, en outre, des remarques identifiées de la façon suivante :
Remarque
Une remarque contient des informations importantes sur le produit, sur la manipulation du
produit ou sur la partie de la documentation à laquelle il faut être particulièrement attentif.
Voir aussi
Conditions requises pour une communication sécurisée (Page 64)
Note relative à la sécurité

Siemens commercialise des produits et solutions comprenant des fonctions de sécurité
industrielle qui contribuent à une exploitation sûre des installations, systèmes, machines et
réseaux.
Note relative à la sécurité

Pour garantir la sécurité des installations, systèmes, machines et réseaux contre les
cybermenaces, il est nécessaire de mettre en œuvre - et de maintenir en permanence - un
concept de sécurité industrielle global et de pointe. Les produits et solutions de Siemens
constituent une partie de ce concept.
Il incombe aux clients d'empêcher tout accès non autorisé à ses installations, systèmes,
machines et réseaux. Ces systèmes, machines et composants doivent uniquement être
connectés au réseau d'entreprise ou à Internet si et dans la mesure où cela est nécessaire et
seulement si des mesures de protection adéquates (ex : pare-feu et/ou segmentation du
réseau) ont été prises.
Pour plus d'informations sur les mesures de protection pouvant être mises en œuvre dans le
domaine de la sécurité industrielle, rendez-vous sur
(https://www.siemens.com/industrialsecurity).
Les produits et solutions Siemens font l'objet de développements continus pour être encore
plus sûrs. Siemens recommande vivement d'effectuer des mises à jour dès que celles-ci sont
disponibles et d'utiliser la dernière version des produits. L'utilisation de versions qui ne sont
plus prises en charge et la non-application des dernières mises à jour peut augmenter le
risque de cybermenaces pour nos clients.
Pour être informé des mises à jour produit, abonnez-vous au flux RSS Siemens Industrial
Security à l'adresse suivante (https://www.siemens.com/industrialsecurity) :
Communication
Avant-propos
Siemens Industry Online Support

Vous y trouvez rapidement et facilement des informations actuelles sur les thèmes suivants :
• Support produit
Toutes les informations et un know-how complet sur votre produit, des caractéristiques
techniques, des FAQ, des certificats, des téléchargements et des manuels.
• Exemples d'application
Des outils et des exemples pour vous permettre d'exécuter vos tâches d'automatisation -
également des blocs fonctionnels, des données sur la performance et des vidéos.
• Services
Des informations sur Industry Services, Field Services, l'assistance technique, les pièces de
rechange et l'offre de formations.
• Forums
Pour obtenir des réponses et des solutions aux questions sur la technique
d'automatisation.
• mySupport
Votre espace personnel dans Siemens Industry Online Support, pour avoir accès à des
notifications, poser des questions à l'assistance et obtenir des documents configurables.
Ces informations vous sont fournies par Siemens Industry Online Support sur Internet
(http://www.siemens.com/automation/service&support).
Industry Mall
L'Industry Mall est le catalogue et le système de commande de Siemens AG pour les solutions
d'automatisation et d'entraînements sur la base de Totally Integrated Automation (TIA) et
Totally Integrated Power (TIP).
Vous trouverez les catalogues de tous les produits des techniques d'automatisation et
d'entraînement sur Internet (https://mall.industry.siemens.com).
Communication
Sommaire
Avant-propos ......................................................................................................................................... 3
1 Guide de la documentation Descriptions fonctionnelles .................................................................... 15
2 Vue d'ensemble du produit ................................................................................................................. 20
3 Services de communication ................................................................................................................. 25
3.1 Vue d'ensemble des possibilités de communication ............................................................ 25
3.2 Protocoles de communication et numéros de port utilisés pour communication
Ethernet ............................................................................................................................ 28
3.3 Vue d'ensemble des ressources de liaison ........................................................................... 33
3.4 Création d'une liaison ........................................................................................................ 33
3.5 Cohérence des données ..................................................................................................... 37
3.6 Secure Communication ...................................................................................................... 40
3.6.1 Principes de base sur la communication sécurisée .............................................................. 40
3.6.1.1 Principes de base sur la communication sécurisée .............................................................. 40
3.6.1.2 Confidentialité par cryptage ............................................................................................... 44
3.6.1.3 Authenticité et intégrité grâce aux signatures .................................................................... 46
3.6.1.4 Gestion de certificats avec STEP 7....................................................................................... 50
3.6.1.5 Exemples de gestion de certificats ...................................................................................... 54
3.6.1.6 Exemple : HTTP over TLS .................................................................................................... 60
3.6.2 Conditions requises pour une communication sécurisée ..................................................... 64
3.6.2.1 Protection des données de configuration confidentielles .................................................... 64
3.6.2.2 Informations utiles sur la protection des données de configuration API confidentielles ........ 67
3.6.2.3 Modifier le mot de passe .................................................................................................... 68
3.6.2.4 Réinitialiser le mot de passe ............................................................................................... 70
3.6.2.5 Affecter un mot de passe par le biais d'une carte mémoire SIMATIC .................................... 72
3.6.2.6 Particularités lors de la sauvegarde et de la restauration d'une CPU ..................................... 73
3.6.2.7 Conseils pour éviter les erreurs et traitement des défauts ................................................... 74
3.6.2.8 Règles pour le remplacement de la CPU .............................................................................. 76
3.6.3 Secure Open User Communication ..................................................................................... 77
3.6.3.1 Secure OUC d'une CPU S7-1500 comme client TLS à un AP tiers (serveur TLS) ..................... 77
3.6.3.2 Secure OUC d'une CPU S7-1500 comme serveur TLS à un AP tiers (client TLS) ..................... 79
3.6.3.3 Secure OUC entre deux CPU S7-1500 ................................................................................. 83
3.6.3.4 Secure Open User Communication par l'interface CP........................................................... 87
3.6.3.5 Secure OUC avec Modbus TCP ............................................................................................ 92
3.6.3.6 Secure OUC par e-mail ....................................................................................................... 93
3.6.4 Communication PG/IHM sécurisée ...................................................................................... 97
3.6.4.1 Communication PG/IHM sur la base de mécanismes de sécurité normalisés......................... 97
3.6.4.2 Autres paramètres pour la communication PG/IHM sécurisée .............................................. 99
3.6.4.3 Conseil pour la communication basée sur certificat entre PG et CPU .................................. 101
3.6.4.4 Comportement de la CPU du chargement jusqu'à l'état prêt à fonctionner ........................ 103
3.6.4.5 Utiliser la communication IHM sécurisée .......................................................................... 105
3.6.4.6 Utiliser la communication PG/PC classique pour TIA Portal................................................. 107
3.6.4.7 Informations relatives à la compatibilité ........................................................................... 108
Communication
Sommaire
3.7 SNMP .............................................................................................................................. 109

3.7.1 Désactivation de SNMP .................................................................................................... 109
3.7.2 Exemple : Désactivation de SNMP pour une CPU 1516-3 PN/DP ......................................... 110
4 Communication PG ............................................................................................................................ 113
5 Communication IHM .......................................................................................................................... 116
6 Open User Communication................................................................................................................ 118
6.1 Vue d'ensemble d'Open User Communication................................................................... 118
6.2 Protocoles pour Open User Communication ..................................................................... 119
6.3 Instructions pour Open User Communication ................................................................... 121
6.4 Open User Communication avec adressage par le nom de domaine .................................. 125
6.5 Configurer Open User Communication par TCP, ISO-on-TCP, UDP et ISO ............................ 128
6.6 Configuration de la communication via FDL...................................................................... 135
6.7 Créer une communication via Modbus TCP ....................................................................... 138
6.8 Configurer la communication par e-mail........................................................................... 141
6.9 Configurer la communication FTP..................................................................................... 142
6.10 Etablissement et interruption de liaisons de communication ............................................. 145
7 Communication S7............................................................................................................................. 146
8 Couplage point à point ...................................................................................................................... 154
9 Communication OPC UA .................................................................................................................... 159
9.1 Informations utiles sur OPC UA......................................................................................... 159
9.1.1 OPC UA et Industrie 4.0.................................................................................................... 159
9.1.2 Caractéristiques générale d'OPC UA .................................................................................. 160
9.1.3 OPC UA pour CPU S7-1200/S7-1500 ................................................................................. 163
9.1.4 Accès aux applications OPC UA ......................................................................................... 165
9.1.5 Adressage des nœuds ...................................................................................................... 169
9.1.6 Informations utiles sur les clients OPC UA ......................................................................... 173
9.1.7 Mappage de types de données ......................................................................................... 177
9.2 Sécurité avec OPC UA ....................................................................................................... 180
9.2.1 Paramètres de sécurité ..................................................................................................... 180
9.2.2 Certificats conformes à la norme X.509 de l'UIT ................................................................ 182
9.2.3 Certificats sur OPC UA ...................................................................................................... 185
9.2.4 Création de certificats autosignés ..................................................................................... 186
9.2.5 Créer soi-même une paire de clés PKI et des certificats...................................................... 187
9.2.6 Transmission sécurisée de messages ................................................................................ 190
9.2.7 Gestion des certificats avec Global Discovery Server (GDS) ................................................ 193
9.2.7.1 Gestion automatisée des certificats avec GDS ................................................................... 193
9.2.7.2 Quantité de données admissible pour la fonction push ..................................................... 196
9.2.7.3 Définition et chargement des paramètres GDS.................................................................. 197
9.2.7.4 Mise en service GDS ......................................................................................................... 198
9.2.7.5 Modèle d'adresse pour la gestion de certificats push ......................................................... 204
9.2.7.6 CertificateGroups dans le modèle d'adresse ...................................................................... 208
Communication
Sommaire
9.3 Utilisation de la CPU S7-1500 comme serveur OPC UA ...................................................... 210

9.3.1 Informations sur le serveur OPC UA des CPU S7-1500 ....................................................... 210
9.3.1.1 Le serveur OPC UA des CPU S7-1500 ................................................................................ 210
9.3.1.2 Nœuds d'extrémité du serveur OPC UA ............................................................................. 213
9.3.1.3 Comportement du serveur OPC UA en service .................................................................. 216
9.3.2 Configurer l'accès aux variables API .................................................................................. 219
9.3.2.1 Gestion des droits de lecture et d'écriture ......................................................................... 219
9.3.2.2 Gestion des droits en écriture et en lecture pour DB complet ............................................ 221
9.3.2.3 Coordination des droits de lecture et d'écriture pour les variables CPU .............................. 222
9.3.2.4 Cohérence des variables CPU ........................................................................................... 224
9.3.2.5 Possibilités d'accès au données fournies par le serveur OPC UA ......................................... 227
9.3.2.6 Attribut MinimumSamplingInterval .................................................................................. 228
9.3.2.7 Exporter fichier XML OPC UA ............................................................................................ 228
9.3.3 Configurer le serveur OPC UA ........................................................................................... 229
9.3.3.1 Activer le serveur OPC UA ................................................................................................ 229
9.3.3.2 Accès au serveur OPC UA ................................................................................................. 231
9.3.3.3 Paramètres généraux du serveur OPC UA ......................................................................... 233
9.3.3.4 Paramètres du serveur pour souscriptions ........................................................................ 235
9.3.3.5 Utilisation des certificats du client et du serveur ............................................................... 238
9.3.3.6 Création de certificats de serveur avec STEP 7................................................................... 244
9.3.3.7 Authentification de l'utilisateur ........................................................................................ 247
9.3.3.8 Utilisateur et rôles avec les droits de fonction OPC UA ...................................................... 249
9.3.3.9 Paramètres de diagnostic du serveur ................................................................................ 252
9.3.3.10 Licences pour OPC UA ...................................................................................................... 253
9.3.4 Configurer une interface serveur OPC UA-Server............................................................... 254
9.3.4.1 Qu'est-ce qu'une interface serveur ? ................................................................................. 254
9.3.4.2 Utilisation de spécifications OPC UA Companion ............................................................... 256
9.3.4.3 Créer une interface serveur pour la spécification Companion ............................................ 264
9.3.4.4 Créer une interface serveur personnalisée ........................................................................ 270
9.3.4.5 Types de données pour les spécifications Companion ....................................................... 276
9.3.4.6 Règles valables pour les fichiers XML OPC UA ................................................................... 280
9.3.4.7 Créer une interface serveur pour un espace de noms de référence .................................... 281
9.3.4.8 Créer des nœuds OPC UA sur la base des mappages de données locales de types de FB
et d'UDT .......................................................................................................................... 285
9.3.4.9 Remarques sur les capacités fonctionnelles avec les interfaces serveur ............................. 288
9.3.5 Fournir des méthodes sur le serveur OPC UA .................................................................... 290
9.3.5.1 Informations utiles sur les méthodes de serveur ............................................................... 290
9.3.5.2 Conditions annexes pour l'utilisation de méthodes de serveur .......................................... 294
9.3.6 Mettre à disposition des alarmes sur le serveur OPC UA .................................................... 296
9.3.6.1 Informations utiles sur les alarmes ................................................................................... 296
9.3.6.2 OPC UA Events ................................................................................................................. 301
9.3.6.3 Conditions OPC UA et alarmes OPC UA ............................................................................. 305
9.3.6.4 Activer Alarms and Conditions ......................................................................................... 307
9.3.6.5 S'abonner aux événement d'un serveur OPC UA ............................................................... 308
9.3.6.6 Méthodes pour OPC UA Alarms and Conditions ................................................................ 310
9.3.6.7 Travailler avec les limites de mémoire pour OPC UA Alarms and Conditions....................... 315
9.3.7 Utiliser les possibilités de diagnostic ................................................................................. 318
9.3.7.1 Diagnostic du serveur OPC UA .......................................................................................... 318
9.3.7.2 Diagnostiquer les changements d'état du serveur ............................................................. 320
9.3.7.3 Diagnostiquer les changements d'état de la session .......................................................... 322
9.3.7.4 Contrôler les événements de sécurité ............................................................................... 323
9.3.7.5 Échec de la requête d'un client distant ............................................................................. 323
Communication
Sommaire
9.3.7.6 Diagnostiquer les abonnements ....................................................................................... 325

9.3.7.7 Résumer les diagnostics ................................................................................................... 329
9.4 Utilisation d'une CPU S7-1500 comme client OPC UA ........................................................ 331
9.4.1 Vue d'ensemble et conditions........................................................................................... 331
9.4.2 Généralités sur les instructions client................................................................................ 332
9.4.3 Nombre d'instructions client utilisables simultanément .................................................... 335
9.4.4 Exemple de configuration pour OPC UA ............................................................................ 336
9.4.5 Création d'interfaces client ............................................................................................... 338
9.4.6 Déterminer l'interface serveur en ligne ............................................................................. 347
9.4.7 Utiliser des textes multilingues ......................................................................................... 352
9.4.8 Règles d'accès à des structures ......................................................................................... 354
9.4.9 Utiliser le paramétrage de liaison ..................................................................................... 355
9.4.9.1 Création et paramétrage de liaisons ................................................................................. 355
9.4.9.2 Manipulation des certificats de client de la CPU S7-1500................................................... 360
9.4.9.3 Authentification de l'utilisateur ........................................................................................ 363
9.4.9.4 Utilisation d'une liaison paramétrée ................................................................................. 364
9.5 Conseils et recommandations .......................................................................................... 372
9.5.1 Règles relatives aux souscriptions ..................................................................................... 372
9.5.2 Règles pour le programme utilisateur ............................................................................... 373
9.5.3 Modèles de copie pour la communication OPC UA ............................................................ 374
10 Attribution d'adresses via DHCP ........................................................................................................ 376
10.1 Principe de l'attribution d'adresses via DHCP ..................................................................... 378
10.2 DHCP avec DNS ................................................................................................................ 380
10.3 Activer DHCP ................................................................................................................... 385
10.4 Configurer l'ID client ........................................................................................................ 386
10.5 Recevoir les adresses des serveurs DNS par DHCP ............................................................. 387
10.6 Recevoir les adresses des serveurs NTP par DHCP .............................................................. 388
10.7 Recevoir le nom d'hôte et le domaine par DHCP ................................................................ 388
11 Routage.............................................................................................................................................. 390
11.1 Vue d'ensemble des mécanismes de routage des CPU S7-1500 ......................................... 390
11.2 Routage S7 ...................................................................................................................... 391
11.3 IP Forwarding .................................................................................................................. 396
11.4 Routage d'enregistrement ................................................................................................ 403
11.5 Interface virtuelle pour applications à base IP ................................................................... 405
12 Ressources de liaison ......................................................................................................................... 409
12.1 Ressources de liaison d'une station ................................................................................... 409
12.2 Affectation de ressources de liaison ................................................................................. 412
12.3 Affichage des ressources de liaison .................................................................................. 416
13 Diagnostic et suppression des défauts .............................................................................................. 420
13.1 Diagnostic de liaisons....................................................................................................... 420
13.2 Adresse de secours .......................................................................................................... 423
Communication
Sommaire
14 Communication avec le système redondant S7-1500R/H .................................................................. 424

14.1 Adresses IP système ......................................................................................................... 425
14.2 Comportement en cas de SyncUp ..................................................................................... 431
14.3 Comportement en cas de commutation entre CPU principale/réserve ................................ 431
14.4 Ressources de liaison du système redondant S7-1500R/H ................................................. 432
14.5 Communication HMI avec le système redondant S7-1500R/H ........................................... 433
14.5.1 Configurer une liaison HMI via l'adresse IP système .......................................................... 433
14.6 Open User Communication avec le système redondant S7-1500R/H .................................. 436
14.6.1 Configurer la liaison de la communication Open User Communication avec le système
redondant S7-1500R/H .................................................................................................... 436
15 Industrial Ethernet Security avec CP 1543-1 ..................................................................................... 442
15.1 Firewall ........................................................................................................................... 443
15.2 Enregistrement ................................................................................................................ 444
15.3 Client NTP........................................................................................................................ 444
15.4 SNMP .............................................................................................................................. 445
15.5 VPN ................................................................................................................................. 445
Glossaire ............................................................................................................................................ 446
Index .................................................................................................................................................. 459
Communication
Guide de la documentation Descriptions
fonctionnelles 1
La documentation pour le système d'automatisation SIMATIC S7-1500, les
CPU 1513/1516pro-2 PN basées sur SIMATIC S7-1500 et les systèmes de périphérie
décentralisée SIMATIC ET 200MP, ET 200SP et ET 200AL se compose de trois parties.
Cette répartition vous permet d'accéder de manière ciblée aux contenus souhaités.
Informations de base
Les manuels système et la mise en route Getting Started décrivent en détail la configuration,
le montage, le câblage et la mise en service des systèmes SIMATIC S7-1500, ET 200MP,
ET 200SP et ET 200AL. Pour les CPU 1513/1516pro-2 PN, référez-vous aux instructions de
service correspondantes. L'aide en ligne de STEP 7 vous assiste dans la configuration et la
programmation.
Informations sur les appareils

Les manuels contiennent une description compacte des informations spécifiques aux
modules, telles que les propriétés, les schémas de raccordement, les courbes caractéristiques,
les caractéristiques techniques.
Communication
Guide de la documentation Descriptions fonctionnelles
Informations globales
Vous trouverez dans les descriptions fonctionnelles des descriptions détaillées sur des sujets
transversaux, p. ex. le diagnostic, la communication, Motion Control, le serveur Web,
OPC UA.
Vous pouvez télécharger gratuitement la documentation sur Internet
(https://support.industry.siemens.com/cs/ww/fr/view/109742705).
Les modifications et compléments apportés aux manuels sont documentés dans des
informations produit.
Vous trouverez les informations produit sur Internet.
• S7-1500/ET 200MP (https://support.industry.siemens.com/cs/fr/fr/view/68052815)
• ET 200SP (https://support.industry.siemens.com/cs/fr/fr/view/73021864)
Collections de manuels (Manual Collections)

Les collections de manuels contiennent dans un fichier la documentation complète relative
aux systèmes.
Vous trouverez les collections de manuels sur Internet.
• S7-1500/ET 200MP (https://support.industry.siemens.com/cs/ww/fr/view/86140384)
• ET 200SP (https://support.industry.siemens.com/cs/ww/fr/view/84133942)
• ET 200AL (https://support.industry.siemens.com/cs/ww/fr/view/95242965)
"mySupport"
Votre espace de travail personnel "mySupport" vous permet de tirer au mieux profit de votre
Industry Online Support.
Dans "mySupport", vous pouvez enregistrer filtres, favoris et tags, demander des données CAx
et constituer dans le volet Documentation votre bibliothèque personnelle. De plus, en cas de
demande d'assistance, vos coordonnées sont déjà renseignées et vous pouvez consulter à
tout moment l'état d'avancement de vos demandes.
Pour bénéficier de toutes les fonctions de "mySupport", vous devez vous enregistrer.
Vous trouverez "mySupport" sur Internet (https://support.industry.siemens.com/My/ww/fr).
"mySupport" - Documentation
Votre espace de travail personnel "mySupport" vous permet de tirer au mieux profit de votre
Industry Online Support.
Dans "mySupport", vous pouvez enregistrer filtres, favoris et tags, demander des données CAx
et constituer dans le volet Documentation votre bibliothèque personnelle. De plus, en cas de
demande d'assistance, vos coordonnées sont déjà renseignées et vous pouvez consulter à
tout moment l'état d'avancement de vos demandes.
Pour bénéficier de toutes les fonctions de "mySupport", vous devez vous enregistrer.
Vous trouverez "mySupport" sur Internet
(https://support.industry.siemens.com/My/ww/fr/documentation).
Communication
"mySupport" - Données CAx

La rubrique Données CAx de "mySupport" vous donne accès aux données de produit actuelles
pour votre système CAx ou CAe.
Quelques clics suffisent pour configurer votre pack à télécharger personnel.
Vous pouvez faire votre choix parmi :
• Des images de produit, des plans cotés 2D, des modèles 3D, des schémas de connexion
des appareils, des fichiers macro EPLAN
• manuels, caractéristiques, instructions de service, certificats
• Données de base des produits
Vous trouverez "mySupport" - Données CAx sur Internet
(https://support.industry.siemens.com/my/ww/fr/CAxOnline).
Exemples d'application
Les exemples d'application mettent à votre disposition différents outils et exemples pour la
résolution de vos tâches d'automatisation. Les solutions sont représentées en interaction avec
plusieurs composants dans le système - sans se focaliser sur des produits individuels.
Vous trouverez les exemples d'application sur Internet
(https://support.industry.siemens.com/cs/ww/fr/ps/ae).
TIA Selection Tool

TIA Selection Tool permet de sélectionner, configurer et commander des appareils pour
Totally Integrated Automation (TIA).
En tant que successeur de SIMATIC Selection Tool, il regroupe dans un même outil les
configurateurs pour la technique d'automatisation bien connus.
TIA Selection Tool permet de générer une liste de commande complète à partir de votre
sélection ou configuration de produits.
Vous trouverez TIA Selection Tool sur Internet
(https://support.industry.siemens.com/cs/ww/fr/view/109767888/en).
Communication
SIMATIC Automation Tool

SIMATIC Automation Tool permet de d'exécuter simultanément des tâches de mise en service
et de maintenance de masse sur différentes stations SIMATIC S7 indépendamment de TIA
Portal.
SIMATIC Automation Tool propose de nombreuses fonctions :
• Scan d'un réseau procédé PROFINET/Ethernet et identification de toutes les CPU
connectées.
• Affectation d'adresses (IP, sous-réseau, passerelle) et nom de station (appareil PROFINET)
à une CPU
• Transmission de la date et de l'heure de PG/PC convertie en heure UTC sur le module
• Chargement du programme sur la CPU
• Commutation du mode de fonctionnement MARCHE/ARRÊT
• Localisation de la CPU par clignotement de LED
• Lecture des informations d'erreur de la CPU
• Lecture du tampon de diagnostic de la CPU
• Réinitialisation aux réglages usine
• Mise à jour du firmware de la CPU et des modules raccordés
Vous trouverez l'outil SIMATIC Selection Tool sur Internet
PRONETA
Avec SIEMENS PRONETA (analyse réseau PROFINET), vous analysez le réseau procédé dans le
cadre de la mise en service. PRONETA dispose de deux fonctions centrales :
• La vue d'ensemble de la topologie scanne automatiquement PROFINET et tous les
composants raccordés.
• La vérification des E/S (IO Check) est un test rapide du câblage et de la configuration des
modules d'une installation.
Vous trouverez SIEMENS PRONETA sur Internet
Communication
SINETPLAN
SINETPLAN, le planificateur de réseau de Siemens, vous assiste lorsque vous planifiez des
installations et des réseaux d'automatisation sur la base de PROFINET. Cet outil simplifie dès
l'ingénierie le dimensionnement prévisionnel de l'installation PROFINET. Il vous aide en outre
à optimiser le réseau, à en exploiter au mieux les ressources et à prévoir les réserves
nécessaires. Vous évitez ainsi, dès la planification, des problèmes lors de la mise en service ou
des défaillances en mode de production. Cela augmente la disponibilité de la production et
contribue à l'amélioration de la sécurité de fonctionnement.
Les avantages en bref
• Optimisation du réseau grâce au calcul de la charge du réseau pour chaque port
• Disponibilité accrue en production par une analyse en ligne et une vérification des
installations existantes
• Transparence avant la mise en service grâce à l'importation et à la simulation de projets
STEP 7 existants
• Efficience grâce à la pérennité garantie des investissements et exploitation optimale des
ressources
Vous trouverez SINETPLAN sur Internet (https://www.siemens.com/sinetplan).
Communication
Vue d'ensemble du produit 2
Les CPU, les modules et processeurs de communication et les systèmes PC des systèmes
S7-1500, ET 200MP, ET 200SP, ET 200pro et ET 200AL vous offrent des interfaces pour
communiquer via PROFINET, PROFIBUS et le couplage point à point.
CPU, modules de communication et processeurs de communication

Des interfaces PROFINET et PROFIBUS DP sont intégrées dans les CPU S7-1500. La
CPU 1516-3 PN/DP dispose par exemple de deux interfaces PROFINET et d'une interface
PROFIBUS DP. D'autres interfaces PROFINET et PROFIBUS DP sont disponibles grâce à des
modules de communication (CM) et des processeurs de communication (CP).
① Interface PROFINET(X2) avec 1 port

② Interface PROFINET(X1) avec commutateur à 2 ports
③ Interface PROFIBUS DP (X3)
④ Interface PROFINET (X1) avec commutateur à 3 ports
Figure 2-1 Interfaces de la CPU 1516-3 PN/DP et de CPU 1512SP-1 PN
Communication
Vue d'ensemble du produit
Interfaces de modules de communication

Les interfaces des modules de communication (CM) ajoutent des interfaces aux CPU (le
module CM 1542-5, par exemple, ajoute une interface PROFIBUS au système
d'automatisation S7-1500).
① Interface PROFIBUS DP
Figure 2-2 Interface PROFIBUS DP des CM 1542-5 et CM DP (dans une CPU ET 200SP)
Communication
Interfaces de processeurs de communication

Les interfaces des processeurs de communication (CP) ajoutent des fonctions aux interfaces
intégrées des CPU. Les CP couvrent des cas d'application spéciaux, le CP 1543-1 par ex.
propose via son interface Industrial Ethernet des fonctions de sécurité pour protéger les
réseaux Industrial Ethernet.
① Interface Industrial Ethernet
Figure 2-3 Interface Industrial Ethernet du CP 1543-1
Communication
Interfaces de modules de communication pour le couplage point à point

Les modules de communication pour le couplage point à point vous offrent une
communication via leurs interfaces RS232, RS422 et RS485, par ex. la communication
Freeport ou Modbus.
① Interface pour le couplage point-à-point
Figure 2-4 Exemple d'interface pour couplage point à point sur le CM PtP RS422/485 BA
Communication
Interfaces de modules d'interface

Les interfaces PROFINET et PROFIBUS DP des modules d'interface (IM) dans l'ET 200MP,
ET 200SP et ET 200AL servent à connecter la périphérie décentralisée ET 200MP, ET 200SP et
ET 200AL au PROFINET ou PROFIBUS du contrôleur IO ou maître DP de niveau supérieur.
① Interface PROFINET avec commutateur à 2 ports
Figure 2-5 Interfaces PROFINET IM 155-5 PN ST (ET 200MP), IM 155-6 PN ST (ET 200SP) et IM 157-
1 PN (ET 200AL)
Services de communication
Les services de communication décrits ci-dessous utilisent les interfaces et les mécanismes de
communication que le système vous offre par des CPU, des modules de communication et
des processeurs de communication.
Communication
Services de communication 3
3.1 Vue d'ensemble des possibilités de communication
Vue d'ensemble des possibilités de communication

Vous disposez des possibilités de communication suivantes pour votre tâche
d'automatisation.
Tableau 3- 1 Possibilités de communication
Possibilités de communication Fonctionnalité Via l'interface :

PN/IE1 DP série
Communication PG2 Pour la mise en service, le test, le diagnostic X X -
Communication IHM2 Pour le contrôle-commande X X -
Communication ouverte par protocole Échange de données via X - -
TCP/IP2 PROFINET/Industrial Ethernet avec TCP/IP
Instructions :
• TSEND_C/TRCV_C
• TSEND/TRCV
• TCON
• T_DISCON
Communication ouverte par ISO-on-TCP2 Échange de données via X - -
PROFINET/Industrial Ethernet avec ISO-on-TCP
Instructions :
• TSEND_C/TRCV_C
• TSEND/TRCV
• TCON
• T_DISCON
Communication ouverte via UDP2 Échange de données via X - -
PROFINET/Industrial Ethernet avec UDP
Instructions :
• TSEND_C/TRCV_C
• TUSEND/TURCV
• TCON
• T_DISCON
Communication

Communication ouverte par ISO (seule- Échange de données via X - -
ment CP avec interface PROFINET/Industrial Ethernet avec protocole ISO
PROFINET/Industrial Ethernet) Instructions :
• TSEND_C/TRCV_C
• TSEND/TRCV
• TCON
• T_DISCON
Communication ouverte par FDL (uni- Échange de données via PROFIBUS avec le protocole - X -
quement CM 1542-5 à partir de la ver- FDL
sion V2.0 du firmware) Instructions :
• TSEND_C/TRCV_C
• TSEND/TRCV
• TUSEND/TURCV
• TCON
• T_DISCON
Serveur OPC UA3 Échange de données avec clients OPC UA X - -
Communication par Modbus TCP Échange de données via PROFINET avec le protocole X - -
Modbus TCP
Instructions :
• MB_CLIENT
• MB_SERVER
E-mail Envoi de messages du processus par e-mail X - -
Instruction :
• TMAIL_C
FTP (seulement CP avec interface Gestion des fichiers et accès à ces derniers par FTP X - -
PROFINET/Industrial Ethernet) (File Transfer Protocol) ; le CP peut être client et
serveur FTP
Instruction :
• FTP_CMD
Fetch/Write (seulement CP avec interface Services de serveur par TCP/IP, ISO-on-TCP et ISO X - -
PROFINET/Industrial Ethernet) Avec des instructions spéciales pour Fetch/Write
Communication S7 Échange de données via PROFINET/PROFIBUS avec le X X -
protocole S7.
Instructions :
• PUT/GET
• BSEND/BRCV
• USEND/URCV
Couplage point à point série Échange de données point à point avec protocole - - X
Freeport, 3964(R), USS ou Modbus
Avec instructions spéciales pour PtP, USS ou
Modbus RTU
Serveur Web Échange de données par HTTP(S), par ex. pour le X - -
diagnostic
Communication

SNMP (Simple Network Management Pour la surveillance et la détection d'erreur des ré- X - -
Protocol) seaux IP, le cas échéant paramétrage des consti-
tuants de réseau IP avec protocole standard SNMP
Synchronisation de l'heure Via l'interface PN/IE : la CPU est un client NTP (Net- X - -
work Time Protocol)
Via l'interface DP : CPU/CM/CP est maître horaire ou - X -
esclave horaire
1 IE - Industrial Ethernet
2 Prenez en compte les spécificités pour S7-1500R/H
3 uniquement via l'interface PROFINET interne de la CPU et via l'interface Ethernet du CP 1543-1 avec la fonction "Accès à
l'API via module de communication" activée
Informations sur le système S7-1500R/H

Vous trouverez des informations sur les possibilités de communication avec le système
redondant S7-1500R/H au paragraphe Communication avec le système redondant
S7-1500R/H (Page 1).
Informations complémentaires
• Exemple d'application : communication CPU-CPU avec contrôleurs SIMATIC (compendium)
Vous trouverez cet exemple d'application sur Internet
• Pour configurer la communication Fetch/Write par un CP1543-1 dans la S7-1500, voir
cette FAQ (https://support.industry.siemens.com/cs/ww/fr/view/102420020).
• Pour plus d'informations sur les services Fetch/Write, voir l'aide en ligne STEP 7.
• Pour plus d'informations sur le couplage PtP, voir la description fonctionnelle
Configurations CM PtP pour des couplages point à point
(http://support.automation.siemens.com/WW/view/fr/59057093).
• Pour les fonctions du serveur Web, voir la description fonctionnelle Serveur Web
• Pour s'informer sur le protocole standard SNMP, voir les pages Service & Support sur
Internet (http://support.automation.siemens.com/WW/view/fr/15166742).
• Pour s'informer sur la synchronisation de l'heure, voir cette FAQ
Communication
3.2 Protocoles de communication et numéros de port utilisés pour communication Ethernet
3.2 Protocoles de communication et numéros de port utilisés pour

communication Ethernet
Ce paragraphe fournit un aperçu des protocoles pris en charge et des numéros de port utilisés
pour la communication via des interfaces PN/IE. Les paramètres d'adresse, la couche de
communication concernée, ainsi que le rôle et le sens de communication sont indiqués pour
chaque protocole.
Ces informations vous permettront d'harmoniser avec les protocoles utilisés les mesures de
sécurité protégeant le système d'automatisation (pare-feu, par ex.). Comme les mesures de
sécurité se limitent aux réseaux Ethernet ou PROFINET, les tableaux ne mentionnent pas de
protocoles PROFIBUS.
Remarque
Numéros de port utilisés
Les numéros de port indiqués sont les numéros de port utilisés par défaut par la CPU
S7-1500. Une grande quantité de protocoles de communications ou d'implémentations vous
permettent d'utiliser d'autres numéros de port.
Les tableaux suivants indiquent les couches et les protocoles mis en œuvre dans les CPU
S7-1500 et dans les modules de communication S7-1500.
Le tableau suivant indique les protocoles pris en charge par les CPU S7-1500, les CPU ET
200SP et les CPU 1513/1516pro-2 PN. Les contrôleurs logiciels S7-1500 prennent également
en charge les protocoles indiqués dans le tableau suivant pour les interfaces Ethernet qui leur
sont affectées.
Tableau 3- 2 Couches et protocoles des CPU et contrôleurs logiciels S7-1500 (par l'interface PROFINET de la CPU)
Protocole Numéro de (2) Couche liai- Fonction Description

port son
(4) Couche
transport
Protocoles PROFINET
DCP Non signifi- (2) Ethertype Abonnés ac- PROFINET utilise DCP pour déterminer les appareils
Discovery and catif 0x8892 cessibles, PROFINET et permettre les paramétrages de base.
basic configu- (PROFINET) PROFINET
ration protocol Discovery and
configuration
LLDP Non signifi- (2) Ethertype PROFINET Link PROFINET utilise LLDP pour déterminer et gérer les
Link Layer catif 0x88CC (LLDP) Layer Discove- relations de voisinage entre appareils PROFINET.
Discovery ry protocol LLDP utilise l'adresse MAC multicast spéciale : 01-80-
protocol C2-00-00-0E
MRP Non signifi- (2) Ethertype PROFINET MRP permet de commander des voies de transmission
Media Redun- catif 0x88E3 (CEI medium re- redondantes par une topologie en anneau.
dancy Protocol 62493-2-2010) dundancy MRP utilise des adresses MAC multicast conforme aux
normes.
Communication

port son
(4) Couche
transport
PTCP Non signifi- (2) Ethertype PROFINET PTCP permet une mesure du décalage entre ports RJ45
Precision catif 0x8892 send clock and et donc la synchronisation de la cadence d'émission et
Transparent (PROFINET) time synchro- la synchronisation de l'heure.
Clock Protocol nisation, based PTCP utilise des adresses MAC multicast conforme aux
on IEEE 1588 normes.
PROFINET IO Non signifi- (2) Ethertype PROFINET Les télégrammes PROFINET IO servent à la transmis-
data catif 0x8892 Cyclic IO data sion cyclique de données IO via Ethernet entre le con-
(PROFINET) transfer trôleur PROFINET IO et les périphériques IO.
PROFINET 34964 (4) UDP PROFINET Le PROFINET Context Manager met à disposition un
Context Mana- connection mappeur de point de terminaison afin de créer une
ger less RPC relation d'application (PROFINET AR).
Protocoles de communication orientés liaison
SMTP 25 (4) TCP Simple mail SMTP est utilisé pour envoyer des e-mails.
Simple mail transfer proto-
transfer protocol
col
SMTPS (SMTP 465 (4) TCP Secure SMTP SMTPS est utilisé pour envoyer des e-mails via des
over TLS) connexions sécurisées.
SMTP avec 25 (4) TCP Simple mail SMTP avec STARTTLS est utilisé pour envoyer des e-
STARTTLS 587 transfer proto- mails via des connexions sécurisées.
col avec la
commande
SMTP
"STARTTLS"
HTTP 80 (4) TCP Hypertext HTTP est utilisé pour la communication avec le serveur
Hypertext transfer proto- Web interne à la CPU.
transfer protocol
col
ISO-on-TCP 102 (4) TCP ISO-on-TCP ISO-on-TCP (selon RFC 1006) sert à l'échange de don-
(selon protocol nées orienté message avec des CPU ou des contrôleurs
RFC 1006) logiciels distants
Communication S7 avec ES, IHM, serveur OPC, etc.
NTP 123 (4) UDP Network time NTP est utilisé pour synchroniser l'heure système de la
Network time protocol CPU avec l'heure d'un serveur NTP.
protocol
SNMP 161 (4) UDP Simple net- SNMP permet de lire et de valoriser des données de
Simple net- 162 (trap) work manage- gestion du réseau (SNMP managed Objects) à l'aide du
work management protocol gestionnaire SNMP.
ment protocol
HTTPS 443 (4) TCP Secure Hyper- HTTPS est utilisé pour communiquer avec le serveur
Secure Hyper- text transfer Web interne à la CPU via Secure Socket Layer (SSL).
text transfer protocol
protocol
Modbus 502 (4) TCP Modbus/TCP Modbus/TCP est utilisé par des instructions
TCP protocol MB_CLIENT/MB_SERVER dans le programme utilisateur.
Modbus
Transmission
Control Proto-
col
Communication

port son
(4) Couche
transport
OPC UA 4840 (4) TCP Basé sur proto- Standard de communication d'une portée allant du
Open Platform cole TCP/IP niveau entreprise au niveau terrain.
Communica-
tions
Unified Archi-
tecture
OUC1 1 ... 1999 (4) TCP Open User Les instructions OUC permettent l'établissement de
Open User utilisable (4) UDP Communi- liaisons, la suspension de liaisons et le transfert de
Communi- sous condi- cation données basés sur Socket Layer.
cation tion2 (TCP/UDP)
et 2000 ... Secure Open
Secure OUC 5000 User Commu-
recomman- nication (TLS)
dé
5001 ...
49151
utilisable
sous condi-
tion2
IGMPv2 Non signifi- (3) Couche ré- Internet Group Protocole réseau pour l'organisation de groupes multi-
Internet Group catif seau Management cast.
Management Protocol
Protocol
Réservé 49152 ... (4) TCP - Plage de port dynamique, utilisée pour le nœud d'ex-
65535 (4) UDP trémité actif de la liaison quand l'application ne déter-
mine pas le numéro de port local.
1 Remarque : la communication ouverte permet à l'utilisateur d'accéder directement à UDP/TCP. Il incombe à ce dernier de
tenir compte des restrictions/définitions de port de l'IANA (Internet Assigned Numbers Authority).
2 N'utilisez pas pour OUC des ports déjà occupés par d'autres protocoles.
Communication
Le tableau suivant affiche les protocoles pris en charge par le contrôleur logiciel S7-1500 via
les interfaces Ethernet affectées à Windows.
Tableau 3- 3 Couches et protocoles des contrôleurs logiciels S7-1500 (par l'interface Ethernet de la page Windows)
Protocole Numéro de (2) Couche liaison Fonction Description

port (4) Couche transport
Protocoles PROFINET
DCP Non significatif (2) Ethertype 0x8892 Abonnés acces- PROFINET utilise DCP pour déterminer les
Discovery and (PROFINET) sibles, appareils PROFINET et permettre les para-
basic configu- PROFINET Discove- métrages de base.
ration protocol ry and configura-
tion
SMTP 25 (4) TCP Simple mail trans- SMTP est utilisé pour envoyer des e-mails.
Simple mail fer protocol
transfer proto-
col
HTTP Réglable 1 (4) TCP Hypertext transfer HTTP est utilisé pour communiquer avec
Hypertext protocol les serveurs Web internes aux CPU. Vous
transfer proto- pouvez modifier dans Windows les numé-
col ros de port afin d'éviter les conflits avec
d'autres serveurs Web.
Si vous souhaitez utiliser l'accès au serveur
Web, vous devez valider le port dans le
pare-feu Windows.
ISO-on-TCP 102 (4) TCP ISO-on-TCP proto- ISO-on-TCP (selon RFC 1006) pour la
(selon col communication S7 avec PG/PC ou IHM.
RFC 1006)
OUC2 1 ... 1999 (4) TCP Open User Com- Les instructions OUC permettent l'établis-
Open User utilisable sous (4) UDP munication sement de liaisons, la coupure de liaisons
Communica- condition3,4 (TCP/UDP) et le transfert de données sur la base de
tion Socket Layer.
2000 ... Secure Open User
et 5000 Communication Si vous souhaitez utiliser OUC, vous devez
(TLS) valider les ports dans le pare-feu Windows.
Secure OUC recommandé4
5001 ...
49151
utilisable sous
condition3,4
Communication

IGMPv2 Non significatif (3) Couche réseau Internet Group Protocole réseau pour l'organisation de
Internet Group Management Pro- groupes multicast.
Management tocol
Protocol
Réservé 49152 ... (4) TCP - Plage de port dynamique utilisée pour le
65535 (4) UDP nœud d'extrémité actif de la liaison quand
l'application ne détermine pas le numéro
de port local.
Si vous souhaitez utiliser cette communi-
cation, vous devez valider les ports dans le
pare-feu Windows.
1 Valeur par défaut pour les interfaces affectées à Windows : 81
2 Remarque : la communication utilisateur ouverte fournit un accès direct à UDP/TCP pour l'utilisateur. Il incombe à ce
dernier de tenir compte des restrictions/définitions de port de l'IANA (Internet Assigned Numbers Authority).
3 N'utilisez pas pour OUC des ports déjà occupés par d'autres protocoles.
4 N'utilisez pas pour OUC des ports déjà occupés par d'autres applications Windows.
Le tableau ci-dessous indique les protocoles pris en charge par les modules de
communication S7-1500 (par ex. CP 1543-1) en plus des protocoles mentionnés dans les
tableaux ci-dessus.
Tableau 3- 4 Couches et protocoles des modules de communication de S7-1500

Protocoles PROFINET/Industrial Ethernet
FTP 20 (data) (4) TCP File transfer proto- FTP est utilisé pour transmettre des fichiers
File transfer 21 (control) col (uniquement avec un CP 1543-1).
protocol
secureFTP 20 (data) (4) TCP File transfer proto- SecureFTP est utilisé pour transmettre des
File transfer 21 (control) col fichiers via une liaison TLS (uniquement
protocol avec un CP 1543-1).
DHCP 68 (4) UDP Dynamic Host Con- DHCP est utilisé pour obtenir d'un serveur
Dynamic Host figuration protocol DHCP la suite d'adresse IP au cours du
Configuration démarrage de l'interface IE.
Protocol
NTPv3 sécurisé 123 (4) UDP Network time pro- NTP sécurisé est utilisé pour régler l'hor-
Network time tocol loge système interne du CP 1543-1 sur un
protocol serveur NTP.
SNMP 161 (4) UDP Simple network SNMPv3 permet au CP 1543-1 de lire des
Simple net- 162 (trap) management pro- données de gestion du réseau (MIB) avec
work mana- tocol authentification sur l'agent SNMPv3.
gement
protocol
Particularité S7-1500 MFP :

Port 111 : La CPU S7-1500 MFP utilise le port 111 pour le service NFS pour la communication
interne.
Communication
3.3 Vue d'ensemble des ressources de liaison
3.3 Vue d'ensemble des ressources de liaison
Ressources de liaison
Quelques services de communications requièrent des liaisons. Les liaisons occupent des
ressources dans les CPU, CP et CM concernés (par ex. les zones de mémoire dans le système
d'exploitation de la CPU). Dans la plupart des cas, une liaison occupe une ressource par
CPU/CP/CM. La communication IHM requiert jusqu'à 3 ressources de liaison par liaison IHM.
Les ressources de liaison disponibles dépendent des CPU, CP et CM utilisés et ne doivent pas
dépasser une limite supérieure définie pour le système d'automatisation.
Ressources de liaison disponibles dans une station

Le nombre maximal de ressources d'une station est déterminé par la CPU.
Chaque CPU apporte des ressources de liaison réservées à la communication PG, IHM et
serveur Web. Il existe en outre des ressources qui peuvent être utilisées pour d'autres services
de communication, par ex. pour SNMP, les liaisons de messagerie, la communication IHM et
S7 ainsi que pour la communication ouverte.
Quand les ressources de liaison sont-elles affectées ?

Le moment de l'affectation de ressources de liaison dépend de la façon dont la liaison est
établie : automatiquement, par programmation ou par configuration (voir chapitre Création
d'une liaison (Page 1)).
Pour plus d'informations sur l'affectation et l'affichage des ressources de liaison, référez-vous
à STEP 7, chapitre Ressources de liaison (Page 1).
3.4 Création d'une liaison
Liaison automatique
STEP 7 créera automatiquement une liaison (par ex. une liaison PG ou IHM) si vous avez relié
physiquement l'interface PG/PC à une interface de la CPU et si vous avez affecté les interfaces
dans la boîte de dialogue "Liaison en ligne" de STEP 7.
Communication
Création programmée de la liaison

Vous créez la liaison programmée dans l'éditeur de programme de STEP 7 dans le contexte
d'une CPU, en paramétrant des instructions pour la communication, par ex. TSEND_C.
L'interface utilisateur conviviale vous aide à définir les paramètres de la liaison (dans la
fenêtre d'inspection, dans les propriétés de l'instruction).
Figure 3-1 Création programmée
Communication
Création configurée de la liaison

Vous créez la liaison configurée dans la vue de réseau de l'éditeur de matériel et de réseaux
de STEP 7, dans le contexte d'une CPU ou d'un Software Controller.
Figure 3-2 Création configurée
Communication
Effets sur les ressources de liaison de la CPU

Vous pouvez souvent choisir aussi bien une liaison configurée qu'une liaison programmée. La
création programmée permet de libérer des ressources de liaison après la transmission des
données. Comme les liaisons par routeur, les liaisons programmées ne sont pas garanties,
c'est-à-dire qu'elles ne sont établies que si des ressources sont libres. Avec la création
configurée, la ressource est disponible après le chargement de la configuration et jusqu'à
nouvelle modification de cette dernière. Les ressources appropriées sont donc réservées pour
l'établissement de liaisons configurées. Le tableau "Ressources de liaison" de la fenêtre
d'inspection de la CPU donne une vue d'ensemble des ressources de liaison déjà affectées et
encore disponibles.
Comment créer quelle liaison ?
Tableau 3- 5 Création de la liaison
Liaison Automatique- Création program- Création configu-

ment mée rée
Liaison PG X - -
Liaison IHM X - X
Communication Web X - -
Communication serveur OPC UA X - -
Communication client OPC UA - X -
Communication ouverte via liaison - X X
TCP/IP
ISO-on-TCP
UDP
ISO
FDL
Communication via liaison Modbus - X -
TCP
Liaison e-mail - X -
Liaison FTP - X -
Liaison S7* - - X
* Notez que pour une CPU S7-1500, l'utilisation de la communication PUT/GET doit être activée dans
les propriétés de la CPU. Pour plus d'informations à ce sujet, voir l'aide en ligne de STEP 7.
Pour plus d'informations sur l'affectation et l'affichage des ressources de liaison, référez-vous
à STEP 7, chapitre Ressources de liaison (Page 1).
Communication
3.5 Cohérence des données
Définition
La cohérence des données est, pour la transmission de données, une propriété importante
que vous devez prendre en compte lors de la configuration d'une tâche de communication. Si
ce n'est pas le cas, des dysfonctionnements peuvent en être la conséquence.
On appelle zone de données cohérente une zone de données qui ne peut pas être modifié par
des processus concurrents. Autrement dit, une zone de données formant un tout mais dont la
taille dépasse la taille maximale de la zone de données cohérentes peut être constituée, à un
moment donné, en partie de nouveaux et en partie d'anciens blocs cohérents.
Une incohérence peut se produire si une instruction de communication est interrompue par
ex. par un OB d'alarme de processus de priorité plus élevée. La transmission de la zone de
données est alors également interrompue. Si le programme utilisateur modifie maintenant
dans cet OB les données qui n'ont pas encore été traitées par l'instruction de communication,
les données transmises proviennent d'instants différents.
La figure suivante montre une zone de données qui est plus petite que la taille maximale de
la zone de données cohérente. Lors de la transmission de la zone de données, on est sûr dans
ce cas qu'aucune interruption par le programme utilisateur n'interviendra durant l'accès au
données et qu'ainsi les données ne seront pas modifiées.
① La zone de données source est plus petite que la taille maximale de la zone de données cohé-
rente (②). L'instruction transmet les données en un bloc dans la zone de données cible.
② Taille maximale de la zone de données cohérente
Figure 3-3 Transmission cohérente de données
Communication
La figure suivante montre une zone de données qui est plus grande que la taille maximale de
la zone de données cohérente. Dans ce cas, les données peuvent être modifiées durant une
interruption de la transmission de données. Il y a interruption par ex. lorsqu'une zone de
données doit être transmise en plusieurs parties. Si les données sont modifiées durant
l'interruption, les données seront issues d'instants différents.
① La zone de données source est plus grande que la taille maximale de la zone de données cohérente (③). A l'instant
T1, l'instruction transmet de la zone de données source dans la zone de données cible uniquement la quantité de
données que la zone de données cohérente peut contenir.
② A l'instant T2, l'instruction transmet le reste de la zone de données source dans la zone de données cible. Après la
transmission, la zone de données cible contient des données issues de divers instants. Si les données de la zone de
données source ont entre temps été modifiées, une incohérence peut se produire.
③ Taille maximale de la zone de données cohérente
Figure 3-4 Transmission de données dont la taille est supérieure à la zone de données cohérente
Exemple d'une incohérence

La figure suivante montre un exemple de modification des données durant la transmission.
La zone de données cible contient des données issues de divers instants.
① Taille maximale de la zone de données cohérente
Figure 3-5 Exemple : Modification des données durant la transmission
Communication
Cohérence des données maximale, spécifique au système pour S7-1500 :

Une incohérence ne survient pas si la taille maximale des données cohérentes, spécifique au
système, est respectée. Pour S7-1500, les données de communication sont copiées de façon
cohérente en blocs de 512 octets maximum dans/à partir de la mémoire utilisateur pendant
le cycle de programme. Pour toutes les zones de données plus importantes, la cohérence des
données n'est pas garantie. Si une cohérence définie des données est requise, les données de
communication dans le programme utilisateur de la CPU ne peuvent pas être supérieures à
512 octets. Vous pouvez alors accéder de manière cohérente à ces zones de données par ex.
à partir d'un appareil IHM avec lecture/écriture de variables.
Si vous devez transmettre plus de données que le taille maximale spécifique au système, vous
devez alors garantir vous-même la cohérence des données par des mesures appropriées dans
le programme utilisateur.
Assurer la cohérence des données

Utilisation d'instructions pour l'accès à des données communes :
Si des instructions de communication, accédant à des données communes, existent dans le
programme utilisateur, par ex. TSEND/TRCV, vous pouvez coordonner vous-même l'accès à
cette zone de données, par ex. au moyen du paramètre "DONE". La cohérence des données
des zones de données transmises par une instruction de communication peut donc être
assurée dans le programme utilisateur.
Remarque
Mesures dans le programme utilisateur
Pour obtenir la cohérence des données, vous pouvez copier les données à transmettre dans
une zone de données distincte (bloc de données global par ex.). Tandis que le programme
utilisateur continue à utiliser les données originales, vous pouvez transmettre les données
enregistrée dans la zone de données distincte de manière cohérente avec l'instruction de
communication.
Utilisez, pour la duplication, des instructions ininterruptibles telles que UMOVE_BLK ou
UFILL_BLK. Ces instructions garantissent la cohérence des données jusqu'à 16 Ko.
Utilisation des instructions PUT/GET ou écriture/lecture par communication IHM :

Pour la communication S7 avec les instructions PUT/GET ou l'écriture/lecture par la
communication IHM, vous devez tenir compte de la taille des zones de données cohérentes
dès la programmation ou la configuration. En effet, il n'existe pas d'instruction pouvant
coordonner la transmission de données dans le programme utilisateur d'un S7-1500 comme
serveur. Les données échangées avec des instructions PUT/GET sont actualisées par le
S7-1500 durant l'exécution du programme utilisateur. Il n'existe pas d'instant durant le
traitement du programme utilisateur cyclique au cours duquel les données sont échangées de
manière cohérente. Il faudrait que la longueur de la zone de données à transmettre soit
inférieure à 512 octets.
Communication
3.6 Secure Communication
• Le nombre maximal de données cohérentes est également indiqué dans les manuels des
modules de communication, parmi les caractéristiques techniques.
• Pour plus d'informations sur la cohérence des données, référez-vous à la description des
instructions dans l'aide en ligne de STEP 7.
3.6.1 Principes de base sur la communication sécurisée
3.6.1.1 Principes de base sur la communication sécurisée

Les possibilités de communication sécurisée, appelée "Secure Communication" dans ce qui
suit, ont été considérablement étendues pour STEP 7 (TIA Portal) à partir de V14 et pour les
CPU S7-1500 à partir de firmware V2.0.
Par "CPU S7-1500", on entend les modèles de CPU S7-1500F, S7-1500T, S7-1500C ainsi que
les CPU S7-1500pro et ET200SP.
D'autres composants prennent en charge la communication sécurisée dans les versions
ultérieures (Secure OUC), voir le paragraphe suivant.
À partir de la version de firmware V4.4, les CPU S7-1200 prennent aussi en charge la
communication sécurisée (Secure OUC).
Condition
• CPU prenant en charge les DB de description de liaison ayant une structure du type de
données système TCON_IP_V4_SEC ou TCON_QDN_SEC. Il s'agit des CPU suivantes :
– S7-1200 à partir de la version de firmware V4.4
– S7-1500 à partir de la version de firmware V2.0
• Également en option avec les CP suivants :
– CP 1243-1 à partir de la version de firmware V3.2
– CP 1243-8 IRC à partir de la version de firmware V3.2
– CP 1543-1 à partir de la version de firmware V2.0
– CP 1545-1
– CP 1543SP-1
La communication sécurisée (Secure Communication) n'est pas possible avec le CP 1242-7
GPRS V2.
Communication
Infrastructure à clé publique (PKI, Public Key Infrastructure)

L'attribut "secure" est utilisé pour repérer des mécanismes de communication qui se basent
sur une Public Key Infrastructure (PKI) (par ex. RFC 5280 pour Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Profile). On entend par Public Key
Infrastructure (PKI) un système qui délivre, distribue et vérifie des certificats numériques. Les
certificats numériques délivrés sont utilisés dans la PKI pour sécuriser la communication
informatisée. Quand une PKI utilise la cryptographie asymétrique, il est possible de doter les
messages d'une signature numérique et de les chiffrer dans un réseau.
Les composants que vous avez configurés pour la communication sécurisée dans STEP 7
(TIA Portal) utilisent une cryptographie asymétrique avec clé publique (Public Key) et clé
privée (Private Key). Le protocole de cryptage utilisé est TLS (Transport Layer Security). TLS
est le successeur du protocole SSL (Secure Sockets Layer).
Objectifs de Secure Communication

L'utilisation de Secure Communication vise à atteindre les objectifs suivants :
• Confidentialité
c'est-à-dire rendre la lecture des données inintelligible pour des tiers non autorisés.
• Intégrité
c'est-à-dire garantir que le message que reçoit le destinataire est intègre, identique à celui
envoyé par l'expéditeur. Le message n'a pas été modifié en transit.
• Authentification du nœud d'extrémité
c'est-à-dire garantir que le partenaire de communication en tant que nœud d'extrémité est
bien celui qu'il prétend être et qu'il faut joindre. L'identité du partenaire est vérifiée.
Si les objectifs ci-dessus étaient particulièrement importants dans le monde des TI et pour les
ordinateurs connectés par le passé, les machines et automates utilisés en environnement
industriel de nos jours, avec leurs données sensibles et en raison de leur mise en réseau,
représentent un risque tout aussi important et exigent un niveau de sécurité élevé pour
l'échange de données.
La protection de la cellule d'automatisation par pare-feu ou par liaison VPN, par ex. avec le
module de sécurité, a fait ses preuves et reste courante.
Mais on rencontre de plus en plus un besoin de transférer des données sous forme chiffrée
aux ordinateurs externes également, via intranet ou les réseaux publics.
Communication
Principes communs de Secure Communication

Indépendamment du contexte, Secure Communication se base sur le concept de la Public Key
Infrastructure (PKI) et comporte les composants suivants :
• Un procédé de cryptage asymétrique permettant :
– Le cryptage ou le décryptage des messages à l'aide de clés publiques ou privées.
– La validation de signatures au niveau des messages et des certificats.
Les messages/certificats sont signés par l'émetteur/le détenteur du certificat avec leur
clé privée. Le destinataire/l'autorité vérifie la signature avec la clé publique de
l'émetteur/du détenteur du certificat.
• Transmission et mémorisation des clés publiques à l'aide de certificats X.509 :
– Les certificats X.509 sont des données signées numériquement qui permettent de
vérifier l'authenticité de clés publiques par rapport à l'identité associée.
– Les certificats X.509 peuvent contenir des informations qui limitent ou caractérisent
plus précisément l'utilisation des clés publiques. Par exemple les dates de début et de
fin de validité d'une clé publique dans un certificat.
– Les certificats X.509 renferment des informations sécurisées sur l'auteur du certificat.
Les explications qui suivent donnent un aperçu des notions de base requises, par exemple,
pour utiliser des certificats dans STEP 7 (TIA Portal) ou pour programmer les instructions de
communication pour secure Open User Communication (sOUC).
Secure Communication dans STEP 7

STEP 7 à partir de V14 met à disposition la PKI nécessaire dans chaque cas pour configurer et
exploiter une Secure Communication.
Exemples :
• Le protocole Hypertext Transfer Protokoll (HTTP) combiné au protocole TLS (Transport
Layer Security) donne Hypertext Transfer Protokoll Secure (HTTPS). Comme HTTPS est une
combinaison de HTTP et de TLS, il est nommé "HTTP over TLS" dans le RFC correspondant.
L'utilisation de HTTPS est reconnaissable à l'URL qui commence par "https://" au lieu de
"http://" dans la barre d'adresse du navigateur. De plus, la plupart des navigateurs mettent
en relief visuellement une telle liaison sécurisée.
• Open User Communication devient secure Open User Communication. Le protocole à la
base est également TLS.
• Les fournisseurs de messagerie offrent également l'accès par le protocole "Secure SMTP
over TLS" afin de rendre les transactions électroniques plus sûres.
Communication
La figure ci-dessous montre le protocole TLS dans le contexte des couches de

communication.
Figure 3-6 Protocole TLS dans le contexte des couches de communication
Secure Communication avec OPC UA

Un serveur OPC UA est implémenté dans les CPU S7-1500 à partir de la version V2.0 du
firmware. OPC UA Security comprend également l'authentification, le chiffrement et
l'intégrité des données au moyen de certificats X.509 numériques et utilise aussi une Public
Key Infrastructure (PKI). Selon les exigences de l'application, vous pouvez choisir différents
niveaux pour la sécurité du nœud d'extrémité. Un chapitre spécifique est consacré à la
description de la fonctionnalité serveur OPC UA.
Secure Communication pour la communication PG/IHM

Une communication PG/PC et IHM – plus brièvement communication PG/IHM – sécurisée,
innovante et normalisée est mise en œuvre à partir de la version V17 entre les composants
centraux de TIA Portal, STEP 7 et WinCC et les automates et les appareils IHM actuels.
Voir aussi
Utilisation de la CPU S7-1500 comme serveur OPC UA (Page 1)
Communication
3.6.1.2 Confidentialité par cryptage

Le chiffrement des messages apporte une contribution majeure à la sécurité des données.
Lorsque des messages chiffrés sont interceptés par un tiers durant leur transit, cet espion
potentiel ne peut rien en faire.
Il existe une multitude de fonctions mathématiques (algorithmes) pour le chiffrement des
messages.
Tous ces algorithmes ont ceci en commun qu'ils traitent un paramètre "clé" pour chiffrer ou
déchiffrer des messages.
• Algorithme + clé + message => message chiffré
• Message chiffré + clé + algorithme => message (déchiffré)
Chiffrement symétrique
Le point essentiel de la cryptographie symétrique, c'est que les deux partenaires de
communication utilisent la même clé pour chiffrer et déchiffrer des messages, comme le
montre la figure suivante : Bob utilise la même clé pour le chiffrement qu'Alice pour le
déchiffrement. Généralement parlant, on dit aussi que les deux parties partagent un secret, la
clé secrète, qui leur permet de chiffrer ou de déchiffrer un message.
① Bob chiffre son message à l'aide de la clé symétrique

② Alice déchiffre le message chiffré à l'aide de la clé symétrique
Figure 3-7 Cryptage symétrique
Ce procédé est comparable à une mallette pour laquelle l'expéditeur et le destinataire

possèdent la même clé afin de la fermer ou de l'ouvrir.
• Avantage : les algorithmes de chiffrement symétriques (par ex. AES, Advanced Encryption
Algorithm) sont rapides.
• Inconvénients : comment faire parvenir la clé à un destinataire sans qu'elle tombe dans de
mauvaises mains ? C'est un problème de distribution de clé. En outre, il est possible de
deviner la clé après avoir intercepté un nombre suffisant de messages ; c'est pourquoi il
faut convenir d'une nouvelle clé assez fréquemment.
En outre, plus le nombre de partenaires de communication augmente, plus le nombre de clés
à distribuer est important.
Communication
Chiffrement asymétrique
Le procédé de chiffrement asymétrique est basé sur l'utilisation d'une paire de clés, composée
d'une clé publique et d'une clé privée. En relation avec une PKI, on parle aussi de procédé clé
publique ou simplement de procédé PKI : Un partenaire, Alice sur la figure ci-dessous,
possède une clé privée et une clé publique. La clé publique est révélée publiquement, c'est-à-
dire à chaque partenaire de communication potentiel. Chaque expéditeur qui possède la clé
publique peut chiffrer des messages pour Alice. Par exemple, Bob sur la figure ci-dessous.
La clé privée d'Alice, que celle-ci doit garder secrète, lui sert à déchiffrer le message chiffré
qui lui a été adressé.
① Alice transmet sa clé publique à Bob. Pour cela, nul besoin de mesures de précaution : chacun a
le droit d'utiliser la clé publique pour les messages adressés à Alice s'il est sûr qu'il s'agit bien de
la clé publique d'Alice.
② Bob chiffre son message avec la clé publique d'Alice.
③ Alice déchiffre le message chiffré de Bob avec sa clé privée. Comme Alice est la seule à posséder
cette clé privée et qu'elle ne l'a jamais donnée à personne, elle seule peut déchiffrer ce mes-
sage. Sa clé privée lui permet de déchiffrer tout message qui a été chiffré avec sa clé publique -
pas seulement celui de Bob !
Figure 3-8 Cryptage asymétrique
Ce procédé est comparable à une boîte aux lettres dans laquelle chacun peut déposer un
message, mais seul celui qui possède la clé de la boîte aux lettres peut en retirer le message.
• Avantages : un message chiffré avec une clé publique ne peut être déchiffré que par le
détenteur de la clé privée. Comme le déchiffrement nécessite une autre clé (privée), il est
aussi bien plus difficile de deviner cette clé parmi l'ensemble des messages chiffrés. Par
suite, il n'est pas nécessaire de conserver les clés publiques rigoureusement secrètes,
comme c'est le cas pour les clés symétriques.
La distribution facile des clés publiques représente un avantage supplémentaire. Avec le
procédé asymétrique, le transfert des clés publiques du destinataire à l'expéditeur qui
chiffre les messages ne demande pas de canal particulièrement sécurisé. La gestion des
clés cause donc moins de travail que dans le procédé de chiffrement symétrique.
• Inconvénients : algorithme requérant des calculs complexes (tel que l'algorithme RSA, du
nom des trois mathématiciens Ronald Rivest, Adi Shamir et Len Adleman), donc moins
performant que le chiffrement symétrique.
Communication
Mise en œuvre de la cryptographie

Dans la pratique, par exemple avec le serveur Web de la CPU et Secure Open User
Communication, le protocole TLS est utilisé en dessous de la couche application respective.
Les couches d'application sont par exemple HTTP ou SMTP, comme le montre le paragraphe
précédent.
TLS (Transport Layer Security) utilise une combinaison de chiffrement asymétrique et de
chiffrement symétrique (procédé de chiffrement hybride) pour la transmission de données
sûre sur Internet, par exemple, et a recours aux sous-protocoles suivants :
• TLS Handshake Protocol, responsable de l'authentification des partenaires de
communication et de la négociation des algorithmes et clés à utiliser plus tard pour la
transmission de données sur la base du chiffrement asymétrique.
• TLS Record Protocol, responsable du chiffrement des données utiles selon les procédés de
chiffrement symétriques et l'échange de données.
Le chiffrement asymétrique tout comme le chiffrement symétrique sont considérés comme
des procédés sûrs. Il n'y a pas de différence importante entre ces deux procédés sur le plan de
la sécurité. Le niveau de sécurité dépend des paramètres utilisés, telle que la longueur de clé
choisie.
Mauvais usage du chiffrement

En tant que suite de bits, une clé publique ne permet pas de reconnaître à quelle identité elle
est associée. Un fraudeur pourrait diffuser sa clé publique et se faire passer pour quelqu'un
d'autre. Si un tiers utilise cette clé croyant s'adresser au partenaire de communication
souhaité, il est possible que des informations confidentielles atterrissent chez le fraudeur. Il
déchiffre alors avec sa clé privée le message qui ne lui est pas du tout destiné et des
informations confidentielles tombent ainsi en de mauvaises mains.
Pour éviter ce genre d'abus, il faut établir entre les partenaires de communication une
relation de confiance qui leur garantisse qu'ils ont bien affaire au partenaire souhaité. Pour
établir cette relation de confiance, on a recours à des certificats numériques dans une
infrastructure à clé publiques (PKI).
3.6.1.3 Authenticité et intégrité grâce aux signatures

On appelle "attaques de l'homme du milieu" celles de programmes qui interceptent la
communication entre serveur et client et agissent comme s'ils étaient eux-mêmes le client ou
le serveur. Si leur fausse identité n'est pas détectée, ces programmes peuvent recevoir des
informations importantes sur le programme S7, par exemple, ou activer des valeurs dans la
CPU et attaquer ainsi une machine ou des installations. Pour éviter ces attaques, on a recours
à des certificats numériques.
Secure Communication utilise des certificats numériques conformes à la norme X.509 der
International Telecommunication Union (ITU). Cela permet de vérifier (authentifier) l'identité
d'un programme, d'un ordinateur ou d'un organisme.
Communication
Comment établir une relation de confiance avec les certificats

Les certificats X.509 ont pour tâche essentielle d'associer une identité comportant les
données d'un détenteur de certificat (par ex. adresse e-mail, nom d'ordinateur) à la clé
publique de cette identité. Une identité peut être une personne, un ordinateur ou une
machine
Les certificats sont émis par des autorités de certification (Certificate Authority, CA) ou par le
détenteur du certificat lui-même. Les systèmes PKI définissent comment les utilisateurs
peuvent faire confiance aux autorités de certification et aux certificats délivrés par celles-ci.
Obtention d'un certificat :
1. Qui souhaite avoir un certificat en fait la demande par l'intermédiaire d'une autorité
d'enregistrement affiliée à l'autorité de certification.
2. L'autorité de certification vérifie si la demande et le demandeur répondent à des critères
définis.
3. Lorsque l'identité du demandeur est clairement constatée, l'autorité de certification
confirme l'authenticité de cette identité en délivrant un certificat signé. Le demandeur
devient ainsi détenteur d'un certificat.
La figure suivante représente la procédure de façon simplifiée. La possibilité pour Alice de
vérifier la signature électronique n'étant pas représentée.
Figure 3-9 Signature d'un certificat par une autorité de certification
Certificats auto-signés
Les certificats auto-signés sont signés par le détenteur lui-même et non pas par une autorité
de certification indépendante.
Exemples :
• Vous pouvez créer et auto-signer un certificat, par exemple pour chiffrer des messages
envoyés à un partenaire de communication. Dans l'exemple ci-dessus, Bob pourrait auto-
signer son certificat au moyen de sa clé privée (au lieu de Twent). Alice peut vérifier, avec
la clé publique de Bob, que la signature et la clé publique de Bob s'accordent. Cette
procédure suffit largement pour garantir la confidentialité des échanges au sein d'une
organisation.
• Un certificat racine est, par exemple, un certificat auto-signé par l'autorité de certification
(émetteur) et contenant la clé publique de cette autorité.
Communication
Particularités des certificats auto-signés

Pour les certificats auto-signés, les attributs "CN" (Common Name of Subject) pour le
détenteur du certificat et "Issuer" (émetteur) sont identiques : en effet, vous avez signé vous-
même votre certificat. Le champ "CA" (Certificate Autority) pour l'autorité de certification doit
être paramétré sur "False", puisque le certificat auto-signé ne doit pas servir à signer d'autres
certificats.
Les certificats auto-signés ne font pas partie d'une hiérarchie PKI.
Contenu des certificats

Un certificat conforme à la norme X.509 V3, norme également utilisée par STEP 7 ou les CPU
S7-1500, comprend pour l'essentiel les parties suivantes :
• Clé publique
• Indications sur le détenteur du certificat (c.-à-d. le détenteur de la clé) ; c'est le Common
Name (CN) of Subject , par exemple
• Attributs tels que numéro de série et durée de validité
• Signature numérique (authentification) de l'autorité de certification (CA) assurant que les
indications sont exactes.
Il y a en outre des extensions, par exemple
• Indication de l'emploi autorisé pour la clé publique (Key Usage), par ex. signature ou
chiffrement de clé.
Lorsque vous créez un nouveau certificat avec STEP 7, par ex. dans le contexte Secure
Open User Communication, sélectionnez l'entrée souhaitée dans la liste des utilisations
possibles, par ex. "TLS".
• Indication d'un "Autre nom du détenteur de certificat" ("SAN", Subject Alternative Name)
qui sert, par exemple lors de la communication sécurisée avec des serveurs Web (HTTP
over TLS), à garantir que le certificat appartient aussi au serveur Web qui a été indiqué
dans l'URL de la barre d'adresse du navigateur.
Comment créer et authentifier les signatures

La cryptographie asymétrique offre les conditions techniques permettant de vérifier les
certificats : voici l'exemple d'un certificat "MyCert" pour décrire les étapes "Signer" et "Vérifier
la signature".
Générer la signature :
1. L'émetteur du certificat "MyCert" génère une valeur de hachage à partir des données du
certificat avec une fonction de hachage précise (par ex. SHA-1, Secure Hash Algorithm).
La valeur de hachage est une suite de bits de longueur constante. Cette longueur toujours
identique de la valeur de hachage a pour avantage que sa signature prend toujours le
même temps.
2. A partir de la valeur de hachage obtenue, l'émetteur du certificat génère une signature
électronique avec la clé privée. C'est souvent le procédé de signature RSA qui est utilisé à cet
effet.
3. La signature électronique est mémorisée dans le certificat. Ainsi, le certificat est signé.
Communication
Vérifier la signature :
1. Celui qui vérifie le certificat "MyCert" se procure le certificat de l'émetteur et donc la clé
publique.
2. Le même algorithme de hachage qui a servi à la signature (par ex. SHA-1) permet de calculer
à nouveau une valeur de hachage à partir des données du certificat.
3. Cette valeur est alors comparée à celle qui est obtenue avec la clé publique de l'émetteur du
certificat et l'algorithme de signature servant à vérifier la signature.
4. Quand la vérification de la signature donne un résultat positif, c'est non seulement l'identité
du détenteur du certificat, mais aussi l'authenticité et l'intégrité du contenu du certificat qui
sont prouvées. Toute personne qui détient la clé publique, c'est-à-dire le certificat de
l'autorité de certification, peut vérifier la signature et s'assurer ainsi que le certificat a
effectivement été signé par l'autorité de certification.
La figure suivante montre comment Alice vérifie avec la clé publique du certificat de Twent
(incarnant l'autorité de certification CA) la signature jointe à la clé publique de Bob. La
vérification est donc possible à condition que le certificat de l'autorité de certification soit
disponible. La validation elle-même se fait automatiquement au cours de la session TLS.
Figure 3-10 Vérification d'un certificat par la clé publique du certificat d'une autorité de certification
Signature de messages
La session TLS utilise également la méthode décrite ci-dessus pour signer et vérifier des
messages :
Lorsqu'une valeur de hachage est générée pour un message, puis signée avec la clé privée de
l'expéditeur et jointe au message d'origine, le destinataire est en mesure de détecter
l'intégrité du message. Le destinataire déchiffre la valeur de hachage à l'aide de la clé
publique de l'expéditeur, calcule lui-même une valeur de hachage à partir du message reçu et
compare les deux valeurs. Si les valeurs sont différentes, c'est que le message a été falsifié en
cours de route !
Communication
Chaîne de certificats jusqu'au certificat de base

Les certificats d'une infrastructure à clés publiques (PKI) sont souvent organisés de manière
hiérarchique : au sommet de la hiérarchie se trouvent les certificats de base, appelés aussi
certificats racine. Il s'agit de certificats qui ne sont pas authentifiés par une autorité de
certification de niveau supérieur. Le détenteur du certificat et son émetteur sont identiques.
Les certificats de base jouissent d'une confiance absolue, ils sont le "pilier" de la confiance et
doivent donc être connus comme fiables auprès du destinataire. Ils sont enregistrés dans une
zone prévue pour les certificats fiables.
Selon la PKI, leur fonction peut être, par exemple, de signer des certificats d'autorités de
certification subordonnées, appelés certificats intermédiaires. Le certificat intermédiaire
hérite ainsi de la confiance dont jouit le certificat de base. Un certificat intermédiaire pouvant
signer un autre certificat au même titre qu'un certificat de base, on parle également de
"certificats CA" dans les deux cas.
Ce système hiérarchique se décline en plusieurs certificats intermédiaires jusqu'au certificat
d'entité finale. Ce dernier est le certificat de l'utilisateur à identifier.
Pour l'authentification, le système hiérarchique fonctionne en sens inverse : l'émetteur du
certificat est déterminé comme il est dit ci-dessus, sa clé publique permet de vérifier la
signature, ensuite c'est le certificat de l'émetteur de rang supérieur qui est déterminé, et ainsi
de suite en remontant la chaîne de confiance jusqu'au certificat de base.
Conclusion : la chaîne de certificats intermédiaires jusqu'au certificat de base, c'est-à-dire le
chemin d'accès aux certificats, doit être présente sur chaque appareil censé valider un
certificat d'entité finale fourni par le partenaire de communication, quel que soit le type de
Secure Communication que vous configurez.
3.6.1.4 Gestion de certificats avec STEP 7

STEP 7 à partir de la version V14 en collaboration avec les CPU S7-1500 à partir du firmware
V2.0 prend en charge l'infrastructure à clés publiques d'Internet (RFC 5280) de telle façon
qu'une CPU S7-1500 est en mesure de communiquer avec des appareils qui supportent aussi
la PKI Internet.
Il en résulte l'utilisation de certificats X.509, par ex. pour vérifier des certificats comme il est
dit dans les paragraphes précédents.
STEP 7 à partir de V14 utilise une PKI semblable à celle d'Internet. Les listes de certificats
révoqués (CRL = Certificate Revocation List) ne sont pas prises en charge, par exemple.
Communication
Créer ou affecter des certificats

Pour les appareils possédant des propriétés de sécurité, une CPU S7-1500 à partir de la
version V2.0 du firmware par exemple, vous créez des certificats pour différentes applications
dans STEP 7.
La fenêtre d'inspection de la CPU présente les zones suivantes pour la création de nouveaux
certificats ou la sélection de certificats existants :
• "Serveur Web > Sécurité" - pour générer ou affecter des certificats serveur Web.
• "Protection & Sécurité > Mécanismes de connexion" - pour la création ou l'affectation de
certificats de communication API (communication PG/IHM sécurisée, à partir de TIA Portal
V17).
• "Protection & Sécurité > Gestionnaire de certificats" - pour générer ou affecter tous les
types de certificats ; la création est réglée par défaut sur les certificats TLS pour Secure
Open User Communication.
• "OPC UA > Serveur > Sécurité" - pour la création ou l'affectation de certificats de serveur
OPC UA.
Figure 3-11 Paramètres de sécurité pour une CPU S7-1500 dans STEP 7
Communication
Particularités de la zone "Protection & Sécurité > Gestionnaire de certificats"

C'est la seule zone de la fenêtre d'inspection permettant de basculer entre le gestionnaire de
certificats global, c.-à-d. pour l'ensemble du projet, et le gestionnaire local, c.-à-d. propre à un
appareil (option "Utiliser les paramètres de sécurité globaux pour le gestionnaire de
certificats"). Cette option détermine si vous avez accès à tous les certificats du projet ou pas.
• Si vous n'utilisez pas le gestionnaire de certificats avec les paramètres de sécurité globaux,
vous n'aurez accès qu'à la mémoire de certificats locale de la CPU. Vous n'accéderez pas
aux certificats importés, par exemple, ni aux certificats de base. Sans ces certificats, les
fonctions disponibles sont restreintes ; vous ne pourrez générer que des certificats auto-
signés, par exemple.
• Si vous utilisez le gestionnaire de certificats dans les paramètres de sécurité généraux et
que vous avez ouvert une session en tant qu'administrateur, vous aurez accès à la
mémoire de certificats globale pour l'ensemble du projet. Vous pourrez affecter à la CPU
des certificats importés, par exemple, ou créer des certificats émis et signés par l'autorité
de certification (CA) du projet.
La figure ci-dessous montre comment les "Paramètres de sécurité globaux" s'affichent dans le
navigateur de projet après que vous avez activé l'option "Utiliser les paramètres de sécurité
globaux pour le gestionnaire de certificats" dans la fenêtre d'inspection de la CPU.
Si vous double-cliquez sur "Connexion utilisateur" sous les paramètres de sécurité globaux
pour vous connecter, vous verrez s'afficher, entre autres, une ligne "Gestionnaire de
certificats".
Communication
Un double-clic sur cette ligne "Gestionnaire de certificats" vous donnera accès à tous les
certificats du projet, répartis sous les onglets "CA" (autorités de certification), "Certificats
d'appareil" et "Certificats fiables et autorités de certification de base".
Clé privée
STEP 7 génère des clés privées lorsque vous générez des certificats d'appareil ou des
certificats de serveur (certificats d'entité finale). Selon que les paramètres de sécurité globaux
sont utilisés ou pas pour le gestionnaire de certificats, la clé privée est stockée sous forme
chiffrée à un autre endroit :
• Lorsque vous utilisez les paramètres de sécurité globaux, la clé privée est stockée sous
forme chiffrée dans la mémoire de certificats globale (pour l'ensemble du projet).
• Lorsque vous n'utilisez pas les paramètres de sécurité globaux, la clé privée est stockée
sous forme chiffrée dans la mémoire de certificats locale (propre à la CPU).
L'existence de la clé privée, nécessaire pour déchiffrer des données par exemple, est indiquée
dans la colonne "Clé privée" dans la page à onglet "Certificats d'appareil" du gestionnaire de
certificats dans les paramètres de sécurité globaux.
Communication
Lorsque vous chargez la configuration matérielle, le certificat de l'appareil, la clé publique et

la clé privée sont chargés dans la CPU.
IMPORTANT
Activation de l'option "Utiliser les paramètres de sécurité généraux pour la gestion des
certificats" et conséquences
L'option "Utiliser les paramètres de sécurité globaux pour le gestionnaire de certificats" a
une influence sur les clés privées utilisées jusque-là : si vous avez déjà créé des certificats
sans utiliser le gestionnaire de certificats dans les paramètres de sécurité globaux, puis
activez l'option pour utiliser le gestionnaire, vous perdrez les clés privées et les ID des
certificats risquent de changer ! Un avertissement vous rappellera ce fait. Il convient donc de
décider dès le début du travail de configuration quelle option est nécessaire quant au
gestionnaire de certificats.
3.6.1.5 Exemples de gestion de certificats

Comme il est expliqué dans les paragraphes précédents, des certificats sont nécessaires pour
tout type de Secure Communication. Les exemples ci-dessous vous montrent comment
manipuler les certificats avec STEP 7 afin que les conditions de la Secure Open User
Communication soient remplies.
Chaque exemple tient compte du type d'appareil mis en œuvre comme partenaire de
communication. Il décrit les étapes requises pour fournir les certificats nécessaires aux
partenaires. La CPU présupposée est toujours une CPU S7-1500 ou un contrôleur logiciel
S7-1500 à partir de la version 2.0 du firmware.
De façon générale :
Durant l'établissement d'une liaison sécurisée ("handshake"), les partenaires de
communication ne transmettent habituellement que leurs certificats d'entité finale
(certificats d'appareil).
Les certificats CA nécessaires à la vérification du certificat d'appareil transmis doivent donc se
trouver dans la mémoire de certificats du partenaire respectif.
Remarque
La date et l'heure actuelles doivent être réglées dans la CPU.
Lorsque vous utilisez la communication sécurisée (par exemple, HTTPS, Secure OUC, OPC
UA), vous devez veiller à ce que les modules concernés disposent bien de la date et de l'heure
actuelles. Si ce n'est pas le cas, les modules considéreront les certificats utilisés comme non
valides et la communication sécurisée ne fonctionnera pas.
Communication
Secure Open User Communication entre deux CPU S7-1500

Vous voulez que deux CPU S7-1500 nommées AP_1 et AP_2 échangent des données par
Secure Open User Communication.
Vous générez les certificats d'appareil requis avec STEP 7 et vous les affectez aux CPU comme
il est dit ci-dessous.
Des autorités de certification propres au projet STEP 7 (CA du projet) sont utilisées pour
signer les certificats d'appareil.
Il faut référencer les certificats au moyen de leur ID dans le programme utilisateur (instruction
de communication TCON combinée au type de données système correspondant, par ex.
TCON_IPV4_SEC). STEP 7 attribue l'ID automatiquement lorsqu'il génère ou crée le certificat.
Marche à suivre
STEP 7 charge automatiquement les certificats CA requis dans les CPU concernées avec la
configuration matérielle, si bien que les conditions sont remplies dans les deux CPU pour
vérifier les certificats. Vous n'avez donc qu'à générer les certificats d'appareil pour la CPU
respective, STEP 7 s'occupe de tout le reste.
1. Sélectionnez AP_1 et activez l'option "Utiliser les paramètres de sécurité globaux pour le
gestionnaire de certificats" dans la zone "Protection & Sécurité".
2. Connectez-vous comme utilisateur dans la zone "Paramètres de sécurité globaux" du
navigateur de projet. Pour un nouveau projet, c'est le rôle "Administrateur" qui est prévu à la
première connexion.
3. Revenez à AP-1 dans la zone "Protection & Sécurité". Dans le tableau "Certificats d'appareil",
cliquez dans une ligne vide de la colonne "Détenteur du certificat" pour ajouter un nouveau
certificat.
4. Dans la liste déroulante de sélection d'un certificat, cliquez sur le bouton "Ajouter".
La boîte de dialogue "Générer un nouveau certificat" s'ouvre.
5. Conservez les valeurs par défaut de cette boîte de dialogue ; elles sont conçues pour
l'utilisation avec Secure Open User Communication (utilisation : TLS).
Conseil : complétez le nom par défaut du détenteur du certificat qui est le nom de la CPU
dans le cas présent. Pour faciliter la distinction, conservez le nom de CPU par défaut au cas
où vous devrez gérer un grand nombre de certificats d'appareil.
Exemple : PLC_1/TLS devient PLC_1-SecOUC-Chassis17FactoryState.
Communication
6. Compilez la configuration.
Le certificat d'appareil et le certificat CA sont des éléments de cette configuration.
7. Répétez les étapes décrites pour API_2.
L'étape suivante consiste à élaborer les programmes utilisateur pour l'échange de données et
à charger les configurations avec le programme.
Utiliser des certificats auto-signés au lieu de certificats CA

Lorsque vous créez des certificats d'appareil, vous pouvez choisir l'option "Auto-signé". Vous
pouvez créer des certificats auto-signés sans être connecté pour les paramètres de sécurité
globaux. Ce procédé n'est pas recommandé, puisque les certificats ainsi créés ne sont pas
dans la mémoire globale de certificats et qu'il n'est donc pas possible de les affecter
directement à une CPU partenaire.
Comme il est dit plus haut, il convient de choisir soigneusement le nom du détenteur du
certificat pour pouvoir associer le bon certificat à un appareil sans aucun doute.
La vérification avec les certificats CA du projet STEP 7 n'est pas possible pour les certificats
auto-signés. Pour vérifier ces derniers, il faut ajouter à la liste des appareils fiables, pour
chaque CPU, le certificat auto-signé du partenaire de communication. Pour cela, il faut avoir
activé l'option "Utiliser les paramètres de sécurité globaux pour le gestionnaire de certificats"
et être connecté comme utilisateur dans les paramètres de sécurité globaux.
Pour ajouter le certificat auto-signé du partenaire de communication de la CPU, procédez
comme suit :
1. Sélectionnez PLC_1 et naviguez jusqu'au tableau "Certificats des appareils partenaires" dans
la zone "Protection & Sécurité".
2. Cliquez dans une ligne vide de la colonne "Détenteur du certificat" pour ouvrir la liste
déroulante permettant d'ajouter ou de sélectionner des certificats.
3. Sélectionnez le certificat auto-signé du partenaire de communication et confirmez ce choix.
Communication
Secure Open User Communication entre CPU S7-1500 comme client TLS et appareil tiers comme
serveur TLS
Vous voulez que deux appareils échangent des données via une liaison ou une session TLS,
par ex. pour échanger des recettes, des données de production ou des données de qualité :
• Une CPU S7-1500 (AP_1) comme client TLS ; cette CPU utilise Secure Open User
Communication
• Un appareil tiers (par ex. un Manufacturing Execution System (MES)) comme serveur TLS
La CPU S7-1500 en tant que client TLS établit la liaison/session TLS au système MES.
① Client TLS
② Serveur TLS
Pour authentifier le serveur TLS, la CPU S7-1500 nécessite les certificats CA du système MES :
le certificat de base et, le cas échéant, les certificats intermédiaires pour vérifier le chemin
d'accès.
Vous devez importer ces certificats dans la mémoire de certificats globale de la CPU S7-1500.
Procédez comme suit pour importer les certificats du partenaire de communication :
1. Ouvrez le gestionnaire de certificats dans les paramètres de sécurité globaux du navigateur
de projet.
2. Sélectionnez le tableau approprié (certificats dignes de confiance et autorités de certification
d'origine) pour le certificat à importer.
3. Faites un clic droit sur ce tableau pour ouvrir le menu contextuel. Cliquez sur "Importer" et
importez le certificat requis ou les certificats CA requis.
Le certificat reçoit une ID de certificat lors de l'importation et peut être affecté à un
module dans l'étape suivante.
5. Cliquez dans une ligne vide de la colonne "Détenteur du certificat" pour ajouter les certificats
importés.
6. Sélectionnez les certificats CA requis du partenaire de communication dans la liste
déroulante et confirmez ce choix.
Communication
En option, le système MES peut également demander un certificat d'appareil de la CPU pour
authentifier cette dernière (c.-à-d. le client TLS). Les certificats CA de la CPU doivent, dans ce
cas, être mis à disposition du système MES. La condition de l'importation des certificats dans
le système MES est l'exportation préalable des certificats CA depuis le projet STEP 7 de la CPU.
Procédez comme suit :
de projet.
2. Choisissez le tableau adéquat pour le certificat à exporter (certificats CA).
3. Sélectionnez le certificat et faites un clic droit pour ouvrir le menu contextuel.
4. Cliquez sur "Exporter".
5. Choisissez le format d'exportation du certificat.
Secure Open User Communication entre une CPU S7-1500 en tant que serveur TLS et l'appareil
d'un autre constructeur en tant que client TLS
Quand la CPU S7-1500 joue le rôle de serveur TLS et que c'est l'appareil tiers, un système ERP
par exemple (Enterprise Resource Planning System), qui établit la liaison TLS, vous avez
besoin des certificats suivants :
• Pour la CPU S7-1500, vous créez un certificat d'appareil (certificat de serveur) avec une clé
privée et vous le chargez avec la configuration matérielle dans la CPU S7-1500. Vous
utilisez l'option "Signé par autorité de certification" pour générer le certificat de serveur.
La clé privée est requise pour l'échange de clés, comme le montre la figure de l'exemple
"HTTP over TLS".
• Pour le système ERP, vous devez exporter le certificat CA du projet STEP 7 et l'importer/le
charger dans le système ERP. Ce dernier l'utilise pour vérifier le certificat de serveur de S7-
1500 que la CPU lui transmet durant l'établissement de la liaison/session TLS.
① Serveur TLS
② Client TLS
Figure 3-12 Secure OUC entre une CPU S7-1500 et un système ERP
Pour la description des actions nécessaires, voir paragraphes ci-dessus.
Communication
Secure Open User Communication avec un serveur de messagerie (SMTP over TLS)
Une CPU S7-1500 peut établir une liaison sécurisée à un serveur de messagerie avec
l'instruction de communication TMAIL-C.
Les types de données système TMail_V4_SEC et TMail_QDN_SEC vous permettent de
déterminer le port partenaire du serveur de messagerie et d'y accéder ainsi par "SMTP over
TLS".
Figure 3-13 Secure OUC entre une CPU S7-1500 et un serveur de messagerie
La condition requise pour une liaison e-mail sécurisée est une importation du certificat racine
et des certificats intermédiaires du serveur de messagerie (fournisseur) dans la mémoire de
certificats globale de la CPU S7-1500. Ces certificats permettent à la CPU de vérifier le
certificat du serveur envoyé par le serveur de messagerie lors de l'établissement de la
liaison/session TLS.
Procédez comme suit pour importer les certificats du serveur de messagerie :
de projet.
2. Sélectionnez le tableau approprié (certificats dignes de confiance et autorités de certification
d'origine) pour le certificat à importer.
3. Faites un clic droit sur ce tableau pour ouvrir le menu contextuel. Cliquez sur "Importer" et
importez le certificat requis ou les certificats CA requis.
Le certificat reçoit une ID de certificat lors de l'importation et peut être affecté à un
module dans l'étape suivante.
5. Cliquez dans une ligne vide de la colonne "Détenteur du certificat" pour ajouter les certificats
importés.
6. Sélectionnez les certificats CA requis du partenaire de communication dans la liste
déroulante et confirmez ce choix.
L'étape suivante consiste à élaborer les programmes utilisateur pour la fonction de client e-
mail et à charger les configurations avec le programme.
Communication
3.6.1.6 Exemple : HTTP over TLS

Cet exemple montre comment utiliser les mécanismes décrits pour établir une Secure
Communication entre un navigateur Web et le serveur Web d'une CPU S7-1500.
Les modifications pour l'option "Accès uniquement par HTTPS" dans STEP 7 sont décrites en
premier lieu. À partir de STEP 7 V14, vous avez la possibilité d'influencer le certificat du
serveur Web d'une CPU S7-1500 avec version V2.0 ou plus du firmware : le certificat du
serveur est généré avec STEP 7 à partir de ces versions.
Sont décrits ensuite les processus qui se déroulent lorsqu'une page Web du serveur Web de la
CPU est appelée avec un navigateur Web d'un PC via une liaison HTTPS chiffrée.
Manipuler des certificats de serveur Web pour CPU S7-1500 à version de firmware 2.0 et
suivantes
Pour les CPU S7-1500 à version du firmware antérieure à V2.0, vous pouviez choisir sans
conditions l'option "Autoriser l'accès uniquement par HTTPS" lors du paramétrage des
propriétés du serveur Web.
Avec ces CPU, vous n'aviez pas à manipuler de certificats ; c'est la CPU qui génère
automatiquement les certificats nécessaires au serveur Web.
Pour les CPU S7-1500 à partir du firmware V2.0, c'est STEP 7 qui génère le certificat de
serveur pour la CPU (certificat d'entité finale). Vous affectez un certificat de serveur au
serveur Web dans les propriétés de la CPU (Serveur Web > Sécurité).
Comme un nom de certificat de serveur est toujours réglé par défaut, la configuration du
serveur Web reste facile : Vous activez le serveur Web, l'option "Autoriser l'accès uniquement
par HTTPS" est définie par défaut - STEP 7 génère lors de la compilation un certificat de
serveur portant le nom par défaut.
Que vous utilisiez ou pas le gestionnaire de certificats dans les paramètres de sécurité
globaux : STEP 7 a toutes les informations requises pour générer le certificat de serveur.
De plus, vous avez la possibilité de déterminer les propriétés du certificat de serveur, tels que
le nom ou la durée de validité.
Remarque
La date et l'heure actuelles doivent être réglées dans la CPU.
Lorsque vous utilisez la communication sécurisée (par exemple, HTTPS, Secure OUC, OPC
UA), vous devez veiller à ce que les modules concernés disposent bien de la date et de l'heure
actuelles. Si ce n'est pas le cas, les modules considéreront les certificats utilisés comme non
valides et la communication sécurisée ne fonctionnera pas.
Communication
Charger le certificat de serveur

Le certificat de serveur généré par STEP 7 est chargé automatiquement dans la CPU avec la
configuration matérielle.
• Si vous utilisez le gestionnaire de certificats dans les paramètres de sécurité globaux,
l'autorité de certification du projet signera le certificat du serveur Web (certificat CA). Le
certificat CA du projet est chargé automatiquement lors du chargement.
• Si vous n'utilisez pas le gestionnaire de certificats avec les paramètres de sécurité globaux,
STEP 7 générera le certificat de serveur en tant que certificat auto-signé.
Lorsque vous adressez le serveur Web de la CPU par l'adresse IP de la CPU, il faut générer et
charger un nouveau certificat de serveur (certificat d'entité finale) à chaque modification de
l'adresse IP d'une interface Ethernet de la CPU. La raison en est que l'identité de la CPU
change avec l'adresse IP et qu'elle doit être authentifiée (signée) pour respecter les règles de
l'infrastructure PKI.
Vous pouvez éviter ce problème en adressant la CPU par un nom de domaine au lieu de son
adresse IP, par ex. "myconveyer-cpu.room13.myfactory.com". Pour cela, vous devez
administrer les noms de domaine de vos CPU avec un serveur DNS.
Fournir au navigateur Web le certificat CA du serveur Web

L'utilisateur qui accède aux pages Web de la CPU par HTTPS fera bien d'installer le certificat CA
de la CPU dans le navigateur Web. En effet, en l'absence de certificat, un avertissement
s'affiche pour recommander de ne pas utiliser cette page. Pour pouvoir visualiser la page,
l'utilisateur doit alors de manière explicite "Ajouter exception".
Le certificat racine valable (Root Certificate) est téléchargeable sur la page Web "Intro" du
serveur Web de la CPU sous "Télécharger certificat".
STEP 7 offre une autre possibilité : Exportez le certificat CA du projet avec le gestionnaire de
certificats dans les paramètres de sécurité globaux dans STEP 7. Importez ensuite le certificat
CA dans le navigateur.
Communication
Déroulement de Secure Communication

La figure ci-dessous montre le déroulement général simplifié de l'établissement de la
communication ("handshake"), en mettant l'accent sur la négociation des clés utilisées pour
l'échange de données (ici par HTTP over TLS).
Mais ce déroulement est applicable par principe à toutes les formes de communication
basées sur l'utilisation de TLS, donc aussi à Secure Open User Communication (voir les
notions de base sur Secure Communication).
Figure 3-14 Handshake pour https
Communication
Les actions qui se déroulent du côté d'Alice (navigateur) pour authentifier le certificat émis
par le serveur Web ne sont pas représentées sur la figure. Le résultat de l'authentification
décide si Alice peut faire confiance au certificat de serveur Web transmis et donc à l'identité
du serveur Web et si elle peut accepter l'échange de données.
Voici le détail des étapes pour vérifier l'authenticité du serveur Web :
1. Alice doit connaître les clés publiques de toutes les autorités de certification concernées, elle
a donc besoin de toute la chaîne de certificats pour vérifier celui du serveur Web (c.-à-d. le
certificat d'entité finale du serveur Web).
Habituellement, Alice dispose du certificat de base requis dans sa mémoire de certificats.
Par exemple, l'installation d'un serveur Web s'accompagne de l'installation d'une série de
certificats de base fiables. Si elle ne possède pas le certificat de base, elle devra le
télécharger sur le site de l'autorité de certification et l'installer dans la mémoire de
certificats du navigateur. L'autorité de certification peut être aussi l'appareil sur lequel se
trouve le serveur Web.
Il y a plusieurs façons d'obtenir les certificats intermédiaires :
– Le serveur lui-même transmet les certificats intermédiaires nécessaires à Alice en
même temps que son certificat d'entité finale, sous forme de message signé afin
qu'Alice puisse vérifier l'intégrité de la chaîne.
– Les certificats contiennent souvent les URL de l'émetteur respectif. Alice peut
télécharger les certificats intermédiaires dont elle a besoin au moyen de ces URL.
Lorsque vous manipulez des certificats dans STEP 7, il est toujours présupposé que vous
avez importé dans le projet les certificats intermédiaires nécessaires et le certificat de base
et que vous les avez associés au module.
2. Alice valide les signatures de la chaîne de certificats à l'aide des clés publiques jointes aux
certificats.
3. La clé symétrique doit être générée et transmise au serveur Web.
4. Quand le serveur Web est adressé par son nom de domaine, Alice vérifie son identité
conformément aux règles d'infrastructure PKI définies dans RFC 2818 : cela lui est possible
parce que l'URL du serveur Web, le "Fully Qualified Domain Name" (FQDN) dans le cas
présent, est rangé dans le certificat d'entité finale du serveur Web. Si l'inscription dans le
champ "Subject Alternative Name" du certificat et l'entrée dans la barre d'adresse du
navigateur sont identiques, tout est en ordre.
La procédure se poursuit avec l'échange de données à l'aide de la clé symétrique, comme le
montre la figure ci-dessus.
Communication
3.6.2 Conditions requises pour une communication sécurisée
3.6.2.1 Protection des données de configuration confidentielles

Comme décrit dans les notions de base sur la communication sécurisée, des clés privées qu'il
faut protéger du mieux possible sont nécessaires pour le fonctionnement correct des
protocoles basés sur certificat.
À partir de STEP 7 V17, vous pouvez protéger ces clés et d'autres données sensibles par un
mot de passe : le mot de passe de protection des données de configuration API
confidentielles.
Renoncer au mot de passe est possible si vous avez mis en œuvre des mesures qui
empêchent un accès non autorisé au projet TIA Portal et à la configuration de la CPU.
Indépendamment du fait qu'un mot de passe soit défini ou non, TIA Portal génère une
information de clé servant à protéger les données de configuration confidentielles de l'API. Le
mot de passe n'a aucune influence sur le déroulement de la communication sécurisée. La
complexité du mot de passe de protection des données de configuration API confidentielles
détermine toutefois la qualité de la protection des clés privées, par exemple.
L'existence d'une information de clé est nécessaire pour une communication sécurisée
comme, par exemple, la communication PG/IHM sécurisée basée sur TLS. La CPU peut
uniquement traiter les certificats nécessaires à la communication sécurisée si cette
information de clé est disponible.
La figure suivante montre les interactions décrites.
Figure 3-15 Interactions avec la protection des données de configuration confidentielles
Communication
Assistant pour les paramètres de sécurité

Si, dans TIA Portal, vous ajoutez au projet à partir du catalogue du matériel une CPU prenant
en charge la communication PG/IHM sécurisée, un assistant pour les paramètres de sécurité
de la CPU démarre.
Cet assistant vous guide pas à pas dans les paramétrages suivants de la CPU :
• Mot de passe de protection des données de configuration confidentielles de l'API
• Mode de la communication PG/PC et de la communication IHM
• Niveau d'accès
Chacun de ces paramètres est expliqué en détails dans l'assistant. Un récapitulatif clair de
tous les paramètres est fourni à la fin.
L'assistant démarre également si vous effectuez un remplacement de module dans la vue du
réseau de TIA Portal, par exemple, et que la nouvelle CPU prend en charge la communication
PG/IHM sécurisée contrairement à la CPU antérieure.
Tous les paramètres dans l'assistant sont appliqués dans la fenêtre d'inspection (propriétés de
la CPU).
Vous pouvez démarrer l'assistant à tout moment au moyen d'un bouton Démarrer dans la
zone "Protection & Sécurité" des propriétés de la CPU.
Conditions
• TIA Portal à partir de la version V17
• La CPU prend en charge la communication PG/IHM sécurisée (à partir de la version de
firmware V2.9 pour les CPU S7-1500, par exemple).
• Il n'y a pas encore eu de chargement dans la CPU ou la CPU a été réinitialisée aux
paramètres d'usine avec l'option "Supprimer le mot de passe de protection des données de
configuration confidentielles d'API".
Marche à suivre
1. Ouvrez les propriétés de la CPU dans la vue de réseau ou dans la vue des appareils.
2. Naviguez jusqu'à la zone "Protection & Sécurité > Protection des données de configuration
API".
Résultat : L'option "Protéger les données de configuration API confidentielles" est activée
et le champ vide pour la saisie du mot de passe est affiché sur fond rouge.
3. Configurez un mot de passe (recommandation) au moyen du bouton "Définir" ou désactivez
l'option "Protéger les données de configuration API confidentielles".
4. Complétez la configuration et créez le programme utilisateur.
5. Procédez au chargement dans la CPU.
Lors du chargement de la configuration matérielle, vous êtes invité une fois à saisir de
nouveau le mot de passe.
Explication : le mot de passe configuré est certes utilisé dans TIA Portal pour générer
l'information de clé pour la protection des données de configuration confidentielles et pour
protéger ainsi ces données, mais ni le mot de passe ni l'information de clé ne sont
enregistrés dans le projet pour des raisons de sécurité. Pour que l'information de clé soit
présente dans la CPU, elle est à nouveau générée lors du chargement de la configuration
matérielle, ce qui exige que le mot de passe y soit également saisi une fois.
Communication
Communication basée sur certificat entre PG/IHM et CPU également

Comme la communication PG/IHM est également basée sur certificat à partir de TIA Portal
version V17 et de la version de firmware V2.9 (CPU S7-1500) ou V4.5 (CPU S7-1200), il vous
sera demandé d'accepter le certificat du serveur au cours de la mise en service.
Règles et conseils pour la gestion des mots de passe

• Utilisez un gestionnaire de mots de passe pour la gestion de vos mots de passe.
• Utilisez les paramètres de vérification de la stratégie des mots de passe dans TIA Portal
pour vérifier que les nouveaux mots de passe saisis sont conformes à la stratégie et éviter
ainsi, par exemple, les mots de passe triviaux :
– Dans le navigateur du projet, naviguez jusqu'à la zone "<Nom du projet> > Réglages
Security > Paramètres" et sélectionnez la zone "Stratégie de mot de passe".
– Définissez, par exemple, le nombre minimal de caractères du mot de passe ou le
nombre minimal de caractères spéciaux qu'il doit contenir.
• Il n'est pas nécessaire d'attribuer des mots de passe différents pour chaque CPU dans une
installation ou une machine. Si les conditions s'y prêtent, vous pouvez définir le même
mot de passe pour un groupe de CPU. Cette stratégie présente également des avantages
en cas de remplacement de composants : si vous affectez aussi le mot de passe de groupe
à la CPU de remplacement, le remplacement de la CPU en sera facilité.
Notez que si le mot de passe de l'une des CPU est compromis, toutes les CPU ayant le
même mot de passe risquent d'être accédées.
• La définition de mots de passe a également des effets sur le remplacement de
composants, car le mot de passe des données de configuration API confidentielles doit
être transféré sur la nouvelle CPU (ou CPU de remplacement) en plus de la configuration
(voir Règles pour le remplacement de la CPU (Page 1)).
• Pour les CPU S7-1500R/H le mot de passe des données de configuration API
confidentielles n'est chargé que sur l'une des deux CPU lors du chargement. Afin que le
processus Sync-Up fonctionne et que la CPU partenaire fonctionne également
correctement, le mot de passe doit être transféré sur la CPU partenaire avant le Sync-Up, à
l'aide de l'éditeur En ligne et diagnostic :
– Sélectionnez la zone "Définir le mot de passe de protection des données de
configuration confidentielles d'API" dans la vue "En ligne & Diagnostic".
– Saisissez le mot de passe requis et cliquez sur le bouton "Définir".
La CPU partenaire peut utiliser les données de configuration protégées de l'API si le mot
de passe correct a été saisi et le processus de synchronisation (Sync-Up) peut
commencer.
Voir aussi
Informations utiles sur la protection des données de configuration API confidentielles
(Page 1)
Communication
3.6.2.2 Informations utiles sur la protection des données de configuration API

confidentielles
Le concept de communication sécurisée par des normes de sécurité englobe les composants
suivants :
• Une information de clé basée sur mot de passe, qui est utilisée pour la protection de
données de configuration confidentielles (par exemple, clés privées pour certificats, mots
de passe)
• Un protocole normalisé (TLS) qui sécurise la communication entre les participants (par
exemple, console de programmation et CPU)
Principe de "protection des données de configuration confidentielles"

La figure ci-après est une représentation simplifiée de la protection des données de
configuration confidentielles d'une CPU S7-1500 standard, par exemple. Le projet et
l'information de clé sont placés dans des zones de mémoire distinctes lors du premier
chargement. Le projet est chargé dans la mémoire de chargement (carte mémoire),
l'information de clé, dans une zone de mémoire interne de la CPU.
La mise en œuvre doit être adaptée selon les concepts de mémoire des différents systèmes
cibles (par exemple, CPU S7-1200, contrôleur logiciel), mais le principe reste le même.
① Projet avec données de configuration confidentielles protégées par mot de passe (ici, dans la
mémoire de chargement = carte mémoire)
② Information de clé (générée à partir du mot de passe) permettant d'utiliser les données de con-
figuration confidentielles protégées (ici : dans la mémoire interne de la CPU)
Figure 3-16 Principe de la protection des données de configuration confidentielles
Communication
Deux zones de mémoire pour une sécurité accrue

Les éléments chargés sont corrélés comme deux pièces de puzzle assorties : Le projet est lié à
l'information de clé chargée, l'information de clé chargée est liée au mot de passe attribué
lors de la configuration.
Le projet et l'information de clé doivent correspondre, sans quoi la CPU ne démarre pas.
Le principe de deux zones de mémoire séparées est également valable pour les CPU S7-1200
et les variantes de CPU S7-1500 sans carte mémoire, par exemple pour le contrôleur logiciel
ou pour PLCSim / PLCSim Advanced. Les variantes sans carte mémoire utilisent deux
partitions séparées pour pouvoir gérer les deux informations indépendamment l'une de
l'autre.
Figure 3-17 Principes de deux zones de mémoire séparées
3.6.2.3 Modifier le mot de passe

Il convient de distinguer si le chargement dans la CPU a déjà eu lieu ou non. Si le chargement
dans la CPU a déjà eu lieu, la CPU dispose de l'information de clé avec laquelle les données de
configuration API protégées par mot de passe sont utilisables.
Modifier le mot de passe - Configuration pas encore chargée

Tant que vous n'avez pas encore chargé de configuration dans la CPU, vous pouvez changer
un mot de passe saisi ou annuler l'activation de la protection par mot de passe.
Conditions
• Il n'y a pas encore eu de chargement dans la CPU.
Marche à suivre
API".
3. Cliquez sur le bouton "Modifier" ou désactivez l'option "Protection des données de
4. Saisissez le mot de passe valable jusque-là dans la boîte de dialogue. En cas de changement
de mot de passe, saisissez également le nouveau mot de passe et confirmez-le.
Tant que vous n'avez pas encore chargé de configuration dans la CPU, celle-ci se trouve en
phase de mise à disposition (voir Comportement de la CPU du chargement jusqu'à l'état prêt à
fonctionner (Page 1)) et vous pouvez y charger n'importe quelle configuration valide avec
votre mot de passe configuré.
Communication
Modifier le mot de passe - Configuration déjà chargée

Si vous avez déjà chargé une configuration dans la CPU et que cette configuration est
protégée par un mot de passe pour les données de configuration API confidentielles, vous
devez dans un premier temps soit restaurer les paramètres d'usine et supprimer ainsi le mot
de passe pour les données de configuration API confidentielles dans la CPU, soit procéder à
un effacement direct en ligne puis à une nouvelle définition.
Conditions
• Vous disposez d'un accès en écriture à la CPU
• La CPU est à l'état ARRET
Marche à suivre
1. Sélectionnez la CPU dans la vue de réseau.
2. Dans le menu contextuel, sélectionnez la commande "En ligne & Diagnostic".
3. Si vous modifiez également le projet sur la carte mémoire, c'est-à-dire que vous voulez
ensuite recharger la configuration :
– Sélectionnez la zone "Réinitialisation aux paramètres d'usine" dans la vue "En ligne &
Diagnostic" ouverte.
– Activez l'option "Supprimer le mot de passe de protection des données de
configuration confidentielles d'API". Pour éviter un démarrage répété de la CPU, activez
aussi l'option "Formater carte mémoire".
– Chargez ensuite le projet avec la configuration modifiée et le mot de passe souhaité.
4. Si vous ne devez pas modifier le projet sur la carte mémoire, c'est-à-dire qu'il s'agit
uniquement d'un mot de passe incorrect défini :
– Sélectionnez la zone "Définir le mot de passe de protection des données de
configuration confidentielles d'API" dans la vue "En ligne & Diagnostic".
– Cliquez sur le bouton "Supprimer". Le bouton "Supprimer" n'est pas utilisable si aucun
mot de passe n'a encore été défini dans la CPU.
– Saisissez le mot de passe requis et cliquez sur le bouton "Définir".
La CPU peut utiliser les données de configuration protégées de l'API si le mot de passe
correct a été saisi.
Communication
Pas d'accès en écriture à la CPU

Si vous ne disposez pas d'un accès en écriture à la mémoire de chargement (niveau d'accès
en lecture), retirez la carte mémoire de la CPU ou effacez la carte mémoire de manière
externe (par exemple, dans votre ordinateur) avant de procéder à la restauration des
paramètres d'usine avec l'option "Supprimer le mot de passe de protection des données de
Remarque
Réinitialisation aux réglages d'usine avec le sélecteur de mode de la CPU
La réinitialisation de la CPU aux réglages d'usine via le sélecteur de mode a pour effet de
supprimer aussi l'adresse IP de la CPU, mais pas le mot de passe pour la protection des
données de configuration API confidentielles.
Voir aussi
Règles pour le remplacement de la CPU (Page 1)
3.6.2.4 Réinitialiser le mot de passe

Il est possible de réinitialiser la protection des données de configuration API confidentielles.
Cela peut, par exemple, s'avérer nécessaire si vous voulez changer le mot de passe mais ne
vous rappelez plus le mot de passe actuel.
Mot de passe oublié - Configuration pas encore chargée

Étant donné que vous devez saisir le mot de passe lors du premier chargement de la CPU via
TIA Portal, la configuration de la CPU ne peut plus être utilisée pour cette CPU. Pour modifier
le mot de passe dans les propriétés de la CPU, il est également nécessaire d'entrer le mot de
passe actuellement valide. Procédez comme suit si vous avez oublié le mot de passe :
Conditions
• Il n'y a pas encore eu de chargement dans la CPU.
Marche à suivre
API".
Communication
3. Cliquez sur le bouton "Réinitialiser".

Notez qu'après la réinitialisation les certificats de la CPU (par exemple les certificats pour le
serveur Web, le serveur OPC UA, pour la communication PG/PC et la communication IHM)
ne peuvent plus être utilisés et doivent, le cas échéant, être créés et affectés de nouveau.
– Si vous utilisez le gestionnaire de certificats dans les paramètres de sécurité généraux,
vous devez réaffecter les certificats du gestionnaire de certificats.
– Si vous n'utilisez pas les paramètres de sécurité généraux pour le gestionnaire de
certificats, vous devez créer les certificats de nouveau et les réaffecter.
4. Confirmez la réinitialisation du mot de passe.
L'option de protection des données de configuration confidentielles de l'API reste activée.
Supprimer le mot de passe - Configuration déjà chargée

Si vous avez déjà chargé une configuration dans la CPU et que cette configuration est
protégée par un mot de passe pour les données de configuration API confidentielles, vous
pouvez supprimer ce mot de passe dans la CPU en ligne pour le chargement d'un nouveau
projet, puis définir un nouveau mot de passe.
Condition
• Vous disposez d'un accès en écriture à la CPU
• La CPU est à l'état ARRÊT.
Marche à suivre
1. Sélectionnez la CPU dans la vue de réseau.
2. Dans le menu contextuel, sélectionnez la commande "En ligne & Diagnostic".
3. Cliquez sur le bouton "Supprimer" dans la zone "Définir le mot de passe de protection des
données de configuration confidentielles d'API".
Le bouton "Supprimer" n'est pas utilisable si aucun mot de passe n'a encore été défini dans la
CPU.
IMPORTANT
Suppression du mot de passe pour les données de configuration confidentielles.
Si le mot de passe a été supprimé alors qu'un projet chargé requiert un mot de passe
correspondant, ce projet ne fonctionnera éventuellement plus sans mot de passe.
4. Si nécessaire, définissez maintenant un nouveau mot de passe avec le bouton "Définir".

5. Effectuez un redémarrage de la CPU.
Voir aussi
Modifier le mot de passe (Page 1)
Communication
3.6.2.5 Affecter un mot de passe par le biais d'une carte mémoire SIMATIC
Vous pouvez utiliser une carte mémoire SIMATIC si vous voulez transmettre le mot de passe
de protection des données de configuration API confidentielles à une CPU sans utiliser TIA
Portal.
L'utilisation d'une carte mémoire SIMATIC est indiquée dans les cas suivants :
• Préparation d'une nouvelle CPU
Lors de la mise en œuvre d'une nouvelle CPU, celle-ci doit être configurée avec un mot de
passe pour la protection des données de configuration API confidentielles. Une fois cette
configuration achevée, il est possible d'utiliser une autre carte mémoire SIMATIC avec le
projet souhaité.
(CPU S7-1200 : il est également possible d'utiliser une carte "Transfert" avec une tâche de
transfert pour installer le programme sur la CPU)
• La CPU a un mot de passe de protection des données de configuration API confidentielles,
mais le mot de passe ne correspond pas au projet
Lorsque les mots de passe sont différents, vous pouvez définir le mot de passe correct à
l'aide de la carte mémoire dans la CPU.
(CPU S7-1200 : munie soit d'une carte "Transfert" SIMATIC, soit d'une carte "Programme"
SIMATIC)
• Réinitialisation du mot de passe de protection des données de configuration API
confidentielles
Comme préparation avant la mise au rebut de la CPU ou comme préparation à un nouveau
projet pour la CPU
Conditions
• TIA Portal à partir de la version V17
Procédure de principe
1. Création d'une carte mémoire SIMATIC avec tâche "SET PASSWORD"
Cette action permet de créer une structure de dossiers et de fichiers selon un modèle
spécifique et d'écrire un mot de passe de protection des données de configuration API
confidentielles comme texte seul dans un fichier spécial sur la carte mémoire SIMATIC.
Voir la description ci-après.
2. Mise en place d'une carte mémoire SIMATIC préparée dans la CPU et mise sous tension de la
CPU
L'automate programmable lit le mot de passe, le traite et enregistre le résultat dans la
mémoire interne. Une entrée existante éventuelle est écrasée.
3. Retrait de la carte mémoire SIMATIC et redémarrage de la CPU
Résultats (S7-1500) : Lorsque la CPU lit la carte mémoire SIMATIC, la LED a le même
comportement que lors d'une mise à jour du firmware. Lorsque la CPU définit le mot de
passe, la LED RUN/STOP clignote. Une fois l'opération achevée avec succès, la LED
RUN/STOP s'allume en jaune et la LED MAINT clignote en jaune.
Le résultat de l'opération est indiqué sous forme de message de succès ou d'erreur dans le
tampon de diagnostic. Si le mot de passe n'a pas pu être défini, la LED ERROR clignote avec
les autres LED.
Communication
Créer une carte mémoire SIMATIC avec tâche "SET PASSWORD"

1. Créez un dossier de nom "SET_PWD.S7S" dans le répertoire racine.
2. Créez un fichier texte de nom "PWD.TXT" avec le mot de passe comme texte seul dans le
dossier que vous venez de créer sur la carte mémoire.
3. Créez un fichier texte de nom "S7_JOB.S7S" contenant "SET_PWD" dans le répertoire racine
de la carte mémoire.
Ce fichier est le fichier de tâche (job) pour affecter un mot de passe de protection des
données de configuration API confidentielles à l'API.
4. La structure de fichiers sur la carte mémoire SIMATIC se présente alors comme suit :
Remarque
Conservation sûre de la carte mémoire SIMATIC
Conservez la carte mémoire SIMATIC dans un lieu sûr accessible uniquement aux
personnes autorisées.
Règles et recommandations
• La définition du mot de passe doit avoir lieu dans un environnement sûr.
• Le contenu du fichier texte "PWD.TXT" définit le mot de passe de protection des données
de configuration API confidentielles. Il doit correspondre au mot de passe que vous avez
également défini dans la configuration de la CPU.
• Pour réinitialiser un mot de passe existant d'un automate programmable, le fichier texte
"PWD.TXT" doit être vide, c'est-à-dire avoir une taille de 0 octet.
• Utilisez un éditeur de texte quelconque pour créer le fichier texte. Le format de texte
recommandé est "UTF-8".
• Les majuscules et minuscules ne sont pas significatives dans les noms de dossiers et de
fichiers. En revanche, la casse est prise en compte dans le mot de passe.
• N'insérez pas de caractère CR/LF à la fin (PWD.TXT ou S7_JOB.S7S).
3.6.2.6 Particularités lors de la sauvegarde et de la restauration d'une CPU

Vous pouvez sauvegarder une configuration opérationnelle d'une CPU dans TIA Portal pour
pouvoir y accéder plus tard en restaurant la configuration originale sauvegardée. Cela vous
permet de charger une configuration modifiée, par exemple pour tester des extensions
fonctionnelles ou modifier des programmes de recherche de défauts dans l'installation, ou de
remplacer des composants à titre d'essai. Vous pouvez ensuite restaurer la configuration
originale sauvegardée de la CPU.
Communication
Sauvegarde de la configuration
Le mot de passe de protection des données de configuration API confidentielles n'est pas
sauvegardé lors de la sauvegarde d'une CPU (menu "En ligne", commande "Charger la
sauvegarde de l'appareil en ligne" dans TIA Portal).
Restauration de la copie de sauvegarde

Lors de la restauration de la copie de sauvegarde d'une CPU (menu "En ligne", commande
"Charger dans l'appareil" avec la copie de sauvegarde sélectionnée dans TIA Portal), la CPU ne
peut communiquer avec une PG/un PC ou une IHM que si la condition suivante est remplie.
• Après la restauration d'une configuration qui a été protégée par un mot de passe de
protection des données de configuration API confidentielles, ce mot de passe précis doit
être présent dans la CPU.
Si ce n'est pas le cas, la CPU ne peut pas accéder aux données de configuration et ne
démarre donc pas.
Solution
Si l'erreur décrite ci-dessus se produit, c.-à-d. que le mot de passe de protection des données
de configuration API confidentielles ne correspond pas à la sauvegarde, vous devez supprimer
le mot de passe de protection des données de configuration API confidentielles dans la CPU,
puis définir le mot de passe correct. La sauvegarde sera opérationnelle après un redémarrage
de la CPU.
Voir aussi
Modifier le mot de passe (Page 1)
3.6.2.7 Conseils pour éviter les erreurs et traitement des défauts

La description suivante fournit une liste de cas d'application pouvant éventuellement
entraîner des messages d'erreur de la CPU.
Informations par le tampon de diagnostic

La CPU reconnaît si le mot de passe pour la protection des données de configuration
confidentielles et la configuration chargée ne correspondent pas. Un message dans le
tampon de diagnostic indique les causes et les solutions possibles, et permet en général de
résoudre le problème.
Communication
"Pièges" typiques
Il convient de prêter attention aux circonstances suivantes afin d'éviter les erreurs ou pour
pouvoir y remédier :
• Configuration chargée ?
Que vous protégiez vos données de configuration confidentielles par un mot de passe ou
non : Sans configuration chargée, la CPU ne quitte pas la phase de mise à disposition.
• Vous tentez de charger la CPU avec un mot de passe configuré et la CPU a déjà reçu
auparavant un autre mot de passe.
Exemple : La CPU est remplacée par une autre CPU, la CPU de remplacement n'a pas été
complètement réinitialisée (réinitialisation aux réglages d'usine avec l'option "Supprimer le
mot de passe pour la protection des données de configuration confidentielles d'API").
Solution :
– Préparer systématiquement la CPU de remplacement avec l'option correspondante
(mot de passe supprimé).
– Utilisez le même mot de passe pour la configuration à charger que celui que vous avez
utilisé pour la configuration déjà chargée.
– Il est possible que le projet / la configuration CPU chargé(e) ne soit pas le bon (la
bonne). Vérifiez si la configuration CPU correspondante est disponible.
– Utilisez la fonction en ligne "Définir le mot de passe de protection des données de
configuration confidentielles d'API" pour supprimer le mot de passe ou pour définir le
même mot de passe que dans la configuration de la CPU. Exécutez ensuite un
redémarrage.
• Une erreur identique se produit si la configuration de votre CPU n'utilise pas de mot de
passe et que la configuration déjà chargée exige un mot de passe défini par l'utilisateur.
Solution :
– Utilisez la fonction en ligne "Définir le mot de passe de protection des données de
configuration confidentielles d'API" pour supprimer le mot de passe ou pour définir le
même mot de passe que dans la configuration de la CPU. Exécutez ensuite un
redémarrage.
Communication
3.6.2.8 Règles pour le remplacement de la CPU

L'attribution de mots de passe a également des répercussions sur le remplacement d'une CPU.
Règles pour le remplacement de la CPU

Tenez compte des règles suivantes lorsque vous remplacez une CPU :
Configuration de la CPU de remplacement via TIA Portal

• Une CPU remplaçant une CPU existante ne devrait pas avoir de configuration ni de mot de
passe configuré pour la protection des données de configuration API confidentielles.
Avantage : Vous pouvez charger le projet dans la CPU de remplacement sans autres
préparatifs, indépendamment du fait qu'un mot de passe soit configuré ou non.
• Si la CPU de remplacement est déjà configurée, vous devez la réinitialiser aux paramètres
d'usine avec les options suivantes activées :
– "Supprimer le mot de passe pour la protection des données de configuration
confidentielles d'API"
– "Formater carte mémoire"
La CPU de remplacement reçoit les données de configuration via la carte mémoire

• Si vous n'avez pas affecté de mot de passe de protection des données de configuration
API confidentielles à une CPU dans votre projet, vous pouvez sans autre manipulation
enficher la carte mémoire de la CPU à remplacer dans une CPU neuve qui n'a pas encore
été utilisée.
Si un mot de passe pour la protection des données de configuration API confidentielles a
déjà été configuré pour la CPU de remplacement, vous devez d'abord réinitialiser cette
CPU aux paramètres d'usine avec l'option "Supprimer le mot de passe pour la protection
des données de configuration confidentielles d'API".
• Si vous avez affecté le même mot de passe à un groupe de CPU, vous pouvez affecter ce
mot de passe de groupe à la CPU de remplacement également avec TIA Portal ou avec une
carte mémoire préparée à cet effet sur la CPU de remplacement (voir Protection des
données de configuration confidentielles (Page 1)).
Dans ce cas, vous pouvez sans autre opération sur le mot de passe enficher une carte
mémoire avec le projet actuel dans la CPU, par exemple, et la mettre en service.
• Si vous affectez des mots de passe distincts à chaque CPU dans votre projet, vous devez
lors de la mise en œuvre de la CPU de remplacement d'abord définir le mot de passe
valable pour la CPU concernée avec l'éditeur En ligne & Diagnostic (zone "Définir le mot de
passe de protection des données de configuration confidentielles d'API" ; voir Modifier le
mot de passe (Page 1)).
Voir aussi
Affecter un mot de passe par le biais d'une carte mémoire SIMATIC (Page 1)
Communication
3.6.3 Secure Open User Communication
3.6.3.1 Secure OUC d'une CPU S7-1500 comme client TLS à un AP tiers (serveur TLS)
Voici comment configurer une Secure Open User Communication par TCP d'une CPU S7-1500
comme client TLS à un serveur TLS.
Configurer une liaison TCP sécurisée d'une CPU S7-1500 comme client TLS à un serveur TLS
Les CPU S7-1500 à partir de la version V2.0 du firmware prennent en charge la Secure
Communication avec adressage par nom de domaine (Domain Name System, DNS).
Pour la communication TCP sécurisée par nom de domaine, vous devez élaborer vous-même
un bloc de données du type de données système TCON_QDN_SEC, le paramétrer et l'appeler
directement dans l'une des instructions TSEND_C, TRCV_C ou TCON.
Conditions :
• La date et l'heure actuelles sont réglées dans la CPU.
• Il y a au moins un serveur DNS dans votre réseau.
• Vous avez configuré au moins un serveur DNS pour la CPU S7-1500.
• Le client TLS et le serveur TLS possèdent tous les certificats nécessaires.
Procédez comme suit pour configurer une liaison TCP sécurisée à un serveur TLS :
1. Créez un bloc de données global dans le navigateur de projet.
2. Définissez une variable de type TCON_QDN_SEC dans ce bloc de données global.
L'exemple ci-dessous montre le bloc de données global "Data_block_1" dans lequel est
définie la variable "DNS ConnectionSEC" du type de données TCON_QDN_SEC.
Figure 3-18 Type de données TCON_QDN_SEC
3. Réglez les paramètres de la liaison TCP dans la colonne "Valeur de départ". Tapez par ex. le
nom de domaine complet (FQDN) du serveur TLS sous "RemoteQDN".
Communication
4. Réglez les paramètres pour Secure Communication dans la colonne "Valeur de départ".
– "ActivateSecureConn" : Activation de Secure Communication pour cette liaison. Quand
ce paramètre a la valeur FALSE, les paramètres de sécurité suivants n'ont pas de
signification. Dans ce cas, vous pouvez configurer une liaison TCP ou UDP non
sécurisée.
– "ExtTLSCapabilities" : quand vous tapez la valeur 1, le client valide le
subjectAlternateName dans le certificat X.509 V3 du serveur afin de vérifier l'identité
du serveur. Cette validation s'effectue dans le contexte de l'instruction.
– "TLSServerCertRef" : ID du certificat X.509 V3 (habituellement un certificat CA), utilisée
par le client TLS pour valider l'authentification du serveur TLS. Quand ce paramètre a la
valeur 0, le client TLS utilise pour valider l'authentification du serveur tous les
certificats (CA) actuellement chargés dans sa mémoire de certificats.
Figure 3-19 Manipulation des certificats du point de vue de la CPU S7-1500 comme client TLS
– "TLSClientCertRef" : ID du propre certificat X.509 V3.
Communication
5. Créez une instruction TSEND_C, TRCV_C ou TCON dans l'éditeur de programme.

6. Interconnectez le paramètre CONNECT de l'une des instructions TSEND_C, TRCV_C ou TCON
avec la variable de type de données TCON_QDN_SEC.
Dans l'exemple suivant, le paramètre CONNECT de l'instruction TCON est interconnecté
avec la variable "DNS connectionSEC" (type de données TCON_QDN_SEC).
Figure 3-20 Instruction TCON
Pour plus d'informations...

Pour plus d'informations sur le type de données système TCON_QDN_SEC, voir l'aide en ligne
de STEP 7.
Pour plus d'informations sur la communication sécurisée, voir chapitre Secure
Communication (Page 1).
3.6.3.2 Secure OUC d'une CPU S7-1500 comme serveur TLS à un AP tiers (client TLS)
Voici comment configurer une Secure Open User Communication par TCP d'une CPU S7-1500
comme serveur TLS à un client TLS.
Communication
Configurer une liaison TCP sécurisée au moyen du nom de domaine du partenaire de

communication
Les CPU S7-1500 à partir de la version V2.0 du firmware prennent en charge la Secure
Communication avec adressage par nom de domaine (Domain Name System, DNS).
Pour la communication TCP sécurisée par nom de domaine, vous devez élaborer vous-même
un bloc de données du type de données système TCON_QDN_SEC, le paramétrer et l'appeler
directement dans l'une des instructions TSEND_C, TRCV_C ou TCON.
Conditions :
• Il y a au moins un serveur DNS dans votre réseau.
• Vous avez configuré au moins un serveur DNS pour la CPU S7-1500.
Procédez comme suit pour configurer une liaison TCP sécurisée à un client TLS :
2. Définissez une variable de type TCON_QDN_SEC dans ce bloc de données global.
définie la variable "DNS ConnectionSEC" du type de données TCON_FDL_SEC.
Figure 3-21 TCON_QDN_SEC_Server
3. Réglez les paramètres de la liaison TCP dans la colonne "Valeur de départ". Tapez par ex.
pour "ID" l'ID locale de la liaison TCP.
Communication
sécurisée.
– "TLSServerReqClientCert" : demande d'un certificat X.509 V3 du client TLS.
– "TLSServerCertRef" : ID du propre certificat X.509 V3.
Figure 3-22 Manipulation des certificats du point de vue de la CPU S7-1500 comme serveur
TLS
– "TLSClientCertRef" : ID du certificat X.509 V3 (ou d'un groupe de certificats X.509 V3),

utilisée par le serveur TLS pour valider l'authentification du client TLS. Quand ce
paramètre a la valeur 0, le serveur TLS utilise pour valider l'authentification du client
tous les certificats (CA) actuellement chargés dans sa mémoire de certificats.
Communication

avec la variable de type de données TCON_QDN_SEC.
avec la variable "DNS connectionSEC" (type de données TCON_QDN_SEC).

Pour plus d'informations sur les types de données système TCON_QDN_SEC, voir l'aide en
ligne de STEP 7.
Communication
3.6.3.3 Secure OUC entre deux CPU S7-1500

Voici comment configurer une Secure Open User Communication par TCP entre deux CPU
S7-1500, sachant qu'une CPU S7-1500 joue le rôle de client TLS (établissement de liaison
actif) et l'autre CPU S7-1500 celui de serveur TLS (établissement de liaison passif).
Configurer une liaison TCP sécurisée entre deux CPU S7-1500

Pour la communication TCP sécurisée entre deux CPU S7-1500, vous devez créer dans chaque
CPU un bloc de données du type de données système TCON_IP_V4_SEC, le paramétrer et
l'appeler directement dans l'une des instructions TSEND_C, TRCV_C ou TCON.
Conditions :
• Les deux CPU S7-1500 ont au moins la version V2.0 du firmware.
Figure 3-24 Manipulation des certificats pour Secure OUC entre deux CPU S7-1500
Communication
Paramètres du client TLS

Procédez comme suit pour configurer une liaison TCP sécurisée dans le client TLS :
2. Définissez une variable de type TCON_IP_V4_SEC dans ce bloc de données global.
définie la variable "SEC connection 1 TLS-Client" du type de données TCON_IP_V4_SEC.
Figure 3-25 IP_V4_SEC_Client
3. Réglez les paramètres de la liaison TCP dans la colonne "Valeur de départ". Saisissez, par
exemple, l'adresse IPv4 du serveur TLS pour "RemoteAddress".
Remarque
Paramètre de liaison InterfaceId
Notez que vous pouvez saisir la valeur "0" pour l'ID d'interface dans le type de données
TCON_IP_V4_SEC. Dans ce cas, la CPU recherche elle-même une interface locale
appropriée de la CPU.
Communication
sécurisée.
– "TLSServerCertRef" : Entrez la valeur 2 (référence au certificat CA du projet TIA Portal
(SHA256)) ou la valeur 1 (référence au certificat CA du projet TIA Portal (SHA1)). Si
vous utilisez un autre certificat CA, entrez l'ID correspondant indiqué dans le
gestionnaire de certificats des paramètres de sécurité généraux.
– "TLSClientCertRef" : ID du propre certificat X.509 V3.
avec la variable de type de données TCON_IP_V4_SEC.
Paramètres du serveur TLS

Procédez comme suit pour configurer une liaison TCP sécurisée dans le serveur TLS :
2. Définissez une variable de type TCON_IP_V4_SEC dans ce bloc de données global.
définie la variable "SEC connection 1 TLS-Server" du type de données TCON_IP_V4_SEC.
Figure 3-26 IP_V4_SEC_Server
3. Réglez les paramètres de la liaison TCP dans la colonne "Valeur de départ". Saisissez, par
exemple, l'adresse IPv4 du client TLS pour "RemoteAddress".
Communication
sécurisée.
– "TLSServerReqClientCert " : demande d'un certificat X.509 V3 du client TLS. Tapez la
valeur "true".
– "TLSServerCertRef" : ID du propre certificat X.509 V3.
– "TLSClientCertRef" : Entrez la valeur 2 (référence au certificat CA du projet TIA Portal
Dans l'exemple suivant, le paramètre CONNECT de l'instruction TSEND_C est interconnecté
avec la variable "SEC connection 1 TLS-Client" (type de données TCON_IP_V4_SEC).
Figure 3-27 TSEND_C

Pour plus d'informations sur les types de données système TCON_IP_V4_SEC, voir l'aide en
ligne de STEP 7.
Communication
3.6.3.4 Secure Open User Communication par l'interface CP

Les paragraphes suivants décrivent les particularités dont il faut tenir compte pour une
communication Secure Open User Communication par le biais d'une interface CP. Au moins
une station est une station S7-1500 comportant les modules suivants :
• CPU S7-1500 à partir de la version de firmware V2.0 (à l'exception du contrôleur logiciel
S7-1500)
• CP 1543-1 à partir de la version de firmware V2.0 ou CP 1543SP-1 à partir de la version de
firmware V1.0
Le CP opère comme client TLS (établissement de liaison actif) ou comme serveur TLS
(établissement de liaison passif) dans une station S7-1500.
La procédure de base et le concept pour l'utilisation de Secure Communication par le biais
d'une interface CP sont similaires à la Secure Communication par les interfaces des
CPU S7-1500. Vous devez, pour l'essentiel, affecter les certificats au CP dans son rôle de
serveur TLS ou de client TLS, et non à la CPU. Il faut donc appliquer d'autres règles et
procédures qui sont décrites ci-après.
Manipulation des certificats pour CP

En règle générale, vous devez avoir ouvert une session dans le gestionnaire de certificats
dans les paramètres de sécurité généraux. La création de certificats autosignés n'est pas non
plus possible sans connexion aux paramètres de sécurité généraux. Vous devez disposer de
droits suffisants (administrateur ou utilisateur "standard" avec les droits "Configurer la
sécurité").
Le point de départ pour la création ou l'affectation de certificats pour le CP est la section
"Sécurité > Propriétés de sécurité". Dans cette section, ouvrez une session pour les
paramètres de sécurité généraux.
Marche à suivre :
1. Sélectionnez le CP dans la vue du réseau de STEP 7 et choisissez la section "Sécurité >
Propriétés de sécurité" dans la fenêtre d'inspection.
2. Cliquez sur le bouton "Connexion utilisateur".
3. Ouvrez une session avec votre nom d'utilisateur et votre mot de passe.
4. Activez l'option "Activer les fonctions de sécurité".
Les propriétés de sécurité sont initialisées.
5. Cliquez dans la première ligne du tableau "Certificats d'appareil" pour générer un nouveau
certificat d'appareil ou pour sélectionner un certificat d'appareil existant.
6. Si le partenaire de communication est également une station S7-1500, vous devez aussi lui
affecter un certificat d'appareil avec STEP 7 comme décrit ici ou décrit pour la CPU S7-1500.
Communication
Exemple : configuration d'une liaison TCP sécurisée entre deux CPU S7-1500 par le biais
d'interfaces CP
Pour la communication TCP sécurisée entre deux CP S7-1500, vous devez créer dans chaque
CPU un bloc de données du type de données système TCON_IP_V4_SEC, le paramétrer et
l'appeler directement dans l'une des instructions TSEND_C, TRCV_C ou TCON.
Conditions préalables :
• Les deux CPU S7-1500 ont au moins la version de firmware V2.0. Si vous utilisez le CP
1543SP-1, une version de firmware à partir de V1.0 convient.
• Les deux CP (CP 1543-1, par exemple) ont au moins la version de firmware V2.0.
• Le client TLS et le serveur TLS doivent posséder tous les certificats requis.
– Un certificat d'appareil (certificat d'entité finale) doit être généré pour le CP et être
placé dans la mémoire de certificats du CP. Si un partenaire de communication est un
appareil tiers (un système MES ou ERP, par exemple), un certificat d'appareil doit
également exister pour cet appareil.
– Le certificat racine (certificat CA) avec lequel le certificat d'appareil du partenaire de
communication est signé doit se trouver dans la mémoire de certificats du CP ou dans
la mémoire de certificats de l'appareil tiers. Si vous utilisez des certificats
intermédiaires, vous devez vous assurer que le chemin de certificat complet est présent
dans l'appareil qui valide. Un appareil utilise ces certificats pour valider le certificat
d'appareil du partenaire de communication.
• Vous devez absolument adresser le partenaire de communication par son adresse IPv4,
pas par son nom de domaine.
La figure suivante présente les différents certificats dans les appareils lorsque les deux
partenaires de communication communiquent par le biais d'un CP 1543-1. La figure montre
également la transmission des certificats d'appareil lors de l'établissement de la liaison
("Hello").
Figure 3-28 Manipulation des certificats pour Secure OUC entre deux CPU S7-1500 via des interfaces
CP
Communication
Paramètres du client TLS

Pour établir une liaison TCP sécurisée dans le client TLS, procédez comme suit :
1. Créez un bloc de données global dans le navigateur du projet.
2. Définissez une variable de type TCON_IP_V4_SEC dans le bloc de données global. Saisissez à
cet effet la chaîne de caractères "TCON_IP_V4_SEC" dans le champ "Type de données".
L'exemple suivant montre le bloc de données global "Data_block_1" dans lequel est définie
la variable "SEC connection 1 TLS-Client" de type TCON_IP_V4_SEC.
L'ID d'interface a la valeur de l'identification matérielle de l'interface IE du CP local (client
TLS).
Figure 3-29 IP_V4_SEC_Client
3. Définissez les paramètres de la liaison TCP dans la colonne "Valeur initiale". Saisissez, par
exemple, l'adresse IPv4 du serveur TLS pour "RemoteAddress".
4. Définissez les paramètres de la Secure Communication dans la colonne "Valeur initiale".
– "ActivateSecureConn" : activation de Secure Communication pour cette liaison. Si ce
paramètre prend la valeur FALSE, les paramètres de sécurité suivants sont non
significatifs. Dans ce cas, vous pouvez configurer une liaison TCP ou UDP non
sécurisée.
– "TLSServerCertRef" : Entrez la valeur 2 (référence au certificat CA du projet TIA Portal
– "TLSClientCertRef" : ID du propre certificat X.509-V3.
Communication

Réglages du serveur TLS

Pour établir une liaison TCP sécurisée dans le serveur TLS, procédez comme suit :
1. Créez un bloc de données global dans le navigateur du projet.
2. Définissez une variable de type TCON_IP_V4_SEC dans le bloc de données global.
L'exemple suivant montre le bloc de données global "Data_block_1" dans lequel est définie
la variable "SEC connection 1 TLS-Server" de type TCON_IP_V4_SEC.
L'ID d'interface a la valeur de l'identification matérielle de l'interface IE du CP local (serveur
TLS).
Figure 3-30 IP_V4_SEC_Server
3. Définissez les paramètres de la liaison TCP dans la colonne "Valeur initiale". Saisissez, par
exemple, l'adresse IPv4 du client TLS pour "RemoteAddress".
Communication
4. Définissez les paramètres de la Secure Communication dans la colonne "Valeur initiale".

– "ActivateSecureConn" : activation de Secure Communication pour cette liaison. Si ce
paramètre prend la valeur FALSE, les paramètres de sécurité suivants sont non
significatifs. Dans ce cas, vous pouvez configurer une liaison TCP ou UDP non
sécurisée.
– "TLSServerReqClientCert" : Demande d'un certificat X.509-V3 par le client TLS. Inscrivez
la valeur "true".
– "TLSServerCertRef" : ID du propre certificat X.509-V3.
– "TLSClientCertRef" : entrez la valeur 2 (référence au certificat CA du projet TIA Portal
6. Interconnectez le paramètre CONNECT de l'instruction TSEND_C, TRCV_C ou TCON avec la
variable de type de données TCON_IP_V4_SEC.
Chargement de l'appareil comme nouvelle station

Lorsque vous chargez une configuration avec certificats et Secure Open User Communication
configurée en tant que nouvelle station dans votre projet STEP 7, les certificats du CP ne sont
pas chargés conjointement avec les certificats de la CPU. Les tableaux Certificats d'appareil
des CP ne contiennent plus de certificats après le chargement de l'appareil comme nouvelle
station.
Vous devez donc reconfigurer les certificats après le chargement. Sinon, un nouveau
chargement de la configuration provoquera la suppression des certificats initialement
présents dans le CP et Secure Communication ne fonctionnera pas.
Liaisons Secure Open User Communication par interfaces CPU et CP : points communs
• Ressources de liaison :
Aucune différence entre OUC et Secure OUC. Une liaison Secure OUC programmée utilise
une ressource de liaison tout comme une liaison OUC, indépendamment de l'interface
IE/PROFINET par laquelle la station communique.
• Diagnostic de liaison :
Aucune différence entre le diagnostic de liaison OUC et Secure OUC.
• Chargement dans la CPU de projets avec des liaisons Secure OUC :
Possible uniquement à l'état ARRÊT de la CPU si des certificats sont également chargés.
Recommandation : Charger dans l'appareil > Matériel et logiciel. Cela permet de garantir la
cohérence entre le programme avec Secure OUC, la configuration et les certificats.
Les certificats sont chargés avec la configuration matérielle, ce qui nécessite un arrêt de la
CPU. Le rechargement de blocs qui utilisent d'autres liaisons Secure OUC n'est possible à
l'état MARCHE que si les certificats nécessaires se trouvent déjà dans le module.
Communication
3.6.3.5 Secure OUC avec Modbus TCP

Pour la liaison Modbus TCP sécurisée, vous devez élaborer vous-même un bloc de données du
type de données système TCON_IP_V4_SEC ou TCON_QDN_SEC, le paramétrer et l'appeler
directement dans l'instruction MB_Server ou MB_CLIENT.
Conditions
• CPU S7-1500 à partir de la version V2.5 du firmware
• Le client Modbus (client TLS) peut accéder au serveur Modbus (serveur TLS) dans le réseau
par communication IP.
Exemple : configurer une liaison Modbus TCP sécurisée à un serveur Modbus TCP
Le paragraphe suivant décrit comme établir une Secure Open User Communication via
Modbus TCP entre un client Modbus TCP et un serveur Modbus TCP.
Procédez comme suit pour configurer une liaison sécurisée entre un client Modbus TCP (client
TLS) et un serveur Modbus TCP (serveur TLS) par l'adresse IPv4 du serveur de messagerie :
2. Définissez une variable de type de données TCON_IP_V4 SEC dans le bloc de données global.
Figure 3-31 TCON_IP_V4_SEC
Communication
l'adresse Ipv4 du serveur de messagerie sous "MailServerAdress".
Tapez par ex. sous "TLSServerCertRef" l'ID du certificat CA du partenaire de communication.
signification. Dans ce cas, vous pouvez configurer une liaison Modbus TCP non
sécurisée.
– "TLSServerCertRef" : Référence au certificat (CA) X.509 V3 du serveur Modbus TCP,
utilisée par le client TLS pour valider l'authentification du serveur Modbus TCP.
5. Créez une instruction MB_Client dans l'éditeur de programme.
6. Interconnectez le paramètre CONNECT de l'instruction MB_Client avec la variable de type de
données TCON_IP_V4_SEC.
3.6.3.6 Secure OUC par e-mail
Liaison sécurisée à un serveur de messagerie via l'interface de la CPU

Pour la liaison sécurisée à un serveur de messagerie, vous devez élaborer vous-même un bloc
de données du type de données système TMAIL_V4_SEC ou TMAIL_QDN_SEC, le paramétrer
et l'appeler directement dans l'instruction TMAIL_C.
Conditions
• Instruction TMAIL_C à partir de la version d'instruction V5.0
• STEP 7 à partir de V15
• CPU S7-1500 à partir de V2.5
• Vous avez affecté à la CPU (client TLS) tous les certificats CA du serveur de messagerie
(serveur TLS) et chargé la configuration dans la CPU.
Communication
Procédure pour l'établissement de la liaison sécurisée au serveur de messagerie

Vous avez le choix entre deux méthodes pour établir une liaison sécurisée au serveur de
messagerie :
• SMTPS : le client tente immédiatement d'établir une liaison TLS au serveur de messagerie
(procédure "Handshake"). Si le serveur de messagerie ne prend pas en charge TLS, aucune
liaison n'est établie.
• STARTTLS : le client établit une liaison au serveur de messagerie. Via la liaison TCP, le
client envoie une requête de "mise à niveau" de la liaison existante en liaison TLS
sécurisée. Si le serveur de messagerie prend en charge TLS, il envoie une commande au
client pour établir une liaison sécurisée. Le serveur de messagerie utilise à cet effet la
commande SMTP "STARTTLS". Le client établit ensuite une liaison sécurisée au serveur de
messagerie. Avantage : si le serveur de messagerie ne prend pas en charge TLS, le client et
le serveur de messagerie peuvent alors communiquer avec une communication non
sécurisée.
Le paramètre "Port distant" dans les types de données au niveau du paramètre de bloc
"MAIL_ADDR_PARAM" vous permet de définir la méthode à utiliser pour la communication.
Tableau 3- 6 Numéros de port pour les procédés SMTPS et STARTTLS
Procédé Port
SMTPS 4651
STARTTLS quelconque (≠465)2
1 L'instruction TMAIL_C utilise SMTPS uniquement pour le port 465. STARTTLS est utilisé pour tous les
autres ports.
2 Conformément à RFC, les serveurs de messagerie utilisent les ports 25 et 587 pour des liaisons
sécurisées avec STARTTLS. L'utilisation d'autres numéros de port pour SMTP n'est pas conforme à
RFC, la réussite de la communication avec un serveur de messagerie de ce type n'est pas garantie.
Communication
Exemple : Configurer une liaison sécurisée à un serveur de messagerie via IPv4

Le paragraphe suivant décrit comment établir une liaison sécurisée (SNMP over TLS) avec un
serveur de messagerie IPv4 grâce à l'instruction de communication TMAIL_C.
Procédez comme suit pour configurer une liaison sécurisée par l'adresse IPv4 du serveur de
messagerie :
2. Définissez une variable de type TMAIL_V4_SEC dans ce bloc de données global.
L'exemple ci-dessous montre le bloc de données global "MailConnDB" dans lequel est
définie la variable "MailConnectionSEC" du type de données TMAIL_V4_SEC.
Figure 3-32 Type de données TMAIL_V4_SEC
l'adresse Ipv4 du serveur de messagerie sous "MailServerAdress".
Remarque
Notez qu'à partir de la version V5.0 de l'instruction TMAIL_C, vous pouvez entrer dans le
type de données TMAIL_V4_SEC la valeur "0" pour l'ID d'interface. Dans ce cas, la CPU
recherche elle-même une interface locale appropriée de la CPU.
Communication
Tapez par ex. sous "TLSServerCertRef" l'ID du certificat CA du partenaire de communication.
sécurisée.
– "TLSServerCertRef" : référence au certificat (CA) X.509 V3 du serveur de messagerie,
utilisée par le client TLS pour valider l'authentification du serveur de messagerie.
5. Créez une instruction TMAIL_C dans l'éditeur de programme.
6. Interconnectez le paramètre MAIL_ADDR_PARAM de l'instruction TMAIL_C avec la variable de
type de données TMAIl_V4_SEC.
Dans l'exemple suivant, le paramètre Mail_ADDR_PARAM de l'instruction TMAIL_C est
interconnecté avec la variable "MailConnectionSEC" (type de données TMAIL_V4_SEC).
Figure 3-33 Instruction TMAIL_C
Liaison sécurisée à un serveur de messagerie via l'interface d'un module de communication

Pour la liaison sécurisée à un serveur de messagerie via un module de communication, vous
devez élaborer vous-même un bloc de données du type de données système TMAIL_V4_SEC,
TMAIL_QDN_SEC ou TMAIL_V6_SEC (uniquement CP), le paramétrer et l'appeler directement
dans l'instruction TMAIL_C.
Conditions :
• Instruction TMAIL_C avec la version d'instruction V4.0
• CPU S7-1500 à partir de la version 2.0 du firmware avec module de communication
CP 1543-1 à partir de la version 2.0 du firmware
• CPU ET 200SP à partir de la version de firmware V2.0 avec module de communication
CP 1542SP-1 (IRC) à partir de la version 1.0 du firmware
• Vous avez affecté au CP (client TLS) tous les certificats CA du serveur de messagerie
(serveur TLS) et chargé la configuration dans la CPU.
L'aide en ligne de STEP 7 vous décrit comment définir la liaison sécurisée à un serveur de
messagerie via l'interface d'un module de communication.
Communication
Exemple d'application
Cet exemple d'application (https://support.industry.siemens.com/cs/ww/fr/view/46817803)
vous indique comment configurer une liaison sécurisée à un serveur de messagerie via le CP
d'une station S7-1500 ou S7-1200 et comment envoyer un e-mail depuis la CPU S7 avec
l'instruction standard "TMAIL_C".

Pour plus d'informations sur les types de données système TMail_V4_SEC et TMAIL_QDN_SEC,
voir l'aide en ligne de STEP 7.
3.6.4 Communication PG/IHM sécurisée
3.6.4.1 Communication PG/IHM sur la base de mécanismes de sécurité normalisés

Une communication PG/PC et IHM – plus brièvement communication PG/IHM – sécurisée,
innovante et normalisée est mise en œuvre à partir de la version V17 entre les composants
centraux de TIA Portal, STEP 7 et WinCC et les automates et les appareils IHM actuels.
Il s'agit en l'occurrence des gammes de CPU suivantes :
• Gamme d'automates S7-1500 à partir de la version de firmware V2.9
• Gamme d'automates S7-1200 à partir de la version de firmware V4.5
• Software Controller à partir de la version de firmware V21.9
• SIMATIC Drive Controller à partir de la version de firmware V2.9
• PLCSim et PLCSim Advanced version V4.0
Des composants IHM ont en outre été actualisés afin de prendre en charge la communication
PG/IHM sécurisée :
• Panels ou PC configurés avec WinCC Basic, Comfort et Advanced
• PC avec WinCC RT Professional
• PC et Comfort Panels WinCC Unified
De même, les logiciels SINAMICS RT à partir de la version V6.1 et STARTDRIVE à partir de la
version V17 ont été actualisés.
Communication
Propriétés de la communication PG/IHM

La communication PG et la communication IHM se caractérisent principalement par leur
simplicité : L'établissement d'une liaison en ligne entre une console de programmation
hébergeant TIA Portal et une CPU, par exemple dans le but de charger un programme,
demande peu d'efforts. Cette liaison en ligne répond également à des critères tels que la
confidentialité et l'intégrité, sur la base d'un standard de communication SIMATIC éprouvé.
Dans le cadre de l'intégration de machines et d'installations dans un environnement
informatique ouvert, il convient cependant de poser les jalons pour une communication entre
la console de programmation/l'appareil IHM et la CPU qui ne se contente pas d'être sûre en
termes d'intégrité et de confidentialité des données sensibles ; cette sécurité doit également
se conformer aux normes universellement reconnues et, partant, répondre aux défis de
l'avenir.
Avec la version V14 de TIA Portal, le procédé "Open User Communication" pour une
communication basée sur le programme utilisateur a d'ores et déjà été étendu avec la
variante "Secure Open User Communication". D'autres mécanismes de communication basés
sur certificat se sont établis (HTTPS, Secure SMTP over TLS ou OPC UA). À partir de la version
V17 de TIA Portal, la communication PG/IHM fait également l'objet d'une amélioration : ici
aussi, le protocole TLS (Transport Layer Security) s'impose afin de sécuriser la communication
PG/IHM avec des mécanismes de sécurité normalisés.
Ce qui change
Mot de passe supplémentaire en option pour plus de sécurité

Le changement le plus marquant dans le cadre de la configuration des appareils mentionnés
ci-dessus est la possibilité d'attribuer un mot de passe pour la protection des données de
configuration confidentielles de la CPU respective. Il s'agit des données telles que les clés
privées qui sont nécessaires pour le fonctionnement correct des protocoles basés sur
certificat (communication sécurisée). Également pour la communication PG/IHM à partir de
TIA Portal V17. Vous avez la possibilité de vérifier les mots de passe attribués dès leur saisie
dans TIA Portal, à l'aide d'un paramètre de stratégie, et d'assurer ainsi le respect des stratégies
de mot de passe dans votre entreprise.
S'il s'avère, après une étude globale sur la base du concept Industrial Defense in Depth de
Siemens, que votre machine ou votre installation n'exige pas cette protection, par exemple
parce qu'il existe déjà une autre protection équivalente, vous pouvez renoncer à l'attribution
d'un mot de passe. Renoncer au mot de passe est possible si vous avez mis en œuvre des
mesures qui empêchent un accès non autorisé au projet TIA Portal et à la configuration de la
CPU.
ATTENTION
Faible protection des clés privées sans mot de passe
Notez que, sans mot de passe pour la protection des données de configuration
confidentielles, les clés privées pour certificats nécessaires à la communication sécurisée ne
sont que faiblement protégées.
Communication
Communication basée sur certificat entre PG/IHM et CPU

Comme la communication PG/IHM est basée sur certificat, il vous sera demandé d'accepter le
certificat du serveur au cours de la mise en service.
Des possibilités de paramétrage supplémentaires vous permettent de définir le
comportement de la CPU pendant le fonctionnement : vous pouvez, par exemple, spécifier
que la CPU autorise les connexions même aux appareils qui ne prennent pas en charge la
communication PG/IHM sécurisée.
Maintenance / Remplacement
Vous devez tenir compte de règles précises pour que le remplacement de la CPU se fasse sans
problème (voir Règles pour le remplacement de la CPU (Page 1)).
Voir aussi
Protection des données de configuration confidentielles (Page 1)
3.6.4.2 Autres paramètres pour la communication PG/IHM sécurisée

Outre l'attribution d'un mot de passe pour protéger les données de configuration
confidentielles de l'API, il existe d'autres possibilités de configuration du comportement de la
CPU en fonctionnement.
Mode de la communication PG/PC et de la communication IHM

Vous pouvez configurer la manière dont la CPU peut communiquer avec les consoles de
programmation et les appareils IHM.
• Uniquement par la communication PG/IHM sécurisée
• Aussi bien par la communication PG/IHM sécurisée que par la communication PG/IHM
utilisée jusqu'ici, aussi appelée "Communication PG/IHM héritée".
Marche à suivre
1. Naviguez jusqu'à la zone "Protection & Sécurité > Mécanismes de connexion" dans les
propriétés de la CPU.
2. Sélectionnez l'option souhaitée.
Communication
Sélectionner un certificat ou générer un nouveau certificat

Lorsque vous choisissez le mécanisme de connexion pour la communication PG/IHM, vous
pouvez sélectionner dans le même contexte un certificat de communication API pour
sécuriser la connexion ou bien faire générer un nouveau certificat par TIA Portal. Si vous avez
attribué un mot de passe ou si vous avez désactivé l'option de protection des données de
configuration confidentielles de l'API (c'est-à-dire que vous n'avez pas défini de mot de
passe), un certificat avec les paramétrages appropriés et un nom par défaut valide est déjà
prédéfini dans la zone "Protection & Sécurité > Mécanismes de connexion".
Marche à suivre
Si vous voulez que TIA Portal génère un nouveau certificat ou que vous voulez sélectionner
un autre certificat existant :
1. Cliquez sur les points de suspension dans le champ "Certificat de communication API" afin de
le développer.
2. Sélectionnez le certificat souhaité ou cliquez sur le bouton "Ajouter".
3. En cas d'ajout, une boîte de dialogue s'ouvre avec les options de paramétrage pour le
certificat.
L'utilisation "Serveur TLS" est imposée ; vous pouvez modifier les autres paramètres (par
exemple, le nom, l'algorithme de hachage...).
Les règles générales de gestion des certificats s'appliquent. Ainsi, l'option "Paramètres de
sécurité généraux pour la gestion des certificats" doit être activée si vous voulez générer un
certificat CA. Vous pouvez également générer un certificat API auto-signé.
Voir aussi
Gestion de certificats avec STEP 7 (Page 1)
Communication
3.6.4.3 Conseil pour la communication basée sur certificat entre PG et CPU

Un des effets de la communication PG/PC basée sur certificat (communication PG/PC
sécurisée) est que le partenaire de communication de la CPU, c.-à-d. la console de
programmation sur laquelle TIA Portal est installée, doit faire confiance au certificat d'appareil
de la CPU pour qu'une liaison puisse être établie.
De manière schématique, il existe les possibilités suivantes de faire confiance au certificat
d'une CPU du point de vue de TIA Portal :
• La console de programmation avec TIA Portal est en possession du certificat d'appareil de
la CPU parce qu'il a été créé ou importé dans le projet. Dans ce cas, la vérification de
certificat s'effectue automatiquement et sans demande de confirmation supplémentaire.
• La console de programmation avec TIA Portal ne possède pas le certificat d'appareil de la
CPU, par exemple parce que la CPU a été identifiée au moyen de la fonction "Abonnés
accessibles" et qu'elle n'existe pas dans le projet. Dans ce cas, TIA Portal demande à
l'utilisateur de TIA Portal de confirmer si le certificat est digne de confiance. Ce qui
implique de nombreuses manipulations, car la CPU ne se trouve par exemple pas à portée
de vue, et que l'authenticité ne peut pas être vérifiée immédiatement de ce fait.
• La console de programmation sur laquelle TIA Portal est installé possède le certificat CA
(autorité de certification) et toutes les CPU du réseau, qui sont accessibles pour TIA Portal,
possèdent des certificats d'appareil qui ont été émis par ce certificat CA.
Cette solution a un avantage : TIA Portal peut automatiquement vérifier des certificats
d'appareil même si les certificats d'appareil des partenaires de communication ne sont pas
présents dans TIA Portal.
Vous trouverez ci-après une description détaillée de la solution basée sur un certificat CA
(autorité de certification).
Conditions
Avec l'autorité de certification de TIA Portal, vous pouvez créer des certificats d'appareil pour
la CPU et utiliser à cet effet les certificats CA existant pour signer les certificats d'appareil.
Mais vous pouvez également importer une autre autorité de certification dans TIA Portal et
l'utiliser.
La condition préalable est l'activation du paramétrage de la sécurité globale du gestionnaire
de certificats. Seul ce paramétrage vous permet de créer des certificats signés par une CA.
Voir aussi : Gestion de certificats avec STEP 7 (Page 1)
Communication
Exporter un certificat CA pour les consoles de programmation

Pour exporter le certificat CA correspondant après la création et l'affectation d'un certificat,
procédez comme suit :
du projet.
2. Choisissez le tableau "Certificats CA" pour le certificat à exporter.
3. Ouvrez le menu contextuel en cliquant avec le bouton droit de la souris sur le certificat
sélectionné.
4. Cliquez sur "Exporter".
5. Choisissez le format d'exportation du certificat et le lieu de stockage.
Enregistrer le certificat CA dans TIA Portal

Pour publier le certificat exporté auprès de la console de programmation avec TIA Portal et
autoriser la vérification de certificat automatique, procédez de la manière suivante :
1. Copiez le certificat CA exporté dans l'étape précédente dans le répertoire suivant :
C:\ProgramData\Siemens\Automation\Certstore\Trusted
2. Démarrez TIA Portal.
L'onglet "Info" de la fenêtre d'inspection affiche, pour chaque certificat CA, un message
indiquant si le certificat CA correspondant a été repris avec succès dans le magasin de
certificats CA de TIA Portal.
Toutefois, aucune raison détaillée n'est fournie en cas d'échec.
Ajouter des certificats d'appareil à la liste de révocation de certificats (CRL) dans TIA Portal
Vous avez la possibilité d'ajouter des certificats d'appareil individuellement à une liste de
révocation de certificats (CRL), par exemple, parce que la clé correspondante n'est plus
considérée comme sûre.
Si TIA Portal établit une liaison à une CPU dont le certificat d'appareil figure dans la liste des
certificats révoqués, une boîte de dialogue s'affiche dans TIA Portal et le système vous
demande de confirmer si vous accordez quand même votre confiance au certificat. En cas de
refus, la liaison n'est pas établie.
Pour ajouter un certificat d'appareil à la liste des certificats révoqués, procédez comme suit :
1. Copiez le certificat d'appareil dans le répertoire suivant :
C:\ProgramData\Siemens\Automation\Certstore\CRL
2. Démarrez TIA Portal.
L'onglet "Info" de la fenêtre d'inspection affiche, pour chaque certificat, un message
indiquant si le celui-ci a été repris avec succès dans le magasin CRL de TIA Portal.
Toutefois, aucune raison détaillée n'est fournie en cas d'échec.
Voir aussi
Exemples de gestion de certificats (Page 1)
Communication
3.6.4.4 Comportement de la CPU du chargement jusqu'à l'état prêt à fonctionner

Pour que la communication entre la CPU et une console de programmation ou un appareil
IHM soit sécurisée, elle doit disposer d'un certificat. Toutefois, le certificat pour un
fonctionnement productif est seulement affecté avec le chargement du projet dans la CPU.
Pour que le chargement initial soit également sécurisé, la CPU crée d'abord un certificat auto-
signé. La description suivante explique les différentes phases de l'établissement de la
connexion.
Conditions nécessaires au premier établissement de la connexion pour le chargement de la CPU

• Il n'existe pas de mot de passe pour les données de configuration API confidentielles dans
la CPU.
Si la CPU a déjà été chargée et qu'elle possède donc déjà un mot de passe des données de
configuration API confidentielles, ce mot de passe doit correspondre au projet à charger.
• Un projet avec la configuration de la CPU (y compris le mot de passe pour les données de
configuration confidentielles de l'API) et le programme utilisateur sont disponibles.
• La CPU est à l'état de fonctionnement STOP.
• La console de programmation et la CPU sont directement connectées entre elles et se
trouvent dans un environnement protégé ; vous pouvez donc identifier la CPU qui doit
être chargée et contrôler la liaison entre la CPU et la console de programmation.
Premier établissement de la connexion à la CPU - Phase de mise à disposition

Le premier établissement de la connexion pour le chargement de la CPU est déjà sécurisé via
le procédé TLS au sens d'une communication PG/IHM sécurisée.
Cependant la CPU utilise pour l'établissement de cette connexion un certificat d'appareil
constructeur (s'il existe) ou un certificat auto-signé. Des restrictions s'appliquent toutefois à
l'utilisation de la CPU dans cette phase. Dans cette phase, la CPU attend la mise à disposition
de l'information de clé basée sur le mot de passe - ou plus simplement : elle attend le mot de
passe pour les données de configuration API confidentielles. Dans la suite, cette phase est
appelée aussi phase de mise à disposition. La phase de mise à disposition de la CPU est
signalée par un message correspondant dans le tampon de diagnostic.
Communication
Lors du chargement d'un projet dans la CPU, la CPU reçoit les données du projet :
• Configuration matérielle y compris les certificats pour la communication sécurisée
(OPC UA, HTTPS, Secure OUC, Secure PG/HMI communication)
• Programme utilisateur
Figure 3-34 Établissement de la connexion - phase de mise à disposition
Terminer la phase de mise à disposition

TIA Portal n'enregistre pas dans le projet le mot de passe pour les données de configuration
API confidentielles ou l'information de clé générée à partir du mot de passe.
C'est pourquoi le mot de passe est interrogé dans un dialogue lors du premier chargement ou
lors du chargement d'un nouveau projet, et transféré à la CPU sous forme d'information de
clé. C'est à l'issue de cette étape seulement que la CPU est en mesure d'utiliser les données de
configuration API confidentielles - la phase de mise à disposition est alors terminée et la CPU
peut passer en fonctionnement.
Si vous ne protégez pas les données de configuration API confidentielles avec un mot de
passe, la saisie du mot de passe n'a pas lieu au premier chargement. Ceci n'a pas d'influence
sur le déroulement de la communication PG/IHM, mais vous devez être conscient du fait que
les données de configuration API confidentielles (par exemple les clés privées) sont à peine
protégées contre les accès non autorisés.
Communication
Démarrage de la communication PG/IHM

Une fois que le chargement a eu lieu et que la CPU a reçu le certificat pour la communication
PG/IHM sécurisée, la console de programmation se connecte une nouvelle fois, cette fois sur
la base du certificat CPU chargé.
Figure 3-35 Démarrage de la communication PG/IHM
3.6.4.5 Utiliser la communication IHM sécurisée

À partir de la version V17 de TIA Portal, CPU et appareil IHM communiquent par le biais de la
communication IHM sécurisée si ces deux appareils remplissent les conditions nécessaires.
La base de la communication IHM sécurisée est la vérification par l'appareil IHM de
l'authenticité de la CPU et son classement comme "digne de confiance" par le biais du
certificat de communication API que la CPU envoie lors de l'établissement de la connexion. Ce
n'est que dans ce cas que la communication IHM sécurisée est possible.
Ce chapitre décrit les mesures à prendre pour les différents appareils IHM afin de marquer
manuellement le certificat de communication API comme "digne de confiance".
Conditions
• La CPU et l'appareil IHM prennent en charge la communication IHM sécurisée.
• La CPU contient un projet actuel (TIA Portal à partir de V17).
Communication
Configurer la communication IHM sécurisée

1. Configurez une vue des alarmes pour l'appareil IHM.
Remarque
Sans vue des alarmes, vous ne pourrez pas détecter les erreurs éventuelles lors de
l'établissement de la connexion.
2. Configurez les paramètres Security requis dans la CPU. Sélectionnez un certificat de

communication API pour sécuriser la liaison IHM ou faites générer un certificat de
communication API par TIA Portal.
3. Configurez la liaison IHM entre la CPU et l'appareil IHM.
4. Chargez le projet dans la CPU et dans l'appareil IHM. Lors du transfert du projet, le certificat
de communication API ainsi qu'éventuellement un certificat CA requis (de l'autorité de
certification) sont transmis à la CPU et à l'appareil IHM.
Approuver le certificat de communication API

Lors de l'établissement de la connexion, la CPU transmet le certificat de communication API à
l'appareil IHM.
• Si le certificat de communication API est déjà présent à l'état "digne de confiance" sur
l'appareil IHM, une communication IHM sécurisée s'établit automatiquement entre la CPU
et l'appareil IHM.
• Si le certificat de communication API n'est pas encore à l'état "digne de confiance" sur
l'appareil IHM, un message s'affiche dans la vue des alarmes de l'appareil IHM signalant
que la CPU n'est pas considérée comme digne de confiance et fournissant un code
d'erreur.
Dans ce cas, vous devez marquer le certificat de communication API sur l'appareil IHM
comme "digne de confiance".
Procédez comme suit selon le type de votre appareil IHM :
Basic Panels de 2ème génération

1. Dans le centre de démarrage, sélectionnez "Settings > Internet Settings > Certificate store".
2. Sélectionnez le certificat de communication API de la CPU dans la liste "Available certificates
in Device".
3. Cliquez sur le bouton "Trust".
4. Redémarrez le logiciel HMI Runtime.
Unified Comfort Panels

1. Ouvrez le Control Panel.
2. Sélectionnez "Security > Certificates".
3. Sélectionnez l'entrée "Other Certificates" dans la liste de sélection "Certifcate store".
4. Sélectionnez le certificat de communication API de la CPU dans la liste "Other certificates".
Communication
5. Cliquez sur le bouton "Trust".

Comfort Panels, Mobile Panels de 2ème génération

1. Ouvrez le gestionnaire de fichiers au moyen de l'icône Windows CE Desktop "My Device".
2. Naviguez jusqu'au répertoire "\flash\simatic\SystemRoot\OMS\Untrusted". Vous y trouverez le
certificat de communication API de la CPU.
3. Copiez le certificat de communication API de la CPU dans le répertoire
"\flash\simatic\SystemRoot\OMS\Trusted".
Si le certificat de communication API est présent à l'état "digne de confiance" sur l'appareil
IHM, la communication IHM sécurisée peut s'établir. Pour plus d'informations, voir les
instructions de service de l'appareil IHM.
3.6.4.6 Utiliser la communication PG/PC classique pour TIA Portal

À partir de TIA Portal version V17, TIA Portal et les CPU S7-1200/S7-1500 à partir de la version
de firmware V4.5/V2.9 communiquent automatiquement de manière sécurisée : les
partenaires de communication règlent automatiquement leurs mécanismes de connexion au
mode de sécurité maximal.
Seules des circonstances particulières (voir Informations relatives à la compatibilité (Page 1))
entraînent un retour à la communication PG/PC classique utilisée jusqu'ici.
Dans certains cas d'application toutefois, une sécurité accrue peut ne pas être souhaitée, car
elle aurait un impact négatif sur la vitesse de transmission pour les CPU à performances de
communication plus réduites.
Conditions
• Aucune liaison en ligne aux CPU ne doit être établie.
• Pour les CPU qui doivent être accessibles en ligne, l'option "Autoriser uniquement la
communication PG/PC et HMI sécurisée" ne doit pas être activée (paramètres CPU dans la
zone "Mécanismes de connexion").
• Les partenaires de communication se trouvent dans un environnement protégé, par
exemple pendant la phase de mise en service.
Configurer la communication PG/PC classique

1. Sélectionnez la commande "Utiliser uniquement la communication PG/PC héritée" dans le
menu "En ligne".
2. Cochez la case devant la commande de menu.
Résultat : Toutes les liaisons en ligne sont établies comme dans les versions de TIA Portal
antérieures à V17.
Ce paramétrage est conservé pour la durée de la session. L'option "Utiliser uniquement la
communication PG/PC héritée" n'est pas activée lorsque vous ouvrez un projet.
Communication
Comportement lorsque l'option "Utiliser uniquement la communication PG/PC héritée" est

activée
• Il n'est pas possible de définir, modifier ou supprimer en ligne un mot de passe de
protection des données de configuration API confidentielles pour les CPU. Ces fonctions
requièrent la désactivation de l'option "Utiliser uniquement la communication PG/PC
héritée".
• Une CPU configurée pour n'autoriser que les communications PG/PC et IHM sécurisées
n'est plus accessible en ligne.
3.6.4.7 Informations relatives à la compatibilité

La description suivante fournit des informations sur l'interaction entre les différentes versions
de TIA Portal avec les différentes versions de firmware des CPU et les effets sur le type de
liaison PG/HMI.
Projets créés avec TIA Portal < V17

SI vous avez créé un projet p. ex. avec la version V16 de TIA Portal pour une CPU S7-1500 (p.
ex. version V2.8), alors la configuration correspondante avec TIA Portal V17 peut également
être chargée sur une CPU S7-1500 V2.9 p. ex. en cas de remplacement - et ce avec le même
comportement que sur une CPU S7-1500 V2.8.
Les projets créés avec TIA Portal < V17 et transférés sur une carte mémoire fonctionnent
également sans problème sur une CPU S7-1500 V2.9.
Toutefois, dès que vous ouvrez le projet avec TIA Portal ≥ V17, actualisez la version de
firmware de la CPU par un remplacement d'appareil et par là même effectuez un
enregistrement comme CPU avec une version de firmware ≥ V2.9, le concept de protection
des données de configuration API confidentielles s'applique (voir Informations utiles sur la
protection des données de configuration API confidentielles (Page 1)). Le projet ne peut plus
être édité avec des versions antérieures à TIA Portal V17.
PG/IHM et CPU différemment connectés

Comme expliqué dans les sections précédentes, la liaison PG/IHM sécurisée à partir de V17
entre une PG/un appareil IHM et la CPU (version actuelle) se distingue par l'utilisation du
procédé de communication normalisé TLS (Transport Layer Security).
Vous avez la possibilité de connecter une CPU V2.9 à une console de programmation actuelle
avec TIA Portal à partir de V17 et, en plus, à un appareil IHM avec un runtime de la version
précédente, par exemple. Les appareils ajustent alors leurs mécanismes de connexion
automatiquement. Pour mieux distinguer les deux mécanismes de connexion, nous
désignons la procédure qui existait jusqu'à maintenant – et qui est basée sur une variante de
la communication S7 – par "procédé héritage" ("legacy").
Communication
3.7 SNMP
En résumé ("PG" signifie ici console de programmation avec TIA Portal) :

• PG/IHM et CPU avec V17 (ou version supérieure) : le procédé TLS est utilisé.
• La PG/ l'IHM est d'une version antérieure (< V17) : le procédé héritage est utilisé, à
condition que vous ayez désactivé l'option "Autoriser uniquement la communication PG/PC
et HMI sécurisée" dans les propriétés de la CPU.
• CPU avec V17 (ou supérieure), plusieurs PG/IHM avec V17 (ou supérieure) et versions
antérieures connectées : TLS et le procédé héritage sont utilisés, à condition que vous
ayez désactivé l'option "Autoriser uniquement la communication PG/PC et HMI sécurisée"
dans les propriétés de la CPU.
Lorsque l'état de la CPU change

Le tampon de diagnostic vous informe lorsque l'état de la CPU change en raison
d'événements liés à la communication PG/IHM sécurisée.
Exemples :
• Après le chargement réussi d'une configuration avec mot de passe configuré, le tampon
de diagnostic signale que la CPU passe de la phase de mise à disposition au mode sécurisé
(procédé TLS).
• Vous avez connecté une PG avec TIA Portal V17 à une CPU V2.9. La communication
PG/IHM sécurisée (procédé TLS) se met automatiquement en place.
3.7 SNMP
3.7.1 Désactivation de SNMP

Le protocole de gestion de réseau SNMP (Simple Network Management Protocol) est un
protocole utilisant divers services et outils pour la découverte et le diagnostic de la topologie
du réseau.
Vous trouverez dans cette FAQ
(https://support.industry.siemens.com/cs/ww/fr/view/79993228) une description des
requêtes SNMP que les CPU S7-1500 et S7-1200 peuvent accepter.
SNMP utilise le protocole de transport UDP. SNMP connaît deux composants de réseau, le
gestionnaire de réseau SNMP et le client SNMP. Le gestionnaire SNMP surveille les nœuds de
réseau. Les clients SNMP collectent, sur les différents nœuds de réseau, les différentes
informations spécifiques au réseau et les enregistrent de manière structurée dans la MIB
(Management Information Base). Avec ces données, divers services et outils peuvent
exécuter un diagnostic de réseau détaillé.
Dans certaines conditions, il est judicieux de désactiver SNMP. Exemples :
• La stratégie de sécurité de votre réseau n'autorise pas l'utilisation de SNMP.
• Vous utilisez une solution SNMP personnalisée, par ex. vos propres instructions de
communication.
Si vous désactivez SNMP sur un appareil, certaines possibilités de diagnostic de la topologie
de réseau (par ex. dans l'outil PRONETA ou sur le serveur Web de la CPU) ne seront plus
disponibles.
Communication
3.7 SNMP
Désactivation de SNMP
Pour désactiver SNMP sur l'une des interfaces intégrées d'une CPU S7-1500, procédez comme
suit :
1. Créez sous STEP 7 un bloc de données qui contient la structure de l'enregistrement B071H.
– Le tableau suivant montre la structure de cet enregistrement B071H.
Octet Élément Codage Explication

0-1 BlockID F003H En-tête
2-3 BlockLength 8 La longueur de l'enregistre-
4 Version 01H ment est comptée à partir de
l'octet 4 "Version".
5 Subversion 00H
6-7 réservé - -
8-11 Commande SNMP Désactivation/activation Si vous voulez désactiver
de SNMP SNMP, entrez la valeur "0".
Si vous voulez activer SNMP,
entrez la valeur "1".
2. Transférez l'enregistrement B071H dans l'OB de démarrage (OB100) avec l'instruction WRREC
(écrire enregistrement) sur la CPU.
Pour ce faire, utilisez l'ID de matériel d'une interface intégrée de la CPU.
3.7.2 Exemple : Désactivation de SNMP pour une CPU 1516-3 PN/DP
Tâche
La stratégie de sécurité de votre réseau n'autorisant pas l'utilisation de SNMP, vous voulez
désactiver SNMP pour une CPU 1516-3 PN/DP.
Conditions
• CPU 1516-3 avec firmware V2.0
• STEP 7 à partir de V14
Communication
3.7 SNMP
Solution
Créez d'abord un bloc de données qui contient la structure de l'enregistrement B071H. La
figure suivante montre le bloc de données "Deactivate SNMP". Le bloc de données "Deactivate
SNMP" contient, outre l'enregistrement B071H, des variables que vous utiliserez pour la
transmission de l'enregistrement. La variable "snmp_deactivate" sert à lancer la tâche pour
WRREC. Enregistrez la variable dans la zone de mémoire rémanente pour que la valeur soit
également disponible dans l'OB de démarrage (OB100).
Figure 3-36 Exemple : Bloc de données pour la désactivation de SNMP
Transférez l'enregistrement B071H dans l'OB de démarrage (OB100) avec l'instruction WRREC
(écrire enregistrement) sur la CPU 1516-3 PN/DP.
Dans le code de programme ci-après, l'enregistrement B071H est transféré par l'instruction
WRREC dans une boucle REPEAT UNTIL.
ORGANIZATION_BLOCK "Startup"
TITLE = "Complete Restart"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
BEGIN
REPEAT
"WRREC_DB_1"
(REQ := "Deactivate SNMP".snmp_deactivate,
//Transfer data record
INDEX:=16#B071,
//Data record number for SNMP deactivation
ID:="Local~PROFINET_interface_1",
//any integrated PROFINET Interface
DONE => "Deactivate SNMP".snmp_done,
ERROR => "Deactivate SNMP".snmp_error,
STATUS => "Deactivate SNMP".snmp_status,
RECORD := "Deactivate SNMP".snmp_record)
//Data record
UNTIL "Deactivate SNMP".snmp_done OR "Deactivate SNMP".snmp_error
END_REPEAT;
END_ORGANIZATION_BLOCK
Communication
3.7 SNMP
Utilisation du code de programme

Vous trouvez le code de programme complet ici.
Pour intégrer le code de programme à votre projet, procédez comme suit :
1. Copier le code de programme complet dans le presse-papiers par Ctrl+A, Ctrl+C.
2. Ouvrez un éditeur de texte ("Bloc-notes" par ex.).
3. Collez le contenu du presse-papiers dans l'éditeur de texte par Ctrl+V.
4. Enregistrez le document comme fichier scl, par ex. SNMP_DEACT.scl.
5. Ouvrez votre projet sous STEP 7.
6. Importez le fichier scl comme source externe.
Pour plus d'informations sur l'importation de sources externes, référez-vous à l'aide en ligne
de STEP 7.
7. Générez l'OB de démarrage et les blocs de données. (Cliquez à droite sur le fichier scl, menu
contextuel : "Générer le bloc à partir de la source")
Réactivation de SNMP
Avec de légères modifications, vous pouvez utiliser le code de programme ci-dessus pour
activer SNMP.
Attribuez aux variables "Deactivate SNMP".snmp_record.SNMPControl dans le programme
utilisateur la valeur "1" :
"Deactivate SNMP".snmp_record.SNMPControl := 1;
SNMP est de nouveau activé lors du prochain démarrage de la CPU.
Communication
Communication PG 4
Propriétés
La communication PG permet à la CPU ou à un autre module compatible avec la
communication d'échanger des données avec une station d'ingénierie (par ex. PG, PC).
L'échange de données peut être effectué via des sous-réseaux PROFIBUS et PROFINET. Le
passage entre différents sous-réseaux S7 est également pris en charge.
La communication PG met à votre disposition des fonctions dont vous avez besoin pour
charger les programmes et les données de configuration, exécuter les tests et évaluer les
informations de diagnostic. Ces fonctions sont intégrées au système d'exploitation du module
compatible avec la communication.
Remarque
À partir de la version V17 de TIA Portal, le protocole TLS (Transport Layer Security) est pris en
charge dans la communication PG/IHM afin de sécuriser l'échange de données entre le PG/PC
et la CPU au moyen de mécanismes de sécurité normalisés.
Pour plus d'informations, voir les chapitres suivants :
• Conditions requises pour une communication sécurisée (Page 1)
• Communication PG/IHM sécurisée (Page 1)
Conditions
• Il existe une liaison physique entre le PG/PC et le module apte à la communication.
• Si l'accès au module apte à la communication doit être réalisé via un routage S7, la
configuration matérielle doit être chargée dans les stations (routeur S7 et nœud
d'extrémité) impliquées.
Procédure pour la connexion en ligne

Pour la communication PG, vous devez établir une liaison en ligne avec la CPU :
1. Sélectionnez la CPU dans la navigation du projet dans STEP 7.
2. Sélectionnez la commande de menu "En ligne > "Connecter en ligne".
Communication
Communication PG
3. Dans la boîte de dialogue "Connecter en ligne", procédez aux paramétrages suivants pour
votre liaison en ligne :
– Sélectionnez le type d'interface (p. ex. PN/IE) dans la liste déroulante "Type de
l'interface PG/PC".
– Dans la liste déroulante "Interface PG/PC", sélectionnez l'interface PG/PC (p. ex. carte
Ind. Ethernet) que vous voulez utiliser pour l'établissement de la liaison en ligne.
– Dans la liste déroulante "Liaison avec interface/sous-réseau", sélectionnez l'interface ou
le sous-réseau S7 relié(e) physiquement avec la console de programmation.
– Si le module apte à la communication est accessible via un routeur S7 (passerelle),
sélectionnez le routeur S7 reliant les sous-réseaux concernés dans la liste déroulante
"1ère passerelle".
Figure 4-1 Créer une communication PG
Communication
Communication PG
4. Cliquez sur "Démarrer la recherche".

Tous les appareils auxquels vous pouvez accéder avec la communication PG apparaissent
rapidement dans le tableau "Abonnés compatibles dans le sous-réseau cible".
5. Dans le tableau "Abonnés compatibles dans le sous-réseau cible", choisissez la CPU
correspondante et confirmez par "Connecter".
Pour plus d'informations sur "Liaison en ligne", référez-vous à l'aide en ligne de STEP 7.
Communication
Communication IHM 5
Propriétés
La communication IHM permet à un ou plusieurs appareils IHM (par ex.
HMI Basic/Comfort/Mobile Panel) d'échanger des données de contrôle-commande avec une
CPU via l'interface PROFINET ou PROFIBUS DP. Les données sont échangées via des liaisons
IHM.
Si vous souhaitez créer plusieurs liaisons IHM avec une CPU, utilisez par ex. :
• les interfaces PROFINET et PROFIBUS DP de la CPU
• des CP et CM avec les interfaces appropriées
Remarque
À partir de la version V17 de TIA Portal, le protocole TLS (Transport Layer Security) est pris en
charge dans la communication PG/IHM afin de sécuriser l'échange de données entre le PG/PC
et la CPU au moyen de mécanismes de sécurité normalisés.
Pour plus d'informations, voir les chapitres suivants :
• Conditions requises pour une communication sécurisée (Page 1)
• Communication PG/IHM sécurisée (Page 1)
Marche à suivre pour créer une communication IHM

Dès que vous amenez une variable (issue d'un bloc de données global par ex.) par glisser-
lâcher dans une vue IHM ou dans la table des variables IHM, STEP 7 crée automatiquement
une liaison IHM. Au lieu de cela, vous pouvez aussi configurer vous-même la liaison IHM.
Procédez comme suit pour configurer une liaison IHM.
1. Configurez l'appareil IHM dans une configuration existante avec la CPU, dans la vue de
réseau de l'éditeur de matériel et de réseaux de STEP 7.
2. Sélectionnez le bouton "Liaisons", puis "Liaison IHM" dans la liste déroulante.
3. Créez une ligne entre les nœuds d'extrémité de la liaison (appareil IHM et CPU) à l'aide d'un
glisser-déposer. Les nœuds d'extrémités sont marqués en couleur. Si aucun sous-réseau S7
correspondant n'existe, il sera créé automatiquement.
Communication
Communication IHM
4. Choisissez la ligne de la liaison IHM dans l'onglet "Liaisons".

Dans la zone "Général" de l'onglet "Propriétés", vous pouvez voir les propriétés de la liaison
IHM et les modifier en partie.
Figure 5-1 Configurer la communication IHM
5. Chargez la configuration matérielle dans la CPU.

6. Chargez la configuration matérielle dans l'appareil IHM.
Vous trouverez des informations concernant le routage S7 de liaisons IHM au chapitre
Routage S7 (Page 1).
Pour plus d'informations sur la création de liaisons IHM, référez-vous à l'aide en ligne de
STEP 7.
Communication
Open User Communication 6
6.1 Vue d'ensemble d'Open User Communication
Caractéristiques d'Open User Communication

C'est par Open User Communication, appelée aussi "communication ouverte", que la CPU
échange des données avec un autre appareil capable de communiquer. Open User
Communication se distingue par les caractéristiques suivantes :
• Norme ouverte (les partenaires de communication peuvent être deux CPU SIMATIC ou une
CPU SIMATIC et un appareil tiers adéquat)
• Communication au moyen de différents protocoles (désignés par "types de liaison" dans
STEP 7)
• Flexibilité élevée en ce qui concerne les structures de données à transmettre permettant
un échange de données ouvert avec n'importe quel partenaire de communication à
condition que celui-ci prenne en charge les types de liaison mis à disposition.
• Secure Communication : Pour la protection de votre système d'automatisation, vous
pouvez procéder à un échange de données sécurisé via Open User Communication. Avec
la Secure Open User Communication, les données sont signées et cryptées avant d'être
envoyées, voir aussi Secure Open User Communication (Page 1).
• Open User Communication est possible dans différents systèmes d'automatisation, voir les
caractéristiques techniques des manuels respectifs.
Exemples :
– Interfaces PROFINET/ Ind. Ethernet intégrées de CPU (S7-1500, CPU ET 200SP,
contrôleur logiciel S7-1500, CPU 1513/1516pro-2 PN)
– Interfaces PROFINET/ Ind. Ethernet de modules de communication (par ex. CP 1543-1,
CM 1542-1, CP 1543SP-1)
Pour plus d'informations sur Secure Communication, voir le chapitre Secure Communication
(Page 1).
Informations sur le système S7-1500R/H

Vous trouverez des informations sur Open User Communication avec le système redondant
S7-1500R/H au paragraphe Communication avec le système redondant S7-1500R/H (Page 1).
Communication
Open User Communication
6.2 Protocoles pour Open User Communication
Protocoles pour Open User Communication

Les protocoles suivants sont disponibles pour la communication ouverte :
Tableau 6- 1 Protocoles de transport pour la communication ouverte
Protocole de transport Via interface

TCP conformément à RFC 793 PROFINET/Industrial Ethernet
ISO-on-TCP conformément à RFC 1006 (Class 4) PROFINET/Industrial Ethernet
ISO conformément à ISO/IEC 8073 Industrial Ethernet (uniquement CP 1543-1)
UDP conformément à RFC 768 PROFINET/Industrial Ethernet
FDL PROFIBUS
Tableau 6- 2 Protocoles d'application pour la communication ouverte
Protocole d'application Protocole de transport utilisé

Modbus TCP TCP conformément à RFC 793
E-mail TCP conformément à RFC 793
FTP TCP conformément à RFC 793
TCP, ISO-on-TCP, ISO, UDP

Ces protocoles (à l'exception d'UDP) établissent une liaison de transport avec le partenaire de
communication avant la transmission de données. Les protocoles orientés liaison sont utilisés
quand la protection contre la perte de données lors du transfert est particulièrement
importante.
Avec UDP, vous avez les possibilités suivantes :
• Envoi individuel (unicast) à un abonné ou diffusion générale (broadcast) à tous les
abonnés du PROFINET via l'interface PROFINET de la CPU ou l'interface Industrial Ethernet
du CP 1543-1
• Diffusion de groupe (multicast) à tous les récepteurs d'un groupe multicast via l'interface
PROFINET de la CPU* ou l'interface PROFINET/Industrial Ethernet du CP 1543-1
* à partir de la version V2.0 du firmware, l'interface PROFINET de la CPU prend en charge 5
groupes multicast au maximum
Longueur max. des données utiles : Les caractéristiques techniques des manuels respectifs
vous indiquent quelles longueurs maximales des données utiles sont prises en charge.
Communication
Protocole pour la communication via PROFIBUS : FDL

La transmission de données via une liaison FDL (Fieldbus Data Link) convient au transfert de
blocs de données cohérents à un partenaire de communication sur PROFIBUS prenant en
charge l'envoi ou la réception conformément au service SDA (Send Data with Acknowledge)
de FDL selon EN 50170, vol 2. Les deux partenaires ont les mêmes droits, c'est-à-dire que
chacun d'eux peut déclencher l'envoi et la réception en fonction des événements.
Conformément au service SDN (Send Data with No Acknowledge) de FDL selon EN 50170,
vol 2., FDL permet :
• Diffusion générale (broadcast) à tous les abonnés du PROFIBUS via l'interface PROFIBUS du
CM 1542-5
• Diffusion de groupe (multicast) à tous les récepteurs d'un groupe multicast via l'interface
PROFIBUS du CM 1542-5
Modbus TCP
Le protocole Modbus est un protocole de communication avec topologie linéaire sur la base
d'une architecture maître/esclave. En mode de transmission Modbus TCP (Transmission
Control Protocol), les données sont transmises comme paquets TCP/IP.
La communication est commandée exclusivement par des instructions appropriées dans le
programme utilisateur.
E-mail et FTP
L'e-mail permet par exemple d'envoyer des contenus de blocs de données (par ex. données
de processus) en pièce jointe.
Vous utilisez la liaison FTP (File Transfer Protocol) pour transférer des fichiers vers et depuis
les appareils S7.
Du côté client, la communication est commandée par des instructions appropriées dans le
Exemple d'application : MQTT Publisher pour la CPU SIMATIC S7-1500

Le "Message Queue Telemetry Transport" (MQTT) est un protocole simple au niveau TCP/IP. Il
est adapté pour l'échange de messages entre des appareils avec une fonctionnalité réduite et
pour la transmission via des réseaux non fiables.
L'exemple d'application met à votre disposition un bloc fonctionnel avec lequel vous pouvez
implémenter le protocole MQTT dans SIMATIC S7-1500.
Vous trouverez l'exemple d'application sur Internet
Communication
6.3 Instructions pour Open User Communication
Bibliothèque de blocs pour les alarmes SYSLOG

Syslog est un protocole binaire de structure simple au niveau UDP/IP. Il permet aux
applications d'envoyer des alarmes, des avertissements ou des états d'erreurs à un serveur
Syslog. Syslog est typiquement utilisé pour la gestion de systèmes d'ordinateurs et la
surveillance de sécurité et s'est établi comme un standard dans le domaine des protocoles.
Pour implémenter le protocole Syslog dans une S7-1500, une solution vous est proposée avec
la bibliothèque "LSyslog". En plus de la bibliothèque, un exemple d'application est mis à votre
disposition. Il vous montre comment générer des alarmes Syslog dans votre automate et les
envoyer au serveur Syslog.
Vous trouverez la bibliothèque de blocs "LSyslog" et l'exemple d'application correspondant sur
Internet (https://support.industry.siemens.com/cs/ww/fr/view/51929235).
Introduction
Vous pouvez configurer la communication Open User via la liaison concernée (par ex. liaison
TCP) comme suit :
• en programmant les partenaires de communication dans les programmes utilisateur ou
• en configurant la liaison dans STEP 7 dans l'éditeur de matériel et de réseaux
Que la liaison soit créée par programmation ou par configuration, des instructions d'envoi et
de réception des données sont toujours nécessaires dans les programmes utilisateur des deux
partenaires de communication.
Création de la liaison avec le programme utilisateur

Quand la liaison est créée de manière programmée, elle est établie et suspendue au moyen
d'instructions dans le programme utilisateur.
Dans certains domaines d'application, il peut être avantageux de ne pas établir les liaisons de
communication de manière statique, à l'aide d'une configuration dans la configuration
matérielle, mais plutôt dans le programme utilisateur. Grâce à une application spécifique,
vous pouvez faire commander la création des liaisons par le programme, c'est-à-dire qu'elles
sont créées en cas de besoin. La création programmée permet, en outre, de libérer des
ressources de liaison après la transmission des données.
Une structure de données qui contient les paramètres requis pour établir la liaison, est
nécessaire pour chaque liaison de communication (par ex. type de données système
"TCON_IP_v4" pour TCP).
Les types de données système (TDS) sont mis à disposition par le système et ont une
structure prédéfinie qui ne peut pas être modifiée.
Les différents protocoles possèdent chacun leurs propres structures de données (voir le
tableau suivant). Les paramètres sont enregistrés dans un bloc de données ("DB de
description de la liaison") par ex. du type de données système TCON_IP_v4.
Communication
Vous disposez de deux possibilités pour spécifier le DB avec la structure de données :

• Recommandation : Faites créer automatiquement le bloc de données lors du paramétrage
de la liaison dans les propriétés de l'éditeur de programme à l'aide du paramétrage de
liaison pour les instructions TSEND_C, TRCV_C et TCON.
• Créer un bloc de données manuellement, le paramétrer et l'écrire directement dans
l'instruction
Nécessaire pour :
– Secure OUC
– Liaison via DNS
– E-mail
– FTP
Dans le "DB de description de la liaison", vous pouvez modifier les paramètres de liaison.
Pour apprendre à programmer l'instruction TCON afin de créer une liaison pour Open User
Communication entre deux CPU S7-1500, voir cette FAQ
Protocoles, types de données système et instructions utilisables pour la création programmée

Le tableau suivant vous montre les protocoles de la communication Open User
Communication ainsi que les types de données système et les instructions correspondants.
Tableau 6- 3 Instructions lors de la création programmée de la liaison
Protocole Type de données sys- Instructions

tème
TCP • TCON_QDN Etablir la liaison et envoyer/recevoir des données
avec :
• TCON_IP_v4
• TSEND_C/TRCV_C ou
ISO-on-TCP • TCON_IP_RFC • TCON, TSEND/TRCV ou
ISO conformément à • TCON_ISOnative1 • TCON, TUSEND/TURCV
ISO/CEI 8073 (Class 4)
• TCON_Configured (suspension de la liaison possible avec
TDISCON)
UDP • TCON_IP_v4 Etablir la liaison et envoyer/recevoir des données
avec :
• TADDR_Param
• TSEND_C/TRCV_C
• TADDR_SEND_QDN
• TUSEND/TURCV/TRCV
• TADDR_RCV_IP
(suspension de la liaison possible avec
TDISCON)
FDL1 • TCON_FDL Etablir la liaison et envoyer/recevoir des données
avec :
• TCON, TSEND/TRCV ou
• TCON, TUSEND/TURCV
TDISCON)
Communication
Protocole Type de données sys- Instructions

tème
Modbus TCP • TCON_IP_v4 • MB_CLIENT
• TCON_QDN • MB_SERVER
• TCON_Configured
E-mail • TMAIL_v4 • TMAIL_C
• TMAIL_v6
• TMAIL_FQDN
FTP2 • FTP_CONNECT_IPV43 • FTP_CMD
• FTP_CONNECT_IPV63
• FTP_CONNECT_NAM
E3
1 Ce protocole n'est utilisable qu'avec le CM 1542-5.

2 Ce protocole n'est utilisable qu'avec le CP 1543-1.
3 Type de données utilisateur
Le tableau suivant vous montre les différentes liaisons de la communication Secure Open
User Communication ainsi que les types de données système et les instructions
correspondants.
Liaison Secure OUC Type de données sys- Instructions

tème
Liaison TCP sécurisée d'une CPU • TCON_QDN_SEC • TSEND_C/TRCV_C
S7-1500 comme client TLS à un
API tiers (serveur TLS) • TCON, TSEND/TRCV
Liaison TCP sécurisée d'une CPU
S7-1500 comme serveur TLS à un
API tiers (client TLS)
Liaison TCP sécurisée entre deux • TCON_IP_V4_SEC1
stations S7-1500
Liaison sécurisée à un serveur de • TMAIL_V4_SEC • TMAIL_C (à partir de V5.0)
messagerie2
• TMAIL_QDN_SEC
Liaison Modbus TCP sécurisée • TCON_IP_V4_SEC1 • MB_Client
• TCON_QDN_SEC • MB_Server
1 Également possible via le CP 1543-1

2 Liaison sécurisée à un serveur de messagerie également possible avec le CP1543-1 et TMAIL_C
(V4.0)
Communication
Création de la liaison par configuration de liaison

Lors de la création par configuration de liaison, les paramètres d'adresse de la liaison sont
définis dans l'éditeur de matériel et de réseaux de STEP 7.
Pour l'envoi et la réception des données, vous utilisez les mêmes instructions que lors de la
création programmée de liaisons :
Tableau 6- 4 Instructions d'envoi/de réception pour les liaisons configurées
Protocole Envoi/réception pour les liaisons configurées

Instructions utilisables :
TCP Envoyer/recevoir des données par :
ISO-on-TCP • TSEND_C/TRCV_C ou
ISO conformément à ISO/CEI 8073 • TSEND/TRCV ou
(Class 4)
• TUSEND/TURCV
UDP Envoyer/recevoir des données par :
• TUSEND/TURCV
FDL Envoyer/recevoir des données par :
• TSEND/TRCV ou
• TUSEND/TURCV
Modbus TCP Non pris en charge
E-mail Non pris en charge
FTP Non pris en charge
Autres instructions pour la communication ouverte

Vous pouvez utiliser les instructions suivantes aussi bien pour les liaisons créées dans le
programme utilisateur que pour les liaisons configurées :
• T_RESET : suspendre et établir une liaison
• T_DIAG : vérifier une liaison
Exemples de base pour Open User Communication

Le support en ligne de Siemens vous offre des blocs fonctionnels (FB) qui vous facilitent la
manipulation des instructions Open User Communication. Vous trouverez les blocs
fonctionnels avec les exemples correspondants sur Internet
Communication
6.4 Open User Communication avec adressage par le nom de domaine

Vous trouverez dans l'aide en ligne de STEP 7 la description :
• des types de données utilisateur et système
• des instructions pour la communication ouverte
• des paramètres de liaison
Les informations concernant l'affectation et la libération de ressources de liaison sont
données au chapitre Affectation de ressources de liaison (Page 1).
Voir aussi
Secure Open User Communication (Page 1)
6.4 Open User Communication avec adressage par le nom de

domaine
Les CPU S7-1500, ET 200SP et les CPU 1513/1516pro-2 PN prennent en charge, à partir de la
version V2.0 de leur firmware, la communication Open User avec adressage par un système
de noms de domaine (DNS). Un client DNS est intégré dans la CPU. En communication par
DNS, vous adressez les partenaires avec des noms de domaine comme alias pour les adresses
IP. L'adressage des partenaires par nom de domaine est possible par TCP et par UDP pour la
communication ouverte.
Votre réseau doit contenir un serveur DNS au moins pour permettre la communication par
DNS.
Le contrôleur logiciel S7-1500 prend en charge la communication par DNS pour toutes les
interfaces qui lui sont affectées.
Communication
Configurer la communication par DNS

Pour qu'une CPU puisse établir une liaison à un partenaire de communication au moyen du
nom de domaine de ce dernier, il faut que le client DNS de la CPU connaisse l'adresse IPv4
d'au moins un serveur DNS. La CPU prend en charge jusqu'à 4 serveurs DNS différents.
Procédez comme suit pour configurer la communication par nom de domaine pour une CPU
S7-1500 :
1. Sélectionnez la CPU dans la vue de réseaux de STEP 7.
2. Dans la fenêtre d'inspection, sélectionnez "Propriétés" > "Général" > "Configuration avancée"
> "Configuration DNS".
3. Dans la colonne "Adresses de serveur DNS" du tableau "Liste de serveurs", tapez l'adresse
IPv4 d'un serveur DNS.
Vous pouvez écrire jusqu'à 4 adresses IPv4 de serveurs DNS.
Figure 6-1 Saisie d'adresses de serveurs DNS en prenant pour exemple une CPU 1516-3 PN/DP
Communication
Configurer une liaison TCP au moyen du nom de domaine du partenaire de communication

Pour la communication TCP par nom de domaine, vous devez élaborer vous-même un bloc de
données du type de données système TCON_QDN, le paramétrer et l'appeler directement
dans l'instruction. Les instructions TCON, TSEND_C et TRCV_C prennent en charge le type de
données système TCON_QDN.
Pour configurer une liaison TCP par le nom de domaine du partenaire de communication,
2. Définissez une variable de type TCON_QDN dans ce bloc de données global.
définie la variable "DNS Connection1" du type de données TCON_QDN.
Figure 6-2 Type de données TCON_QDN
3. Programmez les paramètres de la liaison TCP (par ex. le nom de domaine complet (FQDN))
dans la variable de type TCON_QDN.
4. Créez une instruction TCON dans l'éditeur de programme.
5. Interconnectez le paramètre CONNECT de l'instruction TCON avec la variable de type de
données TCON_QDN.
avec la variable "DNS connection1" (type de données TCON_QDN).
Communication
6.5 Configurer Open User Communication par TCP, ISO-on-TCP, UDP et ISO
Adresser une liaison UDP par le nom de domaine du partenaire de communication

Lorsque vous envoyez des données par UDP, vous pouvez adresser le destinataire par son
nom de domaine complet (FQDN) pour les CPU S7-1500 à partir de la version V2.0 du
firmware. Référencez pour cela dans l'instruction TUSEND au paramètre ADDR une structure
de type TADDR_SEND_QDN.
Le destinataire peut retourner une adresse IPv4 ou IPv6. Référencez donc dans l'instruction
TURCV au paramètre ADDR une structure de type TADDR_RCV_IP. C'est la seule pouvant
accepter les deux types d'adresse IP.
Remarque
Charge du réseau
Contrairement à TCP, le protocole UDP n'est pas orienté liaison. À chaque front au niveau du
paramètre de bloc REQ, l'instruction TUSEND ou TURCV interroge le serveur DNS. Cela peut
entraîner une charge élevée du réseau ou une charge sur le serveur DNS.

Pour plus d'informations sur les types de données système TCON_QDN, TADDR_SEND_QDN et
TADDR_RCV_IP, voir l'aide en ligne de STEP 7.
Pour configurer une liaison TCP sécurisée au moyen du nom de domaine du partenaire de
communication, voir chapitre Secure Open User Communication (Page 1).
6.5 Configurer Open User Communication par TCP, ISO-on-TCP, UDP

et ISO
Paramétrer une liaison pour les instructions TSEND_C, TRCV_C ou TCON

Condition : une instruction TSEND_C, TRCV_C ou TCON est créée dans l'éditeur de
programmation.
1. Dans l'éditeur de programmation, sélectionnez un bloc Open User Communication TCON,
TSEND_C ou TRCV_C.
2. Dans la fenêtre d'inspection, ouvrez l'onglet "Propriétés > Configuration".
Communication
3. Sélectionnez le groupe "Paramètres de la liaison". Tant que le partenaire de liaison n'est pas
choisi, seule la liste déroulante vide pour le nœud d'extrémité partenaire est active. Toutes
les autres possibilités de saisie sont désactivées.
Les paramètres de liaison déjà connus sont affichés :
– Nom du nœud d'extrémité local
– Interface du nœud d'extrémité local
– Adresse IPv4 du nœud d'extrémité local
Figure 6-4 Paramétrage de liaison pour TSEND_C
Communication
4. Choisissez un partenaire de liaison dans la liste déroulante du nœud d'extrémité partenaire.

Il peut s'agir d'un appareil non spécifié ou d'une CPU du projet. Certains paramètres de
liaison sont ensuite inscrits automatiquement comme valeurs par défaut.
Les paramètres suivants sont configurés :
– Nom du nœud d'extrémité partenaire
– Interface du nœud d'extrémité partenaire
– Adresse IPv4 du nœud d'extrémité partenaire
Si les partenaires de liaison sont en réseau, le nom du sous-réseau est affiché.
5. Optez, dans la liste déroulante "Type de configuration", pour l'utilisation de blocs de
programme ou de liaisons configurées.
Communication
6. Dans la liste déroulante "Données de liaison", sélectionnez un DB de description de liaison

existant ou, dans le cas de liaisons configurées, une liaison existante, sous "Nom de liaison".
Vous pouvez aussi créer un nouveau DB de description de liaison ou une nouvelle liaison
configurée. Vous pouvez choisir ultérieurement d'autres DB de description de liaison ou
liaisons configurées ou modifier les noms des DB de description de liaison pour créer de
nouveaux blocs de données :
– Vous voyez également le bloc de données sélectionné au paramètre d'entrée CONNECT
de l'instruction TCON, TSEND_C ou TRCV_C.
– Si vous avez déjà saisi un DB de description de liaison pour le partenaire de liaison au
moyen du paramètre CONNECT de l'instruction TCON, TSEND_C ou TRCV_C, vous
pouvez utilisez ce DB ou en créer un nouveau.
– Si vous éditez le nom du bloc de données affiché dans la liste déroulante, un nouveau
bloc de données portant le nom modifié est créé automatiquement. Sa structure et son
contenu sont identiques à l'ancien et il est utilisé pour la liaison.
– Les noms modifiés d'un bloc de données doivent être univoques dans le contexte du
partenaire de communication.
– Selon le type de CPU et la liaison, un DB de description de liaison doit avoir la structure
TCON_Param, TCON_IP_v4 ou TCON_IP_RFC.
– Un bloc de données ne peut pas être sélectionné pour un partenaire non spécifié.
Une fois que le DB de description de liaison ou la liaison configurée a été sélectionné ou
créé, d'autres valeurs sont déterminées et entrées.
Pour les partenaires de liaison spécifiés :
– Type de liaison ISO-on-TCP
– ID de liaison avec valeur par défaut 1
– Initialisation de la liaison par le partenaire local
– TSAP-ID
pour S7-1200/1500 : E0.01.49.53.4F.6F.6E.54.43.50.2D.31
Pour les partenaires de liaison non spécifiés :
– Type de liaison TCP
– Port partenaire 2000
Pour une liaison configurée avec un partenaire de liaison spécifié :
– ID de liaison avec valeur par défaut 257
– Initialisation de la liaison par le partenaire local
– Port partenaire 2000
Pour une liaison configurée avec un partenaire de liaison non spécifié :
– Port local 2000
Communication
7. Le cas échéant, entrez une ID de liaison pour le partenaire. Il est impossible d'attribuer une
ID de liaison pour un partenaire non spécifié.
Remarque
Dans le cas d'un partenaire de liaison connu, vous devez entrer une valeur univoque pour
l'ID de liaison. L'unicité de l'ID de liaison n'est pas vérifiée par le paramétrage des liaisons
et aucune valeur par défaut n'est entrée pour l'ID de liaison à la création d'une nouvelle
liaison.
8. Sélectionnez le type de liaison souhaité dans la liste déroulante. Les détails d'adresse sont
définis par défaut en fonction du type de liaison. Vous avez le choix entre :
– TCP
– ISO-on-TCP
– UDP
– ISO (uniquement pour Type de configuration "Utiliser la liaison configurée")
Vous pouvez éditer les champs de saisie dans les détails de l'adresse. En fonction du
protocole paramétré, vous pouvez éditer les ports (pour TCP et UDP) ou les TSAP (pour
ISO-on-TCP et ISO).
9. Pour TCP, ISO et ISO-on-TCP, configurez le comportement pour l'établissement de la liaison
avec les cases d'option "Initialisation de la liaison". Vous pouvez choisir le partenaire de
communication initialisant la liaison.
Les valeurs modifiées sont contrôlées immédiatement par le paramétrage de liaison pour
vérifier qu'il n'y a pas d'erreur de saisie et sont transmises dans le bloc de données pour la
description de la liaison.
Remarque
L'Open User Communication entre les deux partenaires de communication est opérationnelle
uniquement lorsque la partie de programme pour le nœud d'extrémité partenaire est chargée
dans le matériel. Pour que la communication soit opérationnelle, vous devez veiller non
seulement à charger la description de liaison de la CPU locale dans l'appareil, mais aussi celle
de la CPU partenaire.
Communication
Configurer des liaisons, par ex. pour TSEND/TRCV

Si vous souhaitez par exemple utiliser les instructions TSEND/TRCV pour la communication
ouverte, vous devez d'abord configurer une liaison (par ex. liaison TCP).
Pour configurer une liaison TCP, procédez comme suit :
1. Configurez les partenaires de communication dans la vue de réseau de l'éditeur de matériel
et de réseaux de STEP 7.
2. Sélectionnez le bouton "Liaisons", puis le type de liaison "Liaison TCP" dans la liste
déroulante.
3. Reliez les partenaires de communication par un glisser-déposer (avec l'interface ou le nœud
d'extrémité local). Si aucun sous-réseau S7 correspondant n'existe, il sera créé
automatiquement.
Une autre solution consiste à créer une liaison à des partenaires non spécifiés.
4. Sélectionnez la liaison créée dans la vue de réseau.
5. Paramétrez le cas échéant les propriétés de la liaison dans la zone "Général", dans l'onglet
"Propriétés", par exemple le nom de la liaison et les interfaces des partenaires de
communication utilisées.
Pour les liaisons avec un partenaire non spécifié, paramétrez l'adresse du partenaire.
Dans la partie "ID locale", vous trouverez l'ID locale (référence de la liaison dans le
programme utilisateur).
6. Sélectionnez le dossier "Blocs de programme" pour l'une des deux CPU dans la navigation du
projet et ouvrez l'OB 1 dans le dossier par un double-clic. L'éditeur de programme s'ouvre.
7. Sélectionnez l'instruction souhaitée, par ex. TSEND, dans la Task Card "Instructions", dans la
zone "Communication", "Open User Communication", et faites-la glisser dans un réseau de
l'OB 1.
8. Affectez, au paramètre ID de l'instruction, l'ID locale de la liaison configurée devant être
utilisée pour la transmission des données.
9. Interconnectez le paramètre "DATA" à l'instruction TSEND avec les données utilisateur, par
ex. dans un bloc de données.
10.Chargez la configuration matérielle et le programme utilisateur dans la CPU.
Configurez la liaison dans la CPU partenaire avec l'instruction de réception TRCV selon la
marche à suivre décrite ci-dessus et chargez-la dans la CPU.
Communication
Particularité des liaisons ISO avec CP 1543-1

Si vous utilisez le type de liaison "Liaison ISO", vous devez cocher la case "Utiliser le protocole
ISO" dans les propriétés du CP pour que l'adressage par les adresses MAC fonctionne.
Figure 6-5 Choisir le protocole ISO CP 1543-1
Dans l'aide en ligne de STEP 7, vous trouverez la description :
Pour savoir comment les instructions TSEND_C et TRCV_C se comportent dans S7-1500, voir
cette FAQ (https://support.industry.siemens.com/cs/ww/fr/view/109479564).
Communication
6.6 Configuration de la communication via FDL
Conditions requises
• Logiciel de configuration : STEP 7 Professional V14
• Nœud d'extrémité de la liaison : CPU S7-1500 à partir de la version de firmware 2.0 avec le
module de communication CM 1542-5 avec version de firmware 2.0
Création d'une liaison FDL configurée

Procédez comme suit pour créer une liaison FDL configurée dans STEP 7 :
1. Insérez une instruction TSEND_C dans l'éditeur de programme.
2. Sélectionnez l'instruction TSEND_C et naviguez dans la fenêtre d'inspection jusqu'à
"Propriétés" > "Général" > "Paramètres de la liaison".
3. Sous "Nœud d'extrémité", sélectionnez le nœud d'extrémité du partenaire. Utilisez l'un des
deux nœuds d'extrémité partenaires suivants :
– CPU S7-1500 avec CM 1542-5
– Non spécifié
4. Sous "Mode de configuration", sélectionnez "Utiliser la liaison configurée".
5. Sous "Type de liaison", sélectionnez "FDL".
6. Sous "Interface", sélectionnez les interfaces suivantes :
– Local : interface PROFIBUS du CM 1542-5
– Partenaire spécifié : interface PROFIBUS du CM 1542-5
7. Sélectionnez le paramétrage <nouveau> pour les données de liaison.
Communication
La figure suivante montre une liaison FDL entièrement configurée dans STEP 7.
Figure 6-6 Configurer une liaison FDL
Création d'une liaison FDL dans le programme utilisateur

Pour la communication par FDL, vous devez créer vous-même le bloc de données de type de
données système TCON_FDL, le paramétrer et l'appeler directement dans l'instruction.
1. Créez un bloc de données global dans le navigateur du projet :
2. Définissez une variable de type de données TCON_FDL dans le bloc de données global.
L'exemple suivant montre le bloc de données global "FDL_connection" dans lequel est
définie la variable "FDL_connection" de type de données TCON_FDL.
Figure 6-7 Programmer une liaison FDL
Communication
3. Programmez les paramètres pour la liaison FDL (les adresses PROFIBUS, par exemple) dans la
variable de type de données TCON_FDL.
4. Insérez une instruction TCON dans l'éditeur de programme.
5. Interconnectez le paramètre CONNECT de l'instruction TCON avec la variable de type de
données TCON_FDL.
Dans l'exemple suivant, le paramètre CONNECT de l'instruction TCON est interconnecté à
la variable "FDL_Connection" (de type de données TCON_FDL).
Figure 6-8 Exemple : instruction TCON pour liaison FDL
Communication
6.7 Créer une communication via Modbus TCP
Créer une liaison dans le programme utilisateur pour Modbus TCP

Le paramétrage se fait dans l'éditeur de programme sur l'instruction "MB_CLIENT ou
MB_SERVER.
Marche à suivre pour créer la communication avec Modbus TCP

L'instruction MB_CLIENT communique en tant que client Modbus TCP via la liaison TCP. Avec
cette instruction, vous établissez une liaison entre le client et le serveur, vous envoyez des
requêtes Modbus au serveur et vous recevez les réponses Modbus correspondantes. Vous
commandez en outre la suspension de la liaison TCP avec cette instruction.
L'instruction MB_SERVER communique en tant que serveur Modbus TCP via une liaison TCP.
L'instruction traite les requêtes de liaison d'un client Modbus, reçoit et traite les requêtes
Modbus et envoie les messages de réponse. Vous pouvez en outre commander la suspension
de la liaison TCP.
Condition : le client peut accéder au serveur dans le réseau par communication IP.
1. Configurez un système d'automatisation S7-1500 avec CPU dans la vue de réseau de
l'éditeur de matériel et de réseaux de STEP 7.
2. Dans la navigation du projet, sélectionnez pour la CPU le dossier "Blocs de programmes" et
double-cliquez sur l'OB 1 dans le dossier pour l'ouvrir. L'éditeur de programme s'ouvre.
3. Sélectionnez dans la Task Card "Instructions", zone "Communication", "Autres",
"MODBUS TCP" l'instruction souhaitée, par ex. MB_CLIENT, et faites-la glisser dans un réseau
de l'OB 1.
Communication
4. Paramétrez l'instruction MB_CLIENT ou MB_SERVER. Ce faisant, respectez les règles

suivantes :
Une adresse IPv4 du serveur doit être spécifiée pour chaque liaison MB_CLIENT.
Chaque liaison MB_CLIENT ou MB_SERVER doit utiliser un DB d'instance univoque avec
l'une des structures de données TCON_IP_v4, TCON_QDN ou TCON_Configured.
Chaque liaison nécessite une ID de liaison univoque. L'ID de liaison et le DB d'instance
forment un couple et doivent être univoques pour chaque liaison.
Figure 6-9 MB_CLIENT
Figure 6-10 MB_SERVER
5. Chargez la configuration matérielle et le programme utilisateur dans la CPU.
Communication
Communication redondante via Modbus TCP

Vous paramétrez une communication redondante via Modbus TCP avec les instructions
MB_RED_CLIENT ou MB_RED_SERVER :
Instruction MB_RED_CLIENT : L'instruction "MB_RED_CLIENT" vous permet d'établir une liaison
redondante entre le client et le serveur, d'envoyer des requêtes Modbus, de recevoir des
réponses et de piloter la déconnexion du client Modbus TCP.
Instruction MB_RED_SERVER : L'instruction "MB_RED_SERVER" traite les requêtes de liaison
d'un client Modbus TCP, reçoit et traite les requêtes Modbus et envoie des messages de
réponse. Les CPU sont en mesure :
• d'éditer plusieurs liaisons de serveur et
• d'accepter simultanément plusieurs liaisons de différents clients sur un port de serveur.
Pour plus d'informations sur les instructions MB_RED_CLIENT ou MB_RED_SERVER, voir l'aide
en ligne de STEP 7.
Serveur Modbus TCP comme passerelle vers Modbus RTU

Si vous utilisez un serveur Modbus TCP comme passerelle vers un protocole Modbus RTU,
vous adressez l'appareil esclave dans le réseau série avec le paramètre statique MB_UNIT_ID.
Le paramètre MB_UNIT_ID correspond au champ de l'adresse de l'esclave dans le protocole
Modbus RTU. Le paramètre MB_UNIT_ID transmet dans ce cas l'instruction à l'adresse correcte
de l'esclave Modbus RTU.
Vous devez programmer vous-même la fonction de passerelle.
Vous trouverez le paramètre MB_UNIT_ID dans le bloc de données d'instance appartenant à
l'instruction MB_CLIENT.
Pour plus d'informations sur le paramètre MB_UNIT_ID, référez-vous à l'aide en ligne de
STEP 7.
Voir aussi
• Pour apprendre à programmer et paramétrer la communication Modbus TCP entre deux
CPU S7-1500, voir cette FAQ
• Vous apprendrez comment programmer et paramétrer une communication Modbus TCP
entre une CPU S7-1500 et une CPU S7-1200, dans cette FAQ
Communication
6.8 Configurer la communication par e-mail
6.8 Configurer la communication par e-mail
Configurer une liaison avec le programme utilisateur pour e-mail

Pour la communication par e-mail, vous devez créer vous-même le bloc de données du type
de données système correspondant, le paramétrer et l'appeler directement dans l'instruction.
La marche à suivre est décrite ci-après.
Marche à suivre pour configurer la communication par e-mail

Les e-mails peuvent être envoyés par une CPU. Pour envoyer des e-mails à partir du
programme utilisateur de la CPU, utilisez l'instruction TMAIL_C.
Condition : le serveur SMTP est accessible via le réseau IPv4.
1. Configurez un système d'automatisation S7-1500 avec CPU dans la vue de réseau de
l'éditeur de matériel et de réseaux de STEP 7.
2. Paramétrez l'instruction TMAIL_C, entrez par exemple l'objet du mail pour Subject.
3. Créez dans un bloc de données global une variable du type TMAIL_v4, TMAIL_v6
(uniquement CP 1543-1) ou TMAIL_FQDN (uniquement CP 1543-1).
4. Définissez dans la variable les paramètres de la liaison TCP dans la colonne "Valeur initiale".
Tapez par ex. l'adresse Ipv4 du serveur de messagerie sous "MailServerAdress" (pour
TMAIL_v4).
Remarque
Notez qu'à partir de la version V5.0 de l'instruction TMAIL_C, vous pouvez entrer dans le
type de données TMAIL_V4_SEC la valeur "0" pour l'ID d'interface. Dans ce cas, la CPU
recherche elle-même une interface locale appropriée de la CPU.
Interconnectez la variable avec le paramètre MAIL_ADDR_PARAM de l'instruction TMAIL_C.

• des types de données système
Communication
6.9 Configurer la communication FTP
Configurer une liaison avec le programme utilisateur pour FTP

Pour la communication par FTP, vous devez créer vous-même le bloc de données du type de
données système correspondant, le paramétrer et l'appeler directement dans l'instruction. La
marche à suivre est décrite ci-après.
Fonctionnalité client et serveur FTP

Des fichiers peuvent être envoyés par une CPU à un serveur FTP et être reçues par ce dernier.
La communication par FTP n'est possible pour S7-1500 qu'avec un CP 1543-1. Le CP peut être
un serveur FTP, un client FTP ou les deux. Les clients FTP peuvent également être des
systèmes/PC d'autres marques.
Pour la fonctionnalité de serveur FTP, vous configurez le CP de manière appropriée dans
STEP 7.
La fonctionnalité de client FTP vous permet, par exemple, d'établir et de couper une liaison
FTP ainsi que de transmettre et de supprimer des fichiers sur le serveur. Pour la fonctionnalité
de client FTP, utilisez l'instruction FTP_CMD.
Communication
Marche à suivre pour configurer la fonctionnalité de serveur FTP

Condition : le serveur FTP est accessible via le réseau IPv4.
1. Configurez un système d'automatisation S7-1500 avec CPU et CP 1543-1 dans la vue des
appareils de l'éditeur de matériel et de réseaux de STEP 7.
Vous devez en outre activer l'option "Autoriser accès via communication PUT/GET par le
partenaire à distance (API, IHM, OPC, ...)" dans la configuration matérielle de la CPU S7-
1500, dans la zone "Mécanismes de connexion" sous "Protection".
2. Effectuez les paramétrages suivants dans les propriétés du CP sous "Configuration FTP" :
– Cochez la case "Utiliser un serveur FTP pour les données de CPU S7".
– Affectez à la CPU un bloc de données et un nom de fichier sous lequel le DB est
enregistré pour FTP.
Figure 6-11 Créer une configuration FTP
3. Chargez la configuration matérielle dans la CPU.
Communication
Marche à suivre pour configurer la fonctionnalité de client FTP

Condition : le serveur FTP est accessible via le réseau IPv4.
1. Configurez un système d'automatisation S7-1500 avec CPU et CP 1543-1 dans la vue des
appareils de l'éditeur de matériel et de réseaux de STEP 7.
Vous devez en outre cocher la case "Autoriser accès par communication PUT/GET du
partenaire à distance (AP, IHM, OPC, ...)" dans la configuration matérielle de la
CPU S7-1500, dans la zone "Mécanismes de connexion" sous "Protection".
2. Appelez l'instruction FTP_CMD dans le programme utilisateur de la CPU.
3. Configurez les paramètres de la liaison pour le serveur FTP dans l'instruction FTP_CMD.
4. Créez un DB global et, à l'intérieur de ce DB global, une variable de type FTP_CONNECT_IPV4,
FTP_CONNECT_IPV6 ou FTP_CONNECT_NAME.
5. Connectez la variable dans le bloc de données à l'instruction FTP_CMD.
6. Pour la liaison au serveur FTP, indiquez dans le DB :
– le nom d'utilisateur, le mot de passe et l'adresse IP pour l'accès FTP dans le type de
données correspondant (FTP_CONNECT_IPV4, FTP_CONNECT_IPV6 ou
FTP_CONNECT_NAME)
Exemples d'application
• Exemple d'application : communication FTP avec S7-1500 et CP 1543-1
L'exemple d'application se trouve sur Internet
• Exemple d'application : communication client FTP avec S7-1200/1500
L'exemple d'application se trouve sur Internet
• des types de données système
Communication
6.10 Etablissement et interruption de liaisons de communication
6.10 Etablissement et interruption de liaisons de communication
Etablissement et interruption de liaisons de communication

Le tableau suivant présente l'établissement et l'interruption de liaisons de communication
dans le cadre de la communication ouverte.
Tableau 6- 5 Etablissement et interruption de liaisons de communication
Etablissement de la liaison Etablissement de la liaison de communica- Interruption de la liaison de communica-

tion tion
Via le programme utilisa- Après le chargement du programme utilisa- • Via les instructions TSEND_C/TRCV_C,
teur teur dans les CPU :
TDISCON et T_RESET
Le partenaire de communication passif éta-
blit l'accès de liaison local en appelant • Si la CPU passe du mode de fonctionne-
TSEND_C/TRCV_C ou TCON. L'appel de ment RUN à STOP
TSEND_C/TRCV_C ou TCON dans le partenaire • En cas de mise hors tension/sous tension
actif déclenche l'établissement de la liaison.
Si la liaison a pu être établie, un message en d'une CPU
retour positif est émis dans les instructions
du programme utilisateur.
Après que vous avez coupé une liaison avec
l'instruction T_RESET, la liaison est à nouveau
rétablie.
En cas d'interruption de la liaison, le parte-
naire actif tente de rétablir la liaison créée.
Ce n'est toutefois le cas que si la liaison avait
auparavant pu être établie avec TCON.
Via la configuration de la Après le chargement de la configuration de la En supprimant la configuration de la liaison
liaison liaison et du programme utilisateur dans les dans STEP 7 et en chargeant la configuration
CPU. modifiée dans la CPU.
Communication
Communication S7 7
Caractéristiques de la communication S7
La communication S7 en tant que communication homogène SIMATIC se caractérise par une
communication spécifique au fabricant entre CPU SIMATIC (pas de norme ouverte). La
communication S7 sert à la migration et au raccordement à des systèmes existants (S7-300,
S7-400).
Nous vous recommandons d'utiliser la communication ouverte pour la transmission de
données entre deux systèmes d'automatisation S7-1500 (voir le chapitre Open User
Communication (Page 1)).
Propriétés de la communication S7
La communication S7 permet à la CPU d'échanger des données avec une autre CPU. Dès que
l'utilisateur a reçu les données du côté de la réception, la réception des données est acquittée
automatiquement et communiquée à la CPU émettrice.
L'échange de données s'effectue par des liaisons S7 configurées. Les liaisons S7 peuvent être
configurées à sens unique ou à deux sens.
La communication S7 est possible via :
• Interface PROFINET ou PROFIBUS DP intégrée d'une CPU
• Interface d'un CP/CM
Liaisons S7 configurées à sens unique

Une liaison S7 à sens unique est configurée dans un partenaire de communication
uniquement et est également chargée dans ce seul partenaire.
Une liaison S7 à sens unique peut être configurée vers une CPU qui est uniquement serveur
d'une liaison S7 (p. ex. CPU 315-2 DP). La CPU est configurée et les paramètres d'adresse et
interfaces sont donc connus.
En outre, il est possible de configurer une liaison S7 à sens unique vers un partenaire ne se
trouvant pas dans le projet et dont les paramètres d'adresse et interfaces ne sont donc pas
connus. Vous devez saisir l'adresse ; celle-ci n'est pas contrôlée par STEP 7. Le partenaire n'est
pas spécifié initialement (aucune adresse de partenaire n'est encore saisie lors de la création
de la liaison S7). Dès que vous entrez l'adresse, il devient "inconnu" (c'est-à-dire : il est
spécifié, mais inconnu dans le projet).
Il est possible, dans ce cas, d'utiliser des liaisons S7 au-delà des limites du projet. Le
partenaire de communication est inconnu pour le projet local (non spécifié) et est configuré
dans un autre projet STEP 7 ou dans un projet extérieur.
Communication
Communication S7
Liaisons S7 configurées à deux sens

Dans le cas d'une liaison S7 à deux sens, la configuration et le chargement des paramètres de
liaison S7 configurés se font dans les deux partenaires de communication.
Instructions pour la communication S7

Les instructions suivantes sont utilisables pour la communication S7 dans S7-1500 :
• PUT/GET
L'instruction PUT vous permet d'écrire des données dans une CPU distante. L'instruction
GET vous permet de lire des données dans une CPU distante. Les instructions PUT et GET
sont des instructions à sens unique, c'est-à-dire qu'une instruction n'est nécessaire que
dans un seul partenaire de communication. Vous pouvez configurer les instructions PUT et
GET confortablement dans le paramétrage de liaison.
Remarque
Blocs de données pour instructions PUT/GET
Pour l'emploi des instructions PUT/GET, vous pouvez utiliser uniquement des blocs de
données avec adressage absolu. L'adressage symbolique des blocs de données n'est pas
possible.
Vous devez en outre valider ce service dans la zone "Protection" de la configuration de la
CPU.
Pour configurer et programmer une liaison S7 et les instructions de communication PUT et

GET pour l'échange de données entre deux CPU S7-1500, voir cette FAQ
• BSEND/BRCV
L'instruction BSEND envoie des données à une instruction partenaire distante du type
BRCV. L'instruction BRCV reçoit des données d'une instruction partenaire distante de type
BSEND. La communication S7 avec le couple d'instructions BSEND/BRCV sert au transfert
sécurisé de données.
• USEND/URCV
L'instruction USEND envoie des données à une instruction partenaire distante du type
URCV. L'instruction URCV reçoit des données d'une instruction partenaire distante du type
USEND. La communication S7 avec le couple d'instructions USEND/URCV sert au transfert
rapide et non sécurisé de données, indépendamment du traitement temporel du
partenaire de communication ; par ex. pour les messages d'exploitation et de
maintenance.
Communication
Communication S7
Communication S7 par l'interface PROFIBUS DP en mode esclave

Dans STEP 7, dans les propriétés de l'interface PROFIBUS DP de modules de communication
(p. ex. CM 1542-5), vous trouverez la case d'option "Test, mise en service et routage". Activez
ou désactivez cette case, si l'interface PROFIBUS DP de l'esclave DP est un abonné actif ou
passif sur PROFIBUS.
• Case activée : l'esclave DP est un abonné actif sur PROFIBUS.
• Case désactivée : l'esclave DP est un abonné passif sur PROFIBUS. Vous pouvez
uniquement établir des liaisons S7 à sens unique vers cet esclave DP.
Figure 7-1 Case d'option "Test, mise en service et routage"
Paramétrer des liaisons S7 pour des instructions PUT/GET

Vous pouvez créer et paramétrer des liaisons S7 dans le paramétrage de liaison des
instructions PUT/GET. Les valeurs modifiées sont immédiatement contrôlées par le
paramétrage de liaison pour détecter les erreurs de saisie.
Condition : une instruction PUT/GET est créée dans l'éditeur de programmation.
Pour configurer une liaison S7 via des instructions PUT/GET, procédez comme suit :
1. Sélectionnez l'appel de l'instruction PUT ou GET dans l'éditeur de programmation.
2. Dans la fenêtre d'inspection, ouvrez l'onglet "Propriétés > Configuration".
Communication
Communication S7
3. Sélectionnez le groupe "Paramètres de la liaison". Tant que le partenaire de liaison n'est pas
choisi, seule la liste déroulante vide pour le nœud d'extrémité partenaire est active. Toutes
les autres possibilités de saisie sont désactivées.
Les paramètres de liaison déjà connus sont affichés :
– Nom du nœud d'extrémité local
– Interface du nœud d'extrémité local
– Adresse IPv4 du nœud d'extrémité local
Figure 7-2 Paramétrage de liaison pour l'instruction PUT
Communication
Communication S7
4. Choisissez un partenaire de liaison dans la liste déroulante du nœud d'extrémité partenaire.

Il peut s'agir d'un appareil non spécifié ou d'une CPU du projet.
Les paramètres suivants sont automatiquement entrés dès que vous sélectionnez un
partenaire de liaison :
– Nom du nœud d'extrémité partenaire
– Interface du nœud d'extrémité partenaire. Si plusieurs interfaces sont disponibles, vous
pouvez le cas échéant modifier l'interface.
– Type d'interface du nœud d'extrémité partenaire
– Nom de sous-réseau des deux nœuds d'extrémité
– Adresse IPv4 du nœud d'extrémité partenaire
– Nom de la liaison utilisée pour la communication.
5. Modifiez le cas échéant le nom de la liaison dans le champ de saisie "Nom de liaison". Pour
élaborer une nouvelle liaison ou éditer une liaison existante, cliquez sur le bouton
"Sélectionner une liaison" à droite du champ de saisie du nom de liaison.
Remarque
Les instructions PUT et GET sont uniquement exécutables entre deux partenaires de
communication si la configuration matérielle ainsi que la partie du programme pour le
nœud d'extrémité partenaire ont été chargées dans le matériel. Pour que la
communication soit opérationnelle, vous devez veiller non seulement à charger la
description de liaison de la CPU locale dans l'appareil, mais aussi celle de la CPU
partenaire.
Configurer des liaisons S7 par ex. pour BSEND/BRCV

Si vous souhaitez par exemple utiliser les instructions BSEND/BRCV pour la communication S7,
vous devez d'abord configurer une liaison S7.
Pour configurer une liaison S7, procédez comme suit :
2. Sélectionnez le bouton "Liaisons", puis l'entrée "Liaison S7" dans la liste déroulante.
3. Reliez les partenaires de communication par un glisser-déposer (avec l'interface ou le nœud
d'extrémité local). Si aucun sous-réseau S7 correspondant n'existe, il sera créé
automatiquement.
Ou bien vous pouvez également créer une liaison à des partenaires non spécifiés.
4. Dans l'onglet "Liaisons", sélectionnez la ligne de la liaison S7.
5. Dans la zone "Général", puis dans l'onglet "Propriétés", le cas échéant dans les propriétés de
la liaison S7, définissez par ex. le nom de la liaison et les interfaces utilisées du partenaire de
communication.
Pour les liaisons S7 avec un partenaire non spécifié, paramétrez l'adresse du partenaire.
Dans la partie "ID locale", vous trouverez l'ID locale (référence de la liaison S7 dans le
programme utilisateur).
Communication
Communication S7
6. Sélectionnez le dossier "Blocs de programme" pour l'une des deux CPU dans la navigation du
projet et ouvrez l'OB 1 dans le dossier par un double-clic. L'éditeur de programme s'ouvre.
7. Dans l'éditeur de programme, appelez les instructions correspondantes pour la
communication S7 dans le programme utilisateur du partenaire de communication (à sens
unique) ou dans les programmes utilisateur des partenaires de communication (à deux
sens). Par exemple, sélectionnez dans la Task Card "Instructions", dans la zone
"Communication", les instructions BSEND et BRCV et faites-les glisser dans un réseau de
l'OB 1.
8. Affectez, au paramètre ID de l'instruction, l'ID locale de la liaison configurée devant être
utilisée pour la transmission des données.
9. Paramétrez les instructions en indiquant où les données doivent être écrites et où elles
doivent être lues.
10.Chargez la configuration matérielle et le programme utilisateur dans la(les) CPU(s).
Communication S7 via CP 1543-1

Si vous configurez la communication S7 via l'interface Industrial Ethernet du CP 1543-1, vous
pouvez sélectionner le protocole de transport pour la transmission de données dans les
propriétés de la liaison S7, sous "Général" :
• Case "TCP/IP" cochée (par défaut) : ISO-on-TCP (RFC 1006) : pour la communication S7
entre CPU S7-1500
• Case "TCP/IP" désactivée : Protocole ISO (ISO/IEC 8073) : adressage par adresses MAC
Figure 7-3 Sélection du protocole de transport CP 1543-1
Communication
Communication S7
Marche à suivre pour la création d'une liaison S7 via différents sous-réseaux S7

Vous avez la possibilité d'utiliser une liaison S7 via plusieurs sous-réseaux S7 (PROFIBUS,
PROFINET/Industrial Ethernet) (routage S7 (Page 1)).
2. Sélectionnez le bouton "Mise en réseau".
3. Reliez les interfaces appropriées aux sous-réseaux S7 concernés (PROFIBUS ou PROFINET /
Industrial Ethernet) par glisser-déposer.
4. Sélectionnez le bouton "Liaisons", puis l'entrée "Liaison S7" dans la liste déroulante.
5. Dans notre exemple, reliez l'AP_1 du sous-réseau S7 de gauche (PROFIBUS) à l'AP_3 du sous-
réseau S7 de droite (PROFINET) par glisser-déposer.
La liaison S7 de la CPU 1 à la CPU 3 est maintenant configurée.
Figure 7-4 Liaisons S7 via différents sous-réseaux
Communication
Communication S7
ET 200SP Open Controller comme routeur pour liaisons S7

Quand vous affectez l'interface "PROFINET onboard [X2]" de la CPU 1515SP PC (F) à la station
SIMATIC PC, la CPU 1515SP PC (F) peut être utilisée comme routeur pour liaisons S7. Quand
vous utilisez l'interface CP pour "Aucun ou un autre paramètre Windows", vous ne pouvez pas
utiliser l'Open Controller comme routeur pour liaisons S7 par routeur.
Une liaison S7 existante utilisant la CPU 1515SP PC (F) comme routeur devient invalide quand
l'affectation de l'interface de la CPU 1515SP PC (F) est modifiée de "Station SIMATIC PC" en
"Aucun ou un autre paramètre Windows". Comme l'AP ne se charge plus du routage pour
cette liaison, la liaison invalide ne vous est pas signalée lors de la compilation de la CPU
1515SP PC (F) . La liaison S7 au routage invalide ne vous sera signalée que lors de la
compilation de ses nœuds d'extrémité.
Les interfaces nécessaires aux liaisons S7 par routeur doivent rester affectées explicitement
dans la CPU 1515SP PC (F) . Vous pouvez éditer l'affectation de l'interface de la CPU 1515SP
PC (F) dans les propriétés, sous "PROFINET onboard [X2] > Affectation d'interface".
Figure 7-5 Routage S7 avec station PC
Des informations détaillées sur la configuration de liaisons S7 et sur l'utilisation d'instructions
pour la communication S7 dans le programme utilisateur sont disponibles dans l'aide en ligne
de STEP 7.
Communication
Couplage point à point 8
Fonctionnalité
La communication par couplage point à point pour S7-1500, ET 200MP et ET 200SP s'effectue
par l'intermédiaire de modules de communication (CM) avec interfaces série (RS232, RS422
ou RS485).
• S7-1500/ET 200MP :
– CM PtP RS232 BA
– CM PtP RS422/485 BA
– CM PtP RS232 HF
– CM PtP RS422/485 HF
• ET 200SP :
– CM PtP
L'échange de données bidirectionnel par couplage point à point fonctionne entre modules de
communication ou bien entre systèmes ou appareils de communication non Siemens. Il faut
au moins 2 partenaires de communication pour la communication ("point à point"). Pour
RS422 et RS485, il est possible d'avoir plus de deux partenaires de communication.
Protocoles pour la communication par couplage point-à-point

• Protocole Freeport (également appelé protocole ASCII)
• Procédure 3964(R)
• Protocole Modbus au format RTU (RTU : Remote Terminal Unit)
• Protocole USS (Universal Serial Interface Protocol)
Les protocoles utilisent différentes couches conformément au modèle de référence ISO/OSI :
• Freeport : utilise la couche 1 (couche physique)
• 3964(R), USS et Modbus : utilisent les couches 1 et 2 (couche physique et couche liaison
de données ; sécurité de transmission accrue par rapport à Freeport). USS et Modbus
utilisent en plus la couche 4.
Propriétés du protocole Freeport

• Le destinataire identifie la fin de la transmission des données à l'aide d'un critère de fin
paramétrable (par ex. écoulement du délai inter-caractère, réception du caractère de fin,
réception du nombre fixe de données).
• L'émetteur ne peut pas déterminer si les données envoyées ont été reçues sans erreur au
niveau du destinataire.
Communication
Couplage point à point
Propriétés de la procédure 3964(R)

• Lors de l'envoi, des caractères de contrôle sont ajoutés aux données (caractère de début,
caractère de fin et caractère de contrôle de bloc). Vous devez veiller à ce que ces
caractères de commande ne figurent pas comme données dans le télégramme.
• L'établissement et la suppression de la liaison s'effectuent à l'aide de caractères de
contrôle.
• En cas d'erreurs de transmission, le transfert de données est automatiquement réitéré.
Echange de données par communication 3964(R) ou Freeport

Les données d'émission sont enregistrées dans le programme utilisateur de la CPU
correspondante dans des blocs de données (tampon d'émission). Pour les données de
réception, un tampon de réception est disponible dans le module de communication.
Contrôlez les propriétés du tampon de réception et adaptez-les le cas échéant. Vous devez
créer un bloc de données pour la réception dans la CPU.
Dans le programme utilisateur de la CPU, les instructions "Send_P2P" et "Receive_P2P"
prennent en charge le transfert de données entre la CPU et le CM.
Marche à suivre pour la création d'une communication 3964(R) ou Freeport

1. Dans la vue des appareils de l'éditeur de matériel et de réseaux de STEP 7, configurez une
structure S7-1500 avec CPU et CM.
2. Sélectionnez l'interface du CM dans la vue des appareils de STEP 7.
3. Paramétrez l'interface (par ex. communication de connexion, configuration de l'envoi de
messages) dans la fenêtre d'inspection de STEP 7 sous "Propriétés" >"Général".
4. Sélectionnez dans la Task Card "Instructions", sous "Communication" > "Processeur de
communication", les instructions "Send_P2P" ou "Receive_P2P" et amenez l'instruction dans
le programme utilisateur par glisser-déposer (par ex. dans un FB).
5. Paramétrez les instructions selon vos exigences.
Autre solution : paramétrage dynamique du module de communication

Dans certains domaines d'application, il est intéressant d'établir la communication de manière
dynamique, c'est-à-dire à l'aide d'une application spécifique commandée par programme.
On trouve ces cas d'application typiques chez les fabricants de machines de production par
exemple. Afin de proposer des interfaces utilisateur des plus conviviales à leurs clients, ces
fabricants adaptent le service de communication à chaque consigne d'exploitation.
Communication
Instructions pour la communication Freeport

Pour la communication Freeport, 3 instructions sont disponibles pour la configuration
dynamique dans le programme utilisateur. Ce qui suit s'applique pour les 3 instructions : les
données de configuration existantes sont remplacées, mais ne sont pas enregistrées
durablement dans le système cible.
• L'instruction "Port_Config" sert à la configuration commandée par programme du port
correspondant du module de communication.
• L'instruction "Send_Config" sert à la configuration dynamique d'intervalles par exemple de
temps et de pauses lors de la transmission (paramètres série de transmission) pour le port
concerné.
• L'instruction "Receive_Config" sert à la configuration dynamique de conditions de début et
de fin d'un message à transmettre (paramètre série de réception) pour le port concerné
par exemple.
Instructions pour la communication 3964(R)

Pour la communication 3964(R), 2 instructions sont disponibles pour la configuration
dynamique dans le programme utilisateur. Ce qui suit s'applique pour les instructions : les
données de configuration existantes sont remplacées, mais ne sont pas enregistrées
durablement dans le système cible.
• L'instruction "Port_Config" sert à la configuration commandée par programme du port
correspondant du module de communication.
• L'instruction "P3964_Config" sert à la configuration dynamique de paramètres de
protocole.
Propriétés du protocole USS

• Protocole simple et série de transmission de données avec échange de télégrammes
cyclique en mode semi-duplex, adapté aux exigences de la technique d'entraînement.
• La transmission de données fonctionne sur le principe maître-esclave.
– Le maître a accès aux fonctions de l'entraînement et peut, entre autres, commander
l'entraînement, lire les valeurs d'état, ainsi que lire et écrire les paramètres
d'entraînement.
Echange de données par communication USS

Le module de communication est le maître. Le maître émet successivement des télégrammes
(télégrammes de requête) vers les entraînements (16 au maximum) et attend un télégramme
de réponse de chaque entraînement adressé.
Un entraînement envoie un télégramme de réponse dans les conditions suivantes :
• lors de la réception sans erreur d'un télégramme
• Lorsque l'entraînement a été adressé dans ce télégramme
Un entraînement ne doit pas répondre quand ces conditions ne sont pas remplies ou quand
l'entraînement a été adressé en mode de diffusion générale.
Pour le maître, la liaison avec les entraînements concernés n'est établie que lorsqu'il reçoit un
télégramme de réponse de l'entraînement après une durée de traitement (temps de réponse)
définie.
Communication
Marche à suivre pour la configuration d'une communication USS

2. Dans la navigation du projet, sélectionnez pour la CPU le dossier "Blocs de programmes" et
3. Sélectionnez dans la Task Card "Instructions", puis dans la zone "Communication", dossier
"Processeur de communication", les instructions pour la communication USS en fonction de
vos exigences, puis faites-les glisser dans un réseau de l'OB 1 :
– L'instruction "USS_Port_Scan" permet d'utiliser la communication via le réseau USS.
– L'instruction "USS_Drive_Control" prépare des données d'émission pour l'entraînement
et évalue les données de réponse de l'entraînement.
– L'instruction "USS_Read_Param" sert à la lecture de paramètres provenant de
l'entraînement.
– L'instruction "USS_Write_Param" permet de modifier des paramètres dans
l'entraînement.
Propriétés du protocole Modbus (RTU)

• La communication s'effectue via des transmissions en série asynchrones à une vitesse
pouvant atteindre 115,2 kbit/s, en mode semi-duplex.
• La transmission de données fonctionne sur le principe maître-esclave.
• Le maître Modbus peut envoyer à l'esclave Modbus des requêtes pour l'écriture et la
lecture d'opérandes :
– Lecture d'entrées, de temporisations, de compteurs, de sorties, de mémentos et de
blocs de données
– Ecriture de sorties, de mémentos, de blocs de données
• La diffusion générale à tous les esclaves est possible.
Echange de données par communication Modbus (RTU)

Le module de communication peut être maître Modbus ou esclave Modbus. Un maître
Modbus peut communiquer avec un ou plusieurs esclaves Modbus (le nombre dépend de la
caractéristique physique de l'interface). Seul l'esclave Modbus explicitement adressé par le
maître Modbus est autorisé à renvoyer des données au maître Modbus. L'esclave détecte la
fin de la transmission de données et l'acquitte. En cas d'erreur, il fournit un code d'erreur au
maître.
Communication
Marche à suivre pour la configuration d'une communication Modbus (RTU)

2. Dans la navigation du projet, sélectionnez le dossier "Blocs de programmes" pour la CPU et
3. Sélectionnez dans la Task Card "Instructions", puis dans la zone "Communication", dossier
"Processeur de communication", les instructions pour la communication Modbus en fonction
de vos exigences, puis faites-les glisser dans un réseau de l'OB 1 :
– L'instruction "Modbus_Comm_Load" configure le port du CM pour la communication
Modbus.
– L'instruction "Modbus_Master" est utilisée pour la fonction de maître Modbus.
– L'instruction "Modbus_Slave" est utilisée pour la fonction d'esclave Modbus.
• Vous trouverez des informations complémentaires sur la communication par couplage
point à point et des notions de base sur la transmission de données série dans la
description fonctionnelle Module de communication CM PtP - Configurations pour
couplages point à point (http://support.automation.siemens.com/WW/view/fr/59057093).
• L'utilisation des instructions citées pour le couplage point à point dans le programme
utilisateur est expliquée dans l'aide en ligne de STEP 7.
• Les informations relatives aux modules de communication avec interface série se trouvent
dans le manuel du module de communication respectif.
Communication
Communication OPC UA 9
9.1 Informations utiles sur OPC UA
9.1.1 OPC UA et Industrie 4.0
Standard unique pour l'échange d'informations et de données

Industrie 4.0 garantit l'utilisation, l'évaluation et l'analyse intensives, dans des systèmes de TI
du niveau entreprise, des nombreuses données issues de la production. Avec Industrie 4.0,
l'échange de données entre les niveaux production et entreprise s'intensifie. La réussite de ce
développement est conditionnée à l'existence d'une norme homogène pour l'échange
d'informations et de données.
L'OPC classique s'exécute uniquement sous les systèmes d'exploitation Windows. C'est pour
contourner cette restriction que OPC Foundation a développé le standard OPC UA (OPC
Unified Architecture).
Le standard OPC UA convient particulièrement à l'échange de données entre niveaux en
raison de son indépendance par rapport aux systèmes d'exploitation, son mode de
transmission sécurisé et la description sémantique des données. Il permet ainsi également le
transfert de données machine (grandeurs de réglage, valeurs de mesure ou paramètres).
Dans le cadre de ce concept, il est essentiel, pour la transmission de données machine à
temps critique, que la communication OPC UA puisse se dérouler en parallèle à la
communication en temps réel.
OPC UA présente une grande capacité d'évolutivité de sorte qu'un échange d'informations
homogène entre capteurs, automates et systèmes MES ou ERP est possible.
OPC UA ne met pas seulement des données à disposition, mais aussi des informations sur les
données (par ex. types de données et types d'objet), ce qui permet un accès aux données
interprétables par machine.
Page thématique OPC UA

Vous trouverez une vue d'ensemble des contributions et liens les plus importants sur
"OPC UA" dans l'Siemens Industry Online Support.
Page thématique OPC UA (https://support.industry.siemens.com/cs/ww/fr/view/109770435)
Communication
Communication OPC UA
9.1.2 Caractéristiques générale d'OPC UA
OPC UA et PROFINET
OPC UA et PROFINET peuvent être utilisés ensemble. Les deux protocoles utilisent la même
infrastructure de réseau.
Indépendance par rapport au système d'exploitation

Le standard OPC UA ne dépend d'aucune plateforme et il utilise un protocole optimisé de
transmission de données binaires basé sur TCP pour des applications haute performance.
OPC UA peut être utilisé, par exemple, sous Windows, Linux, Mac OS X, un système
d'exploitation en temps réel ou un système d'exploitation mobile (Android ou iOS).
Indépendance par rapport à la couche transport

OPC UA prend actuellement en charge les mécanismes de transport et les protocoles
suivants :
• Transmission de messages comme suite binaire directement via TCP/IP.
• Transmission de messages avec XML via TCP/IP et HTTP. Ce mécanisme de transport
n'autorise qu'une transmission lente et n'est donc que très peu utilisé. Les CPU S7-1500 ne
prennent pas en charge ce mécanisme de transport.
Toute application OPC UA prend en charge l'échange de données binaire (prescrit par la
spécification OPC UA).
Simplicité du principe client-serveur

Un serveur OPC UA fournit un nombre considérable d'informations dans un réseau, par
exemple sur la CPU, sur le serveur OPC UA lui-même, sur les données et les types de données.
Un client OPC UA accède à ces informations.
Mise en application dans différents langages de programmation

OPC Foundation a implémenté le standard OPC UA dans plusieurs langages de
programmation : Des piles sont disponibles pour .NET, ANSI C et Java, la maintenance des
piles pour ANSI C et Java n'étant toutefois plus assurée.
OPC Foundation propose la pile .NET ainsi que des exemples de programme sous forme de
logiciel open source (code source ouvert). Voir Github (https://github.com/opcfoundation).
Plusieurs entreprises proposent des kits de développement logiciel SDK (Software
Development Kits). Ces kits de développement logiciel contiennent les piles de OPC
Foundation et d'autres fonctions facilitant le développement de solutions.
Avantages lors de l'utilisation de SDK :
• Assistance par le fournisseur
• Logiciels testés
• Documentation complète
• Clarté des conditions d'octroi de licence (important pour la revente des solutions)
Communication
Évolutivité
OPC UA peut être utilisé pour des appareils dans différentes classes de puissance :
• Capteurs
• Systèmes intégrés
• Automates
• Systèmes sur PC
• Smartphones
• Serveurs sur lesquels s'exécutent des applications MES ou ERP
La classe de puissance des appareils est différenciée par les profils. Différents profils OPC UA
permettent d'échelonner OPC UA, des petits appareils de base aux appareils plus performants.
Un profil OPC UA décrit les fonctions et services qui doivent être pris en charge par le serveur
et le client. Des fonctions et services supplémentaires qui ne sont pas exigés par le profil
peuvent en outre être fournis en option.
Les profils OPC UA se distinguent des profils PROFINET. En effet, ces derniers définissent des
propriétés non propriétaires supplémentaires et des comportements pour les appareils et les
systèmes au sens d'une interface logicielle indépendante des constructeurs.
Nano Embedded Device 2017 Server Profile

OPC Foundation fournit le profil "Nano Embedded Device 2017 Server Profile" pour les
appareils les plus petits à fonctionnalité très réduite. Ce profil correspond sur le plan
fonctionnel à la facette Serveur principal (Core Server Facet) et définit le protocole TCP OPC
UA binaire comme profil de transport obligatoire. Ce profil permet uniquement des liaisons
sans UA Security, il ne permet ni abonnements ni appels de méthode. La prise en charge
d'objets et de variables de diagnostic est optimale pour ce profil.
D'autres profils se basent sur le profil "Nano Embedded Device 2017 Server Profile", exigent
plus de ressources et offrent plus de fonctionnalités.
Micro Embedded Device 2017 Server Profile

Ce profil offre une fonctionnalité restreinte. Il requiert au moins deux liaisons parallèles,
prend également en charge les abonnements et la surveillance des données, mais n'offre ni
UA Security, ni appels de méthode.
• Les Basic Controllers S7-1200 prennent en charge le profil "Micro Embedded Device 2017
Server Profile", le S7-1200 prenant également en charge UA Security.
Embedded 2017 UA Server Profile

Ce profil a été développé pour les appareils dotés d'une mémoire de travail de plus de 50 Mo
et un processeur plus performant. Il se base sur le profil Micro Embedded Device Server. Il
nécessite en plus UA-Security et les appels de méthodes.
Les serveur doivent en outre mettre leur modèle de types utilisé (types de données, types de
références, types de variables, ...) à disposition.
• Les Advanced Controller S7-1500 prennent en charge le "Embedded 2017 UA Server
Profile".
Communication
Profils Standard Discovery et Global Discovery

La spécification "OPC UA Specification Part 7" définit les profils supplémentaires suivants :
• Le profil "Standard 2017 UA Server Profile", approprié pour les serveurs OPC UA sur base
PC
• 2 profils globaux, "Global Discovery Server 2017 Profile" et "Global Discovery and
Certificate Management 2017 Server Profile", qui couvrent les modèles de services et
d'information nécessaires d'un serveur Global Discovery
Concept type/instance
OPC UA propose un modèle d'information orienté objet de réseau entièrement maillé (fully
meshed network) pour les espaces de noms, métadonnées pour la description d'objet
comprises. Le référencement des instances entre elles ainsi que de leurs types permet de
générer des structures d'objet quelconques. Étant donné que les serveurs publient leur
système d'instances et de types, les clients peuvent naviguer dans ce réseau et accéder à
toutes les informations nécessaires. Les instances ainsi que les définitions de leurs types sont
disponibles durant l'exécution.
Les procédures ou les concepts de gestion des références à des types sont optimisés au fil du
temps. Ces optimisations conduisent à de nouvelles versions de la spécification OPC UA
(V1.03 => V1.04, par exemple).
Représentation des variables API

Les informations du serveur OPC UA (par exemple, les variables API) sont modélisées sous
forme de nœuds (Nodes) reliés les uns aux autres par des références. La sémantique est
affichée par le serveur dans la plage d'adresses et les clients y ont accès par la navigation.
Cela permet de naviguer d'un nœud à l'autre avec un client OPC UA et de découvrir quels
contenus peuvent être lus, visualisés ou écrits.
Mécanismes de sécurité intégrés

OPC UA utilise des mécanismes de sécurité à différents niveaux :
• L'établissement de liaisons sécurisées entre un serveur OPC UA et un client OPC UA n'est
possible que si le client et le serveur peuvent justifier de leur identité au moyen de
certificats X.509-v3 et qu'ils acceptent mutuellement leurs certificats (sécurité au niveau
application). Plusieurs stratégies de sécurité sont possibles, y compris une liaison non
sécurisée entre serveur et client (Security Policy : "Aucune sécurité").
• Un serveur peut a priori exiger les informations suivantes de l'utilisateur pour l'accès
autorisé (authentification) :
- un certificat utilisateur (non configurable dans STEP 7)
- un nom d'utilisateur et un mot de passe
- aucune légitimation de l'utilisateur
Les mécanismes de sécurité sont facultatifs et configurables.
Voir aussi
OPC Foundation (https://opcfoundation.org)
Communication
9.1.3 OPC UA pour CPU S7-1200/S7-1500

Pour OPC UA, un système fonctionne comme serveur et met des informations disponibles à
disposition d'autres systèmes (clients).
Les clients OPC UA ont par ex. un accès en lecture et en écriture aux données d'un serveur
OPC UA. Les clients OPC UA appellent des méthodes dans le serveur OPC UA.
Vous pouvez accéder à ces données en ligne avec un client, ainsi que, par exemple, aux
informations sur les performances et le diagnostic. Cette fonction s'appelle "Browsen" dans la
terminologie OPC UA. La fonction "Subscription" évite la lecture régulière d'une variable : le
serveur informe le client des modifications de valeur.
Un système peut servir indifféremment de client ou serveur.
Serveur OPC UA de la CPU S7-1500

À partir de la version V2.0 du firmware, une CPU S7-1500 est équipée d'un serveur OPC UA.
Les chapitres suivants décrivent comment configurer le serveur OPC UA de la CPU S7-1500
afin de mettre des données et des méthodes à la disposition de clients OPC UA de manière
que les clients aient accès en lecture et en écriture à des variables API de la CPU et appellent
des méthodes dans le serveur.
En outre, les chapitres suivants décrivent comment intégrer des spécifications Companion à
la plage d'adresses du serveur OPC UA.
Serveur OPC UA de la CPU S7-1200

À partir de la version V4.4 du firmware, une CPU SIMATIC S7-1200 est équipée d'un serveur
OPC UA.
En principe, le serveur OPC UA est configuré de la même manière qu'une CPU S7-1500, le
périmètre fonctionnel et les structures de quantités sont limités en fonction du profil "Micro
Embedded Device 2017 Server Profile" supporté. Contrairement à une CPU S7-1500, les
fonctions "Registered Read" et "Registered Write" ne sont pas disponibles.
À partir du firmware V4.5, les CPU S7-1200 prennent en charge aussi bien les méthodes de
serveur que les types de données structurés (structures et tableaux).
Pour plus d'informations, voir l'aide en ligne de STEP 7.
Communication
Client OPC UA de la CPU S7-1500

À partir de la version V2.6 du firmware, une CPU S7-1500 est également équipée d'un client
OPC UA.
Les chapitres suivants expliquent comment élaborer, avec des instructions standardisées
(blocs fonctionnels PLCopen), un programme utilisateur qui fournit les fonctions suivantes en
tant que client OPC UA :
• Lire des données d'un serveur OPC UA
• Écrire des données dans un serveur OPC UA
• Appeler des méthodes d'un serveur OPC UA
STEP 7 (TIA Portal) vous aide à élaborer ce programme utilisateur avec un éditeur pour
interfaces client et un paramétrage pour des liaisons OPC UA.
Les instructions OPC UA pour une CPU S7-1500 comme client sont décrites de manière
détaillée dans l'aide sur les instructions (Instructions > Communication > OPC UA).
Client OPC UA à des fins de test

Pour illustrer le maniement des clients OPC UA, la description suivante utilise différents
clients OPC UA :
• "UaExpert" de Unified Automation. Client de grande envergure qui peut être utilisé
gratuitement :
Lien pour le téléchargement de UaExpert. (https://www.unified-
automation.com/downloads/opc-ua-clients.html)
• "UA Sample Client" de OPC Foundation. Ce client est disponible gratuitement pour les
utilisateurs enregistrés auprès de l'OPC Foundation :
Lien pour le téléchargement de l'exemple de client de l'OPC Foundation
(https://opcfoundation.org)
Exemple d'application dans Industry Online Support

Le support en ligne de Siemens Industry propose gratuitement un exemple d'application avec
un API client pour différents cas d'application. Les fonctions de cette interface vous
permettent de créer vos propres clients OPC UA, adaptés à votre cas d'application. Afin de
simplifier le maniement de l'API, nous vous proposons une classe .NET Helper supérieure.
L'API client repose sur la pile .NET OPC UA de l'OPC Foundation.
Cet exemple d'application est disponible gratuitement et montre l'établissement de liaisons
entre serveur et client, ainsi que la lecture et l'écriture de variables API.
Lien pour le téléchargement : OPC UA .NET Client for the SIMATIC S7-1500 OPC UA Server
(http://support.automation.siemens.com/WW/view/fr/109737901)
Communication
9.1.4 Accès aux applications OPC UA

Les paragraphes suivants décrivent les possibilités d'accès dont dispose une CPU S7-1500
avec une application OPC UA (client ou serveur) par le biais d'un CP dans la même station. Ils
montrent en outre comment combiner ces possibilités d'accès avec la fonction "IP
Forwarding" (transmission IP) pour accéder aux appareils d'un autre sous-réseau IP par le biais
d'une station S7-1500.
Tous les paramètres figurent dans la section "Configuration avancée" des propriétés de la CPU
dans la fenêtre d'inspection.
La possibilité d'atteindre l'application OPC UA dans la CPU par le biais d'une interface CP est
liée aux conditions suivantes :
• S7-1500 CPU (sauf S7-1500R/H) à partir de la V2.8 du firmware
• CP 1543-1 à partir de la version de firmware V2.2
Communication
Principe : interface d'accès via un module de communication

Vous devez configurer une interface virtuelle (W1) pour qu'une application CPU telle que
OPC UA soit accessible par le biais d'une interface CP. Les paramètres d'adresse IP de cette
interface virtuelle permettent alors d'accéder aux applications basées sur IP.
Ce principe est illustré dans la figure ci-dessous.
① CPU S7-1500 à partir de la V2.8 du firmware (par ex. CPU 1515-2 PN)
② CP 1543-1 (à partir de la V2.2 du firmware)
③ Interface virtuelle (W1)
④ Conversion de protocole PROFINET / Industrial Ethernet sur bus interne ou bus interne sur PROFINET / Industrial Ether-
net
⑤ Bus interne
Figure 9-1 Principe : interface d'accès via un module de communication
Communication
Exemple : Accès de clients OPC UA au serveur OPC UA de la CPU

Les interfaces suivantes de la station S7-1500 permettent à un client OPC UA d'accéder au
serveur OPC UA de la CPU :
• Interfaces PROFINET locales de la CPU S7-1500
• Interface Ethernet d'un CP 1543-1 (à partir de la version de firmware V2.2)
La figure suivante montre un exemple de configuration possible. La CPU pourrait également
avoir le rôle de client OPC UA et l'appareil dans le sous-réseau du CP, celui de serveur OPC UA.
Figure 9-2 Exemple : Accès de clients OPC UA au serveur OPC UA de la CPU
Communication
Exemple : Accès de clients OPC UA à des serveurs OPC UA par le biais d'une CPU S7-1500 avec
transmission IP (IP forwarding) activée
Un client OPC UA et un serveur OPC UA peuvent également être connectés l'un à l'autre par le
biais d'une CPU S7-1500, cette dernière agissant en tant que transmetteur IP. Cette possibilité
de configuration permet une extension flexible d'installations existantes.
Figure 9-3 Exemple : Accès de clients OPC UA à des serveurs OPC UA par le biais d'une CPU S7-1500 avec transmission IP
(IP forwarding) activée

Dans les paragraphes suivants, vous trouverez d'autres informations sur les possibilités
d'accès via l'interface virtuelle et via l'IP forwarding :
• IP Forwarding (Page 1)
• Interface virtuelle pour applications à base IP (Page 1)
Communication
9.1.5 Adressage des nœuds

Les nœuds (Nodes) constituent les éléments fondamentaux d'OPC UA. Ils sont comparables
aux objets utilisés pour la programmation orientée objets. Des nœuds sont par ex. utilisés
pour les données utiles (variables) ou d'autres métadonnées. Il est également possible de
modéliser un espace d'adressage OPC UA sous forme de nœuds contenant un modèle de
type, avec les définitions de type correspondantes.
ID de nœud (NodeId)
Les nœuds dans l'espace d'adressage OPC UA sont définis de manière unique par un
identificateur de nœud (NodeId).
L'identificateur de nœud NodeId se compose d'un identificateur, d'un type d'identificateur et
d'un indice d'espace de noms. Les espaces nom sont utilisés pour éviter des conflits de noms.
OPC Foundation a définit un certain nombre de nœuds qui donnent des informations sur le
serveur OPC UA respectif. Ces nœuds se trouvent dans l'espace de noms de OPC Foundation
et possèdent l'indice 0.
OPC Foundation a défini en outre des types de données et des types de variables.
Espace de noms (Namespace)

En plus de l'espace de nom OPC Foundation décrit ci-dessus, l'espace de nom est également
intéressant pour l'accès aux données CPU : toutes les variables ou méthodes d'un serveur OPC
UA S7-1500 se trouvent dans l'espace de noms (Namespace) de l'interface serveur standard
"http://www.siemens.com/simatic-s7-opcua".
Cet espace de noms possède par défaut l'indice 3. Mais l'indice est susceptible de changer si
d'autres espaces de noms sont ajoutés au serveur ou si des espaces existants sont supprimés.
Le client OPC UA doit donc demander au serveur l'indice de l'espace de noms actuel (par ex.
"http://www.siemens.com/simatic-s7-opcua") avant l'écriture ou la lecture des valeurs.
La figure suivante montre un exemple de résultat pour une demande de ce type.
Communication
Identifier
L'identificateur Identifier correspond au nom de la variable API entre guillemets. Les
guillemets sont le seul caractère qui n'est pas autorisé à l'intérieur d'un nom dans STEP 7. Les
guillemets permettent ainsi d'éviter des conflits de noms.
L'exemple ci-dessous lit la valeur de la variable "StartTimer" :
L'identificateur Identifier peut comporter plusieurs éléments. Les différents éléments sont
alors séparés par des points.
L'exemple ci-dessous lit le contenu du bloc de données tableau "MyDB" dans son intégralité.
Ce bloc de données comprend un tableau avec dix valeurs de nombres entiers. Ces dix valeurs
doivent être lues en une fois. Il faut donc écrire "0:9" pour Array Range :
Exemple de NodeID, d'identificateurs et d'espaces de noms

La figure suivante montre le rapport entre les différents NodeID, identificateurs et espaces de
noms. Il n'est pas problématique que deux nœuds aient la même identification et
appartiennent à des espaces de noms différents.
STEP 7 (TIA Portal) offre des méthodes simples d'importation d'espaces de noms via une
interface serveur.
Communication
Variables API dans la plage d'adresses du serveur OPC UA

La figure suivante montre où se trouvent les variables API de l'exemple dans la plage
d'adresses du serveur OPC UA (extrait du client UA) :
Le bloc de données "MyDB" est un bloc de données global. Il se trouve donc sous le nœud
"DataBlocksGlobal". "StartTimer" est une variable mémento. Elle est donc représentée sous le
nœud "Memory".
Figure 9-4 Variables API dans la plage d'adresses du serveur OPC UA
Communication
Méthodes dans la plage d'adresses du serveur OPC UA

Si vous implémentez une méthode via votre programme utilisateur, la plage d'adresses du
serveur OPC UA se présente comme suit
(voir Fournir des méthodes sur le serveur OPC UA (Page 1)) :
Figure 9-5 Méthodes dans la plage d'adresses du serveur OPC UA
Communication
9.1.6 Informations utiles sur les clients OPC UA
Notions de base sur les clients OPC UA

Les clients OPC UA sont des programmes offrant les possibilités suivantes :
• Accès à des informations d'un serveur OPC UA (par exemple d'une CPU S7-1500) : en
lecture/navigation, en écriture, abonnements
• Exécution de méthodes par le serveur OPC UA
Néanmoins, les clients OPC UA ne peuvent accéder qu'aux données pour lesquelles une
autorisation correspondante été accordée (voir "Gestion des droits de lecture et d'écriture
(Page 1)").
Pour établir une liaison à un serveur OPC UA, vous avez besoin du nœud d'extrémité du
serveur (voir "Nœuds d'extrémité du serveur OPC UA (Page 1)").
Lecture d'informations dans le serveur OPC UA

Si une liaison est établie à un nœud d'extrémité du serveur, vous pouvez utiliser la fonction
de navigation du client : Vous parcourez la plage d'adresses du serveur à partir d'un point de
départ défini (le nœud racine "Root").
Ainsi, vous recevez entre autres les informations suivantes :
• Variables API, blocs de données et éléments de bloc de données validés
• Indice d'espace de noms et identificateur de ces variables API, blocs de données et
éléments de DB
• Types de données des variables API et des éléments de DB
• Nombre d'éléments dans les tableaux (obligatoire pour la lecture et l'écriture de tableaux)
Vous recevez en outre des informations sur le serveur OPC UA lui-même ainsi que sur le S7-
1500, basées sur le standard "OPC UA for Devices" de OPC Foundation (par exemple, numéro
de série, version du firmware).
Communication
Lire et écrire des données dans le serveur

Vous connaissez désormais l'indice d'espace nom, l'identifiant et le type de données des
variables API. Ainsi, vous pouvez désormais lire certaines variables API et certains éléments de
DB de manière ciblée de même que des structures et des tableaux entiers.
Pour des exemples de lecture de variables booléennes et de blocs de données ARRAY, voir
Adressage de nœuds (Page 1).
Vous trouverez les règles d'accès à des structures ici (Page 1).
Avec les informations que vous obtenez en parcourant la plage d'adresses du serveur (indice,
identificateur et type de données), vous pouvez aussi transférer des valeurs dans le S7-1500
avec le client OPC UA. L'exemple ci-dessous écrase les trois premières valeurs dans le bloc de
données ARRAY "MyDB".
Indiquez dans "Array Range" quels éléments du tableau vous voulez écraser. Le Status Code
"Good" indique que les valeurs ont bien été transférées. Cependant, vous ne pouvez écrire
que les valeurs dans la S7-1500 et non les horodatages de ces valeurs. Les horodatage sont
uniquement accessibles en lecture.
Accès plus rapide grâce à un enregistrement

Une opération Registered Read/Write permet un accès optimisé répété à des données avec
des performances maximales. Lors de l'enregistrement de nœuds de variables, le serveur OPC
UA crée un identifiant de nœud numérique (Identifier) qui renvoie directement au nœud
enregistré. Lors de requêtes de lecture ou d'écriture du client à cet Identifier numérique, le
serveur ne doit pas résoudre de chaînes de caractères comme Identifier et peut accéder de
manière optimisée à la variable requise.
Cet Identifier n'est valable que pour la session actuelle et doit être demandé de nouveau en
cas d'arrêt ou de perte de la session.
Dans l'exemple suivant, la variable "StartTimer" a dans un premier temps été enregistrée sur
le serveur. La fonction rapide "RegisteredWrite" est ensuite utilisée pour la définition de la
valeur.
Communication
La fonction "RegisteredRead" peut être utilisée selon le même modèle, ce qui est
particulièrement judicieux en cas de lecture récurrente de données. Notez bien cependant
qu'il peut être préférable d'utiliser une souscription (Subscription) en fonction de
l'application.
Recommandation : Placez les enregistrements de préférence dans le programme de
démarrage du client OPC UA car l'enregistrement prend du temps.
Notez que vous pouvez paramétrer dans les propriétés de la CPU S7-1500 le nombre
maximum de nœuds enregistrés et que les clients doivent tenir compte de ce nombre, voir
Paramètres généraux du serveur OPC UA (Page 1).
Souscription
On désigne par "Subscription" une fonction ne transférant que les variables pour lesquelles un
client OPC UA s'est enregistré auprès du serveur OPC UA. Pour ces variables enregistrées
(éléments surveillés = monitored Items), le serveur OPC UA n'envoie de message au client
OPC UA que lorsqu'une valeur a changé. Les variables étant surveillées, le client OPC UA n'est
plus obligé de les interroger continuellement (Polling). La charge du réseau s'en trouve
réduite.
Pour utiliser cette fonction, vous devez créer une Subscription. Pour ce faire, vous définissez
l'intervalle d'émission ("Publishing Interval") dans le client UA et vous cliquez sur le bouton
"Create". L'intervalle d'émission est l'intervalle de temps pendant lequel le serveur envoie de
nouvelles valeurs au client dans une notification ("data change notification").
Dans l'exemple suivant, une souscription a été créée : Le client reçoit toutes les
50 millisecondes un message contenant les nouvelles valeurs (intervalle d'émission 50 ms).
Communication
Protéger le serveur contre la surcharge

Le paramètre "Intervalle d'émission minimal" vous permet de paramétrer le serveur OPC UA
de la CPU S7-1500 pour qu'il ne tienne pas compte des intervalles d'émission extrêmement
courts souhaités par le client (voir Paramètres du serveur pour souscriptions (Page 1)).
Exemple : un client souhaite fonctionner à des intervalles d'émission de 50 ms comme décrit
ci-dessus. Mais un intervalle d'émission aussi court entraînerait une augmentation de la
charge du réseau et le serveur s'en trouverait surchargé. Par conséquent, il est judicieux de
régler l'"Intervalle d'émission minimal" du serveur sur 1 000 ms. Les clients qui souhaitent des
intervalles d'émission plus courts dans leur souscription sont alors "ralentis" à 1 000 ms afin
d'éviter la surcharge du serveur.
L'échantillonnage et l'émission ("Sampling & Publishing") dans le cadre d'une souscription
sont des processus de communication que la CPU traite avec la priorité 15 comme les autres
processus de communication (communication TCP/UDP/serveur Web...). Les OB de priorité
supérieure interrompent la communication. Vous accroissez la charge due à la
communication si vous définissez des intervalles d'échantillonnage et d'émission trop courts.
Il est donc recommandé de choisir des intervalles les plus grands possibles qui suffisent
encore pour l'application.
Vous trouverez des informations sur la cohérence des variables sous "Cohérence des variables
CPU (Page 1)".
Surveillance de variables API

Lorsque la Subscription est créée, vous indiquez au serveur les variables qu'il doit surveiller
ainsi. Dans l'exemple ci-dessous, la variable "Voltage" a été ajoutée à la souscription.
La variable "Voltage" contient, par exemple, la valeur d'une tension acquise par une CPU S7-
1500.
L'intervalle d'échantillonnage ("Sampling Interval") contient une valeur négative (-1). Cela
détermine que le paramétrage par défaut du serveur OPC UA est utilisé pour l'intervalle
d'échantillonnage. Le paramétrage par défaut est défini par l'intervalle d'émission
("Publishing Interval") de la souscription. Entrez la valeur "0" si vous souhaitez régler le plus
petit intervalle d'échantillonnage possible.
La longueur de la file d'attente est fixée à "1" dans cet exemple : une seule valeur est lue dans
la CPU dans l'intervalle de 50 millisecondes, puis envoyée au client OPC UA lorsqu'elle a
changé.
Le paramètre "Deadband" a la valeur "0,1" dans l'exemple : les variations de valeur doivent
être d'au moins 0,1 volt ; ce n'est qu'alors que le serveur envoie la nouvelle valeur au client.
Le serveur n'envoie pas les variations de valeur inférieures. Avec ce paramètre, vous pouvez
par exemple masquer le bruit : variations de faible importance d'une grandeur de process qui
n'a pas de signification réelle.
Communication
9.1.7 Mappage de types de données
Types de données SIMATIC et OPC UA

Les types de données SIMATIC ne correspondent pas toujours aux types de données OPC UA.
Les CPU S7-1500 mettent à la disposition de leur propre serveur OPC UA des variables
SIMATIC (avec des types de données SIMATIC) sous forme de types de données OPC UA afin
que les clients OPC UA puissent avoir accès à ces variables de types de données OPC UA par le
biais de l'interface serveur.
Un client peut lire l'attribut "DataType" d'une telle variable et s'en servir pour reconstruire le
type de données d'origine dans SIMATIC.
Exemple
Une variable a le type de données SIMATIC "COUNTER". Dans le tableau, vous lisez COUNTER
→ UInt16. Vous savez désormais que vous n'avez pas besoin de transcoder la valeur COUNTER
qui est transmise comme variable de type de données UInt16.
Le client reconnaît à l'attribut "DataType" que la variable a en fait le type de données SIMATIC
"COUNTER". Le client reconstitue le type de données sur la base de cette information.
Tableau 9- 1 Types de données SIMATIC et OPC UA
Type de données SIMATIC Type de données OPC UA

BOOL Boolean
BYTE BYTE
→ Byte
WORD WORD
→ UInt16
DWORD DWORD
→ UInt32
LWORD LWORD
→ UInt64
SINT SByte
INT Int16
DINT Int32
LINT Int64
USINT Byte
UINT UInt16
UDINT UInt32
ULINT UInt64
REAL Float
LREAL Double
S5TIME S5TIME
→ UInt16
TIME TIME
→ Int32
Communication

LTIME LTIME
→ Int64
DATE DATE
→ UInt16
TIME_OF_DAY (TOD) TOD
→ UInt32
LTIME_OF_DAY (LTOD) LTOD
→ UInt64
DATE_AND_TIME (DT) DT
→ Byte[8]
LDT DateTime
DTL mappé comme structure
Particularité : vous ne pouvez décrire la structure
que complètement avec un client OPC UA. Vous
pouvez accéder en lecture à différents éléments
de cette structure (par ex. à "YEAR")
CHAR CHAR
→ Byte
WCHAR WCHAR
→ UInt16
STRING STRING
(Codepage 1252 ou Windows-1252) → String
WSTRING String
(UCS-2 ; Universal Coded Character Set)
TIMER TIMER
→ UInt16
COUNTER COUNTER
→ UInt16
Arrays (tableaux)
Pour OPC UA, une requête de lecture ou d'écriture constitue toujours un accès à un tableau.
Autrement dit, il s'effectue toujours à l'aide d'un index et d'une longueur, de sorte qu'une
variable simple ne constitue qu'un cas particulier d'un tableau (index 0 et longueur 1). Le type
de données est juste envoyé plusieurs fois successivement par la ligne. L'attribut "DataType"
de la variable désigne le type de données de base. Les attributs "ValueRank" et
"ArrayDimensions" déterminent s'il s'agit d'un tableau et sa taille.
Communication
Types de données basés sur des tableaux

Il existe des types de données SIMATIC pour lesquels une valeur OPC UA est mappée sur un
tableau d'octets. Un tableau de ces types de données est alors mappé sur un tableau à deux
dimensions.
Par exemple, le type de données SIMATIC DATE_AND_TIME (DT) est mappé sur un tableau de
8 octets (Byte[8]) (voir le tableau ci-avant). Si vous définissez un tableau de type de données
SIMATIC DATE_AND_TIME (DT), il s'agira d'un tableau bidimensionnel.
Cela a des conséquences sur l'utilisation de types de données système tels que
OPC_UA_NodeAdditionalInfo et OPC_UA_NodeAdditionalInfoExt, par exemple.
Pour les types de données décrits ci-dessus, vous devez utiliser le type de données système
OPC_UA_NodeAdditionalInfoExt pour des tableaux multidimensionnels au lieu de
OPC_UA_NodeAdditionalInfo.
Structures
Les structures sont transmises sous forme d'ExtensionObject. Le serveur S7-1500 exploite la
représentation binaire pour la transmission de l'ExtensionObjects par la ligne, les éléments de
structure étant disposés directement les uns après les autres. Au début, se trouve la NodeId
du type de données à l'aide de laquelle un client identifie l'architecture de la structure.
Avec la spécification OPC UA <= V1.03, le client doit à cet effet lire le dictionnaire
DataTypeDictionary complet, le décoder et l'interpréter (s'il n'a pas déjà procédé à
l'apprentissage de celui-ci hors ligne par importation de fichier XML).
À partir de OPC UA V1.04, il existe pour cela l'attribut DataTypeDescription plus facile et plus
rapide à lire et interpréter. Le client n'identifie l'architecture de la structure qu'une seule fois,
soit avant, soit pendant le premier accès, et exploite ensuite cette information pendant toute
la durée de la session.
Types de données SIMATIC spéciaux

Les types de données SIMATIC qui ne figurent pas dans le tableau ci-dessus ou qui ne peuvent
pas être définis comme éléments d'une structure ou d'un type de données API ne sont pas
pris en charge par le client OPC UA.
Il s'agit, par exemple, du pointeur "ANY" ou "POINTER", du bloc fonctionnel "Block_FB", de la
fonction "Block_FC" ou du type de données matériel "REMOTE".
Sélectionner un type de données non pris en charge provoque l'émission d'un message
d'erreur.

Vous trouverez des informations plus détaillées sur la représentation des types de données de
base, mais également sur les tableaux et structures, dans la spécification OPC UA - Part 6,
"Mappings" (voir "OPC UA BINARY").
De quoi faut-il tenir compte pour les tableaux et les types de données DTL et LDT dans le
serveur OPC UA d'une SIMATIC S7-1500 ? FAQ
(https://support.industry.siemens.com/cs/ww/fr/view/109766726)
Communication
9.2 Sécurité avec OPC UA
9.2.1 Paramètres de sécurité
Prévenir les risques

OPC UA autorise l'échange de données aussi bien entre différents systèmes au sein des
niveaux process et production qu'avec des systèmes du niveau conduite et gestion de
l'entreprise.
Cette possibilité comporte aussi des risques pour la sécurité. C'est pourquoi OPC UA propose
un certain nombre de mécanismes de sécurité :
• Contrôle de l'identité des clients et serveurs OPC UA.
• Contrôle de l'identité des utilisateurs.
• Échange de données signé/crypté entre clients et serveurs OPC UA.
Les paramètres de sécurité ne doivent être désactivés que dans des cas justifiés :
• Pendant la mise en service.
• Sur des projets isolés, sans connexion Ethernet vers l'extérieur.
Par exemple, lorsque vous sélectionnez le nœud d'extrémité "None" dans "UA Sample Client"
de OPC Foundation, le programme affiche un avertissement clair :
Communication
De même, STEP 7 vérifie lors de la compilation de votre projet si vous avez tenu compte des
possibilités de paramétrage pour la protection et envoie un avertissement en cas de risque.
Ce sera ainsi le cas pour une stratégie de sécurité OPC UA "Aucune Security", qui correspond
au nœud d'extrémité "None".
Remarque
Désactiver les stratégies de sécurité non souhaitées
Si vous avez activé toutes les stratégies de sécurité dans les paramètres Secure Channel du
serveur OPC UA S7-1500 – et donc également le nœud d'extrémité "None" (Aucune Security)
–, l'échange de données même non sécurisé (ni signé ni crypté) est possible entre serveur et
client. Le serveur OPC UA de la CPU S7-1500 envoie son certificat public au client, même avec
"None" (pas de Security). Et certains clients vérifient ce certificat. Par contre, le client n'est pas
obligé d'envoyer un certificat au serveur. L'identité du client peut rester inconnue. Chaque
client OPC UA peut alors se connecter au serveur indépendamment des paramètres Security à
venir.
Lors de la configuration du serveur OPC UA, veillez à ce que seules soient activées des
stratégies de sécurité compatibles avec le concept de sécurité mis en œuvre dans votre
machine ou installation. Toutes les autres stratégies de sécurité doivent être désactivées.
Recommandation : Utilisez le paramètre "Basic256Sha256 - Signer & crypter" avec lequel le
serveur n'accepte que les certificats Sha256. Les stratégies de sécurité "Basic128Rsa15" et
"Basic256" sont désactivées dans les réglages par défaut et ne doivent pas être utilisées
comme nœuds d'extrémité. Sélectionnez des nœuds d'extrémité avec une stratégie de
sécurité élevée.
Autres règles de sécurité

• N'utilisez qu'exceptionnellement le nœud d'extrémité "None".
• N'utilisez qu'exceptionnellement "l'authentification d'invité" de l'utilisateur.
• N'autorisez l'accès aux variables API et éléments de DB via OPC UA que lorsque cela est
vraiment nécessaire.
• Utilisez les listes de clients fiables dans les paramètres du client OPC UA de S7-1500 afin
de restreindre l'accès à certains clients uniquement.
Communication
9.2.2 Certificats conformes à la norme X.509 de l'UIT

Des mécanismes de sécurité sont intégrés dans plusieurs couches avec OPC UA. Et les
certificats électroniques y jouent un rôle très important. Un client OPC UA ne peut établir une
liaison sécurisée à un serveur OPC UA que si le serveur accepte le certificat numérique du
client et le classe comme fiable.
Voir chapitre Utilisation des certificats du client et du serveur (Page 1).
En outre, le client doit également vérifier le certificat du serveur et lui faire confiance. Client
et serveur doivent justifier de leur identité et prouver qu'ils sont effectivement ceux qu'ils
prétendent être ; Ils doivent prouver leur identité. L'authentification mutuelle entre client et
serveur permet d'éviter par exemple des attaques par un homme au milieu ("Man in the
Middle").
Attaques par un homme au milieu (Man in the Middle)

Entre le client et le serveur pourrait s'interposer un "Man in the Middle", nom donné à un
programme qui se substitue au client ou au serveur pour intercepter les échanges entre le
client et le serveur, qui obtient ainsi des informations sensibles sur le programme S7 ou
active des valeurs dans la CPU lui permettant d'attaquer une machine ou une installation.
OPC UA utilise des certificats numériques conformes à la norme X.509 de l'Union
internationale des télécommunications (UIT).
Cela permet de vérifier (authentifier) l'identité d'un programme, d'un ordinateur ou d'un
organisme.
Certificats X.509
Un certificat X.509 contient, entre autres, les informations suivantes :
• Numéro de version du certificat
• Numéro de série du certificat
• Informations sur l'algorithme utilisé par l'autorité de certification pour signer le certificat
• Nom de l'autorité de certification
• Début et fin de validité du certificat
• Nom du programme, de la personne ou de l'organisme pour qui l'autorité de certification a
signé le certificat.
• Clé publique du programme, de la personne ou de l'organisme.
Un certificat X509 associe ainsi une identité (nom d'un programme, d'une personne ou d'un
organisme) avec la clé publique du programme, de la personne ou de l'organisme.
Communication
Vérification lors de l'établissement de la liaison

Lors de l'établissement de la liaison entre client et serveur, les abonnés vérifient toutes les
informations du certificat nécessaires pour constater l'intégrité, comme la signature, la durée
de validité, le nom de l'application (URN), ainsi que les adresses IP du client dans le certificat
client pour la version V2.5 du firmware (uniquement pour cette version).
Remarque
La période de validité enregistrée dans le certificat est également contrôlée lors de
l'établissement de la liaison. L'horloge CPU doit donc être réglée et la date et l'heure doivent
se situer dans la période de validité. Aucune communication n'a lieu dans le cas contraire.
Signature et cryptage
Pour pouvoir vérifier si un certificat a été manipulé, les certificats sont signés.
Pour cela, il y a différentes méthodes :
• Dans TIA Portal, vous avez la possibilité de générer et de signer des certificats. Si vous avez
protégé votre projet et que vous vous êtes connecté avec le droit fonctionnel d'effectuer
des paramétrages de sécurité, les paramètres de sécurité globaux sont également
utilisables. Les paramètres de sécurité globaux permettent d'accéder au gestionnaire de
certificats et donc à l'autorité de certification (CA) de TIA Portal.
• D'autres méthodes sont disponibles pour générer et signer des certificats. Dans TIA Portal,
vous pouvez importer des certificats dans le gestionnaire de certificats global.
– Vous vous adressez à une autorité de certification (CA) pour faire signer votre certificat.
Dans ce cas, l'autorité de certification vérifie votre identité et signe votre certificat à
l'aide de la clé privée fournie par l'autorité de certification. Envoyez à cet effet une CSR
(Certificate Signing Request - demande de signature de certificat) à l'autorité de
certification.
– Vous générez un certificat vous-même et vous le signez.
Pour cela, utilisez par exemple le programme "Opc.Ua.CertificateGenerator" de OPC
Foundation. Vous pouvez également utiliser OpenSSL.
Pour plus d'informations, voir Créer soi-même une paire de clés PKI et des certificats
(Page 1).
Communication
Parenthèse : Types de certificat

• Certificat auto-signé :
Chaque abonné crée son propre certificat et le signe. Exemples d'applications :
Configuration statique avec un nombre limité d'abonnés.
Il n'est pas possible de créer de nouveaux certificats à partir de certificats auto-signés.
Vous devez toutefois charger tous les certificats auto-signés des partenaires dans la CPU
(Arrêt nécessaire).
• Certificat CA :
Tous les certificats sont créés et signés par une autorité de certification (CA). Exemples
d'applications : Installations évolutives.
Vous ne devez charger que le certificat de l'autorité de certification dans la CPU. L'autorité
de certification peut créer de nouveaux certificats (ajout de partenaires possibles sans
Arrêt de la CPU).
Signature
La signature permet de garantir l’intégrité et l'origine d'un message, comme décrit ci-après.
Lors de la signature, l'émetteur forme d'abord une valeur de hachage à partir du texte en clair
(message en clair). L'émetteur crypte ensuite la valeur de hachage à l'aide de sa clé privée et
transmet enfin le texte en clair avec la valeur de hachage cryptée au destinataire. Pour vérifier
l'authenticité de la signature, le destinataire a besoin de la clé publique de l'émetteur
(contenue dans le certificat X509 de l'émetteur). Le destinataire décrypte la valeur de
hachage reçue à l'aide de la clé publique de l'émetteur. Ensuite, le destinataire forme, à son
tour, une valeur de hachage à partir du texte en clair reçu (la fonction de hachage est
contenue dans le certificat de l'émetteur). Puis, le destinataire compare les deux valeurs de
hachage :
• Si les deux valeurs de hachage sont identiques, alors le message en clair reçu par le
destinataire n'a pas été altéré ou manipulé.
• Si les deux valeurs de hachage ne sont pas identiques, alors le message en clair reçu par le
destinataire n'est pas identique. Le message en clair reçu a été manipulé ou altéré lors du
transfert.
Cryptage
En cryptant les données, vous évitez que des personnes non autorisées ne prennent
connaissance du contenu. Les certificats X509 ne sont pas chiffrés ; ils sont publics et chacun
peut les consulter.
Lors du codage, l'émetteur chiffre le message en clair au moyen de la clé publique du
destinataire. Pour cela, l'émetteur a besoin du certificat X509 du destinataire, puisqu'il
contient la clé publique du destinataire. Le destinataire déchiffre le message avec sa clé
privée. Seul le destinataire peut déchiffrer le message. Lui seul détient la clé privée. C'est
pourquoi la clé privée ne doit jamais être transmise.
Communication
Voie protégée
OPC UA utilise les clés privées et publiques du client et du serveur pour l'établissement d'une
liaison sécurisée, appelé Secure Channel. Lorsque la liaison sécurisée est établie, client et
serveur génèrent une clé interne, connue d'eux seuls, qu'ils utilisent pour signer et chiffrer
des messages. Ce procédé symétrique (avec une clé commune) est nettement plus rapide
que le chiffrement asymétrique (utilisant une clé privée et une clé publique).
Voir aussi
Création de certificats autosignés (Page 1)
Certificats sur OPC UA (Page 1)
Secure Communication (Page 1)
Utilisation de certificats avec TIA Portal
9.2.3 Certificats sur OPC UA
Utilisation des certificats X.509 pour OPC UA

OPC UA utilise différents types de certificats X.509 lors de l'établissement d'une liaison client-
serveur :
• Certificats application OPC UA
Ce type de certificat X.509 identifie l'instance logicielle, l'installation respective d'un
logiciel client ou serveur. Sous l'attribut "Organisation Name", saisissez le nom de
l'entreprise qui utilise le logiciel.
Remarque
Le serveur OPC UA du S7-1500 utilise des certificats application y compris pour le
paramétrage de sécurité "None" (Aucune Security). Cela permet de garantir la
compatibilité avec OPC UA V1.1 et les versions antérieures.
• Certificats logiciel OPC UA

Ce certificat X.509 identifie une version concrète du logiciel client ou serveur. Ce type de
certificat contient des attributs qui décrivent quels tests cette version du logiciel a réussis
lors de la certification par OPC Foundation (ou d'autres laboratoires d'essai habilités). Sous
l'attribut "Organisation Name", saisissez le nom de l'entreprise qui a développé ou qui
distribue le logiciel.
Remarque
STEP 7 ne prend pas en charge de certificat logiciel.
Communication
• Certificats utilisateur OPC UA

Ce certificat X.509 identifie l'utilisateur concret qui consulte, par exemple, les données du
processus d'un serveur OPC UA. Ce certificat n'est pas nécessaire lorsque l'utilisateur peut
prouver qu'il en a l'autorisation avec son mot de passe ou lorsqu'un accès anonyme est
configuré.
Remarque
STEP 7 ne prend pas en charge de certificat utilisateur.
Ces certificats sont des certificats d'entité finale : ils identifient par exemple une personne, un
organisme, une entreprise ou l'instance (installation) d'un logiciel.
9.2.4 Création de certificats autosignés
Utiliser le générateur de certificats du client

Beaucoup d'applications client OPC UA ou de SDK sont intégrés dans un exemple
d'application à partir duquel vous pouvez générer des certificats pour le client.
La génération de certificats est décrite en général dans la description de l'application client
OPC UA.
Exemple de client dans l'assistance en ligne

Le OPC UA .NET Client for the SIMATIC S7-1500 OPC UA Server
(https://support.industry.siemens.com/cs/ww/fr/view/109737901) génère au premier
démarrage du programme un certificat logiciel autosigné de l'application client dans le
magasin de certificats Windows. La documentation de cet exemple décrit la procédure pour la
manipulation de ces certificats.
Utiliser le générateur de certificats de TIA Portal

Si vous utilisez un client OPC UA qui ne génère pas de certificat client, vous pouvez créer des
certificats autosignés avec STEP 7.
Pour cela, procédez comme suit :
1. Dans les propriétés de la CPU, double-cliquez sur "<Ajouter>" sous "Protection et sécurité >
Gestionnaire de certificats > Certificats d'appareil".
2. Cliquez sur "Ajouter".
3. Dans la boîte de dialogue "Création d'un nouveau certificat", choisissez comme "Emploi
prévu" l'option "Client OPC UA".
4. Cliquez sur "OK".
STEP 7 entre automatiquement dans le champ "Autre nom du demandeur" (Subject
Alternative Name) l'URI pour le certificat créé. Ce champ s'appelle, par exemple,
"ApplicationUri" en cas de création de certificats par programme au moyen de la pile .NET
d'OPC Foundation. Il peut avoir d'autres noms dans d'autres outils de création de certificats.
Voir aussi
Manipulation des certificats de client de la CPU S7-1500 (Page 1)
Communication
9.2.5 Créer soi-même une paire de clés PKI et des certificats

Ce chapitre ne vous est utile que si vous utilisez un client OPC UA qui n'est pas en mesure de
générer lui-même une paire de clés PKI et un certificat de client. Dans ce cas, vous pouvez,
avec OpenSSL, créer une clé privée et une clé publique, générer un certificat X.509 et signer
ce certificat vous-même.
Utilisation de OpenSSL
OpenSSL est un outil pour la sécurité de la couche de transport (TLS) que vous pouvez utiliser
pour créer des certificats. Vous pouvez également utiliser d'autres outils, par exemple XCA,
un logiciel de gestion de clés avec interface utilisateur graphique, pour une meilleure vue
d'ensemble sur les certificats créés.
Procédez comme suit pour utiliser OpenSSL sous Windows :
1. Installez OpenSSL sous Windows. Si vous utilisez une version 64 bits du système
d'exploitation, installez OpenSSL dans le répertoire "C:\OpenSSL-Win64", par exemple. Vous
pouvez télécharger OpenSSL-Win64 auprès de différents fournisseurs de logiciels Open
Source.
2. Créez un répertoire, par exemple "C:\demo".
3. Ouvrez l'invite de commandes. Pour ce faire, cliquez sur "Démarrer" (Start) et saisissez "cmd"
ou "Invite de commandes" dans le champ de recherche. Dans la liste de résultats, cliquez
avec le bouton droit de la souris sur "cmd.exe" ou sur "Invite de commandes" et exécutez le
programme en tant qu'administrateur. Windows ouvre l'invite de commandes.
4. Passez au répertoire "C:\demo". Saisissez pour cela la commande suivante : "cd C:\demo".
5. Activer les variables d'environnement suivants :
– set RANDFILE=c:\demo\.rnd
– set OPENSSL_CONF=C:\OpenSSL-Win64\bin\openssl.cfg
La figure suivante montre l'invite de commande avec les commandes :
6. Démarrez maintenant OpenSSL. Si OpenSSL a été installé dans le répertoire C:\OpenSSL-

Win64 , saisissez : C:\OpenSSL-Win64\bin\openssl.exe. La figure suivante montre l'invite de
commande avec la commande :
Communication
7. Générez une clé privée. Enregistrez la clé dans le fichier "myKey.key". Dans l'exemple, la
longueur de la clé est de 1 024 bits ; dans la partique, utilisez 2 048 bits pour plus de
sécurité de RSA. Saisissez la commande suivante : "genrsa -out myKey.key 2048" ("genrsa -
out myKey.key 1024" dans l'exemple). La figure suivante montre l'invite de commandes
avec la commande et la sortie de OpenSSL :
8. Créez une demande CSR (Certificate Signing Request), c'est-à-dire une demande de
signature de certificat. Saisissez pour cela la commande suivante : "req -new -key myKey.key
-out myRequest.csr". Pendant l'exécution de cette commande, OpenSSL vous demande
quelques renseignements sur votre certificat :
– Country Name : par exemple "DE" pour Allemagne, "FR" pour France.
– State or Province Name : par "Bavière".
– Location Name : par exemple "'Augsbourg".
– Organisation Name : Entrez ici le nom de votre entreprise.
– Organisational Unit Name : par exemple "IT"
– Common Name : par exemple "Client OPC UA de la machine A"
– Email Address :
Remarque
Remarque concernant la CPU S7-1500 en tant que serveur avec la version de firmware
V2.5
Dans la version V2.5 (et uniquement cette version) des CPU S7-1500, l'adresse IP du
programme client doit figurer dans le champ "Autre nom du demandeur" (Subject Alternative
Name) du certificat créé, sinon, la CPU n'acceptera pas le certificat.
Vos informations sont insérées dans le certificat. La figure suivante montre l'invite de
commandes avec la commande et la sortie de OpenSSL :
La commande crée dans le répertoire C:\demo un fichier contenant la demande CSR

(Certificate Signing Request ), "myRequest.csr" dans l'exemple.
Communication
Utilisation de la demande CSR

Vous pouvez utiliser la CSR de deux manières différentes :
• Vous envoyez la demande CSR à une autorité de certification (CA). Pour cela, tenez
compte des indications concernant l'autorité de certification correspondante. L'autorité de
certification (CA) vérifie vos indications et votre identité (authentification) et signe le
certificat avec sa clé privée. Vous recevez le certificat X.509 signé et vous l'utilisez pour
OPC UA, HTTPS ou Secure OUC (secure open user communication), par exemple. Vos
partenaires de communication vérifient au moyen de la clé publique de l'autorité de
certification si votre certificat a vraiment été émis et signé par cette autorité (c'est-à-dire si
l'autorité de certification a validé vos informations figurant sur le certificat).
• Vous signez la demande CSR vous-même. Utilisez pour cela votre clé privée. L'étape
suivante décrit cette possibilité.
Signer le certificat soi-même

Saisissez la commande suivante pour créer et signer votre certificat vous-même (certificat
autosigné) : "x509 -req -days 365 -in myRequest.csr -signkey myKey.key -out
myCertificate.crt".
La figure suivante montre l'invite de commande avec la commande et la sortie de OpenSSL :
La commande crée un certificat X.509 avec les attributs que vous avez transmis avec la
demande CSR ("myRequest.csr" dans l'exemple) et une durée de validité d'un an (-days 365),
par exemple. De plus, la commande signe le certificat avec votre clé privée ("myKey.key" dans
l'exemple). Vos partenaires de communication peuvent vérifier au moyen de votre clé
publique (contenue dans votre certificat) que vous êtes en possession de la clé privée
correspondant à cette clé publique. Cela garantit également que votre clé publique n'a subi
aucune manipulation frauduleuse de la part d'un pirate informatique.
Avec un certificat auto-signé, vous confirmez vous-même que vos données figurant sur le
certificat sont correctes. Il n'existe aucune autorité indépendante qui authentifie vos
données.
Voir aussi
Communication
9.2.6 Transmission sécurisée de messages
Etablissement de liaisons sécurisées sur OPC UA

OPC UA utilise des liaisons sécurisées entre un client et un serveur. Pour cela, OPC UA vérifie
l'identité des partenaires de communication. Pour authentifier le client et le serveur, OPC UA
se sert de certificats conformes à la norme X.509-V3 de l'UIT (International
Telecommunication Union). Exception : avec la Stratégie de sécurité "Aucune Security", la
liaison établie n'est pas sécurisée.
Mode de sécurité des messages

OPC UA utilise les stratégies de sécurité (Security Policys ) suivantes pour protéger les
messages :
• Aucune sécurité
Aucun message n'est sécurisé. Pour utiliser cette Security Policy, établissez une liaison à
un nœud d'extrémité None d'un serveur.
• Signature
Tous les messages sont signés. Cette mesure permet de vérifier l'intégrité de tous les
messages reçus. D'éventuelles manipulations sont identifiées. Pour utiliser cette Security
Policy, établissez une liaison à un nœud d'extrémité de signature d'un serveur.
• Signature et cryptage
Tous les messages sont signés et cryptés. Cette mesure permet de vérifier l'intégrité de
tous les messages reçus. D'éventuelles manipulations sont identifiées. En outre, aucun
pirate informatique ne peut lire le contenu du message (protection de la confidentialité).
Pour utiliser cette Security Policy, établissez une liaison à un nœud d'extrémité de
signature et de cryptage d'un serveur.
Les noms des stratégies de sécurité contiennent aussi le nom des algorithmes utilisés.
Exemple : "Basic256Sha256 - Signer crypter" signifie : Nœud d'extrémité sécurisé, prend en
charge une série d'algorithmes pour le hachage 256 bits et le cryptage 256 bits.
Communication
Couches requises
La figure suivante montre les trois couches, Couche Transport, Secure Channel et Session qui
sont toujours requises pour l'établissement d'une liaison.
Figure 9-6 Couches requises : Transport, Secure Channel et Session
• Couche transport :
Cette couche envoie et reçoit les messages. OPC UA fait recours à un protocole optimisé
de transmission de données binaires basé sur TCP à cet effet. La couche transport est la
base du Secure Channel suivante.
• Secure Channel
Secure Channel reçoit de la couche transport les données fournies et les transmet à
Session. Secure Channel transmet à la couche transport les données de la session à
envoyer.
En mode de sécurité "Signature", Secure Channel signe les données (messages) qui sont
envoyées. Secure Channel vérifie la signature des messages entrants pour identifier
d'éventuelles manipulations.
Pour la Security Policy "Signature et cryptage", Secure Channel signe et crypte les données
à envoyer. Secure Channel décrypte les données reçues. Secure Channel vérifie ensuite la
signature.
Pour la Security Policy "Aucune sécurité", les paquets de message traversent Secure
Channel sans modification (les messages sont envoyés et reçus en clair).
• Session
Session transfère les messages de Secure Channel à l'application ou reçoit de l'application
des messages à émettre. L'application utilise les valeurs du processus ou fournit les
valeurs.
Communication
Établissement de Secure Channel

Secure Channel est établie de la manière suivante :
1. Le serveur commence à établir Secure Channel, lorsqu'il reçoit la requête correspondante du
client. Cette requête est soit signée, soit signée et cryptée, ou bien le message est envoyé en
clair (mode de sécurité du nœud d'extrémité sélectionné sur le serveur). Avec "Signature" et
"Signature et cryptage", le client envoie un "Secret" (un nombre aléatoire) avec la requête.
2. Le serveur valide le certificat client (non crypté dans la requête) et vérifie l'identité du client.
Si le serveur fait confiance au certificat du client :
– il décrypte le message et vérifie la signature ("Signature et cryptage")
– ou il vérifie juste la signature ("Signature")
– ou il laisse le message inchangé ("Aucune sécurité").
3. Il envoie ensuite une réponse au client (sécurisée de la même façon que la requête). La
réponse contient le secret du serveur. Le client et le serveur calculent une clé symétrique à
partir du secret client et serveur. L'établissement de Secure Channel est alors terminé.
La clé symétrique est maintenant utilisée pour signer et crypter les messages (à la place des
clés privée et publique du client et du serveur).
Établissement de session
La session est établie de la manière suivante :
1. Le client démarre l'établissement de session en envoyant une demande
CreateSessionRequest au serveur. Ce message contient un Nonce, c'est-à-dire un nombre
aléatoire à usage unique. Le serveur doit signer ce nombre aléatoire (Nonce) pour prouver
qu'il est vraiment le détenteur de la clé privée. associée au certificat que le serveur a utilisé
pour établir Secure Channel. Ce message (et tous les suivants) est sécurisé conformément
aux paramètres de sécurité du nœud d'extrémité choisi sur le serveur (stratégies de sécurité
Security Policys sélectionnées).
2. Le serveur répond avec la réponse CreateSession Response. Ce message contient la clé
publique du serveur ainsi que le Nonce signé. Le client vérifie le Nonce signé.
3. Quand le serveur a réussi le test, le client lui envoie une demande SessionActivateRequest.
Ce message contient les indications nécessaires pour authentifier l'utilisateur :
– soit le nom d'utilisateur et le mot de passe,
– soit le certificat X.509 de l'utilisateur (pas pris en charge dans STEP 7),
– soit aucune donnée (quand un accès anonyme est configuré).
4. Lorsque l'utilisateur possède les droits nécessaires, le serveur envoie un message
(ActivateSessionResponse) en retour au client. La session est alors activée.
La liaison sécurisée entre client et serveur OPC UA est établie.
Établissement d'une liaison avec les blocs fonctionnels PLCopen

La spécification PLCopen a défini une série de blocs fonctionnels CEI 61131 pour les clients
OPC UA. L'instruction UA_Connect initie aussi bien une Secure Channel qu'une session selon
le modèle décrit ci-dessus.
Communication
9.2.7 Gestion des certificats avec Global Discovery Server (GDS)
9.2.7.1 Gestion automatisée des certificats avec GDS

À partir de la version de firmware V2.9, le serveur OPC UA de la CPU S7-1500 prend en charge
les services de gestion de certificats qu'un serveur GDS (Global Discovery Server) peut utiliser,
par exemple.
Les fonctions de gestion push GDS permettent de mettre automatiquement à jour les
certificats OPC UA, les listes de confiance et les listes de révocation de certificats (CRL) pour le
serveur OPC UA de la CPU S7-1500. L'automatisation de la gestion de certificats permet
d'économiser le travail manuel nécessaire à la reconfiguration de la CPU, p. ex. après
expiration de la durée de validité d'un certificat et un nouveau chargement de la CPU. Les
fonctions de gestion push GDS permettent en outre de transférer les listes et certificats mis à
jour lorsque la CPU est dans les états de fonctionnement ARRÊT et MARCHE.
Le modèle d'information de la gestion de certificats est spécifié dans la spécification OPC UA
Part 12 (OPC 10000-12: OPC Unified Architecture, Part 12: Discovery and Global Services).
Les sections ci-après donnent une vue d'ensemble générale des Global Discovery Services
ainsi que des fonctions de mise à jour automatisée des certificats prises en charge à partir de
TIA Portal V17 / CPU avec version de firmware V2.9.
Discovery Server
Un client OPC UA a besoin, pour se connecter à un serveur OPC UA, d'informations sur son
point de terminaison, telles que l'URL du point de terminaison et la stratégie de sécurité. Si les
serveurs entrant en ligne de compte dans le réseau sont nombreux, la recherche et la gestion
de ces informations relatives au serveur peuvent être assurées par un Discovery Server.
• Les serveurs OPC UA s'inscrivent auprès du Discovery Server.
• Les clients OPC UA demandent au Discovery Server une liste des serveurs accessibles et se
connectent ensuite au serveur OPC UA souhaité.
Communication
Global Discovery Server (GDS)

Le concept GDS OPC UA permet, d'une part, de configurer des services Discovery couvrant
plusieurs sous-réseaux et, d'autre part, de mettre à disposition des interfaces pour une
gestion centralisée des certificats.
Un Global Discovery Server (GDS) fournit des mécanismes pour la gestion centralisée des
composants suivants :
• certificats signés par une autorité de certification (AC) et certificats autosignés
• Listes approuvées (Trusted Lists) et listes de révocation des certificats (Certificate
Revocation Lists, CRL)
Un GDS met ainsi à disposition un point d'accès à la gestion centralisée des certificats et
assure ainsi les fonctions d'un serveur de sécurité des données au sein d'un réseau OPC UA.
La principale application de GDS est la gestion de certificats signés par une CA avec les CRL
correspondantes, ce qui couvre les tâches suivantes :
• création initiale d'un certificat d'application OPC UA
• mise à jour régulière de la liste de confiance (Trust List) et des CRL
• renouvellement du certificat d'application OPC UA
Gestion des certificats

La gestion des certificats a pour fonction d'automatiser la gestion et la distribution de
certificats ainsi que de listes de confiance pour des applications OPC UA.
On distingue à cet égard les rôles suivants :
• Gestionnaire de certificats : application OPC UA qui propose des fonctions de gestion de
certificats
• Destinataire de certificats : application OPC UA qui reçoit les certificats, les listes de
confiance et les listes de révocation de certificats du gestionnaire de certificats.
Il existe deux modèles de gestion des certificats : la gestion pull et la gestion push.
• Dans la gestion pull, l'application OPC UA agit comme client du serveur GDS et utilise des
méthodes de gestion de certificats pour requérir la mise à jour des certificats et des listes
de confiance.
• Dans la gestion push, l'application OPC UA agit comme serveur et fournit des méthodes à
un GDS OPC UA comme client OPC UA. Le GDS, dans son rôle de gestionnaire de
certificats, utilise ces méthodes pour transmettre ("push") des certificats et des listes
approuvées, voir les explications du concept de mise à jour automatisée de certificats ci-
dessous.
Dans un premier temps, la CPU S7-1500 à partir de la version de firmware V2.9 prend en
charge uniquement la gestion push pour le serveur OPC UA de la CPU.
Vous ne pouvez pas transférer dans la CPU les certificats pour les instructions client OPC UA
de la CPU par gestion push.
Communication
Configuration du système sous GDS

L'exemple de la figure ci-dessous représente les tâches que les appareils abonnés exécutent
en relation avec un serveur GDS qui met à disposition des fonctions de gestion de certificats.
① Appareil Root CA qui établit des certificats pour le système (ces certificats peuvent également
être transmis par d'autres voies, par ex. par e-mail)
② Serveur GDS OPC UA avec gestionnaire de certificats, qui génère ou signe les certificats d'appa-
reil, gère les listes de confiance et les listes de révocation de certificats (CRL) et écrit les certifi-
cats et les listes dans les appareils (fonction push). Pour la fonction push, cet appareil requiert la
fonctionnalité client OPC UA.
③ Appareil avec application OPC UA qui reçoit des certificats et listes via la fonction "push"
Concept de mise à jour automatisée de certificats pour STEP 7 à partir de la version V17
GDS et un gestionnaire de certificats sont typiquement combinés dans une application - dans
la figure ci-dessous il s'agit cependant de deux composants distincts.
Des appareils tels que des clients OPC UA "normaux" conviennent aussi comme gestionnaire
de certificats, à condition qu'ils prennent en charge le type de données Bytestring nécessaire
pour la transmission de certificats, comme par ex. une CPU S7-1500 à partir de la version de
firmware V2.9 comme client OPC UA ou l'outil UA Expert (Unified Automation) avec Plugin
GDS.
En tant que destinataire de certificats, le serveur OPC UA de la CPU S7-1500 met à disposition
les méthodes et attributs standardisés requis par le biais desquels les clients OPC UA peuvent
écrire et lire les certificats, les listes de confiance et les listes de révocation de certificats.
Le rôle principal de la CPU S7-1500 dans le contexte de serveur OPC UA réside dans la
description de la fonction push, contrairement au mode habituel de transfert de certificats sur
la CPU : Par chargement de la configuration matérielle.
La figure ci-dessous montre comment les certificats et les listes pour OPC UA peuvent être
transférés dans une CPU S7-1500 à partir du firmware V2.9 :
• Par chargement de la configuration matérielle à l'état ARRÊT de la CPU ; les certificats font
partie de la configuration matérielle.
• Ou par des méthodes push GDS à l'état de fonctionnement MARCHE ou ARRÊT de la CPU.
Communication
Une utilisation simultanée des deux méthodes de transfert n'est pas possible.
Voir aussi
Certificats sur OPC UA (Page 1)
9.2.7.2 Quantité de données admissible pour la fonction push
Nombre de certificats pour la fonction push

Une CPU S7-1500 possède pour la fonction push OPC UA une quantité de données admissible
de 62 entrées de liste de confiance, indépendamment du type avec la version de fimware
V2.9.
Une entrée de liste de révocation (LRC) est aussi importante qu'une entrée dans la liste des
certificats approuvés.
Taille des éléments pour la fonction push (par ex. certificats)

4096 octets max.
Exemple
Vous voulez garantir un accès au serveur OPC UA pour 62 clients OPC UA max. et remplir la
liste de confiance en conséquence.
Si vous copiez une entrée de la liste de révocation dans la liste de confiance, vous ne pouvez
plus faire confiance qu'à 61 certificats client max.
Il est impossible de transférer des certificats supplémentaires pour OPC UA en chargeant la
configuration matérielle dans la CPU.
Communication
Conseil
Pour minimiser le nombre de certificats requis, nous vous recommandons de faire signer si
possible les certificats client OPC UA par la même autorité de certification.
Dans ce cas, la CPU requiert en tant que serveur OPC UA uniquement le certificat CA
correspondant et les LRC. Avec ces éléments, le serveur OPC UA peut alors vérifier tous les
certificats de client signés par l'autorité de certification. Vous n'avez alors plus besoin
d'ajouter les certificats de client individuellement dans la liste de confiance.
9.2.7.3 Définition et chargement des paramètres GDS

Les sections ci-après décrivent les réglages nécessaires pour la mise à jour des certificats.
Conditions
• STEP 7 (TIA Portal) à partir de V17
• CPU S7-1500 à partir de la version de firmware V2.9
• L'heure/la date de la CPU sont définies (valable en général pour la communication à base
de certificats)
• Le serveur OPC UA est activé
• Au moins un nœud d'extrémité avec la stratégie de sécurité "Signature et cryptage" doit
être configuré et le partenaire doit utiliser ce nœud d'extrémité
• Un utilisateur authentifié avec des droits fonctionnels suffisants a été paramétré
L'utilisateur doit posséder un rôle qui comporte le droit fonctionnel "Gérer des certificats".
Ce droit fonctionnel doit par ailleurs répondre aux conditions suivantes :
– La protection du projet doit être activée dans le navigateur du projet : Navigateur du
projet : "Réglages Security > Paramètres > Protection du projet".
– Dans la zone "OPC UA > Général" des paramètres de la CPU, le paramètre suivant de la
gestion générale des utilisateurs doit être activé : "Activer une gestion des utilisateurs
supplémentaire via les paramètres de sécurité du projet".
La manière de paramétrer les droits de fonction est décrite au paragraphe Utilisateur et rôles
avec les droits de fonction OPC UA (Page 1).
Activer GDS
Si les conditions ci-dessus sont remplies, il faut encore activer GDS :
1. Naviguez dans la fenêtre d'inspection (paramètres de la CPU) jusqu'à la zone "OPC UA >
Serveur > Général".
2. Activez l'option "Activer les Global Discovery Services (Push)"
Communication
Définir la mémoire de certificats utilisée

Les certificats qui sont gérés par GDS sont enregistrés dans une autre zone de mémoire que
les certificats qui sont chargés via TIA Portal (STEP 7). Si GDS est activé, le serveur OPC UA de
la CPU devrait aussi se servir dans le magasin de certificats dont les certificats sont gérés à
l'exécution.
1. Naviguez dans les paramètres de la CPU jusqu'à la zone "OPC UA > Serveur > Sécurité >
Certificats".
2. Sélectionnez l'option "Certificats qui sont gérés en cours d'exécution par le serveur de
gestion des certificats".
L'autre option (Utiliser des certificats configurés et téléchargés dans TIA Portal) utilise les
certificats que TIA Portal charge dans la CPU avec la configuration à l'état ARRÊT de la CPU.
Cette mémoire de certificats ne permet pas d'actualiser les certificats et listes de confiance
durant l'exécution.
Chargement de la CPU
Lors du chargement de la configuration sur la CPU, vous pouvez supprimer, avant le
chargement, les certificats qui sont gérés via GDS. Lorsque vous validez la suppression, le
chargement est suivi d'une phase de mise à disposition (voir section sur la mise en service).
Si vous chargez la carte mémoire hors de la CPU (lecteur de carte mémoire), cette mémoire
de certificats est effacée.
Si les services GDS (push) sont activés et qu'il n'y a pas de certificats de type push, le serveur
OPC UA ne dispose ni de son propre certificat ni de listes de confiance et de révocation de
certificats.
Voir aussi
Mise en service GDS (Page 1)
9.2.7.4 Mise en service GDS

Part 12 de la spécification OPC UA établit une distinction, lors de la gestion des certificats,
entre une phase de mise à disposition (provisioning phase) et une phase d'exécution (run
time phase).
Pendant la phase de mise à disposition, un GDS ou un client OPC UA fournit des listes de
confiance et des listes de révocation de certificats initiales au serveur OPC UA de la CPU. Dans
cette phase, le serveur OPC UA de la CPU accepte tous les certificats et toutes les listes qui lui
sont proposés ; cela est comparable à l'option "Clients de confiance" pour le serveur OPC UA
qui entraîne l'acceptation de tous les certificats client à l'exécution. Ce n'est qu'ainsi qu'il est
possible d'établir une connexion avec des clients inconnus du serveur, c'est-à-dire des clients
qu'il ne peut pas authentifier par des certificats ou des listes de confiance existants avant
d'avoir reçu le certificat client correspondant ou la liste de confiance correspondante.
La phase de mise à disposition se distingue par le fait qu'elle est peu sûre (Security limitée).
C'est pourquoi elle est signalée par l'activation de la LED Maintenance et par une entrée dans
le tampon de diagnostic (Maintenance demanded).
En phase d'exécution, les CRL par exemple sont actualisées et les certificats et listes de
confiance renouvelés. Les communications dans cette phase sont sécurisées (secure).
Communication
Condition
Seuls les utilisateurs autorisés avec des droits de fonction suffisants peuvent établir une
connexion dans la phase de mise à disposition. Les utilisateurs doivent avoir un rôle avec le
droit fonctionnel "Gérer les certificats".
Voir aussi Définition et chargement des paramètres GDS (Page 1).
Règles pour la phase de mise à disposition

Pendant la phase de mise à disposition, le serveur OPC UA de la CPU est incapable
d'authentifier les clients OPC UA qui tentent d'établir une connexion. C'est pourquoi il faut
appliquer les règles suivantes :
• Veillez à ce que l'environnement soit sûr, p. ex. accès à la CPU uniquement permis au
technicien de mise en service. Vérifiez que ce sont les appareils prévus qui communiquent
entre eux.
• Limitez la durée de cette phase.
La phase de mise à disposition de la CPU est signalée par la CPU via l'activation de la LED
Maintenance et par une entrée correspondante dans le tampon de diagnostic (Maintenance
demanded).
Communication
Déroulement de la phase de mise à disposition

Le déroulement de la phase de mise à disposition est esquissé ci-après.
Communication
Passage en phase de mise à disposition

La CPU passe automatiquement en phase de mise à disposition après un démarrage du
serveur OPC UA si l'une des conditions ci-après est remplie :
• Le certificat de serveur OPC UA est le certificat initialement généré et auto-signé par la
CPU et n'a pas encore été remplacé par un certificat de serveur valide.
• La liste de confiance (liste des clients dignes de confiance) est vide.
Le certificat de serveur OPC UA généré par la CPU contient les principaux paramètres du
serveur OPC UA et il est régénéré, la clé privée comprise, à chaque démarrage du serveur OPC
UA après la MISE SOUS TENSION, jusqu'à ce qu'un certificat de serveur valide soit disponible.
C'est pourquoi le démarrage du serveur OPC UA après une MISE SOUS TENSION peut prendre
un certain temps.
Après le chargement de la configuration matérielle et selon les paramètres définis pour le
chargement, la mémoire des certificats pouvant être mis à jour en cours d'exécution est
supprimée ou les certificats sont conservés. Cela signifie que, si un GDS est activé et que le
magasin de certificats a été supprimé, la CPU est en phase de mise à disposition après le
chargement de la configuration matérielle.
Diagnostic de la phase de mise à disposition

En plus de la LED Maintenance, le modèle d'adresse pour fonctionnalité GDS dispose de deux
nœuds qui servent à signaler la phase de mise à disposition du serveur OPC UA de la CPU :
Vous ne pouvez utiliser les deux nœuds à des fins de diagnostic, comme indiqué dans la
figure, que lorsque les conditions requises pour GDS sont remplies (sécurité des points finals
"Signé et crypté", ainsi que droits fonctionnels d'administrateur disponibles).
ProvisioningModeEnabled : Indique qu'une phase de mise à disposition est prise en charge.
ProvisioningModeActive : Indique que le serveur OPC UA de la CPU se trouve en phase de
mise à disposition.
Communication
Fin de la phase de mise à disposition

La CPU met automatiquement fin à la phase de mise à disposition lorsque les conditions
suivantes sont remplies :
• Le certificat généré et autosigné par la CPU pour la phase de mise à disposition a été
écrasé par un certificat de serveur valide. Ce certificat de serveur valide peut être un
certificat autosigné ou signé par une autorité de certification.
• La liste approuvée dans la CPU n'est pas vide, c'est-à-dire que des certificats de client des
clients OPC UA approuvés ou des certificats CA pour la vérification des certificats client
sont présents.
Si le client OPC UA transmet un certificat signé CA et qu'il ajoute également le certificat CA à
la liste de confiance, le serveur OPC UA de la CPU peut accepter automatiquement tous les
autres certificats de clients OPC UA qui ont été signés par la même autorité de certification.
Requête d'un certificat de serveur valide

Le serveur OPC UA de la CPU reçoit un certificat de serveur valide au cours des étapes
suivantes :
1. Un gestionnaire de certificats (client OPC UA) appelle la méthode "CreateSigningRequest"
pour requérir un certificat de serveur avec une Certificate Signing Request (CSR).
2. Cette CSR doit être signée par une autorité de certification (Certificate Authority).
3. La CSR signée doit ensuite être retournée comme certificat de serveur au serveur OPC UA de
la CPU.
Le serveur OPC UA de la CPU met cette méthode à disposition à condition que le client
possède le droit fonctionnel "Gérer les certificats" requis.
La méthode "CreateSigningRequest" autorise les variantes suivantes :
• Mise à jour de certificats sans générer une nouvelle paire de clés (utilisation des clés
internes de la CPU déjà existantes)
• Mise à jour de certificats avec génération d'une nouvelle paire de clés (interne CPU)
Il est en outre possible de générer des certificats avec des paires de clés générées à
l'extérieur.
IMPORTANT
Marche à suivre recommandée pour la génération de certificats
Il convient d'éviter autant que faire se peut le transport de clés privées ; une clé privée ne
doit si possible pas quitter l'appareil.
C'est la raison pour laquelle nous recommandons de générer les certificats sans génération
d'une nouvelle paire de clés ou de générer la paire de clés en interne sur la CPU.
Communication
Générer un certificat sans paire de clés

• La méthode "CreateSigningRequest" retourne une Certificate Signing Request (CSR),
c.-à-d. un fichier (*.csr) contenant des informations spécifiques sur le serveur telles que
nom d'application et URL.
• Hors de la CPU, cette CSR doit être validée, signée et renvoyée comme certificat de serveur
par une autorité de certification (CA).
• Le certificat de serveur doit ensuite être transféré par la méthode "UpdateCertificate" sur la
CPU (par la fonction "push").
Avec cette méthode, la clé ne quitte pas la CPU.
Génération de certificats avec génération interne de la paire de clés

Cette méthode est semblable à celle décrite dans la section précédente si ce n'est qu'une
paire de clés est générée en plus de la CSR. Vous spécifiez dans le paramètre de la méthode
"CreateSigningRequest" qu'elle doit générer une paire de clés.
Avec cette méthode, la clé privée ne quitte pas non plus la CPU.
La génération d'une nouvelle paire de clés constitue une charge énorme pour la CPU. Cette
tâche est traitée avec une priorité inférieure par la CPU dans la zone réservée à la charge de
communication. La durée de cet intervalle de temps dépend de la puissance de la CPU.
Comme la génération de clés entraîne l'utilisation de toute la charge de communication
paramétrée pendant un temps relativement long, configurez la part de la "charge du cycle
due à la communication" de manière à ce que le temps de cycle maximal ne soit pas dépassé
et que des réserves suffisantes soient disponibles. Utilisez pour cela la page de serveur Web
"Diagnostic > Informations d'exécution" de la CPU, par exemple. Cette page donne des
informations sur la charge actuelle due au programme et à la communication et sur le temps
de cycle de votre programme utilisateur. Un régulateur vous permet de gérer les effets d'une
modification de la charge de communication sur le temps de cycle.
Génération de certificats avec génération externe de la paire de clés

La génération de certificats s'exécute par exemple à l'aide d'outils qui permettent de générer
des clés supplémentaires.
Le certificat et les clés sont transférés sur la CPU par la méthode "UpdateCertificate".
Cette démarche est déconseillée pour des raisons de sécurité.
IMPORTANT
Clés différentes pour des systèmes cibles différents
Pour un système de production, utilisez toujours des clés nouvellement générées. Si vous
simulez et testez votre projet sur votre PC avec PLCSIM Advanced, par exemple, n'utilisez en
aucun cas les clés utilisées pour la simulation pour un système de production.
Limitez l'accès aux automates basés sur PC par la configuration d'autorisations appropriées.
Communication
9.2.7.5 Modèle d'adresse pour la gestion de certificats push

La spécification OPC UA Part 12 (OPC 10000-12: Discovery, Global Services) définit des
méthodes et attributs pour serveurs OPC UA qui permettent à GDS et aux clients OPC UA
d'actualiser des certificats et listes de confiance sur le serveur ("gestion de certificats push").
Ces méthodes et attributs se trouvent également dans le modèle d'adresse du serveur OPC
UA.
Dans ce qui suit, la section pertinente est décrite dans le modèle d'adresse du serveur OPC UA
de la CPU S7-1500.
Conditions
Pour visualiser les méthodes et attributs pertinents de la fonctionnalité push GDS, il faut que
les conditions suivantes soient remplies :
• GDS est activé
• La stratégie de sécurité des données prend en charge l'intégrité et la confidentialité des
données par signature et cryptage (Sign & Encrypt)
• Accès avec droit fonctionnel en cours d'exécution "Gérer les certificats".
Modèle d'adresse pour fonctionnalité push GDS

Le modèle d'adresse de la fonctionnalité push GDS correspond au "Information Model for
Push Certificate Management" de la spécification OPC UA OPC 10000-12: Discovery, Global
Services.
Sous le nœud "Configuration du serveur" se trouve la structure suivante :
Communication
Méthodes et attributs d'accès au modèle d'adresse

Vous trouverez dans ce qui suit une description succincte des méthodes et attributs ainsi que
les particularités et restrictions du modèle d'adresse concret de la CPU S7-1500. La
spécification OPC UA nommée ci-dessus contient la description générale.
Vous trouverez à la suite de ce tableau récapitulatif, la description détaillée des différentes
méthodes.
Méthode / attribut (variable) Description

CreateSigningRequest Méthode de génération d'une requête de certificat codée PKCS#10
signée avec la clé privée du serveur OPC UA.
UpdateCertificate Méthode de mise à jour du certificat de serveur pour le serveur OPC
UA
ApplyChanges Méthode d'application d'une modification touchant à la sécurité si
l'attribut "ApplyChangesRequired" a été activé lors de l'exécution
d'une méthode précédemment exécutée.
Remarque
Si un certificat est modifié à la suite de "ApplyChanges", la CPU inter-
rompt les connexions/sessions sécurisées par ce certificat.
Cause : la base des connexions sécurisées – c'est-à-dire le certificat –
n'est plus valable.
GetRejectedList Méthode qui retourne une liste des certificats qui ont été rejetés par
le serveur OPC UA.
Les certificats refusés ne sont pas enregistrés par le serveur OPC UA
des CPU S7-1500. Par conséquent, la méthode renvoie un Array (Re-
jectedList) vide.
ServerCapabilities Variable qui n'est pas prise en charge par le serveur OPC UA de la CPU
S7-1500.
SupportedPrivateKeyFormats Variable qui indique les formats de clé privée autorisés. Pour les CPU
S7-1500 uniquement "PEM" (tableau de chaînes de caractères)
MaxTrustListSize Variable qui indique la taille maximale de la liste de confiance.
MulticastDnsEnabled Variable qui indique si DNS Multicast est pris en charge. Pour les CPU
S7-1500 la valeur est "False".
CertificateGroups Objet (répertoire) qui organise tous les groupes de certificats pris en
charge par le serveur OPC UA. Les groupes de certificats contiennent
les objets qui peuvent être mis à jour dynamiquement en cours d'exé-
cution : Respectivement une liste de confiance et un ou plusieurs
certificats qui sont affectés à une application OPC UA.
Vous trouverez des détails sur la structure de l'objet CertificateGroups,
ainsi que les méthodes et attributs disponibles, au chapitre suivant.
Communication
CreateSigningRequest
Cette méthode possède les paramètres suivants :
Paramètre Type de données Description

[in] certificateGroupId NodeId NodeId de l'objet CertificateGroup. La CPU ne
prend actuellement en charge qu'un groupe de
certificats (DefaultApplicationGroup).
[in] certificateTypeId NodeId Type de certificat requis.
La liste des types de certificat autorisés est
spécifiée par la variable "CertificateTypes" du
groupe de certificats.
Actuellement uniquement le type de certificat
"RsaSha256ApplicationCertificateType".
[in] subjectName String Subject Name qui est requis dans la requête de
certificat. S'il n'est pas spécifié, c'est le Subject
Name courant du certificat qui est utilisé.
[in] regeneratePrivateKey Boolean True : Le serveur génère une nouvelle clé pri-
vée. Cette clé reste enregistrée jusqu'à l'appel
de la méthode de mise à jour de certificats avec
le certificat à signature adéquate.
False : Le serveur utilise la clé privée disponible.
[in] nonce ByteString Nonce supplémentaire pour générer la nouvelle
clé privée (voir regeneratedPrivatKey). Doit
compter au moins 32 octets.
[out] certificateRequest ByteString PKCS #10 - Requête de certificat codé DER.
Method Result Codes
Result Code Description

Bad_InvalidArgument Le certificateTypeId, certificateGroupId ou sub-
jectName n'est pas valide.
Bad_UserAccessDenied L'utilisateur courant ne possède pas les droits
fonctionnels requis.
Communication
UpdateCertificate
Cas d'application :
• Génération de certificats avec CreateSigningRequest. Pas de clé privée mise à disposition.
• Une nouvelle clé privée et un nouveau certificat ont été générés hors du serveur. Les deux
sont mis à jour par UpdateCertificate.
• Certificat généré et signé avec la clé privée du certificat existant. Pas de clé privée mise à
disposition.

[in] certificateGroupId NodeId NodeId de l'objet CertificateGroup. La CPU ne
prend actuellement en charge qu'un groupe de
certificats (DefaultApplicationGroup).
[in] certificateTypeId NodeId Type de certificat requis.
La liste des types de certificat autorisés est
spécifiée par la variable "CertificateTypes" du
groupe de certificats.
Actuellement uniquement le type de certificat
"RsaSha256ApplicationCertificateType".
[in] certificate ByteString Certificat codé DER qui remplace le certificat
existant.
[in] issuerCertificates ByteString Émetteur de certificats
[in] privateKeyFormat String Format de la clé privée. Actuellement seul PEM
est pris en charge. Si la clé privée n'est pas
spécifiée : zéro ou chaîne vide.
[in] privateKey ByteString Clé privée codée comme spécifiée dans priva-
teKeyFormat.
[out] applyChangesRequired Boolean Indique que la méthode "ApplyChanges" doit
être appelée avant l'utilisation du nouveau
certificat.
Method Result Codes

Bad_InvalidArgument certificateTypeId ou certificateGroupId n'est pas
valide.
Bad_CertificateInvalid Le certificat n'est pas valide ou le format n'est pas
pris en charge.
Bad_NotSupported La clé privée n'est pas valide ou le format n'est pas
pris en charge.
Bad_SecurityChecksFailed Une erreur est survenue lors de la vérification de
l'intégrité du certificat.
Apply Changes
La méthode ne possède pas de paramètres.
Communication
Method Result Codes

GetRejectedList
Cette méthode possède les paramètres suivants :

[out] certificates ByteStrings Liste codée DER des certificats rejetés.
La méthode fournit une liste (un Array) vide,
car les certificats refusés ne sont pas enregis-
trés.
Method Result Codes

9.2.7.6 CertificateGroups dans le modèle d'adresse

Les certificats et listes de confiance du serveur OPC UA, mis à jour en cours en cours
d'exécution se trouvent dans le modèle d'adresse, dans l'objet "CertificateGroups" - pour le
serveur OPC UA de la CPU S7-1500 il existe exactement un groupe de certificats nommé
"OpcUaServerGroup".
CertificateGroup dans le modèle d'adresse

La figure suivante montre la structure de l'objet "CertificateGroups" sous le nœud
"ServerConfiguration".
Vous pouvez modifier le Display Name du groupe "OpcUaServerGroup" sous STEP 7 (TIA
Portal) :
1. Naviguez dans la fenêtre d'inspection (paramètres des propriétés de la CPU) jusqu'à la zone
"OPC UA > Serveur > Certificats".
2. Sélectionnez l'option "Utiliser les certificats qui sont gérés en cours d'exécution par le serveur
de gestion des certificats".
3. Modifiez le nom (DisplayName) du groupe de certificats dans le tableau au-dessous.
1 à 64 caractères au format ASCII 7 bits sont autorisés.
Communication
Nœuds "CertificateTypes"
La variable "CertificateTypes" spécifie les NodeIds des types de certificat qui sont affectés à
l'application serveur.
Actuellement seul "RsaSha256ApplicationCertifcateType" est pris en charge.
Noeud "TrustList"
Le nœud de l'objet Listes de confiance (fichier TrustList) définit un type de fichier OPC UA
(Binary encoded stream) qui renseigne sur les certificats et CRL du répertoire "pki
store\trusted/issuer" de la carte mémoire qui peuvent être lus et mis à jour. Ce nœud met à
disposition des méthodes et attributs qui permettent la lecture et la mise à jour.
Ce nœud est une instance du type de données OPC UA "TrustListDataType" structuré comme
suit :

specifiedLists TrustListsMasks Masque de bits qui indique quelles listes con-
tiennent des informations.
trustedCertificates ByteStrings Liste des certificats d'application et certificats
CA dignes de confiance.
trustedCrls ByteStrings CRL pour les certificats de la liste "trustedCerti-
ficates".
issuerCertificates ByteStrings Liste des certificats CA requis pour valider les
certificats signés CA.
issuerCrls ByteStrings CRL des certificats CA dans la liste "issuerCertifi-
cates".
Structure du nœud "TrustList"

Le nœud "TrustList" est structuré comme suit :
Communication
9.3 Utilisation de la CPU S7-1500 comme serveur OPC UA
Méthodes et attributs du nœud "TrustList"

Vous trouverez ci-après une description des nœuds sous "TrustList" qui viennent s'ajouter aux
méthodes du type d'objet Object Type "FileType". Le type "TrustList Type" est dérivé du
"FileType" (voir OPC 10000-5: OPC Unified Architecture, Part 5: Information Model).
Méthode / attribut (variable) Description

LastUpdateTime Variable indiquant l'heure de la dernière mise à jour.
OpenWithMasks Méthode qui permet à un client de lire uniquement une
partie de la TrustList.
CloseAndUpdate Méthode permettant de fermer le fichier de la TrustList et
d'appliquer les modifications.
AddCertificate Méthode permettant d'ajouter un seul certificat à la
TrustList.
RemoveCertificate Méthode permettant de supprimer un seul certificat de la
TrustList.
Description des méthodes

Vous trouverez la description des méthodes ainsi que des Result Codes, des attributs et des
types de l'objet TrustList dans la spécification OPC UA Part 12, Discovery and Global Services.
9.3.1 Informations sur le serveur OPC UA des CPU S7-1500
9.3.1.1 Le serveur OPC UA des CPU S7-1500

Les CPU S7-1500 sont équipées d'un serveur OPC UA à partir de la version de firmware V2.0.
En plus des CPU S7-1500 standard, cela concerne également les CPU S7-1500F, S7-1500T,
S7-1500C, S7-1500pro, les CPU ET 200SP, le contrôleur logiciel SIMATIC S7-1500 et PLCSIM
Advanced.
Conventions Par "CPU S7-1500", on entend également les variantes CPU citées ci-dessus.
Communication
Notions de base sur le serveur OPC UA de la CPU S7-1500

L'accès au serveur OPC UA de la CPU est possible via toutes les interfaces Ethernet intégrées
de la CPU S7-1500.
Les CP permettent d'accéder directement au serveur OPC UA de la CPU par le biais du bus
interne du système d'automatisation dans les conditions suivantes :
• Configuration avec TIA Portal à partir de la version V16
• CPU S7-1500 à partir de la version de firmware V2.8, ainsi que CP 1543-1 à partir de la
version de firmware V2.2
Pour la configuration, voir Accès aux applications OPC UA (Page 1).
Les CM ne permettent pas d'accéder directement au serveur OPC UA de la CPU par le biais du
bus interne du système d'automatisation.
Le serveur stocke les variables API autorisées et d'autres informations sous forme de nœuds
pour l'accès par les clients (voir Configurer l'accès aux variables API (Page 1)). Ces nœuds sont
interconnectés et forment un réseau. OPC UA définit des points d'entrée dans ce réseau
(Well-known Nodes), qui permettent de naviguer jusqu'aux nœuds subordonnés.
Un client OPC UA vous permet de lire, de visualiser ou d'écrire des valeurs de variables du
programme API et d'appeler les méthodes mises à disposition par le serveur. À partir de la
version de firmware 2.5, vous pouvez implémenter des méthodes, voir Informations utiles sur
les méthodes de serveur (Page 1).
Communication
Classes de nœud
Les serveurs OPC UA mettent des informations à disposition sous forme de nœuds (Nodes).
Un nœud peut être par exemple un objet, une variable, une méthode ou une propriété.
L'exemple ci-dessous montre la plage d'adresses du serveur OPC UA d'une CPU S7-1500
(extrait du client OPC UA "UaExpert" de Unified Automation).
Figure 9-7 Exemple de plage d'adresses du serveur OPC UA d'une CPU S7-1500
La variable "MyValue" est sélectionnée (grisée) dans la figure ci-dessus.

Cette variable se trouve sous le nœud "Memory", qui possède la classe de nœud "Object".
"Memory", quant à lui, se trouve sous le nœud "PLC_1" (également un Object).
Communication
Plage d'adresses
Les nœuds sont reliés entre eux par des références, par exemple par la référence
"HasComponent" qui traduit le rapport hiérarchique existant entre un nœud et ses nœuds
subordonnés. Les nœuds constituent, par leurs références, un réseau qui peut par exemple
prendre la forme d'une arborescence.
Un réseau composé de nœuds est également appelé plage d'adresses. Tous les nœuds dans la
plage d'adresses sont accessibles à partir de la racine.
9.3.1.2 Nœuds d'extrémité du serveur OPC UA

Les nœuds d'extrémité du serveur OPC UA définissent le niveau de sécurité pour une liaison.
Vous devez procéder dans le noeud d'extrémité aux paramétrages correspondant à
l'utilisation prévue ou au niveau de sécurité souhaité pour la liaison.
Différents paramètres de sécurité

Avant l'établissement d'une liaison sécurisée les clients OPC UA demandent au serveur avec
quels paramètres de sécurité il est possible d'établir des liaisons. Le serveur répond par une
liste des paramètres de sécurité (nœuds d'extrémité) qu'il propose.
Structure des nœuds d'extrémité

Les nœuds d'extrémité se composent des éléments suivants :
• Identificateur pour OPC : "opc.tcp"
• Adresse IP : 192.168.178.151 (dans l'exemple)
• Numéro de port pour OPC UA : 4840 (port standard)
Le numéro de port est configurable.
• Paramètre de sécurité pour messages (Message Security Modus) : None, Sign,
SignAndEncrypt.
• Procédé de chiffrement et de hachage (Security Policy) : None, Basic128Rsa15, Basic256,
Basic256Sha256 (dans l'exemple).
Communication
La figure suivante montre le programme "UA Sample Client" de OPC Foundation.

Le client a établi une liaison sécurisée au serveur OPC UA d'une CPU S7-1500, au nœud
d'extrémité "opc.tcp://192.168.178.151:4840 - [SignAndEncrypt: Basic256Sha256:Binary]".
Les paramètres de sécurité "SignAndEncrypt:Basic256Sha256" sont contenus dans le nœud
d'extrémité.
Remarque
Sélectionner un nœud d'extrémité avec la stratégie de sécurité la plus élevée possible
Sélectionnez pour les nœuds d'extrémité une stratégie de sécurité (Security Policy)
suffisamment élevée pour l'application et désactivez la stratégie de sécurité la plus faible sur
le serveur OPC UA.
Un certificat Sha256 est nécessaire pour les nœuds d'extrémité les plus sécurisés
(Basic256Sha256) du serveur OPC UA de la CPU S7-1500.
Figure 9-8 Programme "UA Sample Client" de l'OPC Foundation.
L'établissement d'une liaison vers un nœud d'extrémité du serveur n'est réalisé que si le client
OPC UA remplit les paramètres de sécurité requis pour le nœud d'extrémité correspondant.
Communication
Informations fournies par le serveur OPC UA

Les serveurs OPC UA fournissent de nombreuses informations :
• Les valeurs des variables API et des éléments de DB auxquelles les clients ont accès.
• Les types de données de ces variables API et éléments de DB.
• Les données concernant le serveur OPC UA lui-même et la CPU.
Les clients obtiennent ainsi une vue générale des informations qu'ils peuvent lire de façon
ciblée. Aucune connaissance préalable du programme de l'automate programmable et de la
réserve de données de la CPU n'est nécessaire. Il n'est pas nécessaire de s'informer auprès du
développeur du programme de l'automate quand il s'agit de lire des variables API. Sur le
serveur même sont stockées toutes les informations nécessaires (par exemple les types de
données des variables API).
Affichage des informations du serveur OPC UA

Les options suivantes sont disponibles :
• En ligne : Faites afficher toutes les informations disponibles sur le serveur OPC UA durant
l'exécution. Pour cela naviguez dans (parcourez) la plage d'adresses du serveur.
• Hors ligne : Vous exportez un fichier XML basé sur le modèle XML de l'OPC Foundation.
Les méthodes de serveur que vous avez créées vous-même (instance FB pouvant être
appelée par un client OPC UA) sont également exportées à partir de STEP 7 V15.1, voir
Fournir des méthodes sur le serveur OPC UA (Page 1).
• Hors ligne avec l'interface d'application Openness : Dans votre programme, vous utilisez
l'interface de programmation d'application ( API, Application programming interface) de
TIA Portal pour exécuter la fonction d'exportation de toutes les variables API lisibles par
OPC UA. Pour cela, .NET Framework 4.0 est requis, voir TIA Portal Openness, Automatiser
des projets SIMATIC à l'aide de scripts
• Si vous connaissez déjà la syntaxe et le programme de l'automate, vous pouvez accéder
sans recherche préalable au serveur OPC UA.
Communication
9.3.1.3 Comportement du serveur OPC UA en service
Le serveur OPC UA pendant le fonctionnement

Le serveur OPC UA de la CPU S7-1500 démarre lorsque vous activez le serveur et une fois le
projet chargé dans la CPU.
La marche à suivre pour activer le serveur OPC UA est décrite ici.
Comportement à l'état de fonctionnement ARRÊT de la CPU

L'exécution d'un serveur OPC UA se poursuit même quand la CPU passe à l'état ARRET. Le
serveur OPC UA continue de répondre normalement aux requêtes des clients OPC UA.
Le comportement du serveur en détail :
• Si vous interrogez les valeurs des variables API, vous recevez les valeurs qui étaient
actuelles avant l'activation du passage ou le passage de la CPU à l'état de fonctionnement
"ARRET".
• Si vous écrivez des valeurs sur le serveur OPC UA, elles sont prises en charge par le serveur
OPC UA.
Mais la CPU ne traite pas ces valeurs, car le programme utilisateur n'est pas exécuté à l'état
ARRET.
La lecture de valeurs écrites à l'arrêt du serveur OPC UA de la CPU par un client OPC UA
reste néanmoins possible.
Au redémarrage, la CPU écrase les valeurs écrites à l'arrêt avec les valeurs de démarrage
des variables API.
• Si vous appelez une méthode de serveur, vous recevez le message d'erreur
16#00AF_0000 (BadInvalidState) car la méthode de serveur (programme utilisateur) n'est
pas exécutée.
• Les connexions au serveur OPC UA sont maintenues lors d'une transition de mode (STOP >
RUN ou RUN > STOP). Exception : Les données pertinentes pour l'OPC UA sont chargées,
voir prochain paragraphe.
Communication
Le chargement de la CPU peut influer sur le serveur OPC UA

Si vous chargez une CPU alors que le serveur OPC UA s'exécute, il peut s'avérer nécessaire
d'arrêter et de redémarrer le serveur, selon les objets chargés. Dans ce cas, les liaisons actives
sont interrompues et doivent être rétablies après le redémarrage du serveur.
La durée du redémarrage dépend notamment des paramètres suivants :
• l'envergure de la structure de données
• le nombre de variables visibles dans la plage d'adresses OPC UA
• le réglage de la définition de type de données à compatibilité descendante selon la
spécification OPC UA jusqu'à V1.03 (TypeDictionary activé)
• les paramétrages de la charge due à la communication et du temps de cycle minimum
(plus d'informations à ce sujet ici (Page 1))
Pour les versions de firmware de la CPU antérieures à V2.8, le serveur OPC UA était arrêté à
chaque chargement dans la CPU, puis redémarré.
À partir de la version de firmware V2.8, le comportement du serveur OPC UA a été optimisé
de la manière suivante :
• Lors du chargement d'objets à l'état de fonctionnement Arrêt de la CPU, le serveur OPC UA
est toujours systématiquement arrêté puis redémarré. STEP 7 n'affiche pas
d'avertissement dans ce cas.
• Lors du chargement d'objets à l'état de fonctionnement MARCHE de la CPU, le serveur OPC
UA est arrêté uniquement si les objets chargés sont significatifs pour OPC UA ou
susceptibles de l'être. Après une réinitialisation due aux données OPC UA modifiées, le
serveur OPC UA redémarre.
Avant de charger les objets significatifs pour OPC UA dans la CPU et d'arrêter le serveur
OPC UA, STEP 7 affiche un avertissement dans la boîte de dialogue d'aperçu du
chargement. Vous pouvez décider alors si un redémarrage du serveur est compatible avec
le processus en cours d'exécution ou si vous voulez interrompre le chargement. Ces
avertissement ne sont affichés que si un serveur OPC UA s'exécute. Si le serveur OPC UA
n'est pas activé, les données OPC UA n'ont aucune incidence sur le processus de
chargement.
Exemples
• Vous souhaitez ajouter un bloc de code supplémentaire au programme.
Ni les bloc de données, ni les entrées, sorties, mémento, temporisations ou compteurs ne
sont concernés.
Réaction lors du chargement : un serveur OPC UA en cours d'exécution n'est pas
interrompu.
• Vous souhaitez charger un nouveau bloc de données et vous avez marqué ce bloc de
données comme non significatif pour OPC UA.
Réaction lors du chargement : un serveur OPC UA en cours d'exécution n'est pas
interrompu.
• Vous voulez écraser un bloc de données.
Réaction lors du chargement : un avertissement s'affiche signalant le redémarrage du
serveur.
Cause : STEP 7 ne peut pas déterminer si les modifications se rapportent à des données
significatives pour OPC UA ou non.
Communication
Lecture du mode de fonctionnement de la CPU via serveur OPC UA

Le serveur OPC UA autorise la lecture du mode de fonctionnement de la CPU, voir figure
suivante :
Figure 9-9 Lecture du mode de fonctionnement de la CPU via serveur OPC UA
Outre l'état de fonctionnement de la CPU, vous pouvez, par exemple, également lire des
informations sur le manuel (DeviceManual) ou la version de firmware (HardwareRevision).
Communication
9.3.2 Configurer l'accès aux variables API
9.3.2.1 Gestion des droits de lecture et d'écriture
Autorisation de variables API et de variables DB pour OPC UA

Les clients OPC UA peuvent accéder en lecture et en écriture aux variables API et aux variables
DB quand elles sont autorisées pour OPC UA (option par défaut). Pour les variables autorisées,
la case à cocher est activée pour "Accessible depuis HMI/OPC UA".
Vous pouvez modifier le paramétrage par défaut dans les paramètres de TIA Portal :
commande "Paramètres > Programmation API > Général" dans le menu "Outils". Vous
trouverez les options correspondantes dans la section "Interface de bloc/éléments de blocs de
données".
L'exemple suivant montre un bloc de données ARRAY :
Figure 9-10 Autorisation de variables API et de variables DB pour les variables OPC UA
Les clients OPC UA peuvent lire le tableau entièrement en une seule fois (voir Adressage des
nœuds (Page 1)). Les cases "Accessible depuis IHM/OPC UA" et "Écriture autorisée à partir de
IHM/OPC UA" sont cochées pour tous les éléments du tableau.
Conséquence : les clients OPC UA ont aussi bien le droit de lire que d'écrire ces éléments.
Retirer les droits d'écriture

Lorsque vous voulez protéger une variable contre l'accès en écriture, désactivez l'option
"Ecriture autorisée depuis IHM/OPC UA" pour cette variable. Cette mesure permet de retirer le
droit d'écriture aux clients OPC UA et aux appareils IHM.
Conséquence : Seuls les accès en lecture par les clients OPC UA et appareils IHM sont
possibles. Les clients OPC UA ne peuvent pas affecter de valeur à cette variable et ne peuvent
donc pas influencer le déroulement du programme S7.
Communication
Retirer les droits de lecture et d'écriture

Pour protéger une variable contre l'accès en lecture et en écriture, désactivez l'option
"Accessible depuis IHM/OPC UA" (pas de coche) pour cette variable. Le serveur OPC UA
supprime cette variable de sa plage d'adresses. Cette variable CPU n'est plus visible pour les
clients OPC UA.
Conséquence : Les clients OPC UA et appareils IHM ne peuvent ni lire ni écrire cette variable.
Droits d'accès en écriture et en lecture de structures

Lorsque vous retirez le droit d'accès en écriture ou en lecture à un élément d'une structure, il
n'est plus possible d'écrire ou de lire la structure ou le bloc de données dans son intégralité.
Si vous retirez les droits d'accès en lecture ou écriture à un élément d'un type de données API
(UDT), les droits d'accès en lecture ou écriture au bloc de données basé sur l'UDT sont
également retirés.
Visible dans l'ingénierie IHM

L'option "Visible dans l'ingénierie IHM" fait référence aux outils d'ingénierie de Siemens.
Lorsque vous désactivez l'option "Visible dans l'ingénierie IHM" (case non cochée), vous ne
pouvez plus configurer la variable dans WinCC (TIA Portal).
Cette option n'a aucun effet sur OPC UA.
Règles
• Dans STEP 7, n'autorisez les accès en lecture aux variables API et aux variables de blocs de
données que lorsque cela est nécessaire pour la communication avec d'autres systèmes
(automates, systèmes intégrés, MES).
N'autorisez pas d'autres variables API.
• N'autorisez les accès en écriture par OPC UA que lorsque cela est réellement nécessaire
pour certaines variables API et variables de blocs de données.
• Lorsque vous avez désactivé l'option "Accessible depuis HMI/OPC UA" pour tous les
éléments d'un bloc de données, ce bloc n'est plus visible pour un client OPC UA dans la
plage d'adresses du serveur OPC UA de la CPU S7-1500.
• Vous pouvez également empêcher de manière centralisée l'accès à un bloc de données
complet (voir Gestion des droits en écriture et en lecture pour DB complet (Page 1)). Ce
réglage l'emporte sur les paramètres des éléments dans l'éditeur de DB.
Voir aussi
Coordination des droits de lecture et d'écriture pour les variables CPU (Page 1)
Communication
9.3.2.2 Gestion des droits en écriture et en lecture pour DB complet
Masquer des DB ou des contenus de DB pour les clients OPC UA

Vous avez la possibilité d'empêcher facilement un client OPC UA d'accéder à un bloc de
données entier.
Ainsi, les données du DB en question restent masquées pour les clients OPC UA, tout comme
celles des DB d'instance de blocs fonctionnels.
Par défaut, les clients OPC UA peuvent lire et écrire dans les blocs de données. Vous pouvez
modifier ce paramétrage par défaut dans les paramètres de TIA Portal : commande
"Paramètres > Programmation API > Général" dans le menu "Outils". Vous trouverez l'option
correspondante dans la section "Paramètres par défaut pour nouveaux blocs".
Marche à suivre
Pour masquer complètement un bloc de données envers les clients OPC UA, c'est-à-dire pour
protéger un bloc de données des accès en écriture de clients OPC UA, procédez comme suit :
1. Sélectionnez le bloc de données à protéger dans le navigateur du projet.
2. Choisissez la commande "Propriétés" dans le menu contextuel.
3. Sélectionnez la zone "Attributs".
4. Activez ou désactivez la case à cocher "Accessible depuis OPC UA" selon vos besoins.
Figure 9-11 Masquer des DB ou des contenus de DB pour les clients OPC UA
Remarque
Influence sur les paramètres de l'éditeur de DB
Si vous masquez un bloc de données par l'attribut de bloc de données décrit ici, tous les
paramètres des éléments dans l'éditeur de DB ne sont plus pertinents ; il n'est plus possible de
décrire les différents éléments ou d'y accéder.
Communication
Astuce : utiliser la vue d'ensemble de tous les blocs de programme

Si vous utilisez plusieurs blocs de données, il peut être intéressant d'utiliser la vue détaillée du
dossier "Blocs de programme" pour une activation ou une désactivation ciblée de
l'accessibilité OPC UA.
1. Sélectionnez le dossier "Blocs de programme" dans le navigateur du projet.
2. Activez la commande "Vue d'ensemble" dans le menu "Affichage".
3. Sélectionnez l'onglet "Détails".
Une vue d'ensemble des blocs avec leurs attributs s'affiche.
4. Vérifiez que la colonne "DB accessible depuis OPC UA" est activée.
5. Activez uniquement les blocs de données qui doivent être accessibles par le biais de OPC UA.
Figure 9-12 Vue d'ensemble des blocs de programme
9.3.2.3 Coordination des droits de lecture et d'écriture pour les variables CPU
Définition de droits de lecture et d'écriture dans le modèle d'information (OPC UA-XML)

Dans le modèle d'information OPC UA, c'est l'attribut "AccessLevel" qui règle l'accès aux
variables.
AccessLevel est défini bit par bit :
Bit 0 = CurrentRead et Bit 1 = CurrentWrite. Les combinaisons de bits ont la signification
suivante :
• AccessLevel = 0 : aucun accès
• AccessLevel = 1 : read only
• AccessLevel = 2 : write only
• AccessLevel = 3 : read+write
Exemple d'attribution de droits de lecture et d'écriture (read+write)
Communication
Définition de droits de lecture et d'écriture dans STEP 7

En définissant des variables, vous définissez également les droits d'accès à l'aide des
propriétés "Accessible depuis IHM/OPC UA" et "Ecriture autorisée à partir de IHM/OPC UA".
Exemple d'attribution de droits de lecture et d'écriture
Figure 9-13 Exemple d'attribution de droits de lecture et d'écriture
Interaction des droits de lecture et d'écriture

Lorsque vous avez importé une interface serveur OPC UA et que des attributs d'AccessLevel
ont été définis dans le fichier XML OPC UA correspondant, les droits de lecture et d'écriture
obéissent à la règle suivante : Les droits d'accès les plus bas résultant des deux paramètres
s'appliquent.
Exemple
• AccessLevel = 1 (read only) sur l'interface serveur OPC UA
• Les attributs "Accessible depuis IHM/OPC UA" et "Ecriture autorisée à partir de IHM/OPC UA"
sont activés dans la table de variables API.
Résultat : La variable peut uniquement être lue.
Règles
Lorsque des droits d'écriture sont requis :
• AccessLevel = 2 ou 3
• "Ecriture autorisée à partir de IHM/OPC UA" activé
Lorsque des droits de lecture sont requis :
• AccessLevel = 1 (AccessLevel 3 également possible, mais ambigu. Ce réglage insinue
qu'un client OPC UA possède des droits de lecture et d'écriture)
• "Accessible depuis IHM/OPC UA" activé, "Ecriture autorisée à partir de IHM/OPC UA"
désactivé
Lorsque vous ne souhaitez attribuer ni des droits de lecture, ni des droits d'écriture (aucun
accès) :
• AccessLevel = 0
• "Accessible depuis IHM/OPC UA" désactivé
Pour interdire tout accès, il suffit que l'une des deux conditions soit remplie. Dans ce cas,
réexaminez si la variable dans l'interface serveur OPC UA est vraiment indispensable.
Communication
Table d'accès
Le préalable à tout accès est l'activation de l'attribut "Accessible depuis IHM/OPC UA".
L'attribut "Ecriture autorisée à partir de IHM/OPC UA" doit être activé pour qu'un client OPC UA
puisse écrire dans une variable / un élément de bloc de données.
Pour le droit d'accès résultant, référez-vous au tableau suivant.
Tableau 9- 2 Table d'accès
OPC UA-XML STEP 7 (TIA Portal) par ex. table des variables
AccessLevel Accessible depuis Ecriture autorisée à Droit d'accès résultant
IHM/OPC UA partir de IHM/OPC UA
0 x x Aucun accès
x 0 x Aucun accès
1 activé x Read only
2 activé Désactivé Aucun accès
3 activé Désactivé Read only
2 activé activé Write only
3 activé activé Read+write
(x = don't care)
Voir aussi
Cohérence des variables CPU (Page 1)
Gestion des droits de lecture et d'écriture (Page 1)
9.3.2.4 Cohérence des variables CPU
L'attribut "AccessLevelEx" étend les propriétés d'accès

À partir de la version de firmware V2.6, le serveur OPC UA de la CPU S7-1500 prend en
charge, outre l'attribut "AccessLevel" (voir Coordination des droits de lecture et d'écriture pour
les variables CPU (Page 1)), l'attribut "AccessLevelEx", qui, en plus des bits déjà présentés pour
l'accès en lecture et écriture, donne des informations sur la cohérence d'une variable OPC UA.
Le nouvel attribut a été introduit avec la version V1.04 de la spécification OPC UA (Part 3,
Address Space Model).
Communication
Lire les propriétés de cohérence

Dans le modèle d'information OPC UA du serveur OPC UA, l'attribut "AccessLevelEx" définit
l'accès aux variables.
AccessLevelEx est défini bit par bit. Les bits pertinents ici sont les suivants :
• Bit 0 = CurrentRead
• Bit 1 = CurrentWrite
• Les bits 2 à 7 ne sont pas pertinents pour le serveur OPC UA d'une S7-1500 CPU
La signification des combinaisons de bits est décrite dans la section concernant les droits
d'accès en lecture et écriture.
Les bits suivants sont également ajoutés aux propriétés de cohérence :
• Bit 8 = NonatomicRead ; le bit est mis à 1 si la variable ne peut pas être lue de manière
cohérente. En cas de cohérence de lecture de la variable, le bit 8=0.
• Bit 9 = NonatomicWrite ; le bit est mis à 1 si la variable ne peut pas être écrite de manière
cohérente. En cas de cohérence d'écriture de la variable, ou si aucun droit d'accès en
lecture n'est accordé, le bit 9=0.
Exemples
Une variable OPC UA (structure) est accessible en lecture et écriture, mais incohérente pour
un accès en lecture et écriture.
En conséquence : les bits 0, 1, 8 et 9 sont mis à 1 : AccessLevelEx = "771" (1+2+256+512).
Une autre structure est uniquement accessible en lecture.
En conséquence : les bits 0 et 8 sont mis à 1, les bits 1 et 9 ne sont pas mis à 1 :
AccessLevelEx = "257" (1+0+256+0).
Traitement de l'attribut dans le serveur

L'attribut "AccessLevelEx" n'est disponible que dans le serveur OPC UA. Il n'est pas disponible
dans un fichier de Nodeset (fichier d'exportation XML).
L'attribut "AccessLevel" exporté transmet toutefois également l'information d'"AccessLevelEx"
(voir le paragraphe suivant).
Exportation
Lors de l'exportation XML de l'interface serveur SIMATIC standard, le serveur donne la valeur
de l'attribut "AccessLevelEx" à l'attribut "AccessLevel" qui, à la différence de la spécification
V1.03, a été étendu à 32 bits dans la version V1.04.
Importation
Lors de l'importation d'un fichier Nodeset (par exemple à partir d'un fichier d'exportation
d'une interface de serveur), la CPU S7-1500 règle l'attribut "AccessLevelEx" d'après les
informations dont elle dispose pour assurer la cohérence du type de données importé, voir
section suivante. La valeur importée est ignorée.
Communication
Cohérence de types de données dans l'interface serveur

La cohérence de variables (dans le langage OPC UA : "atomicity") au sein d'un cycle de
programme d'une CPU S7-1500 est assurée dans les nœuds de l'interface serveur pour les
types de données suivants :
• BOOL, BYTE, WORD, DWORD, LWORD
• SINT, INT, LINT, DINT, USINT, UINT, ULINT, UDINT
• REAL, LREAL
• DATE, LDT, TIME, LTIME, TIME_OF_DAY, LTIME_OF_DAY, S5TIME
• CHAR, WCHAR
• Les types de données système ou les types de données de matériel basés sur les types de
données énumérés ci-dessus sont également cohérents.
Exemple : HW_ANY, dérivé de UINT (UInt16).
Astuce : lorsque vous naviguez dans la plage d'adresses de la CPU S7-1500 (par ex. avec le
client OPC UA UaExpert), vous trouvez les types de données cohérents sous Types >
BaseDataType > Enumeration/Number/String.
Les variables des types de données suivants ne sont pas cohérents (dans le langage OPC UA :
"nonatomic") :
• De manière générale, les structures SIMATIC ne sont pas cohérentes. C'est-à-dire que
toutes les variables qui sont par exemple des structures sans nom ou ont un type de
données UDT ne sont pas cohérentes.
• Les types de données système, comme par exemple DTL, IEC_Counter, IEC_TIMER, etc. Il
s'agit de types de données dérivés de structures.
Astuce : Lorsque vous naviguez dans la plage d'adresses de la CPU S7-1500 (par ex. avec le
client OPC UA UaExpert), vous trouvez les types de données basés sur de structures sous
Types > BaseDataType > Structure.
Communication
9.3.2.5 Possibilités d'accès au données fournies par le serveur OPC UA
Haute performance selon le cas d'application

OPC UA est conçu pour la transmission de nombreuses données en peu de temps. Vous
pouvez améliorer nettement les performances en n'accédant pas à des variables API
individuelles, mais en lisant et en écrivant dans des tableaux et structures dans leur
ensemble.
La méthode la plus rapide est l'accès à des tableaux. Il convient donc de regrouper les
données pour clients OPC UA dans des tableaux.
Recommandations d'accès du client OPC UA au serveur OPC UA

• Faites appel à l'accès Read/Write normal pour l'accès occasionnel ou exceptionnel aux
données.
• Faites appel à des souscriptions pour l'accès cyclique à certaines données (jusqu'à env.
toutes les 5 secondes).
Optimisez les paramètres d'intervalle d'émission minimal et d'intervalle d'échantillonnage
minimal sur le serveur OPC UA.
• Utilisez les fonctions "RegisteredRead" et "RegisteredWrite" pour l'accès régulier (récurrent)
à certaines variables.
Augmentez la charge due à la communication dans la CPU en modifiant la valeur pour la
"charge du cycle due à la communication". Assurez-vous du bon fonctionnement de votre
application avec les paramètres modifiés.
Marche à suivre pour la création d'un DB Array

Vous pouvez créez des tableaux par exemple dans des blocs de données globaux, dans le bloc
de données d'instance d'un bloc fonctionnel ou comme DB Array. Ce paragraphe décrit
comment créer un DB Array.
Procédez comme suit pour créer un bloc de données avec un tableau (bloc de données
ARRAY) :
1. Dans le navigateur du projet, sélectionnez la CPU avec le serveur OPC UA.
2. Double-cliquez sur "Blocs de programme".
3. Double-cliquez sur "Ajouter nouveau bloc".
4. Cliquez sur le bouton "Bloc de données".
5. Choisissez un nom unique pour le bloc de données ou acceptez le nom déjà inscrit.
6. Dans la liste déroulante dans "Type", sélectionnez l'entrée "DB ARRAY".
7. Dans la liste déroulante dans "Type de données ARRAY", sélectionnez le type de données des
différents éléments du tableau.
8. Entrez la limite supérieure du tableau dans "Limite du tableau".
9. Cliquez sur le bouton "OK".
Communication
9.3.2.6 Attribut MinimumSamplingInterval
Attribut MinimumSamplingInterval de variables

Outre "Value", "DataType" et "AccessLevel", vous pouvez également définir l'attribut
"MinimumSamplingInterval" d'une variable dans le fichier XML représentant la plage
d'adresses du serveur.
L'attribut définit la fréquence d'échantillonnage de la valeur des variables.
Le serveur OPC UA de la CPU S7-1500 gère les valeurs pour "MinimumSamplingInterval" de la
manière suivante :
• Les valeurs négatives et les valeurs supérieures à 4294967 sont mises à -1, ce qui signifie
que la fréquence d'échantillonnage minimale n'est pas définie : le serveur ne précise pas à
quelle vitesse la valeur des variables doit être échantillonnée.
• Les nombres décimaux sont arrondis à trois chiffres après le séparateur décimal.
9.3.2.7 Exporter fichier XML OPC UA
Création du fichier d'exportation OPC UA

La fondation OPC Foundation a spécifié un format standard, basé sur XML, pour décrire les
modèles d'information. Il est ainsi possible de fournir préalablement à un client le modèle
d'information d'un serveur OPC UA ou de charger des modèles d'information dans un serveur
OPC UA. Un fichier dans ce format est appelé fichier nodeset car il décrit un modèle
d'information en tant qu'ensemble (set) de nœuds (nodes).
STEP 7 (TIA Portal) permet une exportation aisée du modèle d'information Standard-SIMATIC
de la CPU S7-1500 CPU comme serveur dans un fichier OPC UA-XML (fichier Nodeset) ; y
compris toutes les variables API et les méthodes validées pour OPC UA.
Vous utilisez le fichier OPC UA-XML pour la configuration hors ligne d'un client OPC UA; Sa
structure est conforme à la spécification OPC UA et sert d'interface Standard-SIMATIC-Server.
Pour créer et exporter le fichier OPC UA-XML, procédez comme suit :
1. Sélectionnez la CPU. Pour cela, cliquez sur l'icône de la CPU (par ex. dans la vue du réseau).
2. Dans les propriétés de la CPU, cliquez sur "Général > OPC UA > Serveur > Exporter".
3. Cliquez sur le bouton "Exporter un fichier XML OPC UA".
4. Sélectionnez le répertoire dans lequel vous souhaitez enregistrer le fichier d'exportation.
5. Choisissez un nouveau nom pour le fichier ou conservez le nom déjà écrit.
6. Cliquez sur "Enregistrer".
Remarque
Les méthodes de serveur sont comprises avec leurs paramètres d'entrée et de sortie dans le
fichier d'exportation OPC UA (Nodeset) à partir de STEP 7 (TIA Portal) V15.1.
Communication
Exportation séparée de tous les éléments de tableau

Quand dans les propriétés de la CPU "OPC UA > Serveur > Exporter", l'option "Exporter tous les
éléments de tableau comme nœuds séparés" est activée, le fichier XML OPC UA contient tous
les éléments de tableaux en tant qu'éléments XML individuels. Le fichier XML contient en
outre la description de chaque tableau dans un élément XML.
Quand il y a beaucoup d'éléments dans un tableau, le fichier XML peut devenir très
volumineux.
Conseil
Dans la FAQ suivante, vous trouverez un convertisseur qui vous permettra de convertir le
fichier d'exportation au format CSV. Vous obtenez ainsi une liste des variables de la CPU
accessibles pour OPC UA.
Vous trouverez le FAQ sur Internet
9.3.3 Configurer le serveur OPC UA
9.3.3.1 Activer le serveur OPC UA
Condition
• Vous devez veiller, lorsque vous utilisez des certificats pour la communication sécurisée
(par exemple, HTTPS, Secure OUC, OPC UA), à ce que les modules concernés disposent
bien de la date et de l'heure actuelles. Si ce n'est pas le cas, les modules considéreront
les certificats utilisés comme non valides et la communication sécurisée ne fonctionnera
pas.
• Vous avez acquis une licence Runtime pour exploiter les fonctions OPC UA, voir Licences
pour OPC UA (Page 1).
Mise en service du serveur OPC UA

Dans les paramètres de base, l'accès au serveur OPC UA de la CPU n'est pas autorisé pour des
raisons de sécurité : Les clients OPC UA ne peuvent accéder ni en lecture ni en écriture à la
CPU S7-1500.
Pour activer le serveur OPC UA de la CPU, procédez comme suit :
2. Dans les propriétés de la CPU, cliquez sur "OPC UA > Serveur".
3. Activez le serveur OPC UA de la CPU.
4. Confirmez les instructions de sécurité.
5. Dans les propriétés de la CPU, sélectionnez la zone "Licences Runtime" et choisissez la
Licence Runtime achetée pour le serveur OPC UA.
6. Compilez le projet.
7. Chargez le projet dans la CPU.
Le serveur OPC UA de la CPU démarre.
Communication
Conservation des paramètres

Si vous aviez déjà activé le serveur et effectué des paramétrages, ces paramétrages ne sont
pas perdus lorsque vous désactivez le serveur. Les paramètres restent en mémoire et ils sont
de nouveau disponibles une fois que vous avez réactivé le serveur.
Nom d'application
Le nom d'application est le nom de l'application OPC UA. Il est valable pour le serveur et le
client. Il s'affiche sous "OPC UA > Général" :
• Le nom d'application par défaut est "SIMATIC.S7-1500.OPC-UA.Application:PLC_1".
• Ce nom par défaut est composé de "SIMATIC.S7-1500.OPC-UA.Application:" et du nom de
la CPU tel qu'il a été choisi sous "Général > Information produit > Nom" ("PLC_1" dans cet
exemple).
• Le serveur OPC UA s'identifie par le biais de ce nom d'application auprès d'un partenaire de
communication (client OPC UA), par exemple lorsqu'un client OPC UA utilise le service
Discovery pour rechercher des serveurs accessibles.
• Le client OPC UA de la CPU utilise le nom d'application affiché lors de l'établissement de la
liaison à un serveur OPC UA. La CPU inscrit en fait ce nom d'application automatiquement
comme "ApplicationName" dans l'instruction "OPC_UA_Connect" (variable de type
"OPC_UA_SessionConnectInfo" dans le paramètre "SessionConnectInfo" de l'instruction
"OPC_UA_Connect").
C'est pourquoi vous devez, lors de la programmation de l'instruction "OPC_UA_Connect",
affecter une chaîne de caractères vide à "ApplicationName". Le nom d'application vous
permet, par exemple, d'identifier le client et ses sessions (SessionNames) à des fins de
diagnostic.
Lorsque vous avez activé le serveur, vous pouvez également utiliser un autre nom qui sera
plus explicite et qui remplira les conditions en vigueur dans votre projet pour une univocité
universelle par exemple.
L'exemple suivant provient de UaExpert :
Communication
Modification du nom de l'application

Procédez comme suit pour modifier le nom de l'application :
2. Dans les propriétés de la CPU, cliquez sur "OPC UA > Général".
3. Saisissez un nom pertinent.
Notez que le nom d'application figure aussi dans le certificat (Subject Alternative Name) et
qu'après modification du nom d'application, vous devez le cas échéant créer à nouveau un
certificat préalablement créé.
9.3.3.2 Accès au serveur OPC UA
Adresses de serveur
L'accès au serveur OPC UA de la CPU S7-1500 est possible via toutes les interfaces PROFINET
intégrées de la CPU (à partir de la V2.0 du firmware).
Les CP permettent d'accéder directement au serveur OPC UA de la CPU par le biais du bus
interne du système d'automatisation dans les conditions suivantes :
• Configuration avec TIA Portal à partir de la version V16 CPU S7-1500 à partir de la version
de firmware V2.8, ainsi que CP 1543-1 à partir de la version de firmware V2.2
Pour la configuration, voir Accès aux applications OPC UA (Page 1).
Les CM ne permettent pas d'accéder directement au serveur OPC UA de la CPU par le biais du
bus interne du système d'automatisation.
Pour les automates SIMATIC S7-1500 SW, le serveur OPC UA est accessible par les interfaces
PROFINET qui sont affectées à l'API logiciel.
D'autres possibilités d'accès des contrôleurs logiciel sont décrits dans l'exemple d'application
suivant : Couplage OPC UA interne et externe via l'interface Ethernet virtuelle du contrôleur
logiciel à partir de la version V2.5
Exemple d'URL (Uniform Resource Locator) via lesquels il est possible d'établir des connexions
au serveur OPC UA de la CPU :
Figure 9-14 Affichage des adresses de serveur
Communication
Les URL se divisent comme suit :

• Identification de protocole "opc.tcp://"
• Adresse IP
– 192.168.178.151
Adresse IP par laquelle le serveur OPC UA est accessible depuis le sous-réseau Ethernet
192.168.178.
– 192.168.1.1
Adresse IP par laquelle le serveur OPC UA est accessible depuis le sous-réseau Ethernet
192.168.1.
• Numéro de port TCP
– Par défaut : 4840 (port standard)
Le numéro de port peut être modifié sous "Serveur OPC UA > Paramètres > Port".
Adresses IP dynamiques
Dans l'exemple suivant, l'adresse IP de l'interface PROFINET [X2] n'est pas encore définie.
Figure 9-15 Affichage des adresses de serveur avec adresse IP dynamique
Le tableau affiche la marque de réservation "dynamically".

L'adresse IP de cette interface PROFINET sera définie ultérieurement sur l'appareil, par
exemple par le biais de l'écran de la CPU.
Communication
Activer l'interface serveur SIMATIC standard

Lorsque l'option "Activer l'interface serveur SIMATIC standard" est activée, le serveur OPC UA
de la CPU met à la disposition des clients les variables API autorisées et les méthodes de
serveur, comme cela a été établi par Siemens dans l'espace de noms auto-défini.
Cette option est activée par défaut.
Laissez-la activée pour que les clients OPC UA puissent se connecter automatiquement au
serveur OPC UA de la CPU et échanger des données.
Si vous n'activez pas cette option, vous devez ajouter l'interface serveur via l'entrée
"Communication OPC UA" dans le navigateur du projet. Cette interface est ensuite utilisée
comme interface serveur OPC UA, voir Configurer une interface serveur OPC UA-Server
(Page 1).
Remarque
Informations générales sur les appareils lisibles y compris lorsque l'interface serveur
SIMATIC standard est désactivée
Les informations générales sur les appareils relatives au serveur OPC UA de la CPU restent
lisibles pour les clients OPC UA, même lorsque vous désactivez l'interface serveur SIMATIC
standard.
Exemples de ce type d'informations sur les appareils : DeviceManual, DeviceRevision,
OrderNumber. Dans ce cas, tous les objets du programme utilisateur restent cependant
invisibles pour les clients.
Si vous souhaitez empêcher que ces informations sur l'appareil soient visibles, vous devez
désactiver le serveur OPC UA de la CPU.
9.3.3.3 Paramètres généraux du serveur OPC UA
Port TCP pour OPC UA

OPC UA utilise par défaut le port TCP 4840. Cependant, vous pouvez aussi choisir un port
différent. Des valeurs de 1024 à 49151 sont possibles. Vous devez toutefois veiller à ce qu'il
n'y ait aucun conflit avec d'autres applications. Les clients OPC UA doivent utiliser le port
choisi pour établir une liaison.
Dans l'exemple suivant, c'est le port 48400 qui a été choisi :
Figure 9-16 Port TCP pour OPC UA
Vous trouverez une vue d'ensemble des protocoles pris en charge et des numéros de port
utilisés des CPU S7-1500 au chapitre Protocoles de communication et numéros de port
utilisés pour communication Ethernet (Page 1).
Communication
Paramètres pour sessions

• Délai d'attente maximal pour sessions
Vous déterminez dans ce champ le laps de temps maximal pouvant s'écouler sans
échange de données avant que le serveur OPC UA mette fin à une session.
Valeurs possibles entre 1 et 600 000 secondes.
• Nombre maximal de sessions OPC UA
Vous déterminez dans ce champ le nombre maximal de sessions que le serveur OPC UA de
la CPU peut établir et exploiter simultanément.
Le nombre maximal de sessions dépend de la puissance de la CPU. Chaque session engage
des ressources.
Nombre maximal de nœuds enregistrés

Vous déterminez dans ce champ combien de nœuds (Nodes) le serveur OPC UA enregistre au
plus.
Le nombre maximal de nœuds enregistrés dépend de la puissance de la CPU et s'affiche lors
de la configuration du contenu du champ (placez le pointeur de la souris dans le champ).
Chaque enregistrement engage des ressources.
Remarque
Aucun message d'erreur en cas de tentative d'enregistrer plus de nœuds que le nombre
maximal de nœuds enregistrables configuré
Lorsqu'un client souhaite enregistrer plus de nœuds que le nombre maximal de nœuds
enregistrables configuré pendant l'exécution, le serveur de la CPU S7-1500 n'enregistre que le
nombre maximal configuré. Au-delà du nombre maximal de nœuds enregistrables configuré,
le serveur répond au client avec les ID StringNode normales sans modification, annihilant
ainsi les gains de vitesses liés à l'enregistrement pour ces nœuds. Le client ne reçoit aucun
message d'erreur.
Lors de la configuration, prévoyez une réserve suffisante. Tenez compte à cet effet du
nombre maximal de nœuds enregistrables (par exemple, par le biais des caractéristiques
techniques de la CPU).

Vous trouverez les ports qui utilisent différents services pour le transfert de données via TCP
et UDP et les points dont vous devez tenir compte pour les routes et les pare-feux dans la FAQ
Communication
Définitions de type de données à compatibilité descendante selon la spécification

OPC UA ≤ V1.03
La spécification OPC UA (<= V1.03) définit des mécanismes pour pouvoir lire dans un serveur
des définitions de type de données à l'aide de TypeDictionaries, par exemple pour des
structures personnalisées (UDT).
Vous pouvez paramétrer les propriétés du serveur OPC UA de la CPU de manière à ce que
cette dernière génère ou non ces définitions de type de données à compatibilité descendante
selon la spécification OPC UA ≤ V1.03 pour l'interface serveur SIMATIC standard.
Comme les TypeDictionaries sont complexes et qu'ils génèrent des fichiers XML OPC UA
(interfaces serveur) de grande taille que le client doit interpréter, une solution plus simple a
été introduite avec la spécification OPC UA V1.04 (attribut "DataTypeDefinition" sur le nœud
DataType). Si votre client prend en charge la spécification OPC UA à partir de V1.04,
désactivez l'option.
Avantages des définitions de type de données selon la spécification OPC UA à partir de la
version V1.04 :
• Le serveur démarre plus rapidement.
• L'utilisation de la mémoire est plus efficace.
• La fonction "Navigation" réagit plus rapidement.
9.3.3.4 Paramètres du serveur pour souscriptions
Souscription au lieu d'interrogation cyclique

L'observation d'une variable constitue une alternative à l'interrogation cyclique d'une variable
API (polling). Pour cela, utilisez une Subscription (abonnement) : Le serveur informe le client
quand la valeur de variables API a changé. Voir "Le client OPC UA".
Un serveur surveille généralement plusieurs valeurs API. C'est pourquoi le serveur envoie
régulièrement au client des messages (notifications) contenant les nouvelles valeurs des
variables API.
Avantages des souscriptions :
• Le serveur démarre plus rapidement.
• L'utilisation de la mémoire est plus efficace.
Communication
À quel rythme le serveur envoie-t-il des messages ?

En créant une Subscription, le client OPC UA indique à quel intervalle le client OPC UA
souhaite recevoir les nouvelles valeurs en cas de changement. Pour limiter la charge due à la
communication par OPC UA, définissez un intervalle de temps pour les messages. Utilisez, à
cet effet, les paramètres Intervalle d'émission minimal et Intervalle d'échantillonnage
minimal.
Figure 9-17 Principe d'une souscription
Intervalle d'émission minimal

Vous réglez comme "intervalle d'émission minimal" l'intervalle de temps selon lequel le
serveur envoie au client un message avec les nouvelles valeurs en cas de changement de
valeurs.
Dans la figure ci-dessous, l'"intervalle d'échantillonnage minimal" a la valeur 250 ms.
L'"intervalle d'émission minimal" est réglé sur 200 ms.
Figure 9-18 Paramètres des souscriptions
Dans cet exemple, le serveur OPC UA envoie un nouveau message toutes les 200 ms en cas
de changement, si le client OPC UA demande une mise à jour.
Si le client OPC UA demande une mise à jour toutes les 1 000 ms, par exemple, le serveur
OPC UA n'envoie un message avec les nouvelles valeurs qu'une fois par 1 000 ms (une
seconde).
Si le client OPC UA demande une mise à jour toutes les 100 ms, le serveur ne l'envoie quand
même que toutes les 200 ms (intervalle d'émission minimal).
Communication
Intervalle d'échantillonnage minimal

Vous réglez comme "intervalle d'échantillonnage minimal" l'intervalle de temps selon lequel
le serveur OPC UA acquiert la valeur d'une variable CPU et la compare à la valeur précédente
afin de constater un changement.
Si vous avez choisi un intervalle d'échantillonnage inférieur à l'intervalle d'émission et qu'un
client OPC UA demande une fréquence d'échantillonnage élevée pour certaines variables API,
deux valeurs ou plus peuvent apparaître par intervalle d'émission.
Dans ce cas, le serveur OPC UA écrit les changements de valeur dans la file d'attente et envoie
tous les changements au client une fois l'intervalle d'émission écoulé. Quand le nombre de
changements de valeurs dans l'intervalle d'émission est supérieur au nombre que peut
contenir la file d'attente, le serveur OPC UA écrase les valeurs les plus anciennes (en fonction
de la "Discard Policy" paramétrée du client abonné aux données, l'option "Discard Oldest" doit
dans ce cas être activée). Les valeurs les plus récentes seront donc envoyées au client.
Nombre maximal d'éléments surveillés (Monitored Items)

Vous déterminez dans ce champ le nombre maximal d'éléments que le serveur OPC UA de la
CPU surveille simultanément pour détecter un changement de valeur.
Cette surveillance engage des ressources. Le nombre maximal d'éléments surveillés dépend
de la CPU utilisée.

Vous trouverez des informations sur les limites système du serveur OPC UA des CPU S7-1500
(firmware V2.0 et V2.1) en termes de souscriptions, d'intervalles d'échantillonnage et
d'intervalles d'émission dans la FAQ
(https://support.industry.siemens.com/cs/ww/fr/view/109755846) suivante.
En cas d'utilisation de souscriptions, des codes d'état spécifiques donnent des informations
sur une éventuelle erreur s'étant produite. Vous trouverez des informations sur les causes et
les solutions pour les codes d'erreur générés dans le client OPC UA dans la liste des codes
d'erreur de l'aide en ligne de STP 7 (TIA Portal) ou dans la FAQ
(https://support.industry.siemens.com/cs/ww/fr/view/109755860) suivante.
Voir aussi
Règles relatives aux souscriptions (Page 1)
Diagnostiquer les abonnements (Page 1)
Communication
9.3.3.5 Utilisation des certificats du client et du serveur

Une liaison sécurisée entre un serveur OPC UA et un client OPC UA n'est possible que si le
serveur est en mesure de justifier de son identité vis-à-vis du client. Le certificat du serveur
sert à cela.
Certificat du serveur OPC UA

Si vous avez activé le serveur OPC UA et confirmé les instructions de sécurité, STEP 7 génère
automatiquement le certificat pour le serveur et l'enregistre dans le répertoire de certificats
local de la CPU. Le gestionnaire de certificats local de la CPU vous permet de consulter et de
gérer ce répertoire (exporter ou supprimer des certificats).
La figure ci-dessous montre le gestionnaire de certificats local de la CPU avec le certificat
généré automatiquement pour le serveur OPC UA :
Figure 9-19 Gestionnaire de certificats local de la CPU
Vous pouvez également créer un certificat de serveur.

Le certificat du serveur est transmis du serveur au client pendant l'établissement d'une
liaison. Le client vérifie le certificat.
Communication
L'utilisateur client décide s'il fait confiance au certificat du serveur.

Côté client, l'utilisateur doit à présent décider s'il fait confiance au certificat de serveur. Si
c'est le cas, il enregistre ce certificat dans son répertoire contenant les certificats de serveur
dignes de confiance.
L'exemple suivant montre une boîte de dialogue du client "UA Sample Client". Si l'utilisateur
clique sur le bouton "Oui", cela signifie que le client fait confiance au certificat de serveur :
Figure 9-20 Boîte de dialogue du client "UA Sample Client"
D'où provient le certificat d'un client ?
Client du S7-1500
Lorsque vous utilisez le client OPC UA d'une CPU S7-1500 (client OPC UA activé), vous pouvez
générer des certificats pour ces clients avec STEP 7 à partir de V15 :
1. Sélectionnez la CPU agissant comme client dans le navigateur du projet.
2. Double-cliquez sur "Configuration de l'appareil"
3. Dans les propriétés de la CPU, cliquez sur "Protection & sécurité > Gestionnaire de
certificats".
4. Dans le tableau "Certificats d'appareil", double-cliquez sur "<ajouter nouveau>".
STEP 7 ouvre une boîte de dialogue.
5. Cliquez le bouton "Ajouter".
6. Dans la liste, sélectionnez l'entrée "Client OPC UA" comme "Utilisation".
Attention :
Les adresses IP sous lesquelles la CPU est accessible dans votre installation doivent être
saisies sous "Autre nom du demandeur de certificat (SAN)".
Vous devez donc configurer les interfaces IP de la CPU avant de créer un certificat de
client.
STEP 7 affiche maintenant le certificat de client dans le tableau "Certificats d'appareil".
Communication
8. Cliquez avec le bouton droit de la souris sur cette ligne et sélectionnez la commande
"Exporter le certificat" dans le menu contextuel.
9. Sélectionnez un répertoire dans lequel vous enregistrez le certificat de client.
Clients d'autres constructeurs

Si vous utilisez des clients UA de constructeurs ou de OPC Foundation, un certificat de client
est automatiquement créé lors de l'installation ou du premier appel du programme. Vous
devez importer ces certificats dans STEP 7 via le gestionnaire de certificats global et les utiliser
pour la CPU concernée (comme indiqué ci-dessus).
Si vous programmez vous-même un client OPC UA, vous pouvez créer des certificats à l'aide
du programme (voir "Certificat d'instance pour le client"). Vous pouvez également créer des
certificats à l'aide d'outils, par exemple OpenSSL ou le générateur de certificats de OPC
Foundation :
• Pour la marche à suivre avec OpenSSL, voir "Générer soi-même des couples de clés PKI et
des certificats".
• Pour la marche à suivre avec le générateur de certificats de OPC Foundation, voir "Création
de certificats autosignés".
Indiquer les certificats du client au serveur

Vous devez mettre les certificats du client à la disposition du serveur afin de pouvoir établir
une liaison sécurisée.
1. Activez l'option "Utiliser les paramètres de sécurité globaux pour la gestion des certificats"
dans le gestionnaire de certificats local du serveur. Le gestionnaire de certificats global est
alors disponible.
Vous trouverez cette option dans les propriétés de la CPU utilisée comme serveur sous
"Protection et sécurité > Gestionnaire de certificats".
Si le projet en question n'est pas encore protégé, dans le "navigateur de projet" de STEP 7,
sélectionnez l'entrée "Paramètres de sécurité > Paramètres" et cliquez sur le bouton
"Protéger ce projet", puis connectez-vous.
L'entrée "Paramètres de sécurité globaux" s'affiche alors dans le "navigateur de projet" de
STEP 7.
2. Double-cliquez sur "Paramètres de sécurité globaux".
3. Double-cliquez sur "Gestionnaire de certificats".
STEP 7 ouvre le gestionnaire de certificats global.
4. Cliquez sur l'onglet "Certificats dignes de confiance".
5. Cliquez avec le bouton droit de la souris sur une surface libre dans la page d'onglet (pas sur
un certificat).
6. Choisissez la commande "Importer" dans le menu contextuel.
Le dialogue d'importation de certificats s'affiche.
7. Sélectionnez le certificat du client auquel le serveur doit faire confiance.
Communication
8. Cliquez sur le bouton "Ouvrir" pour importer le certificat.

Le certificat du client se trouve désormais dans le gestionnaire de certificats global.
Retenez l'ID du certificat de client que vous venez d'importer.
9. Cliquez ensuite sur l'onglet "Général" dans les propriétés de la CPU utilisée comme serveur.
10.Cliquez sur la zone "OPC UA > Serveur > Sécurité > Secure Channel".
11.Faire défiler vers le bas jusqu'à la zone "Clients dignes de confiance" dans la boîte de
dialogue "Secure Channel".
12.Dans le tableau, double-cliquez sur la ligne vide avec "<Ajouter nouveau>". Un bouton
comprenant trois points de suspension est affiché dans cette ligne.
13.Cliquez dessus.
14.Sélectionnez le certificat de client que vous avez importé.
15.Cliquez sur le bouton avec la coche verte.
16.Compilez le projet.
17.Chargez la configuration dans la CPU S7-1500.
Résultat :
Le serveur fait désormais confiance au client. Si, en plus, le certificat du serveur est considéré
comme digne de confiance, le serveur et le client peuvent établir une liaison sécurisée.
Accepter automatiquement les certificats de client

Si vous activez l'option "Accepter automatiquement les certificats de client durant l'exécution"
(sous la liste "Clients dignes de confiance"), le serveur accepte tous les certificats de client.
IMPORTANT
Paramétrage après la mise en service
Pour éviter les risques liés à la sécurité, désactivez l'option "Accepter automatiquement tous
les certificats de client pendant l'exécution" après la mise en service.
Communication
Configuration des paramètres de sécurité du serveur

La figure suivante montre les paramètres de sécurité du serveur disponibles pour la signature
et le cryptage des messages.
Figure 9-21 Configuration des paramètres de sécurité du serveur
Par défaut, le certificat de serveur créé utilise la signature SHA256. Les stratégies de sécurité
suivantes sont autorisées :
• Aucune
Nœud d'extrémité non sécurisé
Remarque
Désactiver les stratégies de sécurité non souhaitées
Si vous avez activé toutes les stratégies de sécurité dans les paramètres Secure Channel du
serveur OPC UA du S7-1500 (paramétrage par défaut) – et donc également le nœud
d'extrémité "Aucune Security" –, l'échange de données même non sécurisé (ni signé ni
crypté) est possible entre serveur et client. Avec "Pas de Security", l'identité du client reste
inconnue. Chaque client OPC UA peut alors se connecter au serveur indépendamment des
paramètres Security à venir.
Lors de la configuration du serveur OPC UA, veillez à ce que seules soient activées des
stratégies de sécurité compatibles avec le concept de sécurité mis en œuvre dans votre
machine ou installation. Toutes les autres stratégies de sécurité doivent être désactivées.
Recommandation : Utilisez, si possible, le paramètre "Basic256Sha256".
Communication
• Basic128Rsa15 - Signature
Nœud d'extrémité sécurisé, prend en charge une série d'algorithmes qui utilisent
l'algorithme de hachage RSA15 et le cryptage 128 bits.
Ce nœud d'extrémité garantit l'intégrité des données en les signant.
• Basic128Rsa15 - Signer crypter
Ce nœud d'extrémité garantit l'intégrité et la confidentialité des données en les signant et
en les cryptant.
• Basic256Rsa15 - Signature
• Basic256Rsa15 - Signer crypter
en les cryptant.
• Basic256Sha256 - Signature
Nœud d'extrémité sécurisé, prend en charge une série d'algorithmes pour le hachage
256 bits et le cryptage 256 bits.
• Basic256Sha256 - Signer crypter
Nœud d'extrémité sécurisé, prend en charge une série d'algorithmes pour le hachage
256 bits et le cryptage 256 bits.
en les cryptant.
Pour activer un paramétrage de sécurité, cliquez sur la case dans la ligne respective.
Remarque
Quand vous utilisez les paramètres "Basic256Sha256 - Signature" et "Basic256Sha256 - Signer
crypter", il faut que le serveur OPC UA et les clients OPC UA utilisent des certificats signés avec
"SHA256".
Pour les paramètres "Basic256Sha256 - Signature" et "Basic256Sha256 - Signer crypter",
l'autorité de certification de STEP 7 signe les certificats automatiquement avec "SHA256".
Communication
Stratégie de sécurité "Aucune Security" et authentification par nom d'utilisateur et mot de passe
Vous pouvez définir la combinaison suivante :
Stratégie de sécurité "Aucune Security" et authentification par nom d'utilisateur et mot de
passe.
• Le serveur OPC UA du S7-1500 prend en charge cette combinaison. Les clients OPC UA
peuvent se connecter et crypter ou non les données d'identification.
• Le client OPC UA de la CPU S7-1500 prend également en charge cette combinaison.
Pendant l'exécution, il ne se connecte cependant que s'il peut envoyer les données
d'authentification cryptées sur la ligne.
Voir aussi
Création de certificats de serveur avec STEP 7 (Page 1)
9.3.3.6 Création de certificats de serveur avec STEP 7

Le paragraphe suivant décrit la procédure permettant de générer de nouveaux certificats avec
STEP 7 et s'applique, en principe, aux différentes utilisations des certificats. STEP 7 paramètre
déjà l'utilisation appropriée, ici "Client et serveur OPC UA", en fonction de la section de
propriétés de la CPU à partir de laquelle vous lancez la boîte de dialogue suivante.
Recommandation : Afin d'utiliser toute la fonctionnalité disponible pour la sécurité du serveur
OPC UA, appliquez les paramètres de sécurité généraux.
Vous activez les paramètres de sécurité généraux dans les propriétés de la CPU, dans la zone
Personnalisation de certificats de serveur

STEP 7 crée automatiquement un certificat pour le serveur OPC UA de la S7-1500, si vous
activez le serveur (voir "Activation du serveur OPC UA (Page 1)"). Ce faisant, STEP 7 utilise les
valeurs par défaut pour les paramètres du certificat. Si vous souhaitez modifier les
paramètres, procédez comme suit :
1. Dans les propriétés de la CPU, cliquez sur le bouton avec les points de suspension dans
"Général > OPC UA > Serveur > Sécurité > Secure Channel > Certificat de serveur". Une boîte
de dialogue affichant les certificats disponibles localement s'ouvre.
2. Cliquez le bouton "Ajouter".
Communication
3. Le dialogue de création de certificats s'affiche (figure suivante). Les valeurs sont déjà entrées
pour un exemple :
Figure 9-22 Personnalisation de certificats de serveur
4. Utilisez d'autres paramètres si cela est nécessaire selon les instructions de sécurité de votre
entreprise ou du donneur d'ordre.
Communication
Description des champs de création de certificats

• CA
Choisissez entre un certificat autosigné ou un certificat signé par l'un des certificats CA de
TIA Portal. Les certificats sont décrits sous "Certificats sur OPC UA". Si vous voulez créer un
certificat signé par l'un des certificats CA de TIA Portal, le projet doit être protégé et vous
devez être connecté avec les droits de fonction nécessaires. Vous trouverez des
informations à ce sujet à la section " Principes de la gestion des utilisateurs dans le TIA
Portal ".
• Titulaire du certificat
La valeur par défaut se compose du nom du projet et de "\OPCUA-1". Dans notre exemple,
le nom du projet est "PLC1". Paramétrez le nom du projet dans les propriétés de la CPU,
sous "Général > Informations sur le projet > Nom". Conservez le réglage par défaut ou
saisissez un autre nom, plus pertinent dans votre projet, pour le serveur OPC UA dans
"Titulaire du certificat".
• Signature
Sélectionnez ici la méthode de hachage et de chiffrement à utiliser pour la signature du
certificat de serveur. Les entrées suivantes sont disponibles :
– "sha1RSA",
– "sha256RSA".
• Valide à partir de
Saisissez ici la date et l'heure de début de validité du certificat de serveur.
• Valide jusqu'au
Saisissez ici la date et l'heure de fin de validité du certificat de serveur. Veillez à ce que le
certificat ne soit pas valide pendant une année ou quelques années seulement. Dans
l'exemple, le certificat est valide pendant 30 ans. Pour des raisons de sécurité, vous devez,
toutefois, renouveler le certificat à une fréquence bien plus élevée. Cependant, une
validité de longue durée vous permet de décider du moment approprié pour cela, c'est-à-
dire du moment où la maintenance d'une installation devra être effectuée.
Communication
• Utilisation
Le réglage par défaut est "Client et serveur OPC UA" Conservez ce réglage par défaut pour
le serveur OPC UA. La boîte de dialogue "Générer un nouveau certificat" peut être appelée
à partir de plusieurs endroits dans STEP 7. Si vous l'appelez pour le serveur Web de la CPU,
par exemple, c'est "Serveur Web" qui sera indiqué sous "Utilisation". La liste déroulante
pour l'utilisation propose les entrées suivantes :
– "Client OPC UA"
– "Client et serveur OPC UA"
– "Serveur OPC UA"
– "TLS"
– "Serveur Web"
• Autre nom du demandeur de certificat (SAN)
L'exemple ci-dessus indique : "URI:urn:SIMATIC.S7-1500.OPC-
UAServer:PLC1,IP:192.168.178.151,IP:192.168.1.1". Cette URI doit être correctement
saisie, car elle sera comparée à la description d'application transmise.
L'entrée suivante serait également valide : "IP : 192.168.178.151, IP : 192.168.1.1".
L'important est de mentionner ici les adresses IP donnant accès au serveur OPC UA de la
CPU.
Voir "Accès au serveur OPC UA (Page 1)".
Ainsi, les clients OPC UA peuvent vérifier si une liaison doit réellement être établie avec le
serveur OPC UA de la S7-1500, ou si, éventuellement, un attaquant tente d'envoyer des
valeurs manipulées au client OPC UA à partir d'un autre PC.
9.3.3.7 Authentification de l'utilisateur
Types d'authentification utilisateur

Vous pouvez aussi régler sur le serveur OPC UA de S7-1500 comment un utilisateur du client
OPC UA doit s'authentifier lorsqu'il souhaite accéder au serveur.
Pour ce faire, il existe les possibilités suivantes :
• Authentification d'invité
L'utilisateur ne doit pas prouver ses droits (accès anonyme). Le serveur OPC UA ne vérifie
pas les droits de l'utilisateur client.
Pour utiliser ce type d'authentification de l'utilisateur, sélectionnez l'option "Activer
l'authentification d'invité" sous "OPC UA > Serveur > Sécurité > Authentification de
l'utilisateur".
Remarque
Pour renforcer la sécurité, n'autorisez l'accès au serveur OPC UA qu'après l'authentification
de l'utilisateur.
Communication
• Authentification par nom d'utilisateur et mot de passe

L'utilisateur doit prouver ses droits (pas d'accès anonyme). Le serveur OPC UA vérifie si le
client utilisateur possède l'autorisation nécessaire pour accéder au serveur. Le nom
d'utilisateur avec le mot de passe correct sert de preuve.
Pour utiliser ce type d'authentification de l'utilisateur, sélectionnez l'option "Activer
l'authentification par nom d'utilisateur et mot de passe" sous "OPC UA > Serveur > Sécurité
> Authentification de l'utilisateur".
Désactivez l'authentification "Invité".
Saisissez l'utilisateur dans le tableau "Gestion des utilisateurs".
Cliquez pour cela sur l'entrée "<Ajouter nouvel utilisateur>". Un nouvel utilisateur au nom
automatiquement attribué est créé. Vous pouvez éditer le nom d'utilisateur et saisir le mot
de passe correspondant. Vous pouvez ajouter au maximum 21 utilisateurs.
• Gestion des utilisateurs supplémentaire via les paramètres de sécurité du projet
L'option "Activer une gestion des utilisateurs supplémentaire via les paramètres de
sécurité du projet" se trouve sous les paramètres OPC UA généraux (propriétés de la CPU :
OPC UA > Général). Quand vous activez cette option, le système utilise la gestion des
utilisateurs du projet ouvert même pour l'authentification de l'utilisateur du serveur OPC
UA : Les mêmes noms d'utilisateur et les mêmes mots de passe sont alors valables dans
OPC UA et dans le projet actuel.
Procédez de la manière suivante pour activer la gestion des utilisateurs du projet :
– Cliquez sur "Paramètres de sécurité > Paramètres" dans le "navigateur de projet".
– Cliquez sur le bouton "Protéger ce projet".
– Tapez votre nom d'utilisateur et votre mot de passe.
– Saisissez d'autres utilisateurs sous "Paramètres de sécurité > Utilisateurs et rôles".
Si vous configurez un autre serveur OPC UA dans votre projet, activez y également l'option
"Activer une gestion des utilisateurs supplémentaire via les paramètres de sécurité du
projet". Ainsi, vous n'aurez pas besoin de saisir de nouveau les noms d'utilisateur et les
mots de passe.
Voir aussi
Authentification de l'utilisateur (Page 1)
Utilisateur et rôles avec les droits de fonction OPC UA (Page 1)
Communication
9.3.3.8 Utilisateur et rôles avec les droits de fonction OPC UA

Les options d'authentification utilisateur suivantes ont recours à des paramètres de projet
globaux pour l'utilisateur du projet :
• Côté serveur :
Lors du paramétrage des propriétés de la CPU (OPC UA > Serveur > Sécurité >
Authentification de l'utilisateur). Il s'agit de l'option "Activer une gestion des utilisateurs
supplémentaire via les paramètres de sécurité du projet"
• Côté client :
Lors de la configuration de l'interface client (onglet "Configuration", zone "Sécurité"). Il
s'agit de l'option "Utilisateur (TIA Portal - Paramètres de sécurité)"
Condition
Afin d'éditer les paramètres de sécurité, le projet doit être protégé et vous devez être
connecté au système avec des droits d'utilisateur suffisants, par exemple en tant
qu'administrateur.
Paramètres dans le navigateur du projet > "Réglages Security"

Vous accédez aux paramètres utilisateur centraux et aux rôles du projet protégé dans la zone
"Réglages Security" dans le navigateur du projet. Vous pouvez y définir de manière centralisée
un utilisateur avec le nom d'utilisateur, le mot de passe ainsi que les droits de fonction
associés. Vous pouvez réutiliser ces paramètres à un autre endroit.
Figure 9-23 Paramétrage des utilisateurs et des rôles
Réutilisation de paramètres de sécurité globaux

Exemples de lieux de réutilisation :
• Choix d'utilisateur pour l'authentification utilisateur auprès du serveur OPC UA
Avec ce paramètre, vous indiquez au serveur quel client (utilisateur) est autorisé à accéder
au serveur avec quel nom utilisateur et quel mot de passe.
• Choix d'utilisateur pour l'authentification client OPC UA
Avec ce paramètre, vous indiquez au client quel nom utilisateur et quel mot de passe il
doit utiliser pour s'authentifier en tant que client auprès du serveur.
Les paramètres du client doivent correspondre à ceux du serveur et inversement : le nom
d'utilisateur et le mot de passe que le client utilise pour se connecter doivent être configurés
sur le serveur et pourvus des autorisations correspondantes.
Communication
Droits de fonction pour serveur et client

Pour les utilisateurs de la fonctionnalité client et les utilisateurs de la fonctionnalité serveur
d'une CPU S7-1500, les droits fonctionnels correspondants pour le client ou le serveur doivent
également être activés. Le fait de définir le nom d'utilisateur et le mot de passe de manière
globale n'est pas suffisant.
L'exemple suivant décrit ce type de gestion des droits.
1. Définissez dans la zone "Réglages Security > Utilisateurs et rôles" un nouveau rôle dans
l'onglet "Rôles" avec un nom, par exemple "PLC-opcua-role-all-inclusive".
Conseil : il se peut que l'onglet soit masqué par une fenêtre d'information ("L'état actuel n'a
pas encore été vérifié..."). Dans ce cas, fermez d'abord la fenêtre d'information.
2. Dans la zone "Catégories de droits de fonction", naviguez jusqu'aux droits Runtime, puis
jusqu'aux droits de fonction de la CPU et sélectionnez la CPU dont vous souhaitez
paramétrer les droits de fonction.
Communication
3. Vous disposez des droits de fonction suivantes dans la zone "Droits de fonction" :
– Accès serveur OPC UA
Ce droit de fonction se répercute sur le serveur OPC UA de la CPU S7-1500. Cette
option doit être sélectionnée pour que l'utilisateur ayant pour rôle "PLC-opcua-role-all-
inclusive" puisse transférer en cours d'exécution des certificats, CRL ou listes de
confiance sur la CPU (fonction push). Ce droit de fonction est nécessaire à la gestion
automatisée des certificats, par ex. dans le cadre de GDS (Global Discovery Service).
– Gestion des certificats
Ce droit de fonction se répercute sur le serveur OPC UA de la CPU S7-1500. Cette
option doit être activée pour que l'utilisateur ayant pour rôle "PLC-opcua-role-all-
inclusive" puisse transférer en cours d'exécution des certificats, CRL ou listes de
confiance sur la CPU (fonction push). Ce droit de fonction est nécessaire à la gestion
automatisée des certificats, par ex. dans le cadre de GDS (Global Discovery Service).
– Authentification de l'utilisateur du client OPC UA
Ce droit de fonction se répercute sur le client OPC UA de la CPU S7-1500 (sur les
instructions client). Cette option doit être sélectionnée pour que l'utilisateur ayant pour
rôle "PLC-opcua-role-all-inclusive" puisse utiliser son nom d'utilisateur et mot de passe
pour s'authentifier auprès du serveur en vue de l'ouverture d'une session.
Figure 9-24 Paramétrer les droits fonctionnels
4. Vous devez aussi attribuer le rôle "PLC-opcua-role-all-inclusive" aux utilisateurs

correspondants (onglet "Utilisateur" de la zone "Réglages Security" dans le navigateur du
projet).
Remarque
"Durée de session" pour utilisateurs possédant des droits de fonction OPC UA
Les valeurs de la colonne "Durée de session" dans le tableau de configuration des
utilisateurs ne sont pas exploitées par la CPU pour les droits Runtime OPC UA.
Les utilisateurs ne sont donc pas automatiquement déconnectés après une période
définie. Utilisez pour cela les mécanismes spécifiques à OPC UA, par exemple le paramètre
"Durée de session maximale" (zone OPC UA > Serveur > Paramètres).
Communication
9.3.3.9 Paramètres de diagnostic du serveur
Diagnostic
Vous pouvez définir l'étendue du diagnostic du serveur OPC UA dans les paramètres de la
CPU.
Pour modifier l'étendue du diagnostic, naviguez jusqu'à la section "OPC UA > Serveur >
Diagnostic".
Figure 9-25 Paramètres de diagnostic du serveur OPC UA
Paramétrage par défaut

Le comportement de diagnostic défini par défaut permet les diagnostics les plus importants
sans augmentation notable de la charge due à la communication.
Vous activez les diagnostics pour les souscriptions si le serveur OPC UA traite également des
souscriptions, éventuellement uniquement dans la phase de mise en service.
En effet, De nombreux diagnostics entraînent une charge élevée de la CPU due à la
communication et peuvent éventuellement évincer d'autres messages importants. Ou bien
des messages importants se noient dans la masse en cas d'afflux important de diagnostic et
ne sont pas pris en compte.

Vous trouverez plus d'informations sur la signification et l'effet des paramètres ci-dessus ici
(Page 1).
Communication
9.3.3.10 Licences pour OPC UA
Licences Runtime
Une licence est nécessaire pour utiliser le serveur OPC UA de la CPU S7-1500. Le type de
licence requise dépend de la puissance de la CPU en question. On distingue les types de
licence suivants :
• SIMATIC OPC UA S7-1500 small (requise pour les CPU 1511, CPU 1512, CPU 1513, CPU ET
200SP, CPU 1515SP PC)
• SIMATIC OPC UA S7-1500 medium (requise pour les CPU 1515, CPU 1516, contrôleur
logiciel CPU 1507, CPU 1516pro-2PN)
• SIMATIC OPC UA S7-1500 large (requise pour les CPU 1517, CPU 1518)
Le type de licence requise est affiché dans "Propriétés > Général > Licences Runtime > OPC UA
> Type de licence requise" :
Figure 9-26 Licences Runtime du serveur OPC UA
Pour confirmer l'achat de la licence requise, procédez comme suit :

1. Dans les propriétés de la CPU, cliquez sur "Licences Runtime > OPC UA".
2. Sélectionnez la licence requise dans la liste déroulante "Type de la licence acquise".
Communication
9.3.4 Configurer une interface serveur OPC UA-Server
9.3.4.1 Qu'est-ce qu'une interface serveur ?
Définition
Une interface serveur regroupe les nœuds d'une plage d'adresses OPC UA d'une CPU en une
unité, mettant ainsi à disposition des clients OPC UA une vue spécifique sur cette CPU.
Chaque interface serveur définit un ou plusieurs espaces de noms dans le serveur OPC UA de
la CPU.
STEP 7 (TIA Portal) distingue les types suivants d'interfaces serveur :
• Spécification Companion
Vous utilisez pour ce type d'interface serveur une spécification Companion créée par un
groupe de travail, par exemple.
Le groupe de travail se compose typiquement de membres de la Fondation OPC et d'une
autre organisation industrielle qui ont défini ensemble un modèle d'information OPC UA
dans un but précis (par exemple, pour l'échange de données avec des appareils RFID ou
avec des machines de moulage par injection).
Ce modèle d'information est réalisé sous forme de nœuds OPC UA dans la plage d'adresses
d'un serveur OPC UA. Les clients OPC UA peuvent accéder à ces nœuds OPC UA.
Vous pouvez également utiliser le type d'interface serveur "Spécification Companion" pour
charger des modèles d'information créés dans votre entreprise avec l'outil SiOME, par
exemple.
Si vous mettez en œuvre une spécification Companion précise dans votre projet, vous
appliquez les définitions de cette spécification Companion en tant qu'interface serveur
dans votre projet.
Pour les interfaces serveur de type Spécification Companion, vous pouvez importer
plusieurs espaces de noms utilisés par la spécification Companion.
Vous trouverez ici (Page 1) d'autres informations sur les spécifications Companion.
Communication
Vous trouverez ici (https://support.industry.siemens.com/cs/ww/fr/view/109755133)

d'autres informations sur SiOME.
– Si des Companion Specifications accèdent à des définitions de type dans des
spécifications dépendantes, utilisez pour cela des espaces de noms de référence. Vous
importez les espaces de noms de référence exactement comme pour les Companion
Specifications.
Voir Créer une interface serveur pour la spécification Companion (Page 1).
– Si vous voulez que des clients OPC UA puissent accéder aux données d'instance de FB
ou d'UDT de la CPU, vous pouvez procéder à ces affectations de données d'instance
automatiquement à partir de TIA Portal version V17. Il vous suffit de mapper les types
de FB ou les UDT sur des types de données OPC UA appropriés d'un espace de noms de
référence importé. Pour que ce mappage soit possible, cochez l'option "Générer des
nœuds OPC-UA sur la base du mappage des données locales" dans la boîte de dialogue
pour la création d'une interface de serveur OPC UA de type Companion
Specification/espace de noms de référence.
Voir Créer des nœuds OPC UA sur la base des mappages de données locales de types de
FB et d'UDT (Page 1)
• Interface serveur personnalisée
Pour ce type d'interface serveur, vous regroupez des nœuds OPC UA d'un serveur OPC UA
en une unité.
Vous vous référez pour cela aux indications pour votre projet ou aux exigences concernant
votre machine ou votre installation.
Vous trouverez ici (Page 1) d'autres informations sur l'interface serveur personnalisée.
Machine de moulage par injection comme exemple pour la spécification Companion

Dans cet exemple, une interface serveur contient les éléments suivants :
• Nœuds OPC UA que vous pouvez lire avec un client OPC UA afin d'obtenir des informations
sur cette machine de moulage par injection (provenant de variables API en lecture)
• Nœuds OPC UA dans lesquels vous pouvez écrire avec un client OPC UA afin de
transmettre des valeurs dans la machine de moulage par injection (dans des variables API
en écriture)
• Nœuds OPC UA que vous pouvez appeler avec un client OPC UA afin de démarrer des
fonctions de la machine de moulage par injection (par le biais de méthodes de serveur)
Cette interface serveur permet une visualisation standard sur une CPU servant à la commande
d'une machine de moulage.
Les Companion Specifications "OPC UA specifications for plastics and rubber machines"
(auparavant "Euromap") définissent pour les machines de moulage par injection un ensemble
de nœuds OPC UA dont vous pouvez vous servir comme interface serveur.
Les autres nœuds OPC UA de la CPU ne sont pas compris dans cette interface serveur. La vue
d'ensemble est ainsi plus claire.
Communication
Exemple d'interface serveur personnalisée

La CPU doit piloter la production de pièces. Lorsqu'un ordre de production arrive en
provenance du système de conduite de niveau supérieur, la production commence.
Les ordres de production sont transmis par le biais d'une méthode de serveur : un système de
conduite transmet les informations relatives à une pièce en appelant la méthode de serveur
dans la CPU. Cette méthode de serveur démarre également la production.
Le système de conduite, c'est-à-dire le client OPC UA connecté ne doit voir que cette méthode
de serveur. C'est pourquoi vous créez une interface serveur personnalisée dans la CPU et
affectez la méthode de serveur à cette interface serveur. Vous autorisez uniquement cette
interface serveur pour les clients OPC UA et limitez ainsi la vue sur la CPU à cette fonction
spécifique.
9.3.4.2 Utilisation de spécifications OPC UA Companion
Introduction
OPC UA est utilisable de manière universelle : Le standard lui-même ne dit pas comment
désigner les variables API. Ainsi, la programmation et la désignation des méthodes de serveur
appelables via OPC UA sont laissées à l'appréciation de chaque utilisateur (développeur
d'application).
Modèles d'information et standardisation pour différents appareils et secteurs

En présence de plusieurs applications similaires, le concept "modulaire OPC UA" se prête
particulièrement bien à la standardisation des interfaces d'appareils ou de machines.
Plusieurs organisations et groupes de travail ont œuvré pour la normalisation et développé
diverses spécifications OPC UA Companion.
Ces spécifications définissent :
• à l'aide de quels objets, méthodes et variables décrire un appareil ou une machine
typique.
• quel espace de noms est prévu pour les objets nommés.
Les machines sont typiquement structurées en unités fonctionnelles ou technologiques et les
unités sont standardisées.
Aux exploitants de machines et d'installations, les spécifications Companion offrent
l'avantage d'une interface unique. Par exemple, tous les plots de lecture RFID respectant la
spécification AutoID peuvent être intégrés de la même manière. Autrement dit, tous les plots
de lecture RFID conformes à la spécification AutoID peuvent communiquer de la même
manière avec les clients OPC UA, quel que soit le fabricant du plot de lecture.
La spécification Euromap 77 Companion développée pour les machines de moulage par
injection constitue un autre exemple de spécification Companion.
Communication
Le chapitre suivant décrit, en prenant pour exemple Euromap 77, comment vous pouvez
intégrer une spécification Companion dans STEP 7 (TIA Portal) et créer des variables API à cet
effet.
Remarque
EUROMAP et la Fondation OPC ont établi le Joint Working Group "OPC UA Plastics and
Rubber Machinery".
Les recommandations EUROMAP existantes 77 (data exchange between injection moulding
machines and MES), 82.1 (temperature control devices) et 83 (general definitions) ont été
publiées sous l'égide neutre de la Fondation OPC en tant qu'OPC 40077, 40082-1 et 40083.
Le changement majeur est la modification de l'espace de noms, par ex. pour EUROMAP 77 :
Actuellement "http://opcfoundation.org/UA/PlasticsRubber/IMM2MES/".
Les exemples énumérés ci-après utilisent les désignations et renvois valables jusqu'ici.
Exemple Euromap 77 (actuellement : OPC 40077)

Euromap 77 et la norme OPC 40077 qui lui succède normalisent l'échange de données entre
les machines de moulage par injection et le système MES (Manufacturing Execution System)
supérieur. Ainsi, le MES peut relier en même temps toutes les machines de moulage par
injection inférieures.
L'interface de données unique facilite l'intégration de machines de moulage par injection
dans une installation.
Utilisation de la spécification Companion : Vue d'ensemble

Euromap 77 est décrit dans le fichier XML fourni par OPC UA
"Opc_Ua.EUROMAP77.NodeSet2.xml".
Remarque
Euromap 77, Euromap 83 et OPC UA for Devices (DI)
Avec la Release Candidate 2, une partie des définitions a été transférée de Euromap 77 vers
Euromap 83 (actuellement OPC 40083). C'est pourquoi vous devez aussi importer l'interface
serveur OPC UA de Euromap 83.
"OPC UA for Devices" est un modèle d'information universel pour la configuration de
matériels et de logiciels. Servant aussi de base à d'autres standards Companion, ce modèle
d'information est également importé.
Vous trouverez les fichiers XML fournis par OPC UA ici :

Euromap77 (http://www.euromap.org/euromap77)
Euromap83 (http://www.euromap.org/euromap83)
OPC UA for Devices (https://opcfoundation.org/UA/schemas/DI/)
Ces fichiers XML définissent une interface OPC UA d'une machine de moulage par injection,
qui est conforme à Euromap 77.
Communication
Utilisation d'Euromap 77 : vue d'ensemble

Procédez comme suit pour utiliser Euromap 77 :
1. Avec le programme SiOME, créez un fichier XML dans lequel vous créez une instance de
type "IMM_MES_InterfaceType".
La marche à suivre pour ce faire est décrite ci-après, sous "Étape 1 : Créer des instances
dans SiOME".
2. Créez dans STEP 7 (TIA Portal) des variables API et des méthodes de serveur qui
correspondent à l'instance de type "IMM_MES_InterfaceType" (créée à l'étape 1).
La marche à suivre pour ce faire est décrite ci-après, sous "Étape 2 : Créer des variables API
dans STEP 7".
Vous trouverez des exemples de nœuds OPC UA avec les variables API correspondantes au
chapitre "Créer une interface serveur pour la spécification Companion (Page 1)".
3. Ajoutez une nouvelle interface serveur de type Spécification Companion dans STEP 7 (TIA
Portal) et importez le fichier XML que vous avez créé à l'étape 1.
La marche à suivre pour ce faire est décrite au chapitre "Créer une interface serveur pour
la spécification Companion (Page 1)".
4. Affectez aux nœuds OPC UA de la nouvelle interface serveur les variables API
correspondantes que vous avez créées à l'étape 2.
La marche à suivre pour ce faire est également décrite au chapitre "Créer une interface
serveur pour la spécification Companion (Page 1)".
Étape 1 : Créer des instances dans SiOME

Ce paragraphe décrit comment utiliser le programme gratuit "SiOME" (Siemens OPC UA
Modeling Editor).
Avec SiOME, vous pouvez créer un fichier OPC UA décrivant une interface serveur (un modèle
d'informations).
Vous trouverez le lien de téléchargement de SiOME et des explications ici
Marche à suivre dans STEP 7

Pour utiliser une nouvelle interface serveur, importez l'interface serveur dans le projet STEP 7
(voir chapitre "Créer une interface serveur pour la spécification Companion (Page 1)").
Lorsque le projet est chargé dans la CPU, la nouvelle interface serveur est disponible pour les
clients OPC UA.
Communication
Marche à suivre dans SiOME 1.7.3
Remarque
La description suivante présente les étapes dans SiOME 1.7.3.
Les versions suivantes de SiOME simplifient la création de DB, structures, variables ou
méthodes correspondants dans le programme utilisateur. Vous pouvez par ex. transférer des
données par glisser-déposer de SiOME vers TIA Portal (programme utilisateur). Les variables
etc. sont déjà correctement mappées ou les éléments FB correspondants sont également
générés correctement pour les méthodes dans le programme utilisateur.
Téléchargez la version actuelle de SiOME sous le lien de téléchargement indiqué ci-dessus et
suivez les instructions dans la documentation qui y est fournie.
La description suivante présente les étapes dans SiOME 1.7.3.

Pour utiliser Euromap 77, créez un fichier XML avec une instance de
"IMM_MES_InterfaceType".
Ce n'est qu'après l'instanciation du type d'objet que la variante (le modèle d'information) de la
machine réelle est créée dans la plage d'adresses du serveur OPC UA.
Le type d'objet "IMM_MES_InterfaceType" est le type d'objet racine d'Euromap 77. "IMM"
correspond à "Injection Moulding Machine".
1. Téléchargez les fichiers "Opc_Ua.EUROMAP77.NodeSet2.xml" et
"Opc_Ua_EUROMAP83_NodeSet2.xml" du site Web d'Euromap (voir ci-dessus).
2. Téléchargez le fichier "Opc.Ua.Di.NodeSet2.xml" du site Web de la Fondation OPC.
Le fichier "Opc.Ua.Di.NodeSet2.xml" contient les définitions de type utilisées par Euromap
77 .
3. Démarrez SiOME.
4. Importez d'abord l'espace de noms "http://opcfoundation.org/UA/DI/".
Cliquez à cet effet sur le bouton "Import XML" dans la zone "Information model".
Figure 9-27 Bouton "Import XML" dans SiOME
SiOME affiche la boîte de dialogue d'ouverture de fichier.

5. Sélectionnez le fichier "Opc.Ua.Di.NodeSet2.xml" et cliquez sur le bouton "Ouvrir" pour
l'importer.
Résultat : SiOME importe le fichier XML et indique dans la zone "Namespaces" l'espace de
noms "http://opcfoundation.org/UA/DI/".
L'espace de noms standard "http://opfoundation.org/UA/" est toujours disponible dans
SiOME et ne doit pas être importé.
Communication
6. Importez maintenant l'espace de noms "http://www.euromap.org/euromap83/".

Cliquez pour cela de nouveau dans la zone "Information model" sur le bouton "Import
XML".
Sélectionnez le fichier "Opc_Ua.EUROMAP83.NodeSet2.xml".
Résultat : SiOME importe le fichier XML et indique maintenant dans la zone "Namespaces"
également l'espace de noms "http://www.euromap.org/euromap83/".
7. Importez maintenant l'espace de noms "http://www.euromap.org/euromap77/".
Cliquez pour cela de nouveau dans la zone "Information model" sur le bouton "Import
XML".
Sélectionnez le fichier "Opc_Ua.EUROMAP77.NodeSet2.xml".
8. Créez un espace de noms propre à votre projet.
À cet effet, cliquez avec le bouton droit de la souris sur "OPC UA Modelling Editor Project"
ou sur "Namespaces" dans la zone "Namespaces" et sélectionnez "Add Namespace".
SiOME ouvre la boîte de dialogue "Add Namespace".
9. Saisissez le nom d'un nouvel espace de noms.
Dans l'exemple, l'espace de noms utilisé est "YourCompany.org".
SiOME affiche maintenant aussi le nouvel espace de noms :
Figure 9-28 Affichage de l'espace de noms dans SiOME
10.Créez une instance du type d'objet racine IMM_MES_InterfaceType de la spécification

Euromap 77 Companion.
À cet effet, cliquez avec le bouton droit de la souris sur le répertoire "DeviceSet" dans la zone
"Information model" et sélectionnez "Add Instance".
SiOME affiche la boîte de dialogue "Add Instance".
11.Pour "Name", indiquez un nom explicite pour la nouvelle instance.
Dans l'exemple, saisissez "IMM_Manufacturer_01234" :
Pour "TypeDefinition", choisissez "IMM_MES_InterfaceType".
Ce type d'objet est le type d'objet racine d'Euromap 77 : lorsque vous créez une instance
de ce type d'objet, vous utilisez Euromap 77 une fois dans la plage d'adresses de votre
serveur OPC UA.
Communication
12.Cliquez sur "OK".

SiOME affiche la nouvelle instance "IMM_Manufacturer_01234" sous "DeviceSet" dans la
zone "Information model" :
Figure 9-29 Affichage de l'information model
13.Créez une instance du type d'objet "InjectionUnitType".

À cet effet, cliquez avec le bouton droit de la souris sur le répertoire "InjectionUnits" dans
la zone "Information model" et sélectionnez "Add Instance".
SiOME affiche la boîte de dialogue "Add Instance".
Pour "Name", indiquez un nom explicite pour l'instance.
Dans l'exemple, saisissez "InjectionUnit_1" :
Pour "TypeDefinition", choisissez "InjectionUnitType".
Cliquez sur "OK".
14.Dans le répertoire "Moulds", créez une nouvelle instance "Mould_1" du type d'objet
"MouldType".
15.Dans le répertoire "PowerUnits", créez une nouvelle instance "PowerUnit_1" du type d'objet
"PowerUnitType".
Communication
16.Enregistrez le fichier XML.

Cliquez à cet effet sur le bouton "Quick save" dans la zone "Information model" :
Figure 9-30 Bouton "Quick save" dans SiOME
17.Exportez le fichier XML.

Cliquez à cet effet sur le bouton "Export XML" dans la zone "Information model".
Figure 9-31 Bouton "Export XML" dans SiOME
SiOME affiche la boîte de dialogue "Export XML".

18.Laissez tous les espaces de noms activés et cliquez sur "OK".
SiOME ouvre la boîte de dialogue "Enregistrer sous".
19.Choisissez un nom explicite et enregistrez le fichier exporté.
Dans l'exemple, donnez le nom "IMM_Manufacturer_01234" au fichier XML.
Résultat :
Vous avez créé un fichier XML qui utilise une fois la spécification Companion "Euromap 77"
(avec une instance).
Communication
Étape 2 : Créer des variables API dans STEP 7 pour l'instance Euromap 77
Pour Euromap 77, vous devez fournir dans votre programme utilisateur des variables API et
des méthodes de serveur qui correspondent à l'instance de type "IMM_MES_InterfaceType".
Procédez comme suit pour créer des variables API pour l'instance de type
1. Créez un type de données utilisateur (UDT).
La figure suivante montre un exemple de début du type de données utilisateur
"InjectionUnit".
Ce type de données a la même structure que "InjectionUnit" dans le type
Veillez à utiliser des types de données SIMATIC qui sont compatibles avec les types de
données OPC UA (voir "Correspondances des types de données" ci-après).
Figure 9-32 Créer un UDT dans STEP 7
2. Ajoutez un nouveau bloc de données global à votre projet STEP 7.

Dans l'exemple, donnez le nom "IMM_Manufacturer_01234" au bloc de données afin
d'établir un lien avec la machine de moulage par injection concernée en précisant le
constructeur et le numéro de série.
3. Créez un nouvel élément dans ce bloc de données.
Dans l'exemple, donnez le nom "InjectionUnit_1" à cet élément.
4. Affectez le nouveau type de données utilisateur "InjectionUnit" à cet élément.
Résultat
Vous avez créé une variable pour Euromap 77 dans le bloc de données
"IMM_Manufacturer_01234" de votre projet STEP 7.
Communication
9.3.4.3 Créer une interface serveur pour la spécification Companion

Pour des informations de base sur les spécifications Companion, référez-vous au chapitre
"Utilisation de spécifications OPC UA Companion (Page 1)". Vous y trouverez également une
description détaillée de l'utilité de la spécification Companion Euromap 77 qui met à
disposition un modèle pour les machines de moulage par injection.
La CPU S7-1500 peut piloter au moyen de ce Companion standard par ex. une machine de
moulage par injection et permettre à un client OPC UA, par ex. un système MES de niveau
supérieur, à une interface l'accès aux fonctions et variables de la machine de moulage par
injection.
Une interface serveur OPC UA de type "Companion Standard" limite l'accès des clients
strictement aux fonctions et variables qui sont par ex. nécessaires pour les systèmes de
niveau supérieur (systèmes MES).
La description suivante montre comment créer dans STEP 7 (TIA Portal) une interface serveur
qui contient uniquement la spécification Companion Euromap 77.
Si vous souhaitez en plus rendre accessibles aux clients OPC UA d'autres variables ou
méthodes que celles nécessaires à la gestion d'une machine de moulage par injection, créez
simplement une interface serveur OPC UA supplémentaire. Vous pouvez ainsi donner une
organisation claire à la CPU comme serveur OPC UA.
Créer une interface serveur pour une spécification Companion

Pour créer une interface serveur pour une spécification Companion dans STEP 7 (TIA Portal),
1. Sélectionnez la CPU que vous voulez utiliser comme serveur OPC UA.
2. Dans la navigation du projet, cliquez sur "Communication OPC UA > Interfaces serveur".
3. Double-cliquez sur "Ajouter une nouvelle interface serveur".
4. Cliquez sur le bouton "Spécification Companion" pour sélectionner ce type d'interface
serveur.
Cette boîte de dialogue contient un nom général pour la nouvelle interface serveur, par
exemple "Interface-serveur_1".
Communication
5. Modifiez le nom de l'interface serveur afin qu'il soit évocateur dans le projet.
Le nom doit avoir la structure suivante selon Euromap 77 :
"IMM_<constructeur>_<numéro de série>".
L'exemple utilise le nom "IMM_Manufacturer_01234".
6. Dans le champ "Importer le fichier XML", sélectionnez un fichier XML contenant la

description d'un modèle d'information.
Le chapitre "Utilisation de spécifications OPC UA Companion (Page 1)" décrit comment
créer un tel fichier XML avec l'outil SiOME.
La figure suivante présente un extrait du modèle d'information :
"IMM_MANUFACTURER_0123456" une instance du type "IMM_MES_InterfaceType", défini
par Euromap 77 . "InjectionUnit_1" est une instance du type "InjectionUnitType" de la
spécification Euromap 77.
Communication

STEP 7 (TIA Portal) importe le modèle d'information décrit dans le fichier XML sélectionné.
Une erreur se produit si on utilise dans le fichier XML importé des définitions de type qui
n'existent pas encore dans STEP 7 (TIA Portal) et qui ne sont pas non plus présentes dans
le fichier XML importé.
Dans l'exemple, on importe un fichier XML qui utilise des définitions de type définies dans
les espaces de noms (Namespaces) suivants :
– http://opcfoundation.org/UA/DI/
– http://www.euromap.org/euromap83/
– http://www.euromap.org/euromap77/
Astuce : STEP 7 indique les espaces de noms manquant dans la partie inférieure de
l'éditeur d'interfaces OPC UA (onglet "Propriétés").
Sélectionnez l'interface serveur dans la navigation du projet (dans l'exemple :
IMM_Manufacturer_01234) et sélectionnez la zone "Espaces de noms" dans la fenêtre
d'inspection. Les espaces de noms manquants sont sélectionnés.
Si un ou plusieurs espaces de noms manquent dans votre projet STEP 7, créez une
nouvelle interface serveur de type "Espace de noms de référence" pour chaque espace de
noms.
Procédez à cet effet comme décrit au chapitre "Créer une interface serveur pour un espace
de noms de référence (Page 1)".
Si tous les espaces de noms de référence existent, STEP 7 affiche le tableau sans erreur :
Communication
8. Faites glisser les éléments OPC UA de la partie droite (éléments OPC UA) dans la partie
gauche du tableau (interface serveur OPC UA), afin que ces éléments (variables API locales)
soient associés aux nœuds OPC UA correspondants d'Euromap 77.
La figure suivante montre un extrait de l'affectation des données locales (variables API)
aux nœuds OPC UA d'Euromap 77 :
IMPORTANT
Vérifier la présence de nœuds de l'interface serveur OPC UA dans le mappage des
données locales
Si des affectations non valides (mappages) existent dans l'interface de serveur, cela peut
entraîner des opérations de lecture et d'écriture incorrectes. Vérifiez les affectations et
effectuez un contrôle de cohérence.
Communication
Informations sur l'interface serveur

L'éditeur pour la configuration de l'interface serveur OPC UA est organisé sous forme de
tableau et fournit les informations suivantes :
• Nom
Le nœud le plus haut (nœud racine) a pour nom "IMM_Manufacturer_01234" dans
l'exemple. Lorsqu'un client navigue dans la plage d'adresses du serveur, ce nœud
constitue le dossier contenant tous les nœuds de niveau inférieur. BrowseName et
DisplayName de ce nœud dépendent du nom que vous avez attribué pour l'interface
serveur.
Ce nom désigne ici par ex. la machine de moulage dans son ensemble. Il s'agit du nom de
l'instance utilisée ici de la spécification Companion Euromap 77 Selon la spécification
Companion, le nom d'instance doit commencer par "IMM" ; vient ensuite le nom du
constructeur de la machine de moulage par injection, puis le numéro de série de la
machine. De cette manière, une machine peut être identifiée de manière univoque.
Les noms de tous les autres nœuds (de niveau inférieur) sont définis par la spécification
(dans l'exemple ci-dessus parEuromap 77). Ces noms de nœud ne peuvent pas être
modifiés. Cela garantit une vue uniforme de toutes les machines de moulage qui
répondent aux exigences de la spécification.
• Type de nœud
Type de nœud OPC UA. Le type est défini par la spécification Companion utilisée.
STEP 7 affiche un type de nœud en couleur dans le tableau dans les cas suivants :
– si le fichier XML importé ne contient pas de définition correspondante ou
– si l'espace de noms dans lequel la définition de type a été faite n'est pas présent dans
STEP 7.
Dans ce cas, vous créez une interface serveur de type "Espaces de noms de référence"
pour chaque espace de noms manquant.
Vous trouverez les espaces de noms manquants sous "Espaces de noms" dans les
propriétés de l'interface serveur.
• Données locales
STEP 7 affiche le bloc de données qui est affecté aux nœuds OPC UA. La CPU lit les valeurs
pour les nœuds OPC UA dans ce bloc de données.
Si un bloc de données est affiché en couleur (par ex. après un contrôle de cohérence), cela
signifie qu'il ne figure pas dans la CPU.
Dans ce cas, vous devez créer le bloc de données manquant dans la CPU (dans le
programme utilisateur) et lui attribuer des valeurs.
• Type de données
Type de données SIMATIC de la variable API (par ex. élément d'un bloc de données) dans
la CPU dans lequel la valeur d'un nœud OPC UA (de type UAVariable) est lue ou dans
lequel une valeur est écrite.
Communication
Générer les données locales

Vous avez la possibilité de générer les données locales pour tous les nœuds ou pour des
nœuds choisis de l'interface serveur qui ne sont pas déjà associés à des données locales de la
CPU (qui ne sont pas mappés). Les nouvelles données locales générées sont
automatiquement mappées.
Vous déclenchez la génération automatique des données locales en cliquant sur le bouton
"Générer les données locales" (tous les nœuds pas encore mappés) ou en sélectionnant des
nœuds individuels puis la commande "Générer les données locales" du menu contextuel.
Bouton "Générer les données locales" :
Figure 9-33 Bouton "Générer les données locales"
Vous pouvez uniquement générer des nœuds qui peuvent être mappés sur les données
locales, et donc pas d'objets, de dossiers, de méthodes ou d'arguments d'entrée/sortie de
méthodes.
Après avoir cliqué sur le bouton ou sélectionné le menu contextuel, vous devez indiquer dans
la boîte de dialogue suivante si les données locales doivent être créées dans un nouveau bloc
de données ou dans un bloc existant.
Contrôle de cohérence
Vous avez la possibilité de vérifier la cohérence de l'interface serveur.
STEP 7 (TIA Portal) vérifie alors si des variables API (blocs de données) avec des types de
données SIMATIC compatibles sont affectées aux nœuds OPC UA de l'interface serveur.
Pour contrôler la cohérence de l'interface serveur, cliquez sur l'icône suivante dans la barre
d'outils de l'éditeur de l'interface serveur OPC UA :
Figure 9-34 Bouton "Contrôle de cohérence"
Exporter interface
Vous avez la possibilité d'exporter l'interface serveur OPC UA dans un fichier XML. Ce fichier
XML contient toutes les définitions de type de données référencées par l'interface serveur.
Pour exporter l'interface serveur OPC UA, cliquez sur l'icône suivante dans la barre d'outils de
l'éditeur de l'interface serveur OPC UA :
Figure 9-35 Bouton "Exporter interface"
Communication
9.3.4.4 Créer une interface serveur personnalisée
Introduction
Cette description est basée sur l'exemple suivant :
Une enceinte de protection entoure la cellule de fabrication "Cell_1". L'enceinte comporte une
porte "Gate_1".
Une CPU S7-1500 commande toute la cellule de fabrication et contrôle également l'accès par
la porte Gate_1.
Un robot emballe des médicaments dans des cartons dans la cellule de fabrication et empile
ensuite les cartons sur des palettes.
Des chariots élévateurs autoguidés transportent les palettes dans l'entrepôt central en
passant par la porte Gate_1.
La CPU publie une interface serveur par le biais de laquelle des systèmes de transport
autoguidés déclenchent l'ouverture de la porte Gate_1.
L'interface serveur contient la méthode de serveur "smOpenGate" pour ouvrir la porte, ainsi
que la variable "Gate_1_State" qui indique l'état de la porte (ouverte ou fermée).
Créer une interface serveur personnalisée

Pour créer une interface serveur, procédez comme suit :
1. Sélectionnez la CPU que vous utilisez comme serveur OPC UA et que vous avez configurée.
2. Cliquez sur "Communication OPC UA > Interfaces serveur".
STEP 7 affiche la boîte de dialogue suivante :
Figure 9-36 Ajouter une interface serveur
4. Modifiez le nom de l'interface serveur afin qu'il soit évocateur dans le projet.
Dans l'exemple, changez le nom "Interface serveur_1" proposé par STEP 7 en "Cell_1".
5. Cliquez sur le bouton "Interface serveur", puis sur "OK".
Communication
6. Cliquez sur le triangle devant "Blocs de programme" dans la zone "Éléments OPC UA" pour
ouvrir le dossier "Blocs de programme".
STEP 7 affiche le tableau suivant pour édition :
Figure 9-37 Éditer l'interface serveur
L'éditeur est divisé en deux zones :

– Interface serveur OPC UA
Sur le côté gauche se trouve le nœud racine de l'interface serveur "Cell_1".
Cette interface est encore vide, car aucun élément OPC UA n'y a encore été ajouté.
– Éléments OPC UA
Sur le côté droit se trouvent les éléments OPC UA.
Les éléments OPC UA sont des objets créés jusqu'ici dans le projet STEP 7 et qui
présentent la propriété "Accessible depuis IHM/OPC UA".
Vous pouvez insérer les éléments OPC UA dans la nouvelle interface serveur "Cell_1".
7. Faites glisser des éléments OPC UA dans la ligne "<Ajouter nouveau>" de la nouvelle
interface serveur.
Remarque
De manière générale : lorsque vous déposez des blocs de données ou des objets
technologiques dans la zone gauche du tableau, STEP 7 (TIA Portal) crée un objet dans
l'interface serveur. Les éléments des blocs de données sont disposés sous forme de nœuds
distincts en dessous.
Si vous ajoutez des structures dans la zone gauche du tableau, STEP 7 crée un nœud pour
l'ensemble de la structure et différents nœuds pour chaque élément de la structure.
Cela s'applique également aux tableaux : dans ce cas, STEP 7 crée aussi un nœud pour
l'ensemble du tableau et différents nœuds pour chaque élément du tableau.
Si vous ajoutez une méthode dans la zone gauche du tableau, STEP 7 crée un nœud
unique ; les arguments de la méthode ajoutée sont affichés pour information.
Dans l'exemple, vous faites glisser la variable "Gate_1_State" de la partie droite vers
"<Ajouter nouvelle>" dans la partie gauche.
Puis, vous faites glisser la méthode de serveur dans la partie gauche.
Communication
Cette méthode de serveur se trouve à l'intérieur du bloc de données "smOpenGate_DB

[DB3]" dans la partie droite.
Le dialogue affiché par STEP 7 (TIA Portal) se présente ainsi :
Figure 9-38 Ajouter des éléments OPC UA à l'interface serveur
IMPORTANT
Vérifier la présence de nœuds de l'interface serveur OPC UA dans le mappage des
données locales
Si des affectations non valides (mappages) existent dans l'interface de serveur, cela peut
entraîner des opérations de lecture et d'écriture incorrectes. Vérifiez les affectations et
effectuez un contrôle de cohérence.
Limiter la partie visible du serveur OPC UA

Par le choix des éléments OPC UA, vous pouvez limiter la partie visible du serveur OPC UA et
donc les possibilités des clients OPC UA.
Dans l'interface serveur de l'exemple, il manque le bloc de données "Robot_1" parce que les
chariots élévateurs n'ont pas besoin d'accéder aux méthodes de serveur et aux variables du
robot.
Dans ce cas, il est plus pertinent de désactiver l'interface de serveur standard (espace de
noms SIMATIC) dans les propriétés OPC UA de la CPU S7-1500, afin qu'il soit impossible
d'accéder aux nœuds filtrés par un autre chemin.
Figure 9-39 Désactiver l'interface serveur standard
Communication
Vous avez également la possibilité de désactiver la visibilité de chaque interface serveur OPC
UA paramétrée dans les propriétés de l'interface serveur et d'empêcher ainsi que cette
interface serveur puisse être utilisée en fonctionnement par des clients.
• Sélectionnez, pour ce faire, l'interface serveur, puis, avec la touche droite de la souris,
choisissez la commande "Propriétés".
Cette option permet, p. ex., de définir plusieurs interfaces de serveur de manière centralisée
et de charger et d'activer uniquement celle qui est nécessaire.
Une fois définie, vous pouvez copier une interface de serveur sur une autre CPU en utilisant la
fonction Glisser-déposer dans la navigation de projet.
Figure 9-40 Désactiver la visibilité de l'interface serveur
Communication
Informations sur l'interface serveur

L'éditeur prévu pour l'édition de l'interface serveur OPC UA est organisé sous forme de
tableau et fournit les informations décrites dans les paragraphes ci-après.
Veuillez noter que toutes les colonnes ne sont pas affichées au départ. Vous déterminez ce
qu'il faut afficher en cliquant avec le bouton droit de la souris sur la ligne d'en-tête du
tableau.
Si une ligne est marquée, vous pouvez incruster les attributs OPC UA du nœud dans la fenêtre
d'inspection (zone "Attributs OPC UA"), p. ex. ID de nœud, catégorie de nœud, type de nœud
et description.
• BrowseName
Le nom de l'interface serveur personnalisée, qui est indépendant de la langue, figure tout
en haut (BrowseName). Ce nom peut être choisi librement.
Sous le nom de l'interface se trouvent les noms (BrowseNames) des différents nœuds OPC
UA qui ont été ajoutés à l'interface serveur.
Vous ne pouvez pas changer le nom d'un nœud OPC UA dans cette boîte de dialogue. Les
noms proviennent du projet STEP 7.
Vous pouvez supprimer un nœud OPC UA du tableau. Il n'appartient alors plus à l'interface
serveur et n'est plus visible pour les clients OPC UA.
• DisplayName
Comme pour le BrowseName, toutefois ce nom peut être traduit et, le cas échéant, affiché
dans la langue correspondante.
• ID de nœud
NodeId du nœud OPC UA, p. ex. http://Server-Node_1; i=1
• Type de nœud
Type du nœud OPC UA, par exemple BOOL, BYTE, INT, etc.
Ces types de nœuds ont été définis par Siemens et non par la Fondation OPC. La
Fondation OPC utilise, par exemple, BOOL pour le type de nœud booléen. BOOL est
directement dérivé de "booléen".
Le type de nœud indiqué ne peut pas être modifié dans cette boîte de dialogue. Si vous
voulez utiliser un autre type de nœud, vous devez modifier le type de la variable API
correspondante dans le projet STEP 7.
• Type de données
Le type de données SIMATIC utilisé dans le projet STEP 7 est indiqué, par exemple Bool,
Byte, Int, etc.
• Niveau d'accès
– Si un nœud OPC UA est une variable (type UAVariable), le nœud peut être accessible
uniquement en lecture (RD) ou en lecture/écriture (RD/WR).
– Si un nœud OPC UA est une méthode (type UAMethod), il peut toujours être appelé.
• Données locales
Type de données SIMATIC du bloc de données dans la CPU dans lequel la valeur d'un
nœud OPC UA (de type UAVariable) est lue ou dans lequel une valeur est écrite.
Communication
Générer les données locales

Vous avez la possibilité de générer les données locales pour tous les nœuds ou pour des
nœuds choisis de l'interface serveur qui ne sont pas déjà associés à des données locales de la
CPU (qui ne sont pas mappés). Les nouvelles données locales générées sont
automatiquement mappées.
Vous déclenchez la génération automatique des données locales en cliquant sur le bouton
"Générer les données locales" (tous les nœuds pas encore mappés) ou en sélectionnant des
nœuds individuels puis la commande "Générer les données locales" du menu contextuel.
Bouton "Générer les données locales" :
Figure 9-41 Bouton "Générer les données locales"
Vous pouvez uniquement générer des nœuds qui peuvent être mappés sur les données
locales, et donc pas d'objets, de dossiers, de méthodes ou d'arguments d'entrée/sortie de
méthodes.
Après avoir cliqué sur le bouton ou sélectionné le menu contextuel, vous devez indiquer dans
la boîte de dialogue suivante si les données locales doivent être créées dans un nouveau bloc
de données ou dans un bloc existant.
Vous avez la possibilité de contrôler la cohérence de l'interface serveur.
Lors du contrôle de cohérence, STEP 7 vérifie si les nœuds OPC UA de l'interface serveur sont
respectivement affectés à un élément OPC UA approprié (même type de données) ou si
l'élément utilisé est toujours existant dans la CPU.
Pour contrôler la cohérence de l'interface serveur, cliquez sur l'icône suivante dans la barre
d'outils de l'éditeur de l'interface serveur OPC UA :
Figure 9-42 Bouton "Contrôle de cohérence"
Exporter interface
Vous avez la possibilité d'exporter l'interface serveur OPC UA dans un fichier XML. Ce fichier
XML contient toutes les définitions de type de données référencées par l'interface serveur.
Pour exporter l'interface serveur OPC UA, cliquez sur l'icône suivante dans la barre d'outils de
l'éditeur de l'interface serveur OPC UA :
Figure 9-43 Bouton "Exporter interface"
Voir aussi
Modèles de copie pour la communication OPC UA (Page 1)
Communication
9.3.4.5 Types de données pour les spécifications Companion
Correspondances des types de données

Le tableau ci-dessous indique le type de données OPC UA correspondant à chaque type de
données SIMATIC.
Affectez les types de données comme indiqué ci-dessous (type de données SIMATIC - type de
données OPC UA). D'autres affectations ne sont pas autorisées. STEP 7 ne contrôle pas le
respect de cette règle et n'empêche pas une affectation incorrecte. Vous avez la
responsabilité d'assurer une sélection et une affectation conformes à la règle des types de
données.
Vous pouvez également utiliser les types de données énumérés par ex. comme éléments de
structure/types de données utilisateur (UDT) pour les paramètres d'entrée et de sortie de
méthodes de serveur créées automatiquement (UAMethod_InParameters et
UAMethod_OutParameters).
Tableau 9- 3 Correspondances des types de données

BOOL Boolean
SINT SByte
INT Int16
DINT Int32
LINT Int64
USINT Byte
UINT UInt16
UDINT UInt32
ULINT UInt64
REAL Float
LREAL Double
LDT DateTime
WSTRING String
DINT Enumeration (Encoding Int32) et tous les types de don-
nées dérivés
Type de données utilisateur obligatoire UNION et tous les types de données dérivés
(UDT, user-defined data type)
Le type de données utilisateur doit être
défini avec le préfixe "Union_", par
exemple "Union_MyDatatype" (voir
l'exemple après le tableau).
Le premier élément (Selector) dans cet
UDT doit être du type de données
"UDINT".
Communication
Type de données utilisateur requis pour UNION

La figure suivante montre la variable "MyVariable" qui possède le type de données
"Union_MyDatatype".
Ce type de données SIMATIC correspond à une variable OPC UA du type de données UNION.
La figure montre un exemple de déclaration : "Union" accepte un tableau d'octets (ByteArray)
lorsque "Selector" est égal à 1 et une chaîne WString lorsque "Selector" est égal à 2.
Utilisation d'autres types de données de base OPC UA

En plus des types de données OPC UA cités au paragraphe "Mappage de types de données" et
de leurs correspondances côté SIMATIC, il existe aussi les types de données de base OPC UA
suivants, que vous pouvez également utiliser :
• OpcUa_NodeId
• OpcUa_QualifiedName
• OpcUa_Guid
• OpcUa_LocalizedText
• OpcUa_ByteString
• OpcUa_XmlElement
Conditions requises pour l'utilisation des types de données de base cités ci-dessus comme
variables dans le programme utilisateur : Les types de données de base doivent être présents
sous forme de types de données complexes possédant exactement la même structure que les
types de données de base OPC UA correspondants.
• OpcUa_NodeId et OpcUa_QualifiedName sont présents comme type de données système ;
c'est pourquoi vous pouvez utiliser ces types de données comme variables mais aussi
comme éléments d'une structure.
• Pour les autres types de données de base, vous devez créer un type de données API
conformément à la spécification OPC UA et l'utiliser ensuite comme élément dans une
structure afin que les types de données des éléments puissent être résolus. L'apparence
que doit prendre le type de données API respectif est décrite ci-après pour les différents
types de données de base. Une structure de données dans laquelle est utilisé l'UDT
"LocalizedText", est par exemple "EUInformation". EUInformation contient des
informations sur les EngineeringUnits. Vous trouverez un exemple de mise en œuvre de la
structure de données EUInformation à la fin des descriptions relatives aux types de
données API.
Communication
Type de données système "OPC_UA_NodeId"

Le tableau suivant donne la signification des paramètres pour le type de données de base
OPC UA "OpcUa_NodeId". Vous utilisez OPC_UA_NodeId pour l'identification d'un nœud dans
le serveur OPC UA.
Paramètres Type de données S7 Signification

NamespaceIndex UINT Indice de l'espace de noms du nœud dans le serveur
OPC UA.
Un nœud peut être une variable, par exemple.
Identifier WSTRING[254] La désignation pour le nœud (objet ou variable) dé-
pend du type d'identificateur :
• Identificateur numérique : Le nœud est désigné
par un nombre, par exemple "12345678" .
• Identificateur de chaîne de caractères : Le nœud
est désigné par un nom, par exemple "MaVa-
riable". On distingue les majuscules et les minus-
cules.
IdentifierType UDINT Type d'identificateur
• 0 : identificateur numérique
• 1 : identificateur de chaîne de caractères
• 2 : GUID
• 3 : Opaque
Type de données système "OPC_UA_QualifiedName"

Le tableau suivant présente la structure du type de données système
"OPC_UA_QualifiedName" :
Nom Type de données S7 Signification

NamespaceIndex UINT Indice de l'espace de noms du nom.
Name WSTRING[64] Nom du nœud ou de la variable.
UDT "Guid"
Créez le type de données API suivant pour le type de données de base "Guid". Vous pouvez
également utiliser d'autres valeurs que les valeurs définies par défaut.
Figure 9-44 UDT "Guid"
Communication
UDT "LocalizedText"
Créez le type de données API suivant pour le type de données de base "LocalizedText" :
Figure 9-45 UDT "LocalizedText"
Le EncodingByte indique quels champs (Locale ou Text) sont disponibles :
EncodingByte Signification
0 Les champs Locale et Text sont vides
1 Le champ Locale est renseigné, le champ Text est vide
2 Le champ Locale est vide, le champ Text est renseigné
3 Les champs Locale et Text sont renseignés
UDT "ByteString"
Créez le type de données API suivant pour le type de données de base "ByteString". On choisit
par exemple ici un Array ByteString avec 12 éléments :
Figure 9-46 UDT "ByteString"
Communication
UDT "XmlElement"
Un XmlElement est un fragment XML sérialisé (chaîne de caractères UTF-8).
Créez le type de données API suivant pour le type de données de base "XmlElement" :
Figure 9-47 UDT "XmlElement"
Exemple : Structure de EUInformation avec UDT "LocalizedText"
Figure 9-48 Exemple : Structure de EUInformation avec UDT "LocalizedText"
9.3.4.6 Règles valables pour les fichiers XML OPC UA
Importation de fichiers XML OPC UA exportés dans une CPU S7-1500

Veuillez tenir compte de la remarque suivante lorsque vous importez des interfaces serveur
provenant de l'exportation de fichier XML OPC UA d'une CPU S7-1500.
Remarque
Namespace "http://www.siemens.com/simatic-s7-opcua" verrouillé à l'importation
Vous ne pouvez pas importer d'interface serveur possédant le Namespace
"http://www.siemens.com/simatic-s7-opcua" dans une CPU S7-1500, car ce Namespace est
réservé pour les CPU S7-1500 (interface serveur standard pour SIMATIC) et verrouillé à
l'importation.
Si vous voulez importer une interface serveur possédant le Namespace
"http://www.siemens.com/simatic-s7-opcua", ouvrez l'interface serveur à importer (fichier
XML OPC UA) et modifiez le Namespace à l'endroit correspondant. Vous pouvez ensuite
importer le fichier modifié.
Communication
Intégrité des fichiers XML OPC UA

Les fichiers XML OPC UA représentent la plage d'adresses du serveur. Vous importez ces
fichiers, par ex., dans le contexte de spécifications Companion OPC UA, après l'adaptation à
l'application comme interface serveur, les chargez avec la configuration matérielle dans la
CPU S7-1500 et les testez.
ATTENTION
Pas de contrôle des fichiers XML OPC UA importés
Protégez ces fichiers XML OPC UA contre toute manipulation non autorisée car STEP 7 ne
contrôle pas l'intégrité de ces fichiers.
Recommandation
Pour réduire les risques en cas d'extension ou de modification de la plage d'adresses du
serveur, procédez comme suit :
1. Protégez le projet (navigateur du projet : Paramètres de sécurité > Paramètres).
2. Exportez l'interface serveur correspondante avant l'extension ou la modification.
3. Retravaillez ce fichier XML OPC UA.
4. Réimportez le fichier comme interface serveur.
9.3.4.7 Créer une interface serveur pour un espace de noms de référence
Spécifications Companion et espaces de noms référencés

Un certain nombre de types d'objets OPC UA (ainsi que d'autres définitions) sont définis dans
une spécification Companion. Ces types d'objets sont définis dans des espaces de noms afin
que leurs noms (définitions de type) soient univoques.
Pour utiliser une spécification Companion dans votre projet, vous créez des instances des
types d'objets de cette spécification Companion.
Communication
Il faut pour ce faire que les définitions d'objet soient présentes dans votre projet STEP 7. Si ce
n'est pas le cas, vous devez importer les définitions d'objet. Pour importer toutes les
définitions d'un espace de noms, vous créez dans STEP 7 une interface serveur de type
"Espace de noms de référence" pour chaque espace de noms.
Remarque
EUROMAP et la Fondation OPC ont établi le Joint Working Group "OPC UA Plastics and
Rubber Machinery".
Les recommandations EUROMAP existantes 77 (data exchange between injection moulding
machines and MES), 82.1 (temperature control devices) et 83 (general definitions) ont été
publiées sous l'égide neutre de la Fondation OPC en tant qu'OPC 40077, 40082-1 et 40083.
Les exemples énumérés ci-après utilisent toutefois les désignations et renvois valables
jusqu'ici.
Communication
Exemple Euromap 77 (actuellement OPC 40077)

Vous avez ajouté une interface serveur pour la Companion Specification Euromap 77
(actuellement OPC 40077).
L'interface serveur utilise des types d'objets qui sont définis dans OPC UA DI ainsi que dans
Euromap 83 et Euromap 77 dans les espaces de noms correspondants.
C'est pourquoi vous devez créer dans STEP 7, en plus de l'interface serveur Euromap 77 de
type "Spécification Companion", d'autres interfaces serveur de type "Espaces de noms de
référence" pour chacun des espaces de noms suivants :
• http://opcfoundation.org/UA/DI/
• http://www.euromap.org/euromap83/
La description suivante montre comment procéder.
Créer une interface serveur pour un espace de noms de référence

Procédez comme suit pour créer une interface serveur pour un espace de noms :
2. Cliquez sur "Communication OPC UA > Interfaces serveur".
STEP 7 (TIA Portal) ouvre alors la boîte de dialogue "Ajouter une nouvelle interface
serveur".
Cette boîte de dialogue contient un nom général pour la nouvelle interface serveur, par
exemple "Interface-serveur_1".
4. Choisissez un nom expressif pour la nouvelle interface serveur.
Dans l'exemple, choisissez le nom "Opc.Ua.Di" ou un nom similaire qui fait de toute
évidence référence à l'espace de noms "http://opcfoundation.org/UA/DI/".
Cet espace de noms doit être importé en premier. Il contient des définitions de base (par
exemple, le type d'objet UA "DeviceType").
Communication
5. Pour "Importer le fichier XML", sélectionnez un fichier XML contenant les définitions de
l'espace de noms "http://opcfoundation.org/UA/DI/".
Dans l'exemple, choisissez le fichier "Opc.Ua.Di.NodeSet2.xml". Vous pouvez télécharger
ce fichier sous (https://opcfoundation.org/UA/schemas/DI/)
Opc.Ua.Di.NodeSet2.xml (https://opcfoundation.org/UA/schemas/DI/)
La figure suivante montre la boîte de dialogue avec les entrées :

STEP 7 (TIA) génère alors nouvelle interface serveur.
Vous la trouverez dans le navigateur de projet de STEP 7 (TIA Portal), sous "Communication
OPC UA > Interfaces serveur > Références espace de noms".
Si une spécification Companion utilise d'autres espaces de noms, ajoutez une nouvelle
interface serveur pour chaque espace de noms.
Ajouter d'autres interfaces serveur pour Euromap 77

Vous avez encore besoin des espaces de noms suivants pour Euromap 77 :
Ajoutez d'abord une interface serveur pour l'espace de noms
"http://www.euromap.org/euromap83/".
Cet espace de noms contient des définitions essentielles pour Euromap 77. C'est pourquoi on
en a d'abord besoin ici. Toutes les définitions de cet espace de noms figurent dans le fichier
XML "Opc_Ua.EUROMAP83.NodeSet2.xml" que vous pouvez télécharger du site Web
d'Euromap (www.euromap.org/en/euromap83).
Ajoutez ensuite une interface serveur pour l'espace de noms
"http://www.euromap.org/euromap77". Toutes les définitions de cet espace de noms figurent
dans le fichier XML "Opc_Ua.EUROMAP77.NodeSet2.xml" que vous pouvez également
télécharger du site Web d'Euromap (www.euromap.org/en/euromap77).
Communication
9.3.4.8 Créer des nœuds OPC UA sur la base des mappages de données locales de types de
FB et d'UDT
Si vous voulez que des clients OPC UA puissent accéder aux données d'instance de FB ou
d'UDT de la CPU, vous pouvez procéder à ces affectations de données d'instance
automatiquement à partir de TIA Portal version V17.
Il vous suffit de mapper les types de FB ou les UDT sur des types de données OPC UA
appropriés d'espaces de noms de référence importés. STEP 7 (TIA Portal) génère alors sur la
base de ces mappages les nœuds requis dans l'interface serveur pour chaque instance de FB
ou chaque utilisation d'UDT lors de la compilation.
Si vous étendez votre programme et ajoutez d'autres instances de FB ou utilisations d'UDT ou
supprimez des instances existantes, vous n'avez pas besoin de vous occuper de l'adaptation
de l'interface serveur, car STEP 7 adaptera l'interface serveur automatiquement lors de la
compilation du programme.
Exemple
• Vous créez un bloc fonctionnel (FB) dans le programme utilisateur de la CPU et définissez
les paramètres constituant la "mémoire" du FB dans la zone "Static" de l'interface du FB.
Les instances (valeurs) de ces paramètres doivent être accessibles aux clients OPC UA.
• Vous créez un type de données OPC UA (par exemple, au moyen de SiOME) avec des
éléments qui correspondent par le type de données aux paramètres dans la zone Static de
l'interface du FB. L'ordre des éléments ne joue aucun rôle. Vous importez ensuite le fichier
Nodeset de référence comme espace de noms de référence.
La figure suivante montre l'affectation des éléments par juxtaposition de la vue de l'espace de
noms de référence (interface serveur) et de la vue des éléments OPC UA (programme).
Mappage des types de données (interface FB / interface OPC UA) : principe

La figure ci-après montre l'affectation des éléments du programme utilisateur de la CPU aux
éléments de l'interface serveur OPC UA. Il n'est pas nécessaire que l'ordre des éléments soit
identique.
Communication
Génération automatique des instances de serveur OPC UA dans l'interface serveur :

principe
La figure suivante montre le résultat de la compilation du projet : les instances du programme
utilisateur sont également générées dans l'interface serveur.
Grâce au mappage entre l'information de type FB / UDT et les informations de type OPC UA,
STEP 7 est en mesure de générer toutes les instances existant dans le programme comme
nœuds dans l'interface serveur. Vous pouvez générer ces nœuds conjointement à une
nouvelle interface serveur ou dans une interface serveur existante.
Communication
Règles
• Seuls les éléments FB dans la zone "Static" d'une interface de FB peuvent être mappés sur
des descriptions de type OPC UA.
• Lors du mappage des types de données, les éléments OPC UA doivent toujours être
sélectionnés dans la même interface de FB ou dans le même UDT pour un objet. Le
mappage de FB ou d'UDT différents vers un objet n'est pas autorisé.
Conditions
• Les types de FB utilisés, définis dans la zone "Static" d'un FB, doivent être configurés
comme "accessibles pour OPC UA".
• Les UDT utilisés doivent être configurés comme "accessibles pour OPC UA".
• Il existe un fichier Nodeset (fichier XML) avec les définitions de type de données OPC UA
qui correspondent aux types de FB ou aux UDT définis dans le programme utilisateur et
peuvent être mappés.
• Un programme utilisateur avec les instances de FB et les utilisations d'UDT existe.
Procédure
Procédez comme suit pour mapper un type de données d'un espace de noms de référence sur
un type de FB ou un type de données UDT :
2. Importez le fichier Nodeset préparé (fichier XML) avec les définitions de type comme espace
de noms de référence
(voir AUTOHOTSPOT).
– Dans la boîte de dialogue "Ajouter une nouvelle interface serveur", cochez l'option
"Générer des nœuds OPC-UA sur la base du mappage des données locales".
Des types de FB ou des UDT peuvent être mappés par glisser-déposer sur des
descriptions de type OPC UA uniquement si cette option est activée.
3. Double-cliquez sur l'icône de l'interface serveur de type "Espace de noms de référence" qui
vient d'être créée.
L'éditeur pour le mappage entre l'interface serveur OPC UA et les éléments OPC UA
s'ouvre. L'option "Générer des nœuds OPC-UA sur la base du mappage des données
locales" est activée dans la zone "Mappage des données locales" de la zone Propriétés de
l'éditeur. Si ce n'est pas le cas, activez l'option.
Éditez le champ "Nom d'interface" en cliquant sur les points de suspension à la droite du
champ.
Sélectionnez une interface serveur existante ou générez une nouvelle interface serveur
(bouton "Ajouter").
Avec "Ajouter", une nouvelle interface serveur est générée. Si vous sélectionnez une
interface serveur existante, vous pouvez éditer les propriétés (bouton "Éditer").
Communication
4. Affectez les types de FB ou les UDT existants aux nœuds de l'interface serveur (espace de
noms de référence) en faisant glisser l'élément OPC UA (côté droit de l'éditeur) sur le nœud
correspondant de l'interface serveur (espace de noms de référence, colonne "Données
locales").
Après la compilation, les nouveaux nœuds générés des instances se trouvent dans
l'interface serveur. STEP 7 crée un objet pour chaque DB d'instance. Les éléments générés
se trouvent sous ces objets.
De manière similaire, STEP 7 génère aussi un objet pour chaque DB global qui est généré
lors de l'instanciation d'un UDT.
Créer un programme utilisateur avec des types de FB ou des UDT

La création des FB et des UDT n'est pas expliquée en détails ici. Référez-vous pour cela à la
description de la création d'un programme utilisateur, par exemple la déclaration d'une
interface de bloc et la déclaration de types de données API (UDT).
Le contrôle de cohérence (bouton "Contrôle de cohérence" de l'éditeur) vérifie également le
mappage des types de données et actualise l'affichage des types de données dans la colonne
correspondante de l'éditeur.
9.3.4.9 Remarques sur les capacités fonctionnelles avec les interfaces serveur
Pour l'utilisation des interfaces serveur OPC UA et en fonction des performances de la
CPU S7-1500, vous devez respecter les limitations qui s'appliquent aux objets suivants :
• Nombre d'interfaces serveur
• Nombre de nœuds OPC UA
• Espace mémoire pour le chargement
• Si vous avez implémenté des méthodes : nombre de méthodes de serveur ou d'instances
de méthodes de serveur
Communication
Capacités fonctionnelles pour méthodes et interfaces serveur OPC UA

Le tableau ci-dessous présente les capacités fonctionnelles des CPU S7-1500 à prendre en
considération lors de la compilation et du chargement d'une configuration (vous trouverez les
caractéristiques techniques actualisées de la CPU sur Internet
(https://support.industry.siemens.com/cs/ww/fr/ps/td)).
Le dépassement des capacités fonctionnelles est signalé par un message d'erreur.
Tableau 9- 4 Capacités fonctionnelles pour interfaces serveur OPC UA
Caractéristiques techniques CPU 1510SP (F) CPU 1505 CPU 1507S (F)
CPU 1511 (C/F/T/TF) (S/SP/SP F/SP T/SP TF) CPU 1517 (F/T/TF)
CPU 1512C CPU 1515 (F/T/TF) CPU 1518 (F)
CPU 1512SP (F) CPU 1515 SP PC (F/T/TF)
CPU 1513 (F) CPU 1516 (F/T/TF)
Utilisation de spécifications Companion importées (modèles d'information)
Nombre maximal d'interfaces
serveur OPC UA :
• Type "Spécification Compa- 10 10 10
nion" 20 20 20
• Type "Espace de noms de 10 10 10
référence"
• Type "Interface serveur"
• Nombre maximal de nœuds 1 000 5 000 30 000

(Nodes) OPC UA dans des
interfaces serveur person-
nalisées
• Taille maximale des inter- 1 024 Ko 5 120 Ko 8 192 Ko

faces serveur OPC UA pou-
vant être chargées
Mise à disposition de méthodes
Nombre maximum de mé- 20 50 100
thodes de serveur utilisables ou
nombre maximum d'instances
de méthodes de serveur (ins-
tructions
OPC_UA_ServerMethodPre,
OPC_UA_ServerMethodPost)
Communication
9.3.5 Fournir des méthodes sur le serveur OPC UA
9.3.5.1 Informations utiles sur les méthodes de serveur
Fournir des méthodes de serveur via le programme utilisateur

Vous avez la possibilité de fournir des méthodes via votre programme utilisateur sur le
serveur OPC UA d'une CPU S7-1500 (à partir du firmware V2.5). Les clients OPC UA peuvent
utiliser ces méthodes par ex. pour lancer un ordre de fabrication via l'appel de méthodes de la
CPU S7-1500.
Les méthodes OPC UA, une réalisation de "Remote Procedure Calls", offrent un mécanisme
efficace concernant les interactions entre plusieurs abonnés. Le mécanisme fournit aussi bien
une confirmation de la commande que des valeurs de retour de sorte que vous puissiez vous
passer de la programmation détaillée de processus de handshaking.
Les méthodes OPC UA permettent, par exemple, de transférer des données de manière
cohérente sans bits de déclenchement/handshaking ou de déclencher certaines actions sur
l'automate.
Comment fonctionne une méthode OPC UA ?

En principe, une méthode OPC UA fonctionne comme un bloc fonctionnel avec protection de
savoir-faire qui est appelé par un client OPC UA externe durant l'exécution.
Le client OPC UA ne "voit" que les entrées et sorties définies. L'intérieur du bloc fonctionnel, la
méthode ou l'algorithme restent invisibles pour le client OPC UA externe. Le client OPC UA
reçoit une réponse sous la forme de l'exécution réussie et des valeurs de retour fournies par
le bloc fonctionnel (méthode). Ou un message d'erreur en cas d'échec de l'exécution.
Vous avez en tant que programmeur le plein contrôle et l'entière responsabilité du contexte
de programme dans lequel la méthode OPC UA s'exécute.
Règles de programmation d'une méthode et comportement durant l'exécution

• Veillez à la cohérence des valeurs retournées via la méthode OPC UA et des valeurs
d'entrée fournies par le client OPC UA.
• Tenez compte des règles d'attribution des noms et de la structure des paramètres ainsi
que les types de données utilisables (voir la Description des instructions du serveur OPC
UA).
• Comportement durant l'exécution : Le serveur OPC UA accepte un appel par instance.
Cette instance de méthode n'est de nouveau accessible pour d'autres clients OPC UA
qu'une fois que le programme utilisateur a exécuté l'appel actuel ou qu'un dépassement
de délai s'est produit.
Le chapitre suivant décrit la marche à suivre générale vous permettant de mettre en œuvre
un programme utilisateur comme méthode de serveur.
Communication
Mise en œuvre d'une méthode de serveur

Un programme (bloc fonctionnel) de mise en œuvre d'une méthode de serveur possède la
structure suivante :
1. Interroger l'appel de la méthode de serveur par OPC_UA_ServerMethodPre
Dans votre programme utilisateur (c.-à-d. dans votre méthode de serveur), vous appelez
d'abord l'instruction "OPC_UA_ServerMethodPre".
Cette instruction a les tâches suivantes :
– Elle sert à demander au serveur OPC UA de la CPU si votre méthode de serveur a été
appelée par un client OPC UA.
– Quand la méthode a été appelée et que la méthode de serveur dispose de paramètres
d'entrée, votre méthode de serveur reçoit alors les paramètres d'entrée.
Les paramètres d'entrée de la méthode de serveur proviennent du client OPC UA
appelant.
2. Éditer la méthode de serveur
C'est dans cette section de la méthode de serveur que vous mettez à disposition le
programme utilisateur à proprement parler.
Vous avez les mêmes possibilités que dans d'autres programmes utilisateur (par ex. accès
à d'autres blocs fonctionnels ou à des blocs de données globaux).
Si la méthode de serveur utilise des paramètres d'entrée, ces paramètres d'entrée sont
également disponibles.
Cette section de la méthode de serveur doit être exécutée seulement quand un client OPC
UA a appelé la méthode de serveur.
Après l'exécution réussie de la méthode, vous positionnez les paramètres de sortie de la
méthode de serveur, si la méthode possède des paramètres de sortie.
3. Répondre à la méthode de serveur par OPC_UA_ServerMethodPost
Pour clôturer la méthode de serveur, appelez l'instruction "OPC_UA_ServerMethodPost".
Informez l'instruction "OPC_UA_ServerMethodPost" par des paramètres si le programme
utilisateur a été exécuté ou pas.
Le serveur OPC UA est informé via les paramètres correspondants de l'exécution réussie du
programme utilisateur. Le serveur OPC UA envoie alors les paramètre de sortie de la
méthode de serveur au client OPC UA.
Appelez les instructions "OPC_UA_ServerMethodPre" et "OPC_UA_ServerMethodPost" toujours
par paire, indépendamment de ce que le programme utilisateur est exécuté entre les deux
instructions ou qu'il se poursuit dans le cycle suivant.
Vous trouverez un exemple de mise en œuvre d'une méthode de serveur dans l'aide en ligne
de STEP 7.
Communication
Intégration de la méthode de serveur

La figure suivante montre comment un client OPC UA (A) appelle la méthode de serveur
"Cool" :
La CPU exécute dans le programme utilisateur cyclique l'instance "Cool1" de la méthode de
serveur "Cool" ⑥.
La CPU demande d'abord avec l'instruction "OPC_UA_ServerMethodPre" ④ si un client OPC UA
a appelé la méthode de serveur "Cool" ①.
• Si la méthode de serveur n'a pas été appelée, l'exécution du programme retourne
directement au programme utilisateur cyclique via ④ et ⑥. La CPU poursuit le programme
utilisateur cyclique après "Cool1".
• Si la méthode de serveur a été appelée, cette information parvient via ④ à la méthode de
serveur Cool. La fonctionnalité peut être exécutée dans la méthode de serveur Cool, voir
"<Fonctionnalité méthodes>" sur la figure.
Ensuite, la méthode de serveur informe le firmware (B) via l'instruction
"OPC_UA_ServerMethodPost" ⑤ que l'instruction a été exécutée ③.
Le firmware renvoie l'information via ② au client OPC UA appelant (A).
Communication
La CPU poursuit le programme utilisateur cyclique après "Cool1".
A Appel de la méthode de serveur et gestion de l'information "Done" (méthode arrêtée)

① Appel asynchrone de la méthode de serveur
② Information "Done" asynchrone de la méthode appelée (méthode arrêtée)
B Attente d'appels du client OPC UA, gestions d'appels dans la file d'attente, transfert de l'information "Done" du pro-
gramme utilisateur cyclique au client OPC UA
③ Transfert de données du serveur OPC UA à l'instance de méthode du programme utilisateur, et vice versa
C Vérifier si la méthode a été appelée.
Si oui, passer les paramètres d'entrées du serveur OPC UA à l'instance de méthode du programme utilisateur et
signaler en retour à l'instance de la méthode que la méthode a été appelée ("called")
④ Appel synchrone de l'instruction OPC_UA_ServerMethodPre comme multi-instance avec indication de la zone de
mémoire pour les données d’entrée du serveur OPC UA.
La valeur de retour informe si le client OPC UA a appelé la méthode.
⑤ Vérifier si la méthode a été arrêtée ou si elle est toujours active ("busy").
D Vérifier si la méthode a été arrêtée.
Si oui, les paramètres de sortie de l'instance de la méthode sont transférées au serveur OPC UA et le système signale
en retour à l'instance de la méthode que la méthode est arrêtée. Le serveur OPC UA en est informé.
⑥ Appel du FB de méthode (dans l'exemple : FB Cool) avec l'instance souhaitée et les paramètres de processus
Figure 9-49 Exemple : Appel de la méthode de serveur "Cool"
Informations sur les instructions de serveur

Les instructions "OPC_UA_ServerMethodPre" et "OPC_UA_ServerMethodPost" sont décrites de
manière détaillée dans l'aide sur les instructions (Instructions > Communication > OPC UA >
Serveur OPC UA).
Voir aussi
Conditions annexes pour l'utilisation de méthodes de serveur (Page 1)
Communication
9.3.5.2 Conditions annexes pour l'utilisation de méthodes de serveur
Types de données autorisés

Si vous mettez à disposition des méthodes de serveur, respectez la règle suivante :
• Affectez les types de données comme indiqué ci-dessous (type de données SIMATIC - type
de données OPC UA). D'autres affectations ne sont pas autorisées.
STEP 7 ne contrôle pas le respect de cette règle et n'empêche pas une affectation incorrecte.
Vous avez la responsabilité d'assurer une sélection et une affectation conformes à la règle des
types de données.
Vous pouvez également utiliser les types de données énumérés par ex. comme éléments de
structures/tableaux/types de données utilisateur (UDT) pour les paramètres d'entrée et de
sortie de méthodes de serveur créées automatiquement (UAMethod_InParameters et
UAMethod_OutParameters).

BOOL Boolean
SINT SByte
INT Int16
DINT Int32
LINT Int64
USINT Byte
UINT UInt16
UDINT UInt32
ULINT UInt64
REAL Float
LREAL Double
LDT DateTime
WSTRING String
DINT Enumeration (Encoding Int32) et tous les types de don-
nées dérivés
Type de données utilisateur obligatoire UNION et tous les types de données dérivés
(UDT, user-defined data type)
Le type de données utilisateur doit être
défini avec le préfixe "Union_", par
exemple "Union_MyDatatype".
Le premier élément (Selector) dans cet
UDT doit être du type de données
"UDINT".
Communication
Nombre de méthodes de serveur implémentables et nombre d'arguments

En implémentant des méthodes de serveur via votre programme utilisateur, le nombre de
méthodes utilisables est limité selon le type de CPU ; voir tableau ci-dessous (vous trouverez
les données techniques actualisées de la CPU sur Internet
(https://support.industry.siemens.com/cs/ww/fr/ps/td)).
Caractéristiques techniques CPU 1510SP (F) CPU 1505 (S/SP/SP F/SP T/SP TF) CPU 1507S (F)
CPU 1511 (C/F/T/TF) CPU 1515 (F/T/TF) CPU 1517 (F/T/TF)
CPU 1512C CPU 1515 SP PC (F/T/TF) CPU 1518 (F)
CPU 1512SP (F) CPU 1516 (F/T/TF)
CPU 1513 (F)
Nombre maximal de méthodes de ser- 20 50 100
veur utilisables ou nombre maximal
d'instances de méthodes (instructions
OPC_UA_ServerMethodPre,
OPC_UA_ServerMethodPost)
Nombre maximal d'arguments par mé- 20 20 20
thode
(Il est possible de configurer et de char-
ger dans la CPU un nombre d'arguments
supérieur au nombre indiqué, mais un
client OPC UA ne peut cependant pas
appeler la méthode.)
Message d'erreur en cas de dépassement haut

En cas de dépassement du nombre maximal de méthodes de serveur, les instructions
OPC_UA_ServerMethodPre ou OPC_UA_ServerMethodPost renvoient le code d'erreur
0xB080_B000 (TooManyMethods).
Fourniture de types de données structurés avec tableaux imbriqués

Lorsqu'un type de données structuré (Struct/UDT) contient un tableau, le serveur OPC UA ne
met à disposition aucune information sur la longueur de ce tableau.
Si vous utilisez ce type de structure, par exemple, comme paramètre d'entrée ou de sortie
d'une méthode de serveur, vous devez veiller à ce que le tableau imbriqué reçoive la longueur
correcte à l'appel de la méthode.
En cas de non-respect de cette règle, la méthode échoue et le code d'erreur
"BadInvalidArgument" est fourni.
Communication
9.3.6 Mettre à disposition des alarmes sur le serveur OPC UA
9.3.6.1 Informations utiles sur les alarmes

Les alarmes vous permettent de détecter rapidement les erreurs lors du traitement du
processus dans les systèmes d'automatisation, de les localiser avec précision et de les
corriger. Il est ainsi possible de réduire considérablement les temps d'arrêt d'une installation.
Avec le modèle d'information OPC UA "Alarms & Conditions", vous disposez d'une possibilité
de traitement d'alarmes standardisée et indépendante de la plateforme.
À partir de la version de firmware V2.9, le serveur OPC UA de la CPU S7-1500 prend en charge
le modèle d'information OPC UA "Alarms and Conditions". Le serveur OPC UA autorise ainsi
l'accès aux alarmes de l'API.
Les sections ci-après décrivent les types d'alarmes disponibles dans SIMATIC qui sont pris en
charge par l'interface OPC UA du serveur OPC UA.
En outre, les chapitres suivants décrivent la marche à suivre pour configurer le serveur OPC
UA de la CPU S7-1500 pour Alarms and Conditions, la structure du modèle Alarms and
Conditions pour OPC UA présentée dans ses grandes lignes, ainsi que les particularités à
prendre en compte en cas d'utilisation d'alarmes de la plage d'adresses du serveur OPC UA, en
comparaison avec les alarmes de l'API du système de gestion d'alarmes de la CPU dans
SIMATIC.
Base pour la mise en œuvre d'alarmes selon OPC UA Alarms & Conditions
Le modèle d'information Alarms and Conditions est précisé dans la spécification "OPC 10000-
9: OPC Unified Architecture Part 9: Alarms & Conditions".
Communication
Alarmes de l'API dans SIMATIC

Le serveur OPC UA de la CPU S7-1500 prend en charge les alarmes de l'API ci-dessous, mises à
la disposition des CPU S7-1500. Vous configurez ou programmez les alarmes comme
d'habitude, sans qu'il soit nécessaire de respecter des règles supplémentaires en vue de leur
utilisation par les clients OPC UA.
Un autre avantage du modèle OPC UA Alarms and Conditions réside dans le fait que, outre
par les appareils HMI, les navigateurs Internet, l'écran de la CPU ou par TIA Portal, ces types
d'alarme peuvent également être affichés par tous les clients OPC UA qui prennent en charge
OPC UA Alarms and Conditions.
• Alarmes de surveillance API avec ProDiag
Avec très peu d'étapes de configuration, vous pouvez intégrer des surveillances simples,
sans devoir modifier le code du programme. La configuration des surveillances est
indépendante des langages de programmation de TIA Portal car seuls des opérandes
individuels sont surveillés et vous n'avez pas besoin de segments de programmation
supplémentaires.
• Alarmes de diagnostic système
Les événements des modules dépendant de la configuration sont connus de la
configuration matérielle de la CPU et exploitables via les appareils d'affichage connectés.
Ces alarmes peuvent uniquement être consultées dans l'éditeur d'alarmes et ne sont pas
éditables.
• Alarmes de programme (instruction Program_Alarm)
Les alarmes de programme servent à signaler des événements synchrones au programme
et sont affectées à un bloc correspondant. Elles sont créées dans l'éditeur de
programmation et éditées dans l'éditeur d'alarmes (TIA Portal).
• Alarmes GRAPH
Vous pouvez également activer des alarmes pour des blocs fonctionnels GRAPH, par
exemple pour des verrouillages, des supervisions et des alarmes GRAPH (surveillances de
la durée d'étape).
Informations importantes sur les types d'alarmes

Les caractéristiques suivantes déterminent les différences de comportement des alarmes :
• Les alarmes possèdent-elles un état (par ex. apparaissante, disparaissante - avec les
horodatages correspondants) ?
• S'agit-il d'alarmes avec obligation d'acquittement ?
Si aucune des caractéristiques suivantes ne s'appliquent, c'est-à-dire que les alarmes sont
sans état et sans obligation d'acquittement, les alarmes informent simplement de la survenue
d'un événement ("Fire and Forget"). Le choix est laissé à l'appareil recevant l'alarme de
l'enregistrer temporairement pour une utilisation ultérieure ou uniquement pour l'affichage.
Communication
Classe d'alarmes déterminant le comportement lors de l'acquittement

La section ci-après décrit les possibilités de paramétrage des alarmes de programme. Vous
pouvez également paramétrer le comportement de l'alarme (par ex. les paramètres de
surveillance ProDiag) selon les alarmes de diagnostic système et les alarmes de surveillance
API. Pour plus de détails, voir les informations complémentaires dans les documents liés.
Vous trouverez les possibilités de paramétrage des alarmes de programme dans l'éditeur
d'alarmes (double-cliquez sur "Surveillances et alarmes API" dans le navigateur du projet, puis
sélectionnez l'onglet "Alarmes").
Pour la CPU S7-1500, paramétrez ici la classe d'alarmes qui détermine si l'alarme doit être
acquittée ou non. En plus du comportement lors de l'acquittement, vous définissez
également lors de la création d'une nouvelle classe d'alarmes la priorité par défaut des
alarmes de cette classe.
L'option "Uniquement pour information", par exemple sous le type d'alarme, vous permet de
déterminer si l'alarme possède un état ou pas. Vous pouvez ainsi réaliser un comportement
"Fire and Forget" de l'alarme.
L'exemple ci-après montre l'éditeur d'alarmes avec le paramétrage de différentes classes
d'alarmes ("Surveillances et alarmes API" dans le navigateur du projet) :
• Première ligne "Program_Alarm": sans obligation d'acquittement, uniquement pour
information ("Fire and Forget").
• Deuxième ligne "Program_Alarm_1": avec obligation d'acquittement et possédant un état,
c'est-à-dire que l'alarme est signalée comme apparaissante ou disparaissante.
• Troisième ligne "Program_Alarm_2": sans obligation d'acquittement et possédant un état,
c'est-à-dire que l'alarme est signalée comme apparaissante ou disparaissante.
Communication
Affichage d'alarmes dans TIA Portal

Vous avez en outre la possibilité d'afficher les alarmes dans TIA Portal durant l'exécution :
L'affichage des alarmes se trouve directement sous l'éditeur d'alarmes (onglet "Diagnostic" >
onglet "Affichage des alarmes").
Tenez compte des points suivants pour l'état et le comportement lors de l'acquittement :
• Si vous cliquez sur le bouton "Alarmes actuelles", les alarmes actuellement apparaissantes,
disparaissantes ou acquittées sont affichées. Seules les alarmes possédant un état et les
alarmes avec obligation d'acquittement sont affichées dans la vue. Dans cette vue, vous
pouvez également acquitter une alarme avec obligation d'acquittement (en bleu) via le
menu contextuel ou à l'aide du bouton "Acquitter".
• Pour visualiser l'historique (par ex. l'alarme a été apparaissante, acquittée et ensuite a été
disparaissante), cliquez sur le bouton "Archive des alarmes". Les trois événements
correspondant à l'alarme concernée sont affichés dans l'ordre chronologique uniquement
dans cette vue. Dans la vue "Alarmes actuelles" vous ne trouverez que l'état actuel.
• Les rapports d'info (alarmes avec la propriété "Uniquement pour information") sont
affichés uniquement dans la vue "Archive des alarmes". Comme ces alarmes ne sont
déclenchées qu'une fois et qu'elles ne sont pas enregistrées dans le tampon de diagnostic,
elles n'apparaissent pas dans la vue "Alarmes actuelles".
• Les surveillances API sont également signalées dans l'affichage des alarmes.
• En règle générale, les alarmes système appartiennent à la classe d'alarmes "No
Acknowledgement" avec l'option "Uniquement pour information". Ces alarmes sont
journalisées dans le tampon de diagnostic de la CPU et permettent d'analyser la
chronologie des alarmes système sur une période limitée. Les changements de l'état de
fonctionnement, sont certes également journalisés dans le tampon de diagnostic, mais ils
possèdent un état : ils signalent par exemple que la CPU est passée en mode ARRET et
quand ce passage a eu lieu et si et quand la CPU a quitté cet état de fonctionnement, c'est-
à-dire qu'elle est passée en mode de fonctionnement MARCHE. Ces informations sont
signalées avec les états "apparaissant/disparaissant".
Communication
Mise à disposition d'alarmes API par le serveur OPC UA

Pour recevoir des alarmes de la CPU S7-1500, le client OPC UA doit s'abonner aux événements
OPC UA Events (MonitoredEventItems).
À cet effet, la plage d'adresses du serveur OPC UA de la CPU S7-1500 met à disposition les
nœuds correspondant, qui constituent des "Event-Notifier" et créent un abonnement pour les
clients OPC UA afin que ces derniers puissent recevoir les alarmes souhaitées.
Par souci d'exhaustivité, il convient de mentionner qu'en plus, d'autres définitions de type
sont également entrées comme nœuds sous "Types" dans la plage d'adresses du serveur à cet
effet. Les définitions de type sous "BaseEventType" et "ConditionType" assurent que les
champs utilisés par les alarmes SIMATIC sont également disponibles sur le serveur OPC UA.
Ainsi la plage d'adresses OPC UA de la CPU S7-1500 reflète, après activation de OPC UA
Alarms and Conditions (propriétés de la CPU dans la configuration matérielle), les différents
types d'alarmes (alarmes de l'API) comme décrit ci-dessus :
• ProcessDiagnostics
Correspond aux alarmes de surveillance API avec ProDiag
• SystemDiagnostics
Correspond aux alarmes de diagnostic système
• UserProgram
Correspond aux alarmes de programme
• Graph
Correspond aux alarmes GRAPH
Le nœud sélectionné pour l'abonnement détermine les types d'alarmes que reçoit le client
OPC UA. Le nœud "Server", par exemple, permet de recevoir toutes les alarmes, le nœud
"UserProgram" permet de recevoir uniquement des alarmes de programme.
Communication
Vous trouverez des informations détaillées sur le modèle OPC UA Alarms and Conditions dans
le chapitre suivant, en particulier pour le nœud "Overloads", à la rubrique : Travailler avec les
limites de mémoire pour OPC UA Alarms and Conditions (Page 1).
Informations supplémentaires sur les types d'alarmes

Les concepts et configurations possibles pour les alarmes API ne seront pas détaillés ici. Pour
plus d'informations sur la configuration des alarmes, l'affichage des alarmes et les
instructions correspondantes, par ex. "Progam_Alarm", référez-vous à l'aide en ligne de
STEP 7.
9.3.6.2 OPC UA Events

Dans la section qui suit, les concepts de base du traitement d'alarmes dans OPC UA seront
approfondis. Il s'agit notamment du concept de base des "Events". Les désignations anglaises
utilisées dans les différentes parties de la spécification OPC UA ont été reprises dans cette
description.
Communication
Propriétés de Events
Dans le modèle d'adresse du serveur OPC UA, vous disposez, à partir de de la version de
firmware V2.9 de la CPU, non seulement de la possibilité d'accéder aux variables API (en
lecture et en écriture) via des nœuds et d'utiliser des méthodes, mais vous pouvez aussi
recevoir des événements ou des alarmes via des nœuds. Cette fonction s'appelle "Events"
(événements) dans la terminologie OPC UA.
Un Event contient, entre autres, un texte d'événement (Message), un horodatage (Time) et
une source d'Event (SourceNode).
Les informations fournies avec un Event du serveur dépendent du type d'événement. OPC UA
définit un BaseEventType dans la Partie 5 de la spécification (Information Model).
D'autres types d'événements qui fournissent différents comportements de signalisation sont
dérivés de BaseEventType. Ces informations de type des différents types d'événements sont
visibles dans la plage d'adresses du serveur OPC UA (dossier "Types"). Ceci s'applique
également par ex. aux types d'événements "Conditions" et "Alarms" qui seront décrits dans le
chapitre suivant.
La spécification OPC UA définit les propriétés (champs) d'un événement (Event) obligatoires
(mandatory) et les événements facultatifs pour le BaseEventType, ainsi que pour les
EventTypes dérivés.
La figure suivante montre la structure hiérarchique de BaseEventType.
Les sections suivantes montrent comment les EventTypes spécifiques sont dérivés de la
racine de la hiérarchie de dérivation, le BaseEventType. Les dérivations spécifiques à SIMATIC
permettent de s'assurer que le client OPC UA peut également s'abonner aux informations, qui
sont fournies avec une alarme dans SIMATIC et affichées par ex. sur un appareil HMI, dans la
plage d'adresses du serveur OPC UA.
L'Event en soi n'est pas disponible comme nœud dans la plage d'adresses. Les Events sont
seulement déclenchés par des nœuds ou des objets qui possèdent la propriété "Event-
Notifier". Ces nœuds sont souvent désignés par le terme d'objets de signalisation
d'événements. Seuls les nœuds ayant cette propriété peuvent être indiqués dans une
Subscription comme EventMonitoredItem pour pouvoir recevoir les Events correspondants
sur le client.
Les nœuds capables de déclencher des Events sur une CPU S7-1500 sont des objets tels que
"Server", en dessous l'objet "SimaticAlarmsAndConditions" et les trois objets
ProcessDiagnostics, SystemDiagnostics et UserProgram disposés en-dessous. L'attribut
"EventNotifier" est activé sur ces objets dans la plage d'adresses du serveur OPC UA de la CPU.
Communication
Définition de SimaticEventType
La figure suivante montre que le type "SimaticEventType" est dérivé directement de
BaseEventType.
BaseEventType est la définition de type de base pour les Events dans OPC UA.
Tous les types d'Event pour OPC UA sont définis directement ou indirectement à partir de
BaseEventType.
Le type "SimaticEventType" est défini dans la plage de noms SIMATIC

(http://www.siemens.com/simatic-s7-opcua).
SimaticEventType possède toutes les propriétés de BaseEventType, ainsi que les propriétés
spéciales qui sont une image de la structure des champs des alarmes SIMATIC.
Description des propriétés Event pour SimaticEventType

Le tableau suivant contient des informations sur les champs SimaticEventType pour les
alarmes du type "Uniquement pour information". Les champs considérés comme facultatifs
selon la spécification OPC UA et qui ne sont pas utilisés par le serveur OPC UA de la CPU ont
été omis. Vous trouverez en outre une description des propriétés dans la spécification OPC
10000-5: OPC Unified Architecture, Part 5: Information Model, Release 1.04.
BrowsePath DataType Explications

EventId ByteString ID unique d'événement
EventType NodeId ID de nœud du type d'événement
Time UtcTime Horodatage de l'événement (Event occurrence)
ReceiveTime UtcTime Horodatage actuel de la génération de l'événe-
ment (Event) OPC UA.
Message LocalizedText Texte d'événement
Severity UInt16 Priorité de l'alarme de SIMATIC (0 à 16) répartie
sur une plage de 1 à 1000 dans OPC UA, voir
tableau ci-après.
La priorité représente le caractère d'urgence avec
lequel il faut réagir à l'événement.
3:AdditionalText_01 LocalizedText Texte complémentaire 1 facultatif
... ... ...
3:AdditionalText_09 LocalizedText Texte complémentaire 9 facultatif
3:AssociatedValue_01 3:SimaticAssociatedAlar Variable 1 facultative (pas pour diagnostic sys-
mValue tème)
... ... ...
3:AssociatedValue_10 3:SimaticAssociatedAlar Variable 10 facultative (pas pour diagnostic sys-
mValue tème)
3:InfoText LocalizedText Texte d'info
Communication

3:ID UInt16 Numéro d'alarme - Numéro (ID) attribué à
l'échelle de la CPU par le système identifiant une
alarme.
3:DisplayClass UInt16 Classe d'affichage (utilisée par les appareils IHM).
Détermine quels événements sont affichés sur
quels appareils IHM.
3:GroupID Uint8 Groupe d'acquittement des alarmes devant être
acquittées ensemble.
Affectation priorité (SIMATIC) - Severity (OPC UA)

Le tableau ci-après montre comment mapper les 17 priorités que vous pouvez attribuer dans
l'environnement SIMATIC sur les 1000 niveaux de Severity du serveur OPC UA de la CPU S7-
1500.
Cette affectation est spécifique au fabricant. D'autres affectations peuvent s'appliquer à
d'autres appareils.
OPC Range Priorité 0..16 (SIMATIC) Severity 1..1000 (OPC UA)

HIGH (667 – 1 000) 16 1000
15 930
14 860
13 790
12 720
MEDIUM (334 – 666) 11 650
10 600
9 550
8 500
7 450
6 400
5 350
LOW (1 – 333) 4 300
3 225
2 150
1 75
0 1
Communication
9.3.6.3 Conditions OPC UA et alarmes OPC UA

Les concepts de base de OPC UA Conditions et OPC UA Alarms seront approfondis dans la
section qui suit, sur la base des explications fournies sur les Events dans les sections ci-
dessus. Les désignations anglaises utilisées dans les différentes parties de la spécification OPC
UA ont également été reprises dans cette description.
Propriétés de Conditions
Le concept des "Events" définis dans OPC UA est important pour la compréhension.
Si, en plus de sa propriété de pouvoir déclencher des Events, un objet signalisation
d'événements fournit également des informations sur l'état, la terminologie OPC UA emploie
le terme de "Conditions". Les Conditions représentent l'état d'un système ou de l'un de ses
composants. En plus des états de base "enabled" et "disabled", d'autres définitions d'états sont
également possibles.
Les changements d'état sont signalés aux clients OPC UA concernés via des Events (Condition
Events).
Un exemple de Condition est l'information sur l'état d'un appareil qui requiert une
maintenance.
Propriétés de Alarms
Les propriétés de ConditionType ne sont toutefois pas suffisantes pour refléter complètement
les caractéristiques des alarmes SIMATIC sur le serveur OPC UA.
À partir de ConditionType, qui est dérivé de BaseEventType, OPC UA définit néanmoins
d'autres types d'événements dérivés tels que AcknowledgeableConditionType et
AlarmConditionType.
AcknowledgeableConditionType complète les propriétés de ConditionType par la
caractéristique "Acquittable" (AckedState).
AlarmConditionType complète les propriétés de ConditionType et
AcknowledgeableConditionType avec la caractéristique permettant de présenter un
"ActiveState". Cela correspond à une alarme apparaissante dans la terminologie SIMATIC.
ActiveState signale que la situation représentant la Condition se produit actuellement ou est
survenue.
Exemple : la température a dépassé une valeur limite. Lorsque "ActiveState" n'est pas activé,
la situation représentant la Condition a disparu. En règle générale, on parle alors d'un "état
normal". Cela correspond à une alarme disparaissante dans la terminologie SIMATIC.
OPC UA définit d'autres états, par ex. SilenceState ou ShelvingState. Mais ces états
supplémentaires ne jouent aucun rôle pour le mappage sur le système de gestion d'alarmes
SIMATIC et ne seront donc pas détaillés ici.
De AlarmConditionType a été dérivé SimaticAlarmConditionType qui contient tous les champs
d'Event requis pour refléter les informations d'état et d'acquittement des alarmes SIMATIC.
Communication
Définition de SimaticAlarmConditionType
La figure suivante montre comment les Events de type "SimaticAlarmConditionType" sont
définis par une série d'extensions de OPC UA "BaseEventType".
Description des propriétés Event pour SimaticAlarmConditionType

Le tableau suivant contient des informations sur les champs de SimaticAlarmConditionType
pour les alarmes possédant un état et acquittables qui s'ajoutent aux champs d'événement
comme pour SimaticEventType. Les champs considérés comme facultatifs selon la
spécification OPC UA et qui ne sont pas utilisés par le serveur OPC UA de la CPU ont été omis.
Vous trouverez en outre une description des propriétés dans la spécification OPC 10000-9:
OPC Unified Architecture, Part 9: Alarms & Conditions, Release 1.04.

ConditionClassId NodeId ID de nœud possibles pour SystemCondition-
ClassType, ProcessConditionClassType ou
BaseConditionClassType
ConditionClassName LocalizedText DisplayName de ConditionClassId
Retain Boolean Indique que l'alarme est encore pertinente
pour des clients OPC UA (activé si une alarme
est encore en attente et pas encore acquit-
tée).
Comment LocalizedText • Commentaire le plus récent qui a été saisi
via la méthode "AddComment" ou "Ack-
nowledge".
• NULL après un redémarrage du serveur et
si aucun commentaire n'a été saisi.
Comment.SourceTimestamp UtcTime Horodatage de la dernière modification du
champ de commentaire
AckedState LocalizedText "Acknowledged" ou "Unacknowledged"
AckedState.Id Boolean Activé sur acquittement
Communication

AckedState.TransitionTime UtcTime Date et heure auxquelles l'alarme a été ac-
quittée.
NULL si l'alarme n'a pas été acquittée ou n'est
pas acquittable.
ActiveState LocalizedText "Active" ou "Inactive"
ActiveState.Id Boolean Activé si l'état est "Active"
9.3.6.4 Activer Alarms and Conditions
Conditions
• Licence Runtime pour OPC UA achetée conformément aux conditions de licence et
configurée dans les propriétés de la CPU
Marche à suivre
Pour activer des alarmes via OPC UA Alarms and Conditions, procédez comme suit :
1. Naviguez dans les propriétés de la CPU jusqu'à la zone "OPC UA > Serveur > Général".
2. Activez l'option "Activer Alarms and Conditions sur le serveur OPC UA".
Les types et objets correspondant capables de déclencher des événements ne sont visibles
dans la plage d'adresses qu'après activation de l'option.
3. Si nécessaire, activez également l'option "Autoriser l'acquittement d'alarmes par le client
OPC UA".
Dans ce cas, chaque client OPC UA connecté peut acquitter une alarme acquittable avec la
méthode "Acknowledge".
Recommandation : activer le diagnostic "Échec des requêtes d'un client OPC UA distant"
Si le serveur OPC UA ne peut pas allouer suffisamment de mémoire, la génération d'alarmes
OPC UA n'est pas possible et des alarmes pour les clients OPC UA peuvent être perdues.
Nous vous recommandons donc d'activer le diagnostic "Échec des requêtes d'un client OPC
UA distant" afin de pouvoir diagnostiquer cet état (propriétés de la CPU > OPC UA > Serveur >
Diagnostic).
Vous devriez en outre aussi activer l'option "Résumer les diagnostics en cas de nombre de
messages élevé".
Dès que la mémoire disponible sera de nouveau suffisante, les clients OPC UA devront
appeler la méthode ConditionRefresh pour connaître l'état actuel du système d'alarme.
Communication
Voir aussi
Méthodes pour OPC UA Alarms and Conditions (Page 1)
Échec de la requête d'un client distant (Page 1)
9.3.6.5 S'abonner aux événement d'un serveur OPC UA
S'abonner à tous les Events via le nœud "Server"

Les serveurs OPC UA mettent des événements à disposition par le biais du nœud "Server" et
de nœuds situés en dessous de celui-ci. Lorsque des clients OPC UA s'abonnent au nœud
"Server", ils reçoivent tous les événements et toutes les alarmes du serveur OPC UA.
Le nœud "Server" se trouve sous "Root" dans le dossier "Objects".
Les serveurs OPC UA informent les client OPC UA des types d'événements qu'ils utilisent (sous
"Root > Types > EventTypes" dans la plage d'adresses).
Possibilités de filtrage d'Events

Les clients OPC UA peuvent opérer une sélection et s'abonner uniquement à certains nœuds
situés sous le nœud "Server" et ainsi à des types d'événements précis, par exemple
uniquement au nœud "UserProgram". Cela permet de limiter le nombre d'événements du
serveur OPC UA aux alarmes de programme.
Une autre possibilité de filtrage consiste en la sélection des propriétés d'événements, c'est-à-
dire "Select Clause" dans la terminologie de la spécification OPC UA.
Autrement dit, une sélection de propriétés d'événements peut également être effectuée dans
l'abonnement dans le client OPC UA outre l'objet de signalisation d'événement (par ex. nœud
"UserProgram"). Vous sélectionnez les propriétés d'événements via le Browse Name de la
colonne correspondante.
OPC UA définit en plus ce que l'on appelle les "Where Clauses". Where Clause dans un filtre
d'événement sert à limiter encore plus le nombre d'Events fournis par le serveur OPC UA pour
l'objet sélectionné, par ex. en définissant un filtre pour la plage de Severity.
Communication
Exemple de client UaExpert

L'exemple du client OPC UA UaExpert montre comment les événements d'un serveur OPC UA
peuvent être reçus via un abonnement. Ci-après les principales informations sur les
Events/alarmes affichées :
• Event View est une propre vue des Events, en plus de Data Access View.
• La zone "Configuration" contient l'objet de signalisation d'événement sélectionné avec les
champs pour Select Clause. Une configuration de Where-Clauses n'est actuellement pas
possible dans UaExpert.
• Dans la zone "Events", onglet "Events" : correspond à la vue dans l'affichage des alarmes
dans TIA avec le bouton "Archive des alarmes" activé ; les Events du type "Uniquement
pour information" et les alarmes disparaissantes y sont également visibles, car UaExpert
les enregistre dans le tampon en arrière-plan pour l'affichage. Dans l'onglet "Alarms", ces
Events ne sont pas visibles.
• Dans la zone "Events", onglet "Alarms" : correspond à la vue dans l'affichage des alarmes
dans TIA avec le bouton "Alarmes actuelles" activé ; les alarmes y sont visibles avec leur
état, par ex. "active" (correspond à "apparaissante") et ces alarmes sont acquittables via le
menu contextuel. Les alarmes disparaissantes ne sont plus visibles dans cette vue.
Les colonnes de la zone Events offrent une sélection de propriétés d'événements, par ex. le
texte d'événement (Message) et la possibilité de savoir si l'alarme a déjà été acquittée
(AAcknowledged).
Communication
Particularités de l'affichage d'alarmes via le serveur OPC UA de la CPU

Les particularités de l'affichage des alarmes via OPC UA Alams and Conditions sont
regroupées dans la section qui suit dans l'état actuel.
Sujet Explication
Commentaire (Comment) Via OPC UA, vous pouvez ajouter un commentaire à une alarme
avec la méthode "AddComment" ou "Acknowledge". Il ne sera
plus disponible après un redémarrage du serveur.
Les alarmes en instance ne sont Le serveur OPC UA prend en charge la méthode "ConditionRe-
pas perdues après redémarrage du fresh" qui permet de fournir l'état le plus récent du système au
serveur client OPC UA, par ex. après le chargement d'un nouveau bloc de
données (redémarrage du serveur et rétablissement de la con-
nexion nécessaires).
9.3.6.6 Méthodes pour OPC UA Alarms and Conditions

La spécification OPC Partie 9 (OPC 10000-9: Alarms & Conditions) définit les méthodes pour
le serveur OPC UA permettant par ex. à des clients OPC UA de réagir à des changements
d'état.
Le tableau suivant décrit les méthodes prises en charge par le serveur OPC UA de la S7-1500.
Conditions
Pour que vous puissiez utiliser les méthodes pertinentes de la fonctionnalité Alarms-and-
Conditions, il faut que les conditions suivantes soient remplies :
• Alarms and Conditions est activé
• Pour la méthode "Acknowledge", l'acquittement d'alarmes par des clients OPC UA doit être
autorisé côté serveur.
Communication
Méthodes pour OPC UA Alarms and Conditions

Vous trouverez dans ce qui suit une description succincte des méthodes, ainsi que les
particularités et restrictions liées à la mise en œuvre du serveur OPC UA de la CPU S7-1500.
Ces méthodes sont visibles dans la plage de types.
La spécification OPC UA nommée ci-dessus contient la description générale.
Vous trouverez à la suite de ce tableau récapitulatif, la description détaillée des différentes
méthodes.
Méthode Description
Acknowledge Méthode d'acquittement d'un objet alarme désigné de ma-
nière univoque par une EventId.
ConditionRefresh Méthode de demande d'une mise à jour de tous les objets
alarme (dans la terminologie SIMATIC : mise à jour de toutes
les alarmes en attente). Tous les éléments surveillés (Moni-
tored Items) de l'abonnement sont mis à jour.
La synchronisation d'objets alarme en attente du serveur
OPC UA de la CPU est, par ex., affichée dans les cas sui-
vants :
• Premier établissement ou rétablissement de la con-
nexion (après une interruption de la communication)
• Changement de vue sur un écran de commande d'un
appareil IHM
AddComment Méthode d'ajout de commentaires à des objets alarme.
Appel des méthodes "Acknowledge" et "AddComment"

Les appels de méthode pour OPC UA utilisent MethodId et ObjectId.
Dans le cas d'un objet alarme, l'ObjectId est l'ID de nœud pour l'instance de l'objet alarme.
Aucune instance n'étant prévue dans le modèle d'adresse de Simatic Alarms and Conditions
pour les objets alarme, la spécification OPC UA prévoit dans ce cas que le client OPC UA utilise
la ConditionId comme ObjectId.
Vous trouverez également des informations sur la détermination de la ConditionId à l'aide de
SimpleAttributeOperands dans la SelectClause du filtre d'événement dans la spécification OPC
UA Partie 9 (OPC 10000-9: Alarms & Conditions) :
Communication
Acknowledge
La méthode Acknowledge (MethodId : i=9111) possède les paramètres suivants :

[in] EventId ByteString L'EventId identifie une notification d'événe-
ment (Event Notification) donnée.
Seuls les événements dont le champ Ack-
edState.Id a la valeur "False" peuvent être ac-
quittés avec la méthode "Acknowledge".
[in] comment LocalizedText Texte de commentaire d'acquittement, par
exemple par un opérateur.
Voir aussi la description complémentaire de la
méthode "AddComment".
Method Result Codes

Good La méthode a été correctement exécutée.
BadNotSupported La méthode ne peut pas être appelée, car l'option
d'acquittement par des clients OPC UA pour
Alarms and Conditions est désactivée pour OPC
UA dans les propriétés de la CPU.
BadConditionBranchAlreadyAcked L'acquittement a déjà eu lieu.
BadNodeIdUnknown La méthode a été appelée avec une ConditionId
incorrecte (voir les remarques sur l'ObjectId).
BadEventIdUnknown La méthode a été appelée avec une EventId incor-
recte.
ConditionRefresh
La méthode ConditionRefresh (MethodId : i=3875) possède les paramètres suivants :

[in] SubscriptionId Uint32 SubscriptionId de l'abonnement qui doit être
actualisée.
Method Result Codes

Bad_SubscriptionIdInvalid La SubscriptinId est invalide.
Bad_RefreshInProgress Exécution de la méthode "ConditionRefresh" en
cours.
Bad_UserAccessDenied La méthode "ConditionRefresh" est exécutée dans
le contexte d'une session erronée. C'est-à-dire que
l'abonnement appartient à une autre session.
Communication
Remarque
Méthode ConditionRefresh2
Le serveur OPC UA de la CPU S7-1500 ne prend pas en charge la méthode ConditionRefresh2,
qui peut synchroniser de manière ciblée un élément surveillé (MonitoredItem) dans un
abonnement. Dans ce cas, le serveur OPC UA renvoie le code de résultat
"Bad_MethodInvalid". Utilisez au lieu de celle-ci la méthode "ConditionRefresh".
AddComment
Vous avez la possibilité d'ajouter des commentaires à des objets Alarms- de type
SimaticAlarmConditionType, car la prise en charge de commentaires est obligatoire pour OPC
UA Alarms and Conditions .
Un commentaire est enregistré dans le champ d'événement "Comment".
Les champs d'événement d'horodatage suivants font partie du commentaire :
• "Comment.SourceTimestamp" horodatage de l'enregistrement du commentaire dans la
CPU
• "Time" pour la date/heure de la modification de l'objet Alarms
Si la méthode "AddComment" est appelée, "Time" et "Comment.SourceTimestamp" sont
identiques.
Particularités des commentaires Alarms-and-Conditions pour le serveur OPC UA de la

CPU
La méthode Add-Comment (MethodId : i=9029) possède les paramètres suivants :

[in] EventId ByteString L'EventId identifie la notification d'événement
avec laquelle un état a été signalé.
[in] comment LocalizedText Texte du commentaire de l'objet Alarms spéci-
fié.
Method Result Codes

Good La méthode a été correctement exécutée.
BadNodeIdUnknown La méthode a été appelée avec une ConditionId
incorrecte (voir les remarques sur l'appel des
méthodes "Acknowlege" et "AddComment").
BadEventIdUnknown La méthode a été appelée avec une EventId incor-
recte.
Communication
Particularités des commentaires Alarms-and-Conditions pour le serveur OPC UA de la CPU

Avec la méthode AddComment, vous avez la possibilité d'ajouter des commentaires à des
objets alarme de type "SimaticAlarmConditionType". Un commentaire est activé même en cas
d'appel de la méthode Acknowledge. La méthode "AddComment" peut être appelée plusieurs
fois.
• Un commentaire est enregistré dans le champ d'événement "Comment". Le
"Comment.SourceTimestamp" indique la dernière date/heure à laquelle un commentaire
a été ajouté.
• L'horodatage "Time" indique la date/l'heure de la dernière modification de l'objet
alarme.
Si la méthode "AddComment" est appelée, "Time" et "Comment.SourceTimestamp" sont
identiques.
Si la méthode "Acknowledge" est appelée, les deux horodatages peuvent être différents, car
l'acquittement a lieu de manière asynchrone.
La prise en charge de commentaires pour OPC UA Alarms and Conditions est obligatoire. Le
système de signalisation SIMATIC ne dispose pas de commentaires correspondants pour les
alarmes. Il faut donc prendre en compte certaines particularités :
• Il n'existe qu'un seul commentaire :
Pour un objet alarme, il n'existe qu'un seul commentaire. En cas de plusieurs appels de
méthode consécutifs, un commentaire existant est donc écrasé à chaque fois.
• Durée de vie et horodatage :
Les commentaires sont uniquement enregistrés dans l'objet alarme actuel. Si l'objet
alarme n'existe plus, par exemple après un redémarrage du serveur, le commentaire est
également supprimé. Les champs d'événement correspondants '"Comment" et
"Comment.SourceTimestamp" sont ensuite réinitialisés.
Le champ d'événement "Time" est donc activé comme si l'appel de méthode
"AddComment" n'avait pas eu lieu. Exemple : Si vous commentez un objet Alarms non
acquitté, le champ d'événement "Time" est horodaté à la date/l'heure de cette
modification de commentaire. Après un redémarrage du serveur, le champ d'événement
"Time" n'indique pas la date/l'heure de création du commentaire, mais l'horodatage de
l'apparition de l'événement (Event) correspondant.
Communication
9.3.6.7 Travailler avec les limites de mémoire pour OPC UA Alarms and Conditions
Le serveur OPC UA de la CPU S7-1500 a une capacité de mémoire limitée en fonction de la
CPU pour la fonction "Alarms and Conditions" (voir les caractéristiques techniques des CPU).
Deux pools de stockage sont disponibles pour différentes catégories d'alarme :
• Pool uniquement pour ProgramAlarms (correspond aux émetteurs (Producers) d'alarmes
de programme, notamment les alarmes de programme via Program_Alarm, ProDiag,
Graph)
• Pool uniquement pour SystemDiagnostics (correspond aux alarmes de diagnostic système)
Dans des conditions défavorables (par exemple en cas d'avalanche d'alarmes), la CPU ne peut
plus mettre à disposition les alarmes en attente (ProgramAlarms ou SystemDiagnostics) de la
plage d'alarmes SIMATIC pour le système OPC UA Alarms-and-Conditions. Dans ce cas, les
alarmes ne sont malgré tout pas perdues.
Vous avez la possibilité de réagir à cet événement de surcharge dans le programme
utilisateur. En fonction de votre application, vous pouvez mettre à disposition des alarmes qui
n'ont pas été transmises au système OPC UA Alarms-and-Conditions dans ce système via la
méthode "ConditionRefresh".
Conditions
• Alarms and Conditions est activé
• Les abonnements Event sont configurés dans le client OPC UA
Communication
Principe
La figure suivante montre de manière simplifiée le stockage intermédiaire d'alarmes
ProgramAlarms pour les mettre de nouveau à disposition du système OPC UA Alarms and
Condition à un autre moment. Les nœuds spécifiés dans la légende de la figure sont visibles
dans la figure suivante du modèle d'adresse.
① Le nombre d'alarmes actives est trop élevé pour rendre accessibles toutes les alarmes via OPC UA Alarms and Condi-
tions.
② Une alarme de surcharge (Overload Alarm) est émise. Cette alarme de surcharge est active jusqu'à ce que la situa-
tion suivante se produise :
• Il n'y a plus aucune alarme en attente pour le système OPC UA Alarms-and-Conditions (OutstandingProgramA-
larms = 0) et
• le nombre d'alarmes dans le système OPC UA Alarms-and-Conditions < valeur max. corrigée de l'hystérésis pour
des alarmes OPC UA (= MaxAlarmsInQueue - OverloadHysteresis).
Les alarmes qui ne sont pas disponibles dans le système OPC UA Alarms-and-Conditions en raison de la surcharge
sont stockées provisoirement comme "OutstandingAlarms".
③ Si un client OPC UA exécute la méthode ConditionRefresh, tous les objets alarme de l'abonnement correspondant
sont synchronisés, et les alarmes en attente pour OPC UA Alarms and Conditions (OutstandingAlarms) sont transfé-
rées dans la zone de mémoire Alarms and Conditions jusqu'à ce que le nombre maximal d'alarmes soit atteint. Les
alarmes "les plus anciennes" sont transférées en premier. Chaque abonnement à ces alarmes reçoit ensuite les
alarmes transmises - pas seulement le client OPC UA qui a appelé la méthode ConditionRefresh.
④ Le client OPC UA commande le traitement des alarmes en attente en fonction des informations du nœud Overloads.
Communication
Modèle d'adresse pour Alarms and Conditions

La figure suivante montre le nœud du modèle d'adresse OPC UA Alarms-and-Conditions.
Particularités
• Si des alarmes en attente disparaissent ou sont acquittées, elles ne parviennent plus dans
le système OCP UA Alarms-and-Condition avec la méthode ConditionRefresh. Elles sont
ensuite "invisibles" pour OPC UA Alarms and Conditions et les clients OPC UA connectés.
Cela a des répercussions par ex. sur les évaluations statistiques d'historiques d'alarmes.
• Pour éviter une fréquence d'alarmes Overloads trop élevée, le seuil de déclenchement de
l'alarme est supérieur au seuil de désactivation de cette alarme si le volume d'alarmes est
proche de la valeur maximale. La valeur de cette différence est affichée dans le nœud
"OverloadHysteresis".
Exemple : Nombre maximal : 200, OverloadHysteresis : 3.
Une alarme Overloads est générée à partir de 200 alarmes et n'est désactivée que si le
nombre d'alarmes est inférieur à 197. Si le volume d'alarmes augmente de nouveau,
l'alarme Overloads est de nouveau émise à partir de 200 alarmes.
Communication
9.3.7 Utiliser les possibilités de diagnostic
9.3.7.1 Diagnostic du serveur OPC UA
Diagnostic en ligne du serveur OPC UA

Vous pouvez établir un diagnostic en ligne du serveur OPC UA de la CPU S7-1500 avec des
clients OPC UA courants, tels que UaExpert.
Les informations de diagnostic sont réparties dans les domaines suivants :
• Server Diagnostics
• Sessions Diagnostics
• Subscriptions Diagnostics
Il existe, par exemple, les nœuds suivants avec des informations de diagnostic dans la plage
d'adresses du serveur :
• ServerDiagnosticsSummary : récapitulatif du diagnostic du serveur
– CurrentSessionCount : nombre de sessions actives
– SecurityRejectedSessionCount : nombre de sessions rejetées en raison de paramètres
de sécurité de nœud d'extrémité non concordants entre client et serveur
• SessionsDiagnosticsSummary : récapitulatif du diagnostic de session
– ActualSessionTimeout : durée paramétrée pendant laquelle la session est conservée en
cas d'interruption de la liaison, par exemple.
Communication
• SubscriptionsDiagnosticsArray : tableau avec un élément par souscription pour la

session concernée
Figure 9-50 Server Diagnostics
Le nœud "SessionsDiagnosticsSummary" montre également les propriétés de l'application

client qui accède au serveur pendant la session.
Figure 9-51 Sessions Diagnostics avec les propriétés de l'application client
Diagnostic de la liaison entre client et serveur

Utilisez l'instruction suivante pour effectuer le diagnostic de l'état de la liaison pendant
l'exécution du programme dans le client :
OPC_UA_ConnectionGetStatus : Lire l'état de la liaison
Communication
9.3.7.2 Diagnostiquer les changements d'état du serveur
Informations sur l'état du serveur

À partir de la version de firmware V2.8, les CPU S7-1500 sont en mesure de générer une
entrée dans le tampon de diagnostic en cas de changement d'état du serveur OPC UA.
Le tampon de diagnostic indique le nouvel état.
La cause du changement d'état est également affichée, par exemple chargement dans la CPU,
transition hors tension - sous tension, instruction du programme utilisateur ou requête de
service d'un partenaire (client).
Condition
Dans les propriétés OPC UA de la CPU, l'option "Changement d'état du serveur OPC UA" est
activée (OPC UA > Serveur > Diagnostic).
Remarque
Lorsque cette option est activée, la CPU inscrit aussi automatiquement la stratégie de sécurité
la moins élevée configurée dans le tampon de diagnostic après le démarrage.
Exemples
Lorsque le serveur OPC UA de la CPU est mis à l'arrêt par une procédure de chargement puis
redémarré avec une nouvelle configuration valide, le tampon de diagnostic indique le nouvel
état du serveur, par exemple Shutdown => Starting => Running.
Quand le serveur OPC UA est mis à l'arrêt par une procédure de chargement et qu'il ne peut
pas démarrer à cause d'un Typedictionary trop volumineux, le tampon de diagnostic indique
seulement l'état "Failed" (Shutdown => Starting => Failed).
Communication
États et changements d'état du serveur
①, ④ Mise sous tension ou chargement à l'état Marche si des données relatives à OPC UA peuvent
être concernées.
② Chargement de la configuration matérielle avec serveur OPC UA désactivé. Le serveur reste à
l'arrêt (shutdown).
Chargement de la configuration matérielle avec serveur OPC UA activé et données OPC UA
erronées (par exemple, trop de structures avec, pour conséquence, un dictionnaire de types
TypeDictionary trop grand). Dans ce cas, le serveur ne peut pas démarrer (voir ③).
③ Le serveur OPC UA ne peut pas démarrer en raison de données erronées, par exemple.
Figure 9-52 États et changements d'état du serveur
Description des états du serveur

Le tableau suivant décrit les différents états pouvant être pris par le serveur OPC UA.
États du serveur Explication

Shutdown État initial
• après mise sous tension
• après chargement de la configuration matérielle avec serveur OPC UA
activé ou désactivé
• après chargement de données concernant OPC UA
Starting La plage d'adresses OPC UA dans le serveur est en cours d'initialisation.
Running Le serveur OPC UA est en marche (état de production normal des serveurs
OPC UA)
Failed État de défaut. Le serveur OPC UA ne peut pas démarrer en raison de don-
nées erronées, par exemple.
Communication
9.3.7.3 Diagnostiquer les changements d'état de la session
Informations sur l'état de la session

entrée dans le tampon de diagnostic en cas de changement d'état d'une session OPC UA.
Le tampon de diagnostic indique le nouvel état. L'ID de session correspondante est également
affichée.
Condition
L'option "Changement d'état de la session" est activée dans les propriétés OPC UA de la CPU
(OPC UA > Serveur > Diagnostic).
Exemple
Un client transmet des données d'authentification erronées (mot de passe incorrect, par
exemple) lors de la connexion. Le nouvel état de la session "ActivationFailed" est inscrit dans
le tampon de diagnostic avec l'ID de session correspondante.
États et changements d'état de la session
① Le client se connecte au serveur avec des données d'authentification correctes.

② Le client se déconnecte dans les règles.
③ Le client n'envoie plus de message ; la session s'arrête par dépassement du délai.
④ Le client se connecte au serveur avec des données d'authentification erronées.
Figure 9-53 États et changements d'état de la session
Communication
9.3.7.4 Contrôler les événements de sécurité

Lorsque la CPU diagnostique un événement de sécurité dans le cadre de la communication
OPC UA, elle peut l'inscrire dans le tampon de diagnostic.
Conditions
• CPU S7-1500 à partir de la version de firmware 2.8
• L'option "Vérification d'événements de sécurité" est activée (propriétés de la CPU > OPC UA
> Serveur > Diagnostic)
Événements de sécurité diagnostiqués

Les CPU S7-1500 diagnostiquent les événements de sécurité OPC UA suivants :
• Le certificat du client est invalide (par exemple, erreur de syntaxe ou sémantique,
signature incorrecte, date actuelle en dehors de la période de validité).
• L'authentification par nom d'utilisateur/mot de passe a échoué (désactivé ou données
incorrectes).
• Le client souhaite utiliser une stratégie de sécurité particulière ou un mode de sécurité de
messages particulier qui ne sont pas pris en charge par le serveur.
• Le client se connecte d'une manière qui n'est pas conforme à la spécification OPC UA (par
exemple, SecureChannelID/SessionID/Client Nonce inattendu).
Exemple
Le serveur détecte les tentatives de compromission de la communication (par exemple, par
détournement de session, attaque par hôte interposé, etc.) en procédant à une vérification.
9.3.7.5 Échec de la requête d'un client distant

entrée dans le tampon de diagnostic pour les événements suivants :
• Requêtes erronées du client (utilisation incorrecte)
• Une erreur de service s'est produite
• Dépassement des limites spécifiques à la CPU, du serveur OPC-UA
Exemple de requête erronée du client

On est en présence d'une requête erronée, par exemple, lorsqu'un client adresse un nœud
(variable) ou requiert une ressource qui n'existe pas.
Dans ce cas, le service à l'origine de l'erreur est inscrit dans le tampon de diagnostic ainsi que
l'ID de session correspondante.
Communication
Erreur de service
En cas d'échec d'un service, le serveur répond avec une erreur de service (ServiceFault). Dans
ce cas, le code d'état (Bad...) est inscrit dans le tampon de diagnostic ainsi que l'ID de session
correspondante.
Exemple de dépassement de limites

Si une requête de service dépasse une limite spécifique à la CPU, par ex. le nombre de
sessions, le nombre d'éléments contrôlés (Monitored Items), le nombre de souscriptions, etc.
le diagnostic correspondant est inscrit dans le tampon de diagnostic. Le type de limite
dépassée est indiqué en liaison avec le message correspondant.
Exception : si vous regroupez des diagnostics et que le message correspondant survient d'une
manière fréquente, la limite à l'origine de l'erreur ne fait l'objet d'aucune entrée. Vous recevez
alors une indication générale sur le dépassement des capacités fonctionnelles prises en
charge.
Entrées possibles pour le service à l'origine de l'erreur

Selon l'application client utilisée, les requêtes adressées au serveur peuvent être résolues de
différentes manières du point de vue de l'utilisateur, par exemple par un outil en ligne à
interface utilisateur graphique ou par des instructions dans le programme du client.
Comme OPC UA suit un paradigme requête-réponse avec son architecture orientée service,
l'application client concernée convertit les requêtes en requêtes de service définies pour OPC
UA
Les noms de ces services sont définis et regroupés en fonction de leur utilisation (voir
opcfoundation.org).
En cas d'utilisation incorrecte, ce sont ces noms de services qui figurent dans le tampon de
diagnostic comme services à l'origine de l'erreur avec l'ID de session correspondante.
Les services possibles dans OPC UA sont énumérés ci-après.
Discovery Service Set (ensemble de services de découverte)

FindServers
GetEndpoints
Session Service Set (ensemble de services de session)

CreateSession
ActivateSession
CloseSession
Cancel
Communication
View Service Set (ensemble de services de visualisation)

Browse
BrowseNext
TranslateBrowsePathsToNodeIds
RegisterNodes
UnregisterNodes
Attribute Service Set (ensemble de services d'attribut)

Write
Read
Method Service Set (ensemble de services de méthode)

Call
Monitored Item Service Set (ensemble de services d'éléments contrôlés)

CreateMonitoredItems
ModifyMonitoredItems
DeleteMonitoredItems
SetMonitoringMode
SetTriggering
Subscription Service Set (ensemble de services d'abonnement)

CreateSubscription
ModifySubscription
DeleteSubscriptions
Publish
Republish
SetPublishingMode
9.3.7.6 Diagnostiquer les abonnements
Informations sur une souscription

entrée dans le tampon de diagnostic en cas de changement d'état d'une souscription.
Le tampon de diagnostic indique le nouvel état, à l'exception de "KeepAlive".
Communication
Condition
L'option "Souscriptions : changement d'état" est activée dans les propriétés OPC UA de la CPU
(OPC UA > Serveur > Diagnostic).
Exemple
Un client OPC UA est connecté à une CPU S7-1500 en tant que serveur OPC UA et génère une
souscription dans le serveur.
Les options de diagnostic pour les souscriptions sont activées dans les propriétés OPC UA de
la CPU.
Les états "Creating" et "Normal" sont successivement inscrits dans le tampon de diagnostic
avec l'ID de souscription correspondante.
États et changements d'état de la souscription
① la souscription est générée, puis est active.

② Le changement d'état n'est pas consigné dans le tampon de diagnostic car, selon l'afflux de
données, il pourrait s'ensuivre trop d'entrées dans le tampon de diagnostic.
③ Voir l'explication relative à "Late" dans le tableau ; par exemple, pas de requêtes d'émission du
client.
④ Valeur KeepAlive maximale atteinte.
⑤ Voir l'explication relative à "TimedOut" dans le tableau.
⑥ La durée de vie maximale de la souscription est atteinte.
⑦ Le client a supprimé la souscription.
Figure 9-54 États et changements d'état de la souscription
Communication
Description des états de la souscription

Une souscription peut prendre les états suivants dans le serveur OPC UA :
État Signification
Creating Le client a requis une souscription dans le serveur. Le serveur génère la souscrip-
tion.
Normal la souscription a été créée dans le serveur et est active.
Closed Le client a supprimé la souscription.
KeepAlive État pris lorsque les éléments contrôlés (monitored items) ne changent pas pen-
dant un certain temps. Ces changements d'état ne sont pas inscrits dans le tam-
pon de diagnostic.
Late Le client a généré une souscription avec des intervalles d'échantillonnage et
d'émission minimum. L'ensemble d'éléments contrôlés n'est pas transmis au
client pendant ce temps.
Le client ne transmet plus de requêtes d'émission (en raison d'une défaillance,
par exemple).
TimedOut Le client a requis une souscription.
Le serveur ne peut servir la souscription (envoyer Publish Response) que s'il y a
suffisamment de demandes d'envoi (Publish Requests) du client.
Lorsque le client cesse d'envoyer des demandes d'envoi, au bout d'un certain
temps, la souscription passe à l'état "TimedOut".
Souscription : erreur des temps d'échantillonnage

À partir de la version de firmware V2.5 de la CPU SIMATIC S7-1500, le serveur OPC UA peut
transmettre le code d'état "GoodOverload" lors de l'utilisation de souscriptions, s'il se produit
une surcharge de la CPU lors de l'échantillonnage des éléments.
Le serveur OPC UA peut aussi inscrire cet événement dans le tampon de diagnostic à partir de
la version de firmware V2.8 de la CPU SIMATIC S7-1500.
Condition
L'option "Souscriptions : erreur des temps d'échantillonnage" est activée dans les propriétés
OPC UA de la CPU (OPC UA > Serveur > Diagnostic).
Communication
Souscription sans erreur

En cas de souscription OPC UA pour différents éléments (des variables, par exemple), le
serveur OPC UA de la SIMATIC S7-1500 doit vérifier à intervalles prescrits (intervalle
d'échantillonnage) si la valeur des éléments change. Ce contrôle, l'échantillonnage ou
"sampling", nécessite un certain temps qui dépend du nombre et du type de données des
éléments. Une fois l'échantillonnage achevé et en présence d'une requête d'émission
(publishing request), le serveur envoie les éléments au client.
Figure 9-55 Souscription sans erreur
Souscription avec erreur

S'il y a trop d'éléments dans la file d'attente, il peut se produire une surcharge ou "overload"
de la pile de communication. La CPU ne peut alors pas contrôler tous les éléments à
l'intervalle d'échantillonnage prescrit et doit donc sauter la tâche d'échantillonnage suivante.
Dans ce cas, elle envoie le code d'état "GoodOverload" (0x002F0000) pour chaque élément
bien que les éléments n'aient pas été contrôlés. Selon CEI 61131-3, ce code d'état a la
signification suivante : "Sampling has slowed down due to resource limitations".
① La tâche d'échantillonnage est sautée.
Figure 9-56 Souscription avec erreur
Voir aussi FAQ 109763090 (https://support.industry.siemens.com/cs/ww/fr/view/109763090).
Voir aussi
Paramètres du serveur pour souscriptions (Page 1)
Communication
9.3.7.7 Résumer les diagnostics

Pour éviter une avalanche de diagnostics OPC UA identiques dans le tampon de diagnostic,
vous pouvez paramétrer à partir de STEP 7 V16 que ces événements seront écrits dans le
tampon comme signalisation groupée. Dans ce cas, la CPU ne génère plus qu'une
signalisation groupée par diagnostic OPC UA et par intervalle (période de surveillance).
Les chapitres ci-après précisent quels diagnostics sont regroupés par la CPU et quel est le
procédé en cas de nombre de messages élevé.
Condition
L'option "Résumer les diagnostics en cas de nombre de messages élevé" est activée dans les
propriétés OPC UA de la CPU (OPC UA > Serveur > Diagnostic, zone "Résumer les
diagnostics").
Exemple
Un client OPC UA "surmène" une CPU S7-1500 en tant que serveur OPC UA de manière
répétée en raison d'une fréquence d'échantillonnage que le serveur ne peut pas suivre
(surcharge).
L'option "Résumer les diagnostics en cas de nombre de messages élevé" est activée.
Dans le tampon de diagnostic apparaît pour ce diagnostic un message indiquant que la
fréquence d'échantillonnage souhaitée ne peut pas être atteinte, suivi du nombre
d'événements de ce type survenus dans l'intervalle configuré.
Diagnostics OPC UA résumables

Les diagnostics cités ci-après constituent respectivement des groupes (types) distincts.
L'option "Résumer les diagnostics en cas de nombre de messages élevé" permet de résumer
des diagnostics appartenant à un même groupe :
• Utilisation incorrecte d'un service OPC UA
• Erreur de service OPC UA
• L'état de souscription a changé
• La fréquence d'échantillonnage n'a pas pu être atteinte (souscriptions, surcharge)
• Échec de la vérification de sécurité OPC UA
• Dépassement des capacités fonctionnelles du serveur OPC UA
Communication
Fonctionnement
La CPU écrit immédiatement les trois premiers diagnostics d'un groupe dans le tampon de
diagnostic. Elle ne tient pas compte de tous les diagnostics suivants du même groupe.
A la fin de l'intervalle de surveillance, la CPU génère une signalisation groupée contenant le
diagnostic et sa fréquence pendant l'intervalle écoulé. Si ces diagnostics apparaissent aussi au
cours des intervalles suivants, la CPU ne génère plus qu'une signalisation groupée par
intervalle.
Dans le tampon de diagnostic, une avalanche de diagnostics laisse le modèle suivant : trois
messages individuels suivis d'une série de signalisations groupées. Cette série peut
comprendre deux, trois signalisations groupées ou plus, cela dépend de l'intervalle de
surveillance choisi et de la durée de l'avalanche de diagnostics.
① Diagnostics d'un groupe (d'un type), par ex. "La fréquence d'échantillonnage n'a pas pu être
atteinte"
② Intervalle de surveillance : Quand un diagnostic apparaît pour la première fois (ou réapparaît),
le temps de surveillance est démarré (ou redémarré).
③ Messages individuels : Les trois premiers diagnostics d'un même groupe sont écrits immédiate-
ment dans le tampon de diagnostic. À partir du quatrième diagnostic, la CPU ne génère plus
que des signalisations groupées. Quand un diagnostic de ce groupe réapparaît après une pause
d'au moins un intervalle, la CPU écrit un message individuel dans le tampon de diagnostic et
redémarre la période de surveillance.
④ Signalisations groupées : Après trois diagnostics, la CPU ne génère plus qu'une signalisation
groupée, comme récapitulatif de tous les autres diagnostics dans cet intervalle. Si ces diagnos-
tics apparaissent aussi au cours des intervalles suivants, la CPU ne génère qu'une signalisation
groupée par intervalle.
Figure 9-57 Récapitulatif des diagnostics
Communication
9.4 Utilisation d'une CPU S7-1500 comme client OPC UA
9.4.1 Vue d'ensemble et conditions

Avec STEP 7 (TIA Portal) à partir de la version V15.1, vous pouvez paramétrer et programmer
un client OPC UA qui sera en mesure de lire des variables API dans un serveur OPC UA. Il est
possible en outre de transmettre à un serveur OPC UA de nouvelles valeurs pour des variables
API. De plus, vous pouvez appeler dans votre programme utilisateur des méthodes qu'un
serveur OPC UA met à disposition. Vous utilisez à cet effet les instructions pour clients OPC
UA dans votre programme utilisateur.
Les instructions du client OPC UA se basent sur la norme "PLCopen OPC-UA Client for
IEC61131-3".
Spécification PLCopen
Ces instructions standardisées vous permettent d'utiliser dans votre programme utilisateur
des fonctions client OPC UA exécutées dans une CPU S7-1500.
De plus, des adaptations minimes suffisent pour aussi exécuter ce programme utilisateur
dans des automates d'autres constructeurs, pourvu que ces constructeurs aient également
mis en œuvre la spécification OPC UA "PLCopen OPC-UA Client for IEC61131-3".
Éditeurs conviviaux dans STEP 7

Un éditeur convivial est à votre disposition dans TIA Portal - le paramétrage de liaison
(Page 1) - pour paramétrer les instructions pour clients OPC UA.
STEP 7 dispose en outre, à partir de la version 15.1, d'un éditeur pour interfaces client
(Page 1).
Ce paragraphe vous explique comment utiliser ces éditeurs.
Pour commencer, vous allez apprendre à créer et configurer une nouvelle interface avec
l'éditeur approprié, puisque vous aurez besoin d'une telle interface pour paramétrer ensuite
des liaisons.
Pour une meilleure compréhension, la description s'appuie sur un exemple (voir Description
de l'exemple (Page 1)).
Communication
Conditions
• Vous disposez de la licence Runtime pour OPC UA et avez configuré la licence dans STEP 7
(Propriétés de la CPU > Licences Runtime).
• Le client de la CPU S7-1500 est activé.
Pour utiliser le client de la CPU S7-1500, vous devez l'activer :
1. Dans les propriétés de la CPU, sélectionnez la zone "OPC UA > Client".
2. Activez l'option "Activer le client OPC UA".
Si vous n'activez pas le client, aucune liaison n'est établie. Vous recevez un message d'erreur
correspondant dans les instructions, par exemple dans "OPC_UA_Connect".
Vous trouverez des informations sur le nom d'application valable également pour le serveur
et le client ici (Page 1).
Vue d'ensemble
Pour utiliser l'éditeur et le paramétrage de liaison, procédez comme suit :
1. Créez d'abord une interface client. Ajoutez à cette interface les méthodes et variables API
auxquelles vous voulez accéder ("Première étape (Page 1)").
2. Paramétrez ensuite la liaison au serveur OPC UA (Deuxième étape (Page 1)).
3. Pour finir, utilisez la liaison paramétrée dans les instructions de client OPC UA (Troisième
étape (Page 1)).
9.4.2 Généralités sur les instructions client

La CPU S7-1500 en tant que client OPC UA vous permet, avec les instructions de client OPC
UA standardisées, de commander la communication pour les tâches suivantes :
• Lire/écrire des variables du serveur OPC UA
• Appeler des méthodes dans le serveur OPC UA
Les instructions facultatives vous permettent de déterminer les renseignements suivants :
• L'état de la liaison entre le client OPC UA et le serveur OPC UA
• Des NodeID de nœuds pour une plage d'adresses dont la hiérarchisation est connue
Communication
Déroulement standardisé de la communication OPC UA

Le déroulement de la communication, et donc l'ordre des instructions, se conforme à un
modèle qui est concrétisé ci-dessous.
① Instructions pour préparer les opérations de lecture et d'écriture

② Instructions de lecture et d'écriture
③ Instructions pour "nettoyer" une fois les opérations de lecture ou d'écriture effectuées
Figure 9-58 Ordre d'exécution d'une opération de lecture ou d'écriture
① Instructions pour préparer les appels de méthode

② Appels de méthode
③ Instructions pour "nettoyer" une fois les appels de méthode effectués
Figure 9-59 Ordre d'exécution d'un appel de méthode dans le serveur OPC UA
Communication
Instructions facultatives (lecture de l'état de la liaison / lecture de NodeID de nœuds

dans le cas d'une plage d'adresse dont la hiérarchisation est connue)
• OPC_UA_ConnectionGetStatus
• OPC_UA_TranslatePathList
① Instructions pour préparer les opérations de lecture et d'écriture avec instruction intercalée pour
demander par exemple les ID de nœud du serveur OPC UA.
② Parallèlement à d'autres instructions, vous pouvez déterminer l'état de la liaison entre son éta-
blissement et sa coupure
③ Instructions pour "nettoyer"
Figure 9-60 Ordre chronologique d'exécution des instructions optionnelle
Éditeurs conviviaux dans STEP 7

Les instructions de client OPC UA sont décrites en détail dans la partie de référence (système
information STEP 7). Un éditeur convivial est à votre disposition dans TIA Portal - le
paramétrage de liaison (Page 1) - pour paramétrer les instructions.
Pour la première ébauche du programme, nous conseillons de commencer par le
paramétrage de liaisons, puis d'utiliser d'autres instructions selon le besoin et d'optimiser le
programme manuellement.
Informations sur les instructions client

Les instructions client sont décrites de manière détaillée dans l'aide sur les instructions
(Instructions > Communication > OPC UA > OPC UA-Client).
Communication
Exemple d'application dans le support en ligne

Cet exemple d'application (https://support.industry.siemens.com/cs/ww/fr/view/109762770)
met à votre disposition un bloc utilisateur S7 "OpcUaClient" qui regroupe les principales
fonctions des instructions OPC UA, accélère la mise en œuvre et simplifie la programmation.
Dans cet exemple, un automate S7-1500 avec un programme de simulation simple pour les
valeurs de processus sert de serveur OPC UA.
Le bloc utilisateur S7 assure les fonctions suivantes :
• Connexion au serveur et déconnexion du serveur
• Diagnostic de la connexion et reconnexion automatique en cas de perte de la connexion
• Registered Read
• Registered Write
• Registered Method Call
9.4.3 Nombre d'instructions client utilisables simultanément
Nombre d'instructions client OPC UA utilisables simultanément

Les limites suivantes sont valables pour une utilisation simultanée d'instructions client OPC
UA (vous trouverez les caractéristiques techniques actualisées de la CPU sur Internet
(https://support.industry.siemens.com/cs/ww/fr/ps/td)) :
Tableau 9- 5 Quantités pour les instructions client OPC UA
Instruction OPC UA Nombre max. pour Nombre max. pour Nombre max. pour
CPU 1510SP (F) CPU 1505 CPU 1507S (F)
CPU 1513 (F) CPU 1516 (F/T/TF)
OPC_UA_Connect 4 10 40
OPC_UA_NamespaceGetIndexLi 4* 10* 40*
st
OPC_UA_NodeGetHandleList 4* 10* 40*
OPC_UA_MethodGetHandleList 4* 10* 40*
OPC_UA_TranslatePathList 4* 10* 40*
OPC_UA_ReadList 20 au total (5 par con- 50 au total (5 par con- 200 au total (5 par connexion
nexion au maximum, voir nexion au maximum, voir au maximum, voir
OPC_UA_Connect) OPC_UA_Connect) OPC_UA_Connect)
OPC_UA_WriteList 20 au total (5 par con- 50 au total (5 par con- 200 au total (5 par connexion
OPC_UA_MethodCall 20 au total (5 par con- 50 au total (5 par con- 200 au total (5 par connexion
Communication
Instruction OPC UA Nombre max. pour Nombre max. pour Nombre max. pour
CPU 1510SP (F) CPU 1505 CPU 1507S (F)
CPU 1513 (F) CPU 1516 (F/T/TF)
OPC_UA_NodeReleaseHandleLi 4* 10* 40*
st
OPC_UA_MethodReleaseHandl 4* 10* 40*
eList
OPC_UA_Disconnect 4* 10* 40*
OPC_UA_ConnectionGetStatus 4* 10* 40*
* 1 par connexion au maximum
Nombre maximal d'interfaces client OPC UA utilisables

Lorsque vous créez des interfaces client OPC UA à l'aide du paramétrage de la liaison, le
nombre d'interfaces client est limité à 40 au maximum.
Vous créez les interfaces client OPC UA en double-cliquant dans la zone "Communication OPC
UA" dans le navigateur du projet sur l'icône "Ajouter une nouvelle interface client".
Le nombre max. d'interfaces client OPC UA dépend du fait que la CPU est également utilisée
ou non comme serveur OPC UA.
9.4.4 Exemple de configuration pour OPC UA

Les chapitres suivants décrivent l'utilisation de l'éditeur pour les interfaces client et le
paramétrage des liaisons.
La description est basée sur un exemple concret : deux CPU S7-1500 travaillent dans
l'installation : une CPU joue le rôle de client OPC UA, l'autre celui de serveur OPC UA.
Il est possible, bien entendu, d'utiliser aussi des automates, des capteurs ou des systèmes IT
d'autres constructeurs comme clients ou comme serveurs OPC UA. L'échange de données
entre systèmes différents (interopérabilité) est justement un avantage majeur d'OPC UA.
Communication
Paramétrage de liaison dans notre exemple :

L'installation produit des pièces brutes dans une ligne de fabrication.
Elle utilise les automates suivants :
1. Une CPU S7-1511 sert de contrôleur pour la ligne de fabrication.
Ce contrôleur est mentionné dans l'exemple "Productionline".
Le serveur OPC UA de l'automate est activé.
Dans l'exemple, la CPU a l'adresse IP 192.168.1.1.
Cette CPU publie les valeurs des variables suivantes via le serveur OPC UA :
– NewProduct
La variable possède le type de données "Bool".
Quand la variable a la valeur TRUE, c'est que la ligne de fabrication a traité une pièce
brute.
qui peut être enlevée.
– ProductNumber
Cette variable contient le numéro d'identification de la pièce brute.
La variable possède le type de données "Int".
– Température
Cette variable contient des valeurs de température acquises pendant la fabrication de
la pièce brute.
La variable est un tableau d'éléments de type "Real".
Cette CPU met en outre à disposition la variable suivante autorisant l'écriture :
– ProductionEnabled
La variable est définie par le client OPC UA :
La variable possède le type de données "Bool".
Si la valeur est TRUE, la ligne de fabrication est libérée et a le droit de fabriquer des
pièces brutes.
De plus, cette CPU met à disposition la méthode suivante via le serveur OPC UA :
– OpenDoor.
Des clients OPC UA peuvent ainsi l'utiliser pour ordonner l'ouverture d'une porte
d'accès à la ligne de fabrication.
2. Une CPU S7-1516 contrôle la collaboration avec d'autres lignes de fabrication.
Dans l'exemple, cette CPU est nommée "Supervisor".
Le client OPC UA de cette CPU est activé.
À l'aide d'OPC UA, cette CPU peut lire les variables "NewProduct" et "ProductNumber",
définir la variable "ProductionEnabled" et appeler la méthode "OpenDoor".
Dans l'exemple, cette CPU a l'adresse IP 192.168.1.2.
Communication
La figure ci-dessous montre l'exemple dans la vue de réseau de TIA Portal :
Figure 9-61 Exemple de paramétrage de connexion dans la vue de réseau
9.4.5 Création d'interfaces client

À partir de sa version 15.1, TIA Portal dispose d'un éditeur pour interfaces client.
Vous réunissez dans une interface client toutes les variables API que vous voulez lire ou écrire
dans un serveur OPC UA.
En outre, l'interface client contient toutes les méthodes que le serveur OPC UA met à
disposition et que vous voulez appeler avec votre programme utilisateur (qui joue le rôle de
client OPC UA).
Lorsque vous créez une interface client, STEP 7 crée aussi des blocs de données pour le
paramétrage de la liaison au serveur OPC UA dans lequel vous voulez lire des données ou
écrire des données.
Nombre maximal d'interfaces client

Vous pouvez créer au maximum 40 interfaces client.
Communication
Éditeur pour interfaces client

Pour créer une interface client, procédez comme suit :
1. Sélectionnez la vue de projet dans TIA Portal.
2. Sélectionnez dans la zone "Appareils" la CPU que vous voulez utiliser comme client OPC UA.
3. Cliquez sur "Communication OPC UA > Interfaces client".
4. Double-cliquez sur "Ajouter une nouvelle interface client".
STEP 7 génère une nouvelle interface client et l'affiche dans l'éditeur :
Figure 9-62 Ajouter une nouvelle interface client OPC UA
STEP 7 appelle cette nouvelle interface "Interface client_1". Si une "Interface client_1"
existe déjà, la nouvelle interface a pour désignation "Interface client_2", etc.
STEP 7 génère en outre les blocs de données suivants :
– Interface_client_1_Configuration
Ce bloc de données contient déjà tous les types de données système requis pour les
instructions du client OPC UA.
Ce bloc de données est rempli si vous paramétrez la liaison avec le serveur OPC UA.
Vous paramétrez une liaison dans les propriétés de l'interface client, voir : Exemple de
configuration pour OPC UA (Page 1).
– Interface_client_1_Data
Un bloc de données pour les variables API que vous voulez lire ou écrire dans un
serveur OPC UA ainsi que pour des méthodes que vous voulez appeler dans le serveur
OPC UA.
Vous l'utiliserez dans votre programme utilisateur.
Actuellement, il est encore vide.
5. Utilisez un nom expressif pour la nouvelle interface client.
Dans l'exemple, choisissez "Productionline".
Vous changez ainsi les noms des blocs de données correspondants en :
– Productionline_Data
– Productionline_Configuration
Communication
6. Pour importer une interface serveur OPC UA, cliquez sur le bouton "Importer interface" en
haut à droite.
Vous pouvez ainsi importer un fichier XML décrivant l'interface serveur d'un serveur OPC
UA.
Autre possibilité : Vous déterminez en ligne l'interface de serveur d'un serveur OPC UA
connecté, voir : Déterminer l'interface serveur en ligne (Page 1).
7. STEP 7 affiche une boîte de dialogue dans laquelle vous pouvez sélectionner un fichier XML.
Ce fichier XML décrit la plage d'adresses d'un serveur OPC UA.
La plage d'adresses d'un serveur OPC UA contient toutes les variables API et méthodes de
serveur publiées par un serveur OPC UA.
Les clients OPC UA peuvent accéder à cette plage d'adresses :
- Lire des variables API
- Écrire des variables API
- Appeler des méthodes de serveur
La plage d'adresses d'un serveur OPC UA peut être subdivisée en une ou plusieurs
interfaces serveur.
Voir Créer une interface serveur pour la spécification Companion (Page 1) pour plus
d'informations sur la création d'interfaces serveur.
Communication
8. Générez une liste de lecture dans cette interface client.

– Cliquez sur "Ajouter une nouvelle liste de lecture" dans la partie gauche de l'éditeur.
STEP 7 ajoute une nouvelle liste portant le nom "Liste_lecture_1".
Dans l'exemple, changez ce nom en "ReadListProduct".
– Ajoutez ensuite à la nouvelle liste de lecture les variables API que vous voulez lire à
partir du serveur OPC UA.
Dans l'exemple, les variables "NewProduct" et "ProductNumber" sont ajoutées à la liste
de lecture "ReadListProduct".
Sélectionnez la variable "NewProduct" dans la partie droite de l'éditeur ("Interface
serveur OPC UA"). Faites glisser la variable "NewProduct" dans la liste de lecture
"ReadProduct" dans la partie centrale de l'éditeur. Procédé de la même manière avec la
variable "ProductNumber".
La figure suivante montre la partie droite du tableau :
Figure 9-63 Liste de lecture dans l'interface serveur OPC UA
Autre possibilité :
Vous pouvez également créer une nouvelle liste de lecture en sélectionnant dans la partie
droite de l'éditeur ("Interface serveur OPC UA") un nœud du type Object ou Folder et en le
faisant glisser vers "Ajouter une nouvelle liste de lecture" dans la partie gauche de
l'éditeur. Cette nouvelle liste de lecture contient alors toutes les variables API du nœud
placé.
Dans l'exemple, choisissez l'objet "Data_for_OPC_UA_Clients" qui contient les variables
"NewProduct" et "ProductNumber". STEP 7 crée la nouvelle liste de lecture
"Data_for_OPC_UA_Clients". L'objet contient également la variable "Temperature".
Supprimez la variable "Temperature" de la liste de lecture, car elle ne doit pas être lue dans
l'exemple.
Changez le nom de la liste de lecture en "ReadListProduct".
Communication
La figure suivante montre le contenu de la liste de lecture :
Figure 9-64 Liste de lecture
Remarque
Les listes de lecture et d'écriture ne prennent pas en charge tous les types de nœuds
Le client OPC UA de la CPU S7-1500 ne prend pas en charge tous les types de données
OPC UA (types de nœuds) pouvant être mis à disposition par le biais d'une interface
serveur OPC UA. Si vous mettez un type de nœud non pris en charge dans une liste de
lecture ou d'écriture par exemple, un message d'erreur correspondant est émis. Dans ce
cas, vous ne pouvez pas ajouter le nœud correspondant à la liste de lecture ou d'écriture.
Les types pris en charge sont indiqués ici : Mappage de types de données (Page 1)
9. Si vous voulez donner de nouvelles valeurs à des variables API, générez une liste d'écriture
dans cette interface client.
– Cliquez sur "Ajouter une nouvelle liste d'écriture" dans la partie gauche de l'éditeur.
STEP 7 ajoute une nouvelle liste portant le nom "Liste d'écriture_1".
Dans l'exemple, changez ce nom en "WriteListStatus".
– Ajoutez maintenant à la liste d'écriture toutes les variables du serveur OPC UA
auxquelles vous voulez affecter de nouvelles valeurs.
Dans l'exemple, ajoutez la variable "ProductionEnabled" à la liste d'écriture
"WriteListStatus".
Sélectionnez la variable dans la partie droite de l'éditeur ("Interface serveur OPC UA").
Faites glisser la variable dans la liste de lecture dans la partie centrale de l'éditeur.
Vous pouvez également créer une nouvelle liste d'écriture en sélectionnant dans la partie
droite de l'éditeur ("Interface serveur OPC UA") un nœud du type Object ou Folder et en le
faisant glisser vers "Ajouter une nouvelle liste d'écriture" dans la partie gauche de l'éditeur.
Cette nouvelle liste d'écriture contient alors toutes les variables du nœud concerné.
Dans l'exemple, choisissez l'objet "Data_from_OPC_UA_Clients" qui contient la variable
"ProductionEnabled". STEP 7 crée la nouvelle liste d'écriture "Data_from_OPC_UA_Clients".
Changez le nom en "WriteListStatus".
La figure suivante montre le contenu de la liste d'écriture :
Figure 9-65 Liste d'écriture
Communication
10.Si vous voulez appeler une méthode de ce serveur OPC UA, créez une nouvelle liste de
méthodes.
– Cliquez sur "Ajouter une nouvelle liste de méthodes" dans la partie gauche de l'éditeur.
STEP 7 ajoute une nouvelle liste portant le nom "Liste de méthodes_1".
Dans l'exemple, changez ce nom en "MethodListOpenDoor".
– Ajoutez maintenant à la liste de méthodes une méthode du serveur OPC UA.
Dans cet exemple, ajoutez la méthode "OpenDoor" à la liste de méthodes
"MethodListOpenDoor".
Sélectionnez la méthode dans la partie droite de l'éditeur ("Interface serveur OPC UA").
Faites glisser la méthode dans la liste de méthodes dans la partie centrale de l'éditeur.
Vous pouvez également créer une nouvelle liste de méthodes en sélectionnant dans la
partie droite de l'éditeur ("Interface serveur OPC UA") une méthode (nœud du type Object)
et en la faisant glisser vers "Ajouter une nouvelle liste de méthodes" dans la partie gauche
de l'éditeur. Cette nouvelle liste de méthodes contient alors la méthode du nœud
concerné.
La figure suivante montre le contenu de la liste de méthodes :
Figure 9-66 Liste de méthodes
Si vous voulez appeler une autre méthode du serveur OPC UA, vous devez créer une
nouvelle liste de méthodes. Chaque liste de méthodes ne contient qu'une seule méthode.
Voir aussi Informations utiles sur les méthodes de serveur (Page 1).
11.Compilez le projet.
Pour cela, sélectionnez-le et cliquez sur l'icône suivante dans la barre d'outils :
STEP 7 compile le projet et met à jour les blocs de données appartenant à l'interface client
"Productionline".
Remarque
Lors de la compilation, STEP 7 écrase toutes les données dans les blocs de données
appartenant à l'interface client. C'est pour cette raison que vous ne devez pas compléter ou
corriger ces blocs de données manuellement.
Communication
Remarque
Renommer des noms de nœuds (DisplayNames)
Vous pouvez modifier le nom d'un nœud dans des listes de lecture, d'écriture et de méthodes
via le menu contextuel. Dans le langage OPC UA, il s'agit du "DisplayName".
Si vous modifiez le nom du nœud d'une liste de méthode alors que le nœud est déjà utilisé
dans un bloc programmé pour l'appel de méthode "OPC_UA_MethodCall", la compilation du
projet entraîne des erreurs de cohérence : les UDT de la méthode sont de nouveau générés
lors de la compilation avec un autre nom. Les références à la méthode utilisées dans le
programme ne correspondent plus.
Pour corriger les erreurs de cohérence, vous pouvez annuler le changement de nom de la
méthode dans l'interface client, ou naviguer jusqu'à l'appel de méthode et y réaffecter les
paramètres concernés sous "Propriétés > Paramètres de bloc" (onglet "Configuration").
Communication
Blocs de données de l'interface client

Les blocs de données suivants font partie de l'interface client "Productionline":
• Productionline_Configuration
Un bloc de données pour la configuration.
Dans l'exemple, ce bloc de données a pour nom "Productionline_Configuration".
Ce bloc de données contient déjà tous les types de données système requis pour les
instructions du client OPC UA.
Il contient en outre des valeurs par défaut générales pour le paramétrage de la liaison à un
serveur OPC UA.
Il se remplira lorsque vous utiliserez le paramétrage de liaison.
• Productionline_Data
Un bloc de données pour les variables API que vous avez saisies dans l'éditeur d'interface
client.
Dans l'exemple, ce bloc de données a pour nom "Productionline_Data".
La figure suivante montre le bloc de données.
Figure 9-67 Bloc de données "Productionline_Data"
Vous utilisez le bloc de données "Productionline_Data" dans votre programme utilisateur

et accédez aux valeurs lues des variables API "NewProduct" et "ProductNumber". Le
paragraphe suivant donne un exemple pour expliquer les faits.
Communication
Lire et écrire les variables API de l'interface client

Exemple : lire la valeur "ProductNumber"
Dans un programme SCL, vous écrivez par exemple :
#MyLocalVariable :=
"Productionline_Data".ReadListProduct.Variable.ProductNumber;
Vous affectez ainsi à la variable locale "#MyLocalVariable", par exemple, le numéro de la pièce
brute qui vient d'être terminée dans la ligne de fabrication.
Conditions :
• Il y a une liaison au serveur OPC UA de la CPU qui commande la ligne de fabrication.
• Le client OPC UA a lu les valeurs actuelles.
C'est pourquoi vous devez contrôler si une valeur lue est valable :
• Vérifiez si la valeur dans "Productionline_Data".ReadListProduct.NodeStatusList[1] est
égale à 0.
• En option, vérifiez quand cette valeur a été lue par le serveur OPC UA. Cette valeur se
trouve dans "Productionline_Data".ReadProduct.TimeStamps[1]. La charge due à la
communication diminue si aucun horodatage n'est demandé.
Exemple : écrire la valeur "ProductEnabled"
Avec le bloc de données, vous transmettez au serveur OPC UA de nouvelles valeurs pour des
variables API. Dans l'exemple, il s'agit de la variable "ProductionEnabled".
L'instruction suivante vous permet de libérer la ligne de fabrication dans l'installation prise
pour exemple :
"Productionline_Data".WriteListStatus.Variable.ProductionEnabled :=
TRUE;
Mais la validation ne réussit que si les conditions suivantes sont remplies :
• Il y a une liaison au serveur OPC UA de la CPU qui commande la ligne de fabrication.
• Les valeurs actuelles sont écrites au moyen du client OPC UA.
Communication
Pour terminer, contrôlez la cohérence des listes de lecture, d'écriture et de méthodes.
1. Sélectionnez la liste que vous souhaitez contrôler.
2. Cliquez sur le bouton "Contrôle de cohérence" au-dessus de la zone "Interface client
OPC UA".
Une affectation sans erreur des variables ou des méthodes aux éléments correspondants de
l'interface serveur est affichée par une coche verte.
Vous pouvez partir du principe que l'échange de données entre client et serveur, ainsi que les
appels de méthodes, fonctionnent sans problème pendant l'exécution.
En cas d'erreur, une liste est affichée dans la fenêtre d'inspection. De cette liste, vous pouvez
sauter à l'erreur correspondante.
STEP 7 effectue les vérifications suivantes lors du contrôle de cohérence :
• Tous les éléments que vous utilisez dans la liste correspondante existent-ils également
dans le serveur ?
• Les types de données correspondent-ils ?
• Pour les méthodes : le nombre, les noms, l'ordre et les types de données d'arguments de
méthode correspondent-ils ?
9.4.6 Déterminer l'interface serveur en ligne

Avec STEP 7 (TIA Portal), vous pouvez déterminer en ligne l'interface d'un serveur OPC UA. De
cette manière, vous apprenez à quelles variables d'un serveur OPC UA connecté vous pouvez
accéder en lecture ou en écriture (mettre à 1) avec des clients OPC UA. Vous apprenez
également quelles méthodes de serveur le serveur OPC UA met à disposition pour des clients
OPC UA.
Si vous travaillez hors ligne, vous pouvez créer l'interface du serveur OPC UA via un fichier
XML OPC UA. Le fichier XML OPC UA contient une description de la plage d'adresses du
serveur, voir : Exporter fichier XML OPC UA (Page 1)
Communication
Déterminer l'interface serveur en ligne

Pour déterminer une interface serveur en ligne, procédez comme suit :
1. Dans le navigateur de projet de STEP 7, sélectionnez la CPU configurée comme client OPC
UA (dans l'exemple Supervisor).
2. Sélectionnez l'interface client (dans l'exemple Communication OPC UA > Interfaces client >
Productionline).
Si aucune interface client n'a encore été créée, double-cliquez sur "Ajouter une nouvelle
interface client".
3. Double-cliquez sur l'interface client sélectionnée.
L'éditeur pour interfaces client s'affiche :
Figure 9-68 Éditeur pour interface client
4. Dans la partie gauche de l'éditeur, cliquez sur "Ajouter une nouvelle liste de lecture", "Ajouter
une nouvelle liste d'écriture" ou "Ajouter une nouvelle liste de méthodes".
5. Dans la partie droite de l'éditeur pour "Source des données de serveur", sélectionnez "En
ligne[]" comme source de données :
Communication
6. Cliquez sur le bouton "Accès en ligne".

STEP 7 affiche la boîte de dialogue "Connecter au serveur OPC UA" :
Figure 9-69 Boîte de dialogue "Connecter au serveur OPC UA"
Astuce : Utilisez le bouton "Accès en ligne" si vous établissez une liaison en ligne à un
serveur OPC UA pour la première fois. Si vous rétablissez la liaison après une interruption,
sélectionnez le bouton "Connexion au serveur en ligne" à côté du champ de sélection "En
ligne".
Entrez en haut à droite l'adresse IP du serveur OPC UA dont vous souhaitez déterminer
l'interface serveur en ligne.
7. Cliquez sur le bouton "Trouver le serveur sélectionné".
STEP 7 établit une connexion au serveur OPC UA et détermine tous les paramètres de
sécurité (server endpoints) mis à disposition par le serveur.
STEP 7 affiche les nœuds d'extrémité sous forme de liste :
Figure 9-70 Serveur OPC UA détecté avec tous les nœuds d'extrémité de serveur
Communication
8. Cliquez sur le nœud d'extrémité que vous souhaitez utiliser pour une liaison de STEP 7 au
serveur OPC UA.
9. Voulez-vous utiliser une liaison sécurisée ?
– Si vous avez sélectionné un nœud d'extrémité de sécurité, choisissez l'entrée
"TIA Portal" comme "Lieu de stockage du certificat".
Pour "Certificat (client)", sélectionnez un certificat client pour le PC sur lequel STEP 7
(TIA Portal) est en cours d'exécution.
Si aucun certificat client n'existe encore pour votre PC, vous pouvez générer un
certificat client ici dans TIA Portal.
Procédez comme suit pour générer un certificat pour votre PC :
- Cliquez sur le bouton dans le champ de saisie "Certificat (client)".
- Cliquez le bouton "Ajouter".
- Pour "Demandeur de certificat", indiquez "STEP 7 (TIA Portal)".
- Sélectionnez l'entrée "Client OPC UA" comme "Utilisation".
- Pour "Autre nom du demandeur de certificat (SAN)", indiquez sous "Valeur" l'adresse
IP du PC sur lequel STEP 7 (TIA Portal) est en cours d'exécution. Écrasez l'adresse IP déjà
inscrite.
- Si votre PC utilise une deuxième adresse IP, indiquez-la également. Si votre PC
n'utilise pas de deuxième adresse IP, effacez la deuxième adresse IP déjà indiquée.
- Cliquez sur le bouton "OK".
– Si vous n'avez pas sélectionné de nœud d'extrémité de sécurité, conservez le
paramétrage par défaut ("Aucun").
10.Comment souhaitez-vous vous connecter ?
– Si vous souhaitez vous connecter comme invité au serveur OPC UA, conservez le
paramétrage par défaut "Authentification de l'utilisateur".
– Si vous souhaitez vous connecter avec votre nom d'utilisateur et votre mot de passe,
choisissez "Nom d'utilisateur et mot de passe".
Utilisez le nom d'utilisateur et le mot de passe définis dans la configuration du serveur
OPC UA, dans les propriétés de la CPU, sous "Général´ > OPC UA > Serveur > Security >
Authentification de l'utilisateur > Gestion des utilisateurs".
Communication
11.Cliquez sur le bouton "Connecter".

En cas de liaison sécurisée, un message supplémentaire indique que vous devez accepter
le certificat du serveur pour permettre l'établissement d'une liaison sécurisée. Un lien dans
la fenêtre de message vous permet d'afficher des renseignements supplémentaires sur le
certificat du serveur.
Cette fenêtre Windows standard fournit uniquement des informations sur le certificat du
serveur. Si vous cliquez sur le bouton pour l'installation du certificat du serveur, le
certificat n'est pas enregistré dans le magasin de certificats de TIA Portal de sorte qu'il vous
sera à nouveau demandé d'accepter le certificat du serveur lors de la prochaine tentative
de connexion.
STEP 7 établit alors une liaison au serveur OPC UA et affiche de nouveau l'éditeur pour les
interfaces client.
Dans la partie droite de l'éditeur, STEP 7 représente le niveau supérieur de la plage
d'adresses du serveur OPC UA :
12.Cliquez sur le petit triangle noir en regard de "Objects".

STEP 7 affiche alors le niveau en-dessous de Objects.
13.Cliquez sur le petit triangle noir en regard de "Productionline".
STEP 7 affiche alors le niveau en-dessous de Productionline.
14.Ouvrez les dossiers de niveau inférieur :
Figure 9-71 Vue en ligne de l'interface serveur OPC UA
Voir aussi
Mappage de types de données (Page 1)
Création d'interfaces client (Page 1)
Communication
9.4.7 Utiliser des textes multilingues

Dans l'éditeur pour les interfaces client, vous importez également avec les fichiers XML OPC
UA (modèles d'information) des textes qui peuvent être affichés dans différentes langues. Le
multilinguisme est facultatif, chaque nœud (Node) peut être défini différemment au regard
des langues proposées.
Dans le fichier XML, les champs suivants peuvent être préparés pour différentes langues :
• DisplayName
• Description
Exemple pour des textes définis comme multilingues dans un fichier XML OPC UA
Dans le fichier XML affiché, les champs Displayname et Description sont par exemple
renseignés à la fois avec un texte par défaut et plusieurs textes localisés.
• Le texte par défaut est la première entrée sans information de localisation
• Le texte localisé est le texte situé après "Locale=" suivi d'un code langue, par exemple "it-
IT" pour italien.
Figure 9-72 Exemple pour des textes multilingues dans un fichier XML OPC UA
Communication
Affichage de textes multilingues

Lors de l'importation d'une interface serveur, les textes multilingues disponibles sont
enregistrés de manière interne et également chargés avec le projet dans une CPU.
L'éditeur client affiche le texte du fichier XML OPC UA dans les colonnes "Nom du nœud"
(correspond à "DisplayName") et "Description" (correspond à "Description").
La langue affichée pour un nœud dépend des règles de mise en cascade suivantes :
• Si le nœud contient du texte dans la langue d'édition actuellement utilisée, le texte
s'affiche également dans la langue d'édition.
(réglage de la langue d'édition : dans le navigateur du projet, sélectionnez la zone
"Langues & Ressources > Langues du projet")
• Si le nœud ne contient pas de texte dans la langue d'édition mais qu'un texte par défaut y
est défini (sans code de langue), le texte par défaut s'affiche.
• Colonne "Nom du nœud" : Si aucun texte par défaut n'est défini mais qu'un texte est
présent dans une autre langue quelconque, le texte DisplayName s'affiche dans la
première langue présente. Cette règle ne s'applique pas aux textes de description.
• Si aucune des conditions citées ci-dessus n'est remplie, aucun texte ne s'affiche.
Figure 9-73 Affichage de textes multilingues
Si vous changez de langue d'édition, le texte multilingue est également modifié selon les
règles expliquées ci-dessus dans l'interface importée.
Vous pouvez ensuite reprendre les nœuds en les faisant glisser dans les listes
correspondantes (liste de lecture, liste d'écriture, liste de méthodes).
Un changement de langue dans les listes (liste de lecture, liste d'écriture, liste de méthodes)
est impossible.
Reprise des textes de description affichés comme commentaire dans des types de données API
Lorsque vous compilez le programme, STEP 7 génère automatiquement des types de données
API (UDT) pour chaque liste de lecture, pour chaque liste d'écriture et pour les entrées et
sorties de chaque méthode. Ces types de données utilisateur possèdent respectivement un
élément pour chaque nœud.
Les types de données utilisateur reprennent le texte de description en tant que commentaire
selon les règles expliquées ci-dessus. STEP 7 génère le commentaire dans une seule langue de
la même manière que les textes dans l'interface serveur OPC UA ne peuvent être affichés que
dans une seule langue.
Communication
9.4.8 Règles d'accès à des structures

Le paragraphe suivant décrit les règles d'accès à des structures. Tenez compte de ces règles
lors de l'accès en lecture et en écriture à des valeurs de structures complètes mises à
disposition par un serveur OPC UA.
Procédure d'accès du client OPC UA de la CPU S7-1500 à des structures

Le client OPC UA de la CPU S7-1500 n'utilise pour un accès performant à des structures en
cours d'exécution ni des attributs TypeDictionaries, ni des attributs DataTypeDefinition mis à
disposition par un serveur pour la résolution de ces structures.
Les possibilités de contrôles des éléments de structures pendant l'exécution du programme
utilisateur dans le client sont donc limitées pour le client OPC UA.
Règles d'accès à des structures

Si vous utilisez les interfaces client pour la configuration des listes de lecture et d'écriture
(paramétrage de la liaison) et affectez types de données API en fonction du modèle de
serveur d'adresse déterminé à importer ou en ligne, les accès en lecture et en écriture à des
structures fonctionnent sans problème.
La configuration à l'aide de l'interface client garantit automatiquement que l'ordre et les types
de données des éléments de structure côté client et côté serveur sont harmonisés.
Recommandation : actualisez une CPU S7-1500 (comme serveur) à la version de firmware
actuelle (par exemple, de V2.0 à V2.5.2 ou version ultérieure).
Pendant l'exécution, le client OPC UA ne contrôle que la longueur globale de la valeur
déterminée. Des contrôles détaillés ne sont pas possibles.
Les règles de mappage sont valables pour l'affectation de structures OPC UA à des variables
API ou des variables de blocs de données (voir Mappage de types de données (Page 1)). Les
types de données non indiqués (par ex. des chaînes d'octets OPC UA) ne sont pas pris en
charge.
Exemple d'affectation correcte d'éléments de structure

La structure est définie de la manière suivante dans le fichier Nodeset importé (exportation
XML) :
Communication
La structure affichée dans la liste de lecture correspond au nœud du fichier Nodeset

correspondant en termes d'ordre et de types de données affectés.
Si la structure est alors modifiée sur le serveur, par exemple si varA et varB sont interverties,
sans modification de la liste de lecture dans le client, l'affectation ne correspond plus.
• La longueur totale des données reste la même (seul l'ordre a été modifié).
• La structure diffère dans le client et dans le serveur !
ATTENTION
Aucun message d'erreur en cas de structure différente entre le client et le serveur
Lorsque les structures ne correspondent pas dans le client et dans le serveur, il se peut que
cette violation de règle ne génère pas de message d'erreur ni de la compilation, ni pendant
l'exécution.
Veillez à ne pas modifier les affectations configurées pour les structures pendant
l'exécution. Le cas échéant, configurez à nouveau les affectations dans les listes de lecture
et d'écriture !
9.4.9 Utiliser le paramétrage de liaison
9.4.9.1 Création et paramétrage de liaisons

Avec les instructions pour clients OPC UA, vous élaborez un programme utilisateur qui
échange des données avec un serveur OPC UA. Une série de types de données système sont
nécessaires pour cela.
À partir de la version 15.1, STEP 7 (TIA Portal) dispose d'un paramétrage de liaison pour
clients OPC UA qui facilite le travail avec ces types de données système.
Le paramétrage de liaison est une option que vous pouvez, mais ne devez pas utiliser. Vous
pouvez aussi créer manuellement les types de données système nécessaires.
Nous nous appuyons sur un exemple (voir description de l'exemple (Page 1)) pour que la
description soit compréhensible.
Communication
Ouvrir le paramétrage de liaison

Pour paramétrer la liaison à un serveur OPC UA, procédez comme suit :
1. Dans le navigateur du projet, double-cliquez dans la zone "Communication OPC UA" sur
l'interface de client que vous voulez paramétrer.
Pour l'exemple de configuration : Double-cliquez sur l'interface de client "Productionline" :
Le chapitre "Créer des interfaces client (Page 1)" montre comment créer une interface
client.
2. Cliquez sur l'onglet "Propriétés" (fenêtre d'inspection) s'il n'est pas déjà affiché.
STEP 7 affiche à présent le paramétrage de liaison pour les instructions du client OPC UA.
L'onglet "Général" est ouvert.
3. Cliquez sur l'onglet "Configuration" et paramétrez la liaison au serveur OPC UA.
Régler les paramètres de liaison

1. Choisissez un nom expressif pour la session. Pour l'exemple, choisissez le nom "OPC UA
Connection to Productionline".
2. Tapez dans le champ "Adresse" l'adresse IP du serveur OPC UA auquel votre programme
utilisateur, qui travaille comme client OPC UA, doit établir une liaison. Dans l'exemple de
configuration, la CPU qui commande la ligne de fabrication possède l'adresse IP
"192.168.1.1". Il s'agit d'établir une liaison au serveur OPC UA de cette CPU, vous écrivez
donc cette adresse IP dans le champ "Adresse". Le serveur OPC UA utilise dans ce cas le port
par défaut 4840.
Autre solution : vous pouvez entrer un nom DNS valide dans le champ "Adresse". La
longueur du nom DNS est limitée à 242 caractères.
Si l'adresse n'est pas valide, le message suivant s'affiche : "Entrez une adresse valide".
Si la chaîne de caractères des champs "Adresse", "Port" et "Chemin" comprend plus de 254
caractères, un message s'affiche pour le signaler au client.
Communication
3. Saisissez un chemin sur le serveur OPC UA afin de limiter l'accès à ce chemin. Cette
indication est optionnelle. Certains serveurs n'établissent cependant de connexion que si un
chemin de serveur est indiqué.
Si vous indiquez un chemin, celui-ci est automatiquement écrit pour l'interface client dans
l'entrée "ServerEndpointUrl" du DB de configuration. L'entrée se compose alors des
éléments "Préfixe du schéma OPC", "Adresse IP", "Numéro de port" et "Chemin du serveur",
par exemple "opc.tcp://192.168.0.10:4840/exemple/chemin".
La figure suivante montre la saisie de l'adresse IP du serveur OPC UA :
Figure 9-74 Paramètres de liaison
4. Si le serveur OPC UA n'utilise pas le port par défaut 4840, il faut entrer ici le numéro du port.
Tapez dans le champ le numéro 65535, par exemple, si le serveur OPC UA auquel vous
voulez établir une liaison utilise ce numéro de port.
5. Vous acceptez en outre les valeurs par défaut pour le "Dépassement de délai de session" (30
secondes) et le "Temps de surveillance" (5 secondes).
Définir les paramètres de sécurité

1. Cliquez sur l'onglet "Configuration" de la zone "Sécurité".
Cette zone contient tous les paramètres de sécurité pour la liaison au serveur OPC UA.
Les paramètres suivants peuvent être définis :
Zone "Général"
Mode de sécurité :
Choisissez dans la liste déroulante le mode de sécurité que la liaison au serveur OPC UA doit
réaliser.
Si le serveur ne remplit pas les conditions pour le mode choisi, aucune session n'est établie.
Communication
Vous avez le choix entre les options suivantes :

• Aucune sécurité : pas de liaison sécurisée !
• Signature : le serveur et le client OPC UA signent la transmission de données (tous les
messages) : ceci permet de détecter les manipulations éventuelles.
• Signature et cryptage : le serveur et le client OPC UA signent et cryptent la transmission de
données (tous les messages) :
Stratégie de sécurité :
Paramétrez les techniques de cryptage pour signer et crypter des messages.
Les réglages suivants sont possibles :
• Aucune sécurité
• Basic128Rsa15
• Basic256
• Basic256Sha256
Lorsque vous configurez une liaison sécurisée, vous devez tenir compte des points suivants :
• Un certificat est nécessaire pour le client pour une liaison sécurisée.
• Vous devez indiquer le certificat de client au serveur.
La marche à suivre est décrite au chapitre "Utilisation des certificats du client et du serveur
(Page 1)" sous "Certificat du client OPC UA".
Zone "Certificats"
Certificat client :
Le certificat confirme l'authenticité du client OPC UA.
Pour sélectionner un certificat, cliquez sur le symbole suivant :
STEP 7 affiche une liste de certificats.

Sélectionnez-y le certificat que vous avez indiqué au serveur.
Cliquez sur le symbole avec la coche verte :
ou bien générez un nouveau certificat. Pour cela, cliquez sur l'icône "Ajouter".
Lorsque vous générez un nouveau certificat, vous devez communiquer ce certificat au
serveur.
Communication
Zone "Authentification utilisateur"

Les options suivantes sont disponibles pour l'authentification utilisateur :
• Invité
• Nom d'utilisateur et mot de passe
• Utilisateur (TIA Portal - paramètres de sécurité)
Pour plus d'informations, voir Utilisateur et rôles avec les droits de fonction OPC UA (Page 1).
Réglage des langues

Les variables UA de type String peuvent être localisées pour OPC UA. Cela signifie que des
textes (valeurs pour la variable UA) peuvent être présentes sur le serveur dans différentes
langues nationales. Des textes localisés peuvent par exemple être présents pour DisplayName
(nom du nœud) et Description (description).
Dans la zone "Langues" de l'onglet "Configuration", vous avez la possibilité d'influencer de la
manière suivante la langue des textes retournés par le serveur :
Dans la zone "Langues", entrez une suite de langues que le serveur doit transmettre au client
lors de l'établissement de la liaison.
La langue ou l'ID locale ainsi liée ("Code langue") que vous entrez dans la première ligne est la
langue privilégiée par le client.
• Si le serveur peut fournir la variable UA dans la langue souhaitée, elle est alors transmise
au client.
• Si le serveur ne peut pas fournir la variable UA dans la langue souhaitée, il vérifie alors s'il
peut fournir la variable UA dans la langue que vous avez entrée dans la deuxième ligne
(1re langue de remplacement).
• Le serveur traite ainsi la liste et s'il ne peut fournir ni la langue souhaitée ni une langue de
remplacement, il fournit alors la langue par défaut.

Quelles sont les causes en cas d'échec de l'établissement de la liaison à un serveur OPC UA ?
FAQ (https://support.industry.siemens.com/cs/ww/fr/view/109766709)
Voir aussi
Communication
9.4.9.2 Manipulation des certificats de client de la CPU S7-1500
D'où provient le certificat du client ?

Lorsque vous utilisez le client OPC UA d'une CPU S7-1500 (client OPC UA activé), vous pouvez
générer des certificats pour ces clients avec STEP 7 à partir de V15.1, comme indiqué dans les
paragraphes suivants.
Si vous utilisez des clients UA de constructeurs ou de OPC Foundation, un certificat de client
est automatiquement créé lors de l'installation ou du premier appel du programme. Vous
devez importer ces certificats dans STEP 7 avec le gestionnaire de certificats global et les
utiliser pour la CPU respective.
Lorsque vous programmez vous-même un client OPC UA, vous pouvez créer des certificats
par programme. Vous pouvez également créer des certificats à l'aide d'outils, par exemple
OpenSSL ou le générateur de certificats de OPC Foundation :
• Pour la marche à suivre avec OpenSSL, voir "Créer soi-même une paire de clés PKI et des
certificats (Page 1)".
• Pour la marche à suivre avec le générateur de certificats d'OPC Foundation, voir "Création
de certificats autosignés (Page 1)".
Certificat du client OPC UA de la CPU S7-1500

Une liaison sécurisée entre le serveur OPC UA et un client OPC UA est réalisée seulement
quand le serveur classe le certificat du client comme approuvé.
Vous devez pour cela indiquer le certificat de client au serveur.
Les paragraphes suivants décrivent comment créer d'abord un certificat pour le client OPC UA
de la CPU S7-1500 et le mettre ensuite à disposition du serveur.
1. Créer et exporter un certificat pour le client

Pour établir une liaison sécurisée, vous devez générer un certificat de client et l'exporter si le
serveur et le client se trouvent dans des projets différents.
Si le client et le serveur se trouvent dans le même projet, il n'est pas nécessaire d'exporter le
certificat client puis de l'importer.
Conditions
L'interface IP de la CPU est configurée et il existe une adresse IP.
Explication : l'adresse IP sous laquelle la CPU est accessible dans votre installation est indiquée
sous "Autre nom du demandeur de certificat (SAN)".
Générer un certificat client OPC UA

La manière la plus simple de générer un certificat client pour une CPU S7-1500 est de
configurer une interface client.
La configuration de l'interface client prévoit la sélection ou la génération d'un certificat client
(voir Création et paramétrage de liaisons (Page 1)).
Communication
Vous pouvez également générer le certificat client de la manière suivante :

1. Sélectionnez dans le "Navigateur du projet" la CPU qui fonctionne comme client.
2. Double-cliquez sur "Configuration de l'appareil"
3. Dans les propriétés de la CPU, cliquez sur "Protection & sécurité > Gestionnaire de
certificats".
4. Dans le tableau "Certificats d'appareil", double-cliquez sur "<ajouter nouveau>".
STEP 7 ouvre une boîte de dialogue.
5. Cliquez sur le bouton "Ajouter".
6. Dans la liste, sélectionnez l'entrée "Client OPC UA" comme "Utilisation".
STEP 7 affiche maintenant le certificat de client dans le tableau "Certificats d'appareil".
8. Si le serveur se trouve dans un autre projet, cliquez avec le bouton droit de la souris sur cette
ligne et sélectionnez le menu contextuel "Exporter le certificat".
9. Sélectionnez un répertoire dans lequel vous enregistrez le certificat de client.
2. Indiquer le certificat de client au serveur

Vous devez mettre le certificat de client à la disposition du serveur afin de pouvoir établir une
liaison sécurisée.
Communication

1. Si le client a été configuré dans un autre projet et que vous y avez généré et exporté le
certificat client :
– Activez l'option "Utiliser les paramètres de sécurité globaux pour la gestion des
certificats" dans le gestionnaire de certificats local du serveur. Le gestionnaire de
certificats global est alors disponible.
Vous trouverez cette option dans les propriétés de la CPU utilisée comme serveur sous
– Si ce projet n'est pas encore protégé, cliquez sur le bouton "Protéger ce projet" sous
"Réglages Security > Paramètres" dans le navigateur de projet de STEP 7 et ouvrez une
session.
STEP 7 affiche alors l'entrée "Paramètres de sécurité généraux" sous "Réglages Security"
dans le navigateur de projet.
– Double-cliquez sur "Paramètres de sécurité généraux".
– Double-cliquez sur "Gestionnaire de certificats".
STEP 7 ouvre le gestionnaire de certificats global.
– Cliquez sur l'onglet "Certificats d'appareil".
– Cliquez avec le bouton droit de la souris sur une surface libre dans la page d'onglet (pas
sur un certificat).
– Sélectionnez le menu contextuel "Importer".
Le dialogue d'importation de certificats s'affiche.
– Sélectionnez le certificat du client auquel le serveur doit faire confiance.
– Cliquez sur le bouton "Ouvrir" pour importer le certificat.
Le certificat du client se trouve désormais dans le gestionnaire de certificats global.
Retenez l'ID du certificat de client que vous venez d'importer.
2. Cliquez ensuite sur l'onglet "Général" dans les propriétés de la CPU utilisée comme serveur.
3. Cliquez sur la zone "OPC UA > Serveur > Sécurité > Secure Channel".
4. Faire défiler vers le bas jusqu'à la zone "Clients dignes de confiance" dans la boîte de
dialogue "Secure Channel".
5. Dans le tableau, double-cliquez sur la ligne vide avec "<Ajouter nouveau>". Un bouton
comprenant trois points de suspension est affiché dans cette ligne.
6. Cliquez dessus.
7. Sélectionnez le certificat client préparé.
8. Cliquez sur le bouton avec la coche verte.
10.Chargez la configuration dans la CPU S7-1500 (serveur).
Communication
Résultat
Le serveur fait désormais confiance au client. Si, en plus, le certificat du serveur est considéré
comme digne de confiance, le serveur et le client peuvent établir une liaison sécurisée.
9.4.9.3 Authentification de l'utilisateur

Vous pouvez régler dans l'interface client du serveur OPC UA de la CPU S7-1500 comment un
utilisateur du client OPC UA doit s'authentifier lorsqu'il souhaite accéder au serveur. Vous
devez pour cela sélectionner l'interface client correspondante dans le navigateur de projet de
la CPU S7-1500 souhaitée sous "Communication OPC UA > Interfaces client" et le type
d'authentification utilisateur dans la fenêtre d'inspection sous "Propriétés > Configuration >
Sécurité".
Types d'authentification utilisateur

Vous disposez des possibilités suivantes pour l'authentification utilisateur :
• Invité
L'utilisateur ne doit pas prouver ses droits (accès anonyme). La CPU génère à cet effet une
session anonyme pour l'utilisateur et le serveur OPC UA ne vérifie pas les droits de
l'utilisateur client.
• Nom d'utilisateur et mot de passe
L'utilisateur doit prouver ses droits (pas d'accès anonyme). Le serveur OPC UA vérifie si le
client utilisateur possède l'autorisation nécessaire pour accéder au serveur. Le nom
d'utilisateur avec le mot de passe correct sert de preuve. Ces données saisies ne peuvent
pas être vérifiées par l'interface client. Toutes les valeurs sont donc acceptées comme
valides.
Remarque
STEP 7 enregistre le nom d'utilisateur et le mot de passe en clair dans le bloc de données
ou le bloc de données d'instance. Recommandation : utilisez l'authentification utilisateur
"Utilisateur (TIA Portal - paramètres de sécurité)".
• Utilisateur (TIA Portal - paramètres de sécurité)

Vous pouvez entrer un nom d'utilisateur pour l'authentification à partir de la liste des
utilisateurs entrés dans la projet. Vous trouverez les noms des utilisateurs entrés du projet
actuel dans le navigateur du projet, dans la gestion des utilisateurs sous "Paramètres de
sécurité > Utilisateurs et rôles". Vous pouvez également y entrer d'autres utilisateurs.
Vous pouvez également entrer un nom qui ne figure pas dans la gestion des utilisateurs
du projet ou bien laisser le champ vide. Ceci est alors nécessaire si le nom d'utilisateur
correspondant provient d'une autre source lors de l'exécution, par exemple via l'IHM ou
depuis un autre client OPC UA.
Communication
Stratégie de sécurité "Aucune Security" et authentification par nom d'utilisateur et mot de passe
Vous pouvez définir la combinaison suivante :
Stratégie de sécurité "Aucune Security" et authentification par nom d'utilisateur et mot de
passe.
• Le serveur OPC UA de la S7-1500 prend en charge cette combinaison. Les clients OPC UA
peuvent se connecter et crypter ou non les données d'identification.
• Le client OPC UA de la CPU S7-1500 prend également en charge cette combinaison :
pendant l'exécution, il ne se connecte cependant que s'il peut envoyer les données
d'authentification cryptées via la ligne !
Conséquence : aucune liaison ne peut être établie pendant l'exécution avec la configuration
suivante :
• S7-1500 comme client OPC UA
• Serveur OPC UA qui ne prend pas en charge le cryptage des données d'authentification en
cas de configuration de la stratégie de sécurité "Aucune Security" (= "none")
Voir aussi
Utilisateur et rôles avec les droits de fonction OPC UA (Page 1)
9.4.9.4 Utilisation d'une liaison paramétrée
Introduction
Ce chapitre vous montre comment utiliser une liaison paramétrée dans les instructions OPC
UA (troisième étape).
Conditions
• Vous avez créé une interface client et lui avez ajouté des variables API et des méthodes,
voir (Première étape (Page 1)).
• Vous avez paramétré une liaison à un serveur OPC UA (Deuxième étape (Page 1)).
Vue d'ensemble
Pour lire des données sur un serveur OPC UA ou y écrire des données, vous utilisez les
instructions suivantes :
• OPC_UA_Connect
• OPC_UA_NamespaceGetIndexList
• OPC_UA_NodeGetHandleList
• OPC_UA_ReadList ou OPC_UA_WriteList
• OPC_UA_NodeReleaseHandleList
• OPC_UA_Disconnect
Communication
Ordre des instructions OPC UA

La figure ci-dessous montre l'ordre dans lequel les instructions OPC UA sont appelées dans un
programme utilisateur pour lire ou écrire des variables API :
① Instructions pour préparer les opérations de lecture et d'écriture

② Instructions de lecture et d'écriture
③ Instructions pour "nettoyer" une fois les opérations de lecture ou d'écriture effectuées
L'instruction "OPC_UA_NodeReleaseHandleList" n'est pas nécessaire quand
"OPC_UA_Disconnect" est appelée aussitôt après.
Figure 9-75 Ordre d'appel pour les opérations de lecture et d'écriture
STEP 7 (TIA Portal) affecte automatiquement des valeurs aux paramètres de ces instructions
quand vous utilisez une interface client et une liaison paramétrée à un serveur OPC UA.
Vous pouvez lire ci-dessous comment procéder.
Communication
Utiliser une interface client et une liaison paramétrée

Procédez comme suit pour utiliser une liaison OPC UA paramétrée :
1. Ouvrez votre programme utilisateur dans TIA Portal.
2. Amenez l'instruction "UA_Connect" dans l'éditeur de programme par glisser-déposer.
Vous trouverez cette instruction sous "Instructions > Communication > OPC UA" dans TIA
Portal.
3. Choisissez une option d'appel pour l'instruction.
L'exemple utilise une multi-instance.
STEP 7 représente l'instruction dans l'éditeur de programme.
L'éditeur du langage de programmation Logigramme (LOG) utilise la représentation
suivante :
L'éditeur du langage de programmation Schéma à contacts (CONT) affiche l'instruction de

manière semblable.
4. Cliquez sur le symbole de boîte à outils dans les éditeurs pour LOG ou CONT.
Ce symbole se trouve dans l'en-tête de l'instruction :
Si vous utilisez l'éditeur pour LIST ou pour SCL : cliquez sur le petit rectangle vert sous le
premier caractère du nom d'instance :
L'exemple (Page 1) utilise "#OPC_UA_Connect_Instance" comme nom d'instance.

STEP 7 affiche alors les propriétés de l'instruction dans une boîte de dialogue séparée.
Communication
5. Sélectionnez sous "Interface client" celle que vous voulez utiliser pour l'instruction.
Dans notre exemple, nous sélectionnons l'interface client "ProductionLine".
STEP 7 interconnecte alors l'interface client "ProductionLine" avec les paramètres de
l'instruction OPC_UA_Connect :
"ProductionLine" est l'interface que le client OPC UA de l'exemple (Page 1) utilise pour
l'échange de données avec le serveur OPC UA "ProductionLine".
6. Amenez l'instruction "UA_NamespaceGetIndexList" dans l'éditeur de programme par
glisser-déposer.
Vous trouverez cette instruction sous "Instructions > Communication > OPC UA" dans TIA
Portal.
Choisissez l'option d'appel "Multi-instance".
Cliquez sur le symbole de boîte à outils (CONT et LOG) ou sur la case verte sous le nom
d'instance (LIST et SCL) si l'éditeur n'est pas déjà ouvert.
Sélectionnez l'interface client que vous voulez utiliser ("ProductionLine" dans l'exemple).
STEP 7 interconnecte alors automatiquement tous les paramètres de l'instruction
"OPC_UA_NamespaceGetIndexList" :
Communication
7. Amenez l'instruction "UA_NodeGetHandleList" dans l'éditeur de programme par glisser-

déposer.
Sélectionnez l'interface client que vous voulez utiliser. L'exemple utilise l'interface client
"ProductionLine".
Sous "Data access > Read/Writelist", sélectionnez la liste de lecture que vous voulez utiliser
(la liste "Product" dans l'exemple).
"OPC_UA_NodeGetHandleList" :
Communication
Si vous voulez écrire des données dans un serveur OPC UA, sélectionnez sous "Data access
> Read/Writelist" la liste d'écriture que vous voulez utiliser (la liste d'écriture
"ProductionStatus" dans notre exemple).
Communication
8. Amenez l'instruction "UA_ReadList" dans l'éditeur de programme par glisser-déposer.

Sélectionnez l'interface client que vous voulez utiliser. Notre exemple utilise l'interface
client "ProductionLine".
Sous "Data access > Readlist", sélectionnez la liste de lecture que vous voulez utiliser (la
liste "Product" dans l'exemple).
OPC_UA_ReadList.
Si vous voulez écrire des données dans un serveur OPC UA, utilisez l'instruction
"OPC_UA_Write" et sélectionnez sous "Data access > Writelist" la liste des variables que
vous voulez envoyer au serveur (la liste d'écriture "ProductionStatus" dans notre exemple).
9. Si vous vous servez dans votre programme utilisateur de listes de lecture ou d'écriture
différentes dont vous pilotez l'utilisation par programme, faites glisser l'instruction
"UA_NodeReleaseHandleList" dans l'éditeur de programme.
Sélectionnez l'interface client que vous voulez utiliser.
Sélectionnez à présent une liste de lecture ou d'écriture que vous voulez valider.
N'autorisez que les listes de lecture ou d'écriture que vous utilisez rarement car
l'enregistrement répété prend du temps.
Répétez ensuite la procédure à partir de l'étape 7 avec l'instruction
"UA_NodeGetHandleList".
10.Amenez l'instruction "UA_Disconnect" dans l'éditeur de programme par glisser-déposer.
Sélectionnez l'interface client que vous voulez utiliser. L'exemple utilise l'interface client
"ProductionLine".
"OPC_UA_Disconnect".
Communication
Instructions prises en charge

Pour les instructions suivantes, STEP 7 affecte automatiquement des valeurs aux paramètres
quand vous utilisez une interface client et une liaison paramétrée à un serveur OPC UA :
• OPC_UA_Connect
• OPC_UA_NamespaceGetIndexList
• OPC_UA_NodeGetHandleList
• OPC_UA_MethodGetHandleList
• OPC_UA_MethodReleaseHandleList
• OPC_UA_ReadList
• OPC_UA_WriteList
• OPC_UA_MethodCall
• OPC_UA_NodeReleaseHandleList
• OPC_UA_Disconnect
Communication
9.5 Conseils et recommandations
9.5.1 Règles relatives aux souscriptions

Les règles suivantes s'appliquent aux souscriptions :
• Groupez les souscriptions dans le client selon différents intervalles d'échantillonnage et
d'émission et répartissez les éléments surveillés (variables) sur ces groupes.
Exemple : Formez une souscription pour les intervalles d'émission supérieurs
(p. ex. 5 secondes) et une souscription pour les intervalles d'émission inférieurs (p. ex. 0,1
seconde).
• Désactivez les souscriptions non utilisées.
Motif : le mode souscription "Désactivé" réduit la consommation de ressources.
• Tenez compte du nombre maximal d'éléments surveillés (Monitored Items) par les
souscriptions pour la CPU S7-1500 correspondante.
Les valeurs sont indiquées dans les caractéristiques techniques de chaque CPU et se
rapportent à un intervalle d'échantillonnage/émission de 1 seconde.
Pour plus d'informations, voir la FAQ 109755846
(https://support.industry.siemens.com/cs/fr/fr/view/109755846).
• Choisissez les mêmes intervalles d'échantillonnage/émission pour le client OPC UA et pour
le serveur OPC UA.
• Évitez les tableaux (array) et les structures en tant qu'éléments de souscriptions, si le
processus les autorise.
Motif : si ne serait-ce qu'une seule valeur d'un tableau ou d'une structure est modifiée, la
structure complète est transférée, ce qui génère une charge de communication inutile.
• Le serveur OPC UA de la CPU S7-1500 acquitte le non respect occasionnel de la cadence
d'échantillonnage requise par un code d'erreur "GoodOverload" selon la spécification OPC
UA, voir aussi l'aide de TIA Portal. Différents clients OPC UA gèrent différemment les codes
d'erreur "Good" non nuls. Tenez compte de ces comportements et réduisez si nécessaire la
charge de communication conformément aux mesures exposées ci-dessus.
Voir aussi
Paramètres du serveur pour souscriptions (Page 1)
Communication
9.5.2 Règles pour le programme utilisateur
Programmes utilisateur pour OPC UA

Les règles suivantes s'appliquent aux programmes utilisateur :
• Si votre application le permet et que la charge due à la communication est élevée, il est
recommandé de régler un temps minimum pour les OB cycliques.
Avantages :
– Le temps de cycle reste pratiquement constant
– La CPU dispose de plus de temps pour les tâches de communication
Astuce : Pour l'analyse de la charge de la CPU (p. ex. communication), utilisez l'instruction
"Runtime_Info" ; mode 21 ou mode 25 (voir l'aide de TIA Portal).
• Réduisez le nombre de variables ou de blocs de données accessibles depuis OPC UA/HMI.
De manière standard, à la création de variables/DB/IDB, toutes les variables sont
accessibles depuis OPC UA/HMI Cette mesure améliore la performance lors du chargement
en RUN.
Astuce : À l'aide de l'affichage détaillé des objets dans TIA Portal, vous pouvez simplement
repérer les blocs de données non significatifs pour OPC UA comme "non accessibles depuis
OPC UA".
• Un transfert cohérent des données au-delà des limites des types de données simples n'est
possible qu'avec les méthodes OPC UA. Si vous utilisez d'autres fonctions OPC UA
(souscriptions, Read/Write), vous devez assurer la cohérence des données dans
l'application.
• Pour les accès répétés en lecture et en écriture aux mêmes variables, OPC UA propose le
service "RegisterNodes". Les serveurs peuvent préparer l'accès optimisé aux variables à
l'aide de ce service. L'instruction "OPC_UA_NodeGetHandleList" du S7-1500 en tant que
client OPC UA appelle ce service implicitement pour préparer le serveur à des accès
optimisés ("Registered Read/Write" dans la terminologie OPC UA).
Appeler l'affichage détaillé des objets dans TIA Portal

Pour appeler l'affichage détaillé des objets, procédez comme suit :
1. Dans la vue du portail, passez dans le portail "Programmation API".
2. Sélectionnez "Afficher tous les objets".
Communication
3. Activez l'onglet "Détails" dans la fenêtre de sélection.

4. Désactivez l'accessibilité de objets individuels depuis OPC UA dans la colonne "DB accessible
depuis OPC UA".
Figure 9-76 Appeler l'affichage détaillé des objets dans TIA Portal
9.5.3 Modèles de copie pour la communication OPC UA
Modèles de copie pour les interfaces OPC UA

Vous pouvez stocker les interfaces de serveurs et de clients OPC UA que vous souhaitez
réutiliser soit dans la bibliothèque du projet, soit dans une bibliothèque globale. Vous ne
pouvez utiliser les modèles de copie de la bibliothèque du projet que dans le projet. Si vous
créez le modèle de copie dans une bibliothèque globale, il peut être utilisé dans différents
projets.
Les CPU à fonctionnalité OPC UA distinguent trois types d'interface du serveur OPC UA :
• Interface serveur habituelle
• Interface Spécification Companion
• Référence à un espace de noms
Lors de l'ajout de l'interface OPC UA sous "Communication OPC UA" dans le navigateur de
projet, chaque type d'interface reçoit sa propre icône. Le modèle de copie reprend la même
icône.
Créez soit des modèles de copie individuels, soit un modèle de copie avec plusieurs
interfaces.
Communication
Créer plusieurs modèles de copie à partir de la sélection

Vous sélectionnez un ou plusieurs éléments et en générez des modèles de copie individuels.
1. Ouvrez la bibliothèque dans la Task Card "Bibliothèques".
2. Sélectionnez les éléments souhaités.
3. Faites glisser les éléments dans le dossier "Modèles de copie" ou dans n'importe quel sous-
dossier de "Modèles de copie".
Créer un modèle de copie à partir de la sélection

Vous sélectionnez plusieurs éléments et vous en générez un modèle de copie unique
contenant tous les éléments sélectionnés.
1. Copiez dans le presse-papiers les éléments dont vous voulez créer des modèles de copie.
2. Dans la bibliothèque, cliquez avec le bouton droit de la souris sur le dossier "Modèles de
copie" ou sur un sous-dossier quelconque.
3. Sélectionnez la commande "Insérer comme modèle de copie unique" dans le menu
contextuel.
Lorsque plusieurs interfaces du serveur OPC UA ou du client OPC UA sont ajoutées à un
modèle de copie, la légende et l'icône sont modifiées en conséquence dans la bibliothèque.
Un "+" est ajouté à l'icône habituelle :
Figure 9-77 Créer un modèle de copie dans STEP 7
Voir aussi
Créer une interface serveur personnalisée (Page 1)
Communication
Attribution d'adresses via DHCP 10
Afin de permettre une automatisation pérenne, performante et flexible, de plus en plus de
composants du secteur manufacturier prennent en charge les normes informatiques. Des
normes Ethernet globales, une communication transparente ainsi qu'un caractère polyvalent
font de l'automatisation assistée par informatique une solution économique adaptée à vos
exigences. Les extensions fonctionnelles des capacités de communication des CPU S7-1500
en ce sens vous donnent plus de liberté pour les mises en œuvre possibles de votre
installation ou de votre machine. La technologie informatique permet une automatisation
efficace. Avec l'introduction de DHCP et de l'extension de DNS pour les CPU S7-1500 à partir
de la version de firmware V2.9, vous gagnez en souplesse pour la conception de votre
solution d'automatisation.
Communication
Attribution d'adresses via DHCP
Vous pouvez configurer les interfaces d'une CPU S7-1500 de façon que les paramètres
d'adresse, comme par exemple l'adresse IP avec le masque de sous-réseau, soient obtenus
d'un serveur DHCPv4 (désigné par serveur DHCP ci-après).
Figure 10-1 Vue d'ensemble de DHCP
Domaines d'application
• Mise en œuvre de la CPU S7-1500 dans un environnement informatique managé
• Ajout de nouveaux appareils dans une structure de production modulaire
Communication
10.1 Principe de l'attribution d'adresses via DHCP
Conditions requises pour la configuration

Les conditions suivantes doivent être remplies pour qu'une interface PROFINET de la CPU
S7-1500 puisse recevoir ses paramètres d'adresse IP d'un serveur DHCP :
• L'attribution d'adresses par un serveur DHCP est configurée.
Activer DHCP (Page 1)
• Aucune communication PROFINET IO ne doit être configurée pour l'interface.
Principe de l'attribution d'adresses par DHCP

Le processus d'attribution d'adresses par DHCP commence dès que le projet est chargé dans la
CPU ou que la CPU avec attribution d'adresses par DHCP configurée est mise sous tension et
démarrée :
DHCP-Discover Le client DHCP recherche un serveur DHCP approprié par diffusion générale. Le client
DHCP s'identifie auprès du serveur DHCP au moyen de l'ID client configurée ou de
son adresse MAC.
DHCP-Offer Le serveur DHCP fournit au client DHCP des paramètres d'adresse IP (adresse IPv4,
masque de sous-réseau, routeur par défaut en option), ainsi qu'éventuellement
d'autres données (options).
DHCP-Request Le client DHCP réclame les paramètres d'adresse IP et les options proposées dans
l'offre DHCP.
Le client DHCP de la CPU S7-1500 accepte toujours la première offre DHCP d'un ser-
veur DHCP qui satisfait aux exigences (adresse IP avec masque de sous-réseau).
DHCP-Acknowle Le serveur DHCP confirme et transmet les paramètres d'adresse IP et les options pro-
dgement posées dans l'offre DHCP.
Le serveur DHCP informe également le client DHCP de la durée pendant laquelle il
pourra utiliser les paramètres d'adresse ("lease time" ou "durée du bail").
Figure 10-2 Principe de l'attribution d'adresses via DHCP
Les paramètres d'adresse IP et les options ne sont pas stockés dans la mémoire de
chargement de la CPU. Après un effacement général ou un redémarrage de la CPU, les
paramètres d'adresse IP et les options sont à nouveau obtenus via DHCP.
Communication
Options lors de l'attribution d'adresses par DHCP

Pour la CPU S7-1500, vous pouvez configurer que les options suivantes doivent être fournies
par un serveur DHCP :
• Adresses de jusqu'à quatre serveurs DNS
Recevoir les adresses des serveurs DNS par DHCP (Page 1)
• Adresses de jusqu'à quatre serveurs NTP
Recevoir les adresses des serveurs NTP par DHCP (Page 1)
• Nom d'hôte et domaine
Recevoir le nom d'hôte et le domaine par DHCP (Page 1)
Si nécessaire, le serveur DHCP fournit également l'adresse d'un routeur (passerelle par défaut)
comme option.
Pendant combien de temps la CPU S7-1500 peut-elle utiliser les paramètres d'adresse DHCP ?
Outre les paramètres d'adresse, le serveur DHCP indique la durée du bail ("lease time") à la
CPU S7-1500 (client DHCP). La durée du bail détermine pendant combien de temps la CPU
peut utiliser les paramètres d'adresse.
La CPU retourne les paramètres d'adresse affectés lorsque la durée du bail a complètement
expiré. La CPU dispose d'une surveillance de temps interne pour la durée du bail.
La CPU a la possibilité de proroger le bail à des moments précis de l'écoulement de la durée
du bail :
• Renouvellement ("renewal") : la moitié de la durée du bail s'est écoulée : La CPU contacte
le serveur DHCP initial et demande une prolongation de la durée de bail. Le serveur DHCP
initial peut soit confirmer la durée de bail existante, soit attribuer une nouvelle durée de
bail. La surveillance de temps dans la CPU est réinitialisée en cas de nouvelle durée de bail.
• Réassociation ("rebinding") : 7/8 de la durée du bail se sont écoulés : La CPU contacte tous
les serveurs DHCP disponibles en diffusion générale et demande une prolongation de la
durée de bail. Un serveur DHCP peut soit confirmer la durée de bail existante, soit attribuer
une nouvelle durée de bail. La surveillance de temps dans la CPU est réinitialisée en cas de
nouvelle durée de bail.
En cas de réponse négative du serveur DHCP lors de la réassociation ou en l'absence de
réponse des serveurs DHCP, la CPU renvoie les paramètres d'adresse après 8/8 de la durée
du bail.
Si la CPU a renvoyé les paramètres d'adresse à l'expiration de la durée du bail, elle lance un
nouveau cycle d'attribution d'adresses par DHCP avec une nouvelle recherche DHCP-Discover.
Voir aussi
Configurer l'ID client (Page 1)
Communication
10.2 DHCP avec DNS
10.2 DHCP avec DNS

À partir de STEP 7 V17, la CPU S7-1500 prend en charge les paramètres d'adresse Nom d'hôte
et Domaine utilisés dans la communication DNS basée sur les noms.
L'adressage basé sur le nom complet constitué du nom d'hôte et du domaine est intéressant
pour certains services de communication :
• La CPU est adressable sous son nom complet, par exemple pour OPC UA, Open User
Communication. En cas d'attribution dynamique de l'adresse IP par le serveur DHCP, un
adressage univoque est toujours possible par le nom DNS.
• Le nom complet peut être contenu dans des certificats de la CPU S7-1500, par exemple
pour la communication OPC UA, le serveur Web, la communication sécurisée.
– Ce n'est que lorsque vous configurez le nom d'hôte et le domaine pour la CPU S7-1500
dans STEP 7 que le nom complet est inscrit comme autre nom de sujet ("subject
alternate name", SAN) dans les certificats d'appareil dans le projet.
– Lorsque vous recevez le nom d'hôte et/ou le domaine de DHCP ou que vous les
définissez par le programme utilisateur, le nom complet n'est pas stocké dans les
certificats d'appareil dans le projet.
Communication
10.2 DHCP avec DNS
La manière dont vous paramétrez la configuration DNS pour votre CPU dépend de la manière
dont vous attribuez le nom d'hôte et le domaine dans votre réseau.
• Attribution centralisée du nom d'hôte et du domaine
Vous attribuez le nom d'hôte et le domaine de manière centralisée dans votre réseau, par
exemple par le biais d'un serveur DNS configuré. Vous configurez dans STEP 7 que la CPU
reçoit le nom d'hôte et le domaine par DHCP.
Dans la configuration suivante, seule l'ID client est configurée dans la CPU S7-1500. Lors
de l'attribution d'adresse par DHCP, le serveur DHCP fournit les options Nom d'hôte et
Domaine à la CPU.
Figure 10-3 Recevoir le nom d'hôte et le domaine par DHCP
Pour cette configuration, vous devez d'abord activer la configuration de nom d'hôte et de
domaine dans STEP 7. Vous spécifiez ensuite que le nom d'hôte et le domaine sont reçus
par DHCP.
Recevoir le nom d'hôte et le domaine par DHCP (Page 1)
• Attribution locale du nom d'hôte et du domaine
Vous pouvez configurer le nom d'hôte et le domaine dans STEP 7 ou les définir dans le
Remarque
Validité des données reçues de DHCP
Lorsque vous modifiez le nom d'hôte et/ou le domaine dans le programme utilisateur,
toutes les données reçues de DHCP (suite IP, nom d'hôte, domaine, serveur NTP, serveur
DNS) deviennent invalides et doivent à nouveau être obtenues auprès du serveur DHCP.
C'est pourquoi vous ne devez modifier le nom d'hôte et/ou le domaine qu'en cas d'urgence
et pas en cours de fonctionnement.
Toutes les connexions peuvent être interrompues si l'adresse IP de l'interface change.
Communication
10.2 DHCP avec DNS
Dans la configuration suivante, le nom d'hôte et le domaine de la CPU sont configurés

dans la CPU S7-1500 en plus de son ID client. Lors de l'attribution d'adresse par DHCP, la
CPU transmet au serveur DHCP le nom d'hôte et le domaine en plus de l'ID client. Le
serveur DHCP reçoit ces informations pour actualiser un serveur DNS avec les données
d'adresse de la CPU, par exemple.
Figure 10-4 Configurer le nom d'hôte et le domaine
domaine dans STEP 7. Vous configurez ensuite le nom d'hôte et le domaine dans STEP 7.
• Attribution centralisée du domaine et attribution locale du nom d'hôte
– Vous configurez dans STEP 7 que la CPU reçoit le domaine par DHCP.
– Vous pouvez configurer le nom d'hôte dans STEP 7 ou le définir dans le programme
utilisateur.
Communication
10.2 DHCP avec DNS
Dans la configuration suivante, le nom d'hôte est configuré en plus de l'ID client dans la
CPU S7-1500. Lors de l'attribution d'adresse par DHCP, la CPU transmet au serveur DHCP le
nom d'hôte en plus de l'ID client. Le serveur DHCP fournit l'option Domaine à la CPU.
Figure 10-5 Configurer le nom d'hôte, recevoir le domaine par DHCP
domaine dans STEP 7. Vous configurez ensuite le nom d'hôte dans STEP 7 et spécifiez que
le domaine est reçu via DHCP.
Condition
• Vous avez activé l'attribution d'adresses par DHCP pour au moins une interface de la CPU
S7-1500.
Activer la configuration du nom d'hôte et du domaine

Procédez comme suit pour activer la configuration du nom d'hôte et du domaine dans
STEP 7 :
1. Sélectionnez la CPU S7-1500 dans STEP 7.
2. Naviguez jusqu'à "Configuration avancée" > "Nom d'hôte et nom de domaine" >
"Configuration du nom d'hôte et du domaine" dans les propriétés de la CPU.
3. Cochez la case "Activer le nom d'hôte et le domaine".
Configurer le nom d'hôte dans STEP 7

Procédez comme suit pour configurer le nom d'hôte dans STEP 7 :
"Configuration du nom d'hôte et du domaine" > "Nom d'hôte" dans les propriétés de la CPU.
3. Sélectionnez "Configurer le nom d'hôte dans le projet" dans la liste déroulante pour
"Configuration du nom d'hôte".
4. Indiquez le nom d'hôte pour "Nom d'hôte".
– Saisissez le nom d'hôte souhaité.
– Si vous cochez la case "Nom d'hôte identique au nom d'appareil", STEP 7 attribue
automatiquement le nom d'appareil comme nom d'hôte.
Ce n'est que lorsque vous avez configuré le nom d'hôte et le domaine dans STEP 7 que le nom
complet s'affiche en regard de "Nom complet".
Communication
10.2 DHCP avec DNS
Attribuer le nom d'hôte dans le programme utilisateur

Procédez comme suit pour attribuer le nom d'hôte dans le programme utilisateur :
3. Sélectionnez "Configurer le nom d'hôte directement sur l'appareil (par exemple, programme
API, écran)" dans la liste déroulante pour "Configuration du nom d'hôte".
4. Appelez l'instruction "CommConfig" dans le programme utilisateur. Le paramètre DATA doit
désigner un UDT "Conf_Hostname" dans lequel le nom d'hôte est défini.
Vous trouverez plus d'informations sur l'instruction "CommConfig" et sur l'UDT
"Conf-Hostname" dans l'aide en ligne de STEP 7.
Configurer le domaine dans STEP 7

Procédez comme suit pour configurer le domaine dans STEP 7 :
"Configuration du nom d'hôte et du domaine" > "Domaine" dans les propriétés de la CPU.
3. Sélectionnez "Configurer le domaine dans le projet" dans la liste déroulante pour
"Configuration du domaine".
4. Saisissez le domaine souhaité pour "Domaine".
Ce n'est que lorsque vous avez configuré le nom d'hôte et le domaine dans STEP 7 que le nom
complet s'affiche en regard de "Nom complet".
Attribuer le domaine dans le programme utilisateur

Procédez comme suit pour attribuer le domaine dans le programme utilisateur :
3. Sélectionnez "Configurer le domaine directement sur l'appareil (par exemple, programme
API, écran)" dans la liste déroulante pour "Configuration du nom d'hôte".
4. Appelez l'instruction "CommConfig" dans le programme utilisateur. Le paramètre DATA doit
désigner un UDT "Conf_Domainname" dans lequel le nom de domaine est défini.
Vous trouverez plus d'informations sur l'instruction "CommConfig" et sur l'UDT
"Conf_Domainname" dans l'aide en ligne de STEP 7.
Communication
10.3 Activer DHCP
Règles de longueurs maximales pour le nom d'hôte, le domaine et l'ID client

Tenez compte des longueurs maximales suivantes en octets, un octet correspondant à un
caractère :
• Nom d'hôte : 63 octets au maximum
• Domaine : 252 octets au maximum
• ID client : 254 octets au maximum
• Nom d'hôte + domaine : 254 octets au maximum
• Nom d'hôte + domaine + ID client : 260 octets au maximum
Ne s'applique que si le nom d'hôte et le domaine doivent être envoyés au serveur DHCP.
10.3 Activer DHCP
Conditions
Marche à suivre
Procédez comme suit pour activer DHCP pour l'interface PROFINET d'une CPU S7-1500 :
1. Sélectionnez l'interface PROFINET de la CPU S7-1500 dans STEP 7.
2. Naviguez jusqu'à "Adresses Ethernet" > "Protocole Internet version 4 (IPv4)" dans les
propriétés de l'interface.
3. Sélectionnez l'option "Adresse IP du serveur DHCP".
Résultat
Vous avez spécifié que l'interface doit recevoir son adresse IP par serveur DHCP.
"Utiliser l'adresse MAC comme ID de client" est configuré comme mode DHCP pour la CPU S7-
1500. Configurer l'ID client (Page 1) décrit comment modifier l'ID client.
Communication
10.4 Configurer l'ID client
10.4 Configurer l'ID client
ID client
La CPU S7-1500 s'identifie toujours au moyen de son ID client auprès d'un serveur DHCP
(option DHCP 61). L'ID client est spécifique à l'interface.
La CPU S7-1500 prend en charge les deux modes suivants en ce qui concerne l'ID client :
• Utiliser l'adresse MAC comme ID de client : l'adresse MAC de la CPU est utilisée comme ID
client pour le client DHCP. Tenez compte du fait que l'adresse MAC et donc l'ID client
changent si vous effectuez un remplacement de CPU dans ce mode de fonctionnement.
• ID de client personnalisée : pour cette option, vous définissez l'ID client dans la
configuration dans STEP 7. Vous pouvez en outre modifier l'ID client à l'exécution, par
exemple avec l'instruction "CommConfig" dans le programme utilisateur.
Si vous effectuez un remplacement de CPU dans ce mode de fonctionnement, la nouvelle
CPU reçoit l'ID client configurée.
Condition
• Vous avez activé l'attribution d'adresses par DHCP pour l'interface.
Configurer l'ID client

Procédez comme suit pour configurer l'ID client dans STEP 7 :
1. Sélectionnez l'interface PROFINET de la CPU S7-1500 dans STEP 7.
2. Naviguez jusqu'à "Adresses Ethernet" > "Protocole Internet version 4 (IPv4)" > "Adresse IP du
serveur DHCP" dans les propriétés de l'interface.
3. Sélectionnez le mode souhaité dans la liste déroulante pour "Mode de fonctionnement" :
– Utiliser l'adresse MAC comme ID de client (mode par défaut)
– ID de client personnalisée
Si vous avez sélectionné l'option "Utiliser l'adresse MAC comme ID de client", la
configuration s'achève ici. Pour l'option "ID de client personnalisée", poursuivez à l'étape 4.
4. Saisissez une ID client valide pour "ID client".
– Une chaîne avec des caractères ASCII de 7 bits dans la plage de 0x21 à 0x7e est
autorisée.
– Certains serveurs DHCP exigent que l'ID soit précédée d'un "0" (certains appareils
SCALANCE, par exemple). Saisissez dans ce cas "\0", suivi de votre ID client.
– Vous pouvez également laisser le champ vide. Dans ce cas, vous devez cocher la case
"L'ID de client peut être modifiée en cours de fonctionnement".
5. Pour que l'ID client personnalisée soit modifiable pendant le fonctionnement, cochez la case
"L'ID de client peut être modifiée pendant le fonctionnement".
Communication
10.5 Recevoir les adresses des serveurs DNS par DHCP
Modifier l'ID client pendant le fonctionnement

L'instruction "CommConfig" permet de modifier l'ID client avec le programme utilisateur.
Appelez l'instruction. Le paramètre DATA doit désigner un UDT "Conf_ClientId" ou un UDT
"Conf_ClientId_Opaque". L'ID client doit être définie dans l'UDT.
Si vous n'avez pas indiqué l'ID client personnalisée dans la configuration dans STEP 7, la CPU
utilise l'adresse MAC comme ID client jusqu'à la première modification de l'ID client.
Remarque
Validité des données reçues par DHCP
Lorsque vous modifiez l'ID client avec "CommConfig", toutes les données reçues de DHCP
deviennent invalides : suite IP, nom de domaine, serveur NTP, serveur DNS. C'est pourquoi
vous ne devez modifier l'ID client qu'en cas d'urgence et pas en cours de fonctionnement.
Vous trouverez plus d'informations sur l'instruction "CommConfig" et sur les UDT
"Conf_ClientId" et "Conf_ClientId_Opaque" dans l'aide en ligne de STEP 7.
10.5 Recevoir les adresses des serveurs DNS par DHCP
Conditions
S7-1500.
Recevoir les adresses des serveurs DNS par DHCP

Procédez comme suit pour recevoir les adresses de 4 serveurs DNS au maximum par DHCP :
2. Naviguez jusqu'à "Configuration avancée" > "Configuration DNS" > "Liste de serveurs" dans
les propriétés de la CPU.
3. Sélectionnez "Paramétrer les serveurs DNS à distance (par ex. DHCP)" dans la liste déroulante
pour "Résolution de nom via DNS".
Résultat : Si le serveur DHCP fournit des adresses de serveurs DNS comme option, la CPU
utilise jusqu'à 4 adresses.
Communication
10.6 Recevoir les adresses des serveurs NTP par DHCP
10.6 Recevoir les adresses des serveurs NTP par DHCP
Conditions
S7-1500.
Recevoir les adresses des serveurs NTP par DHCP

Procédez comme suit pour recevoir les adresses de quatre serveurs NTP au maximum par
DHCP :
2. Naviguez jusqu'à "Heure" > "Synchronisation de l'heure" > "Mode NTP" dans les propriétés de
la CPU.
3. Sélectionnez "Paramétrer les serveurs NTP à distance (par ex. DHCP)" dans la liste déroulante
pour "Synchronisation de l'heure".
Résultat : Si le serveur DHCP fournit des adresses de serveurs NTP comme option, la CPU
utilise jusqu'à 4 adresses.
10.7 Recevoir le nom d'hôte et le domaine par DHCP
Condition
S7-1500.
• Vous avez activé la configuration du nom d'hôte et du domaine dans STEP 7.
Recevoir le nom d'hôte par DHCP

Procédez comme suit pour recevoir le nom d'hôte par DHCP :
3. Sélectionnez "Configurer le nom d'hôte à distance (par exemple, DHCP)" dans la liste
déroulante pour "Configuration du nom d'hôte".
Résultat : Si le serveur DHCP fournit un nom d'hôte comme option, la CPU utilise ce nom
d'hôte.
Communication
10.7 Recevoir le nom d'hôte et le domaine par DHCP
Recevoir le domaine par DHCP

Procédez comme suit pour recevoir le domaine par DHCP :
3. Sélectionnez "Configurer le domaine à distance (par exemple, DHCP)" dans la liste
déroulante pour "Configuration du domaine".
Résultat : Si le serveur DHCP fournit un domaine comme option, la CPU utilise ce domaine.
Communication
Routage 11
11.1 Vue d'ensemble des mécanismes de routage des CPU S7-1500
Le tableau suivant offre une vue d'ensemble sur les mécanismes de routage de la
CPU S7-1500.
Mécanisme de routage Description Applications Chapitre

Routage S7 Le routage S7 est la transmis- Charger des programmes utili- Routage S7 (Page 1)
sion de données au-delà des sateur
limites de sous-réseau S7. Vous Chargement de la configura-
pouvez envoyer des information matérielle
tions d'un émetteur à un récep-
teur en passant par différents Exécuter des fonctions de test
sous-réseaux S7. et de diagnostic
IP Forwarding La fonction IP Forwarding ou Accès aisé depuis le niveau IP Forwarding (Page 1)

transfert IP permet à des appa- conduite jusqu'au niveau ter-
reils de transmettre des pa- rain pour la configuration et le
quets IP entre 2 sous-réseaux IPparamétrage d'appareils, p. ex.
connectés. via PDM ou navigateur Web.
Intégration aisée des appareils
pour l'accès à distance, p. ex.
pour le diagnostic pour la télé-
maintenance ou la mise à jour
du firmware.
Routage d'enregistrement Des données peuvent être Le routage d'enregistrement Routage d'enregistre-
envoyées d'une station d'ingé- est par exemple utilisé en cas ment (Page 1)
nierie PROFINET à des appareils d'utilisation d'appareils de
de terrain en traversant diffé- terrain de fabricants divers. Les
rents réseaux. Comme la sta- appareils de terrain sont adres-
tion d'ingénierie s'adresse aux sés pour le paramétrage et le
appareils de terrain avec des diagnostic via des enregistre-
enregistrements normalisés et ments normalisés (PROFINET).
que ces enregistrements font
l'objet d'un routage par des
appareils S7, le terme de "rou-
tage d'enregistrement" s'est
établi pour ce type de routage.
Communication
Routage
11.2 Routage S7
11.2 Routage S7
Définition du routage S7
Le routage S7 est la transmission de données au-delà des limites de sous-réseau S7. Vous
pouvez envoyer des informations d'un émetteur à un récepteur en passant par différents
sous-réseaux S7. Le passage d'un sous-réseau S7 à un ou plusieurs autres sous-réseaux est
réalisé dans le routeur S7. Le routeur S7 est un appareil disposant des interfaces vers les sous-
réseaux S7 concernés. Le routage S7 est possible via différents sous-réseaux S7
(PROFINET/Industrial Ethernet et/ou PROFIBUS).
Conditions requises pour le routage S7

• Tous les appareils accessibles dans un réseau ont été configurés et chargés au sein d'un
projet dans STEP 7.
• Tous les appareils impliqués dans le routage S7 doivent obtenir des informations
indiquant quels sous-réseaux S7 sont accessibles par quels routeurs S7 (= information de
routage). Les appareils obtiennent l'information de routage par le chargement de la
configuration matérielle dans les CPU, car les CPU jouent le rôle d'un routeur S7.
Dans une topologie avec plusieurs sous-réseaux S7 consécutifs, vous devez respecter
l'ordre suivant lors du chargement : chargez d'abord la configuration matérielle dans la/les
CPU qui sont directement reliées au même sous-réseau S7 que le PG/PC ; chargez ensuite
successivement les CPU des sous-réseaux S7 suivants en commençant par le sous-réseau
S7 le plus proche et en poursuivant jusqu'au sous-réseau S7 le plus éloigné.
• Le PG/PC avec lequel vous souhaitez établir une liaison via un routeur S7 doit être affecté
au sous-réseau S7 auquel il est réellement raccordé physiquement. Vous pouvez procéder
à l'affectation du PG/PC dans STEP 7 sous En ligne & diagnostic > Accès en ligne > Liaison
avec interface/sous-réseau.
• Pour les sous-réseaux S7 du type PROFIBUS : La CPU doit être configurée comme maître DP
ou alors, si elle est configurée comme esclave DP, la case d'option "Test, mise en service et
routage" doit être activée dans les propriétés de l'interface DP de l'esclave DP.
• Le routage S7 est possible pour les liaisons IHM à partir de STEP 7 V13 SP1.
Remarque
Pare-feu et routage S7
Avec le routage S7, un pare-feu ne détecte pas l'adresse IP de l'émetteur si l'émetteur se
trouve en dehors du sous-réseau S7 voisin.
Vue d'ensemble des appareils prenant en charge la fonction "Routage S7, voir cette FAQ
Communication
Routage
11.2 Routage S7
Routage S7 pour liaisons en ligne

Vous pouvez atteindre, à l'aide du PG/PC, des appareils via plusieurs sous-réseaux S7, pour par
exemple :
• charger des programmes utilisateur,
• charger une configuration matérielle ou
• effectuer des fonctions de test et de diagnostic.
Dans la figure suivante, la CPU 1 sert de routeur S7 entre le sous-réseau S7 1 et le sous-
réseau S7 2.
Figure 11-1 Routage S7 : PROFINET - PROFINET
Communication
Routage
11.2 Routage S7
La figure suivante représente l'accès depuis un PG à PROFIBUS via PROFINET. La CPU 1 assume
le rôle de routeur S7 entre le sous-réseau S7 1 et le sous-réseau S7 2 ; la CPU 2 assume le rôle
de routeur S7 entre le sous-réseau S7 2 et le sous-réseau S7 3.
Figure 11-2 Routage S7 : PROFINET - PROFIBUS
Routage S7 pour liaisons IHM

Vous avez la possibilité d'établir une liaison S7 d'un IHM vers une CPU via différents sous-
réseaux (PROFIBUS et PROFINET ou Industrial Ethernet). Dans la figure suivante, la CPU 1 sert
de routeur S7 entre le sous-réseau S7 1 et le sous-réseau S7 2.
Figure 11-3 Routage S7 via une liaison IHM
Communication
Routage
11.2 Routage S7
Routage S7 pour communication CPU-CPU

Vous avez la possibilité d'établir une liaison S7 d'une CPU vers une autre via différents
sous-réseaux (PROFIBUS et PROFINET ou Industrial Ethernet). La procédure est décrite dans
des exemples au chapitre Communication S7 (Page 1).
Figure 11-4 Routage S7 via communication CPU-CPU
Utilisation du routage S7
Pour la CPU, sélectionnez dans la boîte de dialogue "Liaison en ligne" de STEP 7 l'interface
PG/PC et le sous-réseau S7. Le routage S7 est automatiquement exécuté.
Nombre de liaisons pour le routage S7

Le nombre de liaisons disponibles pour le routage S7 dans les routeurs S7 (CPU, CM ou CP)
est indiqué dans les caractéristiques techniques des manuels des CPU/CM/CP respectifs.
Communication
Routage
11.2 Routage S7
Routage S7 : Exemple d'application

La figure suivante montre à titre d'exemple d'application la télémaintenance d'une
installation par un PG. La liaison est établie vie une connexion modem à travers deux sous-
réseaux S7.
Vous pouvez configurer une liaison distante par TeleService dans STEP 7, via "Accès en ligne"
ou "Liaison en ligne".
Figure 11-5 Télémaintenance d'une installation par TeleService
• L'affectation de ressources de liaison pour le routage S7 est décrite au chapitre Affectation
de ressources de liaison (Page 1).
• Vous trouverez des informations détaillées pour la configuration de TeleService dans l'aide
en ligne de STEP 7.
• Vous trouverez des informations complémentaires sur le routage S7 et les adaptateurs
TeleService sur Internet, sous les liens suivants :
– Manuel Industrie Software Engineering Tools TS Adapter IE Basic
(http://support.automation.siemens.com/WW/view/fr/51311100)
– Téléchargements pour TS Adapter
(http://support.automation.siemens.com/WW/view/fr/10805406/133100)
Voir aussi
Communication IHM (Page 1)
Communication
Routage
11.3 IP Forwarding
11.3 IP Forwarding
Transmission de paquets IP avec IP Forwarding

La fonction IP Forwarding ou transfert IP permet à des appareils de transmettre des paquets IP
entre deux sous-réseaux IP raccordés.
Vous activez et désactivez la fonction IP Forwarding dans STEP 7. Lorsque le transfert IP est
activé, la CPU S7-1500 transmet les paquets IP qu'elle reçoit mais qui ne lui sont pas adressés
à des sous-réseaux IP raccordés localement ou à un routeur configuré.
La figure suivante montre comment une PG accède aux données d'un appareil IHM. La PG et
l'appareil IHM se trouvent dans des sous-réseaux IP différents. Les sous-réseaux IP sont
connectés aux deux interfaces X1 et X2 de la CPU.
Figure 11-6 Accès d'une PG à un IHM par la fonction IP Forwarding
Domaines d’application
• Accès aisé du niveau de conduite au niveau terrain pour la configuration et le paramétrage
d'appareils de terrain, par exemple par PDM ou navigateur Web
• Intégration aisée d'appareils pour des accès à distance, par exemple pour le diagnostic en
cas de télémaintenance ou pour la mise à jour du firmware
Communication
Routage
11.3 IP Forwarding
Conditions d'utilisation de IP Forwarding

• Nombre d'interfaces Ethernet :
– La CPU possède au moins deux interfaces Ethernet.
– Ou bien la CPU possède une interface Ethernet et un CP 1543-1 à partir de la version de
firmware V2.2 fournit l'autre interface Ethernet. Dans ce cas, la fonction "Accès à l'API
via module de communication" doit être activée pour le CP dans la CPU.
• IP Forwarding est activé.
• Des passerelles par défaut et itinéraires adaptés sont paramétrés dans chaque appareil
abonné le long du chemin aller-retour des paquets IP.
Table de routage IP
Lorsque la fonction IP Forwarding est activée, la CPU fait suivre les paquets IP qu'elle reçoit et
qui ne lui sont pas adressés. La manière dont la CPU transmet les paquets IP est définie dans
sa table de routage IP interne.
La CPU crée la table de routage IP automatiquement à partir des informations suivantes de la
configuration matérielle chargée :
• Configuration IP des interfaces Ethernet
• Routeur configuré
Exemple de configuration avec IP Forwarding

La figure suivante montre un exemple de configuration avec les paramétrages d'adresse IP et
de routeur requis.
• Un PC sur le sous-réseau IP 192.168.4.0 communique avec un appareil IHM sur le sous-
réseau IP 192.168.2.0.
• L'adresse IP d'un routeur (passerelle par défaut) est configurée sur l'interface Ethernet X3
de la CPU. Il s'agit dans la figure ci-dessous de l'appareil désigné par "Routeur IP".
Dans STEP 7, vous configurez un routeur dans les propriétés de l'interface sous "Adresses
Ethernet" > "Protocole IP".
Figure 11-7 Configurer le routeur
Communication
Routage
11.3 IP Forwarding
• Les adresses IP d'une passerelle par défaut ou les itinéraires correspondants sont entrés de
même pour le PC, le routeur IP, le périphérique IO et l'appareil IHM.
Figure 11-8 Exemple de configuration
Communication
Routage
11.3 IP Forwarding
Avec cet exemple de configuration, on obtient la table de routage IP suivante pour la CPU.
Tableau 11- 1 Table de routage IP de la CPU
Réseau destinataire Interface Passerelle

0.0.0.0/0 10.10.0.10 10.10.0.1
192.168.1.0/24 192.168.1.1 -
192.168.2.0/24 192.168.2.1 -
10.10.0.0/24 10.10.0.10 -
Pour qu'une communication IP entre la PG/le PC et l'appareil IHM soit possible, vous devez
configurer des itinéraires IP supplémentaires vers le sous-réseau IP de l'appareil IHM et dans la
PG et dans le routeur IP. Dans l'appareil IHM, configurez l'adresse IP de l'interface CPU X1
comme passerelle par défaut.
Dans un ordinateur Windows, vous configurez par exemple un itinéraire IP supplémentaire
dans l'invite de commandes au moyen de la commande "route add <sous-réseau IP
destinataire> mask <masque de sous-réseau> <passerelle>". Vous devez toutefois disposer
des droits d'accès appropriés. Pour cet exemple, vous saisirez ainsi la commande suivante
dans l'invite :
• "route add 192.168.2.0 mask 255.255.255.0 192.168.4.20"
Dans un routeur IP, vous configurez des itinéraires supplémentaires par le biais d'une
interface Web, par exemple. Vous configurerez l'itinéraire suivant pour cet exemple :
• Sous-réseau IP de destination : 192.168.2.0
• Masque de sous-réseau : 255.255.255.0
• Passerelle : 10.10.0.10
Communication
Routage
11.3 IP Forwarding
Restrictions
Vous ne pouvez pas configurer des itinéraires IP en plus du routeur (passerelle par défaut)
pour une CPU S7-1500. Le réseau destinataire est un sous-réseau IP raccordé ou bien il est
accessible par exactement un routeur configurable. Comme la CPU S7-1500 ne prend pas en
charge des itinéraires IP supplémentaires, vous ne pouvez pas réaliser des cascades de
routeurs IP bidirectionnelles.
Dans la configuration suivante, vous pouvez configurer soit "Routeur 1", soit "Routeur 2" dans
la CPU. "Routeur 1" est configuré dans l'exemple. Vous ne pouvez donc pas configurer
"Routeur 2". Une communication IP entre le PC et l'appareil IHM n'est pas possible, car le trajet
ne peut pas s'effectuer dans les deux sens.
Figure 11-9 Cascade de routeurs IP non prise en charge
Communication
Routage
11.3 IP Forwarding
IP Forwarding par l'interface d'un CP

La fonction IP Forwarding fonctionne également par le biais de l'interface d'un CP. Vous devez
à cet effet activer la fonction "Accès à l'API via module de communication" pour ce CP dans la
CPU.
L'aide en ligne de STEP 7 décrit comment activer la fonction "Accès à l'API via module de
communication".
Accéder au C/C++ Runtime de la CPU-1518-4 PN/DP MFP via les interfaces X1 ou X2

Si vous activez IP-Forwarding pour la CPU 1518-4 PN/DP MFP, vous accédez via les interfaces
X1 et X2 non seulement aux appareils dans le sous-réseau de l'interface X3, mais aussi au
C/C++ Runtime. Depuis le C/C++ Runtime de la CPU 1518-4 PN/DP MFP, vous accédez à tous
les appareils des sous-réseaux des interfaces X1, X2 et X3.
Autres conditions :
• IP-Forwarding est activé pour la CPU 1518-4 PN/DP MFP.
• L'adresse IP de C/C++ Runtime et l'adresse IP de l'interface X3 se trouvent dans le même
sous-réseau IP.
• Les routages vers les sous-réseaux IP de X1 et X2 sont inscrits dans C/C++ Runtime.
Dans C/C++ Runtime, vous indiquez un routage avec la commande suivante : "Route add-
net <sous réseau IP cible> mask <masque de sous-réseau> gw <Gateway>
La figure suivante montre une configuration dans laquelle un PC accède via l'interface X2 au
système C/C++ Runtime de la CPU 1518-4 PN/DP MFP.
Figure 11-10 Accès à C/C++ Runtime via l'interface X2
Communication
Routage
11.3 IP Forwarding
Tenir compte de la sécurité du réseau en cas de IP Forwarding

Lorsque vous activez la fonction IP Forwarding pour une CPU, vous autorisez un accès de
l'extérieur à des appareils qui ne sont normalement accessibles et pilotés que par la CPU. Ces
appareils ne sont donc en général pas protégés contre les attaques.
La figure suivante montre comment protéger votre système d'automatisation contre des
accès non autorisés.
Figure 11-11 Sécurité du réseau et IP Forwarding
• La CPU accède par les interfaces X1 et X2 à tous les appareils dans les sous-réseaux IP B et
C proches en vert foncé.
• Un routeur SCALANCE S est configuré dans la CPU. La CPU accède par le biais du routeur
aux appareils dans le sous-réseau IP A distant en vert clair.
• Dans la CPU, la fonction "Accès à l'API via module de communication" est activée pour le
CP 1543. La CPU accède à tous les appareils dans le sous-réseau IP par le biais de
l'interface W1.
Si la fonction IP Forwarding est activée dans la CPU, un appareil du sous-réseau IP A peut
accéder à tous les appareils dans les sous-réseaux IP B, C et D proches de la CPU.
Protégez votre système d'automatisation et les appareils raccordés contre des accès non
autorisés de l'extérieur.
Séparez les sous-réseaux IP proches de la CPU des sous-réseaux IP distants au moyen d'un
pare-feu. Utilisez, par exemple, le module de sécurité SCALANCE S avec pare-feu intégré.
La façon de protéger une cellule d'automatisation à l'aide des modules de sécurité SCALANCE
S602 V3 et SCALANCE S623 avec un pare-feu est décrite dans cet exemple d'application
Communication
Routage
11.4 Routage d'enregistrement
Activer/désactiver IP Forwarding
Procédez comme suit pour activer la fonction IP Forwarding :
1. Sélectionnez la CPU dans la vue du réseau de STEP 7 (TIA Portal).
2. Dans la fenêtre d'inspection, naviguez jusqu'à "Général" > "Configuration avancée" > "IP
Forwarding" dans les propriétés de la CPU.
3. Cochez la case "Activer le transfert IPv4 pour les interfaces de cet API" dans la zone
"Configuration IPv4 Forwarding".
Figure 11-12 Activer IP Forwarding
Résultat : IP Forwarding est activé pour toutes les interfaces de la CPU S7-1500.
Pour désactiver IP Forwarding, vous décochez la case "Activer le transfert IPv4 pour les
interfaces de cet API".
Définition du routage d'enregistrement

Des données peuvent être envoyées d'une station d'ingénierie PROFINET à des appareils de
terrain en traversant différents réseaux. Comme la station d'ingénierie s'adresse aux appareils
de terrain avec des enregistrements normalisés et que ces enregistrements font l'objet d'un
routage par des appareils S7, le terme de "routage d'enregistrement" s'est établi pour ce type
de routage.
Les données qui sont envoyées par ce procédé contiennent, outre le paramétrage des
appareils de terrain participants (esclaves DP), des informations spécifiques à chaque appareil
telles que consignes, valeurs limites.
Le routage d'enregistrement est par exemple utilisé en cas d'utilisation d'appareils de terrain
de fabricants divers. Les appareils de terrain sont adressés pour le paramétrage et le
diagnostic via des enregistrements normalisés (PROFINET).
Routage d'enregistrement avec STEP 7

Vous pouvez effectuer un routage d'enregistrement avec STEP 7 en appelant un outil
d'appareils (p. ex. PCT) par l'intermédiaire de l'interface TCI (Tool Calling Interface) et en
transmettant les paramètres d'appel. L'outil d'appareils utilise les mêmes voies de
communication que STEP 7 pour la communication avec l'appareil de terrain.
En dehors de l'installation de l'outil TCI sur l'ordinateur STEP 7, aucune configuration n'est
requise pour ce type de routage.
Communication
Routage
Par exemple, Routage d'enregistrement avec le Port Configuration Tool (PCT)

Le Port Configuration Tool (PCT) permet de configurer les maîtres IO-Link de l'ET200 et de
paramétrer les périphériques IO-Link qui y sont raccordés. Les sous-réseaux sont reliés par des
routeurs d'enregistrement. Les routeurs d'enregistrement sont par exemple des CPU, CP, IM,
maîtres IO-Link.
Vous trouverez les constellations de routeurs d'enregistrement prises en charge par PCT dans
cette FAQ (http://support.automation.siemens.com/WW/view/fr/87611392).
La figure suivante montre un exemple de configuration pour le routage d'enregistrement
avec PCT.
Figure 11-13 Exemple de configuration pour le routage d'enregistrement avec PCT
• La différence entre routage normal et routage d'enregistrement est expliquée dans cette
FAQ (https://support.industry.siemens.com/cs/ww/fr/view/7000978).
• Se reporter aux manuels des appareils respectifs pour savoir si la CPU, le CP ou le CM
prennent en charge le routage d'enregistrement.
• L'affectation de ressources de liaison pour le routage d'enregistrement est décrite au
paragraphe Affectation de ressources de liaison (Page 1).
• Des informations complémentaires sur la configuration avec STEP 7 sont disponibles dans
l'aide en ligne de STEP 7.
Communication
Routage
11.5 Interface virtuelle pour applications à base IP

La CPU S7-1500 CPU offre, à partir de la version de firmware 2.8, la possibilité d'atteindre vos
applications basées IP, comme p. ex. OPC UA, non seulement via ses interfaces (PN) locales,
mais également via les interfaces des processeurs de communication sur la même station. Un
partenaire de communication accède à ces applications basées IP via une interface virtuelle,
configurable dans TIA Portal à partir de la version V16. Cette interface virtuelle est désignée
par W1 (selon CEI 81346-2).
Caractéristiques de l'interface virtuelle

L'interface virtuelle n'est pas une interface entièrement diagnosticable avec les propriétés
connues des interfaces classiques. L'interface virtuelle ne s'affiche pas dans les vues
graphiques, car la liaison interne par le bus interne ne représente pas un sous-réseau S7 et n'a
pas de ports. Il n'est donc pas possible d'établir une liaison physique par un câble réseau.
L'adresse IP de l'interface virtuelle s'affiche (p. ex. dans TIA Portal, sur l'écran de la CPU) et
peut être configurée.
Les services basés IP suivants peuvent, p. ex., être utilisés avec l'interface virtuelle W1 :
• OPC UA (client et serveur)
• liaisons OUC programmées
• communication S7 (accès système d'ingénierie/IHM et instructions pour la communication
S7, comme p. ex. PUT, GET)
L'interface activée peut être utilisée dans les boîtes de dialogue dans lesquelles sont
configurées des liaisons basées IP.
Figure 11-14 Principe de l'interface virtuelle
Communication
Routage
L'interface virtuelle présente les limitations suivantes par rapport aux interfaces classiques :
• L'interface virtuelle ne permet pas d'accéder au serveur Web.
• La sauvegarde en ligne n'est pas possible avec TIA Portal via une console de
programmation raccordée.
• Si la CPU et le partenaire de communication sont reliés entre eux via l'interface virtuelle,
vous ne pouvez pas échanger de données via LLDP (Link Layer Discovery Protocol).
• Le service Routage S7 n'utilise pas l'interface virtuelle W1.
Condition
Les conditions suivantes doivent être remplies pour l'accessibilité d'un service CPU via
l'interface Ethernet d'un CP.
• CP 1543-1 à partir de la version de firmware V2.2
Les CPU R/H ne prennent pas cette fonction en charge, car elles ne prennent pas en charge les
processeurs de communication.
Configuration de l'interface virtuelle W1

Dans les propriétés d'une CPU S7-1500 à partir de la version de firmware V2.8, vous pouvez
affecter une interface virtuelle W1 à un module de communication enfiché sous
"Configuration avancée > Accès à l'API via module de communication". L'accès à la CPU peut
alors se faire de l'extérieur par le biais de cette interface virtuelle. La liste de sélection est vide
si aucun CP n'est enfiché ou si les CP enfichés ne prennent pas en charge l'accès à la CPU.
Figure 11-15 Sélection du CP dans les propriétés de la CPU
Communication
Routage
Une fois le CP sélectionné, les indications et les paramètres pour l'interface virtuelle
s'affichent. Vous pouvez éditer ici les paramètres pour le protocole IP et les paramètres
PROFINET :
• Vous pouvez choisir le sous-réseau IP librement, tout comme le CP. Vous indiquez le sous-
réseau IP via le masque de sous-réseau et l'adresse IP de l'interface virtuelle.
• Lors de la saisie du sous-réseau IP pour l'interface virtuelle, veillez à ne pas indiquer le
même sous-réseau IP que pour l'interface locale de la CPU.
Une fois l'adresse IP saisie, elle apparaît dans la liste des adresses de serveur dans la boîte de
dialogue des propriétés du serveur OPC UA. Avec ces paramétrages, la CPU dispose de la
nouvelle interface virtuelle W1 par laquelle des services CPU comme le serveur OPC UA sont
accessibles au moyen d'un module de communication. Les liaisons créées en conséquence et
la communication S7 (p. ex. IHM et BSEND, BRCV) passent par cette interface Le serveur OPC
UA ne permet pas la sélection d'une interface précise (sélection par une adresse IP) : elles
sont toutes possibles ou bien aucune n'est possible.
Remarque
L'adresse IP de l'interface virtuelle ne figure pas en tant que W1 sous les interfaces locales
actuellement affichées (Xn) sur l'écran de l'appareil, mais sous "Adresses" dans la section
"Paramètres". L'interface virtuelle est visible même lorsqu'aucun CP n'est enfiché ou que
l'interface virtuelle n'est pas activée. L'adresse IP et le masque de sous-réseau ont la valeur
0.0.0.0 si aucune suite IP n'est disponible.
Lorsqu'on modifie les paramètres d'adresse IP configurés et chargés de l'interface virtuelle via
l'écran, l'instruction T_CONFIG ou en ligne, la configuration chargée est à nouveau active
après un redémarrage de la CPU.
Modifications de configuration dans le CP

Un changement du module de communication affecté peut avoir des conséquences sur la
configuration de l'interface virtuelle :
• Dans les propriétés de la CPU :
– Affectation d'un autre CP : la configuration est appliquée pour le nouveau CP.
– Désélection du CP affecté : L'interface virtuelle W1 est désactivée et la configuration est
perdue.
Il faudra à nouveau procéder à la configuration en cas de nouvelle affectation d'un CP.
• Dans l'appareil :
– Déplacement du CP : la configuration reste valable si le CP est uniquement déplacé vers
un autre emplacement de l'appareil.
– Retrait du CP : si le CP est supprimé ou déplacé dans un autre appareil, la configuration
est conservée. Dans la liste déroulante de la CPU, le CP est affiché comme manquant et
la compilation de la configuration affiche une erreur. La correction peut s'effectuer en
désélectionnant le CP manquant ou en affectant un autre CP.
Communication
Routage
Affichage dans le diagnostic et les constantes système

L'interface virtuelle W1 est affichée dans la vue de diagnostic sous "En ligne & Diagnostic".
Dans les propriétés de la CPU, l'identification matérielle de l'interface virtuelle est affichée
dans les constantes système.
Paramètres dans le module de communication

Les paramètres du pare-feu interne au CP n'influent pas sur la communication via l'interface
virtuelle. Les fonctions de sécurité du module de communication ne peuvent donc pas
protéger le traffic de données via l'interface virtuelle.
IMPORTANT
Liaison avec des réseaux non sécurisés
Si vous connectez le CP avec un réseau non sécurisé, vous devez absolument intercaler un
pare-feu supplémentaire entre le CP et le réseau non sécurisé. Utilisez, par exemple, les
modules de sûreté SCALANCE S602 V3 et SCALANCE S623 avec pare-feu intégré.
Communication
Ressources de liaison 12
12.1 Ressources de liaison d'une station
Introduction
Certains services de communications requièrent des liaisons. Les liaisons utilisent des
ressources du système d'automatisation (station). Les ressources de liaison sont mises à la
disposition de la station par les CPU, processeurs de communication (CP) et modules de
communication (CM).
Ressources de liaison d'une station

Les ressources de liaison disponibles dépendent des CPU, CP et CM utilisés et ne doivent pas
excéder un nombre maximal par station.
Le nombre maximal de ressources d'une station est déterminé par la CPU.
Ressources de liaison réservées

Chaque CPU réserve des ressources de liaison pour la communication PG, IHM et serveur
Web. Ceci permet de s'assurer qu'une PG peut toujours établir au moins une liaison en ligne
avec la CPU, quel que soit le nombre d'autres services de communication utilisant déjà des
ressources de liaison.
Ressources de liaison dynamiques

Il existe en outre des ressources dynamiques. La différence entre le nombre maximal de
ressources de liaison et le nombre de ressources de liaison réservées constitue le nombre
maximal de ressources de liaison dynamiques.
Ce contingent de ressources de liaison dynamiques sert aux services de communication PG,
communication IHM, communication S7, Open User Communication, communication Web,
communication client/serveur OPC UA et autres communications.
Communication
La figure suivante montre à titre d'exemple comment des composants mettent des ressources
de liaison à la disposition d'une station S7-1500.
① Ressources de liaison disponibles de la station, dont

A ressources de liaison réservées de la station
A+B Ressources de liaison de la CPU 1518
C Ressources de liaison du module de communication CM 1542-1
D Ressources de liaison du processeur de communication CP 1543-1
② Ressources de liaison maximales de la station à l'exemple d'une configuration avec CPU 1518,
CM 1542-1 et CP 1543-1
Figure 12-1 Ressources de liaison d'une station
Communication
Nombre de ressources de liaison d'une station
Tableau 12- 1 Ressources de liaison prises en charge au maximum pour quelques types de CPU
Ressources de liaison d'une station 1511 1512C 1515 1516 1517 1518
1511C 1513
Ressources de liaison maximales de la station 96 128 192 256 320 384
dont réservées 10
dont dynamiques 86 118 182 246 310 374
Ressources de liaison de la CPU 64 88 108 128 288 320
Nombre max. de ressources de liaison supplémentaires 32 40 84 128 32 64
utilisables par embrochage de CM/CP
Ressources de liaison supplémentaires CM 1542-1 64
Ressources de liaison supplémentaires CP 1543-1 118
Ressources de liaison supplémentaires CM 1542-5 40
Ressources de liaison supplémentaires CP 1542-5 16
Le nombre de ressources de liaison prises en charge par une CPU ou par un module de
communication est indiqué dans les caractéristiques techniques des manuels.
Exemple
Vous avez configuré une CPU 1516-3 PN/DP avec un module de communication CM 1542-1 et
un processeur de communication CP 1542-5.
• Ressources de liaison maximales de la station : 256
• Ressources de liaison disponibles :
– CPU 1516-3 PN/DP : 128
– CM 1542-1 : 64
– CP 1542-5 : 16
– Total : 208
Cette configuration met à disposition 208 ressources de liaison. L'ajout de modules de
communication permet à la station de prendre en charge au maximum 48 ressources de
liaison supplémentaires.
Ressources de liaison réservées

Sur les stations avec les CPU S7-1500, ET 200SP et la CPU ET 200pro, 10 ressources de liaison
sont réservées sur S7-1500 de base.
• 4 pour la communication PG, requises par STEP 7 pour les fonctions de test et de
diagnostic, par exemple, ou le chargement dans la CPU
• 4 pour la communication IHM, utilisées par les premières liaisons IHM configurées dans
STEP 7
• 2 pour la communication avec le serveur Web
Communication
12.2 Affectation de ressources de liaison
Vue d'ensemble - Affectation des ressources de liaison

La figure ci-après montre comment les diverses liaisons utilisent les ressources du S7-1500.
① Communication IHM : voir ci-dessous

② Open User Communication : les liaisons de l'Open User Communication utilisent une ressource
de liaison sur chaque nœud d'extrémité.
③ Communication S7 : les liaisons de la communication S7 utilisent une ressource de liaison sur
chaque nœud d'extrémité.
④ Communication Web : la liaison au serveur Web utilise sur la station au moins une ressource de
liaison. Le nombre de liaisons utilisées dépend du navigateur.
⑤ Communication PG : la liaison PG de la station utilise une ressource de liaison.
⑥ Communication client/serveur OPC UA : pour l'occupation des ressources de liaison du serveur,
voir ci-dessous
⑦ Communication client/serveur OPC UA : pour l'occupation des ressources de liaison du client,
voir ci-dessous
Ressource de liaison pour la communication IHM
Ressource de liaison pour l'Open User Communication
Ressource de liaison pour la communication S7
Ressource de liaison pour la communication Web
Ressource de liaison pour la communication PG
Ressource de liaison pour la communication client/serveur OPC UA
Figure 12-2 Utilisation de ressources de liaison
Communication
Ressources de liaison pour la communication IHM

Lors de la communication IHM, l'utilisation de ressources de liaison sur la station dépend de
l'appareil IHM utilisé.
Tableau 12- 2 Nombre maximal de ressources de liaison utilisées pour différents appareils IHM
Appareil IHM Nombre max. de ressources de liaison de la

station utilisées par liaison IHM
Basic Panel 1
Comfort Panel 21
RT Advanced 21
RT Professional 3
1 Quand vous n'utilisez ni le diagnostic système, ni la configuration d'alarmes, la station ne requiert
qu'une seule ressource de liaison par liaison IHM.
Exemple : vous avez configuré les liaisons IHM suivantes pour une CPU 1516-3 PN/DP :
• deux liaisons IHM à un HMI TP700 Comfort (2 ressources de liaison chacune)
• une liaison IHM à un HMI KTP1000 Basic (1 ressource de liaison)
Au total, 5 ressources de liaison sont utilisées pour la communication IHM dans la CPU.
Ressources de liaison pour la communication client OPC UA

Chaque liaison que le client OPC UA de la CPU a établi avec un serveur OPC UA occupe une
ressource de liaison dans la station.
Lors de l'établissement et de l'interruption d'une liaison OPC UA, le client OPC UA utilise
temporairement une autre ressource de liaison. Cette ressource de liaison est de nouveau
libérée après un temps d'attente d'environ 60 secondes, conformément à RFC 793.
Remarque
Manque de ressources dû à des ressources de liaison temporaires
Un manque de ressources de liaison se produit dans le cas suivant :
• Le client OPC UA établit ou interrompt simultanément plusieurs liaisons.
• Le nombre de ressources de liaison disponibles de la station ne suffit pas pour les
ressources de liaison permanentes et temporaires de la communication client OPC UA.
Veillez à ce qu'il y ait toujours des ressources de liaison disponibles suffisantes pour
l'établissement et l'interruption de liaisons OPC UA dans la station.
Mesures :
• Planifiez des réserves suffisantes pour les liaisons client OPC UA.
• Le cas échéant, établissez ou interrompez les liaisons OPC UA les unes après les autres.
Communication
Ressources de liaison pour le routage

Pour la transmission de données à travers plusieurs sous-réseaux S7 ("routage S7"), une
liaison S7 est établie entre deux CPU. Les sous-réseaux S7 sont reliés les uns aux autres par
des passerelles appelées routeurs S7. Les CPU, CM et CP dans S7-1500 sont des routeurs S7.
Les principes suivants s'appliquent aux liaisons S7 par routeur :
• Une liaison par routeur utilise une ressource de liaison dans chaque nœud d'extrémité,
STEP 7 affiche ces ressources dans le tableau "Ressources de liaison".
• Sur le routeur S7, deux ressources de liaison spéciales sont utilisées pour le routage S7.
STEP 7 n'affiche pas les ressources de liaison spéciales pour routage S7 dans le tableau
"Ressources de liaison". Le nombre de ressources pour le routage S7 dépend de la CPU.
Vous trouverez les ressources pour le routage S7 dans les caractéristiques techniques de la
CPU sous "Nombre de liaisons de routage S7".
Ressource de liaison pour la communication S7
Ressources de liaison particulières pour le routage S7
Figure 12-3 Ressources de liaison pour le routage S7
Le routage d'enregistrement permet lui aussi de transmettre des données d'une station
d'ingénierie connectée à PROFINET à divers appareils de terrain à travers plusieurs sous-
réseaux S7 par le biais de PROFIBUS.
Comme le routage S7, le routage d'enregistrement utilise sur chaque routeur deux des
ressources de liaison spéciales pour routage S7.
Remarque
Ressources de liaison lors du routage d'enregistrement
Sur le routeur d'enregistrement, deux ressources de liaison particulières du routage S7 sont
utilisées pour le routage d'enregistrement. Ni la liaison d'enregistrement ni les ressources de
liaison occupées ne sont affichées dans le tableau des ressources d'enregistrement.
Communication
Quand les ressources de liaison sont-elles utilisées ?

Le moment de l'utilisation des ressources de liaison dépend de la façon dont la liaison est
créée : automatiquement, par programmation ou par configuration (voir chapitre Création
d'une liaison (Page 1)).
• Création programmée d'une liaison :
Dès que, dans le programme utilisateur de la CPU, une instruction d'établissement de
liaison (TSEND_C/TRCV_C ou TCON) est appelée, une ressource de liaison est utilisée.
Un paramétrage approprié du paramètre CONT des instructions TSEND_C/TRCV_C ou
l'appel de l'instruction TDISCON permet de couper la liaison après la transmission des
données et de libérer la ressource de liaison. Une fois la liaison coupée, les ressources de
liaison sont de nouveau disponibles dans la/le CPU/CP/CM.
• Liaisons configurées (par ex. liaison S7) :
Quand vous avez configuré une liaison dans STEP 7, la ressource de liaison est utilisée dès
que la configuration matérielle a été chargée dans la CPU.
Une liaison configurée n'est pas coupée après son utilisation pour la transmission de
données. La ressource de liaison reste utilisée en permanence. Pour libérer la ressource de
liaison, vous devez supprimer la liaison configurée dans STEP 7 et charger la configuration
modifiée dans la CPU.
• Liaison PG :
Des ressources de liaison sont utilisées dès que vous avez relié la PG à une CPU en ligne
dans STEP 7.
• Serveur Web :
Des ressources de liaison sont utilisées dans la CPU tant que vous laissez le serveur Web de
la CPU ouvert dans un navigateur.
• Serveur OPC UA
Chaque liaison au serveur OPC UA de la CPU occupe une ressource de liaison dans la
station. Cette ressource de liaison est immédiatement libérée une fois la liaison coupée.
• Client OPC UA
Chaque liaison que le client OPC UA de la CPU établit avec un serveur OPC UA occupe une
ressource de liaison dans la station. Lors de l'établissement d'une liaison OPC UA, le client
OPC UA utilise temporairement une autre ressource de liaison. Cette ressource de liaison
est de nouveau libérée à l'interruption de la liaison OPC UA après un temps d'attente
d'environ 60 secondes, conformément à RFC 793.
Surveillance du nombre maximal possible de ressources de liaison
Hors ligne
STEP 7 surveille l'utilisation des ressources de liaison lors de la configuration des liaisons. STEP
7 signale tout dépassement du nombre maximal de ressources de liaison par une alarme
appropriée.
En ligne
La CPU surveille l'utilisation des ressources de liaison dans le système d'automatisation. Si
vous établissez dans le programme utilisateur plus de liaisons qu'il n'y a de ressources de
liaison disponibles dans le système d'automatisation, la CPU signale une erreur en réponse à
l'instruction d'établissement de liaison.
Communication
12.3 Affichage des ressources de liaison
Comparaison entre S7-1500 et S7-300

Vous trouverez dans cette FAQ
(https://support.industry.siemens.com/cs/ww/fr/view/109747092) une comparaison de la
gestion des ressources de communication des S7-1500 et S7-300.
Affichage des ressources de liaison dans STEP 7 (vue hors ligne)

Vous pouvez afficher les ressources de liaison d'un système d'automatisation dans la
configuration matérielle. Les ressources de liaison figurent dans la fenêtre d'inspection, dans
les propriétés de la CPU.
Figure 12-4 Exemple : Ressources de liaison réservées et disponibles (vue hors ligne)
① Ressources de liaison spécifiques à une station

Les colonnes des ressources de liaison spécifiques à la station renseignent sur les ressources
de liaison utilisées et disponibles de la station.
Dans l'exemple, le système d'automatisation dispose d'au maximum 256 ressources de liaison
spécifiques à la station :
• 10 ressources de liaison réservées dont 4 sont déjà utilisées et 6 encore disponibles.
Les ressources utilisées se répartissent comme suit :
– 4 ressources pour la communication IHM
• 246 ressources de liaison dynamiques dont 26 sont déjà utilisées et 220 encore
disponibles.
– 6 ressources pour la communication IHM
– 7 ressources pour la communication S7
– 13 ressources pour l'Open User Communication
Communication
Le triangle d'avertissement s'affiche par conséquent dans la colonne des ressources

dynamiques de la station, car la somme maximale des ressources de liaison disponibles de la
CPU, du CP et du CM (= 310 ressources de liaison) excède la limite de la station fixée à 256.
Remarque
Dépassement des ressources de liaison disponibles
STEP 7 signale le dépassement des ressources de liaison spécifiques de la station par un
avertissement. Si vous voulez exploiter la totalité des ressources de liaison disponibles de la
CPU, du CP et du CM, utilisez une CPU avec un plus grand nombre maximal disponible de
ressources de liaison spécifiques à la station ou bien réduisez le nombre de liaisons de
communication.
② Ressources de liaison spécifiques au module

Les colonnes des ressources de liaison spécifiques au module renseignent sur l'utilisation des
ressources de liaison dans les CPU, CP et CM d'un système d'automatisation.
L'affichage s'effectue en fonction du module et non de l'interface.
Dans l'exemple, la CPU met un maximum de 128 ressources de liaison à disposition dont 18
sont déjà utilisées et 110 restent disponibles.
• 6 ressources pour la communication IHM
• 4 ressources pour la communication S7
• 8 ressources pour l'Open User Communication
Communication
Affichage des ressources de liaison dans STEP 7 (vue en ligne)

Si vous êtes connecté en ligne à la CPU, vous pouvez également vous faire afficher sous
"Informations sur la liaison" le nombre de ressources momentanément utilisées.
Figure 12-5 Ressources de liaison - en ligne
La vue en ligne du tableau "Ressources de liaison" contient, outre les colonnes de la vue hors
ligne, des colonnes avec les ressources de liaison momentanément utilisées. Dans la vue en
ligne, toutes les ressources de liaison utilisées dans le système d'automatisation s'affichent,
indépendamment de la méthode ayant servi à créer la liaison.
La ligne "Autre communication" affiche les ressources de liaison utilisées pour la
communication avec des appareils d'autres constructeurs. Le tableau est mis à jour
automatiquement.
Remarque
Quand une liaison S7 par routeur passe par une CPU, les ressources de liaison requises de la
CPU ne sont pas affichées dans le tableau des ressources de liaison.
Communication
Affichage des ressources de liaison pour IHM

Vous trouverez des informations sur la disponibilité et l'utilisation des ressources de liaison
pour les liaisons IHM dans la vue hors ligne de l'appareil IHM (dans la fenêtre d'inspection,
sous les propriétés dans la zone "Ressources de liaison").
Figure 12-6 Ressources de liaison - Communication IHM
Sont affichés dans la zone Ressources de liaison :

• Le nombre de liaisons disponibles dans l'IHM, réservées à la communication IHM et HTTP
• Le nombre de ressources de liaison utilisées hors ligne dans l'IHM pour la communication
IHM et HTTP
Lorsque le nombre maximal de ressources de liaison disponibles pour un appareil IHM est
dépassé, STEP 7 émet un message approprié.
• "Nombre maximal de ressources d'AP utilisées par liaison IHM" : Ce paramètre est un
facteur qui multiplie le nombre de liaisons IHM utilisées hors ligne. Le produit représente
le nombre de ressources IHM utilisées sur la CPU.
Affichage du nombre de ressources de liaison sur le serveur Web

Vous pouvez consulter les ressources de liaison non seulement sous STEP 7 mais aussi sur la
page correspondante du serveur Web affichée dans un navigateur.
Vous trouverez des informations sur l'affichage des ressources de liaison dans le serveur Web
dans la description fonctionnelle Serveur Web
Communication
Diagnostic et suppression des défauts 13
13.1 Diagnostic de liaisons
Table des liaisons dans la vue en ligne

L'état des liaisons d'une CPU sélectionnée dans l'éditeur de matériel et de réseaux de STEP 7
s'affiche dans la vue en ligne de la table des liaisons.
Figure 13-1 Vue en ligne de la table des liaisons
Pour la liaison choisie dans la table des liaisons, des informations de diagnostic détaillées sont
disponibles dans l'onglet "Informations sur la liaison".
Communication
Diagnostic et suppression des défauts
Onglet "Informations sur la liaison" : détails de la liaison
Figure 13-2 Diagnostic de liaisons - détails de la liaison
Communication
Onglet "Informations sur la liaison" : détails des adresses
Figure 13-3 Diagnostic de liaisons - détails des adresses
Diagnostic par serveur Web

Le serveur Web intégré d'une CPU vous permet d'analyser les informations de diagnostic de la
CPU via un navigateur Web.
Les informations suivantes relatives à la communication par PROFINET sont disponibles dans
différents onglets, sur la page Internet "Communication" :
• Informations sur les interfaces PROFINET de la CPU (par ex. adresses, sous-réseaux,
propriétés physiques)
• Informations sur la qualité de la transmission des données (par ex. nombre de paquets de
données reçus/envoyés sans erreur)
• Informations sur l'occupation/la disponibilité de ressources de liaison
• La page "Etat des liaisons" est similaire à la vue en ligne dans STEP 7 et donne également
une vue d'ensemble de toutes les liaisons grâce à la vue détaillée.
Communication
13.2 Adresse de secours
Diagnostic par le programme utilisateur

Vous pouvez évaluer les informations de diagnostic des liaisons configurées et programmées
de la CPU par l'intermédiaire du programme utilisateur si vous programmez l'instruction
T_DIAG.
La fonctionnalité du serveur Web est décrite dans la description fonctionnelle Serveur Web
13.2 Adresse de secours

Si vous n'accédez pas à la CPU via l'adresse IP, vous pouvez paramétrer une adresse de
secours (Emergency IP) pour la CPU. Via l'adresse de secours, vous pouvez rétablir la liaison
avec la CPU, afin de charger une configuration de l'appareil avec une adresse IP valide.
Vous pouvez définir une adresse de secours indépendamment du niveau de protection de la
CPU
Quand avez-vous besoin d'une adresse de secours ?

Dans les cas suivants, votre CPU n'est pas accessible :
• L'adresse IP de l'interface PROFINET est présente en double.
• Le masque de sous-réseau est mal paramétré.
Conditions
• Vous avez sélectionné dans la configuration de l'appareil dans STEP 7 "Définir l'adresse IP
dans le projet" pour le protocole IP.
• La CPU est à l'état de fonctionnement ARRET.
Restaurer la configuration de l'appareil avec une adresse de secours

1. Définissez l'adresse de secours pour l'interface de la CPU avec un outil DCP. Par exemple,
SIMATIC Automation Tool dispose d'une commande DCP "Définir l'adresse IP".
La LED de maintenance de la CPU clignote. Le tampon de diagnostic indique également
qu'une adresse de secours a été activée pour une interface Ethernet.
2. Chargez un projet STEP 7 avec une adresse IP valide dans la CPU.
3. Eteignez, puis rallumez la CPU.
L'adresse de secours est réinitialisée.
Résultat
La CPU démarre avec l'adresse IP valide.
Communication
Communication avec le système redondant
S7-1500R/H 14
Introduction
La communication avec le système redondant S7-1500R/H fonctionne en principe de la même
manière que le système standard S7-1500.
Ce chapitre décrit les particularités et les restrictions de la communication avec le système
redondant S7-1500R/H
Possibilités de communication pour le système redondant S7-1500R/H

• Open User Communication via TCP/IP, UDP, ISO-on-TCP et Modbus/TCP
• Communication S7 comme serveur
• Communication IHM, communication PG
• Communication Secure PG/IHM (voir aussi Communication PG/IHM sécurisée (Page 1))
• SNMP
• Synchronisation d'horloge via NTP
Restrictions pour la communication avec le système redondant S7-1500R/H

• Open User Communication :
– aucune liaison configurée
– pas de prise en charge de Secure Open User Communication
– e-mail : Les CPU S7-1500R/H prennent uniquement en charge les versions < V5.0 de
l'instruction "TMAIL_C". Les versions à partir de V5.0 ne sont pas prises en charge.
– pas de prise en charge de descriptions de liaisons selon "TCON_Param"
• aucun OPC UA
• aucune communication S7 comme client
• aucun serveur Web
• communication PG : il n'est pas possible d'accéder simultanément en ligne aux deux CPU.
Vous pouvez accéder soit à la CPU principale, soit à la CPU réserve.
• les CPU du système S7-1500R/H ne prennent en charge aucun module de communication
enfiché de manière centralisée
Communication
Communication avec le système redondant S7-1500R/H
14.1 Adresses IP système
Les adresses IP système du système redondant S7-1500R/H

En plus des adresses IP d'appareil des CPU, le système redondant S7-1500R/H prend en charge
des adresses IP système :
• adresse IP système pour les interfaces PROFINET X1 des deux CPU (adresse IP système X1)
• Adresse IP système pour les interfaces PROFINET X2 des deux CPU (adresse IP système X2)
Les adresses IP système servent à la communication avec d'autres appareils (par exemple
appareils IHM, CPU, PC). Les appareils communiquent toujours via l'adresse IP système avec la
CPU principale du système redondant. Cela permet par exemple de s'assurer que le partenaire
de communication peut, après une défaillance de la CPU principale, communiquer en mode
redondant avec la nouvelle CPU principale (auparavant CPU réserve) dans l'état système RUN-
Solo.
Chaque adresse IP système est dotée d'une adresse MAC virtuelle.
Vous activez les adresses IP système dans STEP 7.
Avantages des adresses IP système par rapport aux adresses IP d'appareil

• Le partenaire de communication communique de manière ciblée avec la CPU principale.
• La communication du système redondant S7-1500R/H via une adresse IP système continue
à fonctionner également en cas de défaillance de la CPU principale.
Cas d'application
Vous utilisez les adresses IP système dans les applications suivantes :
• Communication HMI avec le système redondant S7-1500R/H : Vous vous servez d'une HMI
pour commander ou surveiller le processus sur le système redondant S7-1500R/H.
• Open User Communication avec le système redondant S7-1500R/H :
– une autre CPU ou une application sur le PC accède à des données du système
redondant S7-1500R/H.
– le système redondant S7-1500R/H accède à un autre appareil.
Des liaisons TCP, UDP et ISO-on-TCP sont possibles.
• IP-Forwarding : si vous utilisez les adresses IP système comme passerelle/route par défaut
pour les routes IP par le système redondant S7-1500R/H, des paquets IP sont transmis,
même en cas de défaillance d'une CPU.
Conditions
• L'interface du partenaire de communication est reliée aux deux CPU par la même interface
respectivement (X2 par exemple).
• L'adresse IP système pour les interfaces du système S7-1500R/H est activée.
Communication
Communication via l'adresse IP système X2

Si les CPU du système redondant S7-1500R/H sont dotées de deux interfaces PROFINET,
privilégiez pour la communication avec d'autres appareils l'interface PROFINET X2.
La figure suivante présente une configuration dans laquelle les partenaires de
communication sont reliés aux CPU du système redondant S7-1500R/H par leur interface
PROFINET X2 respective.
① Open User Communication entre une autre CPU et le système redondant S7-1500R/H
② Communication HMI avec le système redondant S7-1500R/H
③ Open User Communication entre le système redondant S7-1500R/H et un PC
Figure 14-1 Exemple : communication du système redondant S7-1515R via l'adresse IP système X2
Communication
Communication via l'adresse IP système X1

La figure suivante illustre une configuration dans laquelle les partenaires de communication
sont connectés via un commutateur à l'anneau PROFINET du système redondant S7-1500R/H.
L'anneau PROFINET connecte les partenaires de communication via les interfaces PROFINET
X1 respectives des deux CPU.
Comme la CPU 1513R ne dispose que d'une interface PROFINET, le raccordement via l'anneau
PROFINET est le seul moyen de communication via l'adresse IP système X1.
① Open User Communication entre le système redondant S7-1500R/H et une autre CPU
Figure 14-2 Exemple : communication du système redondant S7-1513R via l'adresse IP système X1
Communication
Communication via les adresses IP système X1 et X2

Lorsque les CPU du système redondant S7-1500R/H possèdent deux interfaces PROFINET (X1
et X2), vous pouvez utiliser les adresses IP système respectives pour chaque interface
PROFINET. Les appareils PROFINET connectés aux interfaces X1 des CPU communiquent via
l'adresse IP système X1. Les appareils PROFINET connectés aux interfaces X2 des CPU
communiquent via l'adresse IP système X2.
① Open User Communication entre le système redondant S7-1500R/H et une autre CPU.
Figure 14-3 Exemple : communication du système redondant S7-1515R via les adresses IP système X1
et X2
Communication
IP-Forwarding via les adresses IP système

si vous utilisez les adresses IP système comme passerelle/route par défaut pour les routes IP
par le système redondant S7-1500R/H, des paquets IP sont transmis, même en cas de
défaillance d'une CPU.
Dans la figure suivante, le PC est connecté aux deux interfaces X2 des CPU S7-1500R.
L'adresse IP système X2 est entrée comme passerelle dans le PC pour la route vers l'appareil
IHM. L'appareil IHM est raccordé via un commutateur à l'anneau PROFINET du système
redondant S7-1500. L'adresse IP système X1 est configurée comme routeur dans l'appareil
IHM.
Figure 14-4 Exemple : IP-Forwarding via les adresses IP système
Communication
Activer les adresses IP système

Conditions :
• STEP 7 à partir de V15.1
• système redondant S7-1500R/H avec deux CPU, par ex. deux CPU 1513R-1PN
Si les CPU du système redondant S7-1500R/H sont dotées de deux interfaces PROFINET (X1 et
X2), vous pouvez activer une adresse IP système pour les deux interfaces PROFINET. Ce
paragraphe décrit comment activer l'adresse IP système pour l'interface X1.
Pour activer l'adresse IP système pour votre système redondant S7-1500R/H, procédez comme
suit :
1. Sélectionnez dans la vue de réseau de STEP 7 l'interface X1 de l'une des deux CPU.
2. Dans la fenêtre d'inspection, naviguez vers "Propriétés" > "Général" > "Adresses Ethernet"
jusqu'à la zone "Adresse IP système pour la communication commutée".
3. Activez la case "Activez l'adresse IP système pour la communication commutée".
STEP 7 crée automatiquement une adresse IP système.
Figure 14-5 Configurer l'adresse IP système
4. Le cas échéant, ajustez l'adresse IP système.

5. Le cas échéant, ajustez l'adresse MAC virtuelle. Affectez pour cela une valeur univoque au
sein du projet pour "Adresse MAC virtuelle" pour le dernier octet (plage de valeurs 01H à
FFH).
Remarque
Univocité de l'adresse MAC virtuelle
Le système redondant S7-1500R/H utilise pour chaque adresse IP système une adresse
MAC de la plage d'adresses 00-00-5E-00-01-00 à 00-00-5E-00-01-00. Cette plage
d'adresses est aussi utilisée pour VRRP (Virtual Redundancy Protocol).
Si vous utilisez des appareils avec VRRP, des commutateurs par exemple, vous devez donc
veiller à ce que les adresses MAC soient uniques à l'intérieur d'un domaine de diffusion
Ethernet.
Résultat : l'adresse IP système X1 pour les interfaces PROFINET X1 des deux CPU est activée.
Communication
14.2 Comportement en cas de SyncUp
14.2 Comportement en cas de SyncUp
Comportement de liaisons de communication via l'adresse IP système à l'état système SYNCUP

• Les liaisons HMI, PG et S7 sont fermées temporairement. Il est possible d'établir des
liaisons au système redondant S7-1500R/H pendant une courte durée pendant l'opération
de SYNCUP.
• Toutes les liaisons disponibles de l'Open User Communication sont interrompues :
– Les liaisons configurées par les CPU du système redondant comme partenaires de
liaison actifs sont de nouveau configurées après l'opération de SYNCUP.
– Le système redondant S7-1500R/H configure de nouveau des nœuds d'extrémité de
liaison pour l'établissement de liaison passif après l'opération de SYNCUP.
• Le traitement d'instances en cours d'exécution des instructions TSEND et TRCV est arrêté.
Le paramètre du bloc STATUS fournit 80C4H (erreur de communication temporaire).
14.3 Comportement en cas de commutation entre CPU

principale/réserve
Comportement de liaisons de communication via l'adresse IP système pendant une commutation

entre CPU principale/réserve
• Les instances en cours d'exécution des instructions TSEND et TRCV sont arrêtées et
fournissent l'état 80C4H (erreur de communication temporaire).
• Les liaisons que le système redondant S7-1500R/H avait créées en les activant sont de
nouveau créées par la nouvelle CPU principale.
• La nouvelle CPU principale configure de nouveau des nœuds d'extrémité de liaison pour
l'établissement de liaison passif.
Remarque
Durée augmentée de l'interruption de la liaison
Lorsque le système distant n'émet pas de façon active après la commutation CPU principale-
réserve, il peut arriver que la surveillance de liaison (p. ex. TCP-Keep-Alive ou l'application)
doive être effectuée par le système distant, jusqu'à ce que la liaison puisse à nouveau être
établie.
Communication
14.4 Ressources de liaison du système redondant S7-1500R/H
14.4 Ressources de liaison du système redondant S7-1500R/H
Nombre maximum de ressources de liaison du système redondant S7-1500R/H

Le système redondant S7-1500R/H prend en charge un nombre maximum de ressources de
liaison.
La CPU utilisée détermine le nombre maximal de ressources pour le système redondant :
• CPU 1513R : 88 ressources de liaison au maximum
• CPU 1515R : 108 ressources de liaison au maximum
• CPU 1517H : 288 ressources de liaison au maximum
Affectation des ressources de liaison

Les liaisons de communication occupent des ressources de liaison dans le système redondant
S7-1500R/H.
Chaque liaison de communication avec le système redondant S7-1500R/H occupe des
ressources de liaison dans la station S7-1500R/H. La station S7-1500R/H comprend la
configuration matérielle des deux CPU du système redondant S7-1500R/H.
Selon l'adresse IP utilisée, une liaison de communication utilise également des ressources de
liaison dans l'une ou les deux CPU du système redondant S7-1500R/H.
Le tableau ci-après indique dans quelle CPU une liaison de communication occupe des
ressources de liaison selon l'adresse IP utilisée.
Liaison via... Ressources de liaison de la Ressources de liaison de Ressources de liaison de

station CPU avec ID de redondance CPU avec ID de redondance
1 2
une adresse IP système X X X
une adresse IP d'appareil de X X -
la CPU avec ID de redondance
1
une adresse IP d'appareil de X - X
la CPU avec ID de redondance
2
Communication
14.5 Communication HMI avec le système redondant S7-1500R/H
Affichage des ressources de liaison occupées dans STEP 7

Condition : liaison en ligne au système redondant S7-1500R/H
Vous trouverez l'affichage en ligne des ressources de liaison dans la fenêtre d'inspection sous
"Diagnostic" > "Informations de liaison". STEP 7 affiche toujours les ressources de liaison de la
CPU sélectionnée et de la station S7-1500R/H.
Figure 14-6 Affichage des ressources de liaison du système redondant S7-1500R/H dans STEP 7
14.5.1 Configurer une liaison HMI via l'adresse IP système
Conditions
• Un système redondant S7-1500R/H, par ex. CPU 1513R-1PN
• Adresse IP système activée
• Appareil HMI avec interface PROFINET
Communication
Marche à suivre
Procédez comme suit pour configurer une liaison HMI à un système redondant S7-1500R/H :
1. Dans la vue du réseau de STEP 7, sélectionnez l'interface PROFINET de l'appareil HMI.
2. Tracez une ligne par glisser/déplacer entre l'interface PROFINET de l'appareil HMI et une
interface PROFINET du système redondant S7-1500R/H.
L'appareil HMI et le système redondant S7-1500R/H sont interconnectés.
Figure 14-7 Connecter un appareil HMI avec le système redondant S7-1500R/H
3. Cliquez sur le bouton "Liaisons" dans la liste de fonctions. Vous activez ainsi le mode de
liaison.
4. Tracez une ligne par glisser/déplacer entre l'appareil HMI et une CPU du système redondant
S7-1500R/H.
La liste "Partenaire de liaison" s'ouvre.
Figure 14-8 Configurer une liaison HMI au système redondant S7-1500R/H
5. Sélectionnez le système redondant S7-1500R/H dans la liste "Partenaire de liaison".

Résultat : vous avez configuré une liaison HMI entre l'appareil HMI et le système redondant
S7-1500R/H. La liaison HMI utilise l'adresse IP système. L'appareil HMI se connecte toujours à
la CPU principale.
Communication
Commuter la liaison HMI sur l'adresse IP d'appareil

Pour commuter la liaison HMI de manière fixe sur la CPU sélectionnée, désactivez la case à
cocher "Utilisez l'adresse IP système pour la communication commutée" dans les propriétés
de la liaison HMI. La liaison HMI utilise ensuite l'adresse IP d'appareil de l'interface PROFINET.
Lorsqu'une défaillance de la CPU se produit, la liaison HMI à cette CPU est également
durablement défaillante.
Figure 14-9 Propriétés de la liaison HMI
Remarque
Configuration automatique de la liaison HMI
Si vous ajoutez une variable du système redondant S7-1500R/H par glisser/déplacer dans une
vue HMI ou une table des variables HMI, STEP 7 crée automatiquement une liaison HMI. Cette
liaison HMI est établie par défaut entre l'interface PROFINET de l'appareil HMI et l'interface
PROFINET X1 de la CPU avec ID de redondance 1. La liaison utilise ensuite l'adresse IP
d'appareil de l'interface PROFINET X1.
Vous pouvez commuter la liaison HMI sur une adresse IP système dans les propriétés de la
liaison HMI.
Communication
14.6 Open User Communication avec le système redondant S7-1500R/H
14.6 Open User Communication avec le système redondant

S7-1500R/H
Le tableau suivant vous montre les protocoles de l'Open User Communication que vous
pouvez utiliser pour le système redondant S7-1500R/H ainsi que les types de données
système et les instructions correspondants.
Tableau 14- 1 Protocoles, types de données système et instructions utilisables pour l'Open User Com-
munication avec le système redondant S7-1500R/H
Protocole Type de données système Instructions

TCP • TCON_QDN Établir la liaison et envoyer/recevoir des données
avec :
• TCON_IP_v4
ISO-on-TCP • TCON_IP_RFC • TCON, TSEND/TRCV ou
• TCON, TUSEND/TURCV
TDISCON)
UDP • TCON_IP_v4 Établir la liaison et envoyer/recevoir des données
avec :
• TADDR_Param
• TSEND_C/TRCV_C
• TADDR_SEND_QDN
• TUSEND/TURCV/TRCV
• TADDR_RCV_IP
TDISCON)
Modbus TCP • TCON_IP_v4 • MB_CLIENT
• TCON_QDN • MB_RED_CLIENT
• MB_SERVER
• MB_RED_SERVER
14.6.1 Configurer la liaison de la communication Open User Communication avec

le système redondant S7-1500R/H
Introduction
Le système redondant S7-1500R/H peut communiquer avec d'autres appareils via l'Open User
Communication.
Vous configurez les liaisons dans le programme utilisateur, par ex. via l'instruction "TSEND_C".
Le système redondant S7-1500R/H ne prend pas en charge des liaisons configurées
Vous pouvez configurer des liaisons via des adresses IP d'appareil ou via les adresses IP
système des interfaces PROFINET.
Communication
Communication Open User Communication via une adresse IP système du système redondant
S7-1500R/H
Si vous configurez la liaison via une adresse IP système, la communication s'effectue toujours
via la CPU principale.
Recommandation : utilisez toujours une adresse IP système pour l'Open User Communication.
Communication Open User Communication via une adresse IP d'appareil du système redondant
S7-1500R/H
En mode redondant, le système redondant peut établir ou interrompre des liaisons et envoyer
ou recevoir des données via chaque adresse IP d'appareil.
Si vous configurez la liaison via une adresse IP d'appareil, la communication s'effectue via la
CPU correspondante. Lorsqu'une défaillance de la CPU se produit, toute la communication via
les adresses IP d'appareil de cette CPU est également défaillante.
Configurer une liaison via une adresse IP système

Ce paragraphe décrit comment configurer une liaison vers une autre CPU via une adresse IP
système d'une interface PROFINET du système redondant S7-1500R/H.
Vous configurez la liaison dans le programme utilisateur du système redondant S7-1500R/H
avec une instruction TSEND_C. Dans le programme utilisateur de l'autre CPU, vous configurez
une instruction TRCV_C correspondante.
La procédure est décrite à l'exemple d'une liaison TCP entre le système redondant S7-1500R/H
et une CPU 1516-3PN/DP.
Conditions
• Un système redondant S7-1500R/H, par ex. 2 CPU 1513-1PN
• Adresse IP système de l'interface PROFINET X1 activée
• CPU 1516-3PN/DP
• Les interfaces PROFINET X1 des CPU 1513R et l'interface PROFINET X2 de la CPU
1516-3PN/DP se trouvent dans le même sous-réseau.
Figure 14-10 Exemple de configuration de la liaison TCP
Communication
Instruction TSEND_C dans le programme utilisation du système redondant S7-1500R/H

Procédez comme suit pour configurer une liaison TCP vers une autre CPU :
1. Insérez une instruction "TSEND_C" dans le programme utilisateur.
Figure 14-11 S7-1500R/H : Instruction "TSEND_C"
2. Sélectionnez l'instruction "TSEND_C".
Communication
3. Naviguez dans la fenêtre d'inspection jusqu'à "Propriétés" > "Configuration" > "Paramètres de
la liaison".
Sur le côté gauche, vous voyez le système redondant S7-1500R/H comme nœud d'extrémité
local de la liaison :
– "Interface :" : l'interface X1 est paramétrée par défaut.
– "Sous-réseau :" : si l'interface X1 est affectée à un sous-réseau S7, STEP 7 affiche le nom
du sous-réseau S7.
– La case d'option "Utiliser l'adresse du système H" est activée. Sous "Adresse :" se trouve
l'adresse IP système du système redondant S7-1500R/H.
Figure 14-12 S7-1500R/H : paramétrage de l'instruction TSEND_C dans STEP 7
4. Sélectionnez pour "Partenaire" sous "Noeud d'extrémité :" la CPU 1516-3PN/DP comme
partenaire de communication.
5. Sélectionnez pour "Partenaire" sous "Interface :" l'interface PROFINET X2 de la CPU
1516-3PN/DP.
6. Sélectionnez pour "Local" sous "Données de liaison" le paramètre "<nouveau>".
STEP 7 crée un bloc de données dans le programme utilisateur du système redondant
S7-1500R/H pour les données de liaison, par ex. "PLC_1_Send_DB".
"TCP" est paramétré par défaut pour "Type de liaison".
7. Sélectionnez pour "Partenaire" sous "Type de liaison" le paramètre "nouveau".
STEP 7 crée un bloc de données dans le programme utilisateur de l'autre CPU pour les
données de liaison, par exemple "PLC_3_Receive_DB".
Communication
Instruction TRCV_C dans le programme utilisateur de la CPU 1516-3PN/DP

Créez dans le programme utilisateur de la CPU 1516-3PN/DP une instruction TRCV_C et
paramétrez-la comme suit :
Figure 14-13 S7-1500-3PN/DP : paramétrage de l'instruction TRCV_C dans STEP 7
Communication
Configurer une liaison via l'adresse IP d'appareil

Pour configurer une liaison OUC via une adresse IP d'appareil de l'une des deux CPU :
• Sélectionnez une interface PROFINET appropriée du système redondant S7-1500R/H.
• Désactivez la case "Utiliser l'adresse du système H".
Figure 14-14 Liaison OUC via une adresse IP d'appareil
Voir aussi
Pour plus d'informations sur les états système, reportez-vous au manuel système S7-1500R/H
Voir aussi
DESCRIPTION FONCTIONNELLE PROFINET
Communication
Industrial Ethernet Security avec CP 1543-1 15
Protection complète - Mission d'Industrial Ethernet Security
Industrial Ethernet Security permet de sécuriser des appareils individuels, des cellules
d'automatisation ou des segments d'un réseau Ethernet. En outre, la transmission de données
par la combinaison de différentes mesures de sécurité est protégée de :
• espionnage de données
• manipulation de données
• accès non autorisés
Mesures de sécurité
• Firewall
– IP-Firewall avec Stateful Packet Inspection (layer 3 et 4)
– Firewall également pour télégrammes "non IP" Ethernet selon la norme IEEE 802.3
(layer 2)
– Limitation de la largeur de bande
– Réglementation Firewall globale
Tous les nœuds de réseau situés dans un segment de réseau interne d'un CP 1543-1 sont
protégés par leur Firewall. Exception : Si vous accédez à la CPU via l'interface du CP avec la
fonction "Accès à l'API via module de communication", le pare-feu ne protège pas cette
liaison.
• Enregistrement
A des fins de surveillance, les événements sont enregistrés dans des fichiers journaux qu'il
est possible de lire à l'aide de l'outil de configuration ou bien d'envoyer automatiquement
à un serveur Syslog.
• HTTPS
Pour transmission chiffrée de pages Web, par ex. lors du contrôle de processus.
• FTPS (mode explicite)
Transmission chiffrée de fichiers.
• NTP sécurisé
Sécurisation de la synchronisation et de la transmission de l'heure.
• SNMPv3
Sécurisation de la transmission antiécoute d'informations d'analyse réseau.
Communication
Industrial Ethernet Security avec CP 1543-1
15.1 Firewall
• Groupes VPN
Vous pouvez configurer le regroupement du CP 1543-1 avec d'autres modules de sécurité
pour former des groupes VPN. Des tunnels IPsec sont établis entre tous les modules de
sécurité d'un groupe VPN (Virtual Private Network). Tous les nœuds internes de ces
modules de sécurité peuvent communiquer entre eux par ces tunnels en toute sécurité.
• Protection pour appareils et segments de réseau
Les fonctions de protection Firewall et Groupes VPN peuvent s'appliquer à des appareils
individuels, à plusieurs appareils ou à des segments entiers de réseau.

Pour une liste récapitulative des liens aux articles les plus importants sur la sécurité
industrielle, voir cette FAQ (https://support.industry.siemens.com/cs/ww/fr/view/92651441).
15.1 Firewall
Tâches du Firewall
La fonction de Firewall a pour tâche la protection des réseaux et des stations contre les
influences extérieures et les anomalies. Cela signifie que seules certaines relations de
communication définies au préalable sont autorisées.
Pour filtrer l'échange de données, il est possible d'utiliser entre autres des adresses IPv4, des
sous-réseaux IPv4, des numéros de port ou des adresses MAC.
La fonction de Firewall peut être configurée pour les niveaux de protocole suivants :
• IP-Firewall avec Stateful Packet Inspection (layer 3 et 4)
• Firewall également pour télégrammes "non IP" Ethernet selon la norme IEEE 802.3 (layer
2)
Régles du Firewall
Les règles du Firewall définissent les paquets qui sont autorisés ou interdits dans une
direction.
Communication
15.2 Enregistrement
15.2 Enregistrement
Fonctionnalité
A des fins de test et de surveillance, le module de sécurité dispose de fonctions de diagnostic
et d'enregistrement.
• Fonctions de diagnostic
Le paragraphe suivant indique différentes fonctions de système ou d'état qui peuvent être
utilisées dans le mode en ligne.
• Fonctions d'enregistrement (logging)
Il s'agit d'enregistrer des événements liés au système et à la sécurité. L'enregistrement
s'effectue selon le type d'événement dans des mémoires tampon locales volatiles ou
durables du CP 1543-1. Il est également possible qu'un enregistrement s'effectue dans un
serveur réseau.
Le paramétrage et l'analyse de ces fonctions supposent l'existence d'une connexion
réseau.
Enregistrement d'événement à l'aide des fonctions d'enregistrement (logging)

Les paramètres de réglage du journal vous permettent de définir quels sont les événements à
enregistrer. De ce fait, vous pouvez configurer les variantes suivantes pour l'enregistrement :
• Enregistrement local
Ces variantes permettent d'enregistrer les événements dans des tampons locaux du
CP 1543-1. Dans la boîte de dialogue en ligne de l'outil Security Configuration Tool, vous
pouvez ensuite accéder à ces enregistrements, les afficher et les archiver dans la station
de maintenance.
• Réseau Syslog
Pour le réseau Syslog, vous utilisez un serveur Syslog existant dans le réseau. Celui-ci
enregistre les événements selon la configuration des réglages du fichier journal.
15.3 Client NTP
Fonctionnalité
La date et l'heure sont indiquées dans le CP 1543-1, tout comme dans la CPU, pour permettre
la surveillance de la validité temporelle d'un certificat et pour l'horodatage des entrées du
journal. Cette heure est synchronisable via le protocole NTP. Le CP 1543-1 transmet l'heure
synchronisée à la CPU par le biais du bus interne du système d'automatisation. La CPU reçoit
ainsi également une heure synchronisée pour les événements temporels dans le traitement
du programme utilisateur.
La mise à l'heure automatique et l'ajustement périodique de l'heure s'effectuent à l'aide d'un
serveur NTP sécurisé ou non sécurisé. Vous pouvez affecter au maximum 4 serveurs NTP au
CP 1543-1. Une configuration mixte de serveurs NTP sécurisés ou non sécurisés n'est pas
possible.
Communication
15.4 SNMP
15.4 SNMP
Fonctionnalité
Le CP 1543-1 prend en charge, tout comme la CPU, la transmission d'informations de gestion
via le protocole SNMP (Simple Network Management Protocol). Pour ce faire, un "agent
SNMP" doit être installé sur le CP/la CPU. Cet agent doit accepter les requêtes SNMP et y
répondre. Les informations sur les propriétés des appareils capables de prendre en charge
SNMP sont enregistrées dans les fichiers MIB (Management Information Base) pour lesquels
l'utilisateur doit disposer des droits correspondants.
Pour SNMPv1, la "Community String" est également envoyée. La "Community String" est
comparable à un mot de passe qui est envoyé avec la requête SNMP. Si la Community String
est correcte, les informations demandées sont envoyées. Si elle est fausse, la requête est
rejetée.
Pour le SNMPv3, les données sont transmises chiffrées. Pour ce faire, sélectionnez soit un
procédé d'authentification, soit un procédé d'authentification et de chiffrement.
Sélection possible :
• Algorithme d'authentification : aucun, MD5, SHA-1
• Algorithme de cryptage : aucun, AES-128, DES
Vous pouvez désactiver l'utilisation de SNMP pour le CP/la CPU. Désactivez SNMP quand les
directives de sécurité en vigueur dans votre réseau n'autorisent pas de SNMP ou quand vous
utilisez votre propre solution SNMP.
Consultez le chapitre Désactivation de SNMP (Page 1) pour savoir comment désactiver SNMP
pour la CPU.
15.5 VPN
Fonctionnalité
Pour les modules de sécurité qui protègent le réseau interne, les tunnels VPN (Virtual Private
Network) offrent une liaison de données sécurisée sur le réseau externe non sécurisé.
Le module se sert du protocole IPsec (mode tunnel d'IPsec) pour utiliser le tunnel.
STEP 7 vous permet d'affecter les modules de sécurité à des groupes VPN. Des tunnels VPN
sont établis automatiquement entre tous les modules d'un groupe VPN, sachant qu'un
module dans un projet peut faire partie de différents groupes VPN parallèlement.
Communication
Glossaire
Adresse IP
Nombre binaire utilisé comme adresse univoque dans les réseaux d'ordinateurs dans le
contexte du protocole Internet (IP). Ces appareils sont ainsi adressables de manière univoque
et accessibles individuellement. Avec un masque de sous-réseau binaire, il est possible
d'évaluer une adresse IPv4 de manière à obtenir une structure avec une partie "réseau" et une
partie "hôte". La représentation textuelle d'une adresse IPv4 comporte par exemple
4 nombres décimaux compris entre 0 et 255. Ces nombres décimaux sont séparés par un
point.
Adresse MAC
Identification d'appareil internationale univoque pour tous les appareils Ethernet. L'adresse
MAC est attribuée par le fabricant et comporte 3 octets pour le code fabricant et 3 octets pour
l'identificateur d'appareil en tant que numéro d'ordre.
Adresse PROFIBUS
Identification univoque d'un abonné raccordé à PROFIBUS. L'adressage d'un abonné se fait
par transmission de son adresse PROFIBUS dans le télégramme.
Appareil
Terme générique pour :
• les systèmes d'automatisation (par ex. AP, PC),
• les systèmes de périphérie décentralisée
• les appareils de terrain (par ex. AP, PC, équipements hydrauliques ou pneumatiques) et
• les composants de réseau actifs (par ex. switches, routeurs)
• les passerelles vers PROFIBUS, AS-Interface ou autres systèmes de bus de terrain
Appareil de terrain
→ Appareil
Appareil PROFIBUS
Appareil avec au moins une interface PROFIBUS, soit électrique (par ex. RS485), soit optique
(par ex. fibre optique plastique).
Communication
Glossaire
Appareil PROFINET
Appareil qui dispose toujours d'une interface PROFINET (électrique, optique, sans fil).
Bus
Support de transmission qui relie plusieurs abonnés entre eux. Les données peuvent être
transmises par des câbles électriques ou à fibres optiques aussi bien en série qu'en parallèle.
Carte réseau Ethernet

Circuit électronique servant à relier un ordinateur à un réseau Ethernet. Il permet l'échange
de données / la communication au sein du réseau.
Certificat CA intermédiaire
Il s'agit du certificat d'une autorité de certification signé avec la clé privée d'une autorité de
certification racine.
Une telle autorité de certification intermédiaire signe des certificats d'entité finale avec sa clé
privée.
La signature de ces certificats d'entité finale est vérifiée avec la clé publique de l'autorité de
certification intermédiaire.
Les attributs "Subject" et "Issuer" du certificat CA intermédiaire ne doivent pas être
identiques : en effet, cette autorité de certification n'a pas auto-signé son certificat.
Le champ "CA" doit indiquer "True".
Certificat de base
Il s'agit du certificat d'une autorité de certification : avec sa clé privée, elle signe des certificats
d'entité finale et des certificats CA intermédiaires.
Les attributs "Subject" et "Issuer" doivent être identiques : cette autorité de certification a
auto-signé son certificat.
Le champ "CA" doit indiquer "True".
TIA Portal V14 possède un tel certificat CA racine :
Lorsque vous configurez le serveur OPC UA d'une S7-1500 dans TIA Portal, ce dernier crée un
certificat d'entité finale pour le serveur OPC UA et le signe avec sa propre clé privée.
La signature de ce certificat d'entité finale est vérifiable avec la clé publique de TIA Portal.
Cette clé est contenue dans le certificat CA racine de TIA Portal.
Certificat d'entité finale

→ Voir aussi Certificat d'appareil
Communication
Glossaire
Certificats auto-signés
Il s'agit de certificats que vous signez avec votre clé privée et que vous utilisez comme
certificats d'entité finale.
La signature de ces certificats est vérifiée avec votre clé publique.
Les attributs "Subject" et "Issuer" des certificats auto-signés doivent être identiques : en effet,
vous avez signé vous-même votre certificat.
Le champ "CA" doit indiquer "False".
Vous pouvez utiliser des certificats auto-signés comme certificat d'application pour un client
OPC UA, par exemple.
Pour apprendre à générer un certificat auto-signé avec le générateur de certificats de l'OPC
Foundation, voir ici (Page ).
Certificats CA racines
→ Voir aussi Certificat de base
Certificats d'appareil
Ce type de certificat est signé par une autorité de certification (CA).
La signature d'un certificat d'entité finale est vérifiée à l'aide de la clé publique du certificat de
l'autorité de certification.
Les attributs "Subject" et "Issuer" ne doivent pas être identiques.
"Subject" (demandeur) sera, par exemple, le nom d'un programme, comme pour le certificat
d'application OPC UA.
"Issuer" (émetteur) indique l'autorité de certification qui a signé le certificat.
Le champ "CA" doit indiquer "False".
Client
Abonné d'un réseau qui requiert un service d'un autre abonné du réseau (serveur).
CM
→ Module de communication
Communication
Glossaire
Communication commutée
En plus des adresses IP appareil attribuées aux CPU, le système redondant S7-1500R/H prend
en charge des adresses IP système :
Les adresses IP système servent à la communication avec d'autres appareils (par exemple
appareils IHM, CPU, PG/PC). Les appareils communiquent toujours via l'adresse IP système
avec la CPU principale du système redondant. Cela permet de garantir que le partenaire de
communication puisse communiquer avec la CPU de réserve (en tant que nouvelle CPU
principale) à l'état système RUN Solo après une défaillance de la CPU principale en mode
redondant.
Console de programmation
Les consoles de programmation sont, en fait, des microordinateurs centraux fonctionnant en
environnement industriel, compacts et transportables. Ils se distinguent par un équipement
matériel et logiciel spécial dédié aux automates programmables.
Contrôleur IO, contrôleur PROFINET IO

Appareil centralisé dans un réseau PROFINET, le plus souvent un automate programmable
classique ou un PC. Le contrôleur IO crée des liaisons avec des périphériques IO, échange des
données avec eux, commande et contrôle également le système.

Échange bidirectionnel de données par modules de communication à interface série entre
deux partenaires de communication et pas plus.
CP
→ Processeur de communication
CPU
Central Processing Unit - Module central du système d'automatisation S7 avec système de
commande et de calcul, mémoire, système d'exploitation et interface pour la console de
programmation.
CPU de réserve
Si le système R/H se trouvé à l'état système RUN redondant, la CPU principale commande le
processus. La CPU de réserve traite le programme utilisateur de façon synchrone et peut
assurer la conduite du processus en cas de défaillance de la CPU principale.
Communication
Glossaire
CPU principale
Si le système R/H se trouvé à l'état système RUN redondant, la CPU principale commande le
processus. La CPU de réserve traite le programme utilisateur de façon synchrone et peut
assurer la conduite du processus en cas de défaillance de la CPU principale.
Données cohérentes
Données dont les contenus forment un tout et qui ne doivent pas être séparées lors du
transfert.
Duplex
Procédé de transmission des données ; on fait une distinction entre le procédé semi-duplex et
le procédé duplex intégral.
Semi-duplex : Un canal destiné à l'échange de données en alternance est disponible (envoi et
réception en alternance respectivement dans une direction).
Duplex intégral : Deux canaux destinés à l'échange de données simultané dans les deux sens
sont disponibles (envoi et réception simultanés dans les deux sens).
Esclave
Appareil décentralisé dans un système de bus de terrain qui n'est autorisé à échanger des
données avec un maître que sur requête de celui-ci.
→ Voir aussi Esclave DP
Esclave DP
Esclave dans la périphérie décentralisée, exploité sur PROFIBUS avec le protocole
PROFIBUS DP et qui se comporte conformément à la norme EN 50170, partie 3.
→ Voir aussi Maître DP
États de fonctionnement
Les états de fonctionnement décrivent le comportement d'une CPU individuelle à n'importe
quel moment.
La CPU des systèmes standard SIMATIC disposent des états de fonctionnement STOP, MISE EN
ROUTE et RUN.
La CPU principale du système redondant S7-1500R/H dispose des états de fonctionnement
STOP, MISE EN ROUTE, RUN, RUN Syncup et RUN redondant. La CPU de réserve dispose des
états de fonctionnement STOP, SYNCUP et RUN redondant.
Communication
Glossaire
États système
Les états système du système redondant S7-1500R/H résultent des états système des CPU
principale et de réserve. La notion d'état système est une expression simplifiée qui caractérise
les états de fonctionnement simultanés des deux CPU. Le système redondant S7-1500R/H
présente les états système ARRÊT, MISE EN ROUTE, RUN Solo, SYNCUP et RUN Redondant.
Ethernet
Technologie standard internationale pour les réseaux locaux (LAN) basée sur des trames. Elle
définit des types de câble et la signalisation de la couche physique ainsi que des formats de
paquets et des protocoles pour le contrôle d'accès aux médias.
FETCH/WRITE
Services de serveur avec TCP/IP, ISO-on-TCP et ISO pour l'accès aux zones de mémoire
système des CPU S7. L'accès (fonction client) est possible à partir d'un SIMATIC S5 ou d'un
appareil d'une autre marque/d'un PC. FETCH : lecture directe de données ; WRITE : écriture
directe de données.
Freeport
Protocole ASCII librement programmable ; ici pour la transmission de données via un
couplage point à point.
FTP
File Transfer Protocol ; protocole réseau servant à la transmission de fichiers via des réseaux
IP. FTP est utilisé pour télécharger des fichiers du serveur au client ou pour les téléverser du
client au serveur. En outre, FTP permet de créer et de lire des répertoires, ainsi que de
renommer ou de supprimer des répertoires et des fichiers.
IE
→ Industrial Ethernet
IHM
Human Maschine Interface (interface Homme Machine, appareil servant à visualiser et à
commander des processus d'automatisation.
IM
→ Module d'interface
Communication
Glossaire
Industrial Ethernet
Directive relative à la mise en place d'un réseau Ethernet en environnement industriel. La
différence essentielle avec l'Ethernet standard réside dans la sollicitabilité mécanique et
l'insensibilité aux pannes des différents composants.
Instruction
La plus petite entité autonome d'un programme utilisateur, caractérisée comme partie
délimitée du programme par sa structure, sa fonction ou son utilisation prévue. L'instruction
représente une instruction de tâche pour le processeur.
Interface PROFINET
Interface d'un module compatible avec la communication (par ex. CPU, CP) comportant un ou
plusieurs ports. Une adresse MAC est déjà affectée à l'interface depuis l'usine. Cette adresse
de l'interface garantit, avec l'adresse IP et le nom d'appareil (dans la configuration
individuelle), une identification univoque de l'appareil PROFINET dans le réseau. L'interface
peut être électrique, optique ou sans fil.
Maître
Abonné actif de niveau supérieur participant à la communication/au sous-réseau PROFIBUS.
Le maître possède des droits d'accès au bus (jeton), il peut demander et envoyer des
données.
→ Voir aussi Maître DP
Maître DP
Dans PROFIBUS DP, maître de la périphérie décentralisée qui se comporte selon la norme
EN 50170, partie 3.
→ Voir aussi Esclave DP
Masque de sous-réseau IPv4

Masque binaire divisant une adresse IPv4 (sous forme de nombre binaire) en une "partie
réseau" et une "partie hôte"
Mémoire image (E/S)

C'est dans cette zone de mémoire que la CPU transfère les valeurs des modules d'entrées et
de sorties. Au début du programme cyclique, la CPU transfère la mémoire image des sorties
comme état logique aux modules de sorties. Ensuite, la CPU lit les états logiques des modules
d'entrées et les transfère dans la mémoire image des entrées. Enfin, la CPU traite le
Communication
Glossaire
Modbus RTU
Remote Terminal Unit ; protocole de communication ouvert pour interfaces série basé sur
une architecture maître/esclave.
Modbus TCP
Transmission Control Protocol ; protocole de communication ouvert pour Ethernet basé sur
une architecture maître/esclave. Les données sont transmises comme paquets TCP/IP.
Module de communication
Module exécutant des taches de communication, utilisé dans un système d'automatisation
comme extension d'interface de la CPU (par ex. PROFIBUS ) ou offrant des possibilités de
communication supplémentaires (PtP).
Module d'interface
Module du système de périphérie décentralisé. Le module d'interface relie le système de
périphérie décentralisé à la CPU par un bus de terrain (contrôleur IO/maître DP) et prépare les
données pour les modules de périphérie.
NTP
Le Network Time Protocol (NTP) est une norme de synchronisation d'horloges dans les
systèmes d'automatisation via Industrial Ethernet. NTP utilise le protocole de transport sans
liaison UDP pour l'Internet.
OPC UA
OPC Unified Automation est un protocole pour la communication entre machines, développé
par l'OPC Foundation.
Organisation des utilisateurs PROFIBUS

Comité technique qui définit et développe les standards PROFIBUS et PROFINET.
Paire torsadée
Fast Ethernet via des câbles à paires torsadées est basé sur la norme IEEE 802.3u (100 Base-
TX). Le support de transmission est un câble torsadé et blindé à 2x2 brins, dont l'impédance
caractéristique est de 100 Ohm (AWG 22). Les caractéristiques de transmission de ce câble
doivent être conformes aux spécifications de catégorie 5.
La longueur maximale de la liaison entre un terminal et un composant de réseau ne doit pas
dépasser 100 m. Les branchements sont réalisés selon la norme 100 Base-TX avec des jacks
RJ45.
Communication
Glossaire
Périphérique IO, périphérique PROFINET IO

Appareil de la périphérie décentralisée d'un réseau PROFINET qui est contrôlé et commandé
par un contrôleur IO (par ex. entrées/sorties décentralisées, îlot de vannes, convertisseurs de
fréquence, commutateurs).
PG
→ Console de programmation
PNO
→ Organisation des utilisateurs PROFIBUS
Port
Possibilité de raccordement physique pour appareils qui sont abonnés à PROFINET. Les
interfaces PROFINET disposent d'un ou de plusieurs ports.
Processeur de communication
Module pour des tâches de communication avancées couvrant des cas d'application spéciaux,
tels que dans le domaine de la sécurité des données.
PROFIBUS
Process Field Bus - norme européenne pour le bus de terrain.
PROFIBUS DP
PROFIBUS avec protocole DP qui se comporte conformément à la norme EN 50170. DP
signifie périphérie décentralisée (rapide, compatible temps réel, échange de données
cyclique). Du point de vue du programme utilisateur, la périphérie décentralisée est adressée
exactement comme la périphérie centralisée.
PROFINET
Système de communication industriel, ouvert, basé sur les composants, sur la base
d'Ethernet, pour les systèmes d'automatisation distribués. Technique de communication
promue par l'organisation des utilisateurs PROFIBUS.
Communication
Glossaire
PROFINET IO
IO signifie Input/Output (entrée/sortie) ; périphérie décentralisée (rapide, compatible temps
réel, échange de données cyclique). Du point de vue du programme utilisateur, la périphérie
décentralisée est adressée exactement comme la périphérie centralisée.
PROFINET IO, standard d'automatisation de PROFIBUS & PROFINET International basé sur
Ethernet, définit ainsi un modèle de communication, d'automatisation et d'ingénierie
commun à tous les fabricants.
PROFINET IO utilise une technique de commutation permettant à chaque abonné d'accéder
au réseau à tout moment. Ainsi, grâce à la transmission simultanée de données de plusieurs
abonnés, l'exploitation du réseau est bien plus effective. L'émission et la réception
simultanées sont rendues possibles par l'exploitation de l'Ethernet commuté en duplex
intégral.
PROFINET IO est basé sur l'Ethernet commuté en duplex intégral et une largeur de bande de
transmission de 100 Mbits/s.
Programme utilisateur
Dans SIMATIC, on fait une distinction entre le système d'exploitation de la CPU et les
programmes utilisateur. Le programme utilisateur contient toutes les instructions,
déclarations et données permettant de piloter une installation ou un processus. Le
programme utilisateur est affecté à un module programmable (CPU, FM, par ex.) et il peut
être structuré en unités plus petites.
Protocole
Protocole réglant la communication entre deux ou plusieurs partenaires de communication.
Protocole ISO
Protocole de communication pour la transmission de données orientée message ou orientée
paquet sur l'Ethernet. Ce protocole est lié de près au matériel, il est très rapide et autorise des
longueurs de données dynamiques. Le protocole ISO convient à des quantités de données
moyennes et élevées.
Protocole ISO-on-TCP
Protocole de communication compatible avec le routage S7 pour la transmission de données
orientée paquet sur l'Ethernet ; il offre un adressage de réseau. Le protocole ISO-on-TCP
convient à des quantités de données moyennes et élevées et autorise des longueurs de
données dynamiques.
PtP
Point à Point, interface et/ou protocole de transmission pour l'échange bidirectionnel de
données entre exactement deux partenaires de communication.
Communication
Glossaire
Réseau
Un réseau se compose d'un ou de plusieurs sous-réseaux interconnectés comptant un
nombre quelconque d'abonnés. Plusieurs réseaux peuvent coexister l'un à côté de l'autre.
Routage S7
Communication entre systèmes d'automatisation S7, applications S7 ou stations PC dans
différents sous-réseaux S7 via un ou plusieurs nœuds de réseau qui servent de routeurs S7.
Routeur
Nœud de réseau à identification univoque (nom et adresse) qui relie des sous-réseaux entre
eux et qui effectue le transport de données à des partenaires identifiés de façon univoque
dans le réseau.
RS232, RS422 et RS485

Standard pour interfaces série.
RTU
RTU Modbus (RTU : Remote Terminal Unit, unité de terminal distante) transmet les données
sous forme binaire ; permet un bon débit de données. Les données doivent être converties
dans un format lisible, avant de pouvoir être exploitées.
Sécurité des données

Terme générique pour toutes les mesures de protection contre
• la perte de confidentialité due à un accès non autorisé aux données
• la perte d'intégrité due à la manipulation de données
• la perte de disponibilité due à la destruction de données
Serveur
Appareil, ou plus généralement objet, pouvant fournir certains services ; le service est fourni
sur demande d'un client.
Serveur Web
Logiciel/service de communication pour l'échange de données via Internet. Le serveur Web
transmet les documents à un navigateur Web avec des protocoles de transmission normalisés
(HTTP, HTTPS). Les documents peuvent être statiques ou être regroupés dynamiquement par
le serveur Web à partir de différentes sources sur demande du navigateur Web.
Communication
Glossaire
Service SDA
Send Data with Acknowledge. SDA est un service élémentaire qui permet à un initiateur (par
ex. le maître DP) d'envoyer un message à un autre abonné et pour lequel il reçoit directement
un accusé de réception.
Service SDN
Send Data with No Acknowledge. Ce service est surtout utilisé pour envoyer des données à
plusieurs stations, il ne s'accompagne donc pas d'un acquittement. Convient pour les tâches
de synchronisation et les messages d'état.
SNMP
Simple Network Management Protocol, protocole de gestion de réseau utilisant le protocole
de transport sans liaison UDP. SNMP fonctionne de manière semblable au modèle
client/serveur. Le gestionnaire SNMP surveille les nœuds de réseau. Les agents SNMP
collectent, dans les différents nœuds de réseau, différentes informations spécifiques au
réseau et rendent ces informations accessibles et gérables sous forme structurée dans la MIB
(.Management Information Base). Avec ces informations, un système de gestion de réseau
peut effectuer un diagnostic de réseau détaillé.
Sous-réseau
Partie d'un réseau dont les paramètres doivent être synchronisés pour tous les abonnés (par
ex. pour PROFINET). Un sous-réseau englobe les composants de bus et toutes les stations
raccordées. Les sous-réseaux peuvent par exemple être couplés à un réseau à l'aide de
passerelles ou de routeurs.
Switch
Constituant de réseau pour relier plusieurs terminaux ou segments de réseau dans un réseau
local (LAN).
Synchronisation de l'heure
Possibilité de transmission d'une heure système standard d'une source individuelle à tous les
appareils dans le système de sorte que leurs horloges puissent être réglées en fonction de
l'heure standard.
Système d'automatisation
Automate programmable servant à réguler et commander des chaînes de processus dans
l'industrie des procédés et la production. Selon la tâche d'automatisation, le système
d'automatisation est constitué de différents composants et de fonctions système intégrées.
Communication
Glossaire
Système d'exploitation
Logiciel permettant l'utilisation et l'exploitation d'un ordinateur. Le système d'exploitation
gère des ressources telles que la mémoire ou les périphériques d'entrée et de sortie, et pilote
l'exécution de programmes.
Systèmes redondants
Les systèmes redondants sont caractérisés par le fait que les composants d'automatisation
importants y figurent plusieurs fois (en redondance). En cas de défaillance d'un tel
composant redondant, le contrôle du processus n'est pas interrompu.
TCP/IP
Transmission Control Protocol / Internet Protocol, protocole de réseau orienté liaison,
standard reconnu dans la monde entier pour l'échange de données dans des réseaux
hétérogènes.
Topologie arborescente
Topologie de réseau caractérisée par une structure ramifiée : Deux abonnés ou plus sont
connectés à chaque abonné.
Topologie en anneau
Tous les abonnés d'un réseau sont regroupés dans un anneau.
Topologie linéaire
Topologie de réseau caractérisée par la disposition en ligne des abonnés.
UDP
User-Datagram-Protokoll ; protocole de communication servant à la transmission rapide et
facile de données, sans acquittement. Aucun mécanisme de sécurité tel qu'il en existe avec
TCP/IP n'est disponible.
USS
Protocole Universelles serielles Schnittstellen (protocole d'interface universel série) ; définit
un procédé d'accès selon le principe maîtreesclave pour la communication via un bus série.
Communication
Index
Créer et paramétrer une liaison, 148
Communication PG, 25, 113
A Communication S7, 25, 146, 414
Couplage point à point, 25, 154
Adresse IP, adresse de secours (temporaire), 423
CP, 20
Advanced Encryption Algorithm, 44
Créer une liaison, 33
AES, 44
Liaison ISO avec CP 1543-1, 134
Attaque de l'homme du milieu, 47
par configuration, 134
Autorités de certification, 47
D
B
Demandeur, 47
BRCV, 147
Détenteur du certificat, 47
BSEND, 147
Diagnostic de liaison, 420
C E
Certificat de base, 50
E-mail, 25, 120, 142
Certificat de serveur, 244
Enregistrement, 445
Certificat d'entité finale, 50
Etablissement et interruption d'une
Certificats auto-signés, 48
communication, 145
Certificats numériques, 47
Chiffrement asymétrique, 45
Chiffrement symétrique, 44
F
Client OPC UA
Authentification, 363 FDL, 120
Certificat, 360 Fetch, 25
Notions de base, 173 Fichier d'exportation pour OPC UA, 228
CM, 20 Firewall, 445
Cohérence des données, 37, 37 FTP, 25, 120, 142, 142
Communication
Communication IHM, 116
Communication ouverte, 118 G
Communication PG, 113
GDS, 193, 197
Communication S7, 146
GET, 147
Couplage point à point, 154
Global Discovery Server (GDS), 193, 197
Etablissement et interruption, 145
Open User Communication, 118
Protocoles de communication, 119
H
Routage d'enregistrement, 404
Routage S7, 391 Handshake Protocol, 47
Communication IHM, 25, 116
Communication ouverte
Configuration d'e-mail, 142 I
Configurer FTP, 142
IM, 24
Paramétrage de la liaison, 128
Industrial Ethernet Security, 442
TCP, ISO-on-TCP, UDP, créer, 128
Interfaces de communication, 21
Communication par instruction PUT/GET
Communication
Index
Interfaces de modules de communication Instructions, 121

Couplage point à point, 23 Protocoles, 119
Interfaces de processeurs de communication, 22 OpenSSL, 187
IP Forwarding, 396
ISO, 25, 120
ISO-on-TCP, 120, 128 P
PCT, 404
Possibilités de communication
L
Vue d'ensemble, 25
Liaison Private Key, 42
Diagnostic, 420 Procédure 3964(R), 154
Instructions pour Open User Communication, 121 Processeur de communication, 20
Protocole Freeport, 154
Protocole Modbus (RTU), 154
M Protocole USS, 154
Protocoles pour Open User Communication, 119
Mesures de sécurité, 442
Public Key, 42
Enregistrement, 445
PUT, 147
Firewall, 445
NTP, 445
SNMP, 445
R
Modbus TCP, 120
Module de communication, 20 Record Protocol, 47
Module d'interface, 24 Ressources de liaison
Communication IHM, 413
Présentation, 409
N Routage d'enregistrement, 414
Routage S7, 414
NTP, 25, 445
spécifique à une station, 417
spécifiques au module, 417
utiliser, 415
O
Vue d'ensemble, 33
OPC UA RFC 5280, 42
Certificats X.509, 186 Routage d'enregistrement, 404
GDS, 193, 197 Routage S7, 391
Générateur de certificats, 186 Ressources de liaison, 414
Identifiant, 170
Introduction, 164
Liaison sécurisée, 191 S
Mécanismes de sécurité, 180
Secure Communication, 42
Modèle de couches, 191
Secure Socket Layer, 47
Namespace, 169
Sécurité des données, 442
NodeId, 169
Serveur OPC UA
Nœuds d'extrémité, 213
Adressage, 231
OpenSSL, 187
Amélioration des performances, 228
Paramètres de sécurité, 213
Authentification, 247
Signature et cryptage, 183
Création du certificat de serveur, 238
Variables API, 219
Droits de lecture et d'écriture, 219
Variables de blocs de données, 219
Fichier d'exportation XML, 228
Voie protégée, 191
Intervalle d'échantillonnage, 237
Intervalle d'émission, 236
Caractéristiques, 118
Licences Runtime, 252, 253
Communication
Index
Mise en service, 230

Nom d'application, 230
Notions de base, 211
Paramètres de sécurité, 242
Performance, 228
Personnalisation du certificat de serveur, 244
Plage d'adresses, 171
Port TCP, 233, 235
Souscription, 234
Serveur Web, 25
Ressources de liaison, 33
Signature, 48
SNMP, 25, 445
SSL, 47
Synchronisation de l'heure, 25
Syslog, 445
T
TCON, 121
TCP, 25, 120, 128
TDISCON, 121
TLS, 47
Transport Layer Security, 47
TRCV, 121
TRCV_C, 121
TSEND, 121
TSEND_C, 121
Type de données système, 122
U
UDP, 25, 120, 128
URCV, 147
USEND, 147
Utilisation de ressources de liaison, 415
W
Write, 25
X
X.509, 42
Communication

s71500 Communication Function Manual FR-FR FR-FR

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

s71500 Communication Function Manual FR-FR FR-FR

Transféré par

Droits d'auteur :

Formats disponibles

Communication

Open User Communication 6

Couplage point à point 8

Industrial Ethernet Security

Siemens AG A5E03735816-AJ Copyright © Siemens AG 2013 - 2021.

Objet de cette documentation

Connaissances de base requises

Domaine de validité de la documentation

Nouveautés dans la description fonctionnelle Communication, édition 05/2021, par rapport à

Note relative à la sécurité

Note relative à la sécurité

Siemens Industry Online Support

3.7 SNMP .............................................................................................................................. 109

9.3 Utilisation de la CPU S7-1500 comme serveur OPC UA ...................................................... 210

9.3.7.6 Diagnostiquer les abonnements ....................................................................................... 325

14 Communication avec le système redondant S7-1500R/H .................................................................. 424

Informations sur les appareils

Collections de manuels (Manual Collections)

"mySupport" - Données CAx

TIA Selection Tool

SIMATIC Automation Tool

CPU, modules de communication et processeurs de communication

① Interface PROFINET(X2) avec 1 port

Figure 2-1 Interfaces de la CPU 1516-3 PN/DP et de CPU 1512SP-1 PN

Interfaces de modules de communication

Interfaces de processeurs de communication

① Interface Industrial Ethernet

Figure 2-3 Interface Industrial Ethernet du CP 1543-1

Interfaces de modules de communication pour le couplage point à point

① Interface pour le couplage point-à-point

Interfaces de modules d'interface

① Interface PROFINET avec commutateur à 2 ports

Vue d'ensemble des possibilités de communication

Tableau 3- 1 Possibilités de communication

Possibilités de communication Fonctionnalité Via l'interface :

Possibilités de communication Fonctionnalité Via l'interface :

Possibilités de communication Fonctionnalité Via l'interface :

Informations sur le système S7-1500R/H

3.2 Protocoles de communication et numéros de port utilisés pour

Protocole Numéro de (2) Couche liai- Fonction Description

Protocole Numéro de (2) Couche liai- Fonction Description

Protocole Numéro de (2) Couche liai- Fonction Description

Protocole Numéro de (2) Couche liaison Fonction Description

Protocole Numéro de (2) Couche liaison Fonction Description

Protocole Numéro de (2) Couche liaison Fonction Description

Particularité S7-1500 MFP :

3.3 Vue d'ensemble des ressources de liaison

Ressources de liaison disponibles dans une station

Quand les ressources de liaison sont-elles affectées ?

3.4 Création d'une liaison

Création programmée de la liaison

Figure 3-1 Création programmée

Création configurée de la liaison

Figure 3-2 Création configurée

Effets sur les ressources de liaison de la CPU

Comment créer quelle liaison ?

Tableau 3- 5 Création de la liaison

Liaison Automatique- Création program- Création configu-

3.5 Cohérence des données

Figure 3-3 Transmission cohérente de données

Exemple d'une incohérence

① Taille maximale de la zone de données cohérente

Figure 3-5 Exemple : Modification des données durant la transmission