Millele see artikkel vastab
Artikli kokkuvõte
PLC-loogika ettevalmistamiseks IEC 61508 3. väljaande süsteemse suutlikkuse audititeks vajavad insenerid käitumuslikke tõendeid, mis näitavad, et tarkvara reageerib määratletud tõrketingimustes deterministlikult ja ohutult. Simulatsioonikeskkonda, nagu OLLA Lab, saab kasutada piiritletud kontroll-liivakastina ohutusomaduste testimiseks, tõrkehalduse dokumenteerimiseks ja loogika tugevdamiseks enne ametlikku auditit ja füüsilist valideerimist.
Tarkvara ohutus IEC 61508 standardi kohaselt ei ole peamiselt küsimus selles, kas kood näeb korrektne välja. See on küsimus sellest, kas loogika käitub tõestatult õigesti, korratavalt ja ohutult ka siis, kui protsess väljub tavapärastest raamidest.
See eristus on 3. väljaandes veelgi olulisem, kus tõendamiskoormus tarkvara süsteemse käitumise osas pigem karmistub kui leeveneb. Riistvara tõrkeanalüüs keskendub endiselt tõenäosuslikele tõrkemeetmetele, nagu PFD ja PFH. Tarkvara ei rikne vananemise tõttu kapis; see ebaõnnestub süsteemselt disainivigade, spetsifikatsioonilünkade, soovimatute interaktsioonide ja testimata äärejuhtumite tõttu.
Hiljutine Ampergon Vallis'e siseanalüüs toetab seda seisukohta. OLLA Lab'is läbi viidud 500 simuleeritud ohutusfunktsiooni (SIF) testjuhtumi analüüsi käigus kukkus 68% esialgsetest loogikakavanditest läbi vastupidavuskontrolli, kui neid testiti analoogsignaali triivi, seisvate sisendväärtuste või vahemikust väljas olevate sundväärtustega. See kinnitab väidet, et esimese ringi loogika jätab sageli tähelepanuta ebanormaalsete olekute haldamise.
Mis muutub IEC 61508 3. väljaandes tarkvara ohutuse osas?
Praktiline muudatus seisneb suuremas rõhuasetuses süsteemse suutlikkuse tõestamisele reprodutseeritavate tõenditega, mitte ainult elutsükli järgimise deklareerimisele.
IEC 61508 on alati käsitlenud tarkvara riistvarast erinevalt, kuna tarkvaratõrked on süsteemsed, mitte juhuslikud. Praktikas tähendab see, et 3. väljaande arutelud keskenduvad sellele, kas arendus- ja kontrolliprotsess suudab demonstreerida, et tarkvara ohutusnõuded on tõlgitud kontrollitud ja testitavasse käitumisse.
Mis on süsteemne suutlikkus PLC-tarkvara mõistes?
Süsteemne suutlikkus on arendusprotsessi ja sellest tuleneva loogika demonstreeritud võime vältida, tuvastada ja kontrollida süsteemseid tõrkeid sihtotstarbelise ohutusfunktsiooni nõutaval tasemel.
PLC-inseneride jaoks muutub see definitsioon konkreetseks, kui see tõlkida vaadeldavateks käitumisteks:
- Ohutusloogika täidetakse prognoositaval ja piiritletud viisil.
- Olekute üleminekud on selged ja taastatavad.
- Tõrked viivad süsteemi määratletud ohutusse olekusse.
- Mitte-ohutusloogika ei tohi rikkuda ega viivitada ohutuskäitumist.
- Testitõendid on reprodutseeritavad ja nõuetega jälgitavad.
Millised on 16 süsteemse suutlikkuse jaoks nõutavat ohutusomadust?
Täpne rühmitus võib metoodikate lõikes erineda, kuid praktiline tarkvara ohutusomaduste komplekt, mida kasutatakse edasijõudnud funktsionaalse ohutuse töös, hõlmab järgmisi käitumisi:
- Terviklikkus (Completeness)
- Korrektsus (Correctness)
- Järjepidevus (Consistency)
- Determinism (Determinism)
- Vastupidavus (Robustness)
- Vabadus häiretest (Freedom from interference)
- Jälgitavus (Traceability)
- Kontrollitavus (Verifiability)
- Hooldatavus (Maintainability)
- Lihtsus (Simplicity)
- Kaitstus (Defensiveness)
- Taastatavus (Recoverability)
- Piiritletud (Boundedness)
- Vaadeldavus (Observability)
- Tõrketurvaline käitumine (Fail-safe behavior)
- Testitavus (Testability)
Kuidas peaksid insenerid määratlema „simulatsioonivalmiduse“?
„Simulatsioonivalmidus“ (Simulation-Ready) tuleks määratleda operatiivselt. Simulatsioonivalmis insener suudab tõestada, vaadelda, diagnoosida ja tugevdada juhtimisloogikat realistliku protsessikäitumise vastu enne, kui see loogika jõuab elava protsessini.
Kuidas saab OLLA Lab'i kasutada piiritletud kontroll-liivakastina?
OLLA Lab'i tuleks positsioneerida riskikindla kontroll-liivakastina, mitte sertifitseerimismootorina. Selle operatiivne väärtus on lihtne: insenerid saavad luua redeldiagrammi loogikat veebipõhises redaktoris, käivitada seda simulatsioonis, kontrollida muutujaid ja I/O käitumist ning valideerida loogikat stsenaariumipõhiste masinamudelite ja digitaalsete kaksikute vastu enne füüsilist kasutuselevõttu.
Milliseid tõrkejuhtumeid peaksid insenerid testima?
Insenerid peaksid testima tõrkejuhtumeid, mis paljastavad loogikas peituvad varjatud eeldused:
- Andur väljaspool vahemikku
- Analoogtriiv
- Värisev diskreetne sisend
- Seisev sisendolek
- Lubava signaali kadumine
- Toite tsükkel või taaskäivitamise tingimus
- Käsitsi lähtestamise väärkasutus
- Järjestuse katkestamine
- Side katkemise surrogaat
- Blokeeringute lahkarvamus
Kuidas näeb välja auditi jaoks valmis insenertehniliste tõendite pakett?
Auditi jaoks valmis pakett peaks dokumenteerima insenertehnilise põhjenduse ja käitumusliku tõestuse. Kasutage iga ohutusega seotud stsenaariumi jaoks struktuuri: süsteemi kirjeldus, operatiivne määratlus, loogika ja seadme olek, sisestatud tõrkejuhtum, tehtud muudatus ja õppetunnid.
Ampergon Vallis Lab on pühendunud tööstusautomaatika ja funktsionaalse ohutuse standardite edendamisele, pakkudes tehnilisi juhiseid ja tööriistu keerukate PLC-süsteemide valideerimiseks.
Käesolev artikkel on koostatud tuginedes IEC 61508 3. väljaande nõuetele ja tööstuslikele parimatele tavadele. Simulatsioonitulemused ja metoodikad on illustratiivsed ning mõeldud insenertehniliseks suunamiseks.