OPC

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 13. juni 2016; checks kræver 12 redigeringer .

OPC ( forkortet fra engelsk  Open Platform Communications [1] , tidligere engelsk  O LE for Process Control ) er en familie af softwareteknologier , der giver en enkelt grænseflade til styring af automationsobjekter og teknologiske processer . Mange af OPC-protokollerne er baseret på Windows - teknologier: OLE , ActiveX , COM / DCOM . OPC-protokoller såsom OPC XML DA og OPC UA er platformsuafhængige .

Oprettelse og vedligeholdelse af OPC-specifikationer koordineres af den internationale non-profit organisation OPC Foundation , etableret i 1994 af førende producenter af industrielle automationsværktøjer.

OPC Foundations motto er "Åben kommunikation over åbne protokoller".

Standarder

OPC er et sæt standardspecifikationer . Hver standard beskriver et sæt funktioner til et specifikt formål. Nuværende standarder [2] :

Udnævnelse

OPC-standarden blev udviklet for at reducere omkostningerne ved at skabe og vedligeholde industrielle automationsapplikationer. I begyndelsen af ​​1990 havde industrielle softwareudviklere brug for et universelt værktøj til at udveksle data med enheder fra forskellige producenter eller bruge forskellige dataudvekslingsprotokoller.

Essensen af ​​OPC er enkel - at give udviklere af industrielle programmer en universel fast grænseflade (det vil sige et sæt funktioner) til udveksling af data med enhver enhed. Samtidig leverer enhedsudviklere et program, der implementerer denne grænseflade (sæt af funktioner).

Versioner

I øjeblikket er den seneste version af OPC DA-specifikationen version 3.0, men version 2.05a er den hidtil mest udbredte. Den nyudviklede OPC UA (Unified Architecture) standard forener sættet af funktioner til dataudveksling, hændelsesregistrering, datalagring, datasikkerhed.

OPC DA Version 2.05a

Den mest udbredte. Ud over synkron dataudveksling introducerer denne standard understøttelse af asynkron dataudveksling. Asynkron dataudveksling giver dig mulighed for at fortsætte udførelsen af ​​programmet uden at vente på et svar fra enheden. Denne metode reducerer belastningen på netværket og bør anbefales som den vigtigste. Data modtages ved hjælp af tilbagekaldsfunktionen i brugerprogrammet, som kaldes, når der modtages et svar fra enheden.

OPC Unified Architecture

OPC UA-specifikationen kombinerer alle fordelene ved tidligere specifikationer og åbner nye horisonter for anvendelsen af ​​OPC-teknologier. Især på grund af det faktum, at der var et afslag på at bruge COM-grænsefladen, er kompatibilitet på tværs af platforme sikret. Den nye standard giver allerede i første omgang mulighed for et højere niveau af datasikkerhed end OPC DA. Derudover gør den nye specifikation det muligt at organisere overførsel af information via internettet.

Værktøjskasse

De mest almindelige programmeringssprog, der bruges til at skabe OPC-aktiverede applikationer, er Delphi , C++ , C# eller Visual Basic . Det er muligt at bruge Python-sproget.

Ledelsesniveauer

Baseret på omfanget af OPC-servere i en virksomheds automatiserede kontrolsystem er der flere ledelsesniveauer:

Hvert af disse lag kan betjenes af en OPC-server, der leverer data til en OPC-klient på et højere lag eller endda en "nabo".

Mulige anvendelser af OPC-servere i virksomhedens automatiserede kontrolsystemer

Hvis der er hardware, såsom et ADC -kort , styret via en driver på en Windows-computer eller et andet OS, der understøtter COM / DCOM , så er dette en førsteklasses kandidat til at implementere en OPC-server direkte oven på driveren.

Udskiftning af en enhed kræver ikke ændring af andre applikationer: OPC-serveren ændres, men selve OPC-grænsefladen oven på den forbliver den samme.

Hvis der er en enhed styret via en eller anden netværksprotokol, er det meget muligt at implementere en OPC-server, der modtager data via denne protokol. Den eneste funktion er, at der skal findes mekanismer til at genoprette kommunikationen i tilfælde af fejl.

Ordningen vil være noget mere kompliceret, når man kører kontrolapplikationer på en computer, der ikke understøtter COM/DCOM. I dette tilfælde er en to-komponent OPC-server anvendelig. På den OS-side, der ikke understøtter COM, er der installeret et netværksmodul, som på den ene side er forbundet med applikationen/applikationerne og på den anden side via netværket med OPC-serveren. Bemærk, at netværksmodulet kan være standard, såsom ISaNet i ISaGRAF -systemet . I dette tilfælde er det kun OPC-serveren, der skal udvikles. Nogle gange oprettes et netværksmodul specifikt til en OPC-server. Det er endda muligt at implementere dette modul, der ikke er applikationsspecifikt, men giver en API til enhver applikation, der ønsker at blive betjent af OPC. Sådan fungerer OPC-serveren til OS-9- operativsystemet .

En anden type OPC-server er en gateway til et feltbusnetværk , såsom Profibus eller LonWorks . Implementeringen af ​​denne ordning er meget lig de tidligere sager. Mest sandsynligt vil en fieldbus-netværksadapter blive installeret på Windows-maskinen, og OPC-serveren vil kommunikere med dette netværk via adapterdriveren. Du kan finde mange sådanne eksempler på internettet.

Ideen med en sådan ordning er ret indlysende. Feltbusnetværket fungerer i hård realtid, og OPC giver en mindre krævende gateway til dette netværk fra applikationer på højere niveau.

Der er mange andre steder, hvor OPC kan bruges: til at arbejde med databaser som hjælpe- eller mellemliggende OPC-servere osv. DCOM -teknologi er ikke særlig velegnet til wide area networks. Derfor, for at tiltrække internetteknologier til OPC-teknologi, er følgende måde mulig: Webserverudvidelsen er en OPC-klient, der indsamler data fra OPC-servere. Og på klientsiden lanceres en dynamisk html - eller xml - side, der modtager data fra denne webserver. Det kan endda gøres til en OPC-server til andre applikationer.

Nytten af ​​at bruge OPC i forhold til integration er ret gennemsigtig og følger af selve essensen af ​​OPC. Dette er en standard for grænsefladen af ​​dataudveksling med udstyr. Den første fordel er, at hvis du udskifter en komponent, er der ingen grund til at rette anden software, for selv når du udskifter en driver, fungerer OPC oven på den. For det andet, hvis du vil tilføje nye programmer til systemet, er der ingen grund til at levere enhedsdrivere i dem, bortset fra OPC-klienten, selvfølgelig. Nå, og så videre.

Status

På nuværende tidspunkt er det kun OPC DA- og OPC HDA-specifikationerne, der er den accepterede standard, mens resten af ​​specifikationerne lige er begyndt at fange. Ikke alle specifikationer er komplette, i hvert fald med hensyn til automatiseringsgrænsefladen (f.eks. eksisterer version 2.0 af den brugerdefinerede grænseflade allerede for OPC-Batch, og kun version 1.0 for automatiseringsgrænsefladen. For nogle andre specifikationer er der også et efterslæb af automatiseringsgrænseflader fra brugerdefinerede grænseflader).

Derfor er det kun OPC DA-standarden, der er blevet udbredt. Vi kan sige, at nu leverer rigtig mange producenter deres produkter med OPC DA-servere. I de senere år er OPC HDA-standarden blevet aktivt udviklet. Det samme kan ikke siges om andre specifikationer.

Blandt programmer på højt niveau er billedet det samme. Kun OPC DA er efterspurgt.

Af operativsystemerne understøttes COM / DCOM -teknologi af følgende:

Andre almindelige operativsystemer understøtter ikke COM/DCOM.

Perspektiver

En hel del hardware og software er ikke omfattet af OPC-teknologier. Til gengæld udvikler Microsoft ikke længere COM/DCOM, som bliver erstattet af mere moderne teknologier som .NET.

OPC Foundation holder udviklingen af ​​standarden tilbage med sine politikker. Interfacedokumentation er kun tilgængelig for medlemmer af denne organisation. Medlemskab koster fra flere tusinde dollars, hvilket ikke kun er tilgængeligt for enkelte udviklere, men endda for mange organisationer. Dette forklarer populariteten af ​​OPC DA, dokumentation på denne grænseflade har været frit tilgængelig i lang tid. Som følge heraf bruger mange virksomheder, der ikke ønsker at involvere sig med en ret lunefuld teknologi, har gode lavniveau-programmører og arbejder med et begrænset udvalg af controllere, CORBA-teknologi til deres SCADA-pakker.

Konklusion

OPC-teknologien tilbyder standarder for udveksling af procesdata med det bredeste udvalg af muligheder. I betragtning af de involverede virksomheders høje profil kan OPC-teknologi forventes at tage fart. Dette er en lovende teknologi til integration af heterogene systemer. Selvom dannelsesprocessen langt fra er afsluttet, og der er mange problemer, der skal løses.

Noter

  1. Hvad er OPC? (eng) . Hentet 11. juli 2017. Arkiveret fra originalen 4. juli 2017.
  2. Memorandum, Wisner til Stevens, Overvejelse af OPC-ansvar i området for flugt og unddragelse, 24. oktober 1950, Top Secret. . Efterretninger fra den kolde krig . Hentet: 5. april 2022.

Links