unicon ANALYS AV DATORER I KONTROLLRUM FÖR KÄRNKRAFTVERK SLUTRAPPORT UNICON FÖRENADE KONSULTER

Transkript

1 uncon ANALYS AV DATORER I KONTROLLRUM FÖR KÄRNKRAFTVERK SLUTRAPPORT UNICON FÖRENADE KONSULTER

2 uncon STEN LEIJONHUFVUD URS LINDHOLM ANALYS AV DATORER I KONTROLLRUM FÖR KÄRNKRAFTVERK SLUTRAPPORT t

3

4 INNEHALLSFÖRTECKNING Sd, 0. SAMMANFATTNING 1. INLEDNING Uppdraget Grundsyn Defnton av "vtala funktoner" Avgränsnngar Målgrupper och läsanvsnng 13 NULÄGE OCH TEKNISKA MÖJLIGHETER Kontrollrumsdatorer Funktoner för kontrollrumsdatorer Datorteknsk utvecklng ÖVERGRIPANDE KRAV Systemkrav 25 ) 3.2 Prncper för kravsättnng GRUNDLÄGGANDE BEGREPP MM 33 ) 4.1 Defnton av fel, tllförltlghet mm Feldetekterng, fellokalserng, felsprdnng Recovery 37 } 4.4 Feltolerans Redundans Tllämpnngstransparens SYSTEMUTFORMNING Systemstorlekar Decentralserad systemlösnng Centralserad systemlösnng Systemkonfguratoner med redundans Separerng av system Specalsystem 52

5 6. UTRUSTNINGAR Feltyper Tllgänglghetspredkterng Analys av några datorsystemdelar 63 é 6.4 Tllförltlghetshöjande konstruktoner Datorkonfguratoner med redundans Yttre mljöbetngelser 83 I 7. PROGRAMVARA 85 ^ 7.1 Felkaraktär 85 å 7.2 Programvaruuppbyggnad Standardprogramvara Tllförltlghetspredkterng 115 m 8. DATA Allmänt 123 å 8.2 Statska data Dynamska data Recovery och redundans 139 å 9. SYSTEM- OCH PROGRAMUTVECKLING Behovsanalys 149 É 9.2 Systemutvecklngsprocessen Systemspecfcerng Programsystemutformnng 168 m 9.5 Modulutvecklng Testnng och systemntegraton Dokumentaton 183 m 9.8 Organsaton och personal SYSTEMANSKAFFNING Organsaton Upphandlng av utvecklngsuppdrag Kvaltetsstyrnng av programutvecklng Verferng och valdserng 200

6 11. DRIFT OCH UNDERHÄLL Drftorgansaton Operatv drft 209 fy 11.3 Datorsystemdrft 211 * 11.4 Dokumentaton och utbldnng Allmänt om drftsäkerhet och underhåll 217.) 11.6 Underhåll av utrustnngar 219 k 11.7 Underhåll och modferng av programvara 223 och data 12. SLUTSATSER OCH RIKTLINJER Sammanfattnng och slutsatser Jämförelse datorsystem konventonella utrustnngar 12.3 Datorbaserade system med vtala funktoner Råd och rktlnjer SKI:s roll REFERENSER 247 Blagor 1. Ordlsta 2. Beställnng och projektbeskrvnng 3. Inventerng av kontrollrumsdatorer svenska kärnkraftverk 4. Programvarustruktur för generellt drftövervaknngssystem

7

8 J 0. SAMMANFATTNING ' Denna forsknngsrapport har utarbetats av UNICON Förenade Konsulter på uppdrag av statens Kärnkraftsnspekton (SKI) och behandlar datorsystem kontrollrum för kärnkraftverk. > Om ett sådant datorsystem skall kunna användas vd poten- ' tella haverstuatoner måste det vara konstruerat för att fungera extremt ovanlga och kanske ej förutsedda stuatoner. Analyserna och slutsatserna rapporten skall ses ' mot denna bakgrund. Rapporten försöker att belysa problemområdet sa allsdgt som möjlgt och olka kaptel analyseras:. - systemutformnng utrustnngar programvara - data system- och programutvecklng systemanskaffnng drft och underhåll De väsentlgaste slutsatserna är sammanfattnngsvs: De flesta tllförltlghetsproblem hos utrustnngar kan lösas genom dubblerng av krtska enheter Tllförltlghet hos programvara är en egenskap som endast kan skapas samband med utvecklngen. Tllförltlghet hos datorsystem extremt ovanlga stuatoner kan ej anges kvantferbara och verferbara termer, utom möjlgen för mycket små och funktonellt enkla datorsystem. För att uppnå största möjlga tllförltlghet hos ett sådant datorsystem, bör det

9 8 bara nnehålla en eller ett fåtal funktoner vara funktonellt enkelt, dvs funktonerna skall vara enkla att specfcera och realsera ett ltet datorsystem vara tllämpnngstransparent, dvs datorsystemets nterna arbete skall största möjlga utsträcknng vara oberoende av vad som sker kärnkraftanläggnngen. ( En datorrealserng är tllförltlghetsmässgt konkurrenskraftgt med andra möjlga realserngar av funktoner med extremt höga tllförltlghetskrav av följande orsaker: Är en funkton så enkel att den kan realseras ( med andra typer av utrustnngar, kan den trolgen också realseras med ett mycket enkelt och tllförltlgt datorsystem. ( Kan en funkton ej teknskt realseras med andra utrustnngar bör ett datorsystem kunna kom- ( plettera männskan och förmodlgen utgör de tllsammans ett bättre alternatv än ngen realserng alls eller att funktonen måste lösas av männskan enbart. OBSl Den som vll läsa hela eller delar av rapporten rekommenderas att första hand läsa kap 1-3 samt kap 12. Se vdare läsanvsnng kap

10 1. INLEDNING 1.1 UPPDRAGET Statens Kärnkraftnspekton (SKI) har av UNICON Förenade Konsulter beställt ett forsknngsprojekt avseende "Analys av datorer kontrollrum för kärnkraftverk". Forsknngsprojektets syfte är att ta fram och bereda underlag för formulerng av övergrpande krav på tllförltlg- het hos utrustnngar och programvara datorsystem för kontrollrum svenska kärnkraftverk. ) Målsättnngen är första hand att få fram underlag för att kunna formulera praktskt verferbara krav. Underlagen avses vdare möjlgaste mån vara oberoende av teknska realserngar dock, utan att tappa kontakten med aktuella tllämpnngar. k. Forsknngsprojektets omfattnng och nrktnng framgår av SKI:s beställnng och projektbeskrvnng blaga 2. Det säkerhetsbegrepp som används projektbeskrvnngen är ej I helt lka det som är gängse nom kärnkraftndustrn. Därför har rapportens rubrk ändrats och vssa formulerngar denna slutrapport har ändrats relatvt den prelmnära k slutrapporten (se avsntt 1.3). 1.2 GRUNDSYN I projektet tllämpas en totalsyn på datorsystem. Med undantag av de avgränsnngar som anges avsntt 1.4, är syftet att behandla alla faktorer som är av tllförltlg hetsmässg betydelse för datorer kontrollrum. Analysen baseras på följande huvudmoment: Systemutformnng Utrustnngar (hårdvara) - Programvara Data System- och programutvecklng Systemanskaffnng Drft- och underhåll

11 10 Detta totalsynsätt nnebär, mt-d tanke på projektets omfattnng, att avkall måste göras beträffande detaljerngsnvån. Denna nrktnng av forsknngsprojektet baseras på följande uppfattnng: En totalsyn beträffande tllförltlghetsaspekter är långt mer väsentlg än ensklda tllförltlghetsbefrämjande åtgärder. Jämför "Ingen kedja är starkare än dess svagaste länk". En väl grundad totalsyn på tllförltlghetsproblem är en förutsättnng för att man skall kunna ställa väl avvägda krav på datorsystem. 1.3 DEFINITION AV "VITALA FUNKTIONER" I kärnkraftndustrn tllämpas följande defnton av säkerhetsfunktoner. ************************************************** * * * * * * * * Säkerhetsfunktoner utgörs av de funktoner som erfordras för att förhndra eller begränsa verknngarna av potentella haverer, som skulle kunna utgöra otllåtna rsker ur halso- och säkerhetssynpunkt för omgvnngen krng ett kärnkraftverk. ************************************************** Ett säkerhetssystem är en teknsk och organsatorsk realserng av en eller flera säkerhetsfunktoner. * * * * * * * * * * * * * * * * *

12 11 Med den gängse snäva tolknngen av begreppet säkerhetsfunkton förekommer nga datorbaserade säkerhetssystem kontrollrummen svenska kärnkraftverk. Inga sådana datorbaserade säkerhetssystem planeras. Vssa funktoner en kontrollrumsdator skulle kunna ha en vtal betydelse en potentell haverstuaton utan att därför utgöra säkerhetsfunktoner snäv betydelse. I denna slutrapport har begreppet "säkerhetsfunkton" utgått och ersätts av följande begrepp. ************************************************** * Med vtal funkton en potentell haver- * stuaton (el. vtal funkton) menas * denna rapport en funkton som har vtal * säkerhetsmässg betydelse, men ändå ej utgör * en säkerhetsfunkton enlgt gängse praxs * * nom kärnkraftndustrn. * *************************************************** Ett system^ av vtal betydelse är således en teknsk och organsatorsk reals rng av en eller flera vtala funktoner. De funktoner som ej klassfceras som "vtala funktoner" kallas denna rapport "övrga funktoner". t Denna defnton nnebär att vssa funktoner kommer att betraktas som "övrga funktoner" trots att de för kraftproducenten är ytterst vkt-ga. Det kan exempelvs vara funktoner som är väsentlga för att förhndra personskador eller för att förhndra haverer av dyrbara anläggnngsdelar (turbn, generator). Med tanke på forsknngsprojektets nrktnng kommer rapporten begreppet "system av vtal betydelse" allmänhet vara lk- " tydgt med "datorsystem med vtala funktoner vd en potentell hayerstuaton".

13 AVGRANSNINGÅR Forsknngsprojektet avser "Analys av datorer kontrollrum för kärnkraftverk". V skall försöka belysa vad som faller nom denna ram så allsdgt som möjlgt. I projektet gäller följande avgränsnngar: Datorer för kontrollrum - övrga datorer Med datorer för kontrollrum menas sådana datorsystem som utnyttjas av den drftpersonal kontrollrummet, vlken har ansvar för den operatva drften av ett kärnkraftverk. Det förutsätts att en kontrollrumsdator används för att övervaka och ev styra kärnkraftanläggnngen är ansluten tll processen on-lne (kärnkraftanläggnngen) har ett männska/masknsystem kontrollrummet Många av de resonemang och slutsatser som framförs rapporten kan naturlgtvs även tllämpas för andra typer av datorsystem med höga tllförltlghetsskrav, även om de nte utgör kontrollrumsdatorer eller nnehåller vtala funktoner vd en potentell haverstuaton. Datorsystem - männska Ett datorsystem utgörs av all utrustnng nklusve programvara och data fram tll gränsytan mot männskan. I datorsystem ngår således all utrustnng, programvara, data m m, för presentaton eller för att på annat sätt nformera eller ta emot nformaton från männskan. Forsknngsprojektet behandlar datorsystem men ej hur männskan kan tllgodogöra sg teknskt sett korrekt nformaton och hennes förmåga att handha teknsk utrustnng (t ex tangentbord). Det förutsattes att nformaton presenteras på lämplgt sätt och att utformnngen övrgt av datorsystemen är sådan att mssuppfattnngar och felaktgt handhavade möjlgaste mån undvkes. Däremot fnns en klar medvetenhet om att männskan är en många avseenden svag länk komplcerade system och att bl a datorsystem måste vara utformade med tanke på detta förhållande.

14 13 Datorsystem - process I datorsystemet ngår ej gvare m m som förser datorsystemet med processnformaton. Ej heller ngår ställdon som påverkar processen. I rapporten behandlas således ej problem med gvare och ställdon utom den aspekten att man måste förutsätta att dessa kan vara felaktga eller på annat sätt ofullkomlga. Realserng - tllämpnng I rapporten behandlas realserng av datorsystem nklusve programvara, data m m. Vlka tllämpnngar som är lämplga eller olämplga för kontrollrumsdatorer behandlas endast prncpellt och översktlgt. De tllämpnngssksser som behandlas, utgör endast exempel för att konkretsera framställnngen. Val av funktoner för kontrollrumsdatorer styrs av faktorer, som lgger utanför ramen för detta projekt. 1.5 MÅLGRUPPER OCH LÄSANVISNING Förutom uppdragsgvaren, SKI, är målgruppen för denna rapport första hand den personal på kraftföretagen, som skall ställa :rrav på datorsystem för kontrollrum kärnkraftverk. Generellt sett är kvaltetskraven höga på datorer denna typ av tllämpnng. Även om det nte skulle fnnas några drekta vtala funktoner enlgt defntonen denna rapport, kan rapporten ge väglednng för datorsystem med exempelvs ekonomskt mycket vktga funktoner. Rapporten är ej prmärt rktad tll dem som ska.tl konstruera tllförltlga datorsystem. Behandlngen av olka metoder, systemlösnngar m m är nte tllräcklgt ngående för detta ändamål. ************************************************** * * För att underlätta en snabb genomläsnng av * rapporten har vssa vktga defntoner, * slutsatser m m ramats n. * *. * **************************************************

15 14 t Kaptel 4-11 omfattar de egentlga analyserna. Dessa kaptel omfattar större delen av rapporten och de fordrar ett vsst datorkunnande. För den som har begränsad td tll förfogande lämnas följande rekommendaton: * * I första hand bör kaptlen 1-3 och 12 läsas. * * Kaptel 4 bör läsas som en ntrodukton tll * * övrga analyskaptel. Därefter kan valda * * delar av kaptel 5-11 läsas. * ************************************************** I blaga 1 fnns en ordlsta, som kortfattat beskrver använda fackuttryck, defntoner mm. PraktsVt taget all kvalfcerad ltteratur om datorsystem är skrven på engelska. De.na rapport skrvs på svenska och med svenska fackuttryck och benämnngar. Det är relatvt enkelt så länge som man rör sg med allmänt förekommande begrepp. När det gäller ovanlga begrepp är det svårt att fnna bra översättnngar, som dels entydgt täcker motsvarande engelska begrepp och dels ej står strd med andra översättnngar som används. En alltför långt gående översättnngsver kan leda tll rsk för mssförstånd. V ber därför läsaren ha överseende med att det bland förekommer engelska fackuttryck texten. ^ ^ 1 f

16 15 2. NULÄGE OCH TEKNISKA MÖJLIGHETER I detta kaptel redovsas först en översktlg nventerng av befntlga och planerade kontrollrumsdatorer. Vdare sksseras några möjlga funktoner för kontrollrumsdatorer, som eventuellt skalle kunna utgöra s k vtala funktoner. Slutlgen sksseras några trender nom datorteknken och möjlgheterna att nya datorteknska landvnnngar kan påverka utformnngen av kontrollrumsdatorer. 2.1 KONTROLLRUMSDATORER Datorer har använts kärnkraftsammanhang Sverge allt sedan de första kärnkraftverken togs drft. I blaga 3 redovsas kortfattat de kontrollrumsdatorer, som är drft eller planeras för svenska kärnkraftverk. Kontrollrumsdator->rna kan utvecklngsmässgt ndelas tre nvåer: - Den första generatonen av kontrollrumsdatorer används huvudsaklgen för loggnngs- och beräknngsändamål. Männska/masknsystemet är mycket enkelt. Datorsystemet är komplement tll övrg kontrollutrustnng och kärnkraftanläggnngen kan drvas under längre td utan dator. - Även den andra generatonens datorsystem används för loggnng och beräknngar men dessutom för processövervaknng. Männska/masknsystemet är kompletterat med bldskärmar för vsnng av tabeller och dagram. Inte heller dessa kontrollrumsdatorer är krtska för drften av kärnkraftanläggnngarna. Den senaste generatonen av kontrollrumsdatorer har ännu nte nstallerats utan är på planerngs- och projekterngsstaderna. Datorsystemen skall nnehålla fler funktoner än tdgare system och de kommer även att nnehålla nformaton, som nte fnns de övrga konventonella kontrollutrustnngarna. Männska/masknsystemet består av flera arbetsplatser med avancerad bldpresentaton på färgbldskärmar. Denna generaton av kontrollrumsdatorer är, jämfört med tdgare generatoner, mer väsentlg för drften av kärnkraftanläggnngarna. Datorsystemen är därför dubblerade av tllgänglghetsskäl.

17 FUNKTIONER FÖR KONTROLLRUMSDATORER Allmänt En modern kontrollrumsoator kan ges så stor kapactet att man teoretskt kan lägga n ett stort antal funktoner. Den väsentlgaste begränsnngen utgörs av krav på att funk- < tonerna skall vara av verklg nytta och ekonomskt motverbara. Kretsen av funktoner begränsas ytterlgare av tllförltlghetsmässga aspekter vd menng (dvs ej bara för sådana funktoner, som defneras som s k vtala funktoner denna rapport). Det går nte att generellt fastställa vad en kontrollrums- " dator skall användas tll. Man måste analysera vlken drftstuaton kontrollrunsdatorn skall understödja. Denna kan vara relatvt olk från kärnkraftanläggnng tll kärn- " kraftanläggnng. Dessutom kommer nya behov att uppstå under anläggnngens lvslängd. A För att konkretsera resonemangen sksseras några exempel på funktoner av mer eller mndre vtal natur, som skulle kunna vara aktuella för kontrollrumsdatorer. Om de skall anses som klart vtala funktoner en potentell haverstuaton eller om de är lämplga att nföra vd svenska kärnkraftverk dskuteras ej denna rapport Presentaton av processtatus å En kontrollrumsdator kan nnehålla en stor del av den " väsentlga processnformatonen som fnns tllgänglg, såsom mätvärden, statussgnaler, felsgnaler etc. Informatonen å kan presenteras på bldskärmar, vanlgen form av process- " blder färg. Färg och symboler kan användas för att markera olka lägen, status eller onormala värden. Det fnns stor frhet att nom bldskärmens vsserlgen begränsade utrymme åstadkomma blder för olka ändamål å alltfrån överskter tll detaljblder. Samma dataelement " (t ex mätvärden) kan presenteras på flera olka blder mot lten merkostnad tll skllnad mot konventonella kontroll- å tavlor, där man av utrymmes- och kostnadsskäl vanlgen bara ^ presenterar varje dataelement på ett ställe. I alla svenska kärnkraftverk har konventonella kontroll- " tavlor och manöverpulpeter en central roll kontrollrummet, men bldskärmsteknken kan komplettera tavelpresentatonen. å T ex kan nformatonen struktureras valfrtt, dataelementen kan märkas, se vdare kaptel 8.

18 Händelseskrvnng, sgnalföljdsregstrerng Händelseskrvnng är lksom bldskärmspresentaton normala funktoner för moderna datorserade drftövervaknngssystem. Inträffade händelser, t ex felsgnaler och gränsvärdesöverskrdanden, regstreras med tdsmarkerng. Sgnalföljdsregstrerng är prncp samma sak som händelseskrvnng men tdsupplösnngen och upplösnng av ordnngsföljden av händelser är noggrannare, 1-10 ms, jämfört med några sekunder för normal händelseskrvnng. Det fnns huvudsaklgen två syften med denna typ av regstrerng. Dels skall den kunna tjäna som underlag för en omedelbar felanalys, som kontrollrumspersonalen måste göra för att kunna vdta rktga åtgärder. Dels skall den utgöra underlag för efterföljande felanalys, så att man vd behov skall kunna förbättra utrustnngar, drftrutner m m Sgnalbehandlng Händelse- och sgnalföljdsregstrerng tllämpat på stora och komplcerade anläggnngar, såsom kärnkraftverk, kan nnebära att ett mycket stort antal händelser regstreras vd ett och samma störnngstllfälle. Informatonsmängden är oöverskådlg och specellt den omedelbara felanalysen är svår att genomföra. Det man önskar sg är att datorn gör en "ntellgent" redukton av all regstrerad nformaton. Några metoder som tllämpas med mer eller mndre framgång sksseras nedan. Noggrann tdsupplösnng kan åstadkommas med sgnalföljdsregstrerngen. Ideen är att man lätt skall kunna särsklja de första och därmed utlösande händelserna. Nackdelarna är dock: De första händelserna kan ha en ganska lös kopplng tll efterföljande allvarlgare händelser. Dvs de första händelserna kan vara ganska ontressanta. Fördröjnngstder på gvarsdan (reläer etc) kan vara så stora att den regstrerade tdsordnngen blr felaktg. Klassfcerng av sgnaler ett antal klasser. Klasserna kan vara t ex anläggnngsdelar, mätpunktsklasser, prortetsklasser eller en kombnaton av dessa. Vd presentaton eller utskrft kan man välja vlka klasser av sgnaler som skall vsas. Nackdelarna med denna metod är bl a Olka felstuatoner kan nnebära Oka klassfcerng för en och samma sgnal

19 18 Den nbördes ordnngen vlken sgnalerna uppträder är ofta väsentlg för klassfcerngen Intressanta utlösande sgnaler kan ha låg prortet. Kombnerng av olka sgnaler tll en samlngssgnal. Nackdelarna är bl a - Kombnerngen bygger väsentlg utsträcknng på en analys av vlka fel som kan nträffa. Denna analys är besvärlg att genomföra och kan ej täcka oförutsedda stuatoner. Det kan bl komplcerade logska strukturer, som är svåra att verfera (testa) att de är korrekta. Ett sätt att övervnna en del av nackdelarna är att kombnera metoderna. Detta sn tur medför att sgnalbehandlngen blr ännu mer komplcerad och svår att verfera Drftlägeskontroll Vd drftstörnngar kan drftläg-ssförändrngar kontrolleras mot förutbestämda händelsekedjor. Efter en statusförändrng av vssa förväg defnerade. objekt eller mätpunkter aktveras drftlägeskontrollen. Den kan övervaka att olka objekt och mätpunkter ntar förutbestämda drftlägen nom en vss td efter utlösande händelser eller efter statusförändrng för föregående objekt händelsekedjan. Om anläggnngen ntar ej förutbestämda drftlägen sker särskld larmrapporterng. I övrgt anges t ex händelserapporterngen start och slut av drftlägeskontroll för en händelsekedja. Prncpen kan även användas för generell kontroll av drftläget anläggnngen genom att t ex operatör nterar en drftlägeskontroll (med tdsförskjutnngen = 0 mellan olka objekt) Operatonstdsövervaknng Ett stort antal deloperatoner anläggnngen skall genom- * föras nom en begränsad tdsrymd. Exempel på sådana operatoner är styrstavsnskjutnng, öppnng/stängnng av ven- A tler, förändrng av vätskenvåer osv. *. Här kan datorsystemet övervaka att dessa operatoner utförs å nom angven tdsrymd. I annat fall uppmärksammas operatören * på detta genom larm. 4

20 Rmlghetsanalyser Status för de vktgaste delsystemen en kärnkraftanläggnng mäts genom redundanta raätkanaler. Man kan också erhålla nformaton om ett delsystems status på olka sätt, exempelvs måste flödet genom ett rör med stängd ventl vara lka med noll. Exempel på sådana delsystem är nvå och tryck reaktortank, HC-flöde, temperatur och tryck reaktornneslutnng. För dessa delsystem jämförs och rmlghetskontrolleras mätresultat mot fördefnerade maxmala avvkelser. Om resultatet lgger utanför dessa gränser genereras larm Störnngsregstrerng Utvalda mätvärden lagras regelbundet cyklska dataareor så att man alltd har undanlagrat alla mätvärden under t ex 1 mnut före aktuell tdpunkt och därutöver skall fnnas kapactet för undanlagrng av alla mätvärden under några mnuter efter aktuell tdpunkt. För vssa fördefnerade händelser fryses aktuell tdpunkt och man erhåller en undanlagrng av alla mätvärden omkrng händelsen. Dessa mätvärden kan sedan presenteras va datorns normala presentatonsfunktoner. Funktonen kan ha stor betydelse för analys av en störnngsstuaton. Störnngsregstrerng kallas bland PMR (Post Mortem Revew). ' Tllståndsestmerng. Tllståndsestmerng kan ses som en vdareutvecklng och ' generalserng av sgnalbehandlngsfunktonen. j I datorn fnns en matematsk modell av den process, som * skall övervakas. Modellen kan bestå av allt från en uppsättnng enkla lnjära samband och logska vllkor tll L komplcerade system av olnjära dfferentalekvatoner. Det " vktga är att modellen fungerar för alla de processtllstånd man vll kunna utnyttja estmerngen för. * Estmerngen kan ha olka syften: - Beräkna processtorheter som ej kan mätas Öka noggrannheten uppmätta processvärden ' - Fnna vlka uppmätta processvärden som är felaktga

21 20 Fnna vlket av ett antal förutsedda tllstånd processen befnner sg. Det är knappast möjlgt att samtdgt uppnå alla syftena fu^1 utsträcknng. Man måste förhand bestämma sg för det syfte man första hand vll uppnå och välja estmerngsmodell efter detta. Svårgheten med modeller är att man aldrg kan vara helt sä>.er på att de gäller vd oförutsedda störnngsstuatoner. É ^ m Atgärdshandlednng É En möjlg utöknng av sgnalbehandlngsfunktonen vore att datorn utgående från sn sgnalanalys presenterade förslag tll lämplga åtgärder. Dvs dr.ftnstruktoner skulle fnnas nlagda datorn och beroende på felfall söker datorn upp lämplg(a) drftnstrukton(er) och presenterar dem. En säker funkton för åtgärdshandxednng förutsätter att sgnalanalysen är säker och att de rekommenderade åtgärderna nnefattar även det bästa alternatvet. m 2.3 DATORTEKNISK UTVECKLING I detta avsntt dskuteras några vktga trender utvecklngen av datorteknken. Framställnngen är mycket översktlg. M Allmänt Den datorteknska utvecklngen är synnerlgen snabb. Nya teknologer och metoder avlöser varandra. Det nnebär bl a att: ************************************************** * Det som ur tllförltlghetsssynpunkt vore * * önskvärt, nämlgen standardserade och väl- * * beprövade utrustnngar, programvara, metoder * * mm förekommer ganska sparsamt. *

22 21 Standardserngssträvanden försvåras av att utvecklngen ä.v så snabb och att utvecklngen styrs av faktorer som detta avseende är rratonella (bl a kommersella hänsyn). Även om frontlnjerna för datorutvecklngen är mycket snabb, kan det dröja länge nnan nya faclteter tränger ned och kan utnyttjas av slutanvändare. Förenklat sett kan man ursklja fyra nvåer för ny teknk att tränga genom. En ny facltet måste först bl etablerad på en nvå för att därefter kunna tränga ned tll nästa nvå. A. Forsknng och utvecklng. Nya teknologer och metoder utvecklas vanlgen vd forsknngslaboratorer, unverstet etc. Halvledartllverkarna utvecklar nya avancerade LSI-kretsar. B. Datorleverantörerna utvecklar generella datorsystem. med standard programvara. Tll denna grupp kan också * räknas frstående programvaruföretag, som utvecklar och säljer standard programvara. " C. Systemleverantörer utnyttjar generella datorsystem och standard programvara. Med dessa som bas utveck- I las kundspecfka system. Ofta förekommer det att systemleverantörerna utvecklar basprogramvara för en vss klass av tllämpnngar. (Anm: En systemleverantör I kan vara företagsntern, t ex en ADB-avdelnng.) D. Slutanvändare Genomtrangnngshastgheten för olka datorteknologer och. metoder varerar kraftgt, främst beroende på hur mycket ' resurser (kaptal och manår) som fnns bundet äldre teknologer. Det kan ta alltfrån några år tll över to år k nnan en värdefull nyhet når fram tll slutanvändarna. Studerar man aktuella större projekt för kontrollrumsdatorer k fnner man att systemleverantörerna trolgen redan har väl " utvecklad basprogramvara och prncp väljer datorsystem redan före kontrakt. Det nnebär att ************************************************** * De större kontrollrumsdatorer som skall * levereras nom 3-5 år kommer nästan helt och * hållet att baseras på dag kommersellt * tllgänglg teknk. * *

23 Utrustnngar Utvecklngen av halvledarkretsar är mycket snabb. Genom att teknken att göra allt mndre kretselement förfnas kan fler kretsar rymmas på samma halvledaryta. Dagens LSI-kretsar rymmer tals kretselement. Kostnaden för en LSI-krets beror huvudsaklgen på ytan för halvledarelementet, kapslng och serestorlek. Snabbheten för kretsen beror huvudsaklgen på tllverknngsteknolog och kretselementens storlek. Sammantaget nnebär det att prs/prestanda-förhållandet förbättras mycket snabbare takt än vad varje enskld egenskap utvecklas. Med LSI-kretsar kan man konstruera centralenheter (CPU) med en eller ett fåtal halvledarkapslar (s k mkrodatorer). Även prmärmnnen kan byggas upp av ett fåtal komponenter. För närvarande kan man få n 256 k bts mnne en kapsel. Komponenter med 1 M bts/kapsel komner trolgen att vara en realtet nom några år. J A A Datorarktekturen har även utvecklats. När kostnaderna för å kretselementen sjunker, får man större frhet att konstruera " centralenheter, som är bättre anpassade tll programvara, specella tllämpnngar etc. Specellt halvledartll- ä verkarna, som (httlls) ej har ett alltför stort arv av ' exsterande programvara, kommer ut på marknaden med nya mkrodatorkomponenter med arktektonska nnovatoner. ä De etablerade datortllverkarna är dock hårt låsta tll exsterande programvara. Arktekturförändrngar måste begränsas så att kompatbltet med exsterande programvara bbehåles. Mkroprogrammerade centralenheter har förekommt ett flertal år. Begreppet "frmware" står för sådant som lgger mellan masknvara (hardware) och programvara (software). Med mkrodatorteknken kan ny ntressant frmware utvecklas. Exempelvs fnns det centralenheter som drekt exekverar högnvånstruktoner för vsst högnvåspråk eller tllämpnng. En vdare utvecklng är specella "funktonsmoduler" som kan pluggas n en värddator. En funktonsmodul kan utgöras av en komplett mkrodator med en klart specfcerad funkton frmware såsom matematska funktoner eller datakommunkaton. Beträffande elektromekanska utrustnngar såsom skvmnnen, bandstatoner och skrvare är utvecklngstakten nte lka dramatskt snabb som för rena elektronkenheter. Dock är det nte oväsentlga framsteg som görs på den sdan. Hårdvarukostnaderna skulle kunna bl nästan försumbara även för mycket kraftfulla centralenheter, prmärmnnen, kontrollenheter m fl delar som enbart består av elektronk. Detta kommer nog nte att ske för åtmnstone de mer kända datorfabrkaten pga prssättnngspoltska skäl. å M ^ A A A ^ A

24 23 Under de senaste årtondena har prs/prestanda-förhållandet för datorsystem förbättrats med ungefär en faktor 10 på 10 > år. En god gssnng är att den trenden kommer att stå sg ett antal år framåt. ' Programvara k Förhållandena för programvara är nte lka gynnsamma som för * masknvara. För några år sedan började man tala om en programvarukrs. Det var en reakton på grusade förhopp- nngar om en snabb utvecklng på programvarusdan. Systemprogramvara av typen operatvsystem, komplatorer, I databassystem m m tllhandahålles huvudsaklngen av dator- ' leverantörerna. Programvaran kan endast användas för datorleverantörernas egna datorer. Den öppna programvarumarknaden ^ är fortfarande begränsad bl a pga att datorleverantörerna " subventonerar systemprogramvara med hjälp av prset på masknvaran. Det är vdare mycket stora kostnader att 4 utveckla och underhålla systemprogramvara. Datorleveran- " törerna vll därför begränsa stt utbud av programvara. I Detta är några av orsakerna tll att det är en stor tröghet " nnan nya programvarunnovatoner blr allmänt tllgänglga. De domnerande programmerngsspråken är fortfarande k assembler, Cobol och Fortran, som trots vssa anskts- ' lyftnngar baseras på 1950-talets datorteknk. I För admnstratva tllämpnngar fnns det en del allmänt " tllgänglg standardprogramvara, t ex databassystem. För processtllämpnngar är utbudet av standardprogramvara I mycket begränsat och något allmänt tllgänglgt, generellt " databassystem för processtllämpnngar fnns veterlgen nte. ' En av de vktgare nyheter som nträffat på senare år är att USA:s försvarsdepartment har satsat mycket stora resurser på I utvecklng av ett nytt programmerngsspråk kallat ADA. Det " kommer från början at vara helt standardserat. Förutom själva språket är även omgvnngen för språket standard- I serad. Ett av syftena med ADA är att uppnå vad man tdgare ' knappast lyckats med; nämlgen full portabltet (=överflyttbarhet) av programvara mellan datorer av olka fabr- I kat. ADA är sn grundkonstrukton ett mycket generellt pro- I grammerngsspråk. Det fnns goda möjlgheter att göra "språkutbyggnader" för olka tllämpnngsområden. Dessutom understödjer språket utvecklng av frstående programbbo-. tek. I Det fnns förutsättnngar för att ADA skall nnebära ett genombrott på programvarufronten. Dock kommer det att dröja ett antal år nnan effekterna kommer att märkas påtaglgt. Först kommer det att fnnas ADA-system större omfattnng, som systemleverantörer kommer att kunna utnyttja.

25 24 Bra programmerngsspråk löser dock bara en del av problemen krng utvecklng av programvara. Mycket ntresse har ägnats åt systemutvecklngsmetodk och organsaton av programvaruverksamheten. Ett stort antal metoder för framtagnng av programvara har utvecklats under de senaste åren. Vlken metod som är "bäst" råder det delade menngar om. Trolgen fnns ngen "bästa" metod utan vlken metod som är lämplgast beror på typ av tllämpnng, programvarans omfattnng, kvaltetsnvå, lvslängd etc. Programvarubranschen är så pass ung att praktskt "ngenjörstänkande" ("software engneerng") nte har hunnt etableras. Det förekommer allmänt att kvalfcerad programvara utvecklas mycket amatörsmässgt. Väsentlga tds- och kostnadsöverskrdanden programvaruprojekt samt låg kvaltet hos programvara är långt från ovanlgt. Kvalfcerad utbldnng av karaktären "software engneerng" har bara funnts några år. Om ytterlgare några år har de som fått god programvaruutbldnng kvalfcerat sg som projektledare, chefer m m. Förhoppnngsvs nnebär det att branschen blr alltmer professonell och att andelen dålg programvara mnskar. Volymöknngen är dock stor och det fnns utrymme för många nykomlngar nom branschen. Det kommer säkert att ta lång td nnan programvarubranschen blr stablserad. ^ fl fl _ fl _ fl _ fl

26 I I ft ft ft I I ft ft ft ft ft ft ft 3. ÖVERGRIPANDE KRAV 3.1 SYSTEMKRAV Med ett system av vtal betydelse menas enlgt defntonen avsntt 1.3 ett system som har en vtal betydelse för att förhndra eller begränsa verknngarna av potentella haverer, som skulle kunna utgöra otllåtna rsker ur hälso- och säkerhetssynpunkt för omgvnngen krng ett kärnkraftverk. En funkton kan kräva flera (del)system och omvänt kan ett system utföra flera funktoner. Det senare fallet är vanlgt datorsystem. Specell uppmärksamhet måste ägnas de problem som kan uppstå, om man blandar vtala funktoner och övrga funktoner ett och samma system. Lat oss göra följande defnton: * "Funktonell solaton råder mellan två ' ** system om godtycklg aktvtet eller med det ena systemet (nklusve ändrng av dess * funkton) ej påverkar det andra systemets * funkton." * ** ************************************************** Isolatonen kan vara partell, t ex gäller bara ena rktnngen eller gäller ej för vssa typer av åtgärder. Man måste för vtala system ställa följande krav: 25 I * * Om funktonell solaton från ett "övrgt * system" mot ett "vtalt system" ej förelgger * skall detta "övrga system" behandlas som ett * potentellt "vtalt system". * I ************************************************** För vssa funktoner kan man klart defnera om de utgör "vtala funktoner" eller "Övrga funktoner"..andra funktoner kan vara svårare att klassfcera.

27 Defakto vtalt system är ett sådant system som och för sg cke skulle behöva klassfceras som ett vtalt system, t ex på grund av att det fnns andra formellt vtala system, men där defakto-systemet på grund av t ex narbetade rutner, brstande utbldnng och erfarenheter av de formellt vtala systemen praktken kommer att användas som ett vtalt system. Med den defnton av vtalt system, som tllämpas denna rapport följer att de vtala systemen första hand kommer att användas extremt ovanlga och kanske ej förutsedda stuatoner. Även om vssa typer av stuatoner kan förutses, går det ej att förutse alla tänkbara stuatoner som kan uppkomma samband med ett haver. Förhållandena för vtala funktoner är således helt annorlunda än för normala övervaknngsfunktoner, drftoptmerande funktoner m m, som första hand konstrueras för normala drftförhållanden. Därav följer att: ************************************************** * Ett vtalt system måste utformas för att * * fungera säkert extremt ovanlga och ej * * förutsedda stuatoner. Det måste därför * * utformas för att kunna testas och verferas * * en smulerad mljö. * A ^ M M 4 PRINCIPER FÖR KRAVSÄTTNING När man ställer krav på ett system, detta fall ett datorsystem, skall man utgå från vad det skall användas tll. Först skall man analysera vlka krav, som skall ställas på funkton. Därefter kompletteras de funktonella kraven med ytterlgare krav på tllgänglghet, prestanda, utförande mm. I detta avsntt dskuteras endast prncpellt hur man bör ställa krav på datorsystem för kontrollrum kärnkraftverk. Syftet är att få en bas för analyserna kommande analyskaptel.

28 I I Verferbara krav Generellt sett gäller att alla krav man ställer på ett system skall vara verferbara. Det nnebär att det skall gå att med objektva metoder fastställa om ett krav är uppfyllt eller ej. Tyvärr är det nte möjlgt att med objektva metoder verfera alla önskvärda kvaltetsegenskaper. I stället måste andra verferbara kvaltetsegenskaper krävas, som man vet har stor nverkan på den egenskap som egentlgen är ntressant. För datorsystem fnns det ett flertal vktga kvaltetsegenskaper, som ej kan specfceras verferbara termer. A******************************************* * Alla krav skall vara verferbara. Om detta * * ej är möjlgt för vss kvaltetsegenskap, * * skall sådana ndrekta men verferbara krav * * ställas, som nnebär att önskad kvaltets- * * egenskap uppfylls. * a************************************************* Funkton De grundläggande och väsentlga kraven är naturlgtvs de funktonella. Alla andra krav kan anses vara avhängga av kraven på funkton cdh syftar ytterst tll att funktonskraven uppfylls. Det är vktgt att man ej okrtskt anammar krav som andra sammanhang kan vara helt självklara. Exempel Vssa typer av system, t ex styrutrustnngar för obemannade farkoster kräver kontnuerlg funkton. Ett kort avbrott kan få ödesdgra konsekvenser. I kontrollrumsdatorer kärnkraftanläggnngar bör det ej fnnas sådana funktoner, som kan kräva kontnuerlg funkton. Dessa bör läggas n specella utrustnngar, där en kontrollrumsdator eventuellt kan fungera som överordnat system.

29 28 * Alla krav skall baseras på en analys av * f * aktuell tllämpnng. Onödga krav nnebär * * ökad komplextet och därmed lägre total * - * tllförltlghet (förutom högre kostnader). * \ Det brukar nte vara några större problem att ställa de övergrpande kraven. Svårgheterna kommer när man skall - detaljera kraven och framförallt när man skall specfcera f vad som skall ske onormala stuatoner, undantagsfall m m. För de vtala funktonerna är just de onormala stuatonerna * särsklt vktga. Det är den "normala" mljön 'för vtala \ funktoner att någon onormal och kanske nte ens förutsedd händelse har nträffat. ^ Valdtet f Med valdtet avses kvaltetsegenskapen att full och korrekt - funkton förelgger när ngentng onormalt ndkeras \ systemet. Dvs graden av valdtet anger vlken utsträcknng man kan lta på ett system, när det är normal drft ^ och övrgt normala förutsättnngar råder. \ * För ett vtalt system skall korrekt funkton * * prorteras. I valet mellan vlseledande * - * funkton och uteblven funkton bör uteblven * % * funkton föredras. * ************************************************** Krav på fullgod valdtet är således väsentlgt för ett j vtalt system men det är ett hög grad svårverferbart krav. I prncp måste kravet uppdelas två delar: \ Intal verferng av krav på funkton (Anm. Flera funktonskrav är säkerlgen svåra att * verfera, varför ndrekta verferngsmetoder m måste tllämpas flera led). \ I

30 29 Löpande kortroll av funkton. Denna kontroll syftar främst tll att fastställa att systemet är samma funktonella kondton, som vd den ntala verferngen. Den ntala verferngen kan få vara omfattande och komplcerad men den löpande kontrollen måste vara enkel och tll största delen automatsk. I annat fall kommer den ej att fungera praktken, så fort som något onormalt detekteras systemet, skall larm avges tll operatör eller motsvarande. Denna s k systemövervaknng bör tll stora delar vara automatsk och nbyggd systemet. Efter varje ändrng och uppdaterng av systemet måste prncp en ntal verferng genomföras - helt eller delvs. Även den löpande kontrollen kan behöva ändras. Sammanfattnngsvs kan konstateras: ************************************************** * Det är väsentlgt att ntalt uppnå och * * fortlöpande upprätthålla en hög valdtet * * för de vtala funktonerna, dvs man skall * kunna lta på dem alla stuatoner. Därför * fordras tllförltlg övervaknng av säker- * hetssystemets funkton (= systemövervaknng). * * * ************************************************** Feltolerans Feltolerans är en kvaltetsegenskap, som är närbesläktad med valdtet. Valdtetsegenskaperna förutsätter kända och specfcerade förhållanden. Feltolerans är förmågan att klara av cke förutsedda förhållanden. Exempel på faktorer, som ke. påverka ett system: nterna fel systemet såsom utrustnngsfel och programvarufel fyssk mljö t ex temperatur, strömförsörjnng, elektrska störnngar ndata t ex mätgvare, manuellt nmatade data, data från andra datorer handhavande av operatörer, programvarupersonal, underhållspersonal m fl

31 30 förändrngar omgvnngen, t ex övervakat \ huvudsystem, drftsrutner Idealet vore naturlgtvs om man kunde upprätthålla full och korrekt funkton (= full valdtet) oavsett ovan angvna förhållanden. Detta är naturlgtvs ormlgt. Det man kan kräva är att: vd nterna fel mndre väsentlga delar eller vd måttlga yttre störnngar skall grundläggande funkton upprätthållas men prestanda kan få degraderas vlseledande funkton ej uppträder oavsett fel e.ler störnngsomfattnng uteblven funkton larmas, helst med angvande av orsak när den yttre störnngen, felfunktonen m m upphör, skall systemet snabbt återgå tll normala förhållanden Generella krav på feltolerans kan ej verferas. I stället måste sådana faktorer specfceras, som med god margnal kan anses representera värsta fall Drftsäkerhet - Ett vtalt system av det slag som rapporten behandlar skall vara nsatsberétt vd godtycklg tdpunkt. Drftsäkerhetskraven bör därför formuleras på ungefär följande sätt: Sannolkheten skall överstga x* att ett system vd en godtycklg tdpunkt skall uppfylla föreskrven funkton nom en tdsperod om y tmmar från denna tdpunkt. Vlka värden på x och y som skall väljas måste baseras på analyser av möjlga konsekvenser, andra helt eller delvs redundanta system m m. Typskt kan värdena vara 99.9% och 10 tmmar. Ett system anses som tllgänglgt när kraven på valdtet är uppfyllda. Under övrg td skall systemet anses vara ur (operatv) funkton. Funktonsbortfall kan drabba även ett vtalt system. Behovet av vtal funkton kan vssa fall reduceras av drftsmässga åtgärder, t ex stoppa reaktorn. I så fall kan krav st på åtgärdstder återföras tll ekonomska överväganden, såsom kostnad för produktonsbortfall. Erfordras däremot den vtala funktonen oavsett anläggnngens drftstatus, måste krav ställas på td för åtgärdande av fel. Alltför stora krav på avbrottsfr drft kan dock medföra mnskad total drftsäkerhet. ^

32 Utförande Vd httlls dskuterade krav betraktas systemet som en "svart låda" och kraven anger hur systemet skall uppträda gentemot omgvnngen. Kraven på utförande avser krav på hur den "svarta lådan" skall vara konstruerad. Anlednngen tll att ställa sådana krav från användaren kan vara att: - exsterande organsaton, utrustnngar m m kan nnebära restrktoner man önskar flexbltet för framtda utbyggnader, utbyten av delar m m - man erfarenhetsmässgt vet att ett vsst utförande ger lämplgare total systemlösnng Exempelvs kan det fnnas anlednng att ställa krav på (eller önskemål om): datorfabrkat pga att kompetens och underhållsresurser redan exsterar programmerngsspråk av främst samma orr.aker som ovan men även att moderna högnvåspråk kan ge säkrare programvara nterna gränssntt pga att man vll ha utbytbarhet. Det kan vara befogat med en varnng. Många männskor är gärna konstruktörer. De vll hellre specfcera en konstrukton stället för krav på funkton. Detta kan leda tll oklara ansvarsförhållanden. Den organsaton som skall ta fram ett system och ansvara för dess funkton och prestanda måste få ta totalt ansvar för hela konstruktonen. Slutsatsen är således: ************************************************** ** Det är väsentlgare att koncentrera sg på * krav på funkton än krav på hur systemet * skall konstrueras. * * * ************************************************** Drft- och underhåll För många stora datorsystem har drft- och underhållskostnaderna under systemets lvstd blvt lka stora som framtagnngskostnaderna.

33 32 Detta ndkerar vlken betydelse krav för drft och underhåll måste tllmätas. I drft- och underhåll ngår också åtgärder för att modfera och uppdatera systemet. Alla framtda modferngar nnebär partella nykonstruktoner och måste därför verferas lka noggrant som ursprungssystemet för att tllförltlghetsnvån skall upprätthållas. Därför rekommenderas att kraven utformas på följande sätt: * Behovet av framtda modferngar bör mn- * * meras och de förändrngar som kan förutses * * skall kunna nföras på ett tllförltlghets- * é * mässgt acceptabelt sätt. * Drft- och underhållskraven kan oftast omvandlas tl funktonskrav (t ex särsklda underhållsfunktoner) och tll krav på utförande (t ex synpunkter på dokumentaton). I å é W É 4 4

34 33 4. GRUNDLÄGGANDE BEGREPP I detta kaptel behandlas vssa grundläggande begrepp som är mer eller mndre generella för kommande analyskaptel. 4.1 DEFINITION AV FEL, TILLFÖRLITLIGHET M M Vad menas med fel ett system? * Ett fel ett system fnns då systemet ej * * utför vad som kan förväntas av systemet av * * användaren * ************************************************** Observera att fel här ej knyts tll funktonskraven för ett system. Om ett system uppfyller funktonskraven men ändå ej utför vad användaren förväntar sg av systemet är det ur användarens synpunkt felaktgt. Om ett system ej fungerar enlgt de funktonella kraven, fnns också ett fel. Dvs fel hos ett system beror på både systemets egenskaper och användarens förväntnngar. Att relatera fel tll användarens förväntnngar är emellertd synnerlgen ogreppbart. All verferng av ett system måste grundas på att man kan testa systemet mot kända Vrav. Fnns användarnas förväntnngar och krav dokumenterade, fnns också en specfkaton av systemet 1 ************************************************** * * * * * Normal begränsad betydelse av fel: * * Ett fel ett system fnns då systemet * * ej uppfyller specfkatonerna * **************************************************

35 34 ^ör att analysera fel, felupptäckt, felkonsekvenser måste 4 man ha mer precserade felbegrepp <CENN76> * ** Funktonsfel (falure) * Datafel (error) En händelse vd vlken systemet bryter mot specfkatonerna Fel data pga av ett utrustnngsfel eller programfel (fault) eller pga fel (error) ndata. När datafelet (error) bearbetas av systemet kan det orsaka ett funktonsfel (falure) * Utrustnngsfel, programfel (fault) En fyskalsk (mekansk) defekt eller en defekt en algortm el motsv * A************************************************* Eftersom svenskan saknar lämplga sklda ord för "fault", "error" och "falure" kommer det engelska ordet anges nom oarentes vd de tllfällen, där det är väsentlgt att sklja på de olka typerna av fel. Exempel Ett programvarufel (fault) kan fnnas en programsekvens när den bearbetar en vss kombnaton av korrekta datavärden. Om detta är en extremt ovanlg stuaton kan programfelet (fault) fnnas åratal utan att det gör någon skada. En dag exekveras denna programsekvens med dessa datavärden och resultatet blr att det blr fel (error) data som programsekvensen producerar. Dessa data kanske nte drekt används, varför systemet ännu ej bryter mot specfkatonerna. Sekunder, tmmar eller dagar (dvs mljontals masknstruktoner) efter att datafelet (error) uppstått används dessa data på sådant sätt att ett funktonsfel (falure) uppträder

36 35 Det är väsentlgt att sklja på korrekthet och tllförltlghet. Ett system är korrekt om det är frtt från utrustnngsfel och programfel (fault) och om des nterna data ej nnehåller datafel (error). * * * * Ett system är tllförltlgt om det nte nträffar funktonsfel (falure). Tllförltlghet betyder ej att ett system är frtt från utrustnngsfel eller programfel (fault) eller datafel (error) utan att det kan vara tolerant mot fel. Vdare kan ett korrekt system vara otllförltlgt pga ntolerans mot fel omgvnngen, t ex felaktga ndata, elektrska störnngar. 4.2 FELDETEKTERING, FELLOKALISERING OCH FELSPRIDNING Enlgt föregående avsntt har v tre typer av felbegrepp. V skall nu dskutera hur fel kan sprda sg. Fel (fault) kan dels fnnas kvar datorsystemet från konstruktonsstadet (främst programvarufe2, se 7.1) och dels uppstå spontant (främst hårdvarufel och störnngar, se 6.1). Observera att det kan fnnas utrustnngsfel, programfel (fault) och datafel (error) ett system utan att det bryter mot specfkatonerna, dvs utan funktonsfel (falure) 1 Naturlgtvs kan nte kvarvarande konstruktonsfel upptäckas under löpande drft nnan de orsakar andra följdfel (error eller falure). I så fall hade felen blvt elmnerade långt tdgare. Vssa fel som spontant uppstår utrustnngarna kan upptäckas av specella testfaclteter utrustnngarna nnan fel data nträffar. Normalt kan man nte förutsätta att ett fel (fault) kan detekteras utan att detta leder vanlgen tll ett följdfel (error eller falure).

37 36 Ibland kan ett fel data detekteras drekt samma eller omedelbart följande masknnstruktoner. Ofta kommer dock datafelet att lagras ett v datorns olka mnnen utan att ha blvt detekterat. Ju längre ett datafel lgger oupptäckt lagrat ett mnne, ju svårare är det att, när det slutlgen detekteras, korrgera felet och eventuella följdverknngar av felet. När felet upptäcks kan den yttre processen (kärnkraftverket) ha ett helt annat tllstånd och det kan vara omöjlgt att återskapa korrekta data. Felaktga data kan under mellantden ha använts för att beräkna andra data som då blr behäftade med fel. ************************************************** Utan en tdg detekterng av utrustnngs- * fel och fel ndata är rsken stor för en * okontrollerad och okorrgerbar sprdnng av * fel data. * * ************************************************** Anm.: Det förutsätts att utrustnngarna är konstruerade så att ngen felsprdnng sker utrustnngarna, dvs att ett utrustnngsfel ger ett följdfel annan utrustnng. * All tdg feldetekterng fordrar kunskaper * * och antaganden om felkaraktär och felytt- * * rngar. * ************************************************** Det nnebär at*- prmär feldetekterng bör konstrueras n utrustnngar och programvara så nära potentella felkällor som möjlgt. När ett fel detekteras kan det automatskt även vara lokalserat, men det är långt från alltd fallet. Ett fel måste naturlgtvs lokalseras nnan det kan korrgeras. Innan detta sker kan man med olka metoder undvka detekterade fel eller lndra verknngarna av dessa.

38 37 Som komplement tll feldetekterng behövs * fellokalserng för att * kunna åtgärda felet och * nnan detta skett - undvka felet * och därmed sprdnng av felet * * * 4.3 RECOVERY Vad gör man när ett fel uppstår? Naturlgtvs vll man korrgera felet och eventuella konsekvenser av felet. Med recovery (ung. återhämtnng) menas att ett systemet efter ett fel kan återhämta sg och uppta normal operatv drft, eventuellt något reducerad omfattnng. Grundprncpen för recovery är enkel. Man delar upp systemets aktvteter smådelar "atomc actons", nedan kallade mkroaktvteter. För en mkroaktvtet skall följande vara uppfyllt: Systemstatus skall vara känt före aktvteten startas - Detta systemstatus skall kunna återskapas efter aktvteten blvt genomförd - Det skall fnnas möjlghet att efter mkroaktvtetens fullbordande detektera eventuella fel som nträffat I I prncp genomlöps mkroaktvteterna en efter en med feldetekterng mellan varje aktvtet. Upptäcks fel återskapas föregående systemstatus och aktvteten återupprepas. Se även fgur 4:1. Mkroaktvtet kan detta sammanhang vara ett ytterst brett begrepp. Det kan vara allt från delar av en masknnstrukton tll alla bearbetnngar som genomförs under t ex ett nattskft. Vad som skall nrymmas en mkroaktvtet beror på kraven på och möjlgheterna tll recovery. Det är nte nödvändgt att exakt samma mkroaktvtet genomlöps efter ett fel detekteras. Det kan vara omöjlgt efter det att felet nträffat. En alternatv mkroaktvtet kan ge reducerad men godtagbar funkton. I Ofta förekommer recovery på flera nvåer. De fel som ej kan detekteras på en nvå kan kanske detekteras på nästa nvå. Se fg 4:2.