KRAVSPESIFIKASJON I INTRODUKSJON 1.1 BAKGRUNN Systemet skal operere som en vital del av et kunstprosjekt. Kunstprosjektet er initsiert av Andre S. Marandon, som er kunstenerisk ansvarlig. prosjektet søker støtte fra ulike kunstrelaterte organisasjoner og næringsliv. Prosjektet drives som et ideelt foretak uten ambisjoner om økonomisk profitt. 1.2 KORT OM KRAV TIL SYSTEMET - skal være driftssikkert med klare varslingsrutiner dersom problemer skulle oppstå. Det ferdige systemet skal være lett å operere. Systemet er todelt med en styrende og opererende modul med fast lokalitet, og en modul som transporteres som skal ha minimaleikke skal ha krav til brukeren i det hele tatt. Systemet henter data fra DNMI etter en avtale som begrenser den tilgjengelige datamengden til mlingen tilsvarende et halvt aar. Det elgges derfor vesentlig vekt paa at en henter ut data kun mens publikum har tilgang til den mobile enheten. Kostnader: Delprosjektet skal ikke overstige kr 20 000,- ink mva, vedliehold og oppl¾ring av operat¿r. 1.3 KORT OM SYSTEMETS OMGIVELSER Kort om systemets omgivelser Systemet bestr av to fysiske enheter a) Fast komponenet som innhenter, prosessuerer og videresender data (i tilegg har den en kontroll og alarmfunksjon) Modulen vil befinne seg i vanlige kontoromgivelser med jevn temperatur og luftfuktighet. b) Flyttbar komponent. Denne modulen vil tidvis bli transportert i en lukket container, tidvis v¾re lagret og innenfor andre tidsperioder v¾re i operativ funksjon med publikum tilstede i containeren. Milj¿et for systemet i denne modulen vil,under operativ funksjon, v¾re sv¾rt skiftende med svingende lufttemperatur og luftfuktighet. Naar systemet ikke er operativt vil ogsaa vibrasjoner under transport,krenging og andre plasserings og vektmessige variasjoner oppstaa. 1.4 DOKUMENTETS STRUKTUR 1.5 DEFINISJONER Aluminiumscontainer: Helisolert aluminiumscontainer, tidligere anvendt av Norsk Luftfartsverk. Laasbar d¿r - stort frifelt i den ene veggflaten. Maal: H : 430cm x B: 250 cm x D: 250 cm. DNMI: Det norske Meteriologiske institutt. Fast komponent: datamskin med kommunikasjonstilknytning til telenettet. Komponenten inhenter, prosessuerer data fra DNMI. Komponenten videreformidler allarmer fra den mobile komponenten til 3 mobiltelefoner. Komponenten styrer stenging og opning for publikum av den mobile komponenten. Mobil komponent: Diritalt styrbar enhet plassert i aluminiumscontainer. 1.6 REFERANSER II BRUKER BESKRIVELSER 2.1 OMGIVELSER Fast komponent skal v¾re lett aa opperere, v¾re driftsikker, og ha programerbar flesibilitet som er lett aa opperere fra den brukeren som styrer og overvaaker prosjektet naar det er i drift. Den digitale enheten har tilkombling til vanlig nettspenning, kommunikasjonsdeln tilknyttet denne har tilknytning til telenettet og til nettspenning. Det er montert enkelt overspenningsv¾rn. Systemet skal kommuniserer med DNMI og den mobile komponenten. Mobil komponent skal v¾re lett aa operere, v¾re ekstremt driftsikkert, og ha klare alarmfunksjoner om noe gaar galt. De som skal opperere denne enheten er i f¿rste rekke de som tar imot containeren, som kun skal laase opp containeren, fj¾rne transportsikringer, inspisere hardware og koble til str¿m. I neste haand er publikum sluttbruker - de skal ikke operere systemet, kun v¾re passive motagere. Komponenten skal v¾re tilkoblet nettspenning og ha en GSM enhet for kommunikasjon med mobilnettet og derved den faste enheten. Modulrele: - settes i en kontainer - program som styrer rele - tar imot signal fra hovedmodul - egen strøm tilførsel - tilknytting til rele, som styrer ulike mekaniske innrettninger - kommunikasjons standard - IP, RS232 og relespesifikasjon 2.2 SYSTEMETS BRUKERE Operat¿r er Andre S Marandon. Han har marginal kunnskap og maa l¾res opp i bruken av systemet. Dette vil si at han maa kunne v¾re i stand til aa programere inn aapningstider og utstillingsperioder paa den fates komponenten. Han maa ogsaa kunne rette opp enklere alarmmellinger, og vite hvordan en skal kunne rette opp eventuelle feil paa den mobile enheten. Vedlihehold av systemet skal A. S. M. l¿res opp til. De mer kompliserte felil med tilhprende vedlikehold overlates til x Sluttbruker er, slik jeg ser det de ansvarlige paa stedet. De skal kun koble til str¿m aa gj¿re containeren klar til publikum, og ellers ha en mobiltelefon somvil ringe den ansvarshavende paa stedet i tilfellet ureglemetert bruk (d¿ren staar aapen utenom aapningstiden). - observere helt passivt - operatør - skal bare tilkople og slå på - ingen vedlikehold 2.3 FUNKSJON Der er 3 hovedkomponenteri den digitale stryingen. 1) B¿lgeh¿yden paa ekkofiskfeltet varierer fra min: A til maks: B. Dette gir en output paa syset i den mobile komponenten (i form av lys) paa min: 0W og maks: 20W. 2) Vindstyrken paa .....fjellet varierer fra min: C til maks: D. Dette gir en oustput paa (for hastighet paa en vifte) min: 0v til maks 230v. 3) Sj¿temperaturern aa .....fyr varierer fra min: E til maks: F. Dette gir en output paa (for styring av vanntemperatur i en mindre beholder ved hjelp av en vannkj¿ler) samme antall grader (ekvivalent). Videre er der 2 funkjsoner for fysisk stenging av containerens d¿r. 1) Output i form av xW for stenging og aapning av d¿r. 2) Input i form av d¿rf¿ler Alarmfunkson 1) Alarmfunksjon via fast enhet mot 1 mobiltelefon (tekstmeldinger til operat¿r) for feil paa den diritale styringen av parametrene i containeren. 2) Alarmfunksjon via eller fra fast komponent mot 2 mobiltefoner (tekstmelding til operat¿r og vedlikeholder) for alvaarlige feil i system eller hardware. 3) allarmfunksjon via fast enhet mot 2 mobiltelefoner (tekstmelding til operat¿r og ringesignal til sluttbruker) for aapen d¿r utenom aapningstidene. mod-sentral: input, out put mod-remote: trykker nummer og sender simplex 2.4 OPERASJON 1 1/2 mnd. kontinuerlig operasjon 2.5 ASPEKTER OMKRING LIVSSYKLUS Systemet blir vedlikeholdt ved manuell inspeksjon av hardware baade for fast og mobil komponent. Ellers er systemet programert til inspeksjon og vedlikehold av all software. Den mobile komponenten har i tilegg et minnesystem som sikrer programeringsdata. Hardwaren skal v¾re gjenbrukbar, og derfor inneha en fleksibilitet som skal kunne gj¿red den brukbar i kommende prosjekter. Utskifting av komponenter maa kunne gj¿res av A. S.M. etter insturksjon av x X har ansvar for domumentsjon, versjonskontroll og identifisering - hva naa dette maatte bety. - utvide mod-remote med duplex - alle elementer kan gjennbrukes, fordi de er så generelle - modulbasert operativsystem/miljø 2.6 YTELSE mod-sentral: sun micro ultraspore III, 4 prosessor motherboard MB 2.7 BEGRENSNINGER - skal kjøre sparc - skal kjøre linux 2.8 ANTAGELSER III DETALJERT KRAVSPESIFIKASJON 3 FUNKSJONELL SPESIFIKASJON Systemet skal motta datasett fra Meterologisk Institutt som skal brukes som grunnlag for kontrolldatasett til PLC. 3.1 FUNKSJONELL STRUKTUR OG TVERR-RELASJONER Alt startes fra mod_mctrl som tar eierskap på nødvendige kommunikasjonsporter. Den setter opp DTP-lytting på en kommunikasjonsport for mod_fjktrl, henter en URN a`la FTP via IP på ethernet og oppdaterer variablene i mod_cplc a`la IEC 61158 på RS-232. 3.2 DATA SPESIFIKASJON OG DATAORDLISTE - 4 variabler med verdi mellom 0 og 256. Ut av standard PLC kommer 0V til 10V. 39mV for hver heltallsøkning. 3.2.1 DATA RAMMEVERK 3.2.2 DATA INPUT 3.2.3 DATA OUTPUT Transmisjon fra mod_mctrl til mod_cplc på GSM. Modemet må bruke 9600Hz signalering. Stasjonen på MI Station 1 - Sognefeltet 2 - Ekkofiskfeltet 3 - Sletten Fyr Datasettformat er ISO ASCII. 3.2.4 TVERR-FUNKSJONALE DATA DEFINISJONER Grensesnittet mellom modulene på samme stasjon er trådpipe-basert. For mod_filg blir det FTP via IP på Ethernet. For mod_fjktrl blir det IEC 61158 på RS-232. 3.3 OVERORDNEDE OPERASJONELLE SYSTEMKRAV 3.3.1 NORMAL OPERASJON 3.3.1.1 MODUS OG KONTROLL 3.3.1.2 YTELSE i forbindelse med: --overføring, ingen krav til - sanntid - hastighet --mod_cplc sin stigning/senkning, ingen krav til - sanntid - hastighet i endring - responstid i øverføring 3.3.1.3 SIKKERHET - Det er ingen logisk sikring rundt mod_cplc. 3.3.1.4 OPPSTART OG NEDTAGNING - mctrl skal ha mulighet for overlapping 3.3.1.5 TILGJENGELIGHET - Oppetid på 1 1/5 mnd. 3.3.1.6 INNEBYGDE TESTER - Innebygget test i mod_mctrl. 3.3.2 OPERASJON I FEILSITUASJONER 3.3.2.1 FEILRAPPORTERING 3.3.2.2 GJENERVERVELSE ETTER FEIL Systemet skal kunne gjenerverve seg selv etter feil. 3.3.2.3 SIKKERHET Det er krav om sikring mot fysisk og logisk sikring. Fysisk - strøm/spenningsvern Logisk - filtrering, innbruddsmønsterdeteksjon og integrasjonstesting. 3.3.2.5 YTELSE 3.4 FUNKSJONELLE KRAV 3.4.1 FUNKSJONELLE KRAV TIL MODUL mod_filg Modulen skal koble seg opp mot en FTP-server og hente et bitsett. Den skal så gi sekvensen til mod_filtr ved bruk av trådpiper. 3.4.1.1 INPUT Datavarehuset kommuniserer i henhold til OMG CORBA. 3.4.1.2 PROSESSERING Prosesseringen blir datagram/segmentutveksling i henhold til DOD FTP. 3.4.1.3 OUTPUT Utdata er en fil gjennom en trådpipe. 3.4.1.4 KONTROLL 3.4.1.5 YTELSE i forbindelse med: --overføring, ingen krav til - sanntid - hastighet 3.4.1.6 TILGJENGELIGHET Modulen er en tråd. 3.4.1.7 FEILRAPPORTERING Modulen skal logge alle unntak i et valgfritt bitsett. 3.4.1.8 GJENERVERVELSE ETTER FEIL 3.4.1.9 SIKKERHET 3.3.1.9.1 LOGISK IP-datagram, TCP-segment, IEC 61158 PDU og OS exploits blir tatt hånd av gr.3 og levert i eget dokument. 3.3.1.9.2 FYSISK All fysisk sikring blir tatt hånd av gr.3 og levert i eget dokument. 4 BEGRENSNINGER 4.1 SOFTWARE DESIGN BEGRENSNINGER - CORBA - SCADA 4.1.1 SOFTWARE STANDARDER OG SPRÅK - ISO, IEEE, IEC, The Open Group: The Single POSIX UNIX SPECIFICATIN V.3 - ISO 9000-serie(1,2,3) - håndtering, kvalitetssikring og kravspesifikasjon - ISO ASCII - tegnsett - ISO 3130 - matematisk notasjon - ISO 7498 - ISO OSI Referansemodell - IEC 61131-3: programmering av PLC - IEC 1499 - erstatter SCADA - arkitekturisk modell for distribuerte måle- og kontrollsystemer 4.1.2 - IEC 1158-2 - Fieldbus - kommunikasjon i CAN-nettverk - IEC-870-5-103 SCADA Communications Protocol - IEC RS-232 - ANSI SQL3 - database - DOD STD IP - internett protokoll - DOD STD TCP - transport kontroll diagram UDP TELNET FTP 4.1.2 SOFTWARE GRENSESNITT - SUN MICROSYSTEMS JAVA 2 Specifation 1.4 - SCADA - OMG CWM - Common Warehouse Model - hvordan lagre objekter - OMG CORBA - Common Object Request Broker Architechure - platformuavhengig modellering av system - OMG MDA - Model Driven Architecture - platformuahengig fremstilling av løsning - OMG UML - Unified Modelling Language - std for diagrammer - OMG MOF - MetaObject Facility - std for metamodell - OMG OMA - Object Management Architecture - objekthåndtering - OMG XMI - XML Metadata Interchange - format for xml metadata-overføring Grensesnitt mellom moduler på samme stasjon blir trådpipe-basert. 4.1.3 SOFTWARE PAKKER/VERKTØY 4.1.4 SOFTWARE KOMMUNIKASJONSSTANDARDER OG GRENSESNITT 4.1.5 DATABASE 4.1.6 OPERATIVSYSTEM GNU/LINUX for SPARC med utsikt mot GNU/HURD for SPARC. 4.1.7 TOLERANSE, MARGINER OG MULIGHETER/TILFELLER 4.2 HARDWARE DESIGN BEGRENSNINGER 4.2.1 HARDWARE KRAV OG OMGIVELSER Siemens Simatic S7 4.2.2 HARDWARE STANDARDER - IEC RS-232 4.2.3 HARDWARE GRENSESNITT 4.2.4 TOLERANSER, MARGINER OG MULIGHETER/TILFELLE 4.2.5 BRUKER DESIGN BEGRENSNINGER 5 AKSEPTER OMKRING LIVSSYKLUS 5.1 DOKUMENTASJON Dokumentasjonen er referert i kapittel om dokumentasjon i innleveringsdokumentet og er innkludert i kommisjonens hoveddokument. 5.2 MODUL- OG INTEGRASJONTESTING 5.3 KONFIGURASJONS- OG VERSJONSTYRING 5.4 KRAV TIL SUPPORT, SERVICE OG VEDLIKEHOLD 5.5 KRAV TIL UTVIDELSER 6 AKSEPTER OMKRING INSTALLASJON 6.1 HARDWARE INSTALLASJON 6.2 OVERGANG/OMLEGGING 6.3 OPPLÆRING Det skal lages manualsider til alle modulene. 7 UTGIVELSER UNDERVEIS - oppdateringer på kommisjonens http-portal. - 1.april delrapport/status. 8 AKSEPTANSE KRAV 9 PROSJEKTSTYRING, INKLUDERT KVALITETSSIKRING Kommisjonen baserer prosjektstyring og kvalitetssikring på ISO 9000(1,2,3).