Hvorfor er det viktig for maskinvareutviklere å utføre cusdev av høy kvalitet

Når det gjelder automatisering av prosesser i petrokjemisk industri, spiller ofte stereotypen inn om at produksjonen er kompleks, noe som gjør at alt som kan nås automatiseres der, takket være automatiserte prosesskontrollsystemer. Faktisk ikke helt sånn.

Den petrokjemiske industrien er riktignok ganske godt automatisert, men dette dreier seg om den teknologiske kjerneprosessen, hvor automatisering og minimering av den menneskelige faktoren er avgjørende. Alle relaterte prosesser er ikke automatisert på grunn av de høye kostnadene ved automatiserte prosesskontrollløsninger og utføres manuelt. Derfor, en situasjon der en ansatt en gang hver par timer manuelt sjekker om dette eller det røret er riktig oppvarmet, om den nødvendige bryteren er slått på og om ventilen er trukket tilbake, om vibrasjonsnivået til lageret er normalt - dette er normalt .

Hvorfor er det viktig for maskinvareutviklere å utføre cusdev av høy kvalitet

De fleste ikke-kritiske prosesser er ikke automatiserte, men dette kan gjøres ved hjelp av Internet of Things-teknologier i stedet for automatiserte prosesskontrollsystemer.

Dessverre er det et problem her - et gap i kommunikasjonen mellom kunder fra den petrokjemiske industrien og jernutviklerne selv, som ikke har kunder i olje- og gassindustrien og følgelig ikke får informasjon om kravene til utstyr for bruk i aggressive, eksplosive områder, i tøffe klimaforhold, etc.

I dette innlegget vil vi snakke om dette problemet og hvordan du løser det.

IoT i petrokjemikalier

For å sjekke noen parametere bruker vi gjennomganger for visuell og taktil inspeksjon av ikke-kritiske installasjonskomponenter. Et av de vanlige problemene er knyttet til damptilførselen. Damp er kjølevæsken for mange petrokjemiske prosesser, og den tilføres fra varmesentralen til den endelige noden gjennom lange rør. Det bør tas i betraktning at våre fabrikker og installasjoner ligger under ganske vanskelige klimatiske forhold, vintrene i Russland er harde, og noen ganger begynner noen rør å fryse.

Derfor skal visst personell ifølge forskriftene gjøre runder en gang i timen og måle temperaturen på rørene. På skalaen til et helt anlegg er dette et stort antall mennesker som nesten ikke gjør annet enn å gå rundt og ta på rør.

For det første er det upraktisk: temperaturene kan være lave, og du må gå langt. For det andre er det på denne måten umulig å samle inn og spesielt bruke data om prosessen. For det tredje er det kostbart: alle disse menneskene må gjøre mer nyttig arbeid. Til slutt, den menneskelige faktoren: hvor nøyaktig måles temperaturen, hvor regelmessig skjer dette?

Og dette er bare en av grunnene til at anleggs- og installasjonsledere er ganske alvorlig opptatt av å minimere påvirkningen av den menneskelige faktoren på tekniske prosesser.

Dette er den første nyttige casestudien av mulig bruk av IoT i produksjon.

Den andre er vibrasjonskontroll. Utstyret har elektriske motorer, og det skal utføres vibrasjonskontroll. Foreløpig utføres det på samme måte, manuelt – en gang om dagen går folk rundt og bruker spesielle instrumenter for å måle vibrasjonsnivået for å være sikker på at alt er i orden. Dette er igjen sløsing med tid og menneskelige ressurser, igjen påvirkningen fra den menneskelige faktoren på riktigheten og hyppigheten av slike runder, men den viktigste ulempen er at du ikke kan jobbe med slike data, fordi det er praktisk talt ingen data for behandling og det er umulig å gå videre til service på dynamisk utstyr basert på tilstand.

Og dette er nå en av hovedtrendene i bransjen - overgangen fra rutinemessig vedlikehold til tilstandsbasert vedlikehold, med riktig organisering som opprettholder aktive og detaljerte registreringer av utstyrets driftstimer og full kontroll over dets nåværende tilstand. For eksempel, når tiden er inne for å sjekke pumpene, sjekker du parametrene deres og ser at i løpet av denne tiden har pumpe A klart å samle det nødvendige antall motortimer for service, men pumpe B har ikke ennå, noe som betyr at den kan' ikke betjent ennå, det er for tidlig.

Generelt er det som å skifte olje i en bil hver 15 kilometer. Noen kan stoppe dette på seks måneder, for andre vil det ta et år, og for andre vil det ta enda lengre tid, avhengig av hvor aktivt en bestemt bil brukes.

Det er det samme med pumper. I tillegg er det en annen variabel som påvirker behovet for vedlikehold - historien til vibrasjonsindikatorer. La oss si at vibrasjonshistorikken var i orden, pumpen har heller ikke fungert ennå ved klokken, noe som betyr at vi ikke trenger å reparere den ennå. Og hvis vibrasjonshistorikken ikke er normal, må en slik pumpe betjenes selv uten driftstimer. Og omvendt - med en utmerket vibrasjonshistorikk, betjener vi den hvis timene er jobbet.

Hvis du tar hensyn til alt dette og utfører vedlikehold på denne måten, kan du redusere kostnadene ved å betjene dynamisk utstyr med 20 eller til og med 30 prosent. Med tanke på produksjonens omfang er dette svært betydelige tall, uten tap av kvalitet og uten at det går på bekostning av sikkerhetsnivået. Og dette er en ferdig sak for bruk av IIoT i en bedrift.

Det er også mange tellere hvor informasjon nå samles inn manuelt ("Jeg gikk, så og skrev ned"). Det er også mer effektivt å servere alt dette på nettet, for å se i sanntid hva som brukes og hvordan. Denne tilnærmingen vil i stor grad hjelpe til med å løse problemet med bruk av energiressurser: Hvis du kjenner de nøyaktige forbrukstallene, kan du for eksempel tilføre mer damp til rør A om morgenen og mer damp til rør B om kvelden. Tross alt, nå bygges varmestasjoner med stor margin for å nøyaktig gi varme til alle komponenter. Men du kan bygge ikke med reserver, men klokt, distribuere ressurser optimalt.

Dette er den fasjonable datadrevne beslutningen, når beslutninger tas basert på fullverdig arbeid med dataene som er samlet inn. Skyer og analyser er spesielt populært i dag; på Open Innovations i år ble det snakket mye om big data og skyer. Alle er klare til å jobbe med stor data, behandle den, lagre den, men først må dataene samles inn. Det er mindre snakk om dette. Det er svært få maskinvareoppstarter i disse dager.

Den tredje IoT-saken er personellsporing, perimeternavigasjon osv. Vi bruker dette til å spore ansattes bevegelser og overvåke begrensede områder. For eksempel utføres det noe arbeid i sonen, der ingen fremmede skal være i den - og det er mulig å visuelt kontrollere dette i sanntid. Eller linjemannen gikk for å sjekke pumpen, og har vært lenge med den og beveger seg ikke - kanskje personen har blitt uvel og trenger hjelp.

Om standarder

Et annet problem er at det ikke finnes integratorer klare til å lage løsninger for industriell IoT. For det er fortsatt ingen etablerte standarder på dette området.

For eksempel hvordan ting er hjemme: vi har en wifi-ruter, du kan kjøpe noe annet til et smarthus - en vannkoker, en stikkontakt, et IP-kamera eller lyspærer - koble alt til eksisterende wifi, og alt vil fungere . Det vil definitivt fungere, for wifi er standarden som alt er skreddersydd.

Men når det gjelder løsninger for bedrifter, eksisterer ikke standarder for dette utbredelsesnivået. Faktum er at selve komponentbasen ble rimelig relativt nylig, noe som tillot maskinvare på en slik base å konkurrere med menneskelige ressurser.

Hvis vi sammenligner visuelt, vil tallene være omtrent samme skala.

En sensor for automatisert kontrollsystem for industriell bruk koster rundt $2000.
En LoRaWAN-sensor koster 3-4 tusen rubler.

For 10 år siden var det kun automatiserte prosesskontrollsystemer, uten alternativer, LoRaWAN dukket opp for 5 år siden.

Men vi kan ikke bare ta og bruke LoRaWAN-sensorer i våre virksomheter

Teknologivalg

Med wifi hjemme er alt klart, med kontorutstyr er alt omtrent det samme.

Det er ingen populære og ofte brukte standarder når det gjelder IoT i industrien. Det er selvfølgelig en haug med ulike industrielle standarder som bedrifter utvikler for seg selv.

Ta for eksempel trådløs HART, som ble laget av gutta fra Emerson – også 2,4 GHz, nesten samme wifi. Området med slik dekning fra punkt til punkt er 50-70 meter. Når du tenker på at arealet av våre installasjoner overstiger størrelsen på flere fotballbaner, blir det trist. Og én basestasjon i dette tilfellet kan trygt betjene opptil 100 enheter. Og vi setter nå opp en ny installasjon; i de innledende stadiene er det allerede mer enn 400 sensorer.

Og så er det NB-IoT (NarrowBand Internet of Things), levert av mobiloperatører. Og igjen, ikke til bruk i produksjon - for det første er det rett og slett dyrt (operatøren tar betalt for trafikk), og for det andre danner det en for sterk avhengighet av teleoperatører. Hvis du trenger å installere slike sensorer i lokaler som en bunker, hvor det ikke er kommunikasjon, og du trenger å installere tilleggsutstyr der, må du kontakte operatøren mot et gebyr og med uforutsigbare frister for å utføre en ordre for å dekke objektet med et nettverk.

Det er umulig å bruke ren wifi på sidene. Til og med hjemmekanaler er jammet på både 2,4 GHz og 5 GHz, og vi har et produksjonssted med et enormt antall sensorer og utstyr, og ikke bare et par datamaskiner og mobiltelefoner per leilighet.

Selvfølgelig er det proprietære standarder for fornuftig kvalitet. Men dette fungerer ikke når vi bygger et nettverk med mange forskjellige enheter, vi trenger en enkelt standard, og ikke noe lukket som igjen vil gjøre oss avhengige av en eller annen leverandør.

Derfor ser LoRaWAN-alliansen ut til å være en veldig god løsning, teknologien utvikler seg aktivt og har etter min mening alle muligheter til å vokse til en fullverdig standard. Etter utvidelsen av RU868-frekvensområdet har vi flere kanaler enn i Europa, noe som betyr at vi ikke trenger å bekymre oss for nettverkskapasitet i det hele tatt, noe som gjør LoRaWAN til en utmerket protokoll for periodisk innsamling av parametere, for eksempel en gang hvert 10. minutt eller en gang i timen.

Ideelt sett må vi motta data fra en rekke sensorer en gang hvert 10. minutt for å opprettholde et normalt overvåkingsbilde, samle inn data og generelt overvåke tilstanden til utstyret. Og når det gjelder linjemenn, er denne frekvensen i beste fall lik en time.

Hvorfor er det viktig for maskinvareutviklere å utføre cusdev av høy kvalitet

Hva mer mangler?

Mangel på dialog

Det er mangel på dialog mellom maskinvareutviklere og petrokjemi- eller olje- og gasskunder. Og det viser seg at IT-spesialister lager utmerket maskinvare fra et IT-synspunkt, som ikke kan brukes massevis i petrokjemisk produksjon.

For eksempel et stykke maskinvare på LoRaWAN for å måle temperaturen på rør: hengte det på røret, festet det med en klemme, hengte radiomodulen, lukket kontrollpunktet - og det er det.

Hvorfor er det viktig for maskinvareutviklere å utføre cusdev av høy kvalitet

IT-utstyret er absolutt egnet, men det er problemer for bransjen.

Batteri 3400 mAh. Selvfølgelig er det ikke det enkleste, her er det tionylklorid, som gir den muligheten til å jobbe ved -50 og ikke miste kapasitet. Sender vi informasjon fra en slik sensor en gang hvert 10. minutt, vil den tappe batteriet i løpet av seks måneder. Det er ingenting galt med en tilpasset løsning - skru av sensoren, sett inn et nytt batteri for 300 rubler hver sjette måned.

Hva om dette er titusenvis av sensorer på et stort nettsted? Dette vil ta enormt lang tid. Ved å eliminere arbeidstimene som brukes på gjennomganger, får vi like mye tid til å vedlikeholde systemet.

En ganske åpenbar løsning på problemet er å installere et batteri ikke for 300 rubler, men for 1000, men for 19 000 mAh, det må byttes en gang hvert 5. år. Dette er greit. Ja, dette vil øke kostnadene for selve sensoren litt. Men industrien har råd og industrien trenger det virkelig.

Ingen er en kasdev, så ingen vet om industriens behov.

Og om det viktigste

Og viktigst av alt, det de snubler over er nettopp på grunn av den banale mangelen på dialog. Petrokjemikalier er en produksjon, og produksjonen er ganske farlig, der et scenario med lokal gasslekkasje og dannelse av en eksplosiv sky er mulig. Derfor må alt utstyr uten unntak være eksplosjonssikkert. Og ha passende eksplosjonsbeskyttelsessertifikater i henhold til den russiske standarden TR TS 012/2011.

Utviklerne vet rett og slett ikke om dette. Og eksplosjonsbeskyttelse er ikke en parameter som bare kan legges til en nesten ferdig enhet, som et par ekstra lysdioder. Det er nødvendig å gjøre om alt fra selve brettet og kretsen til isolasjonen av ledningene.

Hva du skal gjøre

Det er enkelt – kommuniser. Vi er klare for direkte dialog, jeg heter Vasily Ezhov, eier av IoT-produktet hos SIBUR, du kan skrive til meg her i en personlig melding eller på e-post - [e-postbeskyttet]. Vi har ferdige tekniske spesifikasjoner, vi vil fortelle deg alt og vise deg hvilket utstyr vi trenger og hvorfor og hva som må tas hensyn til.

Akkurat nå bygger vi allerede en rekke prosjekter på LoRaWAN i grønn sone (der eksplosjonsvern ikke er et obligatorisk parameter for oss), vi ser på hvordan det er generelt, og om LoRaWAN er egnet til å løse problemer på en slik skala. Vi likte det veldig godt på små testnettverk; nå bygger vi et nettverk med høy tetthet av sensorer, hvor det er planlagt rundt 400 sensorer for én installasjon. Når det gjelder mengde for LoRaWAN er dette ikke mye, men når det gjelder nettverkstetthet er det allerede litt mye. Så la oss sjekke det ut.

På en rekke høyteknologiske utstillinger hørte maskinvareprodusenter for første gang fra meg om eksplosjonsbeskyttelse og dens nødvendighet.

Så dette er for det første et kommunikasjonsproblem som vi ønsker å løse. Vi er veldig for cusdev, det er nyttig og fordelaktig for alle parter, kunden får nødvendig maskinvare for sine behov, og utvikleren kaster ikke bort tid på å lage noe unødvendig eller fullstendig omskape eksisterende maskinvare fra bunnen av.

Hvis du allerede gjør noe lignende og er klar til å utvide til olje-, gass- og petrokjemisk sektor, er det bare å skrive til oss.

Kilde: www.habr.com

Legg til en kommentar