Safety-Critical
Computer Systems
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14,
SE 16, 21
Kapitel 1 Introduktion
Sedan mikrodatorernas uppkomst i början av 1970-talet har priserna sjunkit hela tiden vilket har lett till att användningen av
de har ökat dramatiskt. Huvuddelen av mikrodatorerna används inte i vanliga datorer utan i inbäddade system där processorn
inte syns direkt för världen utanför. Sådana applikationer varierar från exempelvis kontrollsystem för flygplan, tvättmaskiner
och automatiska avstängningssystem till kärnkraftverk. Bilindustrin och hushållsapparatindustrin står för den största mängden.
Det finns även system som är tillverkade i mycket små mängder, kanske bara ett unikt system inom industrin.
En viktig skillnad mellan inbäddade system och de applikationer som normalt associeras till mikrodatorer är de konsekvenser
som en icke korrekt operation kan få. Visserligen kan det vara mycket irriterande om en ordbehandlare inte fungerar korrekt
men det är inte troligt att någon människa blir skadad av den. Emellertid kan ett inbäddat system orsaka skada på människor
eller miljö. I extrema fall kan t ex en kärnkraftolycka orsaka skada på hela världens befolkning och miljö.
I många fall är det inte lika klart att ett inbäddat system kan förorsaka skada och därför är det inte självklart att anta att
systemet kan vara farligt för människa och miljö. I praktiken kan nästan alla inbäddade system orsaka skada. En avancerad
brödrost som inte stänger av sig själv kan orsaka brand och personskada eller en mikrobrytare som inte känner av att luckan
till mikrovågsugnen är stängd innan ugnen sätt igång. Även om dessa händelser är osannolika så visar erfarenheten att en stor
del av personskador orsakas av hushållsapparater p g a att det finns så många.
Alla inbäddade IT-system är säkerhetskritiska tills annat är bevisat (István, 1998).
Safety är en egenskap hos ett system som gör att systemet inte äventyrar mänskligt liv eller miljö.
Safety-related system är ett system som försäkrar ("garanterar") att utrustning eller en fabrik är säker.
Uttrycket safety-critical system används normalt som en synonym men det kan även användas för att beteckna ett system
med särskilt höga (kritiska) säkerhetskrav.
Tyvärr är inget system helt säkert. Även om målet är att konstruera ett helt säkert system så påverkar personlig bedömning
och allmän opinion. Konsekvenserna av säkerhetskritiska fel är olika för olika system och en teknik för att analysera ett
systems säkerhetskritiska konsekvenser är att använda tekniken med levels of integrity. Detta behandlas i kapitel 2 och 4.
The scope of safety
Bedömningar om säkerhet finns med i alla steg i ett systems liv. Från början till slutet då systemet upphör. Säkerhet kan lösas
genom både hårdvara och mjukvara. Mjukvara har dock en central roll när det gäller säkerhet.
Säkerhet kan inte enbart produceras genom bra konstruktion. Hur systemet reagerar kan stjälpas genom misstag under dess
produktion, installation eller drift. Säkerhet är nära relaterad till kvalitetsstyrning.
Säkerheten i ett system kan indelas i tre kategorier:
Säkerhet omfattar allt men boken begränsar sig till de två första kategorierna, alltså primary safety och functional safety.
Indirect safety behandlas inte ytterligare.
Forms of safety-related system
Säkerhetsrelaterade system indelas i två kategorier:
Beteckningen EUC används för Equipment Under Control. Utrustningen har sensorer och styrare. Se sida 6 bild 1.2.
Datorer i säkerhetsrelaterade system
Beteckningen PES står för Programmable Electric System och används inom industrin. PES omfattar inte bara vanliga datorer
och mikroprocessorer utan även andra mjukvarukontrollerade enheter som PLCs Programmable Logic Controllers. PLC är
ett exempel på PES. Se även kapitel 10 sida 253.
Det är inte självklart att ett komplext datorsystem används för en säkerhetsfunktion men i många system är det absolut
nödvändigt med datorsystem för att garantera säkerheten. Ett datorsystem har två huvudkomponenter, hårdvara och
mjukvara. Båda är nödvändiga och båda påverkar säkerheten i systemet.
Fördelar med datorbaserade system
Nackdelar med datorbaserade system
Den primära nackdelen kommer direkt från en av dess fördelar, komplexiteten. Komplexitet är ett stort hinder för säkerhet.
Komplexa system har troligtvis fler konstruktionsfel och de är svårare att testa och innehåller därför troligtvis fler oupptäckta
fel. De är också svårare att förstå och därför mer utsatta för mänskliga fel vid installation och drift.
En önskvärd egenskap hos ett säkerhetssystem är förutsägbarhet. I ett komplext system är det svårt att förutsäga hur det
kommer att uppföra sig. Systemet kan ha många olika felyttringar. Det är svårt att testa grundligt.
I många fall är det endast praktiskt genomförbart att använda ett datorsystem för säkerheten. Processen att utveckla ett
datorsystem för säkerhet kan vara både omfattande och tidsödande. Som andra utvecklingsprojekt har det ett antal faser. De
kan representeras med en lifecycle model. Det finns flera modeller men en typisk sådan visas på sida 9. Den har top-down
för konstruktion och bottom-up för testning.
Innan ett system kan konstrueras måste en kravspecifikation tas fram. Den kan indelas i två delar:
I en kravspecifikation skriven med naturligt språk kan det vara svårt att undvika tvetydighet. Ett sätt att förtydliga
kravspecifikationen är att skriva den med formellt språk.
Det är viktigt att skilja på verifikation och validation.
Verification är processen att bestämma om systemet uppfyller kravspecifikationen. Alltså, har vi byggt systemet rätt?
Validation är processen att bestämma om systemet är lämpligt för dess uppgift. Alltså, har vi byggt rätt system?
Faults, errors and system failures
Ett fault kan ha olika former. T ex kan en hårdvarukomponent gå sönder eller ett misstag kan finnas i konstruktionen av
systemet. Ett fault kan leda till ett error som är den mekanism som gör att ett fault blir synligt. Ett mjukvaru fault kan ligga
vilande under lång tid och det är först när denna del av programmet körs som felet upptäcks. Om ett error får systemet att
avvika från sitt önskvärda uppträdande så uppstår ett system failure.
Faults kan indelas i två klasser:
Fault kan också indelas beroende på deras varaktighet:
Det är inte säkert att faults upptäcks omedelbart de inträffar. Effekterna av de kan ligga vilande i systemet och det är viktigt
att dessa felaktigheter tas om hand.
Fault management:
Det är dyrt med säkerhet. Målet för projekt är därför att uppnå en lämplig balans mellan kostnad och säkerhet.
Legal aspects
En tillverkare av ett system som orsakar skada kan göras ansvarig för skadan. Lagarna varierar mellan olika länder men det
kan röra sig om både brottsmål och civilmål samt olika konsumentlagar.
Ett sätt att minska riskerna att bötfällas eller betala skadestånd är att:
Om ett system orsakar skada och tillverkaren kan visa att denne uppfyllt alla rimliga krav och konstruerat systemet på bästa
sätt (state of the art) så är risken mindre att denne ställs till ansvar. Om det finns särskild teknik och standard inom området
för en speciell produkt och tillverkaren inte har använt sig av den så är risken större för att denne ställs till ansvar.
PROBLEMS
Svar: Bilindustrin och hushållsapparatindustrin är de som har de största volymerna av varor med mikroprocessorer. Exempel
på varor är bilar, mikrovågsugnar och tvättmaskiner.
Svar: Kärnkraftindustri och processindustri. Exempel är kärnkraftverk och pappersmassafabriker.
Svar: Inbäddade system är ofta säkerhetsrelaterade. System som reglerar stora effekter.
Svar: Svetsrobot inom bilindustri. Kylning av bränslehärd i kärnkraftverk. Processtyrning inom stålverk.
Svar: Mikrovågsugn, tvättmaskin, diskmaskin, TV och spis.
Svar: Safety är en egenskap hos ett system som gör att systemet inte äventyrar mänskligt liv eller miljö.
Svar: Safety-related system är ett system som försäkrar ("garanterar") att utrustning eller en fabrik är säker.
Uttrycket safety-critical system används normalt som en synonym men det kan även användas för att beteckna ett system
med särskilt höga (kritiska) säkerhetskrav.
Svar: Det går inte.
Svar: Effekterna av att ett system kan få en felyttring varierar stort. Integritetsnivån är ett sätt att definiera vilken nivå av
konsekvenser ett system kan medföra. Exempel på högsta klassen är kärnkraftverkssäkerhet. Exempel på låg klass är t ex en
tvättmaskin. Om den överhettar kan den orsaka brand men konsekvenserna av den blir mycket mindre än en kärnkraftolycka.
Svar: Hazard analysis innebär att identifiera en situation som kan äventyra mänskligt liv eller miljö. Hazard översätts ibland som "riskkälla" men ett bättre svenskt ord är "fara".
Risk analysis innebär att identifiera vilka risker som är kopplade till en hazard. Risk är ett mått på sannolikheten att systemet
kommer att orsaka en olycka. Värdering görs av både sannolikhet för olycka och konsekvenserna av den. Risk kan också
beskrivas som sannolikheten att något icke önskvärt inträffar.
Svar: Vilka konsekvenser ett feltillstånd kan ge, hur sannolikt det kommer att inträffa och vad det kostar att bygga bort.
Svar: Säkerheten i ett system kan indelas i tre kategorier:
Svar:
Svar: Beteckningen PES står för Programmable Electric System och används inom industrin. PES omfattar inte bara vanliga
datorer och mikroprocessorer utan även andra mjukvarukontrollerade enheter som PLCs Programmable Logic Controllers.
PLC är ett exempel på PES. Se även kapitel 10 sida 253.
Svar:
Fördelar med datorbaserade system
Nackdelar med datorbaserade system
Den primära nackdelen kommer direkt från en av dess fördelar, komplexiteten. Komplexitet är ett stort hinder för säkerhet.
Komplexa system har troligtvis fler konstruktionsfel och de är svårare att testa och innehåller därför troligtvis fler oupptäckta
fel. De är också svårare att förstå och därför mer utsatta för mänskliga fel vid installation och drift.
En önskvärd egenskap hos ett säkerhetssystem är förutsägbarhet. I ett komplext system är det svårt att förutsäga hur det
kommer att uppföra sig. Systemet kan ha många olika felyttringar. Det är svårt att testa grundligt.
Svar: Komplexitet är ett stort hinder för säkerhet. Komplexa system har troligtvis fler konstruktionsfel och de är svårare att
testa och innehåller därför troligtvis fler oupptäckta fel. De är också svårare att förstå och därför mer utsatta för mänskliga fel
vid installation och drift.
En önskvärd egenskap hos ett säkerhetssystem är förutsägbarhet. I ett komplext system är det svårt att förutsäga hur det
kommer att uppföra sig. Systemet kan ha många olika felyttringar. Det är svårt att testa grundligt.
Svar: Just genom att datorsystem är mer komplicerade så är det svårare att förutsäga hur de kommer att uppföra sig.
Svar: Se sida 9 i boken.
Svar: Ett annat ord är functional requirement, d v s vad systemet skall kunna göra.
Svar: Oförmåga att förutse alla omgivningar ett system skall kunna klara av. När en felaktighet finns i kravspecifikationen eller
något saknas i den så är det egentligen inget fel på konstruktionen av systemet, eftersom kravet saknas eller är felaktigt.
1.21 Hur integreras individuella moduler under utvecklingsprocessen?
Svar: Först verifieras modulerna genom t ex testning. Sedan kan de integreras successivt eller som "big-bang" genom att hela
systemet sätt ihop på en gång.
1.22 Definiera beteckningen "verification" och "validation".
Svar:
Verification är processen att bestämma om systemet uppfyller kravspecifikationen. Alltså, har vi byggt systemet rätt?
Validation är processen att bestämma om systemet är lämpligt för dess uppgift. Alltså, har vi byggt rätt system?
1.23 Vilken process är den sista fasen i ett projekt med hög säkerhetskritiskt nivå?
Svar: "Highly critical systems" genomgår ofta en formell certifikationsfas enligt de standards som används inom den
industrisektor som systemet finns i.
Svar: En gissning är att "Hazard and risk analysis" och "Certification" är unika för säkerhetskritiska system. Övriga är giltiga för
alla system.
Svar:
Svar:
Random faluts. Dessa beror på hårdvarukomponenter och genom att samla data om dessa komponenter så kan förekomsten av dessa fel beräknas. Exempel kylfläkt för processor.
Systematic faults. Dessa kan vara konstruktionsfel eller misstag i specifikation. Systematiska fel är inte slumpmässiga och
kan därför inte beräknas med statistik. Exempelvis programmeringsfel (logiskt tankefel).
Svar:
Permanent duration. De flesta konstruktionsfel och hårdvarufel är varaktiga.
Transient duration. Exempelvis en strömtopp (spik).
Svar: Inget system kan göras helt säkert men att göra det mycket säkert kostar stora pengar och tar lång tid. En skälig
bedömning måste göras var gränsen ska gå mellan säkerhet och kostnad.
Svar: En tillverkare av ett system som orsakar skada kan göras ansvarig för skadan. Lagarna varierar mellan olika länder men
det kan röra sig om både brottsmål och civilmål samt olika konsumentlagar.
Ett sätt att minska riskerna att bötfällas eller betala skadestånd är att:
Svar: Om ett system orsakar skada och tillverkaren kan visa att denne uppfyllt alla rimliga krav och konstruerat systemet på
bästa sätt (state of the art) så är risken mindre att denne ställs till ansvar. Om det finns särskild teknik och standard inom
området för en speciell produkt och tillverkaren inte har använt sig av den så är risken större för att denne ställs till ansvar.
Sammanfattning kapitel 2. Safety Criteria
Introduktion
I system som bygger på höga säkerhetskrav är det vanligt att man gör ett särskilt dokument för säkerhetskraven (safety
requirements dokument). Dokumentet visar vad systemet skall klara av (inte klara av) för att uppfylla säkerheten.
Systemkrav (relevanta mot säkerhets-relaterade system)
- sannolikheten att en komponent, eller ett system fungerar felfritt under en given tid och under givna förhållanden. Tillförlitligheten varierar med tiden. Denna variation kan minskas om underhållsservice utförs. Tillförlitlighet är av särskild betydelse i applikationer där konternuerlig avbrottsfri funktion är avgörande. Tillförlitligheten kan mätas i, MTTF= mean time to failure.
- sannolikheten att ett system fungerar felfritt vid en given tidpunkt. Om ett system är tillgängligt i 999 fall av 1000, kan man säga att systemet är otillgängligt (unavailability) i 1 fall av 1000.
- systemet skall vara "idiotsäkert". Exempel: en maskin som kräver att man trycker på knappar med båda händerna samtidigt för att den skall fungera, släpper man ena knappen stannar maskinen.
- systemets möjlighet att upptäcka fel och att rapportera till operatören. Exempel: övervakningsutrustning för turbiner, larmanordningar,mm.
- systemets möjlighet att hindra skada i sin egen databas, och att upptäcka, och om möjligt rätta till fel som uppstår.
- i system som inte har idiotsäker funktion, är det viktigt att systemet kan upptäcka fel och återstarta sig självt snabbt.
- är möjligheten att underhålla systemet. Underhåll är de åtgärder som vidtas för att återställa ett system i sin ursprungliga funktion. Hur bra ett system går att underhålla kan mätas i, MTTR=mean time to repair.
- är de egenskaper i ett system som berättigar att man ger det sitt förtroende. Pålitligheten mäts ofta i tillförlitlighet och
tillgänglighet.
Säkerhetskrav
Säkerhetskritiska system måste motsvara vissa säkerhetskrav, vilka är baserade på dess funktion och karaktär. Dessa krav tas fram genom en stegvis process.
Hazard (hot) - möjligheten att skada människor, egendom eller omgivningen.
Interlocks (spärr) - mekanismer som försäkrar att hotfulla händelser endast kan genomföras under säkra betingelser.
Sensorer används för att upptäcka farliga fel.
Guard - håller människor borta från de farliga delarna av systemet, intill dess delarna har blivit säkra. Detta görs av styrare
(actuators).
Safety case
Säkerhetskritiska system måste i de flesta fall certifieras av myndigheter före driftsättning. Systemoperatören måste ta fram en "säkerhetsbok". Denna beskriver design och teknik som har använts vid utveckling av systemet. Argumenten i boken bygger mera på ingenjörernas omdöme än strikt logiska formalia. Syftet med boken är inte att bevisa att systemet är säkert, utan att tala om att man har tagit hänsyn till riskerna och försökt minimera dessa vid utveckling av systemet.
Kapitel 3
Den viktigaste momentet för ökning av säkerheten på ett system är att identifiera på vilka sätt systemet kan orsaka
skada.
Hazard (Fara) är ett tillstånd där det finns en potentiell eller faktisk fara för människor eller miljö.
Relaterat till varje hazard (fara) finns en risk (risk) som är sannolikheten att händelsen inträffar.
När en skada på människa eller miljö har inträffat kallas detta accident. (olyckshändelse)
Detta kapitel ägnas åt att belysa flera metoder att analysera de faror som finns relaterade till ett visst system. De vanligaste
teknikerna är;
En variant av FMECA att analysera faror i form av sannolikheter. [fig 3.2 sid 37]
Det påpekas att hotanalysen måste utföras tidigt och kontinuerligt i projekten då de är av avgörande betydelse för alla delar av projektet. Analysen indela i faser enligt figur 3.13 sid 52.
Detta är en kort resumé över kapitlet och den är indelad som boken.
För att förstå "Risk" måste vi förstå sambanden mellan faror = "hazards" och händelser vilka orsakar skada på en individ eller omgivning.
När en fara och en händelse faktisk orsakar en skada på omgivningen kallas det för olycka "accident".
"An accident is an unintended event or sequense of event that causes death, injury, environmental or material damage."
Mycket av analysen av faror syftar till att identifiera serier av händelser vilka kan leda till olycka, "accident sequences or accident scenarios".
Mycket användbar information kan erhållas om man även studerar "near misses" dvs incidenter.
"An incident is an unintended event or sequense of events that does not result in loss, but, under diffrent circumstances, has the potential to do so."
Farans betydelse är relaterad till den olycka den kan ge upphov till. Följande faktorer är av betydelse nämligen:
Den risk som är förknippad med en fara bestäms av dessa faktorer.
"Risk is a combination of the frequensy or probability of specified hazardous event, and its consequence."
Definitionen tillåter att man behandlar risken ur kvalitativ eller kvantitativ synvinkel. Det som kommer att beskrivas nedan är att man studerar risken ur ett kvantitativ perspektiv. För mer kunskap se boken.
Farans svårighetsgrad kan indelas i olika nivåer nedanstående tabell är föreslagen standard - IEC 1508
Kategori Definition
Katastrof Flera döda
Kritisk En död och eller flera svåra skadade eller svårt sjuka.
Marginell En svår skada eller sjukdom och eller flera mindre skador eller lättare sjukdom.
Negligebar En enstaka skada eller lättare sjukdom.
En viktig notering är att när sannolikheten diskuteras måste man känna till enheten följande tre är vanligast.
Failures on demand (hur många gånger kommer systemet att inte fungera när man behöver det)
Failures per hour (hur många fel under en timme)
Failures per year (se ovan)
Nedan stående tabell, 4.3 i boken, är föreslagen standard enl IEC 1508 för sannolikheten att en fara inträffar.
Händelsen frekvens Hur ofta kommer händelsen att inträffa under systemets operationella livslängd.
Frequent Det är troligt att den är ständigt återkommande.
Probable Det är troligt att den återkommer ofta.
Occasional Det är troligt att den återkommer flera gånger
Remote Det är troligt att den inträffar någon gång
Improbable Det är inte troligt att den inträffar men kan under exceptionella omständigheter inträffa.
Incredible Det är extremt otroligt att händelsen inträffar.
Vid Risk klassificering kombineras sannolikheten att något inträffar och svårighetsgrande hos en fara med varandra och vi erhåller en Risk Klass "risk class, risk level, risk factor".
Tabellen nedan är risk klassificeringen enligt IEC 1508.
Svårighetsgrad
| Frekvens | Catastrophic | Critical | Marginal | Negligble |
| Freguent | I | I | I | I |
| Probable | I | I | II | III |
| Occasional | I | II | III | III |
| Remote | II | III | III | IV |
| Improbable | III | III | IV | IV |
| Incerdible | IV | IV | IV | IV |
För betydelse av riskklasser se boken tabell 4.7
Den godtagbara nivån hos en risk bestäms vilka "fördelar" som är relaterade till risken, och den mängd av arbete som måste tillföras för att reducera risken. Med fördelar avses vilka positiva effekter erhålls om risken reduceras.
Enl IEC 1508 delar in risker i tre nivåer i en ALARP (as low as is reasonably praticable) kon.
Se figur 4.3 sid 68 för en noggrannare förståelse av ALARP konen.
"Safety integrity is the likelihood of a safety-related system satisfactorily performing the required safety functions under all the state conditions within a stated period of time."
Säkerhets redbarheten är sannolikheten att säkerhets funktionerna i ett säkerhets-relaterat system uppträder enligt gällande specifikationer, villkor och tidsrymd.
Hela kapitlet handlar om vilka krav du kan ställa på en produkt beroende på i vilken miljö du skall använda denna. IEC 1508 delar in "Redabarheten" i fyra nivåer, se tabell 4.10 sid 72.
Man skiljer på
Software integrity is that part of the safety integrity relating to dangerous software failures.
Software integrity är en delmängd av Systematic integrity.
Har valt att ej översätta då den eng texten är tydlig.
Kapitlet handlar om etiska och sociala tankar se tabell 4.12 Tio bud ord för proffs sid 77.
Kap 5 Utveckling av Säkerhetskritiska System
Introduktion: Systemsäkerhet kan utföras på många olika sätt. En metod som garanterar ett verkligt säkert system är att
föredra. En sådan metod är givetvis svår och komplicerad att använda/hitta. Sedan rangordnas en del metoder.
5.2 Livscyckelmodel
Boken visar ett exempel på en utvecklingsmodell som kallas "V" modellen som även fanns med i en enkel form i kap.1. Modellen är utvecklad att indikera resultat i varje steg. Den kan också visa flödet av information mellan stegen. En beskrivning finns också i SE sid 424.
Det viktiga med livscykeln är att den fokuserar på säkerhetsaspekter i varje fas av utvecklingsprocessen. Standarden som
definierar livscykeln är: Nödvändig verksamhet innefattar säkerhetsrelaterade system som förekommer under en tidsperiod
som startar med en begreppsfas i ett projekt och slutar när inga system längre är tillgängliga.
5.4 Utvecklingsmetoder
Här ges en överblick av teknikmetodernas innehåll
- Dynamisk test
- Statisk test och analys
Den är uppdelad i fyra delar (STARTS,1987)
- avskiljande
- upplösning
- utarbetande
- beslut/utslag
Felkällor indelas i olika grupper
- feltillstånd i specifikationen
- slumpmässig felyttring av hårdvarukomponenter
- systematiska felkällor i designen inkl. mjukvara
Sett ur designaspekten av ett projekt kan vi identifiera tre metoder att angripa felkällshantering som är särskilt lämpliga:
- Systemarkitektur
- tillförlitlighetteknik
- kvalitetshandhavande
Hierarkisk design används för hårdvaror och mjukvaror. Den delar upp systemet i olika lager.
Moduler i ett högre lager fungerar korrekt endast om moduler i ett lägre lager fungerar.
5.6 Underhåll
Underhåll består av två delar: förebyggande och förbättrande
5.7 Den mänskliga faktorn
5.8 Säkerhetsanalys
I England har the Health and Safety Executive (HSE) publiserat en grundstomme för säkerhetsanalys. Tabellen finns på sidan
107
5.9 Säkerhetsledning
Här nämns planering, organisation, kontroll och värdering.
Eftersom säkerhetsledning är viktigt så är det väsentligt att den är förankrad i "högsta ledningen". En väldefinierad
säkerhetspolicy är väsentlig för att grundlägga arbetssättet och försäkra sig om att den används. I boken finns också en bild på
hur en ledningsstruktur kan se ut Slutligen nämns vikten av teknisk kompetens och träning.,
Robusta Realtidssystem
Kapitel 6
6.1 Introduktion
Feltollerans: design i syfte att felkällan ej skall ge system-felyttring.
Baserat på någon form av redundans och kan ge ett mer komplext system än annars nödvändigt.
Problemet är gammalt(EDVAC 1949) dock byggs komplexiteten i moderna system in i mjukvaran. Skyddar mot hård- och mjukvaru -felkällor.
Viktig faktor i felkällans system: hur många felyttringar som accepteras
Detta kapitel handlar om varierande teknik för att uppnå felkälletolerans.
6.2 Typer av felkällor
Felkällor delas in i typer efter: natur, varaktighet och utbredning
Natur: slumpvisa eller systematiska
slumpvisa är oftast hårdvaruberoende,(alla komponemter kan gå sönder under en tidspriod)
Statistik kan användas för uppskattning av antalet fel per tidsperiod.
Till slumpvisa kan läggas systematiska fel, (tre huvudtyper)
Misstag i: 1)systemspec, 2)mjukvarudesign 3)hårdvarudesign (Program resp maskinvara)
Dessa betraktas som olika former av design felkällor (design faults)
Det är normalt svårare att förutse systematiska fel. (utvecklas i kap 7.)
Hårdvarufel kan vara slumpvisa eller systematiska, det finns inga slumpvisa mjukvarufel.
Varaktighet: Felkällor som kvarstår på obestämnd tid eller kräver åtgärd för att upphöra benämns Permanenta felkällor. Design- och mjukvaru-felkällor är alltid permanenta.
De som kommer och går på kort tid benämns övergående felkällor. En tredje kategori är periodiska felkällor och återkommer,(kontaktproblem , lödning motsv.) Svårt att analysera men mer i kap 8.
Felkällor i hårdvara kan anta alla former emedan mjukvara endast kan ha permanenta.
Utbredning: klassas i begränsad,(enstaka hårdvarudel) eller total.
Fault models: används mest till komplexa system. Modellerna förekommer i många nivåer från enskild komponent och uppåt. Olika modeller som representerar olika feltyper. Syftet är att förbättra system-design.
Olika modeller: single-stuck-at, bridging och stuck-open fault models fungerar genom att simulera fel i/på komponenter som låst i ett eller noll, kortslutning mellan noder etc.
Mjukvarufel: det är accepterat att mjukvara innehåller fel, s.k. buggar. Det finns många olika typer av buggar. det finns inga
slumpvisa mjukvarufel.
Säkerhet uppnås genom en kombination av, undvikande, bortagande, upptäckt och tollerans av felkällor. Framgången beror på vilken täckning man har i ovanstående. Alla former av fel-källe tollerans uppnås genom någon form av redundance. Tidiga system använde TMR (tre modul redundance, sid 125.) Samma signal till alla tre kontroll ut och om skillnad ta majoritetens signal,(två av tre). Design fel är svårare att hitta och man använder bl.a. olikhet vid test.
Teknik: Man hittar felen genom de feltillstånd de genererar och kan vid sökning använda både hård som mjukvara för att hitta likväl som att göra systemet mer felkälle-tollerant.
En vanlig orsak till fel är felaktig eller otillräcklig strömförsörjning vilket kan avhjälpas med en UPS,(battlåda mellan nät och
systemkomponent som förser med stabil spänning vid avbrott på ord nät.
De vanligaste metoderna att erhålla feltolerans inkluderar användandet av redundant hårdvara.
Hårdvaran indelas i så fall i tre grundformer nämligen:
Statisk redundans använder sig av någon form av röstningsmekanism (eng voting). Denna jämför utdata från ett antal moduler och maskar bort effekten av fel hos dessa moduler.
Den enklaste versionen använder tre moduler, termen N- modular redundant systems anges N som det antal moduler systemet innehåller.
I den enklaste "triple modular redundant" (TMR) erhåller indata och skall följaktligen ge tre identiska utdata. Om en moduls utdata skiljer sig från de övriga beroende på ett fel kommer själva rösträknaren (voter) att ge ett resultat som majoriteten håller på. Detta innebär således att fel hos en av modulerna maskas bort.
Används i syfte att undvika single point of failure.
NMR (N- modular redundancy) tolererar fel av storleksordningen (N-1)/2, dvs en 5 modular för att fungera kräver funktion i 5-1/2=2 3 moduler måste vara uppe.
Voting teknik kan appliceras både i form av mjuk och hårdvara.
DYNAMISK REDUNDANS
Använder sig av feldetektion i stället för maskning.En enhet jobbar medan en enhet står i beredskapsläge att ta över vid ett fel.
STANDBY SPARES
En modul arbetar tillsammans med någon typ av schema för feldetektion
Om ett fel hittas rekonfigureras systemet så att den felaktiga modulen tas bort och därigenom felet, en ny modul startas (standby) och det rätta sker.
Hot standby snabb rekonfigurering
Cold Standby mindre snabb
Vardera Hot / Cold har sina fördelar avseende effektförbrukning återstartstid mm.
SJÄLVKONTROLLERADE PAR
Dynamisk redundans som innebär att två identiska moduler ges samma input och output jämförs.
HYBRID REDUNDANS
Använder sig av en kombination av voting, feldetektion och modulsvitching.
N-MODULAR MED SPARES
Utdata mellan de två processerna jämförs för att hitta fel.
Recovery blocks använder någon form av feldetektion för att validera modulens operation, om ett fel upptäcks används alternativ process.
Baseras på acceptans tester, en typ av test kan vara att efter att ha kört en uträkning körs uträkningen baklänges för att kolla
processen.
Koncentrat av kap 7 (med betoning på koncentrat)
Tillförlitlighet (övningsuppgift 7.1)
Tillförlitlighet är sannolikheten för att en komponent fungerar korrekt under en bestämd tidsperiod och under givna omständigheter.
Tillförlitligheten beräknas enligt formeln:
R(t) = n(t)/N
- där n(t) står för antalet komponenter som fungerar korrekt under tidsperioden t och
- där N står för antalet identiska komponenter som ingår.
Otillförlitligheten kan beräknas enligt samma formel men då med antalet fallerande komponenter i täljaren istället. Otillförlitligheten kan också beräknas enligt formeln:
Q(t) = 1 - R(t)
Felfrekvens(övningsuppgift 7.1, 7.2 och 7.3)
Felfrekvens är lika med antalet felfunktioner under en given tidsperiod (t ex ett fel per 1000 tim ger felfrekvensen 1/1000).
Felfrekvensens förändring över tiden följer den sk "badkars kurvan". Av denna framgår det att antalet fel initialt är högt (måndagsexemplar, tillverkningsfel osv) för att snabbt minska till en låg konstant nivå för att slutligen öka till en hög nivå p g a åldrande. Perioden med lågt antal fel kallas för "useful life period". Förhållandet mellan tillförlitligheten och felfrekvensen framgår av följande formel:
R(t) = e-t där står för felfrekvensen under "the useful life period"
MTTF (övningsuppgift 7.4)
MTTF ( Mean Time To Failure) är den förväntade tiden till då en komponent fallerar första gången. MTTF beräknas enligt formeln:
MTTF = 0R(t)dt. Då är konstant är MTTF=1/
MTBF (Mean Time Between Failures) beräknas enligt:
MTBF = MTTF + MTTR
där MTTR står för Mean Time To Repair.
Tillgänglighet
Tillgänglighet är sannolikheten för att systemet skall fungera korrekt vid ett givet tillfälle. Denna beräknas enligt följande:
Tillgänglighet = MTTF/(MTTF + MTTR)
Modellering av tillförlitlighet
Kombinatoriska tillförlitlighetsmodeller medger att ett systems tillförlitlighet beräknas utifrån ingående delars tillförlitlighet.
Delarna kan vara komponenter eller delsystem.
Seriesystem
I ett seriesystem innebär felfunktion i en komponent att hela systemet fallerar. Tillförlitligheten i ett sådant system beräknas enligt följande formel:
R(t) = R1(t)R2(t)….RN(t)
Där R1(t), R2(t) osv står för resp dels tillförlitlighet.
Detta innebär att systemets tillförlitlighet minskar med antalet delar eftersom varje dels tillförlitlighet är mindre än ett.
Parallella system
I ett parallellt system medför fel i en komponent inte att hela systemet fallerar. I detta fall beräknas tillförlitligheten enligt:
R(t) = 1 - Q(t) = 1-(1-R1(t))(1-R2(t))….(1-RN(t))
Detta innebär att systemets tillförlitlighet blir högre än delarnas tillförlitlighet.
Kombinationssystem
I ett system som består av en kombination av både seriella och parallella delar beräknar man hela systemets tillförlitlighet
genom att först reducera delsystemens delar till att motsvara ett delsystem vardera. Därefter beräknas hela systemets
tillförlitlighet på delarnas värden.
Redundans
Redundans i ett system kan uppnås genom parallellkoppling av komponenter. Därmed erhålls feltolerans. Detta innebär inte
med automatik en ökad tillförlitlighet! Ökad tillförlitlighet får man bara om delarnas tillförlitlighet är större än 0,5.
Cut sets/path sets
Ett systems minimala cut sets erhålls genom att man letar upp alla de kombinationer av delsystem (komponenter) som innebär att systemet inte fungerar. Därefter beräknar man varje cut set tillförlitlighetsvärde enligt formeln:
P(C1) = (1-R1(t))(1-R2(t))…(1-RN(t))
Slutligen erhålls den övre gränsen för sannolikheten att systemet fallerar genom att summera samtliga P(C)-värden.
På motsvarande sätt är det med path sets. Här letar man upp alla de kombinationer som innebär att systemet fungerar. Detta
beräknas genom att dualsystemets cut sets beräknas enligt ovan. Dualsystemet erhålls genom att göra parallellkopplingar till
seriekopplingar och vice versa. Dessutom skall delarnas tillförlitlighetsvärde ersättas med dess komplementvärde.
Tillförlitlighet kontra MTTF (övningsuppgift 7.23)
Tillförlitlighet är en funktion av tiden medan MTTF är ett fast värde som inte påverkas av tiden. Detta innebär att om man
lägger till redundans i ett system kan tillförlitligheten över en given tidsperiod öka men minska systemets MTTF p g a
systemets ökande komplexitet.
Det finns bland övningarna ett stort antal räkneuppgifter. Dessa har vi medvetet ej lösningar till här. För att på bästa sätt lära sig beräkningarna bör var och en arbeta igenom uppgifterna.
Kapitel 8
Kapitlet omfattar delarna:
Konstruktionsfel hos mikroprocessorer
Val av mikroprocessorer
Elektromagnetisk kompatibilitet (störningsokänslighet)
Konstruktionsfel
I koden:
Sätt att rätta:
Man måste vara säker på att processorn har exakt samma masktyp (revision) som processorn under testen, det är dock inte
vanligt att tillverkare exakt följer upp med en ny revision för små ändringar av masktyp, såvida inte man måste följa en militär
standard (tex MIL-STD-883D).
Hantering av konstruktionsfel:
Göra systemet tolerant mot fel:
Att upptäcka och undvika fel:
Affärshemligheter
Val av mikroprocessorer
En av sakerna man tar hänsyn till i valet är antalet konstruktionsfel. (Det kan handla om hur processorn hanterar felaktiga instruktioner.) Man måste vara medveten om det eftersom standardprocessorer i första hand är gjorda för andra applikationer än för god systemsäkerhet. Man behöver också vara säker på att kompileraren utför mikrokoden rätt.
Elektromagnetisk kompatibilitet (störningsokänslighet)
problem kan vara:
Även om konstruktionen är god , kan den försämras av
Lagstiftning
I Europa skall en apparat vara så konstruerade att:
Kap 9 Safety-Critical Software (Bobbie Lundström)
Kapitlet behandlar:
Vid framtagning av programvara till icke-kritiska system slutar utprovningen när programmet inte längre sviktar eller stannar när man utför testerna, s. k. "dynamisk provning".
Detta täcker normalt in de situationer då programmet utsätts för ovanliga eller oväntade situationer.
Programvara för kritiska system skall även utsättas för "statisk provning". Man gör en analys av struktur och egenskaper (också kallat "statisk kod-analys"). Programmet "synas" utan att det exekveras t. ex. genom man analyserar hur data används och kommuniceras, hur minnena används, om det finns evighetsloopar, s.k. "svarta hål", och med avseende på kontrollfunktioner. Det finns särskilda verktyg för detta. (kap 12)
Begränsningar:
Statisk provning innebär att begränsningar görs på programspråk samt kräver väl utbildad personal samt att programmet bör utformas så att provning underlättas.
Kapitlet redogör för faktorer som inverkar på språkets användbarhet i kritiska system. Frågor man skall ställa sig är:
Inget program fyller kraven då de till del är motsägelsefulla. ADA ges som ett exempel på ett användbart program i kritiska system även om det inte är idealiskt. C är dåligt.
Det har utvecklats s.k. "subsets" ("utdrag ur") av språken vilka lämpar sig bättre i kritiska system. SPARK-Ada ligger väl till här liksom SPADE-Pascal.
Man påpekar betydelsen av kvaliteten på kompilatorerna.
Trenden är att man använder ADA och C++ (då det uppenbarligen finns fler programmerare som kan C++) med en dragning åt "mer ADA" i framtiden. Boken avråder bestämt från att använda C eller C++ i säkerhetskritiska system.
Programvaruutformning är en interaktiv och skapande process som stegvis förbättrar informationen man kan få ut av systemspecifikationen för att ta fram ett detaljutförande.
Uppgiften att göra detta kan delas in i två huvudaktiviteter som följer på varandra:
Arkitektonisk utformning
börjar med att dela upp systemet och fastställa vilka delar som skall realiseras med hård- resp mjukvara. De riktigt kritiska delarna skall realiseras med hårdvara och använda ROM i st f RAM. Därefter gör man en fullständig specifikation av arkitekturen inklusive alla gränsytor.
Uppdelningsprocessen går från stora moduler mot mindre. Varje modul skall ha sin egen specifikation. Parallellt bör man göra testplaner ("design for testability") och utkast till användarmanualer samt ta fram hur man skall utföra felhantering.
I detta arbete upptäcks många motsägelser i specifikationerna. Ändringar skall dokumenteras och överenskommas. Ackrediteringskrav måste tillgodoses på detta stadium.
En viktig del i detta arbete är att man får grepp om omfattningen av systemet och programvaran. En annan viktig del är att det blir möjligt att se vilka delar som kan isoleras från varandra så att fel inte "fortplantar sig" genom systemet och att identifiera säkerhetskritiska delar/moduler. Detta sätt att gå till väga underlättar också användningen av "interlocks"(kap 2) som har motsvarande uppgift.
Två särskilt viktiga aspekter ges på säkerhetskritisk programvara:
Med isolering avses uppenbarligen mest att reducera möjligheterna för en modul att skriva data i fel minnesplatser så att en annan modul får fel information (data) och/eller den egna modulen förlorar information (data).
Sättet att gå till väga påminner mycket om objektorientering och prototyping, vilket beskrivs summariskt.
Detaljerad utformning
Efter att den arkitektoniska utformningen har gett modulerna en hanterbar storlek vidtar detaljutformningen - vilket föregår programmeringen.
Här är man mer intresserad av vad modulen skall göra än hur.
Att tänka på:
Denna utvecklingsfas skall resultera i en specifikation som beskriver modulens funktion, överordnade rutiner, datastruktur, gränsytor, algoritmer och förutsättningar vilket kallas en "utformningsbeskrivning" (design description).
Man förordar återanvändning av kod som är välkänd.
kallas ofta kodning av den anledningen att det först nu sker en direkt koppling till ett programspråk som döljer processen.
Även här förordas ADA, som ofta betraktas som ett programutformningsspråk i st f enbart programspråk.
Säkerhet skall gå före effektivitet. Programmeringstricks som sparar några få bytes minne eller några millisekunder skall undvikas.
Man bör utnyttja "defensiv programmering" d v s se till att de antaganden som görs i algoritmen, t. ex. att värden ligger inom förutbestämda intervaller, är tillfredsställande innan exekvering utförs. Om det inträffar att ett antagande är ogiltigt, skall det resultera i ett "säkert tillstånd". Kontrollera särskilt hanteringen av noll-värden.
Noter (annotations) är ett sätt att gömma information i programmet för att underlätta senare provning och validering, ev med maskinella hjälpmedel. Noteringarna skall använda en syntax som är osynlig för den kompilator man avser använda.
finns för olika ändamål såsom för:
Beträffande pålitligheten hos verktygen konstateras att dessa inte är felfria. Man skall använda de mest pålitliga verktygen och välja sådana som är oberoende av varandra för att så långt möjligt eliminera felen hos dessa verktyg.
Kapitlet diskuterar varför man använder datorer och programvaror i stället för mekanik i säkerhetskritiska system. Det absolut säkraste är ju att inte ha datorer eller program i systemet om det innebär någon risk. Dock vi är villiga att ta vissa risker för att nå ett högre mål. Användningen av programvara ökar lavinartat - även i säkerhetskritiska system.
System som är mindre säkerhetskritiska har förhållandevis mer programvara i sig än de system som har högre krav på
funktionalitet. I mycket säkerhetskritiska system används datorer endast då ingen annan lösning är möjlig.
Bobbie
10 Programerbar logik för kontroll
Programerbar logik för kontroll (PLC) är självständiga minidatorer som är optimerade för industriell kontroll. Dom består av
en eller flera processorer tillsammans med kraftpaket och kretsar för interface i en passande förpackning. Ett antal moduler för
in och ut data finns tillgängliga för att enheten skall kunna användas i en rad tillämpningar, med hyllmateriel som hårdvara.
Möjligheter finns också för programmering och för generell systemutveckling.
Eftersom PLC i grunden är minidatorer i en låda, så är mycket av materialet i hårdvaru såväl som mjukvaru delarna av denna bok direkt relevanta för PLC användning. Dock, utvecklingen av system baserade på PLCs skiljer sig från den som sker för system som utnyttjar mer konventionell datorhårdvara.
Konsekvent kommer vi i detta kapitel att titta på delar som har relevans till system uppbyggda kring denna form av teknologi.
PLCs var introducerade på 1970 talet som en möjlighet att producera och marknadsföra datorer i stora kvantiteter, i en industriell miljö som karaktäriseras av en mångfald applikationer. På den tiden var enkla kontrollsystem uppbyggda kring elektromekaniska reläer, och PLCs sågs i inledningen som ersättare för dessa kretsar. Konstruktörer som arbetade med dessa relälösningar var vana att konstruera sina lösningar med hjälp av grafisk åskådning baserad på "trappstegs diagram". För att förenkla införandet av en alternativ teknologi, försäljarna av PLCs införde ett användar gränssnitt som möjliggjorde programmering på ett naturligt sätt för ingenjörer förtrogna med "trappstegs diagram". Inledningsvis var kontrollerna begränsade till enkel logik som kunde produceras mha reläer. Ju längre tiden gick ju fler genomarbetade inslag blev adderade för att möta de diverse önskemål från kontroll ingenjörerna. Dessa inkluderade sofistikerade displayer, loggning av data och kommunikations resurser Efter sin inledning har PLCs främst använts till maskin och process kontroll, och har därför använts i stor omfattning i säkerhets-kritiska tillämpningar. Av den anledningen, har utrustningarna special designats för hög driftsäkerhet och pålitlighet. Extra uppmärksamhet har ägnats åt hårdvaru driftsäkerhet och modern design utlovar extremt lång MTBFs. Under de senare åren har vi också PLCs producerade speciellt för hög integrerade applikationer. Dessa använder feltoleranta tekniker för att erhålla extremt hög driftsäkerhet, och en tillverkare hävdar en medeltid utan farliga fel på mer än 7,8 biljoner år (Boothroyd, 1995)! Trots detta måste man döma denna modellen i ljuset från de problem besläktade med uppfattningarna om tillförlitlighet som diskuterades i slutet på kapitel 7, det verkar som det finns enheter med hög tillförlitlighet tillgängliga.
Moderna PLCs kan programmeras på ett antal olika sätt. Vanligtvis är programmerings metoden byggd på att minimera utvecklingstiden och inte i lika hög grad att optimera hastigheten på utförandet. Det vanligaste sättet för programmering av applikations mjukvara till PLCs är nerladdning via serielänk. Användarprogram finns ofta i batteri uppbackade RAM, men för mer säkerhetskritiska applikationer är det att föredra att lagra mjukvaran i exempelvis EPROM eller EEPROM. Många PLC har denna möjlighet.
Eftersom PLCs ofta används i miljöer med risk för elektrisk störning läggs stor vikt på skydd mot detta i utveckling av dessa produkter.
De flesta enheter är uppbyggda för användning av ett grundsystem som erbjuder en uppsättning rutiner för styrning av de olika input/output enheterna. Enkla PLCs utför sina program utan någon form av fler användningar, men mer komplexa utrustningar kan vara mycket mer sofistikerade.
Programmeringsteknik för PLCs har vid ett antal tillfällen varit uppe för att erhålla någon form av standardisering. Det har enligt ISTVAN (980209) inte rönt någon större framgång, "oftast svårt då det är relativt små system att utnyttja standardiserade eller generella utvecklingsverktyg".
Dock redovisas i boken (IEC 1993) följande huvudtekniker:
En jämförelse mellan PLCs och relän ger följande aspekter för PLC
+ Större användningsområde
+ Större flexibilitet
+ Kortare utvecklingstid
- Större risk för fel i utvecklingen
- Känsligare för störningar (Ex EMC)
PLCs i säkerhetskritiska system
PLC har under många år använts i säkerhetskritiska system, ändå har de intill "nyligen" bara används vid applikationer med relativt liten integritet (sårbarhet).
Från kapitel 4 fick vi med oss skillnaden mellan system som ger kontinuerlig kontroll och system som är intermitenta såsom "shutdown" system.
"Shutdown" system används vid potentiellt farliga processer som kräver säkra tillstånd, sådana system kallas ofta "emergency shutdown" system ESD.
Funktionen för ett sådant system är att under kontrollerade former föra ett system till ett säkert tillstånd ifall någon parameter passerar definierade gränsvärden.
För att guida i standards för olika säkerhetskritiska system som kan härledas till olika grader av intigritet (sårbarhet) tar boken upp IEC 1508.
Intigritetsnivå 1 : 1001 (one-out-of-one) Se bild fig10.2 sidan 262.
1001D (Dual 1-out-of-1)
2: 2002 (2-out-of-2) Se bild fig 10.3 sidan 264
3: 2003 (2-out-of-3) Se bild fig 10.4 sidan 265
4: 2003D (Dual 2-out-of-3) Se bild fig 10.5 sidan 266.
(Detta alster är tillrättalagt efter genomgång av kapitlet 980209)
Sammanfattning av kapitel 14 - certifiering
1. Introduktion
Certifiering är en process som går ut på att exvis en komponent testas för att nå upp till en viss standard. Produkter som är certifierade enl. vissa standarder, har ett försprång vad gäller försäljning på marknaden. Certifiering genomförs ofta av centralt styrda eller stora, kända företag för att få acceptans på marknaden. Militära projekt kontrolleras i England av "Ministry of Defence" och i USA av "Department of Defense".
Certifiering kan utföras på :
Detta kapitel kommer i huvudsak att handla om system och produkter.
Utvecklaren måste noggrant förbereda certifiering och bl.a ta fram följande fakta:
Detta arbete är ett grannlaga och mycket viktigt arbete.
Organisationer vill genomföra certifiering för att säkerställa kompetens inom speciella områden. Ett exempel är kvalitetssäkring. Det finns många företag som har en kvalitetsorganisation som är certifierade enligt BS 5750 eller ISO 9000. Certifiering skall säkerställa att företag verkligen är så proffsigt organiserade att de följer givna standards. Det är relativt enkelt att undersöka arbetssätt i företag, men mycket svårare att mäta kompetens.
Därför sker ofta certifiering inom områden som kvalitetssäkring och testning före exvis design.
Certifiering kan också ske av enskilda personer exvis doktorer, civilingenjörer. Certifiering kan också utföras på driftpersonal
av säkerhetskritiska system.
Verktyg och metoder som används vid framtagning av säkerhetskritiska system skall certifieras. Det finns i detta fall flera olika standarder nämligen:
Kanske är den mest kända och använda certifieringsmetoden v.g verktyg metoden som hanterar programspråkskompilatorer.
Fastän certifieringsprocessen genomförs i slutet av ett projekt, måste detta arbete startas tidigt. Certifieringsprocessen innefattar bl.a att övertyga inblandade organisationer, personal m.fl om systemets säkerhet. Detta kallas i boken " certification liaison".
När man valt certifieringsmetod, skall man tillverka en "verifikationsplan" , som skall godkännas av företagsledningen. Denna skall bl.a innehålla:
Diskussioner mellan utvecklare och certifieringspersonal genomförs kontinuerligt under projektets gång, för att lösa ev.
problem efterhand.
The safety case är en sammanställning av alla säkerhetsrelaterade aktiviteter från projektets start till dess att projektet skrotas. Det är också viktigt att dokumentera vid ev. ändringar under drift av systemet. Detta underlag skall nyttjas vid certifiering för att underlätta denna. Det är nödvändigt att involvera användare, olika typer av experter i denna process, för att underlaget skall bli fullständigt.
Safety case innehåller:
Safety case måste innehålla alla dokument som rör säkerhet, och måste visa att systemet klarar av alla ställda säkerhetskrav.
Sidorna 365-370 innehåller en hel hop med standards som jag inte tänker kommentera.
Certifiering av ett säkerhetskritiskt datorsystem har flera syften. Dessa är:
CERTIFIERING ÄR DYRT!!
Nu var det slut på det roliga!