Thermo Surveillance System TSS

Transkript

1 Teknisk Informationsteknologi Ingeniørhøjskolen Aarhus Projekt: TI-OOMI Dato: Thermo Surveillance System TSS GRUPPE Tommy Andreasen Anders Dyhrberg Mette Vestergaard au2227 TI-OOMI Objektorienteret Middleware 2. kvarter

2 Teknisk Informationsteknologi Ingeniørhøjskolen Aarhus Resumé Der er udviklet et heterogent distribueret system til overvågning og opsamling af temperatur og tryk i gæringstanke. Systemet består af en central server, der opsamler data fra et antal tilmeldte målestationer og gemmer disse målinger i en database. Disse data kan efterfølgende hentes ud af en række klienter, der bruger data til at fjernovervåge tilstanden i gæringstankene. Den centrale server og målestationerne er implementeret i C#, og kommunikationen i mellem dem foregår ved hjælp af.net Remoting. Klientprogrammet er implementeret i Java, og kommunikationen mellem denne og serveren foregår ved hjælp af CORBA med anvendelse af SUN ORB og MiddCor.Net. Databasen er udviklet med MS SQL. TI-OOMI Objektorienteret Middleware 2. kvarter

3 Indholdsfortegnelse Versionshistorie Version Dato Initialer Beskrivelser TA, AD, MV Synopsis + Use Case model TA, AD, MV Logisk klassediagram TA, AD, MV Teknisk klassemodel TA, AD, MV Test af SUN ORB og MiddCor.Net ORB TA, AD, MV Endeligt dokument INLEDNING Formål Læsevejledning Forkortelser og definitioner KRAVSPECIFIKATION Generel beskrivelse Systembeskrivelse Systemets funktioner Funktionelle krav Use Cases Anvendt Teknologi ANALYSE OG DESIGN Overvejelser Komponenterne i TSS Kommunikation mellem TRS TSSS SAP/PSP Model Logisk klassediagram Teknisk klassediagram Deploymentdiagram Kommunikationsmodel Persistens IMPLEMENTATION AF PROGRAMMET Valg af udviklingsværktøjer samt opsætning Installering af TSS systemet Installering af TRS Installering af TSSServer med tilhørende database Installering af SAP/PSP PROGRAMEKSEKVERING AF TSS SYSTEMET KONKLUSION...A 7. UNDERSKRIFTSBLAD...B 8. BILAG...C 8.1 Referencer...C 8.2 CD...C Side 2 af 19

4 INLEDNING 1.1 Formål Der er skal udvikles et distribueret system til overvågning og opsamling af temperatur og tryk i gæringstanke. Der er stillet følgende krav til projektet: OOA/OOD teknik med UML Middleware: CORBA og DCOM eller.net Remoting Heterogenitet Datalagring PC platform 1.2 Læsevejledning Kapitel 2: KRAVSPECIFIKATION Beskriver vha. Use Case teknikken de generelle krav, der gælder forudviklingen af TSSS systemet. Endvidere er der en oversigt over den teknologi, der skal anvendes. Kapitel 3: ANALYSE OG DESIGN Beskriver analyse og design. Endvidere gennemgås hvilke overvejelser, vi har gjort mht. udvikling af komponenterne og kommunikationen i mellem dem. Kapitel 4: TEST Beskriver Test Kapitel 5: ANVENDELSE AF PROGRAMMET Beskriver anvendelsen af programmet. Beskriver udviklingsværktøjet samt opsætning og installering af TSS systemet. Kapitel 6: KONKLUSSION Konklusion Kapitel 7: UNDERSKRIFTSBLAD Gruppemedlemmers underskrift Kapitel 8: BILAG Diverse bilag samt CD Side 3 af 19

5 1.3 Forkortelser og definitioner TRS - Temperature Reading Station Opsamler data fra tankene, således at TSSS kan forespørge om dem. TSS - Thermo Surveillance System Det samlede system bestående af TSSS, TRS ere og SAP/PSP TSSS - Thermo Surveillance System Server Indsamler temperatur og tryk fra alle registrerede TRS'ere og gemmer et sæt af data (TRS, temperatur, tryk, alarmtilstand og tidspunkt) i database. Serveren gemmer også rettigheder for administratorer og brugere. SAP - System Administration Program Bruges til administration af systemet. Det er her muligt at tilmelde/afmelde TRS'ere med navn, adresse og alarmniveau. Administrator kan ligeledes tilmelde/afmelde andre administratorer og brugere. PSP - PC Survey Program Viser temperatur og tryk for alle de registrerede TRS'er. Administrator Er en person, der har tilladelse til at administrere systemet vha. SAP Bruger Er en person, der kan overvåge de tilmeldte TRS'ere vha. PSP Side 4 af 19

6 2. KRAVSPECIFIKATION 2.1 Generel beskrivelse Systembeskrivelse Systemoversigt Der er skal udvikles et distribueret system (TSS) til overvågning og opsamling af temperatur og tryk i gæringstanke. Systemet skal bestå af en central server (TSSS), der opsamler data fra et antal tilmeldte målestationer (TRS) og gemmer disse målinger i en database. Temperatur- og trykdata vil blive simuleret i et lille program. Temperatur- og trykdata kan hentes ud af en række klienter, der bruger data til at fjernovervåge tilstanden i gæringstankene. Klienterne får ved login specifikke brugerrettigheder: Administrator får adgang til Systemadministrationsprogrammet (SAP) SAP bruges til administration af systemet. Det er her muligt at tilmelde/afmelde TRS'ere med navn, adresse og alarmniveau. Administrator kan ligeledes tilmelde/afmelde andre administratorer og brugere. Bruger får adgang til PC Survey Programmet (PSP). PSP viser temperatur og tryk for alle de registrerede TRS'er. Nedenstående figur viser, hvorledes TSS er opbygget Tryk Temperatur TRS SAP Administrator Tryk Temperatur TSSS Database TRS PSP Bruger Tryk Temperatur TRS Figur 2-1: TSS systemoversigt Side 5 af 19

7 Aktør-kontekst diagrammer Figur 2-2: Aktør-kontekst diagrammer Aktørbeskrivelser Aktør navn Administrator Type [primær/sekundær] En person rolle, der er en primær aktør i forhold til systemet Beskrivelse En administrator er en person der kan til/afmelde målestationer, administratorer og brugere. Anvender SAP klientprogrammet Antal samtidige aktører 1..* Aktør navn Bruger Type [primær/sekundær] En person rolle, der er en primær aktør i forhold til systemet Beskrivelse En bruger er en person, der har adgang til at overvåge temperatur- og trykdata fra de tilkoblede TRS målestationer. Anvender PSP klientprogrammet Antal samtidige aktører 1..* Aktør navn Temperatur sensor Type [primær/sekundær] En hw rolle, der er en primær aktør i forhold til systemet Beskrivelse En temperatur sensor måler den aktuelle temperatur i en TRS Antal samtidige aktører 1 Aktør navn Tryk sensor Type [primær/sekundær] En hw rolle, der er en primær aktør i forhold til systemet Beskrivelse Entryk sensor måler den aktuelle tryk i en TRS Antal samtidige aktører Side 6 af 19

8 2.1.2 Systemets funktioner Det følgende diagram viser systemets funktioner udtrykt som Use Cases Use Case diagram Figur 2-3: Use Case diagram for TSS systemet Side 7 af 19

9 2.1.3 Funktionelle krav Use Cases Use Case nr. 1: Login Mål: Denne Use Case gør en person i stand til at logge ind som henholdvis bruger eller administrator; dette afgøres ved hjælp af indtastet brugernavn og adgangskode. Administrator får adgang til SAP programmet, mens en bruger får adgang til PSP programmet Use Case nr. 2: Vis temperatur- og tryk data. Mål: Denne Use Case gør brugeren i stand til at få vist de tidligere temperatur og tryk i ønsket tidsinterval fra en ønsket TRS Use Case nr. 3: Send alarm Mål: Denne Use Case gør TSS systemet i stand til at sende en alarmmeddelelse til samtlige brugertyper Use Case nr. 4: Læs aktuel temperatur og tryk Mål: Denne Use Case gør en bruger i stand til at overvåge en valgt TRS Use Case nr. 5: Gem data Mål: Denne Use Case gør TSS systemet i stand til at gemme data fra de tilmeldte TRS er i en database Use Case nr. 6: Administrer alarmniveau Mål: Denne Use Case gør en administrator i stand til at sætte alarmniveau for temperatur og tryk for en TRS Use Case nr. 7: Administrer bruger og brugerrettigheder Mål: Denne Use Case gør en administrator i stand til at til/afmelde en person som en administrator eller bruger Use Case nr. 8: Administrer TRS Mål: Denne Use Case gør en administrator i stand til at til/afmelde en TRS Side 8 af 19

10 2.2 Anvendt Teknologi For at opnå heterogenitet udvikles TSSS og TRS i C#, mens SAP og PSP udvikles i Java. SAP og PSP udvikles som et program, hvor der ved login gives adgang til henholdsvis SAPeller PSP funktionalitet alt efter tildelt brugerrettighed. Der anvendes.net Remoting som kommunikation mellem TSS og TRS, mens der anvendes CORBA mellem TSSS og SAP/PSP med anvendelse af SUN ORB og MiddCor.Net Figur 2-4: Anvendt teknologi Side 9 af 19

11 3. ANALYSE OG DESIGN 3.1 Overvejelser Komponenterne i TSS Målestation: TRS Dette er programmet for målestationerne, der opsamler data for temperatur og tryk. For at undgå at skulle være afhængig af PICO TH-03 Therminstor Converter med RS-232, har vi selv implementeret et lille program, der automatisk genererer nogle tilfældige realistiske data. Vi har valgt at implementere TRS i C# Server: TSSS Dette er programmet for serverdelen i TSS med database. Vi har valgt at implementere TSSS i C#. Vi har valgt at implementere database i MSSql, da flere i gruppen havde kendskab til pruduktet og det virkede som en god og effektiv måde at persistere de nødvendige data på. MSSql ville også sikre udvklingen mod funktionalitetsbegrænsninger, da den måde at persistere data på er gennemtestet og i stand til at håndtere langt mere end dette projekt ville kunne gøre brug af Klientprogram: SAP/PSP Dette er programmet henholdsvis for brugere og administratorer. Vi har valgt at implementere det som et program, hvor der ved login gives adgang til forskellig funktionaltiet alt efter brugerrettighed. Vi har valgt at implementere SAP/PSP i Java, fordi det er et sprog, der er platformsuafhængigt således, at det vil være mulighed for at denne applikation nemt kan bringes til at køre på andre platforme end WIN Side 10 af 19

12 3.1.2 Kommunikation mellem TRS TSSS SAP/PSP Kommunikation mellem TRS og TSSS Der er valgt at anvende.net Remoting, da man ifølge Microsoft skal anvende dette frem for DCOM, som var det andet valg af teknologi til denne opgave. Derudover er.net Remoting valgt, da vi syntes, at det ville være mest interessant at arbejde med en nyere teknologi Kommunikation mellem TSSS og SAP/PSP Vi har valgt at anvende SUN s Java ORB, da denne er tæt integreret med Java programmeringssproget. Der findes andre ORB er, der understøtter Java, som f.eks. JacORB. MiddCor.NET valgte vi fordi, vi havde besluttet os for at ville bruge C# til udviklingen af serveren. Derudover så denne ORB ud til at være interresant at arbejde med. En anden fordel ved MiddCor.NET er, at der fra samme firma også findes en ORB, der kan bruges på mindre.net platforme, såsom PocketPC og Windows CE.NET. 3.2 Model Logisk klassediagram Nedenstående figur viser det logiske klassediagram for TSS systemet. Figur 3-1: Logisk klassediagram Side 11 af 19

13 3.2.2 Teknisk klassediagram Nedenstående diagrammer er for overblikkets skyld er reduceret til de mest essentielle funktioner for at skabe overblikket i stedet for at forstyrre forståelsen ved unødvendige detaljer. creates SAP creates +main() SAPForm +buadminusers_actionperformed() +buadmintrs_actionperformed() +bugetcurrentdata_actionperformed() +bulogout_actionperformed() creates ORBThread +run() TRSAdminDlg LoginDlg UserAdminDlg GetHistDataDlg +buaddtrs_actionperformed() +budeletetrs_actionperformed() +buclose_actionperformed() +buok-actionperformed() +bucancel() +buadduser_actionperformed() +budeleteuser_actionperformed() +buclose_actionperformed() +buok_actionperformed() +bucancel() uses uses uses uses DataProviderImpl UsersImpl LogDataImpl TimeStampImpl +getdataproviderid() +getipaddress() +getname() +getdescription() +getenabled() +getdataprovidertype() +getalerttempll() +getalerttempul() +getalertpressurell() +getalertpressureul() +getupdatetime() +set...() +getinitials() +getpassword() +getfirstname() +getlastname() +getusertype() +getenabled() +set...() +getdataprovider() +getlogtimeserver() +getlogtimerclient() +getpressure() +gettemperature() Figur 3-2: Teknisk klassediagram for SAP/PSP Side 12 af 19

14 Figur 3: Teknisk klassediagram for TRS Deploymentdiagram Figur 4: Teknisk klassediagram for TSSS Figur 3-5: Deploymentdiagram Side 13 af 19

15 3.2.4 Kommunikationsmodel Kommunikation mellem TRS og TSSS Her vises, hvorledes kommunikationen foregår mellem TRS og TSSS ved hjælp af.net Remoting Figur 6: Kommunikationen mellem TRS og TSSS Ovenstående funktionalitet er opnået ved, at der er designet et Interface ClientInterface som både TRS og TSSS har reference til og dermed kender. Dette muliggør at TRS kan oprette en TcpClient på en fast port (10999) og give adgang til en klasse, der implementerer interfacet ClientInterface. Serveren TSSS kan så forbinde sig til Client en på dens IP og den aftalte port og derved få direkte adgang til de i interfacet implementerede funktioner. Et eksempel på dette, kan ses i ovenstående figur Kommunikation mellem TSSS og SAP/PSP Her vises, hvorledes kommunikationen foregår mellem TSSS og SAP/PSP ved hjælp af CORBA Figur 7 Kommunikation mellem SAP/PSP og TSSS Som det fremgår af ovenstående figur foregår kommunikation mellem klienten (SAP/PSP) og serveren (TSS Server) ved, at klienten har en reference til CORBA objektet, som den bruger til at kalde funktionen med. Nu tager ORB en sig af at finde serveren og få marshallet kaldet og sendt det til serveren. Serverens ORB unmarshaller kaldet og sørger for at kalde den rigtige funktion, som så returnerer et resultat til klienten Side 14 af 19

16 SUN ORB contra MiddCor.Net ORB I den følgende tabel sammenlignes et udsnit af funktionaliteten i de to ORB er vi har anvendt i systemet. MiddCor.NET SUN Java ORB IIOP / GIOP IIOP / GIOP Naming Service Naming Service Value Types and Any Value Types and Any IDL Compiler (C#) IDL Compiler (JAVA) Portable Object Adapter (POA) Portable Object Adapter (POA) Event Service support - Multi threaded ORB Multi threaded ORB I forløbet af projektet har vi lavet en hastighedssammenligning af de to ORB er. Testen forløb ved, at vi udførte to CORBA-kald mellem de to ORB er. IDL en for de to funktionskald ser således ud: module SpeedTestApp { interface Test { char getchar(in char tegn); string getstring(in long id); }; }; De to funktioner blev hver kaldt gange. Dette blev gentaget 10 gange, og det er gennemsnittet af disse tider, der er at finde i tabellen herunder: Sun -> Sun MiddCor -> MiddCor Sun -> MiddCor Funktion 1 14,476 s 20,299 s 19,853 s Funktion 2 17,499 s 22,309 s 21,439 s Side 15 af 19

17 3.2.5 Persistens Figur 8: TSSS database Databasens opbygning er holdt relativt simpel, da det set fra databasesiden er en ret begrænset opgave, der skal løses. Tabellernes indbyrdes forhold er begrænset til en bruger, der har en relation til en bruger type. Derved kan det kontrolleres, om den enkelte bruger er admin, bruger, eller f.eks. gæst, og flere ønskelige typer kan tilføjes løbende. Ligeledes er der lavet en tabel til at gemme dataproviders i; - i systemets nuværende stand vil det i alle tilfælde kun være TRS stationer som gemmes, og dette sikres ved at sætte dataprovidertypen til 1. Ideen med at have en dataprovidertype er, at der med tiden kunne komme flere andre typer dataproviders, som skulle håndteres anderledes af systemet, men som skulle overholde samme interface. Derved er løsning gjort ret skalerbart ved en lille ekstra tilføjelse. Dette kunne f.eks være en powerreadingstation PRS eller lignende. logdata er en af de vigtigste tabeller i databasen; - den indeholder de til alle tider indmeldte data fra de forskellige dataproviders. Den er lavet således, at en dataprovider kun kan få gemt sine data en gang på det samme tidspunkt. Således kan der ikke opstå tvetydige informationer Side 16 af 19

18 4. IMPLEMENTATION AF PROGRAMMET 4.1 Valg af udviklingsværktøjer samt opsætning Sprog Java NET 1.1 C# Corba ORB er SUN ORB MiddCor.Net ORB Udviklings Miljø [IDE] Eclipse Visual studio Installering af TSS systemet Installering af TRS Der skal ikke installeres noget for at eksekvere en TRS udover, at der skal være installeret.net Framework 1.1 på computeren. Dernæst skal man sikre sig, at notere IP adressen på den computer, hvor man starter TRS samt sikre sig, at port er åben for trafik ind og ud til internettet. Så klarer TRS og TSSS resten Installering af TSSServer med tilhørende database Databasen er det første, der skal installeres. Dette kræver en MSSQL 2000 installation. Den skal installeres lokalt på den computer, hvor men har tænkt sig at kører TSSServeren. Der skal oprettes en ny database på denne computer, som kaldes TSS. På CD-rom en ligger der en backup af en database med samme navn. Denne kan importeres direkte ind i TSS via enterprise manageren, der kommer med MSSql TSSServeren skal ikke installeres, den skal bare startes, den er dog underlagt de samme krav som der er stillet til TRS. Herefter vil den selv regulere resten Installering af SAP/PSP SAP er modsat de andre kodet i Java, og den skal heller ikke installeres, men kræver naturligvis at en java virtual maskine (1.4.2) er installeret på den computer, hvorfra man ønsker at den skal kører. Første login Der logges ind som administrator med følgende login: User: admin Password: admin Side 17 af 19

19 5. PROGRAMEKSEKVERING AF TSS SYSTEMET Nedenstående figur viser et screenshot for en TRS. Figur 9: Screenshot for TRS I venstre side vises vha. grafer henholdsvis temperatur, tryk og væskeniveau. Ved alarm bliver baggrunden på den pågældende graf rød. Når alarmen ophører vises grafen på normal vis igen. I højre vises en animeret gæringstank med den aktuelle temperatur, tryk og væskeniveau. Endvidere vises opdateringsintervallet til serveren Side 18 af 19

20 Nedenstående figur viser et screenshot for TSSServer, hvor der er tilmeldt tre forskellige TRS er: TRS Zero, TRS One og TRS Two: Figur 10: Screenshot for TSSServer TSSServer har ved tilmeldingen af en TRS, gemt TRS ens IP-adresse, portnummer, opdateringsinterval og beskrivelse. Disse data vises altid. Som det ses på figuren har TSSServeren opnået forbindelse til TRS Zero, og denne kan nu overvåges; - der vises en animeret gæringstank samt de aktuelle temperatur, tryk og væskestand, der opdateres med det givne tidsinterval. TSSServeren har ikke opnået forbindelse til TRS One og TRS Two endnu. Derfor vises der kun TRS ens IP-adresse, portnummer, opdateringsinterval og beskrivelse. I tilfælde af, at TSSServeren mister forbindelsen til en TRS, vises det blot som TRS One og TRS Two. Endvidere føres det ind i log denne kan ses under fanebladet Log. Når forbindelsen igen er oprettet, vil der atter vises det aninmerede gæringstank samt aktuelle data fra TRS en Side 19 af 19

21 6. KONKLUSION Vi skulle i projektet afprøve flere forskellige teknologier på forskellige platforme. Det var svært indledningsvis at skabe det overblik, der skulle til for at overholde alle de stillede krav til en samlet løsning. Der skulle vælges mindst to programmeringssprog; - hvor det blev besluttet at bruge Java og C#. Der skulle anvendes CORBA og enten.net Remoting eller DCOM, hvor det blev besluttet at bruge.net Remoting, da dette er MS seneste skud på stammen, og DCOM formodentligt er på vej ud af markedet. Hvor længe.net Remoting så holder, vides ikke, da det virker som om, at MS konsekvent udvikler på WebServies og umiddelbart promoverer dette langt mere. Der har dermed i dette projektforløb været kontakt med utroligt mange forskellige teknologier. Nogen mere eksistensberettiget end andre. Et af de noget sværere valg, var omkring valget af ORB erne. Der var et langt større marked, end vi umiddelbart havde forventet. Da ingen af os havde nogen tidligere erfaring med brug af ORB er, var vi nødsaget til at læse en del artikler og læne os op af andres erfaringer. Problemet var jo, at det viste sig, at mange af de tilbud der lå i open source, ikke var helt færdige eller også var performance utrolig dårligt, og andre var bare så ustabile at de var for upålidelige. Men beslutningen faldt på det sikre valg SUN ORB og mht. C# siden virkede MiddCor.Net ORB som det mest fornuftige bud. Disse blev brugt til implementering af projektet, og det har egentligt forløbet nogenlunde smertefrit. Performance er fornuftig, og vi har ikke oplevet nogen problemer med ustabilitet Side A

22 7. UNDERSKRIFTSBLAD Tommy Andreasen ( ) Anders Dyhrberg ( ) Mette Vestergaard (au2227) Side B

23 8. BILAG 8.1 Referencer Nedenstående liste angiver de brugte referencer. MiddCor.NET SUN ORB Java J2SE CD CD en indeholder følgende: readme.txt Gruppens navn, projektnavn og abstract over opgaven \doc rapport \src komplet kildekode \bin binær kode + readme for afvikling af kode \res ressourcer, ORB-kode, kode til hastighedssammenligning af de to ORB er, licenser Side C