• Ei tuloksia

The Monitoring of a Group of Applications in a Local Area Network

N/A
N/A
Info
Lataa
Protected

Academic year: 2022

Jaa "The Monitoring of a Group of Applications in a Local Area Network"

Copied!
104
0
0

Kokoteksti

(1)

TEKNILLINEN KORKEAKOULU Tietotekniikan osasto

Kai Kataja

Erään lähiverkon sovellusten valvonta

Diplomityö, joka on jätetty opinnäytteenä tarkastettavaksi diplomi-insinöörin tutkintoa varten Espoossa.

Työn valvoja:

professori Reijo Sulonen

(2)

TEKNILLINEN KORKEAKOULU DIPLOMITYÖN TIIVISTELMÄ

Tekijä ja työn nimi: Kai Kataja Erään lähiverkon sovellusten valvonta

Päivämäärä: 19. syyskuuta 1996 Sivumäärä: 94

Osasto: Tietotekniikan osasto Professuuri: Tik-76 Tietojenkäsittelyoppi Työn valvoja: professori Reijo Sulonen

Työn ohjaaja: -

Tässä diplomityössä suunnitellaan erääseen lähiverkkoon, hyperkanavaan, perustuvan tiedonsiirto-ohjelmiston valvontaohjelmisto. Ohjelmisto sisältää sekä reaaliaikaisen valvonnan että pidemmän ajan käytön tilastoinnin ja laskutuksen. Diplomityössä toteu­

tetaan valvontaohjelmiston tiedonkemuosa ja kehitetään reaaliaikaisen valvonta- ohjelmiston prototyyppi.

Sovelluksen suunnittelussa on hyperkanavan erään tiedonsiirto-ohjelmiston, Netexin, istuntotason erilaisia tapahtumia käsitelty kuten viestejä älykkäässä postijärjestelmässä.

Erilaisista tapahtumaketjuista johdetaan istunnoille tarkka lajittelu. Valvonnan ja tilas­

toinnin erilaiset taipeet saadaan esitettyä täsmällisesti hyödyntämällä johdettua istunto­

jen lajittelua. Lisäksi tapahtumaketjujen jäsentely auttaa suunnittelemaan ohjelmiston tietorakenteet selkeiksi ja tarkoituksenmukaisiksi.

Sovellusten ydinosat on tehty käyttämällä kunkin sovelluksen ympäristöön sopivia työ­

kaluja. Tiedonkeruuohjelmat on ohjelmoitu käyttöjärjestelmän ja käytettyjen verkko- ohjelmistojen käsittelyyn hyvin sopivalla C-ohjelmointikielellä. Valvontaohjelma, jonka käyttöliittymän sujuvuus on eräs ohjelmiston avainalueita, on graafinen ja valikko- ohjattu. Sen toteutus on tehty erityisen hyvin käyttöliittymien tekoon sopivalla sovellus- kehittimellä. Tilastointi-ja laskutusohjelmassa on käytetty apuna monipuolista tauluk­

kolaskentaohjelmaa.

Tämän työn johdannossa perustellaan, miksi verkonvalvontaohjelmistoista ei sellaise­

naan ole verkotettujen sovellusten valvojaksi. Lisäksi rajataan valvottava sovellusympä­

ristö ja tapahtumat. Toisessa luvussa esitellään hyperkanavan ja sen erään istunto- ohjelmiston, Netexin, toimintaperiaatteet. Kolmannessa luvussa esitellään kehittämäni Netex-istuntojen luokittelujärjestelmä sekä pohditaan istuntoluokkia valvonta­

järjestelmän ja tilastointijärjestelmän kannalta. Työn neljännessä luvussa esitellään toteutettu istuntojen valvonta- ja tilastointiohjelmisto. Viidennessä luvussa pohditaan ohjelmiston tulevaisuuden näkymiä, kuten lisäpiirteiden toteuttamista ja tapoja integroitua SNMP-valvontajärjestelmiin.

(3)

HELSINKI UNIVERSITY OF TECHNOLOGY ABSTRACT OF THE MASTER S THESIS

Author and name of the thesis: Kai Kataja

The Monitoring of a Group of Applications in a Local Area Network Date: September 19, 1996 Number of pages: 94 Faculty: The Department of Computer Science

Professorship: Tik-76 Computer Science Supervisor: Reijo Sulonen, Dr. Eng.

Instructor: -

Tliis thesis is focused on the development of a monitoring system for a group of applications in a Hyperchannel local area network. The monitoring system includes short and long terni accounting. The thesis contains the design and implementation of the data collection module and prototypes of the higher level accounting and monitoring systems.

Events and sequences of events in the proprietary session control software (Netex) are classified by considering them analogous to the message classes and acceptable

messaging sequences of an intelligent electronic mail system. Through this modeling system a session classifying system is born. This formal classification assists in the design of data structures and in selecting the right events to the right reports and displays of a complex monitoring system.

The applications are implemented using carefully selected tools. The data collection software is programmed using C because it is very efficient and has a natural interface to the low layers of the VMS operating system and the synchronizing features of the VAX processor family. Also the networking interface to the TCP/IP utilities is suitable for the C language. The monitoring system and its easy to use graphical user interface prototype are implemented using a higher level tool. The prototypes of the statistical modules are developed using a versatile spreadsheet application.

In the introduction of this thesis some reasons are given why a conventional network management system is not suitable for the monitoring of networked applications. Also the scope of this thesis is drawn. The second chapter introduces the Hyperchannel environment to the reader. The third chapter describes the classification system of the session types and discusses their use in monitoring and accounting. The fourth chapter describes the monitoring and accounting systems developed. In the fifth chapter future enhancements of the system are discussed. For example some ways to tie in with SNMP systems are considered.

(4)

Alkulause

Tämän diplomityön valvojana on toiminut professori Reijo Sulonen, jolle ha­

luan esittää lämpimät kiitokseni saamistani hyvistä neuvoista ja ohjeista.

Kiitokset työtovereilleni ymmärtämyksestä diplomityön teon aikana ja työnan­

tajilleni FD Finanssidata Oy:lle ja Helsingin Puhelin Oy:lle hyvien puitteiden jäijestämisestä.

Lisäksi tahdon kiittää lähimmäisiäni, erityisesti vaimoani Pia Katajaa, kärsivälli­

syydestä ja kannustuksesta.

Helsingissä, 19. syyskuuta 1996

Kai Kataja

Laivapojankatu 3 C 50 00180 Helsinki

(5)

Sisällysluettelo

Kansilehti

Diplomityön tiivistelmä Alkulause

Sisällysluettelo Kuvaluettelo Taulukkoluettelo

Käytetyt merkinnät ja lyhenteet

1. Johdanto... 1

2. Hyperkanava ja Netex... 3

2.1. Mikä on hyperkanava?...3

2.2. Hyperkanavan fyysinen- ja siirtoyhteyskerros... 6

2.3. Netex-ohjelmisto...9

3. Istuntojen luokittelujärjestelmä...22

3.1. Istuntojen luokittelu... 22

3.2. Istunnon tunniste...27

3.3. Istunnot valvontajärjestelmän kannalta... 28

3.4. Istunnot tilastointijärjestelmän kannalta... 30

4. Istuntotason valvonta-ja tilastointiohjelmisto...32

4.1. Ohjelmiston toimintaympäristö... 32

4.2. Ohjelmiston osat...35

4.3. UX-funktiot...39

4.4. Tiedonkeruuohjelma...48

4.5. Valvontaohjelma...56

4.6. Tilastointiohjelma...58

5. Ohjelmiston tulevaisuuden näkymiä...61

5.1. SNMP-liittymä... 61

5.2. Hälytysten levitys...63

5.3. Käyttölaskutusliittymät... 63

5.4. Verkon virheiden analyysi... 65

6. Yhteenveto...66 Lähdeluettelo

Liitteet: Ohjelmalistaukset

ii

(6)

Kuvaluettelo

Kuva 1: Hyperkanavajärjestelmän kerrokset... 4

Kuva 2: Hyperkanavan väylänvaraus... 8

Kuva 3: Uudelleenlähetysalgoritmien teoreettinen tehokkuus... 10

Kuva 4: Netex-istunnon kulku...15

Kuva 5: Istuntoluokkien jatkokäsittely... 23

Kuva 6: Istuntojen jäsennys... 25

Kuva 7: Valvontanäyttö, jossa aikajärjestys... 29

Kuva 8: Valvontanäyttö, jossa tapahtumat lajeittain...30

Kuva 9: Valvottava järjestelmä ja valvojat...35

Kuva 10: Ohjelmiston osat ja tiedon kulku... 36

Kuva 11: Rengaspuskureiden alkioiden käyttö...43

Kuva 12: Tiedonkemuohjelman tiedostojen käyttö...48

Kuva 13: Kuukausitiedoston alkua... 50

Kuva 14: Uudet istuntotiedot... 51

Kuva 15: FTP-tiedostonsiirron esimerkki...54

Kuva 16: Valvontaohjelman prototyypin näyttöjä... 58

(7)

Taulukkoluettelo

Taulukko 1: Netex-tiedonsiiito-ohjelmointiliittymän kutsut...13

Taulukko 2: Netex-ohjausohjelmointiliittymän kutsut...14

Taulukko 3: Netex-palvelutietorakenteen kentät...19

Taulukko 4: Pal vei u tietoraken teen kenttien käyttö palvelupyynnöissä... 21

Taulukko 5: Istuntojen luokittelu... 24

Taulukko 6: UX-funktioiden saamat ja antamat tiedot... 41

Taulukko 7: Istuntotapahtumatieto rengaspuskurin tietueessa...45

Taulukko 8: FTP-siirtoparametritiedoston kentät... 52

IV

(8)

Käytetyt merkinnät ja lyhenteet

API ASCII

BCD

В FX

CSMA/CD

CSV

EBCDIC

FTP

IBM

IEEE

ISO

Netex

NRB

NRF

Application Programming Interface; ohjelmointiliittymä American Standards Committee for Information Inter­

change; akronyymi viittaa nykyään yleensä em. standar­

dointikomitean kehittämään merkkitiedon esitystapaan, joka on edelleen laajassa käytössä

Binary Coded Decimal; desimaalilukujen digitaalinen esitys- muotojoukko, joista yleisimmässä luvut 0-9 esitetään neljällä bitillä 0000,0001,0010,... ,1001.

Bulk File Transfer; eräkäsittelypohjainen tiedostonsiirto- järjestelmä Netex-istunto-ohjelmistoa käyttävissä hyper- kanavajärjestelmissä

Carrier Sense, Multiple Access / Collision Detection; kuul- losteluväylä törmäyksen tunnistuksella; yleinen lähiverkoissa käytettävä vuoronvarausjärjestelmä

Comma-Separated Value; eräs taulukkolaskentatiedon tal­

letusmuoto

Extended Binary Coded Decimal Interchange Code; IBM- keskuslaitteissa käytettävä tiedon esitysmuoto, vit. ASCII File Transfer Protocol; TCP/IP-verkoissa käytettävä tiedos­

tonsiirtomenetelmä

International Business Machines; kansainvälinen tietojen­

käsittelyjärjestelmien valmistaja ja markkinoija

Institute of Electrical and Electronics Engineers; elektro- niikkainsinöörien tieteellinen yhteistyöjärjestö, joka harjoit­

taa laajaa julkaisu- ja konferenssitoimintaa

International Organization for Standardization; kansain­

välinen standardoimisjäijestö

Network Executive; hyperkanavassa käytettävä istuntota- son verkko-ohjelmisto

Netex Request Block; Netex-palvelutietorakenne, joka si­

sältää Netex-istunnon tärkeimmät tiedot

Netex Reference Number; Netex-ohjelmiston sisäinen is­

tunnon tunniste

(9)

NSC

oktetti OSI

SNMP

SNMP-DPI

tavu

TCP/IP

их

VAX

VB VMS

Network Systems Corporation; yhdysvaltalainen tietoliiken­

nealan yritys, jonka tuotteita ovat mm. hyperkanava ja Netex

kahdeksan bitin pituinen informaatioyksikkö, vit. tavu Open Systems Interconnection; ISO:n avoimien tiedon­

siirtostandardien kehittämismalli

Simple Network Maintenance Protocol; yleinen verkon- hallintajärjestelmä

SNMP Distributed Protocol Interface; menetelmä, jolla SNMP-agenttia voidaan laajentaa

tietokonearkkitehtuurista riippuva informaatioyksikkö, yleensä kahdeksan bittiä

Transmission Control Protocol / Internet Protocol; eräs IP- verkoissa laajassa käytössä oleva yhteydellinen tiedonsiirto­

tapa; tämä lyhenne tarkoittaa nykyään myös laajemmin usei­

ta IP-verkkoon liittyviä ohjelmistoja ja verkkotuotteita User Exit; ohjelmointiliittymä Netex-ohjelmistoon (Netex API)

Virtual Address Extension; Digital Equipment Corpora­

tionin oma prosessorimalli, jossa on monipuolinen käsky- kanta (CISC) ja jonka rekisterit ovat 32-bittisiä

Visual Basic; eräs Windows-sovellusten ohjelmointikieli Virtual Memory System; Digital Equipmentin oma, laaja käyttöjärjestelmä VAX- ja Alpha-prosessorisille laitteille

vt

(10)

1

.

Johdanto

Tietoverkkojen kasvu on räjähdysmäistä ja niiden asukkaat, verkotetut sovel­

lukset, liittyvät toisiinsa yhä monipuolisemmilla tavoilla. Monimutkaiset kyt­

kennät sovellusten välillä lisäävät toimintahäiriöiden mahdollisuuksia ja edistä­

vät niiden vaikutusten leviämistä. Verkotettujen sovellusten kokonaisuuden hallintaan ei riitä pelkästään tietoliikenteen valvontaohjelmisto; tarvitaan kor­

keamman tason malli koko sovellusjärjestelmästä, sen riippuvuussuhteista ja ominaisuuksista.

Tietoliikenteen valvontaohjelmistot ovat usein rajoittuneet tietyn, suppean val- mistajajoukon tuotteiden valvontaan, tosin tilanne tässä suhteessa paranee ko­

ko ajan, kiitos SNMP-standardien laajan hyväksynnän. Nykyisessä, dynaami­

sessa tietoliikennemaailmassa olisi hyödyllistä kehittää yleisempiä valvontajär­

jestelmien malleja, joita voitaisiin soveltaa erilaisiin ympäristöihin. Tieto­

liikenteen valvontajärjestelmät ovat myös keskittyneet valvomaan siirtoyhteys- ja verkkotason tapahtumia, mikä vaikeuttaa heterogeenisen verkon valvontaa, koska eri verkkoympäristöissä tarvitaan eri työkalut. Työkalujen kirjavuus taas vaikeuttaa laaja-alaisten virhetoimintojen vaikutuksen ilmaisua ja analysointia.

Usein verkon ylempien tasojen - istunto- ja sovellustason - valvonta on täysin erillään alempien tasojen verkonvalvonnasta. Istunto- ja sovellustason valvonta täydennettynä alempien tasojen valvonnalla antaa siksi huomattavasti enemmän tietoa häiriöiden todellisista seurauksista.

Valvontaohjelmiston tulee antaa luotettava ja nopeasti tulkittava kuva verkon nykytilasta. Valvontaohjelmisto ei saa kuitenkaan missään tilanteessa kuormit­

(11)

taa verkkoa eikä sen komponentteja liikaa. Reaaliaikaisen valvonnan lisäksi valvontajärjestelmä voi myös kerätä verkon käytön laskutustietoja ja pidemmän ajan virheseurantatietoa. Verkon käytön laskutus on erittäin tärkeä sovellus ny­

kyaikana myös ylitysten sisäisissä verkoissa, koska kustannusten seurannalle ja kohdentamiselle asetetaan nykyaikana suuria vaatimuksia.

Keskittymällä valvomaan verkon istuntotasoa saadaan kehitettyä valvontajär­

jestelmän malli, jota voidaan soveltaa hyvin erilaisiin verkkoihin, koska useim­

mista verkkojärjestelmistä voidaan löytää istuntotaso. Lisäksi istunto taso 11a ol­

laan lähempänä sovellusten näkemää tiedosiirtoprosessia, jolloin saadut tulok­

set ovat lähemmin yhteydessä todellisen hyötytiedonsiirron suorituskykyyn.

Valvontajärjestelmään on myös helpompi lisätä älykkyyttä, joka käyttää hyväk­

si eri sovellusten piir teitä ja vaatimuksia, kun saadaan tietoja riittävän korkealta tasolta. Näin eri sovellukset voidaan tunnistaa ja niiden tiedonsiirto-operaatiot eritellä vaivattomasti ja tehokkaasti.

FD Finanssidata Oy:n hyperkanavaverkko tarjoaa vakiintuneen ja rajoitetun ympäristön uuden valvontaohjelmiston kehittämiseksi. Esityö istuntotason val­

vontaan on jo tehty [Kataja93]. Siinä on toteutettu tiedonkeruuliittymä erään pienkoneympäristön tietoliikenneohjelmiston istunto tasolle. Tässä työssä suun­

nitellaan ja toteutetaan osia istuntotason valvontajärjestelmästä, jossa on muka­

na sekä reaaliaikainen valvonta että pidemmän ajan käyttö- ja virhetilastointi.

2

(12)

Hyperkanava ja Netex Mikä on hyperkanava?

2. Hyperkanava ja Netex

2.1. Mikä on hyperkanava?

Hyperkanava on nopea, suurten ja keskisuurten tietokoneiden lähiverkko.

Vaikka hyperkanavaverkko voi olla satelliittilinkkejä hyväksi käyttäen jopa mannertenvälinen, tässä työssä käsiteltävä verkko on maantieteellisestikin lähi­

verkko.

Lähes kaikki hyperkanavatuotteet (laitteet ja ohjelmistot) valmistaa yhdysvalta­

lainen Network Systems Corporation1. Tuote ei perustu mihinkään standardei­

hin, mutta yleistyi 1980-luvulla suurissa ATK-tuotantoympäristöissä, koska se pystyi yhdistämään usean eri laitevalmistajan laitteet toisiinsa silloin suhteellisen suurella 50-200 Mbit/s nopeudella. Tyypillisessä hyperkanavaverkossa on yleensä korkeintaan kymmeniä tietokoneita. Toisaalta niiden väliset etäisyydet voivat olla mannertenvälisiä. Hyperkanavan verkko-ohjelmistoissa on otettu huomioon satelliittilinkkien pitkät viiveet käyttämällä suuria tiedonsiirto yksi­

köitä ja erityisesti viipeiseen liikenteeseen sopivaa uudelleenlähetysprotokollaa.

Tiedonsiirtoa eri laitteistoarkkitehtuurien välillä on nopeutettu tekemällä tieto- muotomuunnokset (erilaiset BCD-esitystavat, erilaiset tavu- ja sananpituudet, ASCII- ja EBCDIC- tekstit...) hyperkanavasovittimen puskureissa ilman isän­

täkoneen apua. Ensimmäiset hyperkanavatuotteet tulivat näet markkinoille seit­

semänkymmentäluvun lopussa, jolloin eri sana- ja tavupituuden laitteistoarkki­

tehtuureja (IBM, Honeywell, Univac, CDC, yms.) oli laajasti käytössä.

•Lisätietoa saa linkistä http://www.network.com/

(13)

Hyperkanava ja Netex Mikä on hyperkanava?

Hyperkanavassa tehdään enimmäkseen raskaita eräluonteisia tiedostonsiirtoja sovellusten välillä. Esimerkiksi FD Finanssidata Oy:ssä ei VAX-laitteistoilla tarvitse olla järeitä varmuuskopiointilaitteita tai tulostimia, vaan varmuuskopiot ja suuret tulosteet siirretään hyperkanavalla suurkoneeseen. Sieltä varmuusko­

piot menevät nauharobotille ja tulosteet tehokkaisiin laserkirjoittimiin. Lisäksi suuri joukko sovelluksia pääasiassa siirtää tiedostoja eri keskustietokoneiden välillä.

Netex istunnot

Hyperkanavan laiteajuri

Hyperkanavasovitin ja -kaapelit UX-funktiot Tiedostonsiirto

Kuva 1: Hyperkanavajärjestelmän kerrokset

4

(14)

Hyperkanava ja Netex Mikä on hyperkanava?

Esimerkkiympäristömme sovellukset ovat: tulostuspalvelut, varmuuskopiointi ja tiedostonsiirto sovellusten välillä. Itse asiassa kaksi edellämainittua ovat tie­

dostonsiirron erikoistapauksia ja kaikki kolme käyttävät saman tiedostonsiirto- ohjelmiston palveluita. Ei kuitenkaan kannata pelkistää sovellusympäristöä niin pitkälle, että tarkasteltaisiin pelkästään tiedostonsiirtoa. Silloin hävitettäisiin nauharobotti- tai tulostinjärjestelmien osuus toimintaketjusta pois. Molemmat em. laitteistot ovat sellaisenaan monimutkaisia laitteisto- ja ohjelmistokokonai­

suuksia, joiden toimintakatkojen vaikutukset niistä riippuviin sovelluksiin on otettava kattavassa sovellusympäristön analyysissä huomioon, vaikka niihin ei tässä työssä juurikaan puututa. Tulostuspalvelut ja varmuuskopiointi käyttävät BFX-tiedostonsiirto-ohjelmistoa, jota voidaan käyttää suoraan myös muista so­

vellusohjelmista. Kuvassa on neljäntenä sovelluksena tiedonkeruuohjelma, joka on osa tässä diplomityössä laadittua valvontajärjestelmää. Tiedonkeruuohjelma kerää UX-funktioiden tiedot eikä voi vaikuttaa UX-funktioihin millään tavalla.

Siksi kuvan nuoli tiedonkeruuohjelmaan on yksisuuntainen.

Kuvan seuraavalla tasolla on Netex-istunto-ohjelmisto ja siihen liitetty, tässä diplomityössä laaditun valvontajärjestelmän osa, UX-funktiot. Kuvaan piirretyt NRB-lohkot kuvaavat jokaisen istunnon omaa hallintatietoaluetta. UX-funktiot nimittäin saavat tietoa sekä koko Netexiltä että sen hallitsemilta yksittäisiltä is­

tunnoilta. Lisäksi UX-funktiot voivat vaikuttaa sekä koko Netex-ohjelmistoon (mm. estää sen käynnistymisen tai käynnistää sen uudelleen lopetuksen jälkeen) että yksittäiseen istuntoon (mm. valvomalla käyttöoikeuksia ja muuttamalla lii- kenneparametreja). Siksi nuolet UX-funktioiden ja Netexin sekä sen istuntojen välillä ovat kaksisuuntaisia.

(15)

Hyperkanava ja Netex Hyperkanavan fyysinen-ja siirtoyhteyskerros

Hyperkanava ohjelmistoineen on käytännössä osoittautunut erittäin nopeaksi tiedonsiirtojärjestelmäksi. Tavallisen VAX-lait teen varmistukset ovat satoja miljoonia, jopa miljardeja tavuja sisältäviä tiedostoja. Tällaisia varmistuksia otetaan joka päivä useita kymmeniä. Lisäksi niiden on rajoituttava ilta- ja yöai­

kaan, koska varmistusten otto häiritsee koneen käyttäjiä. Tällaisessa käytössä hyperkanava on pystynyt siirtämään jatkuvasti miljoonia tavuja muutamassa se­

kunnissa.

Eräs mahdollinen hyperkanavan Istunto-ohjelmisto on Netex, jonka palveluilla voi kaksi prosessia viestiä hyperkanavan yli toisilleen. Verkkomme kaikki oh­

jelmistot käyttävät hyperkanavaliikenteeseensä ainoastaan Netex-palveluita, jo­

ten valvomalla sen istuntotasoa saadaan sovellustason tiedonsiirtotapahtumat tarkasti tutkituksi.

2.2. Hyperkanavan fyysinen- ja siirtoyhteyskerros

Hyperkanavan eri koneita yhdistävä johto on 75 O (± 3%) koaksiaalikaapelia.

Hyperkanavakaapelissa kulkevan signaalin kantataajuus on 100 MHz ja se ky­

kenee siirtämään 50 miljoonaa bittiä sekunnissa käyttäen muunnettua Millerin koodausta upotetulla kellolla.2 Hyperkanavassa käytettävä CSMA / CD poik­

keaa paljon DIX3 Ethernet tai ISO 8802.3 (IEEE 802.3) -tyyppisestä CSMA / CD -periaatteesta. Hyperkanavassa saattaa kuitenkin tapahtua törmäyksiä, jo­

ten CD-liite on paikallaan (CD, Collision Detection). Hyperkanavan valmista­

jalla on myös hyperväylä-niminen 10 Mbit/s kuljettava tuote, jonka toimintape-

2NSC86, s. TN:l-2a/4

3Digital Equipment, Intel ja Xerox, jotka kehittivät yhdessä Ethemetin

6

(16)

Hyperkanava ja Netex Hyperkanavan fyysinen-ja siirtoyhteyskerros

riaate on CSMA/CA, eli törmäykset vältetään kokonaan (CA, Collision Avoi­

dance). Hyperväylää ei tässä työssä käsitellä.

Hyperkanavan väylänvarausalgoritmiin on lisätty ennakkovarausmenetelmän4 (MLMA, Multi-Level Multiple Access) piirteitä. Täten algoritmi vaatii kaik­

kien hyperkanavaan liitettyjen sovittimien määritysten muuttamista, kun kana­

vaan lisätään tai siitä poistetaan sovittimia tai kanavan kaapeleiden pituuksia muutetaan. Hyperkanavan asentaminen ja toimintakuntoon saattaminen on mo­

nimutkaista, toisaalta hyperkanavasovittimilla on tarkka tieto toisistaan ja ne käyttävät tätä tietoa hyväksi saavuttaakseen mahdollisimman suuren tiedonsiir­

tonopeuden.

Hyperkanavaliikenteessä lähettäjä odottaa jokaiseen kehykseen vastausta siltä, jolle kehys on lähetetty (tämä on yksinkertaista, koska hyperkanavassa ei ole ryhmäosoitteita). Jos vastausta ei tule, on tapahtunut törmäys tai joku muu häi­

riö ja kehys lähetetään uudelleen. Muut sovittimet antavat vastauskehykselle tietä olemalla lähettämättä lähetyksen jälkeen tietyn ajan (kuittausperiodi, fixed delay). Sen jälkeen jokaisella sovittimella on oma lähetysviipaleensa (prioriteettiperiodit, priority delays). Jos ne jäävät käyttämättä, voi kuka ta­

hansa lähettää (kilpailu, free-for-all). Aikaviipaleensa käyttänyt sovitin antaa muille tilaisuuden käyttää omansa ennen seuraavaa viipaleen käyttöä. Näin yk­

sikään sovitin ei pääse kaappaamaan hyperkanavaa omaan käyttöönsä.5

4Ennakkovarausmenetelmässä jokaista tiedonsiirtoaikaväliä edeltää varausaika väli. Kullakin verkon jäsenellä on oma kiinteä osuutensa (bitti) varausaikavälissä. Näin tiedonsiirtoaika- välin alkaessa jokainen verkon jäsen tietää mitkä jäsenet haluavat lähettää. Rahko84, s. 45 5NSC85, s. SN:4-5

(17)

Hyperkanava ja Netex Hyperkanavan fyysinen-ja siirtoyhteyskerros

aika

■ — - »

kehyksen lähetys

kuittausperiodi

prioriteetti-

periodit kilpailu

- - -

Kuva 2: Hyperkanavan väylänvaraus

ISO 8802.3-tyyppisen CSMA / CD eli kuullosteluperiaatteella vuoron varaavan lähiverkon teoreettinen hyötysuhde on noin 90%.6 Tähän verraten hyperkana­

van tulisi siten pystyä siittämään 45 miljoonaa bittiä sekunnissa eli 5,6 miljoo­

naa 8-bittistä tavua sekunnissa. Tässä on laskettu mukaan siirrettävän tiedon li­

säksi myös ohjausinformaatio. Toisaalta edellä esitetty ennakkovarausväylä- luonne ja kuittauskehykset huonontavat hyperkanavan maksimisiirtonopeutta verrattuna ISO 8802.3 CSMA/CD:hen. Ennakkovarausmenetelmällä on kui­

tenkin etunsa: ISO 8802.3 kuullosteluperiaatteella toimiva verkko tukkeutuu nopeasti lähestyttäessä teoreettista maksimia. Hyperkanavan prioriteettimeka- nismi estää tukkeutumisen. Koska hyperkanavassa tehdään suuria eräluontoisia tiedostonsiirtoja ja tulostuksia, on laajennustarpeiden arvioimiseksi selvitettävä sen todellinen kapasiteetti.

Hyperkanavassa voi olla rinnan yhdestä neljään fyysistä 50 Mbit/s siirtotietä.

Hyperkanavasovittimet pystyvät jakamaan kuorman niille tasaisesti.7 Esimer­

kiksi ISO 8802.3-tyyppisissä verkoissa pelkkä siirtoteiden lisääminen ei samalla tavalla automaattisesti kasvata siirtoyhteystason kapasiteettia. Tällä hetkellä Fi-

6Rahko84, s. 45 7Hardwick88, s. 42

8

(18)

Hyperkanava ja Nelex Netex-ohjelmisto

nanssidatalla on käytössä kaksi siirtotietä lähinnä vikasietoisuuden lisäämiseksi, mutta niiden kuormittuessa olisi mahdollista lisätä kolmas ja neljäs 50 Mbit/s väylä lisäämään tiedonsiirtokapasiteettia muuttamatta verkon ylempiä tasoja mitenkään.

2.3. Netex-ohjelmisto

Edellisessä kappaleessa siis esiteltiin OSI-mallin kerrokset 1 ja 2, eli fyysinen- ja siirtoyhteyskerros. Tämän kappaleen otsikoksi valitsin Netex-ohjelmiston, koska se on sovellusohjelmien kehittäjille mono hitti, joka kattaa OSI-mallin kerrokset 3-5, eli verkko-, kuljetus- ja istuntokerrokset. Nykyisen käsityksen mukaan tämä ei ole nun tuomittavaa kuin vielä muutama vuosi sitten. Silloin ymmärrettiin ainakin joillakin tahoilla koko OSI-mallin tarkoitus hieman väärin, kun kaikkien kerrosten piti ehdottomasti löytyä erillisinä itse tiedonsiirtojärjes­

telmistä. Hyperkanavankin dokumentaatiossa luvataan avata verkko- ja kulje­

tustasojen sovellusrajapinnat joskus tulevaisuudessa. Nykyään ymmärretään kerrosten olevan standardointityötä helpottamaan tarkoitettuja, jokseenkin ab­

strakteja käsitteitä. On jopa esitetty, että istuntokerros on tarpeeton.8

Netex on tiedonsiirtoistuntopalveluja hyperkanavaympäristössä tuottava ohjel­

misto. Netexin tarkempaan toteutukseen ei tässä työssä tutustuta, mutta esitte­

len sen yhden erityispiirteen. Netex käyttää tiedonsiirtoyksiköiden uudelleenlä­

hetyksissä valintaista algoritmia (selective callback) yksinkertaisemman uudel-

8Partridge93, s.8-10

(19)

Hyperkanava ja Netex Netex-ohjelmisto

leenlähetysalgoriimin (go-back-N) sijasta. Algoritmien tehokkuuden ero selviää kuvasta:9

p(p bio frameldi) := 1 - (l - p bijjframelen delay

a(delay, frame) :=--- fnmie

E gbN^P’3^ :_ 1 - P 1 +(a- l)-p Esei(p) := 1 - P

bit := 1 k := 1024 M := k" s := see byte := 8-bit

a := a

p := 10

1-km 4-k-byte\

200-— »Ä

s s /

. 3 . 3

,3-10 .. 1

a =8

0.001 0.01 0.1 1

p

Kuva 3: Uudelleenlähetysalgoritmien teoreettinen tehokkuus

Kuvassa on yksinkertaisen algoritmin tehokkuus (ЕбЬм) kuvattu katkoviivalla ja valintaisen uudelleenlähetysalgoriimin tehokkuus (Е^,) yhtenäisellä viivalla.

9Yksinkertaisessa uudelleenlähetysalgoritmissa lähetetään uudelleen kuittaamaton ja kaikki sen jälkeiset tiedonsiirtoyksiköt. Valintainen algoritmi lähettää uudelleen vain kuittaamatto-

10

(20)

Hyperkanava ja Netex Netex-ohjelmisto

Huomaa, että yhtenäinen viiva leikkaa pisteet (0,1; 0,9), (0,5; 0,5) jne. kuten pitääkin. X-akselilla oleva logaritminen asteikko muuttaa suoran logaritmikäy- räksi. Pystyakselilla on tiedonsiirron suhteellinen tehokkuus teoreettisesta mak­

simista ja vaaka-akselilla (p) on todennäköisyys, jolla yksittäinen tiedonsiirto- yksikkö ei mene perille.10 Parametri a kertoo montako tiedonsiirtoyksikköä eh­

ditään lähettää, kunnes saadaan tieto tiedonsiirtoyksikön perille menosta. Ku­

vassa on käytetty arvoa 8, joka saadaan esimerkiksi puolen kilometrin pituises­

sa hyperkanavassa neljän kilotavun tiedonsiirtoyksiköillä. A:n arvolla yksi algo­

ritmit ovat teoreettisesti aivan yhtä tehokkaita.

Valintaisen algoritmin tehokkuus ei riipu parametrista a, koska se lähettää uu­

delleen vain ne tiedonsiirtoyksiköt, jotka eivät menneet perille. Yksinkertaisem­

pi algoritmi lähettää uudelleen perille menemättömästä lähtien kaikki tiedonsiir­

toyksiköt. Siksi sen tehokkuuteen vaikuttaa a, joka kertoo montako jo lähetet­

tyä tiedonsiirtoyksikköä joudutaan lähettämään uudelleen.

Vaikka kuvassa olevassa kaavassa lasketaan parametrille a arvo fyysisten omi­

naisuuksien (signaalin kulkunopeus 200 km/s, matka 2 • 500 m = 1 km, siirto­

nopeus 50 Mbit/s, yksikkö 4 kilotavua) avulla, on se mahdollista yleistää koko tiedonsiirtojärjestelmää ja sen viiveitä koskevaksi. Valintainen algoritmi auttaa sitä enemmän, mitä enemmän tiedonsiirrossa puskuroidaan tiedonsiirtoyksiköi- tä millä kerroksella tahansa. Toisaalta valintainen algoritmi kuluttaa enemmän sekä muistia että laskentatehoa kuin yksinkertainen algoritmi. Valintaista algo-

man tiedonsiirtoyksikön. Schwartz87, s. 132-156

10Kuvan ensimmäisessä kaavassa on esitetty, miten p saadaan lasketuksi tietoliikenneteknii­

kassa enemmän käytetystä bittivirhesuhteesta ры,, kun tiedetään tiedonsiirtoyksikön pituus

(21)

Hyperkanava ja Netex Netex-ohjelmisto

ritmia on siksi toistaiseksi käytetty varsin harvoin. Laskentatehon ja muistin hinnan laskiessa koko ajan on tämä algoritmityyppi hyvä pitää mielessä uusien protokollien suunnittelussa.

Kuvan mukaan valintainen algoritmi on yksinkertaista huomattavasti parem­

pi, kun tiedonsiirtoyksiköiden tuhoutumistodennäköisyys on yli 0,01 (yksi sa­

dasta). Tämä voidaan saavuttaa ruuhkaisissa verkoissa. Valintainen algoritmi auttaa myös sitä enemmän, mitä suurempi parametri a on. Viipeiset siirtotiet, erityisesti satelliittilinkit, kasvattavat algoritmien tehokkuuseroa huomattavasti.

Netex käyttää menestyksellä sekä parempaa algoritmia että erittäin suuria tie- donsiirtoyksiköitä taatakseen erinomaisen suorituskyvyn kaikissa tilanteissa.

Netex-istunto avataan aina kahden prosessin välille11; mikäli halutaan siirtää tietoa useamman prosessin kesken, avataan riittävä määrä kahden prosessin vä­

lisiä Netex-istuntoja. Netex-istunnossa ensin toinen prosessi ilmoittaa o levänsä valmis tiedonsiirtoon. Se siirtää Netex-palvelutietorakenteessa paikalliselle Ne- tex-ohjelmalle suuren joukon parametreja, joista istunnon muodostumisen suh­

teen tärkein on nimi, jolla juuri tähän odottavaan prosessiin voidaan ottaa yh­

teyttä. Tämä nimi12 on korkeintaan kahdeksan merkkiä pitkä, kirjaimia ja nu­

meroita sisältävä merkkijono.

Netex-tiedonsiirtoa ohjelmoidaan kaikkiaan kahdeksalla aliohjelmakutsulla:

bitteinä (framelen). Olen kuitenkin käyttänyt kuvaajassa mielestäni tähän tapaukseen ha­

vainnollisempaa parametria p.

1'Kaksi tiedonsiirtoprosessia voidaan tietysti sisällyttää saman prosessin säikeisiin tms. Joka tapauksessa kyse on aina kahden, ei monenvälisestä viestinnästä.

12Katso taulukosta "Netex-palvelutietorakenteen kentät" sekä liitteenä olevan Netex-palvelu- tietorakenteen C-kielisestä kuvauksesta kenttä nrbnam.

12

(22)

Hyperkanava ja Nelex Netex-ohjelmisto

OFFER tarjous Ohjelma on valmis tiedonsiirtoon.

CONNECT yhteys Pyyntö muodostaa istunto tatjouksen antaneen ohjelman kanssa.

CONFIRM kuittaus Tarjouksen antanut ohjelma kuittaa istunto- kumppanin yhteys-pyynnön ja ilmoittaa olevansa valmis istunnon muodostamiseen.

WRITE kirjoitus Lähettää tietoa istuntokumppanille.

READ luku Vastaanottaa tietoa. Tätä käytetään myös kuit­

tausten, sulkujen ja katkaisujen vastaanottami­

seen.

WAIT odotus Tämä aliohjelmakutsu palaa vasta kun edellinen, asynkronisena annettu palvelupyyntö on

päättynyt.

CLOSE sulku Viimeinen kirjoituspyyntö. Ohjelma kertoo ole­

vansa valmis istunnon lopettamiseen. Kump­

panin antaessa sulkupyynnön istunto on päät­

tynyt.

DISCONNECT katkaisu Istunnon välitön katkaisu. Tämä voidaan antaa koska tahansa.

Taulukko 1: Netex-tiedonsiirto-ohjelmointiliittymän kutsut

Tämän tiedonsiirto-ohjelmointiliittymän lisäksi on olemassa ohjausohjelmointi- liittymä. Sitä käytetään liittämällä Netex-istuntoja ylläpitävän Netex-prosessin kutsuttavaksi itse tehtyjä aliohjelmia, joille Netex antaa parametreinä erilaisia istuntotietoja ja jotka voivat myös vaikuttaa Netexin toimintaan. Ohjausohjel- mointiliittymään liitetyillä ahohjelmilla, joita jäljempänä kutsun UX-funktioiksi (UX tulee englanninkielisistä sanoista User Exit13), voidaan mm. estää minkä tahansa istunnon muodostuminen. Erilaisia UX-funktioita on seitsemän:

13UserExit -termi on laajasti käytössä mm. IBM-suurkoneympäristön ohjelmistoissa.

(23)

Hyperkanava ja Netex Netex-ohjelmisto

UXINI alustus Tätä kutsutaan NETEX-ohjelman alustukses­

sa. UXINI-aliohjelmassa voidaan varata ja alustaa muidenkin UX-funktioiden tarvitsemat tietorakenteet.

UXTRM lopetus Tätä kutsutaan NETEX:n lopetuksessa.

UXTRM-aliohjelmassa vapautetaan UX- funktioiden tarvitsemat resurssit.

UXOFR tarjous Kutsutaan jonkun istunnon annettua tarjous­

pyynnön.

UXCNN yhteys Kutsutaan vastaavasti yhteyspyynnössä.

UXCNF kuittaus Kutsutaan vastaavasti kuittauspyynnössä.

UXCMP valmis Kutsutaan jonkun saatua tarjouspyyntöönsä vastaukseksi yhteys-sanoman tai lukupyyn- töönsä kuittaussanoman.

UXDSC katkaisu Kutsutaan istunnon katkettua. Tämä funktio saa parametrina istunnossa vaihdettujen sano­

mien ja tavujen määrän.

Taulukko 2: Netex-ohjausohjelmointiliittymän kutsut

Netex-istunnon kulku ja ohjausohjelmointiliittymän toiminta voidaan esittää ha- vainnollisimmin kaavoina, jossa näkyy myös istunnon kolme erilaista osaa:

muodostus, tiedonsiirto ja lopetus. Nämä on eroteltu toisistaan paksuilla vaa­

kaviivoilla.

14

(24)

Hyperkanava ja Netex Netex-ohjelmisto

Prosessi A Prosessi В

UXOFR UXCMP UXCNF

OFFER

^_____ CONNECT UXCNN

CONFIRM —► READ UXCMP

READ WRITE —►

UXDSC

CLOSE READ

CLOSE

READ 4 UXDSC

Kuva 4: Netex-istunnon kulku

Aika etenee kuvassa ylhäältä alaspäin. Ensiksi prosessi A tekee tarjouspyyn­

nön. Se välittyy Netex-istuntoja ohjaavalle ohjelmalle, joka aloittaa tarjous­

pyynnön käsittelyn. Mikäli tarjouspyyntö oli muotoiltu oikein, hypätään UXOFR-funktioon. Jos UXOFR-funktio päästää tarjouspyynnön hyväksytysti läpi, on tarjouspyyntö palveltu loppuun. Tästä ilmoitetaan tarjouspyynnön teki­

jälle.

Seuraavaksi jokin toinen prosessi tekee yhteyspyynnön, jossa se täyttää palve- lutietorakenteeseen prosessia A ajavan koneen Netex-nimen ja prosessin A tar­

jouspyynnössään antaman nimen, jolla siihen otetaan yhteyttä. Yhteyspyyntö käsitellään kuten tarjouspyyntökin; ensin yhteyden yrittäjän Netex-istunnoista vastaava ohjelma tutkii, onko yhteyspyyntö muodollisesti pätevä. Jos se on,

(25)

Hyperkanava ja Netex Netex-ohjelmisto

niin kutsutaan UXCNN-funktiota, joka päättää, päästetäänkö yhteyspyyntö lähtemään verkkoon.

Kun tieto B:n yhteyspyynnöstä saapuu A:lie, merkitään A:n tarjouspyyntö lo­

pullisesti täyttyneeksi. Merkiksi tarjouksen onnistumisesta suoritetaan UXCMP-funktio. Jos A ei jostain syystä halua viestiä B:n kanssa, se voi vasta­

ta yhteyspyyntöön katkaisupyynnöliä. Yleensä A on halukas viestimään B:n kanssa, jolloin A tekee vastaukseksi kuittauspyynnön. Kuittauspyyntökin käsi­

tellään kuten tarjous- ja yhteyspyynnöt, eli ensin Netex-ohjelma tarkistaa kut­

sun ja sitten suorittaa UXCNF-funktion.

Verkkoon päässyt kuittauspyyntö saapuu lopulta B:lle. В on yhteyspyyntönsä jälkeen antanut lukupalvelupyynnön ja kun A:n kuittaus täyttää B:n lukupyyn- nön on istunto sekä A:n että B:n puolesta valmis. B:n luettua A:n kuittauksen laukeaa В-puolen Netex-ohjelmassa vielä UXCMP-funktio. Se päättää istun­

non muodostusvaiheen.

Istunnon toisessa vaiheessa A ja В antavat luku- ja kirjoituspalvelupyyntöjä.

Näistä ei seuraa mitään ohjausohjelmointiliittymän tapahtumia, joten valvonta- ohjelmistolla ei ole mitään tietoa tiedonsiirron kulusta. Tiedonsiirto-ohjelmoin- tiliittymä rajoittaa tämän vaiheen asynkronista toteutusta sallimalla ainoastaan yhden luku- ja yhden kirjoituspyynnön samanaikaisen suorituksen.14

Istunnon kolmas, eli lopetusvaihe, alkaa jommankumman istunnon osapuolen antamalla sulku- tai katkaisupyynnöliä. Näiden ero on siinä, että sulku on istun­

16

(26)

Hyperkanava ja Netex Netex-ohjelmisto

non normaali, järjestynyt lopetustapa, jossa molemmat istuntokumppanit sopi­

vat istunnon lopettamisesta, kun taas katkaisussa toinen istuntokumppani lo­

pettaa istunnon äkillisesti. Kuvan istunto päättyy A:n antamaan sulkupyyntöön, jonka В lukee ja vastaa sulkupyynnöllä. Istunnon päättyessä suoritetaan aina

UXDSC-funktio.

Netex-palvelutietorakenne

Katsahtaaksemme hieman syvemmälle Netex-istuntoon käydään esittelynomai- sesti läpi Netex-palvelutietorakenteen kentät.14 15 Kursiivilla olevat kentät eivät muutu istunnon avaamisen jälkeen. Palvelu tieto rakenteen VAX-arkkitehtuurin C-kielinen esitys on liitteenä. Vasemmassa sarakkeessa on esitetty sekä lyhyet että pitkät nimet. Koska Netex-tuotteita on kymmeniä erilaisia, nimitykset eivät kaikissa implementaatioissa ole samat, joten joillakin kentillä on useita eri ni­

miä.

asp Tämä on asynkroniselle aliohjelmalle (katso kenttä ast) annettava parametri.

ast Tähän laitetaan sellaisen aliohjelman osoite, jota kutsutaan asynkronisesti palvelupyynnön päätyttyä.

bfl,

BufferLength

Tällä kentällä kerrotaan tiedonsiirtopuskurin koko. Mikäli tuleva tieto ei mahdu tähän kokoon, jää osa tiedosta saa­

matta. Huomaa, että lähtevän tiedon pituus on kentässä Ien.

bsi,

MaxInBlock

Tähän kenttään kerrotaan suurin odotettu luettavan tiedon määrä. Jos kenttä jätetään nollaksi käytetään oletusarvoa.

Mikäli kenttä on -1, niin käytetään suurinta sallittua arvoa.

14NSC85, s. SN:3-6/l 15NSC89, s. 25-34

(27)

Hyperkanava ja Netex Netex-ohjelmisto

bso,

MaxOutBlock

Tähän kenttään keirotaan suurin odotettu kirjoitettavan tiedon määrä. Jos kenttä jätetään nollaksi käytetään ole­

tusarvoa. Mikäli kenttä on -1, niin käytetään suurinta sallittua arvoa.

buf.

Buffer

Tähän kenttään asetetaan tiedonsiirtopuskurin alkuosoite.

cis, Class

Tämä kertoo käytettävän Netex-linjakurin tason. Kentässä saa käyttää vain joko arvoa nolla tai kaksi.

dmod, mod, DataMode

Tällä kentällä kerrotaan siirrettävän tiedon tyyppi, jotta automaattinen tiedonmuunnos tietäisi, miten tietoa tulee käsitellä. Mahdollisia aivoja ovat bittivirta (0), oktettitieto (1), 8-bittinen ASCII (2), EBCDIC (3), CDC:n BCD (4), Honeywellin BCD (5), UNIVACm Fieldata (6) ja CDC:n Display code (7).

hst,

HostName

Tähän kenttään laitetaan yhteyspyynnössä sen koneen nimi, johon halutaan ottaa yhteyttä. Jos kenttä täytetään välilyönneillä, otetaan sisäinen yhteys tähän koneeseen.

ind, Indication

Tämä kenttä kertoo, minkälainen vastaus saatiin tarjous- tai lukupyyntöön. Eri vaihtoehdot ovat: yhteys (1), kuittaus (2), tavallinen kirjoituskomennolla lähetetty paketti (3), sulku (5) ja katkaisu (6). Arvo 4 ei ole käytössä.

ios Tämä on käyttöjärjestelmäkohtainen tiedon syöttö- ja tulostustoimintojen tilakenttä.

len,

DataLength

Lähetettävän tiedon pituus sanoina. Huomaa, että eri lait­

teistoissa sanan pituus vaihtelee. Nykyään tämä pituus on lähes aina 8-bittiä eli oktetti, vaikka tietokoneen sanan pituus olisikin pidempi (tavallisesti 32 tai 64 bittiä). Katso myös kenttää ubc.

nam,

ProcessName

Tähän kenttään laitetaan korkeintaan kahdeksan merkkiä pitkä, aakkosnumeerinen prosessin tunnus. Sitä käytetään ohjaamaan istunnot oikealle prosessille.

nrf, Nref

Tämä on yhteyden tunnusnumero. Kenttä jätetään nollaksi yhteys tai tarjouspyynnöissä ja istuntoja hoitava ohjelma täyttää tunnuksen siihen, kun istunto syntyy. Tämän jälkeen kenttää ei saa muuttaa.

18

(28)

Hyperkanava ja Netex Netex-ohjelmisto

nrs, Status

Palvelupyynnön tilakenttä. Tämä on -1, jos pyynnön palvelu on kesken, ja 0, jos pyyntö palveltiin virheettä.

Mikäli palvelupyyntöä suoritettaessa tapahtui virhe, on tässä kentässä positiivinen virhekoodi.

obf,

ODataAddress

Tähän laitetaan oktettitietopuskurin16 alkuosoite.

obs, obl, ODataLength

Tässä kerrotaan oktettitiedon pituus. Kirjoitettaessa siihen laitetaan kirjoitettavan tiedon pituus ja luettaessa puskurin pituus. Luvun päätyttyä kentässä on saapuneen oktettitie­

don pituus.

osd Tämä on Netex-ohjelman työaluetta. Sitä ei saa muuttaa.

rat, MaxRate

Tähän kenttään voi esittää toivomuksen tiedonsiirron nopeudesta. Yksikkönä on tuhat bittiä sekunnissa. Jos kenttään laitetaan nolla, niin silloin käyttäjä haluaa mah­

dollisimman nopean yhteyden. Istunnon muodostuttua istunto-ohjelmisto täyttää kenttään käytettävän tiedon­

siirtonopeuden.

req,

UserRequest

Tämä kertoo palvelupyynnön tyypin; onko se synkroninen vai asynkroninen ja onko se tyyppiä yhteys, kuittaus, kirjoitus, sulku, katkaisu, tarjous vai luku.

rsl Kenttä on varattu tulevia ohjelmistomuutoksia varten.

rs2 Kenttä on varattu tulevia ohjelmistomuutoksia varten.

rs3 Kenttä on varattu tulevia ohjelmistomuutoksia varten.

rsu Kenttä on varattu UX-funktioiden käyttöön.

tmo, Timeout

Kenttä kertoo, miten monta sekuntia luku- tai tarjous­

pyyntö odottaa vastausta. Jos annetaan nolla, niin odo­

tetaan ikuisesti.

ubc,

UnusedBits

Tämä kenttä kertoo montako bittiä viimeisestä lähetettä­

västä sanasta ei kuulu itse tietoon. Tällä voidaan lähettää tietoa muuttamatta bittiäkään eri sananpituuden tietoko­

neiden kesken. Katso myös kenttä Ien.

Taulukko 3: Netex-palvelutietorakenteen kentät

16Netex-istunnossa voidaan siirtää kahdenlaista tietoa: sovellustietoa (Pdata, presentation data) ja oktettitietoa (Odata, octet data). Sovellustieto muunnetaan siirrettäessä dmod-kentäs- sä olevan ohjeen mukaisesti, mutta oktettitiedon muotoon ei kosketa.

(29)

Hyperkanava ja Netex Netex-ohjelmisto

Palvelutietorakenne on nimensä mukaisesti vain Netexiä kutsuttaessa käytettä­

vä paikallinen parametrijoukko, jota ei koskaan kuljeteta verkon yli. Istunnon kummassakin päässä on oma palvelutietorakenteensa, eikä saman istunnon eri puoliskojen palvelu tieto rakenteilla ole välttämättä mitään yhteistä varsinkaan eri sana- tai tavupituutta käyttävissä järjestelmissä. Se on olemassa ainoastaan Netexiä käyttävän prosessin ja paikallisen Netex-ohjelman väliseen viestintään.

Tämä on luonnollista, kun muistetaan hyperkanavan päätarkoituksen olevan yhdistää jopa täysin eri arkkitehtuurisia järjestelmiä toisiinsa. Kussakin ympä­

ristössä voidaan käyttää sille ominaisia ohjelmointitapoja ja tiedon esitysmuoto­

ja, mikä parantaa järjestelmän tehokkuutta ja helpottaa sovellusten tekemistä.

Seuraavassa taulukossa17 on esitetty palvelutietorakenteen kenttien käyttö eri palvelupyyntötyypeissä:

17NSC85, s. 3-6

(30)

Hyperkanava ja Netex Nelex-ohjelmisto

tarjous yhteys kuittaus luku kirjoitus sulku katkaisu

Status R R R R R R R

Indication R D D R D D D

Data Length R S S R S S S

UnuscdBits R

s

S R S S S

Nref R R X X X X X

Buffer S S

s

S S S S

BufferLength S S

Datamode R S

s

R S S

s

Timeout S S

Class N N

MaxRate N N

MaxInBlock N N

MaxOutBlock N N

ODataAddress S S

s

S S S

s

ODataLength

c

S

s

C S S

s

ProcessName

c s

HostNamc R

s

selitykset:

R palautetaan Returned

D palautetaan katkaisun yhteydessä returned if Disconnected

S annetaan parametrina Specified

N annetaan parametrina mutta lopullinen arvo neuvotellaan

specified but Negotiated

C annetaan parametrina mutta sisältö muuttuu

specified but Changed

X vain luku sallittu, ei saa muuttaa read only Taulukko 4: Palvelutietorakenteen kenttien käyttö palvelupyynnöissä

(31)

Istuntojen luokittelujärjestelmä Istuntojen luokittelu

3. Istuntojen luokittelujärjestelmä

3.1. Istuntojen luokittelu

Netex-istunto on aina kahden prosessin välinen viestien vaihtoketju. Prosessit ovat kuten mitkä tahansa kaksi oliota, joilla on tavoitteena vaihtaa jotakin tie­

toa. Viestijöiden tavoitteet voivat toteutua joko kokonaan, osittain tai ei ollen­

kaan. Tavoitteiden toteutumisaste vaikuttaa merkittävästi istunnon jatkokäsit­

telyyn:

Valvontajärjestelmä on kiinnostunut pääasiassa kesken olevista ja osittain tai ei ollenkaan onnistuneista istunnoista. Onnistuneet istunnot on jätetty valvontajär­

jestelmän ulkopuolelle, koska valvonnan tehoa huonontaa liika informaatio. Jos halutaan jättää jokin merkki onnistuneesta istunnosta valvontajärjestelmään se on mielestäni lyhyen ajan tilastointia, eikä valvontaa sinänsä. Netex-ympäris- tön erikoispiirre, jossa vasta päättyneen istunnon siirtämän tiedon määrä saa­

daan selville, vielä korostaa onnistuneiden istuntojen tilastointiluonnetta. Aino­

astaan onnistuneet istunnot tuottavat volyymitietoa tiedonsiirrosta, joka on erittäin tärkeää laskutus- ja seurantamekanismeille, mutta turruttaa valvojat no­

peasti.

Tilastointijärjestelmän päähuomion kohteena ovat kaikki päättyneet istunnot ja niiden yritykset, vaikka verkon käytön laskutusosa käsitteleekin ainoastaan täy­

sin onnistuneita istuntoja. Epäonnistuneiden istuntojen tilastointia voidaan pe­

rustella sillä, että halutaan seurata verkon luotettavuutta. Tilastointijärjestel­

mällä ei sen sijaan ole mitään mielenkiintoa kesken olevia istuntoja kohtaan.

22

(32)

Istuntojen luokittelujärjestelmä Istuntojen luokittelu

Seuraavassa kuvassa jaetaan neljä istuntopääluokkaa tilastoinnin ja valvonnan kesken:

Kuva 5: Istuntoluokkien jatkokäsittely

Käytännössä istunnot jaetaan eri luokkiin tarkastelemalla niiden tapahtumien järjestyksiä. Tapahtumiahan ovat kaikki seitsemän UX-funktio tyyppiä: alustus, lopetus, tarjous, yhteys, kuittaus, valmis ja katkaisu. Käsittely helpottuu, kun otetaan huomioon, että vain tapahtumat valmis ja katkaisu voivat joko onnis­

tua tai epäonnistua. Muut viisi jakautuvat nekin kahteen eri tyyppiin. Alustus ja lopetus kertovat koko Netex-ohjelman alustuksesta ja lopetuksesta. Ne siis liit­

tyvät istuntoihin kollektiivisesti. Kummankaan tapahtuman jäljiltä ei ole Netex- istuntoja kesken, vaan kaikki keskeneräisiin istuntoihin liittyvät tietorakenteet voidaan alustaa. Tarjous, yhteys ja kuittaus taas ovat vain indikaatioita istun­

non tilan muutoksista ja ovat sinänsä aina onnistuneita. Soveltamalla näitä omi-

(33)

Istuntojen luokittelujärjestelmä Istuntojen luokittelu

naisuuksia ja Netex-istunnon dokumentoitua kulkua saadaan rakennettua seu- raava taulukko, johon on luokiteltu erilaiset istuntotyypit niiden sisältämien ta­

pahtumien lajin ja järjestyksen mukaan:

onnistunut istunto (kaksi erilaista)

1.1 TARJOUS, VALMIS, KUITTAUS, KATKAISU tai

1.2 YHTEYS, VALMIS, KATKAISU Lisäksi VALMIS ja KATKAISU ovat onnistuneet.

osittain onnistunut is­

tunto

(kaksi erilaista)

2.1 TARJOUS, VALMIS, KUITTAUS, KATKAISU tai

2.2 YHTEYS, VALMIS, KATKAISU Lisäksi VALMIS on onnistunut ja KATKAISU on epäonnistunut.

kesken oleva istunto (viisi erilaista)

3.1 TARJOUS

3.2 TARJOUS, VALMIS, jossa VALMIS on onnistunut

3.3 TARJOUS, VALMIS, KUITTAUS, jossa VALMIS on onnistunut

3.4 YHTEYS

3.5 YHTEYS, VALMIS, jossa VALMIS on onnistunut

epäonnistunut istunto (kuusi erilaista)

4.3.1 tilasta 3.1 ulos kaaviosta 4.3.2 tilasta 3.2 ulos kaaviosta 4.3.3 tilasta 3.3 ulos kaaviosta 4.3.4 tilasta 3.4 ulos kaaviosta 4.3.5 tilasta 3.5 ulos kaaviosta

4 heti ulos kaaviosta

Taulukko 5: Istuntojen luokittelu

Valmis-ja katkaisu-tapahtumat voivat olla joko onnistuneita tai epäonnistunei­

ta, koska ne ovat istunto-ohjelman antamia indikaatioita istunnon tilan muutok­

sista. Tarjous-, kuittaus- ja yhteys-tapahtumat onnistuvat aina, koska ne ovat osa istunto-ohjelmalle annettujen palvelupyyntöjen käsittelyä. Valmis- tai kat- kaisutapahtuman onnistuminen nähdään istunnon palvelutietorakenteen paluu-

24

(34)

Istuntojen luokittelujärjestelmä Istuntojen luokittelu

koodikentästä.18 Lisäksi, jos katkaisussa ilmoitettu siirretyn tiedon määrä on molempiin suuntiin nolla, on tiedon siirto todennäköisesti epäonnistunut. Täl­

löin ei vika välttämättä ole tiedonsiirtojärjestelmässä, vaan siirto voi epäonnis­

tua jos siirrettävät tiedostot tai hakemistot puuttuvat. Ne voivat olla myös tois­

ten sovellusten varaamia. Kenties tilaa tiedoston kirjoittamiseen ei ole riittäväs­

ti. Näissä kaikissa tapauksissa tiedonsiirtoistunto on sujunut hyvin, mutta so­

vellus ei. Siten on perusteltua käsitellä tällainen katkaisu epäonnistuneena.

Seuraavasta kuvasta nähdään, miten istunnon luokka voidaan määrittää jäsen­

tämällä istunnon tapahtumaketjua samalla kun istuntoon liittyviä uusia tapahtu­

mia saadaan selville. Kuvassa olevassa jäsennyspuussa edetään juuresta lehtiin päin kunnes siirrytään pois jäsennyspuusta tai päädytään johonkin äärimmäisis­

tä lehdistä.

Kuva 6: Istuntojen jäsennys

18Katso taulukosta "Netex-palvelutietorakenteen kentät" sekä liitteenä olevan Netex-palvelu- tietorakenteen C-kielisestä kuvauksesta kenttä nrbnrs.

(35)

Istuntojen luokittelujärjestelmä Istuntojen luokittelu

Kuvassa lähdetään ratkaisemaan istunnon luokkaa juuresta eli tilasta neljä.

Kaaviossa edetään tilasta toiseen seuraamalla istuntotapahtumanuolia. Mikäli jostakin tilasta ei mikään sopiva nuoli johda pois, on istunto epäonnistunut ja asetetaan luokkaan neljä.

Luokassa neljä on kaksi erikoisistuntotyyppiä: alustus ja lopetus. Kumpikin koostuu yhdestä tapahtumasta, joka ilmoittaa kyseisen verkkosolmun Netex- ohjelmiston joko aloittaneen toimintansa tai lopettaneen sen. Kun tällainen is­

tunto tulee valvontajärjestelmän näköpiiriin, on päätettävä kaikki kyseiseen ko­

neeseen kesken olleet istunnot. Lisäksi nämä erikoisistunnot on ilmaistava val- vontaohjelmIstossa näkyvästi.

Luokan neljä istunnot voidaan luokitella edelleen tarkemmin sen mukaan mikä oli se tila, josta jouduttiin kaaviosta ulos. Esimerkiksi, jos heti ensimmäinen is­

tunnon tapahtuma on katkaisu, on istunto luokkaa neljä. Mikäli istunnon tapah­

tumaketju oli tarjous-kuittaus-katkaisu on se luokkaa 4.3.1. Tällä tarkemmalla luokittelulla saadaan luokan neljä istunnot jaettua kymmeneen aliluokkaan.

Näistä aliluokista kuitenkin hylätään ne neljä, jotka jatkaisivat jo katkaisutapah- tumaan johtanutta tapahtumaketjua. Niissä tapauksissa olisi suuri vaara sotkea jo päättyneen istunnon kirjanpitoa jonkin jälkeenpäin sattuneen virheen takia, joten hylkäämme aliluokat 4.1.1, 4.1.2, 4.2.1 ja 4.2.2. Jäljelle jääneet aliluokat

on esitetty taulukossa Istuntojen luokittelu.

26

(36)

Istuntojen luokittelujärjestelmä Istunnon tunniste

3.2. Istunnon tunniste

Eri istunnot erotellaan toisistaan yhdistämällä kolme eri tietoa yhdeksi, yksikä­

sitteiseksi istunnon tunnisteeksi. Tunnisteen rungon muodostaa Netex-ohjel- man istunnolle antama numero (NRF).19 Se ei kuitenkaan kelpaa sellaisenaan ainoaksi tunnisteeksi, koska eri laitteiden Netex-ohjelmat saattavat käyttää sa­

moja numeroita istunnoissaan ja samankin laitteiston Netex-ohjelma alkaa tois­

taa istuntonumeroita käynnistyttyään uudelleen. Niinpä tunnisteeseen lisätään sen koneen hyperkanavanimi, jossa istuntoa tarkkaillaan. Tämä nimi on kor­

keintaan kahdeksan merkkiä pitkä kirjain- ja numeroyhdistelmä. Viimeiseksi li­

sätään tunnisteeseen istunnon ensimmäisen tapahtuman aikaleima.

Edellä esitetystä kolmiosaisesta istunnon tunnisteesta voidaan jättää istunnon ensimmäisen tapahtuman aikaleima pois. Tämän yksinkertaisemman tunnisteen etuna on huomattavasti vaivattomampi ylläpito. Tällöin on kuitenkin mahdollis­

ta, että Netex-ohjelmiston alustamisen tai istunnon numeron uudelleenkäytön vuoksi eri istunnoille muodostuu samanlainen tunniste. Se on kuitenkin lyhyellä tarkasteluvälillä harvinaista. Niinpä valvontajärjestelmä, joka ei muutenkaan säilytä istuntotietoa pitkään, voi käyttää tätä yksinkertaisempaa kaksiosaista is­

tunnon tunnistetta ja pidemmän ajan tilastoinnissa käytetään kolmiosaista, täy­

sin yksikäsitteistä tunnistetta.

19Katso taulukosta "Netex-palvelutietorakenteen kentät" sekä liitteenä olevan Netex-palvelu- tietorakenteen C-kielisestä kuvauksesta kenttä nrbnrf.

(37)

Istuntojen luokittelujärjestelmä Istunnot valvontajärjestelmän kannalta

3.3. Istunnot valvontajärjestelmän kannalta

Istuntojen luokittelua voidaan käyttää hyväksi valvontajärjestelmässä monin eri tavoin. Istunto täytyy jossakin vaiheessa päästää pois valvontajärjestelmän pii­

ristä. Toisaalta valvontajärjestelmän olennainen osa on Käyttöjärjestelmä, siis se tapa, jolla kiinnostavat tiedot saadaan esille massatiedosta. Siinä auttaa tie­

don järjestäminen ryhmiin. Edellä esittämäni istuntoluokat ovat istunnoille juuri tällainen järjestäjä.

Valvontajärjestelmä seuraa lyhyellä aikavälillä kaikkia istuntoja joista sillä on tietoa. Jottei säilytettävän tiedon määrä kasva liian suureksi, on lopulta päätet­

tävä, mistä tiedosta on pakko luopua uuden tilan saamiseksi. Edellä jo totesin, että valvontajärjestelmä on kiinnostunut pääasiassa muista kuin onnistuneista istunnoista. Ensimmäinen käsittelysääntö onkin luopua ensiksi vanhimpien, on­

nistuneiden istuntojen tiedoista, koska näiden kiinnostavuus on pienin. Seuraa- vaksi luovumme vanhojen osittain onnistuneitten istuntojen tiedoista, sillä nii­

den joukossa on myös tarkoituksellisesti keskeytettyjä istuntoja. Sitten seuraa kesken olevat istunnot ja lopuksi epäonnistuneet istunnot. Epäonnistuneiden is­

tuntojen tiedoista luovutaan viimeksi, koska ne ovat aina odottamattoman ti­

lanteen aiheuttamia.

Käytännössä on pakko määritellä tarkemmin, mitä ovat vanhimmat tiedot.

Vuorokautta vanhempi istunto on vanha, ja sen tiedoista luovutaan edellä esite­

tyn suunnitelman mukaan. Lisäksi, koska mikään valvontajärjestelmässä oleva istunto ei ole yli vuorokautta vanhempi, voidaan näytöissä jättää päivämäärät pois ja käsitellä vain kellonaikoja. Valvontajärjestelmän istuntokapasiteetin on

28

(38)

Istuntojen luokittelujärjestelmä Istunnot valvontajäijestelmän kannalta

oltava niin suuri, ettei koko käytettävissä oleva istuntotila täyty viimeisen vuo­

rokauden epäonnistuneiden istuntojen tiedoista.

Valvontajärjestelmän näyttöjä voidaan rakentaa istuntojen luokituksen mukaan.

Olen hahmotellut kahta eri tapaa näyttää istuntoja. Toisessa viimeisimmät is­

tunnot näkyvät aikajärjestyksessä ja istunnon luokka ilmaistaan värillä tai taus­

takuvalla. Tämän näyttötavan etuna on ajan kulun helppo seuranta. Tapahtu­

mien syy-seuraussuhde on helppo nähdä. Siirto tulkitaan aina tapahtuvaksi yh­

teydenottajasta tarjouksen antajaan, vaikka todellinen hyötytieto voi siirtyä kumpaan suuntaan tahansa tai vaikka molempiin suuntiin.

штттттттт

lllilllllilllllliiilill11111111111

мшшшшшм

.^44%%v.v.v.v.v.%ssx.«.:w:.:.:.

NETEX-valvontajärjestelmä: tiedonsiirrot 12.4.1996 21.59

aika I mistä (ohjelma) I minne (ohjelma) I tila I lähetetty1 I vastaanotettu I siirtonopeus

0934 I VAX3 () I 0K088 (BFXJS) I oo I 0 (0) I 0 (0) I 0 Mbit/s

1012 I 0K088 (2214Z-01) I VAX3 (ОРТОНPR) I о I 4 (168) I 13 (133 935) I 1,53 Mbit/s 1027 I 0K088 (2218Z-01) I VAX3 (VOTTOHPR) I о I 4 (168) I 7 (33 639) I 1,07 Mbit/s

Шpii iSl

Kuva 7: Valvontanäyttö, jossa aikajärjestys

Toinen tapa on asettaa eri istuntoluokat näytön eri osiin. Tällöin on vaikeampi hahmottaa istuntojen tilamuutosten tapahtuma-aikojen suhdetta toisiinsa. Toi-

(39)

Istuntojen luokittelujärjestelmä Istunnot tilastointijärjestelmän kannalta

saalia, jos olemme kiinnostuneita ainoastaan tietyntyyppisistä istunnoista, on tällaisesta näytöstä helpompi etsiä haluamaansa tietoa. Valvontajärjestelmän näytöissä on pystyttävä valitsemaan kumpi tahansa esitetyistä tavoista näyttää istuntotietoa.

Ш1Р

ISIS

■pl

¡lili.

N ETEX-valvontajärjestelmä: tiedonsiirrot lajeittain 12.4.1996 21.57 li.

Kesken Osittaiset Epäonnistuneet

'li!

0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 ¡III 0952 VAX1 -> VAX2 43234 0952 VAX1 -> VAX2 43234 0952 VAX1 -> VAX2 43234

Jill

1027 VAX2 -> VAX1 556 1027 VAX2 -> VAX1 556 1027 VAX2 -> VAX1 556 II 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234

0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 ЩЩ

0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234

0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 lili 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234

III

0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234

ill

0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 1:11 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 III 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 0922 VAX1 -> VAX2 43234 Hf

siili

ттттттттттж

Kuva 8: Valvontanäyttö, jossa tapahtumat lajeittain

3.4. Istunnot tilastointijärjestelmän kannalta

Tilastoja pidetään kaikesta muusta paitsi keskeneräisestä istuntotiedosta. Tämä tilastoinnin kattavuus johtuu ennen kaikkea tilastoinnin jatkuvasti muuttuvasta luonteesta. Aina tulee uusia tiedon tarpeita, jolloin tarvitaan jotain sen tyyppis­

tä tietoa, minkä keräämiseen ei ole edeltä varauduttu. Tällöin on hyvä, että kai­

kesta mahdollisesta on kerätty tiedot talteen. Tietoa on myös säilytettävä usei-

30

(40)

Istuntojen luokittelujärjestelmä Istunnot tilastointijärjestelmän kannalta

den vuosien ajalta, koska niitä voidaan tarvita erilaisissa selvittelyissä (rikokset, ohjelmistovirheet, jne.).

Tilastoja voidaan tehdä hyvin erilaisiin tarkoituksiin. Helposti luulisi, että ver­

kon käytön laskutukseen tarvitaan vain täysin onnistuneiden istuntojen tietoja.

Kuitenkin asiakas saattaa vaatia hyvitystä epäonnistuneista istunnoista, mikäli epäonnistuminen johtui tiedonsiirtopalvelun tuottajan virheestä. Tällöin epäon­

nistuneiden istuntojen tilastoja tarvitaan laskutuksen tukena.

Ylläpidolle voi olla tärkeää raportoida pelkästään osittain tai täysin epäonnistu­

neista istunnoista. Jos epäonnistumisista voidaan osoittaa jokin tietty kellonai­

ka, päivä, vuodenaika, laitteisto tai jokin muu yhteinen tekijä, voi siitä olla hyö­

tyä ongelman syyn selvittämisessä.

Yhteenvetona voidaan todeta, että tilastojen raakatieto on talletettava mahdol­

lisimman täydeUisenä muuttuvia tarpeita varten. Tieto on myös säilytettävä luo­

tettavasti useiden vuosien ajan.

(41)

Istuntotason valvonta- ja tilastointiohjelmisto Ohjelmiston toimintaympäristö

4. Istuntotason valvonta- ja tilastointiohjelmisto

4.1. Ohjelmiston toimintaympäristö

FD Finanssidata Oy:n tietojenkäsittelylaitteisto koostuu kymmenistä eri valmis­

tajien eri kokoisista tietokoneista ja niiden oheislaitteista. Oheislaitteet vaihtele- vat levykeasemista suurtehotulostimiin. Laitteistoja käytetään ja niitä valvotaan ympäri vuorokauden. Jotta saavutettu palvelutaso voidaan säilyttää yhä vähe­

nevällä työntekijäjoukolla on valvontaohjelmIstoja jatkuvasti kehitettävä pa­

remmiksi.

Millainen sitten on parempi valvontaohjelmisto? Usean vuoden aikana on mo­

nissa operointi- ja valvontaympäristön kehitysprojekteissa selkiytynyt joukko hyvän valvontajärjestelmän ominaisuuksia. Luonnollisesti ne ovat usein ristirii­

taisia, joten aina joudutaan valitsemaan useista hyvistä ominaisuuksista ne, joi­

den kehittämiseen keskitytään.

Hyvä valvontajärjestelmä toimii poikkeustilanteissakin. Huonompia esi­

merkkejä ovat järjestelmät, jotka tukehduttavat järjestelmän poikkeustilanteis­

sa. Käytännössä suuri osa valvontajärjestelmistä toimii poikkeustilanteissa huo­

nosti, toisin sanoen, ne on suunniteltu toimimaan, kun levytilaa on riittävästi, tietoliikenneverkko ei ole tukossa, keskusyksikkö ei ole ylikuormittunut, näyt­

töruudulla on tilaa uusille ikkunoille ja kirjoittimen paperi ei lopu koskaan.

Käytännön valvontaympäristössä on aina pula resursseista. Siksi valvontajärjes­

telmän jokaisessa osassa on huolehdittava, ettei se omalla toiminnallaan vaikeu­

ta tai jopa ehkäise virheen korjaamista.

32

(42)

Istuntotason valvonta- ja tilastointiohjelmisto Ohjelmiston toimintaympäristö

Hyvä valvontajärjestelmä hälyttää ajoissa, tehokkaasti ja oikein. Nämä ominaisuudet ovat vielä vaikeampia saavuttaa kuin edellinen poikkeustilanteis­

sa toimivuuden vaatimus. Hälytysrajojen ylityttyä hälytys saadaan mahdollisim­

man ajoissa, kun varmistetaan, että hälytyksen tekeminen vaatii mahdollisim­

man vähän resursseja. Resursseilla tarkoitan tässä keskusyksikköä, muistia, le­

vytilaa ja kaikkia muitakin tietojenkäsittely-ympäristön resursseja. Tämä vaati­

muksen täyttäminen on luonnollisesti sitä vaikeampaa, mitä korkeamman tason työkaluilla valvontajärjestelmää kehitetään. On joka tapauksessa hyvä etsiä jo­

kaisesta kehitystyökalusta esiin sen taloudelliset ja tuhlailevat ohjelmointitavat.

Poikkeustilanteissa on usein välittömästi pulaa resursseista. Mikäli valvontaoh­

jelma on ohjelmoitu samoilla työkaluilla samoja ohjelmointitapoja käyttäen kuin muut sovellukset se joutuu kilpailemaan sovellusohjelmien kanssa samoista re­

sursseista eikä ehkä saa hälytystä perille.

Hälytyksen tehokkuus on hyvin suhteellinen käsite. Mikäli hälytettävänä on ih­

minen, tekevät yksilölliset erot tehokkaan hälyttämisen vaikeaksi. Joku voi ko­

kea hälytyksen liian tehokkaana ja liian tehokas hälytys ärsyttää. Esimerkiksi kovaääninen puhesyntetisaattori jäi lyhytaikaiseksi kokeiluksi. Liian tehokas hälytys, mikäli se ei toistu liian usein, on kuitenkin huomaamatonta hälytystä parempi. Hälytysjärjestelmän suunnittelussa on aina muistettava pitää yhteyttä valvontahenkilökunnan kanssa. Heillä on pitkäaikaista käytännön kokemusta eri valvomojärjestelmien parissa ja he osaavat usein neuvoa hälytysjärjestelmän kehittäjää. Turhat hälytykset johtavat hyvin nopeasti koko järjestelmän hyl­

käämiseen. Loppujen lopuksi käyttäjät määrittelevät mikä on siedettävä häly­

tysten määrä ja mitkä ovat toimivat hälytysrajat.

Viittaukset

LIITTYVÄT TIEDOSTOT

Saksassa on säädetty laki työriitojen sovittelusta, mutta siinä todetaan, että valtiolliset sovintopalvelut ovat niiden työmarkkinaosapuolten käytettävissä, jotka sitä

Osittaisen hinnan mallissa toteuttajatiimin valinta tapahtuu kuiten- kin ilman, että suunnitelma viedään lopulliseen muotoonsa ja yhteiskehittäminen jatkuu vielä ennen

Ryhmillä oli vastuu myös osaamisen pitkäjänteisestä kehittämisestä ja suuntaa- misesta niin, että aluetaso miellettiin käytännössä yleisesti ennemminkin ryhmien osaamisen

Vuonna 1996 oli ONTIKAan kirjautunut Jyväskylässä sekä Jyväskylän maalaiskunnassa yhteensä 40 rakennuspaloa, joihin oli osallistunut 151 palo- ja pelastustoimen operatii-

Tornin värähtelyt ovat kasvaneet jäätyneessä tilanteessa sekä ominaistaajuudella että 1P- taajuudella erittäin voimakkaiksi 1P muutos aiheutunee roottorin massaepätasapainosta,

Lähetettävässä sanomassa ei ole lähettäjän tai vastaanottajan osoitetta vaan sanoman numero. Kuvassa 10.a on sanoman lähetyksen ja vastaanoton periaate. Jokin anturi voi

Sahatavaran kuivauksen simulointiohjelma LAATUKAMARIn ensimmäisellä Windows-pohjaisella versiolla pystytään ennakoimaan tärkeimmät suomalaisen havusahatavaran kuivauslaadun

(Hirvi­Ijäs ym. 2017; 2020; Pyykkönen, Sokka & Kurlin Niiniaho 2021.) Lisäksi yhteiskunnalliset mielikuvat taiteen­.. tekemisestä työnä ovat epäselviä