MBA INFORMATION MANAGEMENT THESIS RESEARCH PROJECT                         

    Please Use the online survey.

Selection and decision-making criteria for a Distributed Control Systems in the process industry”.

5.5 Interoperabiliteit naar systemen buiten het DCS

De effectiviteit van de productie in een onderneming wordt niet alleen door het procesbesturingssysteem (DCS) bepaald, maar heeft ook coördinatie op een hoger niveau nodig voor het managen van mensen, uitrustingen en materiaal om het maximale potentieel uit de installatie te halen. Dit wordt vaak gedaan door software die valt onder de verzamelnaam “Manufacturing Execution System” (MES) laag.

De MES laag (niveau 3) definieert een aantal functies welke boven het procesbesturingssysteem (niveau 1 & 2) liggen maar onder het niveau (niveau 4) van de enterprise business systemen (ERP).

Er zal een mate van interoperabiliteit moeten zijn tussen verschillende systemen op niveau 2 (DCS – PLC – veiligheid instrumentatie systemen (SIS) en uiteraard de veldapparatuur die zich op niveau 1 bevindt.

Om de functionaliteit te bereiken zoals hiervoor in paragraaf 5.4 beschreven zal het DCS systeem capaciteiten moeten hebben om:

·        Data te kunnen verzenden naar andere functionele eenheden (één richtingsverkeer);

·        Data te kunnen ontvangen van andere functionele eenheden (één richtingsverkeer);

·        Te communiceren (twee richtingen verkeer);

·        Externe programma’s kunnen uitvoeren.

Deze functies moeten autonoom kunnen werken en vragen van de eindgebruiker geen specifieke kennis. De eisen en technische mogelijkheden aan de te verbinden systemen en applicaties worden hoger naarmate de interoperabiliteit toeneemt. De volgende modellen die iets zeggen over interoperabiliteit:

·        Het zevenlagen OSI model;

·        Het interoperabiliteit raamwerk;

·        ANSI/ISA-95 en het ANSI/ISA-88.

5.5.1 Het OSI-model (of ISO-OSI)

Het OSI-model (of ISO-OSI) is de benaming voor ISO Reference Model for Open Systems Interconnection en is ontstaan in 1977 en is in 1995 herzien. Het OSI-model is een gestandaardiseerd middel om te beschrijven hoe data wordt verstuurd over een netwerk. Het zorgt er voor dat er compatibiliteit en interoperabiliteit is tussen de verschillende types van netwerktechnologieën van organisaties over de hele wereld. Dit zevenlagen ISO model deelt de communicatie in zeven lagen. De lagen zijn, van hoog naar laag: Toepassing, Presentatie, Sessie, Transport, Netwerk, Datalink en Fysiek[1]^, [2]. 

De voordelen van het OSI model zijn[3]:

• Verminderde complexiteit;
• Standaardisering;
• Interoperabele technologieën;
• Modulaire ontwikkeling;
• Snellere evolutie;
• Het aanleren wordt eenvoudiger.

Tabel  SEQ Tabel \* ARABIC 1 OSI Model

Fig. 1 Fabrieksvloer naar ERP systeem interoperabiliteit

5.5.2 Het Interoperabiliteit raamwerk

Fig. 2 Interoperabiliteit raamwerk diagram[4]

Het bovenstaande raamwerk geeft de verschillende categorieën aan betreffende de technische-, informele- en organisatorische aspecten. De gegevens kunnen twee kanten op (omhoog en omlaag) maar over het algemeen wordt er bij een DCS systeem veel meer gegevens naar boven gestuurd dan gegevens die omlaag gaan. Vooral bij DCS systemen is men om veiligheidsredenen erg voorzichtig om andere systemen schrijfrechten op het DCS systeem te geven.  Technisch gesproken is de uitvoering vaak een aanzienlijk kleiner probleem bij de moderne systemen. Het Nederlandse Forum voor Standaardisatie voegen nog twee dimensies toe aan het model namelijk “enterprise” (aan de top) en “juridisch” (aan de bodem)[5].

Daarnaast staan 10 onderwerpen welke belangrijk zijn voor een goede interoperabiliteit en integratie.

De onderwerpen die over de breedte van de diverse lagen gaan zijn:

1.      Gemeenschappelijke betekenis van begrippen (zie paragraaf 5.5.4 ISA- 95 en 5.5.5. (ISA-88);

2.      Identificatie van systeembronnen;

3.      Tijdsynchronisatie;

4.      Beveiliging en privacy;

·        Als we over integratie met andere systemen spreken moeten we gelijktijdig kijken naar de potentiële gevolgen van de verbonden systemen en de potentiële dreiging die daar vanuit gaat (zie paragraaf 5.5.8).

5.      Logs en audits;

6.      Transacties statusberichten;

7.      Systeembeheer;

8.      Prestaties / betrouwbaarheid en schaalbaarheid;

9.      Configuratie;

10.  Systeem evolutie.

5.5.3 Interoperabiliteit en integratie

Deze paragraaf zal op de volgende zaken in gaan:

1.      Welke bedrijfsfuncties moeten met elkaar communiceren?

2.      Wat bestaat er aan standaarden om dit te bereiken?

De DCS systemen van de grote aanbieders zijn steeds meer een geïntegreerd systeem geworden, die bestaan uit subonderdelen die op een nette manier met elkaar geïntegreerd zijn. Dit ten opzichte van SCADA systemen die toch vooral een operator interfaces zijn.

De vraag die de eindgebruiker zich zal moeten stellen is; wat is voor ons de beste strategische keuze, een geïntegreerde oplossing of verbinden met een extern systeem omdat dat goedkoper is, dan wel gewoon al aanwezig is en gebruikt moet worden of kwalitatief beter is. Dit laatste wordt een “best of breed strategie” genoemd en wordt bij de technologiestrategie meer in detail beschreven.

De kans dat een koppeling met een bestaand systeem moet worden uitgevoerd is groot doordat de meeste DCS projecten migraties of uitbreidingen zijn bij bestaande installaties.

Bovenstaande figuur laat zien dat we spreken van integratie als we binnen het zelfde systeem blijven en over interoperabiliteit als we overstappen naar een ander systeem. Door de leveranciers wordt natuurlijk geprobeerd om het eigen systeem zo groot als mogelijk te krijgen.

Tabel 2 DCS Interne MES oplossingen

Onderstaand voorbeeld van één van de DCS leveranciers combineert de real-time en transactionele data management infrastructuur om de MES beloftes waar te maken met een standaard architectuur.

Fig. 3 Emerson bedrijfsbrede “enterprise - besturingsintegratie oplossing”[7]

Enkele voorbeelden van informatiestromen ten behoeve van bedrijfsfuncties zijn:

·        Het verzorgen van lange termijn trending van procesgegevens voor ondersteunende diensten zoals procestechnologen, laboranten, monteurs, elektriciens en management;

·        Het samenstellen van managementinformatie ten behoeve van energieverbruik, logistiek et. cetera;

·        Onderhoudstatussen doorgeven aan onderhoudspakketten, dit is mede afhankelijk van de onderhoudsfilosofie. Bij een visie van “we draaien er meedoor tot dat het stuk is, en we kunnen tussen de batches eenvoudig het onderdeel vervangen[8]” zijn intelligente veldnetwerken niet noodzakelijk;

·        Productieorder informatie van uit een ERP systeem naar een DCS systeem.

In Appendix E5 staat een uitgebreide lijst van bedrijfsfuncties communicatie tussen de verschillende niveaus.

Interoperabiliteit kunnen we onderscheiden op twee manieren.

1.      Waarmee moet het DCS communiceren?

a.       Verticale interoperabiliteit;

·        Verticale interoperabiliteit omhoog (bijvoorbeeld DCS aan MES planningsmodule);

·        Verticale interoperabiliteit omlaag (bijvoorbeeld DCS naar veldapparatuur);

b.      Horizontale interoperabiliteit (bijvoorbeeld PLC aan DCS);

2.      Welke technologie is daarvoor nodig? (dit wordt in de technologieparagraaf 5.6.XX beschreven).

De verschillende systemen (ERP, MES, DCS, SCADA en PLC) breiden zich in elkaar richting uit en op bepaalde vlakken is er een overlap. Het is daarom van belang om de verschillende systemen met elkaar te laten communiceren. Het laten communiceren van verschillende systemen is geen sinecure. De systemen zijn namelijk met totaal verschillende doelstelling in het leven geroepen, door mensen in een totaal verschillende omgeving[9]. Om twee systemen op een zinnige wijze met elkaar te laten communiceren moeten er afspraken - protocollen bestaan hoe één en ander moet plaats vinden.

·        Het ANSI/ISA-95.00.03-2005 Enterprise-Control System Integration bijschrijft het gehele model van niveau 0 (het proces) tot niveau 5 businessmanagement. In de praktijk wordt het vooral toegepast tussen de niveaus 2 en 5.

·        Het ANSI/ISA-88.01-1995 model wordt toegepast op de niveaus 1 en 2 en vooral bij batch applicaties met enige uitlopers naar niveau 3. (dit is het gebied DCS naar MES).

·        Tussen niveau 1 en niveau 2 bestaan een hele serie protocollen zoals onder andere Hart, Foundation Fieldbus en Profibus tussen het DCS systeem en de veldapparatuur.

Steeds meer systemen ondersteunen deze standaarden en waar dat niet het geval is worden er steeds meer maatwerkoplossingen toegepast.

Voor een interoperabiliteit project is het belangrijk dat de verschillende leveranciers de relevante vorenstaande normen en protocollen ondersteunen.

5.5.4 ANSI/ISA-95 (01, 02 en 03)

ISA-95 is de internationale standaard voor de integratie van kantoor- en productie- automatiseringssystemen.

ISA-95-01 en ISA-95-02 zijn tevens omschreven in de ISO/IEC 62264-1, de standaard voor Enterprise-Control System Integration[10].

ISA-95 bestaat uit modellen en terminologie die nauwkeurig in kaart brengen welke informatie moet worden uitgewisseld tussen systemen gericht op verkoop, financiën en logistiek en systemen gericht op productie, onderhoud en kwaliteit. Aan de hand van UML (Unified Modeling Language) object modellen wordt deze informatie gestructureerd om zodoende gestandaardiseerde interfaces te kunnen ontwikkelen tussen ERP- en MES systemen. Bovendien kan ISA-95 worden gebruikt voor het opstellen van User Requirements, voor (MES) leveranciersselecties en als basis voor het ontwikkelen van MES systemen en databases.

De afbeelding hieronder laat zien hoe de verschillende informatiestromen lopen tussen de verschillende bedrijfsfuncties die binnen de ISA-95 norm zijn omschreven.

Fig. 4 ISA 95.00.01 CDV 04 (2008) model

De afbeelding hieronder laat de verschillende lagen zien in het ISA-95 model en welke bedrijfsfuncties daar primair thuis horen.

Fig. 5 ISA-95 met toegevoegd businessmanagement laag[11]

5.5.5 ISA-S88 standaard

ISA-88 voorheen S88 geheten, is een internationale standaard. Het helpt industrieën om flexibel te kunnen produceren. De standaard bestaat uit modellen en termen die het productieproces logisch indelen en de besturing van het machinepark regelen. ISA-88 kan worden toegepast in volledig geautomatiseerde-, semi-geautomatiseerde- en zelfs in volledig handmatige productieprocessen.

De S88.01 standaard heet voluit ANSI/ISA-88.01-1995, Batch Control Part 1: Models and Terminology. Hoewel de standaard is ontwikkeld voor batch processen, kan het ook worden toegepast bij continue- en discrete processen. Denk bij continue processen bijvoorbeeld aan olieraffinaderijen, waterzuivering of gaswinning. Discrete processen kom je bijvoorbeeld tegen in de auto-industrie. Zodra bij dergelijke processen een bepaalde mate van flexibiliteit is vereist, is de ISA-88 standaard goed bruikbaar. ISA-88.01 plaatst het equipement in het fysieke model. Deze indeling is hiërarchisch en gaat van globaal naar gedetailleerd. Op basis van deze indeling kan de control systeem engineer uiteindelijk alle mogelijkheden van het equipement gaan programmeren[12].

Fig. 6 Functionele gebieden van ISA-88 en ISA-95[13]
5.5.6 Prioriteiten per systeem

Doordat er gewerkt wordt met verschillende systemen hebben we ook te maken met verschillende prioriteiten per systeem[14].

De veiligheid van de installatie, heeft in de omgeving en voor de mensen die er werken of in de buurt wonen topprioriteit. Er zijn een aantal overwegingen die gemaakt moeten worden bij de koppelingen met DCS/PLC en zeker SIS veiligheidssystemen. Dit wordt in paragraaf 5.5.7.2 nader omschreven.

Het tweede belangrijke punt is beveiliging tegen ongewenste beïnvloeding van de systemen. Dit wordt in paragraaf 5.5.8 nader omschreven.

5.5.7 Functionaliteit en integratie

Uit het ARC onderzoek “Control System Functionality & Integration” bleek dat de proces historieserver, safety instrumentatie systemen (SIS), batch applicaties, en advanced process control (APC) toepassingen de hoogste mate van integratie hebben met het DCS systeem.

De integratie met een trainingsimulator en enterprise asset management (EAM), veldinstrumenten bewaking en LIMS komen het minst vaak voor. Zaken als configuratie management en systeemonderhoud worden door de gebruikers als een geïntegreerd deel van proces besturingssysteem gebruikt.

Fig. 7 Control Systeem functionaliteit  en integratie^[15]

5.5.7.1 Proces historisatie server

De proces historisatie server heeft als doel om lange termijn (maanden tot soms wel 10 jaar) procesgegevens op te kunnen slaan die door de gebruikers op het operator DCS scherm weer kunnen worden opgevraagd dan wel beschikbaar zijn voor anderen in de organisatie (onderhoud, productieleiding, technologie et cetera).

Daarnaast dienen alle procesjournaals te worden opgeslagen.

We kennen de onderstaande log bestanden die soms gecombineerd zijn in één proces logbestand:

• Operator wijzigingen;
• Alle binnengekomen alarmstatussen;
• Alle verrichte systeem wijzigingen door onderhoud;
• Alle verrichte systeem wijzigingen door engineers.

Sommige ondernemingen zijn op een bepaald merk historisatie systeem gestandaardiseerd en eisen dat het DCS systeem hieraan wordt gekoppeld. Voorbeelden zijn bijvoorbeeld PI (OSI) MIMS (Siemens) PHD (Honeywell). Men dient echter goed te beseffen dat een externe historie server wel vaak de proces (trend) gegevens kan in lezen maar niet altijd de procesjournaals. Zonder de procesjournaals is het erg lastig om offline een goede evaluatie uit te voeren van processituaties.

5.5.7.2 Interoperabiliteit naar SIS – ESD systemen

Procesveiligheid is de eerste prioriteit in de procesindustrie en er bestaan dan ook speciale systemen die de procesveiligheid moeten garanderen zonder menselijke tussenkomst. De mens is bewust uit deze lijn gehaald in verband met het faalbare gedrag van een mens. De mate van vereiste veiligheid wordt uitgedrukt in Safety Integrity Level (SIL) klassen conform de IEC61508 norm. Een DCS valt in SIL 1 terwijl een ESD (Emergency Shutdown Systeem) over het algemeen een SIL 3 klasse indeling hebben.

Fig. 8 Niveaus van integratie DCS - SIS[16]

Van de Laan stelt dat veiligheid volgens het “Safety Integrated Concept” in alle gelederen van de industriële organisatie bewaakt moet kunnen worden. Het grote voordeel voor bedrijven is dat ze in de productieomgeving geen gescheiden veiligheidssystemen (hard- en software en bedrading) hoeven aan te leggen. Dat betekent ook dat productiebesturing en veiligheid met een zelfde programmeertaal kunnen worden ontworpen. Een Siemens PLC dient bijvoorbeeld meteen als veiligheid PLC te functioneren[17]. De mate van integratie is bij de verschillende DCS aanbieders verschillend.

Tussen de verschillende concepten van DCS-ESD integratie bestaan verschillende gezichtpunten.

Voor eenvoudige communicatie, onderhoud en reserve onderdelen zou het optimaal zal als alles gelijk is. Er is dan minder training nodig en aanpassingen kunnen sneller en eenvoudiger worden uitgevoerd. Hierin zit ook gelijk het grote risico, dan de functies van de twee systemen is totaal verschillend.

Het DCS werkt in een dynamische wereld terwijl het ESD systeem er statisch bijstaat en wacht tot het proces uit de hand loopt voordat het ESD syteem ingrijpt.

Er bestaan zelfs ondernemingen zoals Exxon Mobil die de programmering van deze twee systemen bij twee verschillende engineers neerleggen (DCS engineer en safety engineer). De kans dat een zelfde denkfout wordt gemaakt in twee systemen of dat er een softwarebug optreedt in twee systemen op het zelfde tijdstip is minimaal.

Als uitgangspunt moeten we stellen dat besturing- en veiligheidsystemen functioneel gescheiden en onafhankelijk van elkaar dienen te werken.

Fig. 9 Besturing- en veiligheidsfuncties fysieke en logische scheiding[18]

De mate van integratie is afhankelijk van het risicoprofiel van de onderneming en hieruit volgt dan een gewenste configuratie. Zo zou de gewenste configuratie één of meerdere van onderstaande functies of profielen hebben:

• Geen integratie van systemen en de I/O is volledig gescheiden;
• Het lezen van informatie uit het ESD systeem (trips);
• Het lezen van veldinstrumentatie data uit het ESD systeem (AI en DI tags);
• Gebruik maken van dezelfde veld I/O voor schakelacties maar wel apart geschakeld;
• Het kunnen plaatsen van een “Override” vanaf het DCS naar het SIS systeem;
• Gelijksoortige I/O hardware;
• Dezelfde engineeringssoftware;
• Gelijksoortige controller hardware;
• DCS en SIL functies op dezelfde controller.

Uitgaande van bovenstaande lijst kan men stellen dat boven aan de lijst de systeemintegriteit, veiligheidsfuncties en (investerings- en onderhoudskosten) maximaal zijn en onderaan de lijst dit precies andersom is. Het is dan ook noodzakelijk om per plant een risicoprofiel op te stellen en daarbij de mate van integratie te kiezen.

Ineos Sicicas geeft aan dat een koppeling met SAP (ERP) op dit moment niet wordt toegepast omdat hiervoor de productiegegevens zeer betrouwbaar moeten zijn en dat is afhankelijk van de kwaliteit van de applicaties op het MES niveau[19].

5.5.8 Beveiliging - Security

Door de toepassing van informatietechnologie zoals Windows Ethernet TPC/IP en webservices in PLC/SCADA en DCS systemen zijn deze systemen meer gevoelig voor virus, worm, hackers en mogelijke terroristen overal ter wereld. In 2003 heeft de Slammer Worm de SCADA systemen voor de voedseldistributie uit laten vallen en het safety parameter display systeem (SPDS) en de procescomputers in de Ohio Davis-Besse nucleaire fabriek geïnfecteerd[20]. Ook werd de oliewinning in de Golf van Mexico slachtoffer. Hackers hebben met keyloggers ook SCADA systemen van de waterbehandelingsinstallaties van Harrisburg[21] geïnfecteerd, petroleum verladingssystemen laten uitvallen en moedwillig afvalwater lekkage veroorzaakt.

Zelfs onschuldige security scans van PLC en SCADA netwerken hebben bij diverse bedrijven geleid tot miljoenen dollars aan productieverlies[22]. In het totaal zijn er meer dan 50 incidenten bekend in de BCIT “Industrial Security Incident Database ISID” betreffende de procesindustrie.

Fig. 10 Bescherming van de systeemgrenzen[23]

Er ligt een directe relatie tussen interoperabiliteit en beveiligingsincidenten, dit komt:

• Enerzijds doordat systemen meer open en verbonden zijn met andere systemen en
• Anderzijds dat er steeds meer COTS hard- en software wordt toegepast (zie paragraaf 5.6 technologie).

Fig. 11 Interne beveilingsincidenten met als toegangspoort

Fig. 12 Externe beveiligingsincidenten met als toegangspoort

Tabel 3 Startpunt beveiligingsincidenten[24]

5.5.9 Uitvoering interoperabiliteit en integratie project

Doordat er verschillende systemen geïntegreerd worden zijn er natuurlijk ook verschillende partijen (leveranciers) die dit willen/kunnen uitvoeren, elk met hun eigen voor- en nadelen.

De volgende partijen kunnen (delen) van de implementatie uitvoeren[25]:

• ERP leverancier met een top-down benadering;
• DCS automatiseerders leveranciers bottum-up benadering;
• System integrators;
• Interne ontwikkeling door de eigen organisatie.

De voor- en nadelen van de verschillende uitvoerders van een implementatieproject wordt beschreven in de paragraaf 5.7.XX Implementatie.

5.5.10 Probleemgebieden bij integratie

Bij het integreren van bedrijfsapplicaties kunnen er enkele probleemgebieden ontstaan. Het is dan ook raadzaam om de effecten die kunnen optreden te bestuderen. De potentiële problemen zijn:

• Koppeling met de rest van de applicatieontwikkeling in het bijzonder de gebruikers interface[26];
• Koppelingen met applicatieontwikkeling waar real-time database onderhoud gebeurd;
• Beveiligingen van de remote-proces naar-proces-communicatie;
• Batch (planning, hoog volume, neigend naar processor overbelasting);
• Betrouwbaarheid van het berichtenverkeer, is de informatie aangekomen (j/n), verwerkt (j/n);
• Hoe is de transactionaliteit te bewaken;
• Centralisatie van beheerstatus (fout en performancebeheer);
• Centralisatie van de datatransformatie;
• Masterklok bepalen voor tijdsynchronisatie;
• Effecten bepalen als tijd niet meer synchroon is.

Management of compliance. Hoe zorg je er voor dat alle informatie tussen de verschillende applicaties gelijk blijven?

Hoe behandel je de interactiviteit tussen de verschillende modules, bijvoorbeeld de asset managementtool geeft aan dat pomp B12 defect is en er een reparatie moet plaats vinden, hoe weet het productieplanningsprogramma dat?

APPENDIX E5

Interoperabiliteit

In dit appendix staan een aantal voorbeelden van applicaties die gegevens uitwisselen tussen de verschillende niveaus (levels).

Niveau 1 naar niveau 2 conform ISA-95 norm

·        Proces apparatuur (druk, flow, temperatuur, pH);

·        Online analyse apparatuur;

·        PLC (voor besturing deelprocessen – Packed units);

Niveau 2 naar niveau 3 visa versa conform ISA-95 norm

·        Advanced Process Control (APC);

·        Proces optimalisatie systemen;

·        Assetmanagement pakket;

·        Bewaking veldinstrumenten;

·        Batch;

·        Conditiemonitoring – trillingsmetingen;

·        Documentatiesystemen zoals I-MOC;

·        Engineeringsdatamanagement;

·        Enterprise Asset Management (EAM);

·        Historisatie unit;

·        Laboratorium pakket (LIMS);

·        Onderhoudspakketten conform MINOSA bijvoorbeeld Maximo of SAP PM module;

·        SIL Veiligheidsinstrumentatie systeem – (SIS of ESD);

·        Statistical Process Control (SPC) toepassingen;

·        Trainingssimulator.

Niveau 3 naar niveau 2

·        Productiekosten doelstellingen;

·        Kwaliteitsplannen – standaarden en klanteisen;

·        Onderhoudsterugkoppelingen;

·        Materiaal en energie voorraden en beheer;

·        Productieplanning;

·        Antivirus server;

·        Domeincontroller – beveiligingsserver.

Niveau 2 naar niveau 4 conform ISA-S95 norm

Directe koppelingen van DCS aan het ERP pakket bijvoorbeeld SAP of subsysteem

·        Productieplanning;

·        Voorraadbeheer;

·        Logistieke operaties.

Directe koppelingen tussen niveau 2 en niveau 5 zullen waarschijnlijk niet plaatsvinden.

When you need specific information please send my a e-mail.

Willem.Hazenberg@dcsselect.eu

18-10-2009