Availability og reliability i softwarearkitektur

Størrelse: px
Starte visningen fra side:

Download "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

ATiSA H3: Beer Web Store

ATiSA H3: Beer Web Store ATiSA H3: Beer Web Store Gruppe: Hotel Christer Vindberg, Anders Kabell Kristensen, Bo Sunesen og Anders Viskum 20011271, 20041248, 20041083 og 20043103 {chrisv10, dalko, sunesen, anden} @ cs.au.dk december

Læs mere

Kommunikationsprotokoller Summit06 worksession. Lisa Wells Datalogisk Institut Aarhus Universitet

Kommunikationsprotokoller Summit06 worksession. Lisa Wells Datalogisk Institut Aarhus Universitet Kommunikationsprotokoller Summit06 worksession Datalogisk Institut Aarhus Universitet Plan Kort introduktion til protokoller Protokoller i ISIS Katrinebjerg projekter Internet-baseret trådløs telefoni

Læs mere

Comendo Remote Backup. Service Level Agreement

Comendo Remote Backup. Service Level Agreement Comendo Remote Backup Service Level Agreement Side 2 af 7 Indholdsfortegnelse Service Level Agreement... 1 Indholdsfortegnelse... 2 Introduktion... 3 Comendo Remote Backup ansvar og forpligtelser... 3

Læs mere

Basal TCP/IP fejlfinding

Basal TCP/IP fejlfinding Basal TCP/IP fejlfinding Dette notat beskriver en række enkle metoder til fejlfinding på TCP/IP problemer. Metoderne er baseret på kommandoer, som er en fast bestanddel af Windows. Notatet er opbygget

Læs mere

Optimering af fraværsregistrering

Optimering af fraværsregistrering Journal Optimering af fraværsregistrering Eksamensprojekt i Programmering C, klasse 3.4, 2011 AFLEVERET 09-05-2014 Indhold Abstract... Fejl! Bogmærke er ikke defineret. Problemformulering... 2 Produktet...

Læs mere

Interferens. Afstand (d interferer ) til det interfererende System. Afstand (d) mellem sender og modtager

Interferens. Afstand (d interferer ) til det interfererende System. Afstand (d) mellem sender og modtager Interferens Interferens er et alvorligt problem for short range enheder, men der er muligheder for at teste resistensen over for interferensen. I denne artikel beskrives nogle af de konsekvenser og scenarier,

Læs mere

Automatisk Vandingssystem

Automatisk Vandingssystem Automatisk Vandingssystem Projektdokumentation Aarhus Universitet Gruppe 6-3. Semester - F15 vejleder: Michael Alrøe dato: 28-05-2015 Lærke Isabella Nørregård Hansen - 201205713 - IKT Kasper Sejer Kristensen

Læs mere

Svendeprøve Projekt Tyveri alarm

Svendeprøve Projekt Tyveri alarm Svendeprøve Projekt Tyveri alarm Påbegyndt.: 8/2-1999 Afleveret.: 4/3-1999 Projektet er lavet af.: Kasper Kirkeby Brian Andersen Thomas Bojer Nielsen Søren Vang Jørgensen Indholds fortegnelse 1. INDLEDNING...3

Læs mere

Rejsekort A/S idekonkurence Glemt check ud

Rejsekort A/S idekonkurence Glemt check ud Rejsekort A/S idekonkurence Glemt check ud 9. marts 2015 1 Indhold 1 Introduktion 4 1.1 Problembeskrivelse........................ 4 1.2 Rapportens opbygning...................... 4 2 Ordliste 5 3 Løsning

Læs mere

Fjernaflæsning af målere

Fjernaflæsning af målere Status og visioner vedr. fjernaflæsning/- kommunikation med målere Bjarne Lund Jensen Produktchef, kommunikation Fjernaflæsning Teknologisk 2009/BLJ 1 Indhold Fjernaflæsning i 2001 Kommunikationsmuligheder

Læs mere

BAS 914S/929S Datablad

BAS 914S/929S Datablad BAS 914S/929S BA Systems Petershvilevej 1 DK-3200 Helsinge http://www.basystems.dk BAS 914S/929S tilhører en familie af programmerbare kontrollere der er målrettet til mindre samt medium størrelse installationer.

Læs mere

Agenda. Muligheder for anvendelse. Komponenter. Features. Restore muligheder. DR og TSM integration. Repository. Demo. Spørgsmål

Agenda. Muligheder for anvendelse. Komponenter. Features. Restore muligheder. DR og TSM integration. Repository. Demo. Spørgsmål Agenda Muligheder for anvendelse Komponenter Features Restore muligheder DR og TSM integration Repository Demo Spørgsmål Muligheder for anvendelse Data Center dmsave/lokal TSM Remote Office Application

Læs mere

SOSIGW. - Driftsvejledning for SOSIGW 1.0. Indeks

SOSIGW. - Driftsvejledning for SOSIGW 1.0. Indeks SOSIGW - Driftsvejledning for SOSIGW 1.0 Indeks Indeks... 1 Revisionshistorik... 2 Introduktion... 2 Kontrol af korrekt driftstilstand... 2 Ændring af statisk konfiguration... 2 Logfil... 2 Backup... 3

Læs mere

Virtualisering, Cloud Computing og OPC UA i automationssammenhæng - hvad er de reelle use cases?

Virtualisering, Cloud Computing og OPC UA i automationssammenhæng - hvad er de reelle use cases? Virtualisering, Cloud Computing og OPC UA i automationssammenhæng - hvad er de reelle use cases? Lars Peter Hansen Produktchef for Industrial Communication Lars-peter.hansen@siemens.com T.: +45 4477 4827

Læs mere

Security as a Service hvorfor, hvornår og hvordan. Gorm Mandsberg, gma@dubex.dk Aarhus, 13.06.2013

Security as a Service hvorfor, hvornår og hvordan. Gorm Mandsberg, gma@dubex.dk Aarhus, 13.06.2013 Security as a Service hvorfor, hvornår og hvordan Gorm Mandsberg, gma@dubex.dk Aarhus, 13.06.2013 SecaaS hvorfor, hvornår og hvordan hvad Hvorfor.. Hvornår.. Hvordan.. Disclamer: Dubex er MSSP og leverer

Læs mere

3.g elevernes tidsplan for eksamensforløbet i AT 2015

3.g elevernes tidsplan for eksamensforløbet i AT 2015 Mandag d. 26.1.15 i 4. modul Mandag d. 2.2.15 i 1. og 2. modul 3.g elevernes tidsplan for eksamensforløbet i AT 2015 AT emnet offentliggøres kl.13.30. Klasserne er fordelt 4 steder se fordeling i Lectio:

Læs mere

Application Management Service

Application Management Service Application Management Service I dette Whitepaper vil vi beskrive nogle af vores erfaringer med Application Management. De fleste virksomheder har på et tidspunkt lavet, eller fået lavet, en mindre applikation,

Læs mere

Oversigts billedet: Statistik siden:

Oversigts billedet: Statistik siden: 1 Tilslutning: Tilslut et nætværks kabel (medfølger ikke) fra serverens ethernet port til din router. Forbind derefter bus kablet til styringen, brun ledning til kl. 29, hvid ledning til kl. 30 Forbind

Læs mere

PROfessiOnel RisikOstyRing med RamRisk

PROfessiOnel RisikOstyRing med RamRisk 4 Professionel risikostyring med ramrisk www.ramrisk.dk Risikostyring med RamRisk Rettidig håndtering af risici og muligheder er afgørende for enhver organisation og for succesfuld gennemførelse af ethvert

Læs mere

Programmering af CS7050 TCP/IP modul

Programmering af CS7050 TCP/IP modul Comfort CSx75 Programmering af CS7050 TCP/IP modul Introduktion CS7050 TCP-IP modulet er en fuldt integreret enhed, som tilbyder nye funktioner til Comfort seriens centraler i form af TCP/IP Ethernet forbindelse

Læs mere

ZTH-.. som MP-Bus tester

ZTH-.. som MP-Bus tester ZTH-VAV og ZTH-GEN juster- og diagnoseværktøj som MP-Bus tester. Tilslutning i tavle eller samledåse Tester Kort beskrivelse MP-Bus tester er ikke velegnet til kabel-test. Anvendelse Tilslutning og forsyningsspænding

Læs mere

Programmering C Eksamensprojekt. Lavet af Suayb Köse & Nikolaj Egholk Jakobsen

Programmering C Eksamensprojekt. Lavet af Suayb Köse & Nikolaj Egholk Jakobsen Programmering C Eksamensprojekt Lavet af Suayb Köse & Nikolaj Egholk Jakobsen Indledning Analyse Læring er en svær størrelse. Der er hele tiden fokus fra politikerne på, hvordan de danske skoleelever kan

Læs mere

Basis Abonnement 28 dage @ 2 fps (Billede-Serie) Gyldig fra 01. Maj 2011 Kamera overvågning - Axis Kameraer and NAS tilsluttet gennem Internettet.

Basis Abonnement 28 dage @ 2 fps (Billede-Serie) Gyldig fra 01. Maj 2011 Kamera overvågning - Axis Kameraer and NAS tilsluttet gennem Internettet. Basis Abonnement 28 dage @ 2 fps (Billede-Serie) Gyldig fra 01. Maj 2011 Kamera overvågning - Axis Kameraer and NAS tilsluttet gennem Internettet. Funktion Kapacitet Kamera Ekstra Kamera Live. Max antal

Læs mere

Velkommen. Program: Oplæg om emnet baseret på Best Practice (ITIL) Refleksion

Velkommen. Program: Oplæg om emnet baseret på Best Practice (ITIL) Refleksion Driftskontrakter Hvordan sikrer man sig, at man får en ordentlig driftskontrakt? Hvad skal man være opmærksom på, og hvornår begynder man egentlig at tænke den ind? Velkommen Program: Oplæg om emnet baseret

Læs mere

Service Level Agreement

Service Level Agreement Service Level Agreement For DanDomain server og infrastrukturservices Indhold 1. Generelt... 2 2. Definitioner... 3 3. Teknisk support... 4 4. Hotline... 4 5. Ændringsanmodninger... 4 6. Vedligeholdelse

Læs mere

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet.

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet. MOX og APOS2 Forord Dette dokument er en del af APOS version 2 manualerne. APOS version 2 (APOS2 herefter) er et organisation, klassifikation og personale system baseret på Sag & Dokument standarderne.

Læs mere

BAS 920. Datablad. BA Systems Petershvilevej 1 DK-3200 Helsinge http://www.basystems.dk

BAS 920. Datablad. BA Systems Petershvilevej 1 DK-3200 Helsinge http://www.basystems.dk BAS 920 BA Systems Petershvilevej 1 DK-3200 Helsinge http://www.basystems.dk BAS 920 tilhører en familie af frit programmerbare kontrollere designet til at være skalerbare fra helt små til meget store

Læs mere

KOMPONENT BESKRIVELSE

KOMPONENT BESKRIVELSE Beskrivelse : S12-20-8A tegningsnummer 630014 Program som styrer 5 individuelle trykforløb på samme tid. Kan køre med intern tryk-reservoir. Kommunikerer med PC-program 714014 Dato Sign. Beskrivelse af

Læs mere

Vejledning Installation af Easy Route Mobile programpakke på håndterminal

Vejledning Installation af Easy Route Mobile programpakke på håndterminal Vejledning Installation af Easy Route Mobile programpakke på håndterminal Udarbejdet af: Flonidan DC A/S Islandsvej 29, DK-8700 Horsens Telefon: +45 75 61 88 88 Fax: +45 75 62 60 88 www.flonidan.dk Installation

Læs mere

Bring lys over driften af belysningen

Bring lys over driften af belysningen Bring lys over driften af belysningen CityTouch LightPoint Asset Management system for belysning CityTouch LightPoint / Asset Management 3 Velkommen til den nye intelligens inden for belysning. Professionel

Læs mere

1 Ordliste 2. 2 Indledning 3 2.1 Problemstillinger... 3 2.2 Problemformulering... 4 2.3 Problemafgrænsning... 4 2.4 Mål med projektet...

1 Ordliste 2. 2 Indledning 3 2.1 Problemstillinger... 3 2.2 Problemformulering... 4 2.3 Problemafgrænsning... 4 2.4 Mål med projektet... Indhold 1 Ordliste 2 2 Indledning 3 2.1 Problemstillinger.................................. 3 2.2 Problemformulering................................ 4 2.3 Problemafgrænsning................................

Læs mere

Grow. With the Leader. IBM Storwize v7000. v/lars Kok

Grow. With the Leader. IBM Storwize v7000. v/lars Kok Grow. With the Leader. IBM Storwize v7000 v/lars Kok Information Explosion Zettabytes Informationen i danske virksomheder fordobles hver 18-24 måneder Exabytes Budget til Storage & daministration stiger

Læs mere

XProtect-klienter Tilgå din overvågning

XProtect-klienter Tilgå din overvågning XProtect-klienter Tilgå din overvågning Tre måder at se videoovervågning på For at skabe nem adgang til videoovervågning tilbyder Milestone tre fleksible brugergrænseflader: XProtect Smart Client, XProtect

Læs mere

Pervasive computing i hjemmet et sikkerhedsproblem?

Pervasive computing i hjemmet et sikkerhedsproblem? Pervasive computing i hjemmet et sikkerhedsproblem? Jakob Illeborg Pagter Alexandra Instituttet A/S Oplæg En af de konkrete visioner for pervasive computing er det intelligente hjem. Dette begreb dækker

Læs mere

Sikkerhedspolitik Version 4.0506 d. 6. maj 2014

Sikkerhedspolitik Version 4.0506 d. 6. maj 2014 Nærværende dokument beskriver de sikkerhedsforanstaltninger, som leverandøren har opstillet til den interne fysiske sikkerhed, datasikkerhed, logisk sikkerhed og sikkerhed i forbindelse med netværk, firewall

Læs mere

Kampagnetilbud. Spar op til 50% Læg frisk LAN på

Kampagnetilbud. Spar op til 50% Læg frisk LAN på Kampagnetilbud Læg frisk LAN på Spar op til 50% Beskyt dit LAN effektivt med UTM Førende ethernet switches og fi rewalls til stærkt nedsatte priser Køb samlet eller hver for sig Kampagnetilbud Hold dit

Læs mere

Dit netværk er vores højeste prioritet!

Dit netværk er vores højeste prioritet! Dit netværk er vores højeste prioritet! Hvor sikker er du på dit netværk? Netværkssikkerhed er ingen selvfølge. Det har mange virksomheder måttet konstatere den seneste tid. Vi har været vidne til gentagne

Læs mere

SERVICE LEVEL AGREEMENT for levering af In & Outbound Datacenters IT-Ydelser

SERVICE LEVEL AGREEMENT for levering af In & Outbound Datacenters IT-Ydelser SERVICE LEVEL AGREEMENT for levering af In & Outbound Datacenters IT-Ydelser iodc (In & Outbound Datacenter) Hvidovrevej 80D 2610 Rødovre CVR 35963634 ( IODC ) Version 1.0 1 1. Forudsætninger... 3 2. Ansvar

Læs mere

PID2000 Archive Service

PID2000 Archive Service PROLON CONTROL SYSTEMS Herstedvesterstræde 56 DK-2620 Albertslund Danmark Tlf.: (+45) 43620625 Fax: (+45) 43623125 PID2000 Archive Service Bruger vejledning Juni 2002 Denne manual beskriver brugen af softwaren

Læs mere

Sikkerhedsanbefaling. Forholdsregler ved ophør af serviceopdateringer til Windows XP Embedded

Sikkerhedsanbefaling. Forholdsregler ved ophør af serviceopdateringer til Windows XP Embedded Sikkerhedsanbefaling Forholdsregler ved ophør af serviceopdateringer til Windows XP Embedded Juli 2014 Indledning Microsoft har annonceret, at selskabet den 31. december 2016 frigiver den sidste serviceopdatering

Læs mere

S E R V I C E L E V E L A G R E E M E N T for. Netgroups levering af IT-ydelser m.v.

S E R V I C E L E V E L A G R E E M E N T for. Netgroups levering af IT-ydelser m.v. S E R V I C E L E V E L A G R E E M E N T for Netgroups levering af IT-ydelser m.v. Netgroup A/S Store Kongensgade 40 H 1264 København K CVR-nr.: 26 09 35 03 ( Netgroup ) Version 4.4 1. Forudsætninger...

Læs mere

SW6 SAI. Services 1: (Fil) service admin torsdag 7/4 05

SW6 SAI. Services 1: (Fil) service admin torsdag 7/4 05 SW6 SAI Services 1: (Fil) service admin torsdag 7/4 05 agenda Backup / Restore SW pakke management Windows Installer RPM mm Patch management Linux / Windows Backup og Restore I hvilke situationer er der

Læs mere

DE BEAR TECHNOLOGY. o Processer, metoder & værktøjer. e-mail: info@dbtechnology.dk WWW.DBTECHNOLOGY.DK

DE BEAR TECHNOLOGY. o Processer, metoder & værktøjer. e-mail: info@dbtechnology.dk WWW.DBTECHNOLOGY.DK Mission Critical o Projekt Information management o Processer, metoder & værktøjer. Side 1 of 11 Projekt information Projekt information management inkluderer alle de processer, som er nødvendige for at

Læs mere

Enes Kücükavci Roskilde Tekniske Gymnasium 20 05 2010 Mathias Turac Informationsteknolog B Vejleder: Karl Bjranasson Programmering C

Enes Kücükavci Roskilde Tekniske Gymnasium 20 05 2010 Mathias Turac Informationsteknolog B Vejleder: Karl Bjranasson Programmering C Indhold Indledning(Enes)... 2 Problemstilling (Enes)... 2 Teori (Enes)... 2 Løsningsforslag (Enes)... 4 RFID relæet (Mathias)... 6 Krav (Enes og Mathias)... 8 Målgruppen (Mathias)... 8 Rekvirent... 8 Implementering(Mathias)...

Læs mere

Har det en værdi og hvordan kommer du i gang?

Har det en værdi og hvordan kommer du i gang? Virtualisering? Har det en værdi og hvordan kommer du i gang? Torben Vig Nelausen Produktchef Windows Server, Microsoft og Claus Petersen Senior Partner Technology Specialist, Microsoft Agenda Hvad er

Læs mere

Undervisningen, H3. Hovedforløb 3. Total antal Lektioner. Operativsystemer 3. Netværk 3. Projekt. Områdefag: Netværk 3 36 18 54

Undervisningen, H3. Hovedforløb 3. Total antal Lektioner. Operativsystemer 3. Netværk 3. Projekt. Områdefag: Netværk 3 36 18 54 Undervisningen, H3 Hovedforløb 3 5 ugers varighed Netværk 3 Operativsystemer 3 Projekt Total antal Lektioner Områdefag: Netværk 3 36 18 54 Bundne specialefag: Operativsystemer 3 72 18 90 Fejlfinding 36

Læs mere

SERVICEMÅL OG BOD. Christian Sandbeck, Bid Excellence Executive

SERVICEMÅL OG BOD. Christian Sandbeck, Bid Excellence Executive SERVICEMÅL OG BOD Christian Sandbeck, Bid Excellence Executive MIN BAGGRUND Uddannelse : cand.merc.jur 2 3 DISKUSSIONSSPØRGSMÅL 1 Hvorfor har vi Servicemål? 4 ITIL S SVAR: SLA ER SKAL UNDERSTØTTE KUNDENS

Læs mere

Mini SRP. Afkøling. Klasse 2.4. Navn: Jacob Pihlkjær Hjortshøj, Jonatan Geysner Hvidberg og Kevin Høst Husted

Mini SRP. Afkøling. Klasse 2.4. Navn: Jacob Pihlkjær Hjortshøj, Jonatan Geysner Hvidberg og Kevin Høst Husted Mini SRP Afkøling Klasse 2.4 Navn: Jacob Pihlkjær Lærere: Jørn Christian Bendtsen og Karl G Bjarnason Roskilde Tekniske Gymnasium SO Matematik A og Informations teknologi B Dato 31/3/2014 Forord Under

Læs mere

Installation og Drift. Aplanner for Windows Systemer Version 8.15

Installation og Drift. Aplanner for Windows Systemer Version 8.15 Installation og Drift Aplanner for Windows Systemer Version 8.15 Aplanner for Windows løsninger Tekniske forudsætninger Krav vedr. SQL Server SQL Server: SQL Server 2008 Express, SQL Server 2008 R2 eller

Læs mere

NemID DataHub adgang. morten@signaturgruppen.dk & jakob@signaturgruppen.dk. Doc. 25538-12, sag 10/3365

NemID DataHub adgang. morten@signaturgruppen.dk & jakob@signaturgruppen.dk. Doc. 25538-12, sag 10/3365 NemID DataHub adgang morten@signaturgruppen.dk & jakob@signaturgruppen.dk Agenda Funktionaliteten og brugeroplevelsen Arkitekturen og komponenterne bag NemID og digital signatur Datahub token Pause Udvikling

Læs mere

Tekniske krav til spiludbydere i forbindelse med opnåelse af tilladelse til at udbyde online spil i Danmark

Tekniske krav til spiludbydere i forbindelse med opnåelse af tilladelse til at udbyde online spil i Danmark Tekniske krav til spiludbydere i forbindelse med opnåelse af tilladelse til at udbyde online spil i Danmark Version 1.10 Versionshistorik Version Dato Opsummerende beskrivelse af ændringer 1.00 2010-10-5

Læs mere

Toshiba EasyGuard i brug:

Toshiba EasyGuard i brug: Toshiba EasyGuard i brug Toshiba EasyGuard i brug: tecra a5 Få mobil produktivitet i helt nye dimensioner. Toshiba EasyGuard indeholder en række funktioner, der hjælper mobile erhvervskunder med at opfylde

Læs mere

PS102: Den menneskelige faktor og patientsikkerhed

PS102: Den menneskelige faktor og patientsikkerhed IHI Open School www.ihi.org/patientsikkerhed PS102: Den menneskelige faktor og patientsikkerhed (1 time) Dette modul er en introduktion til emnet "menneskelige faktorer": Hvordan indarbejdes viden om menneskelig

Læs mere

Projekt - Visual Basic for Applications N på stribe

Projekt - Visual Basic for Applications N på stribe Projekt - Visual Basic for Applications N på stribe Mikkel Kaas og Troels Henriksen - 03x 3. november 2005 1 Introduktion Spillet tager udgangspunkt i det gamle kendte 4 på stribe, dog med den ændring,

Læs mere

2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING

2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING 2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING Baggrund Udgangspunktet er projekt 2, dvs. en blog om cupcakes, hvor målgruppe, afsender og modtager allerede er defineret. Du bliver nu bedt om at udvikle et

Læs mere

SSSystems.local. Netværk. Sikkerhed. Webserver

SSSystems.local. Netværk. Sikkerhed. Webserver SSSystems.local Netværk Vi har valgt at bygge vores netværk på en måde der sikre at trafik fra DMZ en ikke kan komme ned til vores LAN. Både ved hjælp af firewall regler og NAT. Men for at sikre at vi

Læs mere

Agenda. Typiske udfordringer. Begreber omkring recovery. Forretningens krav. Metoder/muligheder. Recovery med TSM. Nye teknologier

Agenda. Typiske udfordringer. Begreber omkring recovery. Forretningens krav. Metoder/muligheder. Recovery med TSM. Nye teknologier Agenda Typiske udfordringer Begreber omkring recovery Forretningens krav Metoder/muligheder Recovery med TSM Nye teknologier Afrunding - spørgsmål Typiske udfordringer Ingen SLA fra forretningen på systemer

Læs mere

Hvad du søgte efter Identiteten på det websted, du besøgte umiddelbart før vores websted (henvisende websted).

Hvad du søgte efter Identiteten på det websted, du besøgte umiddelbart før vores websted (henvisende websted). Brugervilkår og andre gode ting, som du bør vide for at være sikker online. Sikkerhed er alles ansvar En del af IKEA ånden er "jeg gør min del, du gør din del, og sammen gør vi en masse." Dette gælder

Læs mere

Freeware for PC security

Freeware for PC security Freeware for PC security Indledning: For en privat person kan det være svært at finde ud af, hvad der er godt for at kunne beskytte sin computer. Denne rapport vil prøve at dække nogle af de programmer,

Læs mere

Hovedopgave Master i informationsteknologi linjen i softwarekonstruktion

Hovedopgave Master i informationsteknologi linjen i softwarekonstruktion Hovedopgave Master i informationsteknologi linjen i softwarekonstruktion DLI Admin: Evaluering af performance- og availabilitykvalitet med arkitekturprototyper Michael Kaare Christensen Institut for Datalogi,

Læs mere

Security Center Et overblik

Security Center Et overblik 01.03.2012 Security Center Et overblik mailfence/spamfence... 2! Generelt om spamfence... 2! Generelt om mailfence... 2! Gennemse e-mails... 2! Overblik... 2! Statistik... 3! E-mail rapport... 3! Indstillinger...

Læs mere

PROFI BRUGER manual Til daglig betjening af systemet

PROFI BRUGER manual Til daglig betjening af systemet PROFI BRUGER manual Til daglig betjening af systemet Indhold: 1 Lysdioder og symboler...3 2 Betjening af systemet...5 2.1 Tilkobling...5 2.2 Frakobling...5 2.3 Overfaldsalarm...6 2.4 Alarmstop...6 2.5

Læs mere

Databasesystemer, forår 2005 IT Universitetet i København. Forelæsning 3: E-R modellering. 17. februar 2005. Forelæser: Rasmus Pagh

Databasesystemer, forår 2005 IT Universitetet i København. Forelæsning 3: E-R modellering. 17. februar 2005. Forelæser: Rasmus Pagh Databasesystemer, forår 2005 IT Universitetet i København Forelæsning 3: E-R modellering 17. februar 2005 Forelæser: Rasmus Pagh Forelæsningen i dag Datamodellering hvad, hvornår, hvorfor og hvordan? Business

Læs mere

HOSTINGPLANER DDB CMS HOS DBC

HOSTINGPLANER DDB CMS HOS DBC HOSTINGPLANER DDB CMS HOS DBC Indhold Hostingplaner DDB CMS hos DBC... 1 1 Hostingplaner... 3 2 Definitioner... 4 2.1 Miljøer... 4 2.2 Support... 4 2.2.1 DDB CMS - 1. line support... 4 2.2.2 DDB CMS -

Læs mere

Tilbudsmateriale: Ny Storage løsning. 1. Introduktion. 2. Løsningsoverblik. 2. januar 2012

Tilbudsmateriale: Ny Storage løsning. 1. Introduktion. 2. Løsningsoverblik. 2. januar 2012 2. januar 2012 Tilbudsmateriale: Ny Storage løsning. 1. Introduktion Dette tilbudsmateriale er annonceret på Syddjurs Kommunes hjemmeside iht. Bekendtgørelsen af lov om indhentning af tilbud på visse offentlige

Læs mere

Tidsregistrering. Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4. Informationsteknologi B. Roskilde Tekniske Gymnasium 25-11-2014

Tidsregistrering. Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4. Informationsteknologi B. Roskilde Tekniske Gymnasium 25-11-2014 2014 Tidsregistrering Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4 Informationsteknologi B Roskilde Tekniske Gymnasium 25-11-2014 Indholdsfortegnelse 1 Indledning... 3 2 User stories... 3 3

Læs mere

Dm071 / Dm072 - Obligatorisk projekt 3: Design af model

Dm071 / Dm072 - Obligatorisk projekt 3: Design af model Dm071 / Dm072 - Obligatorisk projekt 3: Design af model Fag: Projektet omhandler emner fra fagene Software Design og Software Konstruktion. Formål: Formålet med projektet er at give dig mulighed for sammen

Læs mere

VLAN, Trunk & VTP. VLAN: Virtual Local Area Network

VLAN, Trunk & VTP. VLAN: Virtual Local Area Network (C) EC MID 2005 VLAN, runk & VP 2003 EC MID, Heh 1 VLAN: Virtual Local Area Network VLAN s er en logisk opdeling af enheder eller brugere VLAN s fungerer på OI lag 2 ( og 3 ) Opbygget af witche ( og Routere

Læs mere

Arduinostyret klimaanlæg Afsluttende projekt programmering C

Arduinostyret klimaanlæg Afsluttende projekt programmering C Arduinostyret klimaanlæg Afsluttende projekt programmering C Udarbejdet af: Mathias R W Sørensen, klasse 3.4 Udleverings-dato: 02-03-2012 Afleverings-dato: 11-05-2012 Programmeringvejleder: Karl G. Bjarnason

Læs mere

Miniprojekt2011. Formålet er at lære og indlære god objektorienteret programudvikling og programmering med Java, samt undervejs at opfylde studiekrav.

Miniprojekt2011. Formålet er at lære og indlære god objektorienteret programudvikling og programmering med Java, samt undervejs at opfylde studiekrav. Miniprojekt2011 Projektbeskrivelse Der skal fremstilles en lille java application på PC, hvor brugeren kan foretage interaktioner med en simpel database på disken via et grafisk brugerinterface. Formålet

Læs mere

MULTIMEDIEDESIGNER 1. ÅRS PRØVE

MULTIMEDIEDESIGNER 1. ÅRS PRØVE MULTIMEDIEDESIGNER 1. ÅRS PRØVE Eksamensprojekt, 2. semester, forår 2010 TEMA: E-HANDEL Erhvervsakademiet København Nord Udleveret mandag d. 3. maj 2010 Afleveres i 4 eksemplarer senest d. 28. maj kl.

Læs mere

IPv6 sameksistens med IPv4. af Laurent Flindt Muller & Jakob Pedersen

IPv6 sameksistens med IPv4. af Laurent Flindt Muller & Jakob Pedersen IPv6 sameksistens med IPv4 af Laurent Flindt Muller & Jakob Pedersen Gennemgangsplan: Network Address Translation Protocol Translation (NAT-PT) - Motivation - IPv4 NAT - NAT-PT - Stateless IP/ICMP Translation

Læs mere

OS2 Opgavefordeler. Løsningsbeskrivelse Version 2. Udarbejdet af Miracle A/S Simon Møgelvang Bang smb@miracle.dk

OS2 Opgavefordeler. Løsningsbeskrivelse Version 2. Udarbejdet af Miracle A/S Simon Møgelvang Bang smb@miracle.dk OS2 Opgavefordeler Løsningsbeskrivelse Version 2 Udarbejdet af Miracle A/S Simon Møgelvang Bang smb@miracle.dk 15/2/2015 Løsningsbeskrivelse for OS2 Opgavefordeler 1. Introduktion... 3 2. Kontekst... 3

Læs mere

Call Recorder Apresa. Apresa Call Recording

Call Recorder Apresa. Apresa Call Recording Apresa Call Recording Hvorfor optage samtaler? De optagede samtaler giver en værdifuld indsigt i eksempelvis: Medarbejdernes evne til at kommunikere positivt med kunden Medarbejdernes fokus på aftalte

Læs mere

Få styr på vejbelysningen

Få styr på vejbelysningen Få styr på vejbelysningen CityTouch LightWave Remote Lighting Management CityTouch LightWave / Intelligent lysstyring 3 Velkommen til den nye offentlige belysning. I dag er vejbelysning statiske enheder,

Læs mere

Betjeningsvejledning til Håndterminal og AnyQuest Host

Betjeningsvejledning til Håndterminal og AnyQuest Host Betjeningsvejledning til Håndterminal og AnyQuest Host INDHOLDSFORTEGNELSE: 1 Indledning... 2 2 Generelt for Håndterminalen... 3 2.1 Justering af Dato og Tid.... 3 3 Aflæsning... 6 3.1 Opstart... 6 3.1.1

Læs mere

Indledning. Søren Mønsted: Visionsfilm som projektmål 24. november 2004. Side 1

Indledning. Søren Mønsted: Visionsfilm som projektmål 24. november 2004. Side 1 Indledning Alle projekter har et mål. Hvad enten det drejer sig om et personligt projekt om at holde op med at ryge, projektet med at bygge en bro eller projektet med at arrangere en havefest for hele

Læs mere

Skriftlig opgave. Designtanker i database-nære systemer

Skriftlig opgave. Designtanker i database-nære systemer Skriftlig opgave til eksamen for faget»databaser«designtanker i database-nære systemer Martin Ancher Holm Juni 2010 1 Intro Denne skriftlige opgave indeholder kort de daglige tanker jeg har omkring design

Læs mere

Forår 2012 - Firewalls

Forår 2012 - Firewalls Syddansk Universitet DM830 - Netværkssikkerhed Imada - Institut for matematik og datalogi Forår 2012 - Firewalls Forfatter: Daniel Fentz Johansen Alexei Mihalchuk Underviser: Prof. Joan Boyar Indhold 1

Læs mere

OMKnet trådløs. Overblik. Gode ting ved trådløs. Dårlige ting ved trådløs 3/12/2012

OMKnet trådløs. Overblik. Gode ting ved trådløs. Dårlige ting ved trådløs 3/12/2012 OMKnet trådløs Dette dokument er udarbejdet ud fra egen viden, informationssøgning og testning på kollegiet. En længere og større testning og undersøgelse vil være nødvendig før en præcis pris og endelig

Læs mere

100% adgangskontrol med FlexAir

100% adgangskontrol med FlexAir 100% adgangskontrol med FlexAir 100% ADGANGSKONTROL 100% LET SIKKERT ØKONOMISK FlexAir Enkelt, fleksibelt og sikkert Med FlexAir adgangskontrolsystem fra Scantron træffer du altid det rigtige valg. Systemet

Læs mere

Funktion Spændvidde Nøjagtighed Luftfugtighed 0,0 til 100 % RF ± 3,0 % RF (40-60 %) ± 5,0 % RF (0-20 % og 80-100 %)

Funktion Spændvidde Nøjagtighed Luftfugtighed 0,0 til 100 % RF ± 3,0 % RF (40-60 %) ± 5,0 % RF (0-20 % og 80-100 %) Brugsanvisning Datalogger Model RHT10 Dataloggeren måler og gemmer op til 16.000 luftfugt- og temperaturmålinger fra 0-100 % RF og i temperaturområdet fra -40 til 70 ºC. Målefrekvens, alarm og start indstilles

Læs mere

Profort A/S. Profort A/S. Dansk ingeniørfirma 12 år på markedet Dansk udviklet og produceret

Profort A/S. Profort A/S. Dansk ingeniørfirma 12 år på markedet Dansk udviklet og produceret Profort A/S Trådført alarm Duplex 948 4 udgange 8+2 indgange Duplex 312 1 udgang 1+1 indgange 1 Infrarød AUX Trådløs alarm Duplex Industri 4+1 udgange 4+4 indgange 60 trådløse - display Duplex 988 8 udgange

Læs mere

Energy Operation skræddersyet hosted løsning til energioptimering. Jens Ellevang Energi Management Konsulent

Energy Operation skræddersyet hosted løsning til energioptimering. Jens Ellevang Energi Management Konsulent Energy Operation skræddersyet hosted løsning til energioptimering Jens Ellevang Energi Management Konsulent Emne Schneider Electric Danmark A/S - Name Date 2 Fra energidata til energi management Har du

Læs mere

Radio Frequency Identification. Jonas Nobel, Nikolaj Sørensen og Tobias Petersen

Radio Frequency Identification. Jonas Nobel, Nikolaj Sørensen og Tobias Petersen Radio Frequency Identification Jonas Nobel, Nikolaj Sørensen og Tobias Petersen Hvad er RFID I starten af 70'erne blevet stregkoden opfundet til at gøre det lettere at handle. Stregkoden kunne huske et

Læs mere

EG Brandsoft Varmestyring med fugtovervågning, der er integreret med Brandsoftkalendersystemet stor varmemæssig besparelse og godt for miljøet

EG Brandsoft Varmestyring med fugtovervågning, der er integreret med Brandsoftkalendersystemet stor varmemæssig besparelse og godt for miljøet EG Brandsoft Varmestyring med fugtovervågning, der er integreret med Brandsoftkalendersystemet stor varmemæssig besparelse og godt for miljøet Varmestyringsmodulet, der kontrolleres fra EG Brandsoft kalenderen,

Læs mere

Enkelt Nemt Effektivt Skalérbart

Enkelt Nemt Effektivt Skalérbart Enkelt Nemt Effektivt Skalérbart Overvåg hele din IT infrastruktur med ét værktøj Som IT ansvarlig er din infrastruktur lig med dit image over for interne som eksterne kunder. Din mulighed for at reagere

Læs mere

Lean Construction-DK s. Guide til bedre planlægning med Last Planner System

Lean Construction-DK s. Guide til bedre planlægning med Last Planner System Lean Construction-DK s Guide til bedre planlægning med Last Planner System Introduktion Last Planner System er et værktøj i Lean Construction udviklet specielt til byggeriet og med hensyn til byggeriets

Læs mere

PDC Helpdesk Brugervejledning

PDC Helpdesk Brugervejledning PDC Helpdesk Brugervejledning PDC Helpdesk November 2013 Indhold 1 Introduktion... 3 2 Brug af browser eller e-mails... 3 3 Log på PDC Helpdesk... 4 4 Oversigts side for sager... 5 4.1 Oversigt over eksisterende

Læs mere

Call Recorder Apresa. Apresa Airport Voice Logger

Call Recorder Apresa. Apresa Airport Voice Logger Apresa Airport Voice Logger APRESA Airport Voice Recording APRESA Airport er et Voice Recording system til SIP, VoIP, digitale og analoge linier. Baseret de nyeste tekniske udviklinger, tilbyder APRESA

Læs mere

Applikations Virtualisering. Anders Keis Hansen Anders.keis.hansen@atea.dk

Applikations Virtualisering. Anders Keis Hansen Anders.keis.hansen@atea.dk Applikations Virtualisering Anders Keis Hansen Anders.keis.hansen@atea.dk Hvem er jeg Anders Keis Hansen Arbejder i Ateas konsulent afdeling Baggrund som System administrator, IT Arkitekt primært med fokus

Læs mere

KIH Database. Systemdokumentation for KIH Databasen. 1. maj 2013. Side 1 af 13

KIH Database. Systemdokumentation for KIH Databasen. 1. maj 2013. Side 1 af 13 KIH Database Systemdokumentation for KIH Databasen 1. maj 2013 Side 1 af 13 Indholdsfortegnelse Indholdsfortegnelse... 2 Indledning... 3 Systemoverblik... 3 KIH Database applikationsserver... 5 Forudsætninger

Læs mere

MODERNISERINGSSTYRELSEN ØSLDV WINDOWS SERVICE DOKUMENTATION, INSTALLATION OG KONFIGURERING AF ØSLDV/RAY WINDOWSSERVICE

MODERNISERINGSSTYRELSEN ØSLDV WINDOWS SERVICE DOKUMENTATION, INSTALLATION OG KONFIGURERING AF ØSLDV/RAY WINDOWSSERVICE Indhold Ændringshistorik... 2 Formål... 2 Om programmet... 2 Systemkrav... 2 Installation... 3 Event Log... 5 Installationsprogrammets skærmbillede... 6 Konfigurering af xml-opsætningsfil... 7 Beskrivelse

Læs mere

Projekt: VAX NemHandel 4.0

Projekt: VAX NemHandel 4.0 Ejer: mysupply ApS Projekt: VAX NemHandel 4.0 Emne: Dette dokument beskriver de tekniske specifikationer for VAX NemHandel 4.0 samt krav til miljøet, herunder hardware og software, hvori VAX NemHandel

Læs mere

Start af nyt schematic projekt i Quartus II

Start af nyt schematic projekt i Quartus II Start af nyt schematic projekt i Quartus II Det følgende er ikke fremstillet som en brugsanvisning der gennemgår alle de muligheder der er omkring oprettelse af et Schematic projekt i Quartus II men kun

Læs mere

Cyber sikkerhed Process IT Cyber sikkerhed og risiko analyse

Cyber sikkerhed Process IT Cyber sikkerhed og risiko analyse Cyber sikkerhed Process IT Cyber sikkerhed og risiko analyse Hvorfor IT sikkerhed Hvordan fik Cyber sikkerhed management opmærksomhed Risikoanalyse af ProcessIT i samarbejde med Administrativ IT Overvej

Læs mere

Duplex 312 FJERNAKTIVERING, OVERVÅGNING OG STYRING Brugermanual Varenr. 009012

Duplex 312 FJERNAKTIVERING, OVERVÅGNING OG STYRING Brugermanual Varenr. 009012 Brugermanual, Duplex 312, Side 1 Duplex 312 FJERNAKTIVERING, OVERVÅGNING OG STYRING Brugermanual Varenr. 009012 Sådan virker Duplex 312 Funktionsoversigt Brugermanual, Duplex 312, Side 2 GSM styring og

Læs mere

Vejledning til Mboard

Vejledning til Mboard Vejledning til Mboard Mobiltelefonen er uden overdrivelse den mest udbredte og fremadstormende teknologi. De fleste telefoner kan i dag håndtere mail, video, musik, radio, GPS og gå på internettet. - og

Læs mere

Informationssikkerhed Version 2.0 29.09.10

Informationssikkerhed Version 2.0 29.09.10 Informationssikkerhed Version 2.0 29.09.10 Retningslinjer for retablering af systemer og data (Ændringer i forhold til tidligere version er markeret med Understregning) Disse retningslinjer beskriver de

Læs mere

APPLIKATIONSARKITEKTUR ERP INFRASTRUKTUR. EG Copyright

APPLIKATIONSARKITEKTUR ERP INFRASTRUKTUR. EG Copyright APPLIKATIONSARKITEKTUR ERP INFRASTRUKTUR EG Copyright Infrastruktur er mere end nogle servere... Den Mentale Infrastruktur Den Fysiske Infrastruktur Den Mentale Infrastruktur Vi vil jo gerne have vores

Læs mere