Modèles de sources industrielles
Inventaires de sources, définitions de tags et d’événements, identifiants, horodatages et liens avec le contexte de production.
Construisez le chemin de données derrière le reporting de production.
GTMI construit des modèles de données, des pipelines, des stockages de reporting et des tableaux de bord pour la fabrication. Nous utilisons des accès aux sources approuvés et convenons de chaque mesure avec son responsable opérationnel.
Pour les équipes d’exploitation, d’ingénierie et de données qui planifient un reporting de production ou un pipeline d’analytique industrielle.
Saisie
Automate, SCADA, MES, historian
Modèle
Événements, tags, définitions des mesures
Mise à disposition
API et stockages de reporting
Usage
Tableaux de bord et rapports de poste
L’accès au reporting suit les approbations des systèmes sources. Les responsables opérationnels approuvent la mesure et les décisions prises à partir de celle-ci.
GTMI peut construire le pipeline de données et l’application de reporting, ou livrer une partie précise de ce travail. Le travail comprend les inventaires de sources, les modèles de tags et d’événements, le transport, le stockage, les calculs, les règles d’accès et la réalisation des tableaux de bord. Nous identifions d’abord qui ou quoi utilisera les données et ce que le rapport doit montrer. Cela détermine les sources et les interfaces nécessaires dans votre environnement de fabrication.
Inventaires de sources, définitions de tags et d’événements, identifiants, horodatages et liens avec le contexte de production.
Transport MQTT et API, modèles historian, données de séries temporelles et stockages de reporting PostgreSQL.
Vues Grafana et Power BI pour les mesures de production convenues, l’OEE, les rapports de poste et la revue opérationnelle.
Contrôles de qualité des données, accès approuvé des consommateurs, attentes d’actualisation et responsabilité de support documentée.
Le travail sur les sources peut couvrir automates, SCADA, MES, historian, ERP, qualité et saisies manuelles. GTMI documente la signification des événements, les horodatages, les identifiants, les règles de calcul et le traitement des enregistrements manquants ou corrigés. Nous revoyons les définitions des mesures avec les responsables opérationnels du client et documentons avec le modèle les contrôles de qualité des données et les responsabilités. La définition obtenue donne à ceux qui revoient la production une base cohérente pour choisir les chiffres à utiliser, comparer les postes et examiner un résultat contesté.
La livraison peut utiliser un transport MQTT ou API, des modèles historian et séries temporelles, des stockages PostgreSQL, et Grafana ou Power BI, selon l’environnement. Pour les systèmes d’exécution, la conception recourt à des interfaces en lecture seule approuvées ou à des frontières d’API et à un stockage d’analytique distinct lorsque nécessaire. GTMI met en œuvre le pipeline et les vues de reporting convenus, les contrôle par rapport aux enregistrements source et documente les responsabilités d’actualisation, d’accès et de support.
Exemple illustratif : données de fabrication fictives
Le poste d’assemblage fictif va de 22 h 00 le 3 avril à 6 h 00 le 4 avril 2030, en UTC. Une extraction par jour calendaire perd les deux premières heures. Une autre règle d’exclusion modifie à nouveau le dénominateur.
| Champ de définition | Règle de reporting |
|---|---|
| Mesure | Disponibilité : minutes de marche divisées par les minutes de production planifiées |
| Source | Événements fictifs horodatés d’arrêt et de démarrage de ligne, et planning des postes |
| Limite du poste | De 22:00 à 06:00 UTC ; le poste complet est rattaché à sa date de début |
| Exclusions | Déduire la pause planifiée de 30 minutes des minutes de production |
| Corrections | Conserver l’événement d’origine, le motif et le relecteur pour chaque correction ; marquer les rapports comme provisoires jusqu’à leur revue |
| Statut de l’échantillon | Aucun événement manquant ni correction dans ce jeu de données ; on suppose que la ligne a tourné entre les arrêts indiqués |
| Événement | Intervalle UTC | Minutes |
|---|---|---|
| 1. Arrêt non planifié | 22:40 à 23:05 | 25 |
| 2. Pause planifiée | 00:15 à 00:45 | 30 |
| 3. Arrêt non planifié | 02:10 à 02:30 | 20 |
| Vue | En marche / dénominateur | Disponibilité |
|---|---|---|
| Poste complet, pause planifiée exclue | 405 / 450 min | 90,0 % |
| Extraction calendaire, de 00:00 à 06:00 seulement | 310 / 330 min | 93,9 % |
| Poste complet, pause planifiée incluse | 405 / 480 min | 84,4 % |
Le poste complet compte 480 minutes, une pause planifiée de 30 minutes et 45 minutes d’arrêts non planifiés : 405 minutes de marche. Les écarts ci-dessus viennent de la limite de temps et de la règle d’exclusion, non d’un changement de production. Une définition convenue indique à l’équipe de revue quel chiffre utiliser. Il s’agit de la disponibilité seule, pas d’un calcul complet de l’OEE.
Commencez par un dossier d’architecture pour un besoin de reporting, ou cadrez la mise en œuvre de son pipeline et de ses vues.
Conception des sources, du modèle, du transport et de l’accès pour un besoin de reporting précis, prête pour la revue du client.
Mise en œuvre du chemin de données et des vues de reporting convenus, avec les contrôles par rapport aux sources et la passation.
Dites-nous quelle décision le rapport soutient et pourquoi les chiffres sont contestés ou difficiles à utiliser. Nous pouvons déterminer si le travail relève de la saisie à la source, de la définition de la mesure, du pipeline ou de la vue du rapport. Les rapports existants et des échantillons de sources peuvent suivre plus tard.