Siemens

L’intégration Siemens couvre deux plateformes. Siemens Building X (BPCloud) est la plateforme cloud et la voie recommandée pour les nouveaux sites — détaillée ci-dessous. Siemens Desigo CC est la plateforme héritée sur site, toujours prise en charge mais nécessitant une configuration manuelle de signaux virtuels dans le BMS ; résumée à la fin. Les deux voies ne partagent aucun prérequis.

Siemens Building X (BPCloud)

Ce que fait l’intégration

myCoreAI se connecte à un tenant Building X via son JSON:API public pour détecter les équipements et les points, lire les valeurs actuelles et historiques, et écrire des consignes numériques lorsque cela est अनुमति. La découverte mappe automatiquement les équipements, dispositifs et points de Building X vers les systèmes, composants et signaux Myrspoven.

• Style d’API : JSON:API sur HTTPS
• Authentification : Identifiants client OAuth2
• URL de base : https://api.bpcloud.siemens.com/

Identifiants requis

Par bâtiment :

Propriété	Description
ClientId	ID client OAuth2 pour le compte de service
ClientSecret	Secret client OAuth2 (à traiter comme un identifiant)
SiemensBuildingXPartitionId	UUID de partition Building X — périmètre du tenant pour tous les appels API
ExternalBuildingId	GUID d’emplacement du bâtiment dans l’API de structure Building X

Sécurité. ClientSecret est partagé uniquement via un canal sécurisé convenu d’avance (partage via gestionnaire de mots de passe ou transmission chiffrée). S’il est exposé dans un chat, un e-mail ou un ticket, le secret est réinitialisé dans Building X / Auth0 puis rediffusé.

Permissions API requises

• API de structure (lecture) : équipements, types d’équipements, emplacements, groupes de points, groupes-de-points/{id}/points
• API des opérations (lecture) : dispositifs, dispositifs/{id}/points, points/{id}, point-value-resource (actuel et historique)
• API des opérations (écriture) : POST points/{id} — uniquement lorsque myCoreAI écrit des consignes

Un accès en lecture seule suffit pour l’analyse et le reporting. L’accès en écriture n’est requis que lorsque myCoreAI optimise activement le bâtiment.

Découverte

La découverte s’exécute en deux phases déterministes. Les données brutes sont d’abord récupérées ; l’interprétation se fait dans une passe séparée. Le résultat est vérifiable et reproductible d’une exécution à l’autre.

Phase 1 — collecte d’instantané

1. Récupérer la liste des équipements et le catalogue des types d’équipements pour la partition.
2. Résoudre le périmètre d’emplacement du bâtiment et filtrer les équipements pour ce bâtiment.
3. Construire une cartographie dispositif-vers-équipement à partir de isControlledBy relations.
4. Récupérer les dispositifs dans l’emplacement du bâtiment.
5. Construire des cartes d’enrichissement des groupes de points (tags, ID d’équipement, ID de dispositif par ID de point).
6. Pour chaque dispositif, récupérer ses points et résoudre l’équipement propriétaire.

Phase 2 — attribution des signaux et des composants

1. Amorcer les composants à partir des équipements en utilisant les mappages connus des types d’équipements.
2. Convertir chaque point en signal et normaliser ses tags de groupe de points.
3. Faire correspondre le catalogue de règles (GUID de type d’équipement + tags requis/interdits) pour attribuer une position de signal et un type de composant.
4. Revenir au rattachement par défaut du composant de l’équipement lorsqu’aucune règle ne correspond.
5. Post-traitement : fusionner les doublons, dédupliquer les noms de signaux, supprimer les affectations incompatibles.

Groupes de points et stratégie de repli

Les groupes de points de Building X lient les points aux équipements de manière déterministe. Un ID de groupe de points encode le type d’entité — Equipment-{id} ou Device-{id}.

La voie privilégiée est GET /structure/partitions/{partitionId}/point-groups. Certains tenants restreignent ce point de terminaison et renvoient HTTP 403 ; l’intégration le détecte automatiquement et revient à une vérification par entité. Aucune configuration requise.

Lecture et écriture des valeurs

Les valeurs actuelles sont lues avec un repli à trois niveaux par signal :

1. Point-group endpoint (par lots — le moins de requêtes)
2. Point de terminaison batch des valeurs de points
3. Point de terminaison d’historique par point (dernière valeur, en dernier recours)

L’analyseur de valeurs gère les chaînes, les nombres, les booléens et les éléments JSON. « on »/« off » et « ouvert »/« fermé » sont normalisés en 1/0. NaN et l’infini sont rejetés.

Les valeurs historiques sont récupérées via le point-value-resource avec un intervalle de dates en UTC. La pagination est automatique.

Les écritures ne sont acceptées que pour des valeurs numériques finies.

Types d’équipements et de signaux pris en charge

Le mappage des signaux est piloté par un catalogue de règles indexé sur les GUID de type d’équipement et les tags sémantiques.

Famille d’équipements	Système Myrspoven	Exemples de positions de signaux
Unité de traitement d’air (UTA)	Ventilation	Température, pression, débit, CO₂, consignes d’air soufflé/repris
Unité terminale (VAV/CAV)	Ventilation	Commande de zone, observables de confort, position du registre
Circuit hydraulique	Chauffage	Températures de départ/retour, consignes, position de vanne, état de pompe
Refroidissement (groupe froid, tour de refroidissement)	Refroidissement	Températures du groupe froid, eau du condenseur, signaux de tour de refroidissement
Échangeur de chaleur	Chauffage / Refroidissement	Positions des vannes de départ/retour, de dérivation et d’isolement
Compteur d’énergie	Énergie	Points de consommation d’énergie
Capteurs observables	Observables	Météo, confort des pièces, CO₂, occupation

Les équipements hors de cette liste complètent quand même la découverte ; les points sans correspondance ne sont pas reliés automatiquement et peuvent nécessiter une extension de règle. Le fichier de diagnostics est le point de départ pour cette extension.

Liste de contrôle d’intégration

• Provisionner un compte de service OAuth2 (flux des identifiants client) dans le tenant Building X / Auth0.
• Accorder l’accès en lecture — et l’accès en écriture le cas échéant — à la partition concernée.
• Partager ClientId, ClientSecret, SiemensBuildingXPartitionId, et ExternalBuildingId avec Myrspoven via le canal sécurisé convenu.

Héritage : Desigo CC (sur site)

Les anciens déploiements Siemens utilisent Desigo CC sur site plutôt que Building X. Le modèle d’intégration diffère fondamentalement : au lieu d’une API cloud avec des métadonnées d’équipement structurées, myCoreAI communique via des signaux virtuels créés dans le BMS lui-même.

Cette voie est toujours prise en charge mais n’est plus recommandée pour les nouveaux sites. Les sites Desigo CC sont intégrés au cas par cas avec Myrspoven, car la disposition exacte des signaux virtuels dépend des signaux lus par rapport à ceux écrits.

Étapes générales :

1. Exécuter la découverte sur le BMS pour énumérer les signaux disponibles.
2. Sélectionner les signaux à lire et à écrire.
3. Créer les signaux virtuels requis dans le BMS (configuration manuelle unique par bâtiment).
4. Relancer la découverte pour détecter les signaux virtuels.
5. Confirmer la structure résultante dans Myrspoven.

La structure des dossiers de signaux virtuels, la gestion du watchdog et le comportement de repli sont coordonnés au cas par cas avec Myrspoven afin d’éviter de perturber le BMS en production.