Reliable Architecture Ved Henrik Bærbak Christensen. Emne: Kritiske systemer Overvågning og kontrol system for et kemisk produktions anlæg CP09

Transkript

1 Reliable Architecture Ved Henrik Bærbak Christensen Emne: Kritiske systemer Overvågning og kontrol system for et kemisk produktions anlæg CP december, 2009 Gruppe 5 Thomas Mollerup Lanng, Michael Brøbech Mogensen,

2 Indholdsfortegnelse 1 Indledning Struktur og opgave beskrivelse Teori Kritiske systemer Terminologi og teknikker Risiko analyse og specifikation Arkitektur beskrivelse Arkitektur design og taktikker CP Formål Krav Analyse Risici identifikation og klassifikation Risici dekomponering Risici vurdering og reduktion Design Component og connector view Deployment view Design evaluering ved observer pattern Diskussion og refleksion Konklusion Gruppe 5 Side 2 af 22

3 1 INDLEDNING Denne rapport indeholder opgavebesvarelsen for den 3. obligatoriske opgave vedrørende design af en pålidelig software arkitektur med fokus på de underopdelte kvalitets attributter tilgængelighed(availability) og sikkerhed (safety) for et overvånings og kontrol system, CP09, til et kemisk anlæg. 2 STRUKTUR OG OPGAVE BESKRIVELSE Teori anvendt ved løsning af opgaven er beskrevet i afsnit 3 og en sammenfattende konklusion gives i afsnit 5. Opgaven beskrives i afsnit 4 og indeholder: Kravs beskrivelse for systemet En analyse og beskrivelse af risici, der kan forekomme i systemet herunder klassificering af risici, dekomponering af risici for at identificere årsager og en reduktion af risici ved anvendelse af arkitektur design taktikker Design af den pålidelige arkitektur, ved anvendelse af arkitektur views/viewpoints component og connector og deployment eller allocation, som kan reducere eller forhindre de identificerede risici herunder evaluering af et specifik design mønster, observer pattern, og anvendelighed i det eksisterende arkitektur design Diskussion og refleksion og opsamling på lærings punkter herunder fremtidige forbedringsmuligheder Gruppe 5 Side 3 af 22

4 3 TEORI I det følgende beskrives teori og metoder relevante for opgaven i denne rapport. 3.1 KRITISKE SYSTEMER Definition [4]: I et kritisk system er pålidelighed (dependability) den vigtigste kvalitet. Denne kan yderligere opdeles, som vist i Figur 1. Overordnet findes der 3 typer kritiske systemer: System Beskrivelse Sikkerheds kritiske systemer (safety critical) Et system karakteriseret ved, at fejl (failure) kan medføre skader, tab af liv eller seriøse skader på miljøet. Missions kritiske systemer (mission critical) Et system karakteriseret ved, at fejl (failure) kan medføre at en mål drevet aktivitet ikke kan fuldføres. Forretnings kritiske systemer (business critical) Et system karakteriseret ved, at fejl (failure) kan medføre høje tab for brugerne. Tabel 1: Klassificering af kritiske systemer [4]. Denne opgave vil hovedsagelig behandle aspekter af safety critical system, men vil også indeholde aspekter af business critical. Figur 1: Klassificering af kvalitets attribut pålidelighed (dependability) i under attributter [4] Kvalitets attribut Tilgængelighed (availability) Pålidelighed (reliability) Sikkerhed og miljø (safety) Beskrivelse 1. Et systems evne til at levere services, når det er påkrævet[4] 2. Sandsynligheden for, at et system vil være i stand til at levere de forventede services på et givent tidspunkt[6] 1. Et systems evne til at levere services, som specificeret[4] 2. Sandsynligheden for, at et system korrekt vil levere de forvente services over en given tidsperiode 1. Et systems evne til at være operationel uden at medføre en katastrofal fejl [4] Gruppe 5 Side 4 af 22

5 2. Afgørelse om hvor sandsynlig det er, at et system vil medføre skade på mennesker eller miljø [6] Sikkerhed (security) 1. Et systems evne til beskytte sig selv i mod tilfældig eller tilsigtet indtrængen[4] 2. Afgørelse om hvor sandsynlig det er, at et system kan modstå tilfældig eller tilsigtet indtrængen [6] Tabel 2: Klassificering af pålideligheds kvalitets attributter [4], [6]. Af disse kvalitets attributter er der availability og reliability, som kvantitativt kan måles ved at beskrive sandsynlighed. Safety og security måles kvalitativt ved en beslutning eller afgørelse om, at systemet er sikkert, dette gøres ved klassifikation af risici med hensyn til alvorlighed. 3.2 TERMINOLOGI OG TEKNIKKER Pålideligheden af et system kan forbedres ved at sikre kvalitets attributterne indeholdt i kvaliteten pålidelighed. Dette kan gøres ved at anvende specifikke teknikker for de enkelte attributter. Kvalitets attribut Behandles her sammen, selvom de ikke er ens. Beskrivelse Kontekst Failure og fault Tilgængelighed (availability) Pålidelighed (reliability) Sikkerhed og miljø(safety) Sikkerhed (security) Teknikker Fault avoidance Fault detection and removal Fault tolerance Kontekst Acciddent Hazzard Damage Hazzard serverity Hazzard proberbility Teknikker Hazzard avoidance Hazzard detection and removal Damage limitation Kontekst Exposure Vunerability Attack Threats Control Damage: denial of service, corruption of programs or data, disclosure of confidential information Teknikker Vunerability avoidance Attack detection and neutralisation Tabel 3: Sikring af pålidelighed vha. teknikker [4]. Gruppe 5 Side 5 af 22

6 3.3 RISIKO ANALYSE OG SPECIFIKATION I denne opgave er anvendt en risiko analyse og specifikation metode [4] til at beskrive og evaluere mulige risici systemet skal kunne i mødekomme klassificeret som tilladelighed, Tabel 4. Risiko klasse Ikke tilladelig (intolerable) Så lav som praktisk mulig (as low as reasonably pratical - ALARP) Tilladelig (Acceptable) Beskrivelse Systemet skal designes således, at den givne risiko enten ikke forekommer eller den ikke resultere i et uheld. Er typisk karakteriseret ved risici som vedrører menneske liv eller finansiel stabilitet og som har en betydelig sandsynlighed for at forekomme. Systemet skal designes således, at sandsynligheden for, at den givne risiko for et uheld reduceres eller i relation til andre aspekter som pris og aflevering. Systemet skal designes således, at alle tiltag udføres for at reducere sandsynligheden for, at risiko forekommer, disse aktiviteter må dog ikke forøge pris eller ændre planen. Tabel 4: Risiko klasser [4]. Denne analyse er understøttet af en risiko dekomponering, som beskriver mulige årsager til en identificeret risiko. Dette gør det muligt at beskrive en krav specifikation for systemet, som vedrører arkitektur kvaliteten pålidelighed. De enkelte steps og produkter fra processen [4] er beskrevet i Figur Risiko identifikation (produkt: risiko beskrivelse) 2. Risiko analyse og klassificering (produkt: risiko evaluering (assessment) ) 3. Risiko dekomponering: (produkt: root cause analysis (for eksempel fault tree) 4. Risiko reduktion assessment: (produkt: pålideligheds krav specifikation) Figur 2: Risiko analyse proces steps [4]. Step 3 i processen kan understøttes af deduktiv root cause analyse vha. fault tree, hvor risiko, øverste hændelse, dekomponeres indtil root cause haves for den enkelte hændelse. Figur 3: Fault tree - i dette tilfælde udsnit af deduktiv identifikation af risici for forkert beholder tryk. Gruppe 5 Side 6 af 22

7 3.4 ARKITEKTUR BESKRIVELSE Systemet i denne opgave har en arkitektur, som kan beskrives af en arkitektur beskrivelse (architectural description). Definition [6]: En arkitektur beskrivelse indeholder information om et systems strukturer, som indeholder software elementer, de eksterne synlige egenskaber for disse og relationerne mellem dem. Elementer er komponenter (components), som har funktionel opførsel og relationer (relations) er forbindelser (connectors), som vedrører kommunikation kontrollen mellem komponenter herunder protokol som definerer operationer og rækkefølge heraf og roller for de enkelte komponenter. Ontologien for arkitektur beskrivelse ses i Figur 4, hvor der introduceres abstraktioner viewpoint og views til beskrivelse af forskellige perspektiver af en arkitektur til forskellige interessenter (stakeholders). I denne opgave anvendes viewpoints component & connector og deployment. Figur 4: Ontologi af en arkitektur beskrivelse, opgave anvendte views er markeret rødt [5]. Component & connector viewpoint [5]: elementer består af komponenter (component) og relationer af forbindelser (connector) mellem disse, hvor komponenten indeholder funktionalitet og et veldefineret ansvar eller rolle og forbindelser er beskriver kommunikationen mellem komponenterne (herunder kontrol og data). Deployment viewpoint [5]: elementer består af software elementer, som kan være eksekverbare(executables) eller link libraries indeholdende komponenter, fra component & connector view og miljø elementer som er knuder (nodes) af computer hardware. Relationer består af følgende type: - allocated-to, som er viser til hvilke miljø elementer de enkelte software elementer er allokeret til - afhængigheder mellem software elementer - protokol forbindelser (links) mellem miljø elementer, som viser, hvilken kommunikations protokol anvendt mellem knuderne. Gruppe 5 Side 7 af 22

8 3.5 ARKITEKTUR DESIGN OG TAKTIKKER Arkitektur design processen beskriver, hvorledes en software arkitektur designes, således at både kvalitets attribut og de funktionelle krav opfyldes. Processen kan beskrives i step som i Figur Funktionelle krav og arkitektur kvaliteter beskrives 2. Design forslag 3. Evaluering ift. funktionelle krav og kvaliteter og den bedst egnede arkitektur vælges 4. Det valgte arkitektur design realiseres i et system Figur 5: Arkitektur design steps. Processen er karakteriseret ved at være: kreativ, iterativ (herunder de dekomponering af funktionelle og kvalitets krav), eksperimentel herunder arkitektur prototyping og baseret på erfaring. Definition taktikker [4]: Arkitektur design beslutning, der har indflydelse på kontrollen af et kvalitets attribut svar, Figur 6. En samling af taktikker kaldes også en arkitektur strategi. Er desuden karakteriseret ved at være, hvad arkitekter udfører i praksis. Taktikker kan detail beskrive andre taktikker og kan have indflydelse på mere end en kvalitets attribut, da kvalitets attributter er indbyrdes afhængige. Figur 6: Model af hvorledes taktikker kan kontrollere, ved et givet stimulus, kvalitets attribut svaret [4]. Klassifikation af kvalitets attributter og taktikker [6]: - Availability - Modifiability - Performance - Security - Testability - Usability I denne opgave behandles hovedsagelig tilgængelighed (availability )og pålidelighed (reliability), som ikke er ens, men i forhold til availability taktikker også har anvendelse for at sikre pålidelighed. Dekomponering af availability ift. taktikker, som kan anvendes til at maskere eller korregere fejl ses i Figur 6 og beskrivelse i Tabel 5. Gruppe 5 Side 8 af 22

9 Availability Fault types (problem) Fault detection Fault recovery- preparation and repair Fault recovery- reintroduction Fault prevention Figur 7: Tilgængeligheds taktikker [6]. Taktikker (løsnings muligheder) Ping echo, Heartbeat, exception Voting, active redundancy, passive redundancy, spare Shadow operation, state resynchronization, checkpoint rollback Removal from service, transactions Tabel 5: Availability fejl og taktikker [6]. Gruppe 5 Side 9 af 22

10 4 CP09 Dette afsnit indeholder løsningsbeskrivelsen for opgaven CP09, herunder analyse og arkitektur design. 4.1 FORMÅL Formålet med opgaven er at designe en arkitektur, som adresserer forretnings- og sikkerheds(safety) aspekter til et kemisk anlæg. Arkitekturen skal kunne håndtere risici for højt eller lavt tryk i systemet som beskrives med kvaliteten pålidelighed og kvalitets attribut availability. 4.2 KRAV De overordnede krav til realiserede system er beskrevet på system koncept Figur 1 og overordnede krav i Tabel 1. Figur 1: Koncept system [1]. Id Krav Kravs klasse KR-1 KR-2 KR-3 For højt tryk eller for høj temperatur vil sprænge og ødelægge beholderen og væskerne heri vil fordampe i anlægges omgivelser og udgør en alvorlig risiko for menneskene i anlægget. Desuden vil en efterfølgende reparation, oprydning og afbrudt produktion være meget bekostelig for anlægget. I tilfælde af en nødsituation hvor tryk og temperatur opbygges vil en sikkerhedsventil åbne og føre væskerne til et sikkerhedskammer og hermed undgå skader på mennesker og beholder. Nøjagtig kontrol af den kemiske proces er meget vigtig pga., at selv meget små afvigelser / fejl i temperatur og tryk vil resultere i, at output C vil blive af lav kvalitet, hvilket vil reducere prisen på produktet betragtelig og dermed fortjeneste for anlægget. Det er forudset, at systemet vil indeholde en applikation kaldet CP09- control. Ansvar: kontrollere den kemiske proces for maksimere sikkerhed Safety/business Business Funktionalitet / komponent Gruppe 5 Side 10 af 22

11 KR-4 (safety) og fortjeneste. Algoritmen, som beregner den rette kontrol af pumpestyrke, varme og udgangsventil åbning, er meget kompleks og involverer at løse en hydro-dynamiske ligninger i real-tid. Det er forudset, at systemet vil indeholde en applikation kaldet CP09- monitor Ansvar: At vise et grafisk billede og visualisere systemet på Figur 1 i kontrolrummet i anlægget, således af beholderen vises med sensor og aktuator data og alarmere operatørerne i tilfælde af detekterede risici i systemet. Tabel 1: Overordnede arkitektur krav [1]. Funktionalitet / komponent 4.3 ANALYSE I det følgende afsnit bliver der fortaget en delvis risiko drevet specifikation analyse [1]. Analysen tager udgangspunkt i en risici identifikation, som herefter dekomponeres vha. fejl træet (fault tree). Fejlene kategoriseres og en vurdering (assessment) udføres, som vha. arkitektur kvalitets taktikker søger at reducere eller maskere de identificerede risici. Analyse vurderings produktet anvendes i design afsnittet til den safety og business kritiske arkitektur for systemet CP Risici identifikation og klassifikation De ikke fyldestgørende identificerede risici fra opgave beskrivelsen [2] for det realiserede system er beskrevet i Tabel 2. Identificeret risici Risiko klasse Risiko Konsekvenser Tilladelighed alvorlighed Beholder tryk for højt Service failure Høj Safety Intolerable Beholder tryk for lavt Service failure Medium Business ALARP Sensor (temperatur / tryk) Physical Medium Safety / ALARP målinger forkerte Business Sensor computer crash Service Medium Safety / ALARP Business Aktuator (pumpe / ventil / Physical Medium Safety / ALARP varmelegeme) ignorer kommando Business Aktuator computer crash Service Medium Safety / ALARP Business Væske indløb (A / B) er blokeret physical/mechanical Medium Safety / ALARP Business TCP/IP netværk fejl Physical Lav Safety / ALARP Business Tabel 2: Identificeret og klassificerede risici [2]. Afgrænsning [2] 1. De første 2 risici, beholder tryk for højt eller lavt, er høj risiko niveau, mens de resterende risici er lav risiko niveau, hvilket betyder, at beholder tryk er afhængig af f.eks. en sensor måle fejl. Netværks tilgængeligheden er sikret ved at have 2 uafhængige netværk. Derfor indeholder hver computer knude 2 netkort, som hver er forbundet med forskellige fysiske LAN netværk. Derfor kan risikoen for netværks fejl ses bort fra. 2. Risici for højt eller lavt tryk kan samles i risikoen forkert beholder tryk i fault tree, pga., at de har lignende risiko dekomponering. Gruppe 5 Side 11 af 22

12 4.3.2 Risici dekomponering Fejl træet for risikoen Forkert beholder tryk ses i Figur 2. Med udgangspunkt i denne risiko er der deduktivt analyseret, hvad der kan medføre denne risiko ved at spørge til iterativt hvad kan gå galt indtil bunden af træet nået, som beskriver root causes eller årsager, der i sidste ende fører til den uønskede tilstand. Forkert beholder tryk Temperatur og tryk Ukorrekt måling Kontrol algoritme fejl (1) Strømsvigt (2) Defekt overløbsventil Defekt udgangsventil Defekt pumpe Defekt varmelegme Manglende vedligeholdelse (5) Manglende vedligeholdelse (6) Manglende vedligeholdelse (7) Manglende vedligeholdelse (8) Sensor fejl (3) Sensor Algoritmefejl (4) Manglende data Computer crash Sensor data forsinket Strømsvigt (9) Overbebyrdet computer Hardware fejl som følge af slitage Software fejl Defekt hardware (10) Manglende vedligeholdelse (11) Manglende vedligeholdelse (12) Figur 2: Risiko dekomponering ved fault tree [4]. Gruppe 5 Side 12 af 22

13 Sammenfatning af root causes ses i Tabel 6. Id Root cause Klasse RC-1 Sensorfejl Fysisk fejl RC-2 Sensor algoritmefejl Service fejl RC-3 Kontrol algoritmefejl Service fejl RC-4 Manglende vedligeholdelse Fysisk fejl RC-5 Defekt hardware Fysisk fejl RC-6 Strømsvigt Fysisk fejl Tabel 6: Identificeret root causes. Diagrammet er fokuseret på sikkerhedsaspektet og viser derfor ikke, at de samme hændelser også kan føre til, at blandingsforholdet i beholderen kan blive forkert. Grenen Ukorrekt måling gælder for både temperatur og tryk sensorer. Fortolkningen kan være forkert pga. sensor fejl, algoritmefejl (dækker også aritmetiske fejl) eller manglende data. Manglende data kan skyldes, at computeren er gået ned eller at den har for meget at lave, f.eks. hvis data ophober sig over lang tids drift uden passende vedligeholdelse. RC-3 Kontrol algoritme fejl gælder også for både tryk og temperatur og er i det tilfælde hvor, algoritmen ikke leverer et korrekt resultat som følge af software fejl. RC-4 Manglende vedligeholdelse af systemet kan skyldes forglemmelse fra personalets side eller uvidenhed, som følge af mangelfuld vedligeholdelses instruktioner. Under vedligeholdelse kommer også regelmæssig udskiftning af komponenter med begrænset levetid. Gruppe 5 Side 13 af 22

14 4.3.3 Risici vurdering og reduktion Nedenfor i Tabel 3 er de individuelle root causes listet og arkitektur taktikker [6] til, at reducere eller maskere fejlene. Id Root cause Availability kvalitets Taktikker og løsning Attribut / fault type RC-1 Sensorfejl Fault recovery - repair, Redundans og Ping / echo Fault detection RC-2 Sensor algoritmefejl Fault recovery - repair Redundans og voting RC-3 Kontrol algoritmefejl Fault recovery - repair Redundans og Passive redundancy, voting RC-4 Manglende vedligeholdelse Fault detection Vedligeholdelsesplan, software notifikation RC-5 Defekt hardware Fault recovery - repair, Fault detection Redundans, Ping / echo strategi, heart beat RC-6 Strømsvigt Fault recovery - repair Redundans, UPS tilknyttes de enkelte delsystemer Tabel 3: Arkitektur strategi givet root cause analyse. RC-1 Sensorfejl Sensorfejl er der allerede taget højde for ved at dublere de to sensortyper og dermed gives der muligheder for at lave validering af de forskellige resultater i forhold til hinanden. RC-2 Sensor algoritmefejl Denne er beskrevet i afsnit RC-3 Kontrol algoritmefejl Denne er beskrevet i afsnit RC-4 Manglende vedligeholdelse Manglende vedligeholdelse er den fejlkilde, der kan føre til flest fejltilstande i systemet. Og det skyldes, at mange af komponenterne i systemet har en begrænset levetid og at der er tale om et system, der behandler fysiske materialer. Derfor er vurderingen, at det er afgørende, at der regelmæssigt foretages manuelt inspektion og vedligeholdelse af systemet. Herunder de fysiske dele som ventiler, pumper og lignende, men også computere og deres forskellige software komponenter. Af træet ses det at manglende vedligeholdelse kan føre til softwarefejl og ideen er her, at vedligeholdelse af computere sikrer, at når der er ryddet op så stiger kravene til ressourcer efterhånden som der opsamles data/logs under produktion. Vedligeholdelse omfatter også periodemæssigt udskiftning af hardware i forhold til forventet levetid, opgradering af antivirus, OS patching og periodisk eftersyn af diske. Risikoen minimeres ved at introducere et software vedligeholdelses program, der indeholder alarmer, beskrivelser og huskelister som personalet kan benytte til at huske hvad der skal laves og hvornår. Gruppe 5 Side 14 af 22

15 RC-5 Defekt hardware Erfaringsmæssigt viser det sig, at hardware ikke er fejlfrit og at hardware delkomponenter ikke altid holder så længe som forventet i forhold til specifikationerne. Risikoen minimeres med redundant hardware. RC-6 Strømsvigt Et strøm svigt kan forekomme på flere niveauer. Et totalt strømsvigt, vil få alle pumper og varmelegeme til at stoppe med at virke, det betyder, at produktionen vil stoppe og kedlen langsomt vil gå i stå, hvilket betyder, at materiale måske vil gå tabt og der spildes tid på atter at få startet systemet op igen. Et delvist strømsvigt kan være fatalt, hvis det er på en af de enkelte dele. Hvis strømmen til en computer svigter udebliver måleresultaterne med fare for manglende styring af den aktuelle ind/ud mængde af materiale eller varme med fare for højt tryk i beholderen. Risikoen for strømsvigt minimeres til så lavt et niveau som praktisk muligt (ALARP) ved at benytte UPS på hvert enkelt delsystem. Der vil stadigvæk være mulighed for at UPS komponenten kan fejle samtidig med at den el nettet fejler eller at en ledning rives over til komponenten der afhænger af strøm. Gruppe 5 Side 15 af 22

16 4.4 DESIGN I det efterfølgende afsnit præsenteres et design, der tager højde for de identificerede risici og i øvrigt holder fokus på tilgængelighed (availability) og sikkerhed (safety). Målet er at skabe et system der til en hvert tid er tilgængeligt og minimere fare for person skade Component og connector view I det følgende afsnit diskuteres arkitektur design, der adressere de områder fra fejltræet, der ikke allerede er behandlet. Det vil sige sensorfejl og algoritmefejl ved sensorerne og i kontrol algoritmen. Udgangspunkt Nedenfor i Figur 8 vises udgangspunktet for udarbejdelsen af den endelige løsning. Figur 8 giver et overblik over systemets grundlæggende elementer. Tryk sensor #1 * * Udløbsventil * Tryk sensor #2 Overtryksventil Temperatur sensor #1 * * * Kontrol enhed (CP09) * * * * Pumpe A Temperatur sensor #2 * * Pumpe A Figur 8: Udgangspunkt for component & connector view Af Figur 8 ses det, at systemet er udstyret med sensorer til tryk og temperatur, ventiler til udløb og overtryk og to pumper der tilfører beholderen materiale. Systemet styres af en kontrolenhed. Endvidere er defineret en komponent til overvågning, som beskrevet i KR-3 og KR-4, Tabel 7. KR-3 KR-4 Det er forudset, at systemet vil indeholde en applikation kaldet CP09- control. Ansvar: kontrollere den kemiske proces for at maksimere sikkerhed (safety) og fortjeneste. Algoritmen, som beregner den rette kontrol af pumpestyrke, varme og udgangsventil åbning, er meget kompleks og involverer at løse en hydro-dynamiske ligninger i real-tid. Det er forudset, at systemet vil indeholde en applikation kaldet CP09- monitor Ansvar: At vise et grafisk billede og visualisere systemet på Figur 1 i kontrolrummet i anlægget, således at beholderen vises med sensor og aktuator data og alarmere operatørerne i tilfælde af detekterede risici i systemet. Tabel 7: Komponent funktionalitet og ansvar. Funktionalitet / komponent Funktionalitet / komponent Gruppe 5 Side 16 af 22

17 Endelige view I den færdige løsning er der tilført nye elementer som resultat af nedbrydning af kontrolelementet og adressering af de risici, der ønskes minimeret eller fjernet. Det endelige CP09 component & connector view ses i Figur 9. Tryk sensor #1 Sensor par #1 CP09 CP09 Kontrol #1 Heart beat Udløbsventil Overtryksventil Temperatur sensor #1 TCP/IP CP09 Kontrol #2 Pumpe B Tryk sensor #2 RS232 TCP/IP RS232 Pumpe A Sensor par #2 Temperatur sensor #2 Overvågning Figur 9: CP09 component and connector view. Sensor par #1 og #2 Da hver sensor for temperatur og tryk er dubleret er det oplagt at kombinere dem for på den måde at udnytte, at systemet kan fungere med kun det ene par og på den måde i møde komme root causes sensorfejl og sensoralgoritmefejl. Sensor par #1 og #2 er udstyret med, hver deres computer til aflæsning og fortolkning af resultater. Sensor komponenten implementerer en Ping/echo [6] taktik, der sikrer, at sensorfejl detekteres, idet der polles med faste mellemrum for måleresultater. I tilfælde af manglende svar eller gentagne forsinkede svar kan operatøren notificeres. Resultaterne underlægges en acceptance test [3], der afgør om resultaterne ligger inden for gældende domæne. CP09 For at adressere root cause defekt hardware er CP09 opdelt i to komponenter, der er konfigureret som Passive redundancy [6] Den aktive komponent sender alle måleresultater og styringsdata over til den passive, for på den måde at holde den opdateret med henblik på at overtage processen i tilfælde af problemer. Den passive komponent udnytter en Heart beat taktik [6] til overvågning af den aktive. Da måleresultater og styringsdata skal komme med regelmæssige mellemrum vil manglende data betyde, at den aktive komponent ikke er i stand til at drive processen og så overtages den aktive rolle samtidig med at operatøren notificeres om hændelsen med henblik på, at han skal udrede og udbedre fejlen med den, nu passive komponent. Fra CP09 siden virker, hvert sensor par som Active redunancy [6] da de begge leverer identiske resultater. Resultaterne sammenholdes og accept testes [3], og hvis det ene skiller sig meget ud fra det andet er det muligt at lave sammenligning med tidligere resultater og udlede, hvilken sensor der er defekt. Gruppe 5 Side 17 af 22

18 For at minimere risikoen for kontrolalgoritmefejl genereres styringsdata af tre uafhængige algoritmer (N-versions programmering [3]), hvor der med vælges med flertalsafgørelse det endelige resultat og endvidere sikres, at der ikke kommer voldsomme afvigelser i styringen ved at normalisere resultatet ud fra definerede grænseværdier. I tilfælde af at grænseværdierne for maximalt ændring i styringen overskrides notificeres operatøren. Ved løbende at lave overvågning gives der mulighed for differentieret handling på baggrund af de målte data, så der kan defineres forskellige grader af fejl situationer, hvor en mindre overskridelse af tolerancerne udløser en alarm og hvis ikke operatøren får afhjulpet problemet i tide så går systemet ned til safe mode [6], hvilket vil sige at processen stoppes. Arbejdsstation Der er yderligere tilført en arbejdsstation til manuel overvågning af systemet aktuelle tilstand i form af alarmer og afvikling af vedligeholdelsessoftware. Yderligere tiltag Hvis kunden er villig til at betale for et ekstra sensor par er det muligt at løfte systemet evne til fejl recovery betragteligt, fordi det så vil blive muligt at lave afstemning (voting [6]) på måleresultaterne. Den nuværende konfiguration understøtter ikke voting, fordi der skal bruges mindst tre resultater for at opnå flertal. En voting taktik kombineret med de muligheder, der vurderes at være for validering af resultaterne vil bringe systemets pålidelighed til et niveau, hvor risiko for, at der benyttes fejlagtige måleresultater kan betegnes som i kategorien ALARP [6]. Ovenstående løsning anses for passende i denne sammenhæng, men der er stadigvæk en mindre chance for at hvis eksempelvis et måleresultat får en af CP09 algoritmerne til at gøre systemet ustabilt, så vil det også ske på den redundante komponent fordi de er identiske og har synkroniseret datagrundlag. Når skiftet sker, vil den nye aktive komponent overtage, hvor den anden måtte give op og dermed bliver den også ustabil. Som option kan kunden også vælge at sikre sig yderligere ved at lade de enkelte algoritme køre i virtuelle maskiner. Det får betydelig konsekvens på pris, men til gengæld er der mulighed for at hver version af algoritmerne ikke bare kan udvikles i forskellige sprog, men at de også kan afvikles på forskellige platforme Deployment view Figur 10 viser deployment view for det ikke safety og business kritiske CP09 system. Dette er udgangspunktet for det endelige deployment view for CP09. Figur 10: Principielle deployment model uden safety krav. Gruppe 5 Side 18 af 22

19 Nedenfor i Figur 11 ses det endelige deployment view for CP09, som inkludere alle elementer og relationer fra component & connector view Figur 9. Figur 11: Safety kritisk deployment Design evaluering ved observer pattern Indføring af observer mønstret betyder, at roller byttes rundt, så CP09 ikke længere skal servicere arbejdsstationer, men de kan selv abonnere på dataene direkte frasensorerne. Udnyttelse af observer mønstret er en god ide og vil sandsynligvis blive brugt på CP09 komponenten netop til håndterings arbejdsstationer. Observer mønstret tilføjer fleksibilitet, da det er nemt at tilføje flere abonnenter på sensor dataene. Udvekslingen vil også med observer løsningen blive asynkron i stedet for synkron, forstået på den måde, at data bliver leveret som events i stedet for som svar på forespørgsler. Med den nuværende løsning vil det i relation til sensor parrene være oplagt at behandle tryk og varme sensorerne ens af hensyn til genbrug af kode og protokoller. Gruppe 5 Side 19 af 22

20 Indførelse af RMI betyder, at formelle protokoller til aflæsning af sensor målingerne bliver erstattet af API beskrivelser og at der kommer kompileringscheck på data udvekslingen. I forhold til tilgængeligheden vil implementering af observer på sensor åbne op for, at arbejdsstationerne kan virke uafhængigt af kontrol og styrings komponenten. 4.5 DISKUSSION OG REFLEKSION Løsning af denne opgave har vist at brug af teorien i høj grad er en kreativ proces forstået på den måde, at der ofte er flere løsninger på det samme problem, men med forskellige karakteristika. Graden af kreativitet er erfaret ved vigtigheden i at få lavet et godt udgangspunkt for løsningen. Udgangspunktet var fejltræet, hvor en brainstorm over tid til sidst udformede et stort fejltræ med alle mulige risici. En nærmere analyse viste overlap og at hvis fokus var på de sikkerhedskritiske områder, så var vi dækket ind også med hensyn til de forretningskritiske områder. Resultatet blev, at vi afgrænsede løsningen til udelukkende at fokusere på sikkerhedsaspektet. Opgaven illustrerer et fint sammenspil mellem de forskellige views og viewpoins, fra starten med fejltræet over til component & connector view for til sidst at vise, hvordan og hvor meget hardware der skal bruges i deployment view. Produktet af denne opgave er blevet et godt overblik over systemet og kan i den færdige tilstand bidrage til god kommunikation mellem arkitekter, udviklere, kunder og andre interessenter. Vi ville gerne have realiseret dele af arkitekturen for afprøve teknikkerne i praksis. Dette kunne f.eks. tage udgangspunkt i nogle simulerede sensorer og kontrollere i et virtualiseret miljø. Gruppe 5 Side 20 af 22

21 5 KONKLUSION Resume: Vi har erfaret, hvordan risiko analyse og specifikations processen ved en struktureret tilgang giver indblik i risici for hændelser, som et systems arkitektur skal kunne håndtere og hvilke hændelser er tilladelige, men ønskes reduceret bedst mulig i designet. Ortogonalt med de funktionelle krav og kvalitets attributter en arkitektur skal opfylde er det hermed muligt at specificere safety krav, som skal opfyldes. I denne opgave har set på, hvorledes disse krav opfyldes i arkitektur designet ved anvendelse af availabilty og fault toletance taktikker. Gruppe 5 Side 21 af 22

22 Referencer 1. Monitor and control system for a chemincal plan, CP09, kravsbeskrivelse, Henrik Bærbak Christensen, Monitor and control system for a chemincal plan, CP09 opgavebeskrivelse, Henrik Bærbak Christensen, Handbook of Software Reliability Engineering, Michael R. Lyu (Ed), McGraw-Hill, Software Engineering 7th Ed", Sommerville, Addison-Wesley, An Approach to Software Architecture Description Using UML Revision 2.0, Henrik Bærbak Christensen et al., University of Aarhus, Computer science, Software Architecture in Practice 2nd Ed, Bass, Clements, and Kazman, Addison-Wesley 2003 Gruppe 5 Side 22 af 22