Availability og reliability i softwarearkitektur

Transkript

1 Availability og reliability i softwarearkitektur Gruppe 2 Jørgen Vrou Hansen Marjus Nielsen Said Shah Alizadeh marts 2010 Abstract Dette papir omhandler arkitektoniske discipliner og metoder behandlet under Reliable Software Architecture fagpakken. Vi afprøver metoder til at beskrive availability og reliability krav og fejlmuligheder i et konkret system, og taktikker til at opnå en arkitektur som overholder de beskrevne krav.

2 Indholdsfortegnelse 1 MOTIVATION SYSTEMBESKRIVELSE PROBLEMFORMULERING AFGRÆNSNING METODE RELEVANTE TEORIER OG PUBLIKATIONER FAULT, ERROR OG FAILURE Dependability Fault tolerance KVALITETSATTRIBUTTER Quality Attribut Scenarios SOFTWARE RELIABILITY METRIC FAULT TREE ANALYSE SURVIVABILITY ARKITEKTONISKE PROTOTYPER ANALYSE OG RESULTATER REFERENCE ARKITEKTUR Module view Component & Connector view Allocation view QUALITY ATTRIBUTE SCENARIOS FAULT TREE Tab af målere FAULT TREE OG SCENARIER ARKITEKTONISKE TAKTIKKER PROTOTYPE NY ARKITEKTUR Module view Sekvensdiagram for aflæsning af måler Allocation view KONKLUSION REFERENSER APPENDIX A: QAS APPENDIX B: FAULT TREE ANALYSE Tab af data Tab af netværket Side 2 af 34

3 1 Motivation I fagpakken Relaiable Software Architecture har vi skaffet os bekendtskab med arkitektoniske grundelementer indenfor udvikling af pålidelig software. Vi har beskæftiget os med metoder til at beskrive krav til et system og at analysere fejlkilder. Har været igennem adskillige taktikker for at opnå de arkitektoniske kvaliteter og lært hvordan den resulterende arkitektur dokumenteres. Vi finder det relevant at afprøve nogle af disse metoder og taktikker i et konkret projekt fra en af vores arbejdspladser hvor der laves et system som afregner borgernes varme og strømforbrug. Dette involverer bl.a. nøjagtige forbrugsmålinger som aflæses og indsamles på bestemte tidspunkter. På grund af at systemet bruges til afregning er der store krav til availability, reliability og security. Disse krav er business kritiske for udviklingsvirksomheden fordi forkerte målinger vil medføre enten at energileverandøren taber penge hvis forbruget måles for lavt eller i modsat fald at kunderne bliver utilfredse. Desuden er området reguleret af lovgivning. Lovgivningen er dog mest i forhold til sikkerhed fordi der behandles persondata. Krav om sikkerhed er udenfor scope af denne opgave. Kravene om reliability og availability danner grundlag for at vi i praksis kan afprøve og vurdere nogle metoder, værktøj og taktikker til at adressere disse kvalitetskrav. Målet er at projektet resulterer i en arkitektur som med rimelighed kan antages at overholde kvalitetskravene for reliability og availability. Projektets vigtigste formål er at vi opnår domain kendskab indenfor dependable software arkitektur som senere kan anvendes i forbindelse med praktiske erhvervsmæssige problemstillinger. Side 3 af 34

4 2 Systembeskrivelse Et Automatisk Meter Reading (AMR) system består af et antal målere forbundet til et radiomodul. Radiomodulerne samt et vist antal routere og en central opsamlings enhed, den såkaldte concentrator, danner et radionetværk. Concentratoren administrerer netværket og udfører jobs til aflæsning af målerne. Data logges, omformateres og sendes til et overliggende system, kaldt afregning systemet. Afregning System konc. Forsk. teknologier: Wir. M-Bus, Z-Wave, H W C ZigBee etc. E E H W C D Forsk. teknologier E D H W C E H H H W C E H H H W C Router samler et antal varmemålere op (10-200) via P2P (et hop) wireless M-Bus. Router kan være batteriforsynet eller netforsynet El måler (E) Vand(W) varme(h) Køle (C) Display (D) Figur 1 system oversigt Et fuldimplementeret AMR system involverer mange hardware- og software komponenter. For at begrænse opgaven indenfor projektets rammer har vi valgt at arbejde med en simplificeret udgave af AMR systemet som vist i Figur 1. Vi abstraherer væk fra enhver router og repeater, alternative routnings veje samt at hele overliggende system bliver betragtet som en enkelt afregnings applikation. Side 4 af 34

5 3 Problemformulering Vi vil afprøve og evaluere metoder til at opnå en arkitekur med krav til availability og reliability i et konkret projekt. Opgaven omfatter beskrivelse af availability og reliability krav til systemet samt en vurdering af hvordan disse krav kan opnås. Et lille udsnit af mulige løsningsforslag afprøves ved hjælp af prototyper. 3.1 Afgrænsning I dette projekt afgrænser vi os fra at inddrage andre kvalitetsattributter end reliability og availability. Side 5 af 34

6 4 Metode Som udganspunkt for projektet laver vi en referense arkitektur, som ikke fokuserer på availability eller reliability. Derefter laves en fault tree analyse for at vise potentielle fejlkilder og kvalitetskrav til dele af systemet beskrives i kvalitets attribut scenarier. På den baggrund udvælges en mængde availability og reliability tactics, som afprøves vha. arkitektoniske prototyper. De bedst egnede taktikker bruges til at lave en ny arkitektur, som overholder kvalitetskravene til systemet. Projektet resulterer i en vurdering af i hvor høj grad de anvendte taktikker og metoder forbedrer availability og reliability i forhold til referencearkitekturen. Det teoretiske indhold fra foregående kurser i Reliable Software Architecture danner hovedsagligt rammerne for den teoretiske del af projektet. Vi har ydermere opsøgt flere materialer med fokus på det relaterede metoder, kvalitetsattributscenarier (herefter QAS), fault tree og prototyping. Disse artikler skal hjælpe gruppen med at tilegne sig den nødvendige teoretiske viden for at opnå et højere niveau af konkretisering og detaljering. Under afsnit 5 er der en liste over disse artikler og kilder samt en gennemgang af de anvendte teorier. På baggrund af ovennævnte metoder som vi tager udgangspunkt i, kan vi be- eller afkræfte om arkitekturerne vil være fornuftig i forhold til vores system og de stillede krav. Som modellerings metode anvender vi UML. Denne rapport og kilde koden vil være samlingen af dokumenter produceret under dette projektforløb. Kildekoden er vedlagt i en zip fil. Side 6 af 34

7 5 Relevante teorier og publikationer Vi har udvalgt, læst og evalueret en del artikler som er listet i afsnit 8. Disse skulle hjælpe med at inspirere os til et bedre design. Ligeledes har vi også brugt disse artikler som fundament for en bredere vinkel på visse problemstillinger, såsom fault tree. Herunder laver vi en gennemgang af de aktuelle teorier med henvisning til de relevante artikler. 5.1 Fault, error og failure [Avizienis], [Bass], [Sommerville] og [Burnstein] definerer begreberne fault, error og failure. Fault er en fejl som er indført i systemet af udviklere, hardwarefejl eller interaktionsfejl [Avizienis]. Error er en forkert eller ugyldig tilstand i systemet som kan føre til at systemet ikke fungerer korrekt Failure dækker over at systemet ikke kan udføre operationer i henhold til specifikationen Der er overordnet tre måder at undgå failures i et system [Sommerville]: Fault avoidance undgå at lave fejl Fault detection and removal finde og rette fejl Fault tolerance undgå at faults i systemet udløser failures [Avizienis] bruger desuden begrebet Fault forecasting hvor man vurderer antallet af faults og hvilke konsekvenser de kan få Dependability Dependability er et systems evne til at levere en service som man med rette kan stole på. Dependability kan også defineres som et systems evne til at undgå service fejl som forekommer oftere eller er alvorligere end man kan acceptere [Avizienis]. Dependability er stort set det samme som survivability hvilket defineres som et systems evne til at udføre sin opgave til tiden [Avizienis]. Survivability beskrives nærmere i afsnit Fault tolerance Fault tolerance udføres ved at opdage fejl og undgå at de manifesterer sig som failures. Alle fault tolerance teknikker er ikke lige effektive. Deres evne til at undgå failures kaldes deres coverage. Coverage påvirkes af om man i designet af fault tolerance teknikken kan forudsige typen af fejl og hvor de kan opstå, og i hvilket omfang man er i stand til at behandle de fejl man opdager [Avizienis]. 5.2 Kvalitetsattributter Computersystemer anvendes til mange kritiske forretnings-applikationer, hvor svigt kan få alvorlige konsekvenser (store økonomiske tab). Udvikling af systematiske metoder til at relatere kvalitets attributter i et system giver et solidt grundlag for at træffe beslutninger om design tradeoff og gør det muligt for udviklere at forudsige hvilke system attributter et givent system må overholde. Det endelige mål er evnen til at evaluere og udarbejde Side 7 af 34

8 tradeoff mellem forskellige kvalitet attributter for at nå frem til et bedre samlet system [cert] Quality Attribut Scenarios Kvalitets attributter beskriver en bestemt brugerforventning til systemet som skal indfries under bestemte omstændigheder. [Bass] Scenarier for kvalitets attributter skal skrives specifikt så en arkitekt har bedst mulighed for at lave et godt design. Hvordan man definerer og specificerer en QAS er illustreret i nedenstående tabel. Scenario Illustration Source of stimulus. Dette er en enhed (computer, menneske eller andet) som genererer stimulus. Stimulus. Stimulus er en tilstand der skal tages stilling til når den opfanges af systemet Environment. Stimulus optræder på bestemte betingelser. Systemet kan være i en overloaded tilstand, eller kørende, når stumulus indtræffer. Artifact. En komponent er stimuleret, dette kunne være en bestemt komponent, eller hele systemet. Response. Dette er svaret efter at aktiviten er blevet behandlet at systemet. Response measure. Når svaret kommer skal det være målbart sådan at kravet kan eftervises eller testes. Figur 2 Quality attribute scenario Scenarier beskriver en kvalitet i systemet, men de beskriver ikke hvordan de vil blive opnået. For hver kvalitets scenaio kan der være mange måder at opnå den på. Det er derfor op til arkitekten at vurdere ud fra system krav og miljø hvordan man får man bedst mulige trade-off [Bass]. Projektgruppen vil bruge QAS til at vurdere hvilke arkitektoniske taktikker der er mest relevante i forhold til de opstillede krav i problemformuleringen. 5.3 Software Reliability Metric Diskussionen om software kvalitets involverer to vigtige problemstillinger: Hvilke attributter er vigtige for arkitekturen? Hvordan måler man disse attributter? Det første aspekt stiller krav til at definere og anvende et kvalitets framwork og det næste kræver et veldefineret metric system til at måle attributternes kvalitet. For at måle Availability og Reliability har man udviklet flere metoder nogle af dem er beskrevet herunder: POFOD (Probability of Failure On Demand) Sandsynligheden for at systemet vil fejle når et service er ønsket RODOF (Rate of Occurrence Of Failure) Side 8 af 34

9 Et bud på frekvensen af system fejl, når et service ønskes MTTF (Mean Time To Failure) Den tid der vil gå indtil systemet fejler (ikke-reparerbar elementer, average [Halliburton]) MTBF (Mean Time Between Failure) Den tid der vil gå mellem to system fejl (reparerbar elementer, average [Halliburton]) AVAIL (availability) Sandsynligheden for at systemet er tilgængeligt i et givet tidspunket.[sommerville] Ifølge [Rosenberg] er alle ovenstående metoder baseret på Fault detection and removal aktivitet. Vil man have en forbedret måle system bør man at inddrage Fault prevention aktiviteten i sit metrik system. Denne metode er udviklet og anvendes af Software Assurance Technology Center (SATC) i NASA. Metoden fokuserer på en omfattende krav-specifikation og test-plan. Hun argumenterer at det altid er nemmere og billigere at finde fejlene i så tidlig fase i en udvikling proces (fault prevention) i forhold til et senere tidspunkt hvor produktet er i drift (fault detection and removal). Hun mener at det vil medføre en faktor 14 kost optimering. At anvende en metrik mekanisme for at måle reliability kræver et færdigt produkt sat i drift, hvor man kan opsamle data til statistik og måling. Denne mulighed er ikke tænkeligt i dette projektets rammer. Derfor har vi fravalgt det i projektet. 5.4 Fault tree Analyse Teknikken Fault Tree Analyse blev udviklet i Bell labrotarie i starten af 60 erne og siden da den er anvendt i vidt omfang til relaibility og safty analyser. Fault tree er en grafisk repræsentation af samspillet mellem en række lav niveau begivenheder (basic events) som kan få system til at ende i en uønsket tilstand (failure)[ FaultTree.org]. Denne metode anvendes især inden for sikkerheds område til bestemmelse af sandsynligheden for en sikkerhedsrisiko [Wiki]. Et fault tree er bygget op sådan at basic events ligger i bunden af træet. De er forbundet til en top event (hazard) via nogle logiske symboler kendt som gates [FaultTree.org]. Hazard (Top event) Basic event1 Basic event2 Figur 3 Fault tree Side 9 af 34

10 Basic events i bunden af grafen er typisk komponenter eller operator fejl. Nogle eksampler er: Pump fejl Temperatur føler fejl Ingen operatør respons Mens top events repræsenterer identificeret hazard eller system failure. Nogle eksamler er Total tab af produktion Tab af mission Miljø forurening Der er to forskellige tilgange til en fault tree. Den første er en induktive tilgang, hvor der udpeges basic events som kan tvinge systemet til en uønsket tilstand. Hvorimod i en deductive tilgang, tager man udgangspunkt i et uønsket system tilstand og analyserer sig frem til mulige årsager (basic events) [Sommerville]. En fault tree analyse involverer 5 processer: At definere uønskede events og studere dem At opnå system forståelse At konstruere et fault træ At evaluere fault træet At kontrollere de identificerede hazard Der er flere store spillere til at definere og standardisere Fault Tree Analyse, hvor iblandt Boeing, NASA og NRC (Nuclear Regulatory commission) kan nævnes. 5.5 Survivability Survivability er systemets evne til at udføre dens mission, til trods for attacks, failures og ulykker. [Ellison] beskriver 3 scenarioer hvori der kan opstå uheld. Attack Udefrakommende begivenhed (Intrusion, DOS) Failure Internal generated events (SW, HW, human errors, bad data) Accidents Externally generated events (Natural Disaster) Målet med survivability er at systemet skal kunne udføre dens mission selvom store dele af systemet er beskadiget eller ødelagt. Hvis man kigger på et system hvor man har væsenlige og mindre væsenlige services forventes der at de væsenlige services altid kan leveres selvom systemet er blevet kompromitteret. Et netværks system består at funktionelle krav, og survivability krav. Fællesmængden af disse krav udgør de væsentlige funktionelle services. [Ellison] Der findes 4 aspekter indenfor survivability. Disse strategier består af forskellige tiltag der tilsammen understøtter den valgte strategi: [Ellison] Resistance Encryption, diversity og voting etc. Recognition Redundency og monitoring etc. Recovery Fysisk informations redundency etc. Side 10 af 34

11 Adaption and Evolution Broadcast warning to other nodes og broadcast adaption strategi Når man skal bygge et survivable sytem indgår der forskellige andre kvalitets attributter som tilsammen gør systemet survivable. Kvalitets attributter som dependability, availability og performance etc. bliver ofte implementeret under udviklingsfasen, hvorimod survivability ofte tænkes igennem bagefter implementeringen fasen. Det er derfor vigtig at synliggøre hvilke arkitektoniske metoder der understøtter survivability som en system attribut. Når man har defineret de essentielle funktionalitetskrav hvor survivabily er vigitg kan man udarbejde en (ATA) Atribute tradeof Analysis for at se hvilke tradeof survivability har på andre kvalitets attributter såsom Availability og Performance. [Ellison] forholder sig mest til problematikken omkring unbound networksystems og trussels billedet udadtil. Mange af de taktikker vi har arbejdet med såsom availability indgår som strategier for at gøre et system mere survivable. Vores produkt kan kategoriset som del at et bounded network, og unbounded network da det både kan centralt administreres og har en snitflade til et unbounded network. Det kunne derfor være interessant at lave en ATA og dertil scenarioer for at se om og hvilke andre kvalitets attributter man går på kompromi med for at understøtte survivability attributter. Da dette projekt løber over en begrænset tidshorisont har valgt at fokusere mere på emner beskrevet i problemformuleringen. 5.6 Arkitektoniske prototyper Arkitektoniske prototyper består af en mængde eksekverbare programmer som udforsker i hvilket omfang en arkitektur opfylder et givet systems ønskede kvaliteter [Bardram]. I modsætning til traditionelle software prototyper som fokuserer på et udsnit af et systems funktionalitet, fokuserer arkitektoniske prototyper på de nonfunktionelle krav [Bardram] da en arkitektur i stort omfang er nonfunktionel af natur [Bass]. Arkitektoniske prototyper bruges til at udforske og lære hvilke design muligheder findes. Jævnført [Bass] s Architecture Business Cycle har Arkitektens erfaring stor indflydelse på hvilke design valg arkitekten træffer. God erfaring med en taktik kan gøre arkitekten tilbøjelig til at vælge denne taktik igen til andre projekter, selv om der måske findes andre mere passende valg. Flere designmuligheder kan udforskes på en hurtig og billig måde ved at afprøve alternative taktikker i arkitektoniske prototyper i et realistisk setup. Arkitektoniske prototyper bruges typisk til at addressere arkitektonisk risiko, f.eks. at finde den optimale balance mellem forskellige ønskelige men modstridende kvaliteter. Desuden hjælper arkitektoniske prototyper arkitekten i at kommunikere designvalg ud til resten af udviklingsteamet, som så kan bygge videre på de givne rammer [Bardram]. [Bardram] klassifiserer arkitektoniske prototyper som Exploratory og Experimental. Side 11 af 34

12 Exploratory bruges til at klarlægge krav til arkitekturen i samarbejde med interesenter og til at afprøve og diskutere alternative løsninger. Eksperimental derimod bruges til at afprøve specifikke løsningsforslag og via eksperimenter afgøre om disse overholder kvalitetskravene. Side 12 af 34

13 6 Analyse og resultater I dette afsnit beskriver vi det arbejde vi har udført for at besvare problemformuleringen med basis i den litteratur som er beskrevet i afsnit 5. Vi laver først en basal reference arkitektur, som ikke tager hensyn til specifikke kvalitetskrav. Derefter beskrives krav til systemet i form af kvalitetsattributscenarier og mulige fejlkilder analyseres og beskrives i en fault tree analyse. På baggrund af de beskrevne kvalitetskrav og fejlkilder udvælges et sæt taktikker som afprøves i arkitektoniske prototyper. Erfaringerne fra prototyperne resulterer i en arkitektur som sikrer en højere grad af availaility og reliability end reference arkitekturen. 6.1 Reference arkitektur I dette afsnit beskriver vi en basal arkitektur, som opfylder de funktionelle krav til systemet men hvor der ikke er gjort noget for at sikre specifikke kvalitetskrav. Vi beskriver arkitekturen fra tre viewpoints ligesom i [Christensen] Module view Som vist på Figur 4 består systemet af ét fakturerings modul, som har forbindelse til en concentrator og hver concentrator kan aflæse flere målere. <<Interface>> Fakturering 1 * <<Interface>> Concentrator 1 * <<Interface>> Meter Figur 4 Module view Component & Connector view På runtime kører de forskellige komponenter på flere fysiske lokationer og der er forbindelse mellem faktureringssystem, concentrator og målere via netværk som vist i Figur 5. :Fakturering b :Concentrator W-MBUS :Meter Figur 5 Component & connector view Målere opdaterer deres forbrug i en uendelig løkke og kan aflæses af en concentrator efter behov (Figur 6 og Figur 7). Side 13 af 34

14 :Meter Loop [while true] UpdateUsageStatistics Figur 6 Sekvensdiagram for måler :Concentrator :Meter Loop [for each meter] GetUsageStatistics UsageStatistics Figur 7 Sekvensdiagram for aflæsning af måler Concentrator pusher data som er blevet samlet op i en periode til faktureringssystemet på bestemte tidspunkter som illustreret i Figur 8. :Concentrator :Fakturering Loop [for each meter] ReportUsageStatistics Figur 8 Sekvensdiagram for datarapportering fra konsentrator Allocation view Afregningssystemet, concentrator og målere deployes til forskellige nodes. Vi ser her bort fra muligheden at en concentrator kan deployes til samme node som en måler. Side 14 af 34

15 Scenario Details :Applikationsserver ODBC/LAN Fakturering b :Databaseserver :ConcentratorBoks MSSQL Concentrator W-MBUS :Måler Meter Figur 9 Allokering af komponenter til nodes 6.2 Quality attribute scenarios Da availability er en vigitg kvalitet for vores system har vi udvalgt følgende scenarios der illustrerer availability scenarios. QAS specifiserer kvalitet i en bestemt bruger interaktion. Systemet skal hurtigt kunne hente data fra mange energi-enheder. Et sådan krav ville være acceptabelt tidlig i et udviklingsforløb. Når man når længere i forløbet og kravene bliver mere specificeret ville ovenstående krav være ubrugelig, da de ikke giver grundlag for at bedømme systemet. Kvalitets attributter skal derimod skrives i form af scenarier, såsom systemer skal kunne hente data fra 100 energi enheder på under 5 sekunder. Dette krav vil en arkitekt kunne bedømme og udarbejde kvalificeret arkitektur på baggrund af [Bass]. Følgende QAS er lavet for at evaluere og definere en brugerinteraktion, der skal være med til at sikre en høj softwarekvalitet ved hjælp af arkitektoniske taktikker. QAS 1: Omhandlende concentrators evne til at indsamle energi-målinger fra måler-punkter Relevant Quality Attributes: Availability Source: Concentrator (Internal) Stimulus: Måler kan ikke aflæses Artifact: Kommunikations modulet Environment: Normal operation Response: Concentrator skal logge fejlen. Hvis Concentrator ikke kan aflæse måleren tager et redundant concentrator over Response Measure: De målere som concentrator ikke kan aflæse bliver aflæst af en redundant concentrator, med maksimalt en times forsinkelse. Questions: Issues: Tabel 1 QAS for tab af forbindelse mellem en concentrator og måler Side 15 af 34

16 Scenario Details QAS 2 Omhandlende kommunikationsfejl. Relevant Quality Attributes: Reliability Source: System (Internal) Stimulus: Støj forårsager bit fejl i en kommunikations pakke. Artifact: Concentrator Environment: Normal operation Response: Concentrator udfører en CRC-128 check og detekterer om pakken er fejlramt. Response Measure: Sandsynligheden for at en pakke med bit fejl går igennem systemet ubemærket skal være max 2.9*10-37 %. Questions: Issues: Tabel 2 QAS for bitfejl i kommunikation Ud fra QAS og fault tree vil vi vurdere hvilke hazards der udgør den største trussel for concentratorens availability og reliability. Med dette billede kan vi designe en arkitektur som gerne skulle modstå disse hazards. Vi kan ikke nå at designe arkitekturer for alle QAS og fault tree grene, og vil derfor sammenligne de hazards de begge påpeger for derigennem at danne sig et nuanceret billede at availability taktikker for concentratoren. 6.3 Fault tree De tilstande som vi har identificeret som de mest kritiske og som kan få brugeren af systemet til at opfatte det som hverken pålideligt eller tilgængeligt er: Tab af data Misted forbindelse til netværket Med udgangspunkt i det har vi valgt at anvende en deduktiv fremgangsmåde i en fault tree analyse for at finde årsager, som kan tvinge systemet i en af disse to hazards. Appendix B: Fault Tree Analyse er en samling af hazards vi har analyseret ved at anvende fault tree teknikken. Her vil vi sætte fokus på en hazard som omhandler tab af målere i netværket Tab af målere Figur 10 er et fejl træ diagram, som viser årsagerne til at en måler mister kontakten til sin (master) concentrator. Det er selvfølgelig en ret uheldig tilstand som påvirker systemets availability i den forkert retning. Side 16 af 34

17 Figur 10 Basic events medvirkende til tab af måler hazard Tab af målere pga. operator fejl Operator issues: Operatøren kan komme til at fjerne en måler fra concentratorens måler liste ved en fejl. RF issues: kommunikationskvaliteten i en radio netværk er afhængig af mange faktorer som luft fugtighed, temperatur, refleksion, kollision og mm. Derfor kan kommunikationskvaliteten mellem netværks enhederne svinge meget og til tider falder det helt ud. Concentrator issues: En eller mange måler(e) kan gå tabt i systemet som følge af en defekt concentrator. Løsning: Denne problematik håndteres normalt ved indførelse af redundante komponenter (concentrator) i systemet. Redundant concentrator i netværket kan man umuligt komme udenom. Men man kan spare på antallet af concentratorerne ved at anvende andre mekanismer. F. eks. Kan en concentrator finde og huske flere forskellige veje (path) til hver måler. Det gør at en hel sub-net forbundet til concentrator via en router falder ikke ud, hvis den ene router går i stykker. En supplerende taktik vil være at kræve at hver måler skal være set og registreret af mindst 2 concentrator. Stopper den ene concentrator kan måleren altid hentes hjem via den anden concentrator. 6.4 Fault tree og scenarier Fault tree kan bruges tidlig i et udvikingsforløb, allerede på det tidspunkt man har en grundviden om sit system. Det samme gælder for QAS hvor man meget tidlig kan specifisere nogle scenarier for sit system som beskriver hvordan det skal agere alt efter systemets tilstand. fault tree er designet til at identificere kritiske hazards, og QAS fortæller hvordan systemet skal agere i bestemte situationer. Det er derfor oplagt at undersøge hvordan fault tree og QAS i fællesskab kan hjælpe til at gøre ens arkitektur mere robust. Samspillet mellem QAS og fault tree er ikke et stort emne blandt videnskabelige publikationer. Det er derfor interessant at undersøge hvordan de komplimenterer hinandens stærke og svage sider. Side 17 af 34

18 Scenario Details Fault tree beskriver hvilke kriterier der skal være opfyldt for at ende i en bestemt fejl-tiltand som er kritisk for systemet ved hjælp af træ strukturer hvor rodknuden er hazard jf fig. 10. QAS beskriver en bestemt brugerinteraktion eller system tilstand tilsvarende fault tree, og beskriver også et løsningforslag (responce). Den store forskel ligger i hvordan man måler ens løsningenforslag/responce hvilket skal fremgå når man laver et scenarie. Det er nemlig derpå man vurderer hvilken arkitektonisk taktik som er vigtig lige i denne situation. Situationen hvor en måler ikke længere kan aflevere sine resultater er meget kritisk for vores concentrator. Hvis man ser på fault tree over denne hazard ville fault recovery taktikken, redundancy, være oplagt som derfor er beskrevet som løsningforslag jf QAS for denne problemstilling foreslår også en redundant concentrator. Men der hvor QAS udmærker sig er hvordan løsningen måles, som fault tree ikke nødvendigvis fortæller noget om. I vores tilfælde forventes det at måler resultater hentes trods concentrator svigt, med maksimalt en times forsinkelse, hvilket betyder man er nød til at lave en arkitektur med en redundant concentrator som altid står og er klar til at tage over. Det er ikke acceptable at nogle teknikkerer først skal ud med en ny concentrator. Problemet med fault tree i dette scanarie kunne være en misforståelse af løsningenforslaget, hvor arkitekten kunne forledes til at tro en sparre concentrator ville være tilstrækkelig og bygge en arkitektur ud fra det. Havde man derimod lavet QAS ville arkitekten kunne designe systemet sådan at kunden ville få indfriet sine kvalitets krav til oppetid. Det er dog svært at få dækket alle mulige scenarier med QAS, da tiden det tager at dække sig helt ind ikke vil være acceptabelt i mange projekter. I mange situationer kan det også være tilstrækkelig at lave en overordnet QAS da arkitekturen vil kunne løse mange relaterede failures, som kan sidestilles med fault tree basis events. Man udarbejder derfor ikke scenarioer for hver basis events da man ser på hazard som helhed. Ovenstående betragtning af sammenspillet mellem QAS og fault tree, kan danne grundlag for en ny måde at lave foranalyse på. Med udgangpnkt i fault tree fig. 10 og QAS 6.2 Tabel 1 fælles for disse er at QAS dækker alle fault tree event, og derfor kan arkitekten lave en arkitektur som overholder krav til QAS responce messure og samtidig dække fault tree hazard. Dette kan også illustreres ved nendenståede udvidet QAS tabel som har fået en ekstra attribut (FT Hazard Covered) hvilket fortæller om pågældende scenario dækker en eksisterende fault tree hazard. Relevant Quality Attributes: Availability Source: Concentrator (Internal) Stimulus: Måler kan ikke aflæses Artifact: Kommunikations modulet Environment: Normal operation Response: Concentrator skal logge fejlen. Hvis concentrator ikke kan aflæse måleren tager et redundant concentrator over Response Measure: De måler som concentrator ikke kan aflæse bliver aflæst af en redundant concentrator, med maksimalt en times forsinkelse. FT Hazard Covered Loss of meter jf fig. 10 Questions: Issues: Dette scenario addresser fault tree fig. 10 mest kritiske tilstand (hazard) Tabel 3 Udvidet QAS, der inkluderer covered fault tree Side 18 af 34

19 Selve processen i at linke fault tree harzard og QAS vil i mange tilfælder komme helt naturligt. Det man skal være opmærksom på for at sige en QAS er dækkende for fault tree er om fault tree hazard kan sidestilles med QAS stimulus, og derved adresser den samme kritiske tilstand for systemet. Man kan også forstille sig QAS og fault tree basis events, hvis en af disse basis event menes af udgøre den største sandsynlighed for hazard. Derefter kan man så lave en specialiseret QAS for dette event. Hvis man samtidig dokumentere hele sin proces med hvilke fault tree events og QAS der høre sammen kan man tidlig danne et grundlag for en solid arkitektur med focus på fault avoidness. [Bass] En af målene med dette projekt var at vurdere om QAS og fault tree tilsammen kunne danne grobund for en robust arkitektur. Til dette har vi vurderet at QAS og fault tree står utrolig stærk forenet, idet QAS beskriver det ønskede funktionalitet, og fault tree specificere mulige fejl kilder for hazard. Hvis de to teknikker har fælles hazard, løser man begge med en samlet arkitektonisk taktik, og samtidig har man dokumentation på alle de fejlmuligheder fault tree basis event denne arkitektur adresser. 6.5 Arkitektoniske taktikker For at sikre man altid kan aflæse målere, har vi lavet en arkitektonisk taktik som bygger på redundante concentrator. Som nævnt tidligere er der mange miljømæssige årsager til at en concentrator kan miste sine målere, og derved ikke kan udføre sine jobs. Nedenstående illustration synliggør vores arkitektur. Meter RF link RF link Konc. 1 TCP/IP Konc. 2 Udveksler Job Information Figur 11 Fault tolerant arkitektur Som det fremgår af fig. 11 er en måler altid kendt af 2 concentratorer. En måler er dog altid på kun én concentrators masterliste dvs. at måleren under normale omstændigheder vil altid blive aflæst af denne concentrator. Måleren har kun til opgave at beregne energi-forbrug samt at fortælle den er tilstedet via RF. Af problemformuleringen fremgår det at vi vil afprøve taktikker for at opnå availibilty samt reliability. Denne udfordring har vi netop adresseret ved at lave en redundant arkitektur. Hvis concentrator 1. Jf. fig. 11 skulle ende i en tilstand som ikke kan rettes på runtime, eller mister sit radio link, kan concentrator 2 altid foretage det job som concentrator 1 skulle havde udført. Fault avoidness, detection og recovery er tre availability taktikker vi vil anvende i vores arkitektur for at opnå en højere grad af availability. Side 19 af 34

20 Fault avoidance: For at minimere fejl i runtime, har vi valgt at bruge et type stærkt programmerings sprog som C# hvor alt kode er managed. Ligeledes har vi brugt safe programming teknikker som exception handling for at sikre potentielle fejl situationer. Samtidig har vi lagt vægt på arkitektoniske mønstre som lav kobling og høj samhørighed. Disse tre fault avoidness taktikker er med til at gøre koden mere robust, og derved mere available. Fault detection: Indenfor fault detection er ping, echo, exception, herat beat og CRC nogle af de velkendte og standard metoder. Disse metoder anvendes mest for enten at sikre sig en fejlfri kommunikation eller holde øje med at de andre enheder er i live. I dette afsnit kigger vi på fault detection som overvågning af både concentrator og målerne. Overvågning af concentratorerne Anvendelse af ping/echo mekanismen mellem to concentrator optager dobbelt så meget båndbrede i forhold til heartbeat. For at minimere belastningen på netværket vælger vi heartbeat frem for ping/echo. Overvågning af målerne Til at holde øje med at en måler er stadigvæk funktionelt og kan levere sine service er Ping/echo et mere passende taktik. I stedet for at sende masser af heartbeats fra mange målere med tendens mod kaos og kollision, kan Ping/echo anvendes som et mere kontrolleret mekanisme. Ulempen er at Ping/echo involvere et request og reply, altså 2 pakker, hvilket betyder mere belastning af RF båndet. Men til gengæld kan man anvende systemets data request i stedet for ping og echoet vil være forbrugs data. Sådan undgår man faktisk spild af RF båndbredden forårsaget fault detection mekanismen. Fault recovery: Blandt availability taktikker vil Passive redundancy (warm restart) udmærke sig som en god kandidat i forhold til active redundancy (hot restart) eller spare. Vores system kan sagtens tåle service udfald i kortere periode. Hvis systemet mangler data fra et område kan det altid bestilles og hentes indenfor en rimelig tidsramme. Derfor er der ingen grund til at belaste både concentratorerne og netværkets dyr båndbrede med tunge tilstands synkroniseringer mellem concentratorerne. Derimod spare vil være en alt for langsom, besværlig og dyr operation, da det i praksis kræver mange mande timer i form af kunde koordination, transport og installation af den nye concentrator. Passiv redundans kan implementeres ved at lade arkitekturen understøtte en minimal synkronisering mellem concentrator 1 og 2. Dette kan udføres ved at concentrator 1 og 2 skaffer bekendtskab med hinandens job informationer. Denne synkronisering skal selvfølgelig være opdateret med jævne mellemrum, da en operatør kan have ændret i jobs, og dette selvfølgelig skal afspejles på den redundante concentrator. Ved at lade de to redundante concentrator kende hinanden job information via en indbyrdes synkronisering, giver mulighed for at hvis concentrator 1 ikke modtager svar på dens ping til måleren over en bestemt tid, kan den bede concentrator 2 til at rulle tilbage og udføre dens jobs i den tid den ikke kunne kontakte måleren. Dette er også en del af Adaption and Evolution som beskrevet under Survivability afsnittet. Side 20 af 34