ISA95

La nécessité d'un découplage entre la planification et la réalisation des activités opérationnelles s'est avérée essentielle pour connecter deux univers de discours très différents dans l'entreprise, ceci indépendamment de l'urbanisation effective des solutions informatiques. Cette séparation est présentée sous les deux aspects des processus et des responsabilités.

La norme définit un ensemble de modèles décrivant les aspects structurels (Produit, matières, installations de production, ressources humaines) et opérationnels (capabilité, production) du système de production utilisés pour supporter les échanges d'information (B2M, Business To Manufacturing).

La norme définit un ensemble de modèles d'activités décrivant les aspects comportementaux (processus métier, activités, tâches) du système de production utilisés pour définir les besoins de support informationnel (MES/MOM, Manufacturing Execution Systems, Manufacturing Operation Management)

La norme définit des services informationnels permettant de traiter les besoins d'interaction entre solutions informatiques.

La norme supporte l'ensemble des domaines opérationnels liés à la production, incluant la maintenance, la qualité et la logistique interne.

La norme décrit une hiérarchie globale de l'entreprise issu du modèle physique ISA-88 La hiérarchie proposée ampute le modèle ISA-88 des 2 couches basses (Equipment module et Control Module) et propose des terminologies alternatives aux niveaux Process Cell et Unit pour les autres types de production (continue et discrète) et le stockage.

La norme, qui distingue à présent l'équipement en tant que ressources opérationnelle dans l'installation et l'actif mécanique référencé par la maintenance, précise que ce modèle hiérarchique décrit dans la norme correspond au premier cas, et ne propose pas de terminologie pour la hiérarchie de l'actif physique (d'où le pluriel dans le titre de cette section).

Contrairement à la norme ISA-88, qui s'articule de façon très précise aux 4 niveaux inférieurs, la norme ISA-95 n'est pas directive quant à l'organisation physique du système industriel. Il n'est d'ailleurs pas dans l'intention de la norme d'imposer la hiérarchie physique proposée : le modèle étant extensible et réductible, il n'est donc qu'un exemple possible d'organisation industrielle qui permet de discuter de l'univers du discours.

La norme propose 4 modèles pour décrire les ressources mises en œuvre dans le système de production. Elles sont limitées formellement aux 4 types suivants : Personnel, Équipement (rôle), Actif physique (matériel) et Matières.

Ces modèles, relativement semblables s'appuient sur un méta-modèle implicite pouvant être décliné pour d'autres types de ressources qui ne seraient pas correctement pris en compte par les modèles proposés. (outillage et énergie par exemple).

Tous les modèles de la norme sont organisés autour d'une structure de description d'activité opérationnelle élémentaire, le "segment" (process, product, requirement, capability...). Le segment définit les activités opérationnelles (étapes de production, de maintenance, de qualification, logistique) en leur associant simplement les ressources correspondantes et les données/paramètres associés. Au-delà des objectifs d'interopérabilité de la norme, le segment constitue l'élément de modélisation qui permet d'associer l'exécution des activités physiques réelles à leur prise en compte globale dans l'architecture du système de production.

Ce modèle permet de décrire une activité opérationnelle complète (par exemple l'élaboration d'un produit) au moyen d'une structure simple et très ouverte permettant par exemple de décrire aussi bien une spécification produit basée sur le modèle process ISA-88 qu'un mode opératoire détaillé basé sur le modèle procédural ISA-88 (bien que ceci soit mal accepté au sein des comités ISA88 et ISA95 en raison de leur focalisation respective)

Ce modèle, destiné aux échanges d'information pour la planification, permet de décrire l'état des ressources sur un horizon de temps et d'espace déterminé.

2 modèles similaires permettent de décrire les travaux à effectuer (ordres de production, de maintenance, d'analyse, de transfert...) et de rapporter leur réalisation. Structurés comme le modèle de définition, ils permettent de supporter des ordres simples faisant appel principalement au savoir-faire des exécutants pour assurer l'ensemble du travail demandé, comme des ordres complexes (make to order) pour lesquels le travail doit être décrit minutieusement.

La seconde édition publiée de cette partie a été partiellement dépouillée de son contenu normatif et n'est pas encore alignée avec les derniers développements de la norme. Elle contient :

• Une justification à caractère informatif de la conception des modèles de données de la partie 2, reposant sur la Purdue Enterprise Reference Architecture, partiellement décrite dans les sections 5 (hiérarchie fonctionnelle) et 6 (flux de données)
• La présentation de la hiérarchie physique dérivée de l'ISA-88 (section 5.3)
• Le découpage des activités opérationnelles du système de production en quatre domaines : production, qualité, maintenance et stocks (section 8.2)
• La notion de segment pour identifier les éléments d'activités gérés dans les différentes phases de leur cycle de vie : définition, aptitude à la réalisation, planification et exécution (section 8.3)
• Une explication des modèles de données (section 8.4) qui seront développés dans les parties 2 et 4. Cette section fait référence aux modèles obsolètes (typés production) de la version initiale de la norme qui ont fait place depuis à des modèles non typés applicables aux domaines opérationnels définis dans la section 8.2
• Les annexes A et B qui identifie un certain nombre d'activités non fonctionnelle, explicitement exclues du champ d'application de la norme et les normes applicable : sécurité, information, configuration, documentation, conformité réglementaire, incidents et déviations
• L'annexe C qui présente quelques facteurs opérationnels et indicateurs de performance qui sont supposés justifier l'utilisation de la norme

Cette partie contient l'essentiel des modèles de données qui constituent le cœur de la norme :

• La section 4 donne un aperçu de l'organisation des modèles de données et précise les choix de conception et description de ces modèles. Elle précise la structure de certains attributs qui ne seront pas détaillés par la suite : référence aux ressources, Hierachy scope, Value,
• Les sections 5 et 6 décrivent tous les modèles de données sous forme de diagrammes de classes UML et de tableaux d'attributs par classe.
  • La section 5 comprend les modèles communs sur lesquels s'appuie également la partie 4 : Personnel, Role base equipment, Physical asset, Material, Process segment
  • La section 6 comprend les modèles réservés aux échanges entre le domaine MOM et le domaine de la gestion : Operations definition, Operations schedule, Operations performance, Operations capability
• L'annexe A reprend dans le cadre normatif actif les modèles de données typés production de la première version de la norme, bien qu'il soit conseillé de ne pas les utiliser
• Les annexes B et C donnent des exemples d'utilisation et de mise en œuvre des modèles de données

La prochaine édition définira un modèle pour les événements permettant d'associer plusieurs modèles de données dans une transaction cohérente d'un point de vue métier. Des événements types seront proposés dans la partie 9.

Cette partie propose un découpage fonctionnel des activités de gestion des opérations de fabrication qui doivent faciliter l'intégration entre les fonctions de planification d'entreprise et de logistique, d'une part et les fonctions de contrôle de processus d'autre part.

Plus cohérent, le modèle des activités MOM de l'ISA-95 devrait remplacer les "11 fonctions du MESA[1]", modèle marketing proposé en 1997.

• La section 5 décrit le modèle générique comprenant huit activités principales
• Les sections 6 à 9 reprennent la description de ce modèle dans le contexte des quatre domaines opérationnels définis dans la partie 1 : production, maintenance, qualité et stocks

Cette partie de la norme comporte deux types d'apports : la répétition des modèles de la partie 2 pour les besoins d'intégration internes au domaine MOM qui diffèreraient de ceux qui impliquent d'autres domaines (ERP par exemple) ; de nouveaux modèles qui complètent ceux de la partie 2.

• La section 4 donne un aperçu des modèles à suivre et leurs relations avec la partie 2 et rappelle les choix de conception et description de ces modèles.
• La section 6 décrit le nouveau modèle qui permet de décrire les relations entre ressources
• La section 7 décrit le modèle Work definition qui reprend le model Operations definition de la partie 2 en le complétant avec les concepts de Master (type de travail réutilisable pour créer une nouvelle définition) et Directive pour exprimer une instance de réalisation.
• La section 7.14 introduit le nouveau modèle Workflow specification pour décrire un flux d'activité représenté par exemple en BMPN.
• La section 8 décrit le modèle Work schedule qui reprend le modèle Operations schedule avec quelques modifications : segment requirement devient Job order et un nouvel objet Job list qui consolide les Job orders au niveau d'une ressource
• Les sections 9 et 10 décrivent les modèles Work performance et Work capability similaires aux modèles de la partie 2
• La section 13 décrit le nouveau modèle Work alert pour échanger des événements d'activité opérationnelle détachés de tout contexte.

La prochaine révision inclura un modèle pour les calendriers et les enregistrements des données de production

Cette partie de la norme définit une transaction comme une séquence de dialogue entre applications mettant en jeu un ou plusieurs messages constitués de l'assemblage d'un verbe d'action avec un nom précisant l'information liée à cette action. Elle s'inspire de la spécification OAGIS[2]

• La section 4 définit les différents modèles transactionnels PULL, PUSH et PUBLISH et la structure des messages
• La section 5 définit les verbes utilisables et les modèles transactionnels associés : ACKNOWLEDGE, CANCEL, CHANGE, CONFIRM, GET, PROCESS, RESPND, SHOW, SYNC ADD/CHANGE/DELETE
• La section 6 liste tous les noms issus de modèles de la norme utilisables dans les transactions. Il peut s'agit du modèle complet ou de tout objet du modèle. Pour chaque nom, un tableau indique les verbes possibles en fonction des critères associés aux clé de sélection du nom
• L'annexe A étend la section 6 avec les noms des modèles "Production" de la version initiale de la norme
• L'annexe B donne des exemples

Cette partie du standard propose un modèle de service de messagerie MSM permettant aux applications d'envoyer et de recevoir des messages d'autres fournisseurs de services MSM quel que soit le mécanisme de communication sous-jacent, dans le cadre d'un protocole de communication application-à-application de bout en bout.

• La section 4 présente les principes de communication et notions de base exploitées par la suite
• La section 5 définit les modes d'exploitation des canaux MSM
• La section 6 définit les services MSM relatifs à la gestion des canaux, des publications, des fournisseurs et des consommateurs
• La section 7 décrit des exemples de scénarios MSM

Dans la mesure où les modèles de la norme ne proposent qu'un minimum d'attributs et de valeurs prédéfinies, de nombreux concepts doivent être réconciliés lors d l'édition et de la lecture des messages.

Cette partie de la norme propose une méthode pour l'alignement sémantique entre différentes applications, d'une façon plus simple que l'ISO 11179

• La section 4 explique le rapprochement des concepts locaux avec un concept de référence géré dans un registre dans le contexte du traitement d'un message reçu par une application
• La section 5 définit le modèle du registre qui associe chaque concept local à un concept de référence
• La section 6 définit les services du registre pour le gestion et l'exploitation des concepts de référence et locaux, des espaces de noms et des catégories de concepts

Cette partie du standard est un guide pour la spécification, la validation et la documentation des interfaces basées sur l'ISA-95, le Profile MOM. Elle suggère qu'une telle spécification doit :

• Fournir des détails métier sur les communications et les constructions de messages entre les systèmes d'entreprise, systèmes de contrôle, systèmes MOM dans le contexte du profile MOM, basés que la norme ISA-95
• Fournir les spécifications et le contexte sur l'implémentation physique du profil MOM.
• Fournir des informations sur la façon dont le profile MOM peut être utilisé comme modèle pour les futures mises en œuvre.
• Autoriser les éditeurs de logiciels et les intégrateurs à mettre en œuvre une version spécifique du profil MOM et à interagir avec d'autres systèmes compatibles similaires.

Cette partie de la norme définira des événements typiques des activités opérationnelles des systèmes industriels. Cette approche orientée processus sera intégrée dans la prochaine édition de la partie 2.

Cette approche permet de dépasser les contraintes d'expression d'un modèle particulier pour construire des messages composites orienté métiers. Par exemple, l'événement Resource defined traite les actions CRUD sur les objets Personnel class, Equipment class, Equipment, Physical asset class, Material class, Material definition, Hierarchy scope.

La norme ISA-88 avait à l'origine l'ambition de couvrir l'ensemble du contrôle et de la gestion du système de production. Le comité ISA88 ayant recadré son périmètre de contrôle des flux et transformations physiques dans l'atelier, le comité ISA95 a été créé pour reprendre le domaine de la gestion de la production et des flux physiques généraux. Les deux normes se recouvrent assez largement sur la description de l'outil de production, avec un accent plus pratique et opérationnel côté ISA-88, plus générique et tactique côté ISA-95. Les deux normes permettent de décrire les dimensions d'un système de production utile pour son développement, la redondance et la compatibilité des modèles ne faisant que renforcer la cohérence globale qui s'en dégage. Une ontologie supérieure[3] susceptible de rationaliser les concepts sémantiques des deux normes et de s'affranchir des contraintes terminologiques a été proposée.

Le groupe de travail XML du MESA (travail initié par le World Batch Forum absorbé en 2012 par MESA[4]) développe un ensemble de schémas XML nommé B2MML pour mettre en œuvre l'ensemble des modèles de la norme dans les développements basés sur cette technologie. Cette spécification inclut un sous-ensemble de structures BatchML dédié aux modèles de la norme ISA-88.

L'Open Application Group[5] est une association d'éditeurs de logiciels de gestion d'entreprise regroupant en particulier les grands éditeurs ERP. La norme ISA-95 s'est inspirée de ses travaux pour définir le modèle transactionnel de la partie 5 de la norme. L'OAG a repris certains modèles de la norme dans sa spécification de schemas XML pour l'interopérabilité autour des solutions de gestion d'entreprise.

MIMOSA[6] est une association consacrée à la gestion des actifs industriels. Les modèles de l'ISA-95 traitent les équipements et la maintenance de manière très différente de ce standard, adoptant une approche homogène pour tous les domaines opérationnels.