Kāpēc funkcionāla specifikācija ir būtiska, lai panāktu SCADA projektu

Week 2 (Jūnijs 2019).

$config[ads_text] not found
Anonim

SCADA sistēmas prasības

Labi dokumentētas SCADA sistēmas prasības, visticamāk, ir vissvarīgākais SCADA projekta veiksmes veicinātājs. Tas var šķist acīmredzams, bet tomēr tā teikt: funkcionālās specifikācijas rakstīšanai ir jānotiek PIRMS, lai sāktu darbu ar SCADA sistēmu .

Kāpēc funkcionālā specifikācija ir būtiska, lai panāktu SCADA projektu (fotoattēlu kredīts: ABB)

Lielākais izmaksu un grafika killer par projektu ir jāpārstrādā daļa vai visu dizainu . Tas ir tāpēc, ka katrs projekta posms ir veidots, balstoties uz iepriekšējā posmā veikto datu un darba pamatojumu.

Ja daži iekārtas funkcija vai I / O punkts vai signāla formāts tiek izlaista vai izlaista, projekta pievienošanas vai labošanas process vēlāk var radīt nopietnu negatīvu ietekmi.

Vēl viens iemesls, kas uzsver funkcionālās specifikācijas nozīmi, ir tāds, ka projekta izstrādes un ieviešanas posmā tiek pieņemti daudzi lēmumi un kompromisi, lai projekts tiktu saglabāts budžetā un grafikā . Tikai, stingri satverot sistēmas funkcionālās prasības, var pieņemt lēmumus par to, ko no projekta samazināt, objektīvi.

SCADA projekta funkcionālā specifikācija

Vispopulārākais veids, kā veidot izpratni par sistēmas prasībām, ir funkcionālās specifikācijas formā . Dokuments rūpīgi izklāsta strukturētu veidu, kā process darbojas un kā SCADA sistēma mijiedarbosies ar šo procesu.

Šķiet, ka nav funkcionālās specifikācijas standarta. Bet ir pareizi uzskatīt, ka jebkura sistēmas funkcionalitātes definīcija jāveic ar "lejupejošu" pieeju, proti, vispirms jāstrādā pie visaptverošām funkcijām, uzdevumiem un komunikācijām, un tad jādara viss konkrētākiem uzdevumiem un funkcijas.

Neatkarīgi no formāta, funkcionālajā spec ir jābūt šādiem elementiem:

  1. Aprakstiet procesu
  2. Aprakstiet procesa fizisko izkārtojumu
  3. Novērtējiet SCADA sistēmas "misijas kritiskumu"
  4. Aprakstiet, kā informācija plūsma caur sistēmu
  5. Definēt drošības stratēģiju
  6. Dokumentējiet trauksmes stratēģiju
  7. Definēt sistēmas testēšanu un pieņemšanas kritērijus

1. Aprakstiet procesu

Iekļaujiet materiālu ievadus, izvades, apstrādes posmus, cikla laikus, darbības periodus, pilnīgu sīku informāciju par parastajiem ekspluatācijas apstākļiem, kā arī par jebkādiem ārkārtas apstākļiem, kas varētu pastāvēt ikdienas darbībās.

Šajā iedaļā iekļaujiet, kādām kontroles sistēmām un algoritmiem jābūt dažādām iekārtām . Ja slēgtā cikla vadība ir plānota jebkuram līmenim, temperatūrai, spiedienam vai plūsmai, tā ir skaidri jānorāda.

Nepieciešamība pēc sarežģītākām kontroles cilpām, piemēram, kaskādēm vai plūsmas virzienam, vai vajadzība saskarties ar mainīgo frekvenču piedziņām, būtu jānosaka priekšā. Būtu jāapkopo arī īpašas vajadzības, lai ievietotu šos cilpas automatizētai vai manuālai kontrolei vai bez tās.

Atgriezties pie satura ↑

2. Aprakstiet procesa fizisko izkārtojumu

Iekļaujiet visus dokumentus, rasējumus, skices utt., Kas nodrošina sajūtu par to, kur procesi un saistītās iekārtas atrodas salīdzinoši viens ar otru un ar paredzētajām operatora uzraudzības / kontroles stacijām.

Iekļaujiet visus zināmos vai iespējamos ierobežojošos nosacījumus, kas var būt projekta parametros. Atbilstošas ​​elektroenerģijas trūkums vai ārkārtēji karstuma vai mitruma apstākļi vai klasificētu bīstamo teritoriju iesaistīšana ir jāatspoguļo projekta sākumā, nevis dažkārt pēc tam, kad lietas ir nokļuvušas.

Atgriezties pie satura ↑

3. Novērtēt SCADA sistēmas "misijas kritiskumu"

Kādas sekas varētu būt sekas, ja SCADA sistēmas atteice izraisa procesa izbeigšanos? Nelielas neērtības vai izkļūšana no katastrofas? Ko darīt, ja dati vai sakari ir zaudēti? Vai tas ir vienkārši darbības vai procesuāls traucēklis vai arī tiek apdraudēta sabiedrības drošība?

Daži strukturētas kļūmes analīzes veidi, piemēram, FMEA (neveiksmju režīma efektu analīze), ir izdevīgi šajā brīdī. Šis paņēmiens nosaka kļūmju iespējamību, šo kļūmju atklāšanas varbūtību un neveiksmes seku smaguma pakāpi.

Tas noved pie dažādu kļūmju, kas var notikt, rangu.

Atteices režīma efektu analīze (FMEA)

RangsSmagumsNotikumsNoteicamība
1Nav efektsRemote: neveiksme ir maz ticama <1 15 000 000Dizaina vadība atklās iespējamo cēloni vai mehānismu un nākamo kļūdu režīmu
2Sistēma darbojas ar minimālu iejaukšanosZems: salīdzinoši maz kļūmju <1 no 150 000Ļoti liela iespēja, ka dizaina vadība atklās iespējamo cēloni vai mehānismu un nākamo kļūdu režīmu
3Sistēma darbojas ar zināmu produktivitātes pasliktināšanosZems: relatīvi maz kļūmju <1 no 15 000Augsta izredzes projektēšanas kontrole noteiks iespējamo cēloni vai mehānismu un nākamo kļūdu režīmu
4Sistēma, kas darbojas ar ievērojamu veiktspējas pasliktināšanosVidēji: gadījuma defekti <1 no 2000Maza iespēja, ka dizaina vadība atklās iespējamo cēloni vai mehānismu un nākamo kļūdu režīmu
5Sistēma nav izmantojama bez bojājumiemVidējs: gadījuma defekti <1 400Moderna iespēja konstrukcijas kontrole noteiks iespējamo cēloni vai mehānismu un nākamo kļūdu režīmu
6Sistēma nav saderīga ar nelieliem bojājumiemVidēji: gadījuma defekti <1 no 80Maza iespēja, ka dizaina vadība atklās iespējamo cēloni vai mehānismu un nākamo kļūdu režīmu
7Sistēma nav derīga ar aprīkojuma bojājumiemAugsta: atkārtotas kļūdas <1 no 20Ļoti zema iespēja, ka dizaina vadība atklās iespējamo cēloni vai mehānismu un nākamo kļūdu režīmu
8Sistēma nav ekspluatējama ar destruktīvu bojājumu, nekaitējot drošībaiAugsta: atkārtotas kļūdas <1 no 8Attālinātās iespējas konstrukcijas kontrole noteiks iespējamo cēloni vai mehānismu un nākamo kļūmju režīmu
9Ļoti augsta riska pakāpe, kad iespējamais atteices režīms ietekmē drošu sistēmu ar brīdinājumuVey augstums: neveiksme ir gandrīz neizbēgama <1 3Ļoti izolēta iespēja projektēšanas kontrole noteiks iespējamo cēloni vai mehānismu un nākamo kļūdu režīmu
10Ļoti augsta riska pakāpe, kad potenciālais atteices režīms neietekmē drošu sistēmu bez brīdinājumaVey augsts: neveiksme ir gandrīz neizbēgama <1 2Dizaina vadība nevar noteikt iespējamo cēloni vai mehānismu un nākamo kļūdu režīmu

Šāda veida novērtējums virzīs lēmumus par aparatūras platformu, kas tiks izvēlēta, un nepieciešamību pēc atlaišanas procesoros, tīklos un datu glabāšanas ierīcēs.

Ļoti kritiskie procesi, tie, kas, ja tie nedarbojas pareizi, var radīt traumas vai būtiskus iekārtas vai īpašuma bojājumus, ir jāidentificē tā, kā tas noticis, izvēloties aparatūru, kas var būtiski atšķirt izmaksas.

Nododot atlaišanu CPU vai I / O vai comm saites, var panākt, bet ar ievērojamām izmaksām.

Atgriezties pie satura ↑

4. Aprakstiet, kā informācija plūsma caur sistēmu

  • Sākumā ar Operatora ievadi un ierakstu saglabāšanu ieraksta, ka uzņēmēji šobrīd glabā papīra formas, ko tās izveido vai piegādā, ierakstus žurnālu žurnālos utt .;
  • Informācija, kas ir pieejama, izmantojot esošos procesa instrumentus, veiktas apaļu vai sloksņu diagrammas;
  • Informācija, kas būs pieejama, izmantojot saiknes ar citām informācijas sistēmām, datu bāzēm, esošajām SCADA sistēmām utt .;
  • Informācija, kas ieplūdīs sistēmā, izmantojot SCADA I / O, temperatūru, spiedienu, plūsmu utt .;
  • un pabeidziet to, ko paredzēts izmantot SCADA informācijas galamērķim.

Vienkārši tiek parādīts vietējo operatoru darbstacijās? Izplatiet uz attālām vietām visā apgabala tīklā? Piespiedāt uz administratīvo lieldatoru datu bāzi? Vai formatēts aktīvās servera lapās, kurām var piekļūt iekštīklā vai internetā?

Šajā sadaļā jāiekļauj saraksts ar I / O punktiem, kas tiks konfigurēti sistēmā, inženieru vienību diapazons šajos punktos, vēlamais atjaunināšanas biežums katram punktam.

Atgriezties pie satura ↑

5. Definējiet drošības stratēģiju

Parasti vismaz 2 lietotāju līmeņi tiek ieviesti SCADA sistēmā. Pirmais līmenis ir paredzēts vidējiem lietotājiem, un tas parasti ļauj piekļūt visiem darbības ekrāniem un atļauj izmaiņām procesa noteikšanas punktos, lai nodrošinātu iekārtas netraucētu darbību.

Otrajam līmenim parasti tiek piešķirts lielāks piekļuves līmenis, piekļuve konfigurācijas ekrāniem un atļauja mainīt brīdinājuma punktus un datu apkopošanas frekvences .

Atgriezties pie satura ↑

6. Dokumentējiet trauksmes stratēģiju

Pirmkārt, definējiet punktus sistēmā, kas būs jāuztraucas. Nākamais, nosakiet, vai vēlaties, lai sistēmā būtu dažādi trauksmes signāli, kuriem ir dažādi smaguma pakāpe. Ilgstošas ​​novirzes starp iestatījuma vērtību un procesa mainīgo ne-kritiskam procesa parametram parasti radīs vienkāršu novirzes signalizāciju un vienkāršu operatora paziņojumu ir atbilstoša atbilde.

Viena veida novirze uz kritiskāku procesa vērtību var būt saistīta ar procesa bloķēšanu vai operatora korektīvo darbību vadlīnijām, tādēļ šim satraucošajam līmenim sistēmā ir jātiek atšķirīgai.

Trauksmes signāli, kas tiks savienoti ar procesa iekārtu ārkārtas izslēgšanu, vēl arvien jāsaņem prioritāte sistēmā .

Ir arī stratēģija prātā, kā trauksmes tiks reģistrētas, atzītas un izslēgtas no sistēmas. Iespējams, tas būs atšķirīgs dažādiem trauksmes signālu veidiem. Parasti tiek veidots logfails (un, iespējams, izdrukāts drukātā veidā), kas dokumentē katru darbību un notikumu, kas notiek SCADA sistēmā, ieskaitot trauksmes signālus.

Trauksmes signāli, kas ir operatora paziņojumi, bieži vien var būt pašattīrīti, ti, kad novirze pazūd, tāpat arī trauksme . Augstākam prioritārajam signālam jābūt fiksētam tā, lai operatora apstiprinājums kliegt klaksonu, bet tik ilgi, kamēr pastāv trauksmes stāvoklis, trauksmes signālu nevar pilnībā notīrīt.

Pārliecinieties, ka procesa inženieri, kas ir atbildīgi par procesu, pārskata un apstiprina galīgo trauksmes signālu un satraucošo stratēģiju sarakstu, kā arī darbības, kuras ir atbildīgas par kontroles procesa uzturēšanu, un apkopes personām, kurām būs jāreaģē trauksmes apstākļi.

Šo dažādo grupu motīvi un mērķi ir diezgan atšķirīgi, tāpēc pirms galīgā saraksta un stratēģijas apstiprināšanas notiks daudz sarunu.

Procesu inženieri parasti vēlas vairāk satraucoši nekā praktiski, kā rezultātā rodas daudz traucējumu trauksmes signāli. Tie ir uzņēmējiem apgrūtinoši, un drīz pēc to ieviešanas diezgan bieži tiek izstumti vai ignorēti. Daudz labāk ir uzstādīt samazinātu signalizācijas sistēmu, kas operatoriem ir nozīmīgi un noderīgi.

Apkopes cilvēki parasti izvēlas trauksmes signālus, kas var darboties kā ierīču darbības traucējumu prognoze, nevis procesu novirzes, tāpēc viņiem būs jāpatur prātā, ka pirmās divas grupas var aizmirst.

Atgriezties pie satura ↑

7. Noteikt sistēmas testēšanas un pieņemšanas kritērijus

Visbeidzot, attiecībā uz funkcionālajām specifikācijām ir jānorāda to loma SCADA sistēmas testēšanā un apstiprināšanā pēc ekspluatācijas uzsākšanas .

Ir svarīgi saglabāt pārbaudes jēdzienu laikā, kad tiek ģenerēti funkcionālie parametri. Par katru funkciju, kas aprakstīta specifikācijā, vismaz jāprojektē un jāapkopo pārbaudes vai verifikācijas metode .

Šis dokuments būs noderīgs vēlāk, kad tas kļūs par pamatu jūsu sistēmas pieņemšanas pārbaudes plānam. Ja jūs nevarat iedomāties aprakstošās funkcijas testa vai verifikācijas darbību, tad varbūt jums tiešām šī funkcija nav nepieciešama vai arī jūs to nesaprotat pietiekami labi, lai pilnībā aprakstītu.

Atgriezties pie satura ↑

Atsauce // SCADA sistēmas notekūdeņu attīrīšanā, Stephan J. Sosik, izpilddirektors Process-Logic, LLC

Saistītie elektriskie ceļveži un izstrādājumi

MEKLĒŠANA: raksti, programmatūra un ceļveži