Interoperabilität von Produktion und Unternehmensführung

Transkript

1 Quelle: Siemens AG Interoperabilität von Produktion und Unternehmensführung Einheitliche Terminologien, Daten- und Betriebsmodelle für das Produktionsmanagement auf Basis der Normenreihe DIN EN "Integration von Unternehmensführungs- und Leitsystemen" Eine Informationsbroschüre des DKE K 931 Systemaspekte

2 Inhalt Übersicht... 3 Gliederung... 3 Die DIN EN Einführung und Entstehung... 3 Übersicht über die Teile 1 bis Teil Teil Teil Teil Teil Implementierung Nutzen Allgemeine Aspekte Hersteller und Lieferanten Endanwender Systemintegratoren Direkte Übernahme der Ergebnisse in IT-Systeme Abkürzungsverzeichnis Zusammenfassung Literaturhinweise Stand Januar 2007 Seite 2

3 Übersicht Ziel dieser Broschüre ist es, auf kurze und verständliche Art und Weise dem Leser die Inhalte der Normenreihe DIN EN zu vermitteln, die Relevanz zur täglichen Arbeit und den daraus ableitbaren möglichen Nutzen darzustellen. Der Anwendungsbereich ist dabei gleichermaßen die Fertigungs- und Prozessindustrie. Die vorgenannte Normenreihe behandelt zentrale Aspekte der Integration bzw. Interoperabilität von Produktion, Leitsystemen und Unternehmens-EDV. Die Normenreihe basiert im Wesentlichen auf den Arbeiten der amerikanischen Normungsorganisation ISA (The Instrumentation, Systems and Automation Society) und dessen Komitee SP 95. Die Broschüre gibt einen kurzen Überblick über die Gründe für die Entwicklung dieser Normenreihe sowie über ihre wesentlichen Ziele. Gliederung Nach der Definition des Geltungsbereiches werden die einzelnen Teile der Normenreihe vorgestellt: ausgehend von allgemeinen Modellen und einer einheitlichen Terminologie (für Anlagen, Materialien, Produkte, Personal usw.) werden Daten- und Betriebsmodelle für Produktionsmanagement (Produktions- und Instandhaltungsplanung, Qualitätsmanagement, Bestandsführung) entwickelt; des Weiteren werden einige systemtechnische Aspekte der Interoperabilität bzw. der Rollen der beteiligten (IT) Systemen diskutiert. In einem eigenen Abschnitt wird kurz eine konkrete XML-Implementierung der in Teil 1 und 2 definierten Schnittstellen, die so genannte Business-to-Manufacturing Markup Language (B2MML) dargestellt. Der letzte Teil der Broschüre ist dem Nutzen der Anwendung der Normenreihe DIN EN gewidmet, unter Berücksichtigung spezifischer Aspekte von Herstellern und Lieferanten, Systemintegratoren und Endbenutzern. Für Abkürzungen und Fachtermini sei an dieser Stelle auf das Glossar ab Seite 19 verwiesen. Die DIN EN Einführung und Entstehung Die Integration von Produktion, Leit- und EDV-Systemen ist ein stets wichtiges Thema für Unternehmen, unabhängig von ihrer Größe oder der Branche, um die Konkurrenzfähigkeit am Markt zu verbessern. Warum geht es dabei? Vereinfacht ausgedrückt muss der durchgängige Austausch von Informationen zwischen den Unternehmensfunktionen wie Fertigung, Planung, Materialwirtschaft, Personal, den Leitsystemen und den EDV-Systemen inhaltlich richtig, vollständig, und zeitnah ohne Verzögerung erfolgen, ein altbekanntes, jedoch nur unvollständig gelöstes Problem. Die Normenreihe DIN EN hat das Ziel, den durchgängigen Austausch von Informationen im Unternehmen zu ermöglichen und die Integration unabhängig vom Grad der Automatisierung zu verbessern. Sie beeinflusst die Aufgaben der meisten fertigungsnahen Unternehmensbereiche. Weltweit operierende Unternehmen haben starkes Interesse an ihr, weil damit unterschiedliche EDV-Methoden vereinheitlicht und zusammengeführt werden und man nachhaltig zu robusten pflegeleichten Integrationslösungen kommen kann. Die wesentlichen Stand Januar 2007 Seite 3

4 Vorteile für den Benutzer sind: Kürzere Anlaufzeit der Einführung neuer Produkte, verbesserte Werkzeuge zur Integration, niedrigere Automatisierungskosten, bessere Möglichkeiten, um Benutzeranforderungen zu definieren, Optimierung der Supply Chain usw. Daher ist die Norm wichtig sowohl für Hersteller wie auch für Anwender und System-Integratoren. DIN EN bietet eine einheitliche Terminologie für Unternehmens-EDV und Leitsysteme sowie eine Anzahl von Konzepten und Modellen für die Integration der Unternehmensfunktionen. Die technische Lösung wird durch die einheitliche Modellierung der Schnittstellen zwischen den Unternehmensfunktionen und Leitfunktionen bestimmt. Wesentliche Konzepte dabei sind Objekt-Modellierung sowie die Modellierungssprachen UML und XML. Zur Entstehung: Die ISA arbeitet seit 1995 mit einem Team von Anbietern von Produktionssystemen, Herstellern von ERP-Software, Beratern und Endanwendern an der Entwicklung der mehrteiligen Normenreihe ISA-95 Enterprise-Control System Integration. Sie hat sie in IEC SC 65E Devices and Integration in Enterprise Systems eingebracht, wo sie von von der IEC/ISO JWG 5 (Joint Working Group) als IEC Enterprise-Control System Integration international weitergeführt wird. Dabei hat man einen beschleunigten Ablauf für die Entwicklung und Freigabe der einzelnen Entwicklungsphasen der Norm, die so genannte Fast Track Procedure gewählt, ein beschleunigtes Verfahren zur Normenerstellung. Bemerkenswert ist, dass die Arbeiten der JWG 5 von Anfang an unter aktiver Beteiligung sowohl von Herstellern von integrierten Fertigungssystemen als auch von Endanwendern und Beratern in einem Team von 30 Experten aus vielen Ländern stattfinden. Die Normenreihe ISA-95 ist als 6-teiliger Standard konzipiert, wobei sich die Teile 4 und 6 noch in der Entwurfsphase befinden. Teil 5 ist seitens der ISA freigegeben und liegt derzeit bei der IEC als als genehmigtes Arbeitsvorhaben (NP) vor. Die Normenreihe DIN EN Integration von Unternehmensführungs- und Leitsystemen, identisch zu den IEC Normen, enthält gegenwärtig drei Teile, nämlich: Teil 1: Modelle und Terminologie - (deutsche Textfassung mit einem Wörterbuch Englisch-Deutsch); Teil 2: Attribute des Objektmodells (englischer Text) Teil 3 Aktivitätsmodelle für das operative Produktionsmanagement (englischer Text) In absehbarer Zeit werden alle Normenteile mit dem Status DIN EN vorliegen, deshalb wird die Normenreihe im Folgenden auch so angesprochen Einführung IT-Systeme im industriellen Umfeld können in verschiedene funktionale Kategorien eingeteilt werden. Die Normenreihe DIN EN verwendet ein hierarchisches Unternehmensmodell mit vier Ebenen, die ursprünglich in der Purdue Enterprise Reference Architecture (PERA) [1-a] und [1-b] definiert wurden. Wie in Abb. 1 dargestellt, entspricht Ebene 4 der (strategischen und taktischen) Unternehmensführung mit Aktivitäten im Bereich Einkauf, Verkauf, Langzeit-Planung, Management von Produktionsstandorten, Logistik, Personalwesen usw. Ebene 3 enthält Aktivitäten aus den Bereichen Produktionsleitung, Qualitätsmanagement, Instandhaltung und Materialbestandsführung. Ebene 2 umfasst die Automatisierungssysteme der verschiedene Branchen: chargenorientierte oder kontinuierliche Produktion oder diskrete Fertigung. Stand Januar 2007 Seite 4

5 Business Planning and Logistics Planning, Plant Management, etc Level 4 Interfaces addressed in part 1, 2 and 5 Manufacturing Operations and Control Dispatching, Detailed Scheduling, Reliability Assurance, etc Activities addressed in part 3 and 4 Level 3 Batch Control Continuous Cont rol Discrete Control Levels 2, 1, 0 Abbildung 1: Hierarchisches Ebenenmodell entsprechend IEC Die Normenreihe DIN EN behandelt die IT-Integration von Unternehmensführung (Ebene 4) mit Automatisierungssystemen (Ebene 2). Ziel ist dabei eine möglichst vollständige und in allen Industriezweigen anwendbare Definition und Beschreibung der zwischen Leitsystem und Unternehmens-EDV angesiedelten Funktionen wie in Abb. 2 schematisch dargestellt, sowie der auszutauschenden Informationen und damit die klare Definition von Systemgrenzen (ERP MES DCS/SCADA) und Verantwortlichkeiten (welche Aktivitäten werden welcher Ebene zugeordnet?). Stand Januar 2007 Seite 5

6 Order Processing (1.0) Product Cost Accounting (8.0) Product Shipping Admin (9.0) Scheduling (2.0) PRODUCTION OPERATIONS MANAGEMENT Material and Energy Control (4.0) INVENTORY OPERATIONS MANAGEMENT Cont rol (3.0) INVENTORY OPERATIONS MANAGEMENT QUALITY OPERATIONS MANAGEMENT Product Inventory Control (7.0) Procurement (5.0) MAINTENANCE OPERATIONS MANAGEMENT Maintenance Management (10.0) Quality Assurance (6.0) Research Development and Engineering Marketing & Sales Abbildung 2: Funktionales Unternehmensmodell (Vereinfachte Darstellung aus IEC ) Unterhalb der Ebene 4 sind dabei alle Aufgaben angesiedelt, die sich auf den Betrieb der Produktionsanlage sowie die in diesem Rahmen auszuführenden Tätigkeiten, die Sicherheit der Fertigung bzw. der Prozesse, die Sicherheit und Qualität der hergestellten Produkte, Industriestandards bzgl. Produktion und Qualität (z.b. FDA, IFS, GAMP) und die Verfügbarkeit und Zuverlässigkeit der Produktion beziehen bzw. diese direkt beeinflussen. Übersicht über die Teile 1 bis 5 Teil 1 Teil 1 legt zunächst die Systemgrenzen von Leitsystemen einerseits und zur Unternehmensführung andererseits fest. Außerdem wird für die auf Ebene 3 angesiedelten Aufgaben eines Produktionsleitsystems (Manufacturing Execution Systems = MES) eine einheitliche Terminologie entwickelt und diese durch Objektmodelle funktional strukturiert. Stand Januar 2007 Seite 6

7 Business Planning and Logistics Planning, Plant Management, etc Definition Information Capability Information Schedule Information Performance Information Manufacturing Operations and Control Dispatching, Detailed Scheduling, Reliability Assurance, etc Abbildung 3: Modell für Informationsaustausch entsprechend IEC Ziel ist, wie Abb. 3 zeigt, die Kategorisierung und Strukturierung der über die Schnittstellen zwischen Ebene 3 und Ebene 4 auszutauschenden Informationen über Product Definition (Definition der Produkte mittels Spezifikation bestimmter Ressourceneigenschaften, insbesondere die hierarchische Einsatzstoffliste und Produkt- / Prozessparameter) Capability (Verfügbarkeit, Eigenschaften, Einschränkungen von Ressourcen) Schedule (Produktionsaufträge mit Anforderungen an die zu verwendenden Ressourcen) Performance (Rückmeldung über tatsächlich verwendete Ressourcen, insbesondere produzierte und verbrauchte Materialien) bezogen auf die Ressourcenmodelle für Equipment (Anlagenstruktur gemäß dem folgenden Modell in Abb. 4) Stand Januar 2007 Seite 7

8 Level 4 activities typically deal with these objects ENTERPRISE contains 1 or more SITE contains 0 or more AREA Level 3 activities typically deal with contains 0 or more these objects PROCESS CELL PRODUCTION UNIT PRODUCTION LINE STORAGE ZONE contains 1 or more UNIT UNIT WORK CELL STORAGE UNIT Equipment used in batch production Equipment used in continuous production Equipment used in repetitive or discrete production Abbildung 4: Betriebsmittel-Hierarchie entsprechend IEC Equipment used for storage or movement Personal Material (Materialnamen, Materialtypen und -klassen für Roh-, Zwischen und Fertigprodukte, Materiallose usw.) Process Segment (Prozessbeschreibung) Der Vorteil in der Einführung dieser Modelle liegt darin begründet, dass unterschiedliche Aspekte der Produktion im Wesentlichen unabhängig voneinander modelliert werden können und nur lose gekoppelt sind, so dass z.b. für verschiedene Varianten desselben Produktes (unterschiedliche Spezifikationen, d.h. Product Definitions) dasselbe Prozessmodell (Process Segment) verwendet werden kann für verschiedene Produktionsaufträge ( Schedule) dieselben Spezifikationen (Product Definition) verwendet werden können Einschränkungen bzgl. Equipment ( Capability) unabhängig von dem jeweils zu produzierenden Produkt und dem zugehörigen Plan ( Schedule) formuliert werden können Teil 2 Teil 2 beschreibt die konkreten Attribute, d.h. Dateninhalte der in Teil 1 identifizierten Objekte. Ziel von Teil 2 ist es, die Basis für konkrete Implementierungen des Objekt- und Datenmodells der zwischen Ebene 3 und Ebene 4 auszutauschenden Informationen zur Verfügung zu stellen. Die Implementierung selbst (z.b. in XML) ist nicht Aufgabe der Norm, sondern kann unabhängig davon erfolgen (z.b. mit Hilfe des Schemas B2MML, das durch das WBF festgelegt wurde). Die Datenmodelle beschreiben dabei die folgenden Aspekte der in Teil 1 identifizierten Modelle: Stand Januar 2007 Seite 8

9 den konkreten Dateninhalt mittels eindeutiger IDs, Namen, textueller Beschreibungen, konkret vorgegebene Eigenschaften wie z.b. Zustände (aus einer fest definierten Liste von möglichen Zuständen), Mengen / Werte (jeweils mit Maßeinheit) frei definierbare Eigenschafts- oder Parameterlisten (teilweise mit Maßeinheit), beispielsweise für Rezeptparameter Verwaltungsaspekte, z.b. Versionsnummern Zeitmodelle: z.b. Gültigkeitszeitraum für die Verfügbarkeit einer bestimmten Ressource, Start- und Endezeit für einen Produktionsauftrag Zugehörigkeit von Objekten zu bestimmten Klassen, z.b. Materialien zu Materialklassen wie Farbstoffe, Reinigungsmittel, Katalysatoren. Hierarchien, d.h. Referenzen innerhalb eines Objektmodells, z.b. für die oben aufgeführte Anlagenstruktur (Equipment); oder für die hierarchische Strukturierung einer Einsatzstoffliste (Bill of Material), d.h. Einsatzstoffe je Prozessabschnitt (Process Segment) Externe Referenzen auf (zu anderen Modellen gehörige) Objekte, z.b. die Verwendung einer bestimmten Resource (Equipment, Material,...) im Produktionsplan ( Schedule); oder die Anwendung einer bestimmten Prozessbeschreibung (Process Segment) zur Herstellung eines Zwischenproduktes (Product Segment) Logische, funktionale oder zeitliche Abhängigkeiten, z.b. von Prozessabschnitten (Process Segments) zur Beschreibung einer zeitlichen Abfolge oder der Wegeführung von Material durch die Produktionsanlage Teil 3 Teil 3 entwickelt zunächst ein generisches Modell für die Aktivitäten Definition Management (Spezifikations-Management) Resource Management (Ressourcen-Management) Detailed Scheduling (Feinplanung) Dispatching (Auftragsauslösung) Execution Management (Durchführungsüberwachung) Data Collection (Datenakquisition) Tracking (Verfolgen) Analysis (Analyse, Prüfungen) innerhalb der Ebene 3, welches dann auf die vier Kategorien (Produktionsaufträge, Produktionsdatenerfassung usw.) Quality (Qualitätsmanagement, Probendefinition, Analyse, Freigabe usw.) Maintenance (Instandhaltungsplanung, Instandhaltungsdaten usw.) und Inventory (Bestandsführung, Materialien) angewandt wird: Definition Management, Resource Management usw. Damit ist die funktionale Untergliederung aus Teil 1 ein Spezialfall von Teil 3 für die Kategorie. Ziel von Teil 3 ist eine durchgängige funktionale Strukturierung der Aktivitäten innerhalb der Ebene 3 sowie der zwischen den Funktionen auszutauschenden Informationen hier beispiel- Stand Januar 2007 Seite 9

10 haft in Abb. 5 gezeigt für die Kategorie Produktionsmanagement () und weiter detailliert für die Aktivität Produktionsfeinplanung (Detailed Scheduling): Definition Information Capability Information Schedule Information Response Information Detailed Schedule resource management Resource availability Detailed production scheduling Detailed Schedule e Reports on work in in progress and work completed tracking dispatching Performance analysis Product definition management data collection execution Equipment and Equipment Operational process specific Operational and process commands production rules response specific data Abbildung 5: Aktivitäten der Produktionssteuerung entsprechend IEC Die identifizierten Aktivitäten und Informationen sind dabei als rein funktionale, nicht als systemtechnische Gliederung (z.b. als Applikationen) zu verstehen. Durch die Einführung der drei neuen Kategorien Quality, Maintenance und Inventory wird die in Teil 1 definierte Schnittstelle zwischen Ebene 3 und Ebene 4 entsprechend erweitert. Teil 4 Teil 4 [1-4] beschreibt die konkreten Attribute der in Teil 3 identifizierten Aktivitäten (analog zur Vorgehensweise in Teil 2, ausgehend von Teil 1). Da in Teil 3 ein generisches Aktivitätenmodell entwickelt wurde, wird zunächst ein ebenfalls allgemein gehaltenes Objekt- und Datenmodell eingeführt, das sog. Common Work Model, das für die in Teil 3 definierten Kategorien (, Quality, Maintenance, Inventory; dafür steht der Platzhalter Work ) anwendbar ist. Das in Teil 2 entwickelte Modell erscheint wiederum als Spezialfall für die Kategorie. Stand Januar 2007 Seite 10

11 Detailed Work Schedule Detailed Work Performance Work Task relates to Made up of Work Request may relate to Made up of Work Response Work Segment relates to Work Task Segment Made up of related to What resources are needed for a specific task What resources are needed for a common task Work Order Made up of What is to be done may relate to Operations Management Made up of Work Order Response What was done What can be done for common task What can be done for a specific task What was the resource utilization for a task Work Capability Work Task Capability Capability Utilization Work Segment Capability Work Task Segment Capability Segment Capability Utilization Abbildung 6: Aktivitäten und Ressourcen entsprechend ISA Draft 5 Ziel von Teil 4 ist es zum einen, die Basis für die konkrete Implementierung für die zwischen den Ebenen 3 und 4 auszutauschenden Informationen auf die in Teil 3 neu definierten Kategorien zu erweitern, und zum anderen die zwischen den einzelnen Kategorien und Aktivitäten auszutauschenden Informationen innerhalb der Ebene 3 zur Verfügung zu stellen. Die internen Modelle der einzelnen Aktivitäten sind nicht Gegenstand der Norm. Mithilfe des Common Work Models (Allgemeines Arbeitsmodell) lässt sich z.b. wie Abb 6 und Abb. 7 zeigen, die Feinplanung von Arbeitsabläufen (Detailed Work Schedule) darstellen, d.h. die Unterteilung von Work Requests (Arbeitsanforderungen) in Work Orders (Arbeitsaufträge) während der Planung anhand der Work Segments (Arbeitsabschnitte) die entsprechende Unterteilung von Work Tasks (Arbeitsinhalte) in Work Task Segments (Arbeitsabschnitte) die Zuordnung von Ressourcen (hier: Work Centers) aus den vier genannten Kategorien zu den einzelnen Work Orders und umgekehrt die Verteilung der Work Orders auf die einzelnen Work Centers die Zusammenfassung einzelner Ressourcen und ihre Verwendung für eine Work Task Stand Januar 2007 Seite 11

12 Work centers Detailed Work Schedule Work Order Line 1 Line 2 Storage Module 1 Maintenance Team 1 Test Lab 6 Storage Module 2 Work Task: Resources required to implement a specific type of work request Work Request Time Work Task Segment: Resources required to implement a specific type of work order Abbildung 7: Detail Auftragssplanung entsprechend ISA Draft 5 Teil 5 Teil 5 behandelt abschließend weitere Aspekte der Interoperabilität zwischen Ebene 3 und 4, die in Teil 1 und 2 nicht berücksichtigt wurden. Dabei werden Transaktionsmodelle eingeführt, die beschreiben, wie Informationen über die Schnittstelle zwischen den Ebenen 3 und 4 ausgetauscht werden, welche Rollen die beteiligten Systeme dabei spielen und welche Verantwortlichkeiten sie dabei in Bezug auf ihren Datenhaushalt haben: PUSH: der Eigner der Daten sendet diese zusammen mit einer Bearbeitungsanforderung (PROCESS, CHANGE, CANCEL) an einen Empfänger, der die Anforderung zu bestätigen hat (ACKNOWLEDGE, CONFIRM) PULL: ein System sendet eine Anforderung zur Datenübermittlung (GET) an den Dateneigner, der diese dann zur Verfügung stellt (SHOW) PUBLISH: in diesem Falle übermittelt (nach einer Registrierung nicht Teil des Modells) eine Datenquelle verschiedene Daten an die Empfänger zu deren Verfügung (SYNC ADD, SYNC CHANGE, SYNC DELETE), ohne von den Empfängern eine konkrete Verarbeitung der Daten anzufordern; die Empfänger aktualisieren ihre jeweilige lokale Kopie der Daten. Die Dateninhalte selbst entsprechen den in den Teilen 1 und 2 definierten Modellen. Teil 5 spezifiziert zudem, für welche Datenmodelle aus Teil 1 welche der o.g. Transaktionsmodelle gelten bzw. welchen Einschränkungen sie unterliegen. Außerdem werden die in Teil 1 definierten Modelle in kleinere Einheiten unterteilt, die eine bzgl. einer Transaktion (PROCESS, CHANGE,...) logisch zusammengehörige Gruppe von Daten umfassen; somit können z.b. je nach Änderungshäufigkeit unterschiedliche Teile der Objektmodelle ausgetauscht werden ( Stammdaten, Laufzeitinformation ). Ziel von Teil 5 ist, diese Festlegungen aus der Verantwortung einzelner Applikationen herauszunehmen und in die Norm zu überführen und so eine bessere Interoperabilität sowie Reduzierung der Komplexität der Applikationen zu erreichen. Teil 5 verfolgt wiederum nicht Stand Januar 2007 Seite 12

13 das Ziel, eine Implementierung (z.b. in XML) zu beschreiben bzw. die Technologie oder das Protokoll (z.b. HTTP, WebServices,...) für den Datenaustausches selbst festzulegen. Das folgende Beispiel (Abb. 8) zeigt die Implementierung eines Geschäftsprozesses (Ebene 3 und 4) A) Abfragen von Informationen bzgl. der Produkt-Stammdaten ( und ) B) Abfragen von Informationen bzgl. der Anlage-Stammdaten ( und ) C) Kombination der Produkt-Stammdaten und der Anlage- (Maschinen-) Anforderung aus Ebene 4 mit den tatsächlichen Ressourcen in Ebene 3 (interne Aktivität auf Ebene 3 nicht gezeichnet) D) Abgleichen mit den tatsächlichen Produktionsmöglichkeiten ( ) in Ebene 4 E) Erstellen einer Grobplanung in Ebene 4 (interne Aktivität auf Ebene 4 nicht gezeichnet) F) Erstellen einer Feinplanung in Ebene 3 auf Basis der Grobplanung von Ebene 4 ( ) G) Ausführen und Steuerung der Produktion in Ebene 3 (interne Aktivität auf Ebene 3 und darunter nicht gezeichnet) H) Produktionsdatenaufzeichnung und auswertung in Ebene 3 (interne Aktivität auf Ebene 3 nicht gezeichnet) I) Verarbeiten der aufbereiteten Produktionsdaten in Ebene 4 ( ) J) Materialverbuchung in Ebene 4 ( ) unter zu Hilfenahme der oben definierten Transaktionen Level 4 PLM Level 4 Asset Mgt Level 4 Planning & Capacity Analysis Level 4 Inventory Mgt GET Product Definition SHOW Product Definition GET Equipment SHOW Equipment PROCESS Capability PROCESS Schedule PROCESS Performance PROCESS MaterialSubLot Level 3 Product Definition Management Level 3 Resource Mgt Level 3 Detailed Scheduling Level 3 Tracking Abbildung 8: Geschäftsprozessmodell (Beispiel) entsprechend ISA Draft 6 Implementierung Die konkrete datentechnische Umsetzung der UML-basierten Modelle wird vom World Batch Forum in Abstimmung mit ISA und IEC/ISO durchgeführt [2]. Das Ergebnis für die Teile 1, 2 und 5 sind die (frei verfügbaren) XML-Schemata der sogenannten Business-to- Manufacturing-Markup Language (= B2MML, Version 4.0). Dabei werden die in Teil 1, 2 und 5 definierten Modelle auf XML-Schemata umgesetzt (Entsprechung Modell : Schema = 1 : 1; siehe Abb. 9); außerdem werden die logischen Gruppie- Stand Januar 2007 Seite 13

14 rungen aus Teil 5 berücksichtigt. Ziel ist eine einheitliche und vollständige Spezifikation eines (offenen, erweiterbaren) Datenformates, das in üblichen IT-Systemen direkt verwendet werden kann. Modell aus Teil 1, 2 und 5 XML Modell XML-Schema Information About Equipment Classes Information About Equipment May be made up of 0..n Equipment Class 0..n 0..n Defined by Equipment Has properties of Has values for 0..n 0..n Equipment Class Property Maps to Equipment Property Information About Capability Tests Is tested by a 1..n 0..n Equipment Capability Test Specification 0..n 0..n Records the Defines a execution of procedure for obtaining a Equipment Capability Test Result Abbildung 9 Implementierung eines Geschäftsprozesses nach WBF B2MML Equipment Schema, V 4.0 Die Systemarchitektur unter Verwendung von B2MML wird i.a. wie folgt aussehen Message-orientierte Middleware Asynchrone Kommunikation zwischen ERP und MES; Message-Routing (zu unterschiedlichen Applikationen), verteilte Transaktionen zur gesicherten Kommunikation Connectoren zur Umsetzung von B2MML nach nicht-b2mml, z.b. unter Verwendung von Standardmechanismen wie XSLT, XQuery, XPath Unterstützung von Standard-Protokollen (http, WebServices,...) Stand Januar 2007 Seite 14

15 Business System B2MML business connector B2MML MES connector ISO/IEC + WBF standard: MES B2MML (XML) connector B2MML MES connector B2MML MES connector MES Factory X B2MML MES connector MES Factory Y B2MML MES connector MES Factory Z PCS Fact ory X PCS Fact ory Y PCS Factory Z Abbildung 10: Schichtenmodell mit B2MML Die Einführung von B2MML für den Datenaustausch zwischen Ebene 3 und Ebene 4 (Abb. 10) bietet dabei folgende Vorteile: Durch die Einführung eines einheitlichen Datenformates wird die Schnittstellenvielfalt reduziert und dadurch Kosten für Implementierung und Instandhaltung gesenkt. Im Gegensatz zu vielen bisher verwendeten Mechanismen (z.b. OPC, ODBC) umfasst B2MML auch semantische und kontextuelle Informationen über die Bedeutung der Daten, die Rollen der beteiligten Systeme und deren Verantwortlichkeiten. Diese Festlegungen müssen so nicht mehr in den Applikationen implementiert und gepflegt werden. Applikationen bzw. Schnittstellen müssen nicht mehr direkt auf alle anderen Kommunikationspartner (MES, ERP) abgestimmt werden, sondern können über eine Middleware voneinander entkoppelt werden, die dann die Aufgaben des Datenmappings (nicht-b2mml nach B2MML und zurück) und Routing (= welche Requests gehen an welche Systeme bzw. Applikationen?) vornimmt. Insgesamt werden die einzelnen Systeme von der Aufgabe der Daten- und Protokollumsetzung entlastet, die Einführung neuer oder der Ersatz existierender Applikationen wird deutlich erleichtert. Dies ist insbesondere dann entscheidend, wenn eine Vielzahl verschiedener Systeme (möglicherweise von unterschiedlichen Herstellern), verteilt über mehrere Produktionsstandorte zu pflegen ist. B2MML ist nur eine mögliche Implementierung. Gegenwärtig wird ebenfalls an einer Datenbankorientierten Implementierung B2MQL gearbeitet, die SQL anstelle von XML zur Darstellung der auszutauschenden Daten verwendet. Stand Januar 2007 Seite 15

16 Nutzen Wie kann diese Norm für Sie als Systemintegrator, Software-Hersteller (Lieferant) oder Software-Anwender von Nutzen sein? Allgemeine Aspekte Ein offensichtlicher Nutzen ist die allgemeingültige, einheitliche Definition von Begriffen und Terminologien. Mitarbeiter, die im kommerziellen Bereich eines Unternehmens arbeiten, sind nun in der Lage, mit den Mitarbeitern aus der Produktion und Automatisierungstechnik zu kommunizieren. Üblicherweise benützen diese beiden Personengruppen unterschiedliche Begriffe für dieselben Dinge oder belegen die gleichen Dinge mit unterschiedlichen Namen, so daß die Kommunikation mit Missverständnissen endet, die unnötige Zeitverluste und Fehler nach sich ziehen. Techniker, Bedienpersonal (Operatoren), Manager und die Geschäftsleitung können sich mit Hilfe der Norm besser verstehen. Weiterhin haben Mitarbeiter unterschiedlicher Unternehmen und Branchen eine gemeinsame Basis von Begriffen. Die Norm wurde von einer Gruppe von Experten entwickelt, die auf dem Gebiet der Integration von Unternehmensführungs- und Leitsystemen arbeiten und praktische Erfahrungen in den verschiedensten Anwendungsgebieten haben. Die Modelle und Terminologie, auf die sie sich geeinigt haben, stellen sicherlich auch für Ihr Unternehmen eine passende Lösung dar, so dass es keinen Grund geben sollte, das Rad neu zu erfinden. Hersteller und Lieferanten Für einen Hersteller von Unternehmensplanungssystemen (ERP) und von Produktionssteuerungs- und Überwachungssystemen (Manufacturing Operations/Execution Systems MOS/MES) gibt es viele Festlegungen in der DIN EN 62264, die er bei der Entwicklung, Vermarktung und dem Verkauf von Produkten in Betracht ziehen und davon unmittelbar profitieren kann. Die DIN EN vermittelt sowohl ein gutes Verständnis für die Thematik der Integration von Unternehmensplanungs- und -steuerungssysteme als auch für das Gebiet der Produktionssteuerungs- und Überwachungssysteme. Es stellt daher eine gute Wissensbasis für jeden Entwickler, Systemarchitekten aber auch Produktmanager dar. Die Norm bietet eine gute Basis, auf der die notwendigen Produktgespräche aufgebaut werden können. Hersteller haben Vorteile, wenn sie der in Teil 1 der Normenreihe definierten Terminologie folgen. Jede an der Entwicklung beteiligte Person sollte uneingeschränkten Zugang zu der Beschreibung von denjenigen Begriffen haben, von denen sie in ihrer Entwicklungsarbeit an einem Produkt betroffen sind. Ergebnis ist die konsistente Verwendung von Begriffen innerhalb eines Produktes. Die meisten MOS/MES Produkte und ERP-Systeme haben das Betriebsmodell fest eingebaut. Im ersten Teil der Normenreihe ist ein Geräte- und Anlagenmodell definiert, das es gestattet, die Objekte einer Fabrik zu beschreiben. Falls objektorientierte Programmiertechniken zur Anwendung kommen, können die Anlagenobjekte in der Stand Januar 2007 Seite 16

17 Anlagenhierarchie direkt als Klassen verwendet werden, von denen Unterklassen (subclasses) abgeleitet werden können. Es ist nicht die Absicht der Norm, vorzuschreiben, wie ein Produkt entworfen werden soll. Jedoch stellt Teil 3 eine eindeutige Referenz dar, wenn es in einer Diskussion um die Festlegung geht, welche Funktionen durch ein MES/MOS-Produkt abgedeckt werden. Aktivitäten, wie z.b. Reihenfolgeplanung oder Datenakquisition mögen von einem MES/MOS-Produkt nicht abgedeckt sein, sind jedoch in einem anderen Produkt des gleichen Systemanbieters enthalten. Der Teil 2 beschreibt die Objektmodelle und die damit verbundenen Attribute. Diese Modelle können z.b. in der Datenbank eines Produktes verwendet werden. Dies erleichtert es, eine DIN EN kompatible Schnittstelle bereitzustellen und/oder die B2MML-Schemata zu unterstützen. Im Teil 2 gibt es einen Abschnitt, der der Übereinstimmung (Kompatibilität, d. h. Entsprechung, Vollständigkeit) gewidmet ist. Endanwender Sowohl beim Kauf als auch bei der Bewertung und dem Einsatz eines MES/MOS-Produktes kann der Endanwender folgenden Nutzen ziehen. Automatisierungsprojekte haben heute oft die Integration einer Organisations- Software mit einem System der Produktionsführung zum Gegenstand. Eine wichtige Aufgabe ist dann die Identifikation und Definition der Ziele, welche Aufgaben/Abläufe zwischen Unternehmens- und Produktionsebene automatisiert werden sollen. Die Abläufe, Aktivitäten und Aufgaben mögen zunächst weder identifiziert, definiert oder sogar verstanden sein. Das funktionale Unternehmensmodell der DIN EN (siehe Abb. 2) kann und sollte als Ausgangspunkt gewählt werden, um die betroffenen Funktionen und Datenflüsse zu identifizieren. Produkte unterschiedlicher Hersteller lassen sich durch den Endbenutzer besser vergleichen. Hersteller stellen die Funktionen und Eigenschaften ihrer Produkte auf unterschiedliche Art und Weise dar. Um eine gute Vergleichs- und Bewertungsbasis für unterschiedliche Produkte zu erhalten liegt es nahe, die DIN EN als Universalsprache zu verwenden. D.h., die Darstellungen der Hersteller in die DIN EN Terminologie zu übertragen und dann erst zu vergleichen. Für jede in dem funktionalen Unternehmensmodell dargestellte Funktion (siehe Abb.2) gibt es eine Liste von Unterfunktionen. Ein Endbenutzer kann insofern direkt davon profitieren, als er seine potentiellen Lieferanten auffordern kann, genau aufzuführen, welche der Unterfunktionen abgedeckt, in welchen Produkt sie enthalten und wie diese Funktionen in der Sprache des Lieferanten benannt sind. Systemintegratoren Systemintegratoren sind dann betroffen, wenn es um die Auswahl und Implementierung einer Lösung geht. Um die richtige Auswahl zu treffen, ist ein gutes Verständnis notwendig, welche Stand Januar 2007 Seite 17

18 Funktionen benötigt werden und was von diesen Funktionen erwartet wird. Systemintegratoren müssen daher die Spezifikationen ihrer Kunden genau analysieren. Die Norm kann dazu beitragen, die Aufgabenstellung zu strukturieren, um so zur erfolgreichen Auswahl eines MES/MOS-Produktes beizutragen. Eine der Aufgaben ist die Festlegung, ob eine bestimmte Funktion zur Produktions-, Unternehmens- oder zu beiden Ebenen gehört. Das funktionale Unternehmensmodell (Abb. 2) kann als Richtlinie verwendet werden, wo welche Funktionen angesiedelt sind. Falls ein Systemintegrator mit Anforderungen aus der Produktionsführungsebene befasst sein sollte, dann ist insbesondere der Teil 3 wichtig für ihn. Sie können beispielsweise als zur Produktion, der Instandhaltung, dem Qualitätswesen oder dem Inventar zugehörig klassifiziert werden. Häufig bearbeiten Systemintegratoren Anforderungen, die Vorgänge der Produktion, Instandhaltung, Qualitätssicherung oder Bestandsfortschreibung beschreiben und anhand der Aktivitäten des Betriebsmodells klassifiziert und behandelt werden können, z.b. Feinplanung, Auftragsauslösung, Datenerfassung usw. (siehe Abb. 7, Produktionsbetriebsmodell). Falls die Anforderungen (Lasten- oder Pflichtenheft) vollständig nach DIN EN klassifiziert und verstanden sind, fällt dem Integrator die Entscheidung wesentlich leichter, ob sie zusammengeführt und so von nur einem Produkt abgedeckt werden können, oder ob die Implementierung besser mit unterschiedlichen Produkten erfolgt. Eine Lösungsauswahl wird dadurch leichter. Auch die Diskussion mit unterschiedlichen Lieferanten vereinfacht sich, wenn alle Beteiligten bzgl. Anforderungen und deren Kontext dasselbe Verständnis haben. Direkte Übernahme der Ergebnisse in IT-Systeme Wie bereits erwähnt, wird die konkrete datentechnische Umsetzung der UML-basierten Modelle vom World Batch Forum in Abstimmung mit ISA und IEC/ISO durchgeführt. Das Ergebnis für die Teile 1, 2 und 5 sind die (frei verfügbaren) XML-Schemata der sogenannten Business-to-Manufacturing-Markup Language (= B2MML, Version 4.0); die Umsetzung von Teil 5 wird ebenfalls durch das WBF bearbeitet. Ziel ist eine einheitliche und vollständige Spezifikation eines (offenen, erweiterbaren) Datenformates, das in üblichen IT-Systemen direkt verwendet werden kann. Über die Vorteile, die B2MML für den Datenaustausch zwischen Ebene 3 und Ebene 4 wurde bereits unter Implementierung berichtet. Stand Januar 2007 Seite 18

19 Abkürzungsverzeichnis ERP IEC DKE DIN ISA Enterprise Resource Planning Der Begriff Enterprise Resource Planning (ERP, auf deutsch in etwa Planung [des Einsatzes/der Verwendung] der Unternehmensressourcen ) bezeichnet die unternehmerische Aufgabe, die in einem Unternehmen vorhandenen Ressourcen (wie zum Beispiel Kapital, Betriebsmittel oder Personal) möglichst effizient für den betrieblichen Ablauf einzuplanen. Der ERP-Prozess wird in Unternehmen heute häufig durch Software-ERP-Systeme unterstützt. (aus Wikipedia) International Electrotechnical Commission Die Internationale Elektrotechnische Kommission (IEC) ist die führende weltweite Organisation, die Internationale Normen für alle Gebiete der Elektrotechnik, Elektronik und verwandter Gebiete erarbeitet und veröffentlicht Die DKE (Deutsch Kommission Elektrotechnik Elektronik Informationstechnik im DIN und VDE) ist die nationale Organisation für die Erarbeitung von Normen und Sicherheitsbestimmungen in dem Bereich der Elektrotechnik, Elektronik und Informationstechnik in Deutschland; ein Organ des DIN Deutsches Institut für Normung e. V. und des VDE VERBAND DER ELEKTROTECHNIK ELEKTRONIK INFORMATIONSTECHNIK e. V.; sie wird vom VDE getragen; das deutsche Mitglied in der IEC Internationale Elektrotechnische Kommission, Genf, und im CENELEC Europäisches Komitee für elektrotechnische Normung, Brüssel; die für Deutschland zuständige Nationale Normungsorganisation (NSO) des ETSI Europäisches Institut für Telekommunikationsnormen, Sophia Antipolis. Das DIN ist ein eingetragener, gemeinnütziger Verein mit Sitz in Berlin (DIN Deutsches Institut für Normung e. V., gegründet 1917). Das DIN ist die für die Normungsarbeit zuständige Institution in Deutschland und vertritt die deutschen Interessen in den weltweiten und europäischen Normungsorganisationen. Dieser Status wurde im Vertrag mit der Bundesrepublik Deutschland am 5. Juni 1975 anerkannt. Instrumentation, Systems and Automation Society Stand Januar 2007 Seite 19

20 ISO MES MOS PERA UML WBF XML International Organization for Standardization Die Internationale Organisation für Normung (ISO) ist die internationale Vereinigung von Normungsorganisationen und erarbeitet internationale Normen in allen Bereichen mit Ausnahme der Elektrik und der Elektronik, für die die IEC zuständig ist. (aus Wikipedia) Manufacturing Execution System Englisch für Produktionsleitsystem. Der Begriff Produktionsleitsystem wird im deutschen Sprachgebrauch sehr branchenspezifisch verwendet. Grundsätzlich kann man zwischen Fertigungsleittechnik (Stückgutproduktion) und der Verfahrensleittechnik (prozesstechnische Produktion) unterscheiden. Je nach Sichtweise werden auch andere Bezeichnungen bevorzugt. (aus Wikipedia) Manufacturing Operations System Purdue Enterprise Reference Architecture Unified Modeling Language Die Unified Modeling Language (UML) ist eine von der Object Management Group (OMG) entwickelte und standardisierte Sprache für die Modellierung von Software und anderen Systemen. Im Sinne einer Sprache definiert die UML dabei Bezeichner für die meisten Begriffe, die für die Modellierung wichtig sind, und legt mögliche Beziehungen zwischen diesen Begriffen fest. Die UML definiert weiter grafische Notationen für diese Begriffe und für Modelle von statischen Strukturen und von dynamischen Abläufen, die man mit diesen Begriffen formulieren kann. Die UML ist heute eine der dominierenden Sprachen für die Modellierung von betrieblichen Anwendungssystemen (Softwaresystemen). (aus Wikipedia) World Batch Forum Extensible Markup Language Die Extensible Markup Language (engl. für erweiterbare Auszeichnungs-Sprache ), abgekürzt XML, ist ein Standard zur Erstellung maschinen- und menschenlesbarer Dokumente in Form einer Baumstruktur, der vom World Wide Web Consortium (W3C) definiert wird. XML definiert dabei die Regeln für den Aufbau solcher Dokumente. Für einen konkreten Anwendungsfall ("XML-Anwendung") müssen die Details der jeweiligen Dokumente spezifiziert werden. Dies be- Stand Januar 2007 Seite 20

21 trifft insbesondere die Festlegung der Strukturelemente und ihre Anordnung innerhalb des Dokumentenbaums. XML ist damit ein Standard zur Definition von beliebigen in ihrer Grundstruktur jedoch stark verwandten Auszeichnungssprachen. Eine Sprache wie XML zur Definition anderer Sprachen nennt man Metasprache. XML ist eine vereinfachte Teilmenge von SGML. (aus Wikipedia) XSLT XSL Transformation XSLT steht für XSL Transformations und ist Teil der Extensible Stylesheet Language (XSL). XSLT ist eine Programmiersprache zur Transformation von XML- Dokumenten. Es baut auf der logischen Baumstruktur eines XML- Dokumentes auf und erlaubt die Definition von Umwandlungsregeln. XSLT-Programme, sogenannte XSLT-Stylesheets, sind dabei ebenfalls nach den Regeln des XML-Standards aufgebaut. (aus Wikipedia) XPath Die XML Path Language (XPath) ist eine vom W3C-Konsortium entwickelte Anfragesprache, um Teile eines XML-Dokumentes zu adressieren. XPath dient als Grundlage einer Reihe weiterer Standards wie XSLT, XPointer und XQuery. Die aktuelle Version ist XPath 1.0, während der Nachfolger XPath 2.0 noch nicht als Empfehlung standardisiert ist. (aus Wikipedia) XQuery XQuery steht für XML Query Language und bezeichnet eine vom W3C spezifizierte Abfragesprache für XML-Datenbanken. XQuery benutzt eine an XSLT, SQL und C angelehnte Syntax und verwendet XPath sowie XML Schema für sein Datenmodell und seine Funktionsbibliothek. XQuery ist aus den Sprachen XQL, XML-QL und Quilt hervorgegangen. (aus Wikipedia) Stand Januar 2007 Seite 21

22 Zusammenfassung Dieser Beitrag beschreibt in Kurzform die Inhalte der Normenreihe DIN EN die Integration von Unternehmens- und Produktionssystemen sowie die Vorteile, aus denen die genannten Anwenderkreise bei ihren Tätigkeiten Nutzen ziehen können. Hersteller: Entwurf und Strukturierung eines Produktes Endanwender: Strukturierung von Anwendungsanforderungen, Vergleich von Produkten unterschiedlicher Hersteller Integratoren: Verstehen der Anforderungsspezifikationen und Hilfe bei Produktauswahl Stand Januar 2007 Seite 22

23 Literaturhinweise Übersetzungen entsprechen, soweit anwendbar, dem Englisch-Deutschen Wörterbuch aus DIN EN Begriffe, die in diesem Teil noch nicht eingeführt wurden, sind gemäß des gemeinsamen Verständnisses der Autoren ins Deutsche übertragen worden; diese Übertragung erhebt jedoch keinen Anspruch auf Verbindlichkeit. Die in diesem Dokument enthaltenen Graphiken lehnen sich an die Graphiken aus DIN EN an. Für die Teile 4 und 5 wurde auf die Entwürfe der ISA SP95 zurückgegriffen. Um eine einheitliche Betrachtung der Abbildungen zu ermöglichen, wurde eine durchgehende englischsprachige Beschriftung entsprechend ISA verwendet und diese auch zum Teil in den Text übernommen, mit deutschen Benennungen in Klammern dahinter. Dem Leser wird empfohlen, für die deutschen Entsprechungen das englisch-deutsche Wörterbuch und die deutsch beschrifteten Bilder der DIN EN heranzuziehen. [1-a] Williams, T.J.: The Purdue Enterprise Reference Architecture (PERA) A Technical Guide for CIM Planning and Implementation, ISA, Research Triangle Park, NC (1992) [1-b] [2] WBF B2MML (V4.0, Juni 2007): Business To Manufacturing Markup Language [3-a] Johnsson, C. (Lund Institute of Technology): ISA 95 - how and where can it be applied?; 2004, ISA Expo. [3-b] Johnsson, C. (Lund Institute of Technology) and Schumacher, H. (Siemens AG): Communication through B2MML is that possible?; 2004, WBF. Stand Januar 2007 Seite 23

24 Teile dieses Artikels beruhen auf einer Übertragung von [3-a] und [3-b] ins Deutsche. An der weiteren Ausarbeitung haben mitgewirkt (in alphabetischer Reihenfolge): Dr. Marcus Adams Aschaffenburg Prof. Dr. Wolfgang Kühn Wuppertal Thomas Stör Nürnberg Dr. Martin Zelm Stuttgart Die Autoren sind Mitarbeiter im Arbeitskreis Unternehmensmodelle der DKE (Deutsche Kommission Elektrotechnik Elektronik Informationstechnik im DIN und VDE) Ingo Rolle (DKE Frankfurt, bzgl. Fragestellungen zu Normen und Normungsverfahren beratend mitgewirkt. Stand Januar 2007 Seite 24