Services publics et code hérité adjacent au SCADA : considérations particulières pour les équipes de modernisation

Dans une entreprise de services publics, la frontière entre technologies de l'information (TI) et technologies opérationnelles (TO) ne se réduit pas à une simple ligne sur un schéma de réseau. Il s'agit plutôt d'une membrane perméable à travers laquelle les données circulent dans les deux sens : des programmes COBOL génèrent des fichiers de configuration de consigne utilisés par les automates programmables industriels (API), des programmes RPG lisent les données d'historisation SCADA pour la facturation et les rapports réglementaires, des interfaces C existantes traduisent les sorties des mainframes en formats compréhensibles par les systèmes de contrôle distribués, et des flux de travaux JCL planifient et séquencent les échanges de données de part et d'autre de cette frontière en fonction du calendrier des processus opérationnels. Le logiciel qui gère ce flux n'est ni purement TI, ni purement TO. Il constitue le tissu conjonctif qui assure le fonctionnement des entreprises de services publics, et c'est la catégorie de code que les équipes de modernisation sont le moins préparées à analyser au démarrage d'un programme de transformation.

Le secteur de l'énergie connaît actuellement l'une des transformations numériques les plus importantes de son histoire. À mesure que les entreprises de services publics modernisent leurs infrastructures grâce aux réseaux intelligents, aux sous-stations connectées, aux systèmes de contrôle industriel (ICS) et à l'automatisation avancée, les réseaux OT sont plus interconnectés que jamais. Cette interconnexion ne supprime pas la couche logicielle existante ; au contraire, elle la rend plus critique, car chaque nouveau point de terminaison de réseau intelligent et chaque plateforme d'analyse cloud dépendent de flux de données provenant d'applications développées il y a plusieurs décennies. Moderniser ces applications sans comprendre leur rôle dans la chaîne de données opérationnelles n'est pas une modernisation, mais une rupture dont les conséquences s'étendent bien au-delà du centre de données, jusqu'à l'infrastructure physique.

Que signifie réellement « adjacent à SCADA » ?

Le terme « logiciels connexes au SCADA » désigne les logiciels informatiques qui interagissent avec les systèmes de technologies opérationnelles. Il ne s'agit pas du logiciel SCADA lui-même, ni du micrologiciel de l'automate programmable, ni du code embarqué de l'unité terminale distante (RTU), mais de la couche applicative métier qui alimente ces systèmes en données et en reçoit. Cette catégorie est vaste, peu étudiée et se distingue nettement du reste du portefeuille d'applications d'entreprise.

Dans un environnement de service public typique, le code associé au système SCADA comprend :

Programmes de calcul de consigne et de seuil. Ces programmes COBOL et PL/I calculent les seuils de charge, les cibles de tension, les seuils de pression et les limites de fonctionnement, et sont transmis aux systèmes SCADA sous forme de fichiers de configuration ou de flux de données directs. Ils intègrent les exigences de conformité réglementaire, les spécifications techniques et les limites de sécurité physique. Une erreur de calcul ne se traduit pas par une valeur erronée dans un rapport, mais par un seuil de fonctionnement incorrect sur lequel le système de contrôle réagit.

Les programmes consommateurs de données d'historisation (RPG et COBOL) lisent les données opérationnelles des bases de données d'historisation SCADA à des fins de facturation, de rapports réglementaires et d'analyse des performances. Ces programmes dépendent de formats de données, de conventions d'horodatage et de définitions d'unités d'ingénierie spécifiques produits par l'historisation. Une modification du format des données de sortie de l'historisation ou du programme consommateur côté informatique peut entraîner, sans avertissement, une altération des calculs de facturation ou des déclarations réglementaires.

Programmes de passerelle de protocole. Programmes C personnalisés assurant la traduction entre les formats de sortie des systèmes centraux et les interfaces réseau ou basées sur des fichiers utilisées par les systèmes DCS (Systèmes de Contrôle Distribué) et SCADA. Ces passerelles implémentent des protocoles spécifiques (Modbus, DNP3, IEC 61850, formats propriétaires) et reposent sur des hypothèses codées en dur concernant la structure des messages, l'ordre des octets et la synchronisation, hypothèses qui ne sont documentées nulle part.

Flux de données par lots vers temps réel. Flux de tâches JCL qui planifient et séquencent les échanges de données à l'interface IT/OT selon des plages horaires spécifiques. Un traitement par lots effectué pendant la nuit par un utilitaire peut générer des données de configuration qui doivent être disponibles pour le système SCADA avant le début des opérations du matin. Cette dépendance temporelle est implicite dans la configuration du planificateur et les attentes opérationnelles de la salle de contrôle ; elle n'est documentée nulle part dans le code de l'application.

Programmes de traitement des alarmes et des événements. Ces programmes reçoivent les enregistrements d'alarmes des systèmes SCADA, appliquent une logique de classification et de routage, génèrent des ordres de travail et produisent des rapports de conformité réglementaire. La logique de classification des alarmes, qui détermine quels événements nécessitent quels rapports réglementaires et dans quels délais, est souvent intégrée au code du programme, lequel a accumulé des décennies d'évolutions réglementaires.

Il s'agit du code que les ingénieurs et les développeurs informatiques possèdent partiellement, sans le comprendre pleinement. Lorsqu'un programme de modernisation demande « que pouvons-nous changer ? », la réponse concernant le code associé au SCADA est presque toujours : « moins que vous ne le pensez, et seulement après une analyse plus approfondie que prévu. »

Pourquoi l'analyse de modernisation standard échoue ici

La plupart des cadres d'analyse de modernisation d'entreprise partent du principe que le code analysé ne contrôle que les données et la logique métier, et qu'une modification apportée à un programme produit un résultat différent au niveau des données, sans conséquence dans le monde physique. Le code associé aux systèmes SCADA remet en cause cette hypothèse de quatre manières spécifiques.

Conséquences physiques des erreurs de données

Dans une application de facturation standard, une erreur de calcul génère une facture erronée. Cette erreur est détectable, réversible et d'étendue limitée. Dans un code associé à un système SCADA, une erreur de calcul peut produire une consigne incorrecte, une valeur cible sur laquelle un système de contrôle agit en ajustant des paramètres physiques : pression, tension, débit, température. La conséquence n'est pas une erreur numérique dans une base de données. Il s'agit d'un processus physique fonctionnant en dehors de ses paramètres prévus, avec des conséquences allant de la perte d'efficacité à la détérioration des équipements, voire à des incidents de sécurité.

Cette asymétrie entre erreur de données et conséquence physique est la raison fondamentale pour laquelle le code associé aux systèmes SCADA ne peut être analysé avec la même tolérance au risque que le code métier standard. Une modification qui « fonctionne correctement » du point de vue de la production d'une sortie valide peut néanmoins produire une sortie opérationnellement incorrecte, respectant les limites légales du type de données, syntaxiquement valide, mais physiquement erronée pour le contexte opérationnel qu'elle représente.

Dépendances temporelles que l'analyse statique ne peut pas modéliser

Les programmes informatiques associés aux systèmes SCADA sont souvent soumis à des contraintes temporelles importantes pour leur fonctionnement, mais invisibles pour les outils d'analyse statique. Un programme générant des données de configuration doit s'achever avant que le cycle d'interrogation du système SCADA ne les lise. Un traitement par lots agrégeant les données d'historique doit se terminer avant l'horodatage de fin d'intervalle requis pour les rapports réglementaires. Un programme de relais d'alarmes doit traiter les événements dans le délai de réponse spécifié par les procédures opérationnelles de la salle de contrôle.

Ces contraintes de synchronisation résident dans les procédures opérationnelles du service, la configuration du planificateur et la compréhension implicite des développeurs, et non dans le code source. Les outils d'analyse statique, qui se concentrent sur la structure du code et le flux de données, ne permettent pas de visualiser les exigences de synchronisation externes au code.

Conséquence pratique : l’analyse de modernisation du code associé aux systèmes SCADA doit documenter explicitement le contexte temporel de chaque programme concerné. Cela exige une connaissance opérationnelle, des entretiens avec les opérateurs de salle de contrôle, l’examen des calendriers de conformité réglementaire et l’analyse des dépendances des tâches du planificateur, et non une simple analyse du code.

Identification des fonctions de sécurité

Les normes IEC 61511 (sécurité fonctionnelle pour les secteurs de l'industrie de transformation) et IEC 61508 (sécurité fonctionnelle des systèmes électriques, électroniques et électroniques programmables liés à la sécurité) définissent les exigences de certification des logiciels assurant des fonctions de sécurité. Un code certifié selon ces normes n'est pas un simple code existant pouvant être remanié pour des raisons de maintenance. La certification porte sur des artefacts de code spécifiques, à savoir la version précise du binaire évalué par l'organisme de certification. Toute modification du code, même pour corriger un défaut mineur qui passerait inaperçu dans une application métier, invalide la certification et requiert une nouvelle certification avant que le code modifié puisse être déployé dans une fonction de sécurité.

De nombreuses entreprises de services publics utilisent des programmes associés aux systèmes SCADA qui effectuent des calculs liés à la sécurité, la détection des surpressions, le calcul des points de consigne de protection des transformateurs et la logique d'arrêt d'urgence. Ces programmes peuvent être soumis à des exigences de certification de sécurité, parfois à l'insu de l'équipe de modernisation informatique. La première question à se poser concernant le code associé aux systèmes SCADA est la suivante : ce code remplit-il une fonction de sécurité ? Si oui, lesquelles, sous quelle certification, et quelles sont les implications d'une modification ?

Couplage matériel et protocole

Les programmes de pontage de protocole et le code d'interface embarqué dépendent directement du matériel et des versions de protocole qu'ils implémentent. Un programme qui implémente Modbus RTU avec des codes de fonction, des tables de registres et des valeurs de délai d'attente spécifiques à un modèle RTU particulier d'un fournisseur donné n'implémente pas Modbus de manière générique ; il implémente cette combinaison spécifique, avec des hypothèses qui peuvent ne pas être valides pour toute autre configuration.

Lors de l'analyse de ce code en vue de sa modernisation, la dépendance ne se limite pas au code source COBOL ou C ; elle concerne également le modèle de l'unité terminale distante (RTU), la version du firmware, la topologie du câblage physique et la configuration réseau. Toute modification de ces éléments peut perturber l'interface, même si le code source du programme reste inchangé. De plus, des modifications du code source peuvent perturber des interfaces apparemment sans lien, car le pont a été conçu pour compenser des spécificités de protocole propres au fournisseur et non documentées.

La frontière entre les technologies de l'information et les technologies opérationnelles : là où réside le code

Le modèle Purdue (ISA-99 / IEC 62443) définit l'architecture conceptuelle des réseaux de systèmes de contrôle industriels en cinq niveaux, des processus physiques au niveau 0 aux systèmes d'entreprise au niveau 4. Le code hérité adjacent au SCADA dans les environnements de services publics se trouve généralement aux niveaux 3 et 4, les zones des opérations de fabrication et du réseau d'entreprise, mais ses flux de données traversent le niveau 2 (la couche de supervision SCADA) dans les deux sens.

La frontière entre les technologies de l'information (TI) et les technologies opérationnelles (TO) de niveaux 3 et 2 présente les risques opérationnels et de sécurité les plus élevés. Des acteurs étatiques se positionnent au sein des réseaux TO des mois avant leur activation, tandis que des groupes de ransomware déploient désormais des charges utiles ciblant les systèmes de contrôle industriel (ICS) afin de bloquer les interfaces homme-machine (IHM) et d'interrompre la production. Le point d'entrée le plus fréquent n'est pas le logiciel SCADA embarqué, mais la couche frontière TI/TO, où le code côté TI et les systèmes côté TO échangent des données via des interfaces conçues pour la fiabilité opérationnelle plutôt que pour la sécurité face aux attaques.

Comprendre précisément l'ensemble des programmes qui franchissent cette limite, et leur fonctionnement à ce niveau, est indispensable à la fois pour la planification de la modernisation et l'amélioration de la sécurité. Un programme qui lit les données d'un système SCADA et les enregistre dans une base de données de facturation franchit cette limite dans un sens. Un programme qui calcule les consignes et les enregistre dans un répertoire de configuration lu par un automate programmable la franchit dans l'autre sens. Ces deux programmes sont liés au système SCADA. Ils n'apparaissent ni dans une analyse du réseau SCADA ni dans un inventaire des applications informatiques, ce qui explique leur sous-analyse systématique.

Modèles de code spécifiques aux programmes connexes aux systèmes SCADA

Code de calcul des unités d'ingénierie

Les calculs d'unités d'ingénierie (EU) convertissent les valeurs brutes des capteurs, généralement des nombres entiers issus de convertisseurs analogiques-numériques, en mesures physiques avec des unités, des plages et une précision spécifiques. Une boucle de courant 4-20 mA provenant d'un transmetteur de pression produit un nombre brut ; le calcul EU le convertit en PSI ou en bar avec l'étalonnage du zéro et de la plage approprié.

Ce code de calcul possède des caractéristiques qui le distinguent de la logique métier standard :

Cobol

       CALCULATE-PRESSURE-EU.
      *  RAW-COUNT ranges 0-4095 (12-bit ADC)
      *  SENSOR-ZERO-OFFSET = 819  (4mA = 20% of 4095)
      *  SENSOR-SPAN       = 3276  (16mA span = 80% of 4095)  
      *  RANGE-LOW-PSI     = 0
      *  RANGE-HIGH-PSI    = 500
           COMPUTE EU-PRESSURE-PSI =
               (RAW-COUNT - SENSOR-ZERO-OFFSET) /
               SENSOR-SPAN *
               (RANGE-HIGH-PSI - RANGE-LOW-PSI)
               + RANGE-LOW-PSI
           IF EU-PRESSURE-PSI < RANGE-LOW-PSI OR
              EU-PRESSURE-PSI > RANGE-HIGH-PSI
               MOVE 'RANGE-VIOLATION' TO ALARM-STATUS
               PERFORM GENERATE-ALARM
           END-IF.

Les constantes de ce calcul, SENSOR-ZERO-OFFSET, SENSOR-SPAN, RANGE-LOW-PSI, RANGE-HIGH-PSICes constantes correspondent aux spécifications physiques de l'instrument. Si elles sont codées en dur (comme c'est souvent le cas dans les anciens logiciels), toute modification de l'instrument physique nécessite une modification du code. Si elles sont erronées (suite à un réétalonnage, un remplacement ou une erreur de configuration initiale de l'instrument), la valeur EU est systématiquement incorrecte pour tous les enregistrements produits par le programme. Une analyse statique permet de localiser la définition de ces constantes ; seule une validation opérationnelle peut confirmer leur exactitude pour la configuration actuelle de l'instrument.

Logique de génération et de classification des alarmes

Le code de génération d'alarmes figure parmi les codes connexes aux systèmes SCADA les plus soumis à la réglementation dans le secteur des services publics. Les normes NERC CIP (Protection des infrastructures critiques) pour les entreprises de production d'électricité, les exigences de la NRC pour les installations nucléaires et les exigences de déclaration de l'EPA pour les services de distribution d'eau et d'assainissement précisent toutes quels événements doivent déclencher des alarmes, quelles informations ces alarmes doivent contenir et dans quels délais elles doivent être signalées.

Cobol

       CLASSIFY-ALARM.
           EVALUATE TRUE
               WHEN EU-PRESSURE-PSI > HIGH-HIGH-LIMIT
                   MOVE 'HH'   TO ALARM-PRIORITY
                   MOVE 'NERC' TO REPORTING-FLAG
                   PERFORM GENERATE-NERC-EVENT
               WHEN EU-PRESSURE-PSI > HIGH-LIMIT
                   MOVE 'HI'   TO ALARM-PRIORITY
                   MOVE 'LOG'  TO REPORTING-FLAG
               WHEN EU-PRESSURE-PSI < LOW-LIMIT
                   MOVE 'LO'   TO ALARM-PRIORITY
                   MOVE 'LOG'  TO REPORTING-FLAG
               WHEN EU-PRESSURE-PSI < LOW-LOW-LIMIT
                   MOVE 'LL'   TO ALARM-PRIORITY
                   MOVE 'NERC' TO REPORTING-FLAG
                   PERFORM GENERATE-NERC-EVENT
           END-EVALUATE.

Les limites d'alarme dans ce code, HIGH-HIGH-LIMIT, HIGH-LIMIT, LOW-LIMIT, LOW-LOW-LIMITCes paramètres opérationnels ont une importance réglementaire. Toute modification de ces limites influe à la fois sur le fonctionnement du système de contrôle et sur les obligations de déclaration réglementaire du fournisseur d'énergie. Tout programme de modernisation modifiant le code de classification des alarmes doit faire l'objet d'un examen par les services des affaires réglementaires dans le cadre de son processus de gestion des changements, et non d'une simple validation technique.

Implémentations de ponts de protocole

Les programmes de pontage de protocoles existants figurent parmi les codes SCADA les plus difficiles à moderniser, car leurs dépendances sont extrêmement complexes à identifier. Chaque programme implémente une version de protocole spécifique pour un périphérique donné, les comportements propres au fournisseur, non documentés, étant compensés dans le code.

c

/* Legacy Modbus RTU bridge -- written for Modicon 984 PLCs, circa 1998 */
/* NOTE: 984 series uses 1-based register addressing, not 0-based */
/* Function code 03 only -- 984 does not support FC 04 */
/* Max 60 registers per request -- 984 firmware limitation */

#define MODBUS_FC03_READ_HOLDING  0x03
#define MAX_REGS_PER_REQUEST      60    /* 984 firmware limit, not Modbus spec */
#define REGISTER_OFFSET           1     /* 984 uses 1-based addressing */

int read_holding_registers(int start_reg, int count, uint16_t *buffer) {
    /* Compensate for 984 1-based addressing */
    uint16_t adjusted_start = (uint16_t)(start_reg + REGISTER_OFFSET);
    
    if (count > MAX_REGS_PER_REQUEST) {
        /* 984 will return error if count exceeds 60 */
        /* Split into multiple requests silently */
        return read_registers_chunked(adjusted_start, count, buffer);
    }
    /* ... */
}

Ce code repose sur quatre hypothèses implicites concernant un modèle d'automate programmable spécifique, qui ne font pas partie de la spécification Modbus : l'adressage des registres à partir de 1, le code de fonction 03 uniquement, une limite de 60 registres et le traitement par blocs des requêtes importantes. Ces hypothèses ne figurent pas dans la documentation Modbus. Il s'agit de comportements spécifiques au Modicon 984, documentés dans un manuel matériel de 1998, aujourd'hui indisponible. Si ce pont est modernisé sans tenir compte de ces hypothèses, ou si l'automate est remplacé par un modèle plus récent utilisant un adressage standard à partir de 0, chaque lecture de registre renverra une valeur erronée, décalée d'une adresse de registre.

L’analyse prémoderne : que faut-il produire ?

Avant toute modification, refactorisation ou remplacement de code lié au SCADA, l'analyse doit produire un ensemble de livrables allant au-delà de ce que fournit une analyse standard de modernisation d'entreprise.

Inventaire des fonctions opérationnelles. Chaque programme associé à un système SCADA doit être classé selon sa fonction opérationnelle : calcul de l’UE, transmission des consignes, consommation des données historiques, génération d’alarmes, passerelle de protocole, conversion du traitement par lots en temps réel. Cette classification détermine les personnes devant participer au processus de changement : les seuls ingénieurs informatiques ou une équipe pluridisciplinaire comprenant des ingénieurs de contrôle, du personnel d’exploitation et des spécialistes de la conformité réglementaire.

Cartographie des points de passage entre les systèmes IT et OT. Chaque flux de données franchissant la frontière IT/OT doit être documenté : quel programme produit les données, dans quel format et selon quelle fréquence ; quel système OT les utilise ; et quelles sont les conséquences en cas de données incorrectes, retardées ou absentes. Cette cartographie représente le profil de risque opérationnel de la couche adjacente au SCADA.

Identification des fonctions de sécurité. Chaque programme doit être évalué afin de déterminer s'il remplit une fonction de sécurité conformément aux normes IEC 61511, IEC 61508, NERC CIP ou autres normes applicables. Les programmes identifiés comme intégrant des fonctions de sécurité nécessitent une gestion des modifications distincte, une notification réglementaire et, potentiellement, une recertification. Le calendrier de modernisation de ces programmes diffère fondamentalement de celui des programmes métiers classiques.

Registre des paramètres opérationnels codés en dur. Chaque constante codée en dur représentant un paramètre opérationnel, des valeurs d'étalonnage de capteur, des limites d'alarme, des contraintes de protocole ou des seuils de temporisation doit être identifiée, documentée avec sa signification opérationnelle et validée par rapport aux spécifications actuelles de l'instrument. Ce registre alimente le processus de gestion de la configuration qui remplace les constantes codées en dur par une configuration gérée en externe.

Documentation des dépendances temporelles. Le contexte temporel de chaque programme, les fenêtres opérationnelles durant lesquelles il doit s'exécuter, les dépendances du planificateur qui imposent ces fenêtres et les procédures opérationnelles qui dépendent de son exécution doivent être explicitement documentés. Cette documentation constitue la spécification par rapport à laquelle l'implémentation modernisée doit être validée.

Spécification du protocole et de l'interface. Chaque programme de pontage de protocole doit être analysé afin d'identifier les comportements spécifiques au fournisseur, les hypothèses de version du protocole et les compensations propres au périphérique. Le résultat est un document de spécification permettant de valider une implémentation de remplacement, en confirmant que tous les comportements compensatoires sont préservés, même ceux qui n'étaient pas présents dans la spécification d'origine.

Les approches de modernisation qui fonctionnent et celles qui ne fonctionnent pas

Le modèle de la figure étrangleuse, appliqué avec précaution. Ce modèle, qui consiste à développer de nouvelles fonctionnalités en parallèle des anciennes, à les déployer progressivement et à les mettre hors service graduellement, est adapté au code associé aux systèmes SCADA et effectuant du traitement de données côté informatique (consommateurs de données historiques, calculs de facturation). L'ancien programme continue de fonctionner pendant la transition ; la nouvelle implémentation produit des résultats parallèles dont l'équivalence est validée avant la mise hors service de l'ancien programme.

Le problème de l'étranglement (Strangler Fig) ne s'applique pas aux flux de données en temps réel. Pour les programmes exécutés sur un flux de données en temps réel, où l'exécution simultanée d'anciens et de nouveaux programmes est impossible en raison des conflits opérationnels qu'elle engendrerait, la transition doit être instantanée et validée hors ligne avant toute mise en production. L'exécution parallèle d'un programme de calcul de consigne produisant des valeurs différentes de celles du programme actuel enverrait des consignes contradictoires au système de contrôle.

Externalisation de la configuration avant toute modification du code. Pour les programmes dont les paramètres opérationnels sont codés en dur, la première étape de modernisation la plus sûre consiste à externaliser ces paramètres dans un fichier de configuration ou une base de données, sans modifier la logique de calcul. Ainsi, les paramètres deviennent visibles, gérables et auditables sans impacter le code de calcul, qui a une incidence opérationnelle. Le risque lié à l'externalisation des paramètres est nettement inférieur à celui d'une refactorisation de la logique de calcul.

Code relatif aux fonctions de sécurité : analyse et documentation, et non refactorisation. Le code certifié conforme aux normes de sécurité doit être analysé et documenté lors de la phase de planification de la modernisation, mais toute modification doit être reportée à un programme de recertification spécifique, mené en coordination avec les autorités réglementaires, et non intégrée à une initiative de modernisation générale. Le risque d’invalider une certification de sécurité lors d’une modernisation d’envergure n’est justifié par aucun avantage habituel de cette dernière.

Comment SMART TS XL Prise en charge de l'analyse du code hérité adjacent au SCADA

SMART TS XL's analyse de code statique Cela concerne le côté informatique de la zone de convergence SCADA, c'est-à-dire les programmes COBOL, JCL, RPG, PL/I et C exécutés sur les systèmes centraux et intermédiaires et qui génèrent, transforment ou utilisent des données transitant par les environnements OT. Pour ce code, l'analyse structurelle produit l'inventaire des fonctions opérationnelles et le registre des paramètres codés en dur requis par l'analyse préalable à la modernisation.

La cartographie des dépendances applicatives établit la carte des points de passage entre les environnements IT et OT : chaque programme écrivant dans une interface de fichier utilisée par un système SCADA, chaque étape de tâche JCL produisant des données critiques pour le timing opérationnel, chaque programme du flux de données de l'historiseur, de la source OT au consommateur IT. Lorsqu'un programme COBOL de facturation d'un fournisseur d'énergie lit les données de l'historiseur via un pont C intermédiaire, la carte des dépendances représente les dépendances COBOL-C et C-historiseur comme une chaîne continue, rendant ainsi l'ensemble des points de passage IT/OT visibles et non plus seulement décelables lors d'incidents opérationnels.

La capacité d'analyse d'impact est particulièrement cruciale pour le code associé aux systèmes SCADA, car elle permet d'évaluer l'impact de toute modification proposée avant sa mise en œuvre. Toute modification d'un programme de calcul d'unité opérationnelle partagé (via un copybook) avec le code de génération d'alarmes, le code de transmission des consignes et le code d'écriture de l'historique nécessite la compréhension des trois impacts secondaires avant toute intervention sur le calcul. Dans un code métier standard, une modification incorrecte génère des données erronées. Dans un code associé aux systèmes SCADA, elle génère des paramètres de fonctionnement erronés.

La capacité d'expansion du JCL révèle la structure temporelle et séquentielle de la couche batch : quels travaux s'exécutent dans quel ordre, quelles sorties de jeux de données alimentent quelles étapes suivantes et quels flux de travaux sont limités temporellement par des contraintes opérationnelles. Il s'agit de la base de données structurelles nécessaire à la documentation des dépendances temporelles requise pour la modernisation des systèmes SCADA.

La fonction de recherche d'entreprise permet de gérer à grande échelle le registre des paramètres codés en dur : retrouvez en quelques secondes chaque occurrence d'une constante d'unité d'ingénierie spécifique, chaque valeur limite d'alarme et chaque adresse de protocole codée en dur dans tous les artefacts COBOL, C, RPG et JCL de l'environnement, et ce, sur des millions de lignes de code. Pour les entreprises de services publics qui gèrent des centaines de milliers de lignes de code hérité associé à la SCADA, cette fonction de recherche fait toute la différence entre un audit manuel qui prend des mois et un inventaire automatisé qui ne prend que quelques heures.

Pour les équipes qui planifient modernisation de l'héritage des systèmes de services publics, SMART TS XL Elle fournit l'analyse structurelle côté informatique qui permet à l'équipe de modernisation de collaborer efficacement avec les ingénieurs de contrôle côté OT, lesquels comprennent le contexte opérationnel. La frontière IT/OT ne peut être franchie sans risque par les seules équipes IT ou OT ; elle ne l'est que lorsque les deux parties possèdent une connaissance structurelle précise de la composition de leurs systèmes.

Pourquoi ce code exige une attention différente

Les entreprises de services publics qui modernisent leur code existant associé à la SCADA ne se contentent pas de mettre à jour un logiciel obsolète. Elles modifient la couche logicielle qui assure l'interface entre les systèmes d'information et l'infrastructure physique. Les conséquences d'une mauvaise modernisation ne se limitent pas aux erreurs de données, aux interruptions de service ou aux pertes financières ; elles affectent également les systèmes physiques essentiels aux personnes qui dépendent de ces services publics.

Les caractéristiques qui rendent ce code unique – les conséquences physiques des erreurs de données, les dépendances temporelles invisibles à l'analyse statique, les contraintes de certification de sécurité, le couplage matériel-protocole – ne constituent pas des arguments contre sa modernisation. Au contraire, elles plaident en faveur d'une compréhension approfondie avant toute modification. Le cadre d'analyse présenté dans ce guide permet justement cette compréhension. Le programme de modernisation qui en découle est plus sûr car le périmètre des modifications est défini par des preuves et non par des suppositions, les dépendances temporelles sont documentées et non implicites, le code des fonctions de sécurité est identifié et non modifié accidentellement, et les points de passage entre les environnements IT et OT sont cartographiés et non découverts lors d'incidents opérationnels après déploiement.