FI104600B - Kuormitustilanteen valvonta palvelutietokantajärjestelmässä - Google Patents
Kuormitustilanteen valvonta palvelutietokantajärjestelmässä Download PDFInfo
- Publication number
- FI104600B FI104600B FI963371A FI963371A FI104600B FI 104600 B FI104600 B FI 104600B FI 963371 A FI963371 A FI 963371A FI 963371 A FI963371 A FI 963371A FI 104600 B FI104600 B FI 104600B
- Authority
- FI
- Finland
- Prior art keywords
- measurement
- counter
- list
- measurement period
- service
- Prior art date
Links
- 238000012544 monitoring process Methods 0.000 title claims description 6
- 238000005259 measurement Methods 0.000 claims description 186
- 238000000034 method Methods 0.000 claims description 56
- 238000012545 processing Methods 0.000 claims description 35
- 230000008569 process Effects 0.000 claims description 31
- 230000008859 change Effects 0.000 claims description 30
- 230000004044 response Effects 0.000 claims description 3
- 238000012360 testing method Methods 0.000 description 35
- 230000004913 activation Effects 0.000 description 29
- 230000006870 function Effects 0.000 description 27
- 230000007704 transition Effects 0.000 description 15
- 238000007726 management method Methods 0.000 description 10
- 230000011664 signaling Effects 0.000 description 8
- 230000001960 triggered effect Effects 0.000 description 5
- 238000006243 chemical reaction Methods 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 238000011084 recovery Methods 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 108091006146 Channels Proteins 0.000 description 1
- 241000252067 Megalops atlanticus Species 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000003213 activating effect Effects 0.000 description 1
- 238000007792 addition Methods 0.000 description 1
- 230000002730 additional effect Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 238000000151 deposition Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 238000012384 transportation and delivery Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
- G06F11/3419—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment by assessing time
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/835—Timestamp
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/86—Event-based monitoring
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/88—Monitoring involving counting
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99942—Manipulating data structure, e.g. compression, compaction, compilation
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Monitoring And Testing Of Exchanges (AREA)
- Telephonic Communication Services (AREA)
- Alarm Systems (AREA)
- Debugging And Monitoring (AREA)
- Exchange Systems With Centralized Control (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
104600
Kuormitustilanteen valvonta palvelutietokantajärjestelmässä
Keksinnön ala 5 Keksintö liittyy yleisesti palvelutietokantajärjestelmään, ja erityisesti menetelmään, jonka avulla voidaan valvoa kuormitustilannetta palvelutietokantajärjestelmässä. Erään edullisen sovelluskohteen muodostavat älyverkon palvelutietokantajärjestelmät.
10 Keksinnön tausta
Telekommunikaation nopea kehitys on tehnyt mahdolliseksi sen, että operaattorit voivat tarjota käyttäjille monia eri tyyppisiä palveluja. Kehittyneitä palveluja tarjoavaa verkkoarkkitehtuuria kutsutaan älyverkoksi, josta käytetään yleisesti lyhennettä IN (Intelligent Network).
15 Älyverkon toiminnallista arkkitehtuuria on esitetty kuviossa 1, jossa verkon toiminnalliset oliot (functional entities) on esitetty ovaaleina. Seuraavassa tätä arkkitehtuuria kuvataan lyhyesti, koska keksintöä kuvataan jatkossa viitaten älyverkkoympäristöön.
Loppukäyttäjän (tilaajan) pääsystä verkkoon huolehtii CCAF-toiminto 20 (Call Control Agent Function). IN-palveluihin pääsy toteutetaan olemassaoleviin digitaalisiin keskuksiin tehtävillä lisäyksillä. Tämä tehdään käyttämällä hyväksi yleistä puhelun tilamallia BCSM (Basic Call State Model), joka kuvaa sitä olemassaolevaa toiminnallisuutta, jolla kahden käyttäjän välinen puhelu prosessoidaan. BCSM on korkean tason tila-automaattikuvaus niistä puhe-25 linohjaustoiminnon (CCF, Call Control Function) toiminnoista, joita tarvitaan käyttäjien välisen yhteysreitin pystyttämiseen ja ylläpitoon. Tähän tilamalliin lisätään toiminnallisuutta palvelun kytkentätoiminnon SSF (Service Switching Function) avulla (vrt. olioiden CCF ja SSF osittainen päällekkäisyys kuviossa ·, 1), jotta voidaan päättää, milloin on kutsuttava älyverkon palveluja (eli IN- 30 palveluja). Kun näitä IN-palveluja on kutsuttu, huolehtii älyverkon palvelulogiikan sisältävä palvelun ohjaustoiminto SCF (Service Control Function) palve-lusidonnaisesta (puheluyrityksen) käsittelystä. Palvelun kytkentätoiminto SSF liittää siis puhelunohjaustoiminnon CCF (Call Control Function) palvelun ohjaustoimintoon SCF (Service Control Function) ja sallii palvelun ohjaus-: 35 toiminnon SCF ohjata puhelunohjausta CCF. SCF voi esim. pyytää, että 2 104600 SSF/CCF suorittaa määrättyjä puhelu- tai yhteystoimintoja, esim. laskutus- tai reititystoimenpiteitä. SCF voi myös lähettää pyyntöjä palveludatatoiminnolle SDF (Service Data Function), joka huolehtii pääsystä älyverkon palvelusidon-naisiin tietoihin ja verkkotietoihin. SCF voi näin ollen esim. pyytää SDF:ää ha-5 kemaan tiettyä palvelua koskevia tietoja tai päivittämään näitä tietoja.
Edellä esitettyjä toimintoja täydentää vielä erikoisresurssitoiminto SRF (Specialized Resources Function), joka tarjoaa sellaisia erikoiskeinoja, joita vaaditaan joidenkin älyverkon tarjoamien palvelujen toteuttamiseksi. Esimerkkejä tällaisista ovat protokollamuunnokset, puheentunnistus, ääni-ilmoitukset, 10 jne. SCF voi esim. pyytää SSF/CCF-toimintoja luomaan ensin yhteyden loppukäyttäjien ja SRF:n välillä ja sen jälkeen pyytää SRF:ää antamaan ääniviestejä loppukäyttäjille.
Muita älyverkon toiminnallisia olioita ovat erilaiset hallintaan liittyvät toiminnot, joita ovat SCEF (Service Creation Environment Function), SMF 15 (Service Management Function) ja SMAF (Service Management Access Function). SMF käsittää mm. palvelujen hallinnan, SMAF tarjoaa liitynnän SMF:ään ja SCEF mahdollistaa älyverkon palvelujen määrittelyn, kehityksen, testauksen ja syötön SMF.n kautta SCF:Ile. Koska nämä toiminnot liittyvät ainoastaan verkon operaattorin toimintaan, ei niitä ole esitetty kuviossa 1.
20 Seuraavassa kuvataan vielä lyhyesti kuviossa 1 esitettyjen toiminnal listen olioiden roolia IN-palvelujen kannalta. CCAF vastaanottaa kutsuvan osapuolen antaman palvelupyynnön, joka muodostuu tyypillisesti kuulokkeen nostosta ja/tai tietystä kutsuvan osapuolen valitsemasta numerosarjasta. CCAF välittää palvelupyynnön edelleen CCF/SSF:lle prosessointia varten. Puhe-25 lunohjaustoiminnolla CCF ei ole palvelutietoja, mutta se on ohjelmoitu tunnistamaan palvelupyynnöt. CCF keskeyttää puhelunmuodostuksen hetkeksi ja ilmoittaa palvelun kytkentätoiminnolle SSF tiedon puhelun tilasta. SSF:n tehtävänä on, käyttäen ennalta määrättyjä kriteerejä, tulkita palvelupyyntö ja näin .· ollen määrittää, onko kysymyksessä älyverkon palveluihin liittyvä palvelu- 30 pyyntö. Mikäli näin on, SSF muodostaa standardoidun IN-palvelupyynnön ja lähettää pyynnön SCF:lle yhdessä palvelupyynnön tilaa koskevan informaation kanssa. SCF vastaanottaa pyynnön ja dekoodaa sen. Tämän jälkeen se toimii yhdessä SSF/CCF:n, SRF:n ja SDF:n kanssa pyydetyn palvelun antamiseksi loppukäyttäjälle.
? 35 Älyverkon fyysisen tason arkkitehtuuri kuvaa sitä, kuinka edellä 3 104600 kuvatut toiminnalliset oliot sijoittuvat verkon fyysisiin olioihin. Älyverkon fyysistä arkkitehtuuria on havainnollistettu kuviossa 2, jossa fyysiset oliot (physical entities) on kuvattu suorakaiteina tai ympyröinä ja toiminnalliset oliot ovaaleina. Merkinantoyhteyksiä on kuvattu katkoviivoilla ja varsinaista hyötyliikennettä 5 (transport), joka on esim. puhetta, yhtenäisillä viivoilla. Optionaalisia toiminnallisia olioita on merkitty katkoviivalla. Kuviossa esitetty signalointi-verkko on signalointijärjestelmän numero 7 mukainen verkko (SS7, Signalling System Number 7 on tunnettu signalointijärjestelmä, jota kuvataan CCITT:n (nykyisin ITU-T) sinisessä kirjassa Specifications of Signalling System No. 7, 10 Melbourne 1988).
Tilaajalaitteet SE (Subscriber Equipment), joita voivat olla esim. puhelin, tietokone tai telefax, kytkeytyvät joko suoraan palvelun kytkentäpisteeseen SSP (Service Switching Point) tai verkkoliittymäpisteeseen NAP (Network Access Point).
15 Palvelun kytkentäpiste SSP tarjoaa käyttäjälle pääsyn verkkoon ja hoitaa kaikki tarvittavat valintatoiminnot. SSP pystyy myös havaitsemaan älyverkon palvelupyynnöt. Toiminnallisesti SSP sisältää puhelunhallinta- ja palve-lunvalintatoiminnot.
Verkkoliittymäpiste NAP on puhelunohjaustoiminteen CCF sisältävä 20 perinteinen puhelinkeskus, esim. hakijan DX 220 -keskus, joka osaa erottaa älyverkon palveluja tarvitsevat puhelut perinteisistä puheluista ja reitittää älyverkon puheluja tarvitsevat puhelut asiaankuuluvalle SSPille.
Palvelun ohjauspiste SCP (Service Control Point) sisältää ne palveluohjelmat, joita käytetään tuottamaan älyverkon palveluja.
25 Palveludatapiste SDP (Service Data Point) on tietokanta, joka sisältää asiakkaan ja verkon dataa, jota SCP:n palveluohjelmat käyttävät tuottaakseen yksilöityjä palveluja. SCP voi käyttää SDP:n palveluja suoraan tai merkinantoverkon välityksellä.
.· Älykäs oheislaite IP (Intelligent Peripheral) tarjoaa erityistoimintoja, 30 kuten tiedonantoja sekä ääni- ja monivalintatunnistusta.
Palvelun kytkentä- ja ohjauspiste SSCP (Service Switching and Control Point) koostuu SCPistä ja SSPistä yhdessä solmussa (eli jos kuviossa esitetyssä SSP-solmussa on sekä SCF- että SSF-oliot, on kysymyksessä SSCP).
* 35 Palvelun hallintapisteen SMP (Service Management System) tehtäviin 4 104600 kuuluu tietokannan (SDP) hallinta, verkon valvonta ja testaus sekä verkkotietojen keräys. Se voi kytkeytyä kaikkiin muihin fyysisiin olioihin.
Palvelun luontiympäristön pistettä SCEP (Service Creation Environment Point) käytetään älyverkon palvelujen määrittelyyn, kehittelyyn ja testauk-5 seen ja syöttämään palvelut SMP:lle.
Palvelun liitännäisohjain AD (Adjunct) vastaa toiminnallisesti palvelun ohjauspistettä SCP, mutta se on kytketty suoraan SSP.hen nopealla datayhteydellä (esim. ISDN 30B+D-liittymä), eikä yhteiskanavamerkinantoverkon SS No.7 kautta.
10 Palvelusolmu SN (Service Node) voi ohjata älyverkon palveluja ja suorittaa tiedonsiirtoa käyttäjien kanssa. Se kommunikoi suoraan yhden tai useamman SSP:n kanssa.
SMAP (Service Management Access Point) on fyysinen olio, joka tarjoaa tietyille käyttäjille yhteyden SMP:hen.
15 Edellä on lyhyesti kuvattu älyverkkoa taustaksi keksinnön mukaisen menetelmän kuvaukselle. Kiinnostunut lukija voi saada tarkemman käsityksen älyverkosta esim. ITU-T:n suosituksista Q.121X tai Bellcoren AIN-suo-situksista.
Kuten edellä esitettiin, SSF lähettää SCF:lle standardoituja IN-20 palvelupyyntöjä tietyissä vaiheissa puhelunmuodostusta. Koska palvelun ohjauspiste SCP (tai palvelun liitännäisohjain AD) on tyypillisesti verkon keskitetty solmu, joka palvelee useita puhelinkeskuksia, on myös tärkeää suorittaa jatkuvasti erilaisia kuormitusmittauksia tällaisen keskitetyn palvelupisteen tietokannassa. Esim. SCP (tai AD) voidaan jakaa tällaisten 25 mittausten kannalta toiminnallisiin osiin kuvion 3 mukaisesti. Alimman kerroksen muodostaa ns. platform-kerros 31, joka sisältää laitteiston ja peruskäyttöjärjestelmän (esim. Unix). Platform-kerroksen päällä on sovelluskohtainen kerros 32, joka voidaan jakaa kolmeen osaan: palvelutietokantaan (SDB, Service Data Base) 32a, 30 palvelulogiikkaohjelmalohkoon (SLP, Service Logic Programs) 32b ja mittausohjelmalohkoon (MP, Measurement Programs) 32c. Palvelulogiikkaohjelmat ovat niitä ohjelmia, jotka liipastuvat solmuun tulevista palvelupyynnöistä ja tarjoavat varsinaisen IN-palvelun. Nämä ohjelmat suorittavat siis prosessointityötä kutsukohtaisesti. Mittausohjelmalohko on 35 puolestaan se kokonaisuus, joka hoitaa SCP:n kuormitukseen liittyvää 5 TOA600 prosessointia. Mittausohjelmalohko ei siis suorita työtään kutsukohtaisesti kuten palvelulogiikkaohjelma, vaan se suorittaa operaationsa esim. mittausväleittäin tai tietyissä tilanteissa, esim. ylikuormitustilanteissa.
Palvelutietokannassa on tyypillisesti tietotauluja, joissa jokaisella 5 tilaajalla on oma rivinsä Ri (i=1,2,...n). Tilaajan tunniste OI on jokaisen rivin alussa avaimena. Keksinnön kannalta oleellisia ovat sellaiset tietotaulut, jotka liittyvät em. mittauksiin. Yhtä tällaista mittaustaulua vastaa mittauskohteiden ryhmä, jota kutsutaan (mittaus)moduuliksi. Usean mittausmoduulin mittaustaulut voidaan sijoittaa samaan tietotauluun tai mittausmoduulin 10 mittaustaulu voi muodostaa oman tietotaulunsa. Mittaustaululla tarkoitetaan siis moduulikohtaista tietojoukkoa, joka voi olla järjestelmässä tietotaulun osa tai kokonainen tietotaulu. Mittausmoduulia kutsutaan jatkossa myös mittausryhmäksi.
Kullakin tilaajalla on järjestelmässä tilaajakohtaiset laskurit, joita 15 kasvatetaan niihin liittyvien tapahtumien seurauksena, esim. kutsumäärälaskuria kasvatetaan kutakin kutsua kohti. Laskureista kootaan lukuarvot mittausväleittäin.
Kuviossa 3 on havainnollistettu menetelmän sovellusympäristöä käyttäen edelleen esimerkkinä älyverkon palvelun ohjauspistettä SCP. 20 Yleisesti ottaen voidaan kuitenkin todeta, että menetelmää voidaan soveltaa missä tahansa palvelutietokantajärjestelmässä, johon tulee satunnaisesti palvelupyyntöjä, joihin järjestelmä antaa vastauksen. Seuraavassa kuvataan tällaista ympäristöä yleisesti rajoittumatta pelkästään älyverkon SCP-solmuun.
Jotta tuleviin palvelupyyntöihin voitaisiin antaa vastauksia, on 25 prosessorin, jolla on pääsy tietokantaan suoritettava palvelukohtaista prosessointia. Palvelupyyntöihin liittyvät (mittaus)kohteet (eli (mittaus)objektit) muodostuvat tietokantajärjestelmän tietotaulujen yksittäisistä riveistä, joita prosessori käsittelee. Järjestelmässä talletetaan pyyntöjen lukumäärät ja tietyt tapahtumat määrätyn pituisten mittausaikavälien aikana.
30 Kohteet voidaan luokitella kohdeluokkiin siten, että kussakin luokassa 9 kaikki kohteet ovat samaa tyyppiä (esim. tilaajia), kun tilannetta tarkastellaan niiden tapahtumien kannalta, joita talletetaan. Saman tyyppisistä kohteista voidaan muodostaa mittausryhmä ja kunkin kohdeluokan sisällä voidaan määritellä useampi kuin yksi mittausryhmä. Mittausryhmän sisällä kuhunkin 35 kohteeseen liittyy laskureita, joilla tapahtumia talletetaan. Laskuriarvot voivat 6 104600 vaihdella kohteesta toiseen, mutta tietyn tapahtuman tulkinta on samanlainen jokaisen kohteen osalta, tietyt tapahtumat voivat esim. merkitä numeromuunnospyyntöä jokaisen tilaajan (eli kohteen) kohdalla.
Mittaukseen liittyvä toiminnallisuus käsittää seuraavanlaisia 5 tallennustoimintoja riippumatta siitä, minkälaisessa ympäristössä palvelutietokantajärjestelmä on.
Jokaisen pyynnön saapuessa luodaan palvelulogiikkaproseduurista dedikoitu ilmentymä, halutun kohteen datarivi haetaan tietotaulusta ja vaadittava palvelulogiikkaprosessointi suoritetaan. Mittausryhmässä jokaiseen 10 yksittäiseen datariviin liittyy laskuriryhmä, jolla erilaisten tapahtumien esiintyminen talletetaan. Palvelulogiikkaprosessoinnin aikana kasvatetaan laskuriarvoja talletettaviksi haluttavien tapahtumien esiintymisen mukaisesti.
Lisäksi on edullista, jos sama prosessori voidaan asettaa hoitamaan palveluprosessointia, tapahtumien talletukseen liittyviä toimintoja (laskurien 15 kasvatusta) ja laskuriarvojen talletusta useiden eri mittausryhmien osalta. Laskuriarvojen talletuksella tarkoitetaan sitä, että laskurien arvot haetaan säännöllisin väliajoin, jotta ne voidaan kirjoittaa muistiin (lokitiedostoon) tai lähettää ulkopuoliseen järjestelmään prosessointia varten. Käytännössä yhden prosessorin käyttö saattaa olla jopa ainoa vaihtoehto. Tämä johtuu siitä, että 20 palvelupyyntöihin liittyy useinkin tiukat vasteaikavaatimukset, jolloin tietokanta on toteutettava RAM-muistiin (ei levylle). Kaikissa kaupallisissa tietokonejärjestelmissä ei ole edes mahdollista, että useammalla kuin yhdellä prosessorilla olisi pääsy samaan RAM-muistiin. Usealle prosessorille yhteinen RAM-muisti on myös vaikea toteuttaa, koska joudutaan huolehtimaan siitä, 25 ettei synny päällekkäisiä muistioperaatioita.
Tällaisissa tietokantajärjestelmissä ylikuormituksen rajoitusmenetelmä tarvitsee lähes reaaliaikaista tietoa siitä, mihin rajoituksen alaisiin kohteisiin kohdistuu eniten kutsuliikennettä.
Konventionaalisissa palvelutietokantajärjestelmissä on eniten 30 kutsuttuja kohteita koskevat listat muodostettu erillisen prosessorin avulla mittaustietojen käsittelyn yhteydessä (hallintajärjestelmässä sen jälkeen, kun mittaustiedot on ensin siirretty sinne). Näin ollen kuormitustilanteesta saatu kuva ei ole ollut aina riittävän hyvin reaaliaikainen.
35 Keksinnön yhteenveto 7 104600
Keksinnön tarkoituksena on eliminoida edellä mainittu epäkohta ja aikaansaada menetelmä, jossa mittaustiedot saadaan entistä paremmin reaaliajassa.
Tämä päämäärä saavutetaan keksinnön mukaisella menetelmällä, 5 joka on määritelty itsenäisissä patenttivaatimuksissa.
Keksinnön ajatuksena on ylläpitää tietokannassa mittauskohteita rivi riviltä käsittelevän talletus- ja nollausprosessin avulla listaa niistä kohteista, joihin kohdistuu eniten kutsuja. Ylläpito hoidetaan siten, että yksittäisen rivinkäsittelyn yhteydessä verrataan rivillä olevan laskurin arvoa listan sillä 10 hetkellä pienimpään arvoon ja suoritetaan päivitys, mikäli arvo on suurempi kuin mainittu pienin arvo. Ajatuksena on siis yhdistää eniten kutsuttujen kohteiden määrittäminen siihen nollauskäsittelyyn, joka mittausväleittäin tehdään kunkin kohteen kutsumäärälaskurille. Eniten kutsuttujen kohteiden määrittäminen saadaan näin ollen toteutettua mittausryhmän muodossa 15 talletus- ja nollausprosessin avulla. Samalla periaatteella voidaan muodostaa vähiten kutsuttujen lista.
Jos esim. tietotaulun tuhannesta puhelinnumerosta 50 on sellaisia, joihin voi tulla runsaasti liikennettä esim. tietyn kampanjan aikana, määritellään siis yksi mittausryhmä, johon otetaan nämä 50 kohdetta. Tälle 20 mittausmoduulille määritellään lyhyt mittausväli, esim. 1 minuutti. Lisäksi ko. moduulille voidaan määritellä, että lokitietueita ei tehdä lainkaan, vaan ko. moduulin tapauksessa talletus- ja nollausprosessi suorittaa ainoastaan nollausta ja eniten kutsuttujen listan päivitystä.
Huomattakoon, että vaikka tässä yhteydessä puhutaan talletus- ja 25 nollausprosessista, tarkoitetaan sillä prosessia, joka hoitaa sekä laskuriarvojen talteenottoa että niiden nollausta. Laskuriarvoja ei välttämättä kirjoiteta heti lokitiedostoon, vaan laskuriarvot voidaan esim. lähettää ulkopuoliseen järjestelmään. Mittauskohteen yksittäisellä käsittelykerralla ei myöskään aina suoriteta sekä talteenottoa että nollausta, vaan molemmat voidaan ohittaa tai 30 suorittaa ainoastaan nollaus.
Kuvioluettelo
Seuraavassa keksintöä ja sen edullisia suoritusmuotoja kuvataan , tarkemmin viitaten oheisten kuvioiden 4-10 mukaisiin esimerkkeihin oheisissa 35 piirustuksissa, joissa 8 104600 kuvio 1 havainnollistaa älyverkon toiminnallista arkkitehtuuria, kuvio 2 havainnollistaa älyverkon fyysistä arkkitehtuuria, kuvio 3 havainnollistaa SCP-solmun tapahtumamittauksen kannalta oleellisia osia, 5 kuvio 4 havainnollistaa keksinnön mukaista palvelutietokanta- järjestelmää, kuvio 5a esittää aika-akselia, jolla on havainnollistettu kuvion 4 järjestelmässä noudatettavaa vuorotteluperiaatetta, kuvio 5b esittää aika-akselia, jolla on havainnollistettu yleistä 10 vuorotteluperiaatetta, jota noudatetaan kuvion 4 järjestelmässä, kuvio 6 on vuokaavio, joka esittää järjestelmän siirtymistä tyhjäkäyntitilasta normaaliin toimintatilaansa, ja kuviot 7a...Id muodostavat vuokaavion, joka kuvaa laskurien talletus-ja nollausprosessin kulkua, 15 kuviot 8, 9 10 ovat vuokaavioita, jotka havainnollistavat tarkemmin eniten kutsuttujen -listan muodostamisessa vaadittavia toimenpiteitä kuvioissa 7a...7d esitetyssä talletus- ja noilausprosessissa.
Keksinnön yksityiskohtainen kuvaus 20 Kuviossa 4 on havainnollistettu keksinnön mukaista tietokantajärjestelmää DBS, joka voi olla esim. älyverkon SCP-solmussa. Tietokanta sisältää ainakin yhden perustietotaulun BT ja ainakin yhden - · mittaustaulun MT, joissa on paljon peräkkäisiä rivejä. Kuviossa on esitetty yksi perustaulu ja kolme mittaustaulua.
25 Perustaulun yksi rivi vastaa yhtä mittauskohdetta (esim. tilaajaa).
Rivin alussa on kohteen tunniste OI. Samassa perustaulussa olevat kohteet kuuluvat samaan mittauskohdeluokkaan, toisin sanoen kaikki saman perustaulun kohteet ovat tyypiltään samanlaisia. Perustaulun yksi kohde voi ’·. sisältyä useaan eri mittaustauluun MT, esim. sama tilaaja voi olla mukana 30 kutsumäärämittauksessa, jossa mittausvälin pituus on esim. 5 min. ja kutsumäärämittauksessa, jossa mittausvälin pituus on esim. 24 tuntia.
Perustaulun jokaisella rivillä ovat lisäksi parametrit, jotka kertovat, mihin mittausryhmiin kyseinen kohde on sisällytetty aktiivisena. Jatkossa näiden parametrien tunnukset ovat ObjActj (j=1...mittausryhmien lukumäärä).
35 Parametrien arvot ovat käyttäjän aseteltavissa.
9 104600
Yksittäinen mittaustaulu käsittää otsikkorivin HR ja peräkkäisiä rivejä Ri (i=1...n). Mittaustaulun yhdellä rivillä Ri on kohdekohtaiset parametrit ja kohdekohtaiset laskurit. Kukin mittaustaulu muodostaa tietyn mittausryhmän edellä esitettyn tapaan. Kussakin mittaustaulussa ovat siis mukana ne kohteet, 5 joille suoritetaan samanlaista mittausta. Esim. kuvion yhdessä mittaustaulussa voisivat olla ne tilaajat, joille suoritetaan kutsumäärämittausta, toisessa ne tilaajat, joille suoritetaan jotakin tapahtumalaskurimittausta ja kolmannessa ne tilaajat, joille suoritetaan puhelunpituusmittausta. Kuten aiemmin todettiin, saman tyyppisestäkin mittauksesta (esim. kutsumäärämittauksesta) voi olla 10 useita eri mittaustauluja.
Mittaustaulun otsikkorivillä HR ovat ne parametrit, jotka ovat yhteisiä koko mittausryhmälle. Nämä parametrit kuvataan jäljempänä.
Keksinnön mukaisen menetelmän kannalta järjestelmän oleellinen osa on myös eniten kutsuttujen kohteiden lista (tai taulukko) TL, johon 15 mittausvälin kuluessa kerätään esim. kymmenen eniten kutsutun kohteen joukko. Tämän listan sisältö kirjoitetaan lajiteltuna sitä vastaavaan tietotauluun sen jälkeen, kun rivit on mittausvälin aikana käsitelty tai sen jälkeen, kun mittausvälin vaihtuessa havaitaan, että rivien käsittely jäi kesken juuri päättyneen mittausvälin aikana.
20 Palvelulogiikkaohjelmainstanssi SLPi lukee perustaulun BT rivejä, joten perustaulun riveillä on myös sellaisia parametreja, joita käytetään palvelun tuottamiseen. Koska ne eivät kuitenkaan kuulu tämän keksinnön piiriin, el niitä kuvata tässä yhteydessä tarkemmin.
SSP:n lähettämä palvelupyyntö SR sisältää tilaajan (kohteen) 25 tunnisteen. Kun SCP saa tällaisen palvelupyynnön luodaan palvelulogiikkaohjelmasta palvelulogiikkaohjelmailmentymä SLPi, joka ryhtyy palvelemaan ko. palvelupyyntöä. Tämä tehdään sinänsä tunnetulla tavalla siten, että järjestelmässä oleva palvelulogiikan suorituslohko SLE luo t · · palvelulogiikkailmentymän SLPi ottamalla kopion palvelulogiikkamalleista , 30 jotka on talletettu lohkoon SLPT. Tämä kopio (eli SLPi) asetetaan i vastaanotetun palvelupyynnön käyttöön. Palvelupyynnöt palvelulogiikan suorituslohko SLE noutaa puskurista BF, johon tulevat palvelupyynnöt talletetaan.
SLPi lukee palvelupyynnöstä tilaajan tunnisteen, minkä jälkeen se 35 pystyy lukemaan tunnistetta vastaavan rivin perustaulusta. Riviltä SLPi saa 10 104600 selville parametrien ObjActj (j=1,2...) arvot. Mikäli kohde on aktiivinen, SLPi lukee niiden mittaustaulujen otsikkoriveiltä, joissa kyseinen kohde on mukana, onko myös mittausryhmä aktiivinen. Tämä ilmoitetaan mittaustaulun otsikkorivillä olevalla parametrilla, jota kutsutaan jatkossa nimellä ActNew. Jos 5 sekä kohde että mittausryhmä ovat aktiivisia, SLPi kasvattaa mittaustaulun ko. kohteen rivillä olevan yhden tai useamman laskurin arvoa. Kuten kuviossa 4 esitetään, käyttäjä antaa parametrien ObjActj ja ActNew arvot hallintajärjestelmän (SMP) välityksellä. Koska jatkossa käsitellään parametria ObjAct mittausryhmäkohtaisesti, ei indeksiä j käytetä.
10 Mittaustaulun riveillä olevat laskurit on edullisesti kahdennettu siten, että riville muodostuu kaksi laskuriryhmää, joita on merkitty viitemerkeillä CG1 ja CG2. Ryhmissä on samat laskurit (yksi tai useampi) eli ryhmän kullakin laskurilla on vastaava laskuri toisessa ryhmässä. Laskureita kasvatetaan vuorovälein siten, että aika-akseli jaetaan kuvion 5a mukaisesti peräkkäisiin 15 mittausaikaväleihin TP, joista joka toista on merkitty viitemerkillä F ja joka toista viitemerkillä T. Mittausaikavälien F aikana kasvatetaan esim. laskuriryhmän CG1 laskureita ja mittausaikavälien T aikana laskuriryhmän CG2 laskureita (tai päinvastoin). Se kumpi aikaväli kulloinkin on kysymyksessä määritetään pariteettimuuttujalla, jota ylläpidetään mittaustaulujen 20 otsikkoriveillä. Lukiessaan mittaustaulun otsikkoriviä SLPi lukee myös pariteettiparametrin arvon, jolloin se tietää, kumpaa mittaustaulun rivillä olevaa laskuria sen on kasvatettava. Pariteettiparametri on Boolen muuttuja, joka voi • saada arvot T(rue) tai F(alse), mistä syystä joka toista aikaväliä on kuviossa merkitty viitemerkillä T ja joka toista puolestaan viitemerkillä F.
25 Palvelulogiikkaohjelmainstanssi SLPi hoitaa riveillä olevien tapahtumalaskureiden kasvattamista itsenäisesti, mikä tarkoittaa sitä, että se kasvattaa sokeasti laskureiden arvoja, mikäli havaitsee kyseisen mittausryhmän ja -kohteen aktiivisiksi. Mittausohjelmalohko hoitaa sen sijaan •j riveillä olevien laskureiden talletusta ja nollausta. Mittausohjelmalohkossa voi 30 olla omat alilohkonsa CRj jokaisen mittausryhmän laskurien talletusta ja nollausta varten. Lisäksi mittausohjelmalohko (tai alilohko CRj) määrää laskurien vaihtohetket vaihtamalla pariteetin arvoa jokaisen mittausvälin TP alussa. Niissä mittausaikaväleissä, joissa SLPi kasvattaa laskuriryhmän CG1 laskureita mittausohjelmalohko käsittelee laskuriryhmän CG2 laskureita, ja 35 niissä mittausaikaväleissä, joissa SLPi kasvattaa laskuriryhmän CG2 11 104600 laskureita mittausohjelmalohko käsittelee laskuriryhmän CG1 laskureita. Laskurien kasvatus (eli tapahtumien talletus) hoidetaan siis laskurien talletus-ja nollausprosessiin nähden erillisellä prosessilla, joka hyödyntää ainoastaan pariteettiparametrin arvoa tietämättä mitään muuta siitä, missä vaiheessa 5 laskurien talletusprosessi työskentelee. Jatkossa nimitetään niitä laskureita, joita kulloinkin kasvatetaan aktiivilaskureiksi ja niitä joiden arvoja talletetaan ja nollataan passiivilaskureiksi. Tietyn mittausaikavälin aikana kasvatetut laskuriarvot käsitellään siis kyseistä mittausaikaväliä seuraavan mittausaikavälin aikana, jolloin puolestaan kasvatetaan sitä laskurijoukkoa, jota 10 käsiteltiin edellisen mittausaikavälin aikana.
Järjestelmään kuuluu lisäksi oleellisena osana herätysajastin TM, jonka avulla asetetaan prosessori PR käynnistämään mittausohjelmalohko pienin väliajoin WP. Herätysaikavälin pituus voi olla esim. 10 sekuntia eli herätysaikaväli on hyvin lyhyt verrattuna mittausaikaväliin TP. Herätysajastin 15 tai -ajastimet voi(vat) olla mittausryhmäkohtaisia tai usealle mittausryhmälle yhteisiä.
Käyttäjän määrittämän parametrin avulla voidaan mittausryhmäkohtaisesti määritellä, kuinka monen kohteen laskurit enintään saadaan käsitellä yhdellä suorituskerralla eli yhtä herätystä kohti. Jos kaikkien 20 kohteiden passiivilaskurijoukot ehditään käsitellä mittausaikavälin kuluessa (eli siihen mennessä, kun todetaan uusi mittausvälin vaihtumishetki), asetetaan mittausryhmälle lippu merkiksi siitä, että kyseisen mittausaikavälin kuluessa ei * - enää tarvitse mennä käsittelemään mittausobjekteja. Vaikka siis laskurien talletus- ja nollausprosessi herätetäänkin edelleen tihein välein 25 herätysajastimen avulla, ei mittausobjekteja enää käsitellä.
Kuten edellä todettiin, on edullista, jos sama prosessori suorittaa sekä mittausohjelmaa että palvelulogiikkaohjelmaa SLPi. Kuviossa 4 tätä yhteistä prosessoria on merkitty viitemerkillä PR. Mittausohjelman suoritus • · ·: käynnistetään ajastimen TM avulla aina, kun aikaväli WP on kulunut.
30 Tietokanta tietotauluineen sekä mittausohjelma ja palvelulogiikkaohjelma voivat olla samassa RAM-muistissa, mutta järjestelmä voi olla myös sellainen, että tietokanta tietotauluineen on levyllä. Tällöin järjestelmässä on kaksi prosessoria siten, että toinen suorittaa palvelulogiikkaohjelmaa ja toinen käsittelee levyllä ylläpidettäviä laskuriarvoja. 35 Joka tapauksessa prosessoriin liittyy tietyt muistialueet MA1...MA3, joilla 12 104600 mittausohjelmalohko, palvelulogiikkaohjelmalohko sekä tietokanta tietotauluineen ovat. Palvelun suorituslohkon muistialuetta on merkitty viitemerkillä MA4 ja palvelulogiikkamallien muistialuetta viitemerkillä MA5. Kuten edellä kuitenkin mainittiin, on vasteaikojen kannalta edullista käyttää 5 RAM-muistia ja yhtä prosessoria.
Jos kaikkien kohteiden (tilaajien) passiivilaskurijoukkoja ei ehditä käsitellä, esim. prosessoriylikuorman takia, käytettävissä olevan mittausaikavälin TP kuluessa, jätetään loput kohteet käsittelemättä. Periaatteena on, että tekemättömän työn ei anneta kasautua. Proseduuri 10 merkitsee kuitenkin ne rivit, jotka on ehditty käsitellä. (Jos rivejä jää käsittelemättä, jäävät laskurit myös nollaamatta, eikä lokitiedostoon kyetä kirjoittamaan.) Palvelulogiikkaohjelmainstanssi kuitenkin kasvattaa sokeasti kaikkia laskureita, myös käsittelemätttä jääneillä riveillä. Näitä rivejä ei kuitenkaan voida käsitellä jatkossa, koska niiden arvot eivät enää ole 15 mittausaikavälin pituiselta ajalta, esim. 5 min. pituiselta ajalta. Kun mittausohjelma rupeaa käsittelemään rivejä, tarkistetaan erikseen, voiko laskuriarvon kirjoittaa lokitiedostoon. Laskuriarvoja kasvatetaan siis sokeasti, mutta seuraavassa käsittelyaikavälissä tarkistetaan, onko arvo kelvollinen kirjoitettavaksi lokitiedostoon vai ei.
20 Tiheästi toistuvien herätyksien avulla saadaan hoidettua eri mittausryhmien eripituiset mittausaikavälit. Järjestelmässä ei siis ole omaa laskuria (ajastinta) jokaiselle eripituiselle mittausaikavälille, joita eri mittausryhmillä on, vaan järjestelmässä on yksi ainoa laskuri, joka herättää mittausohjelman tiheästi, esim. 10 s välein. Jokaisella herätyskerralla 25 mittausohjelma tarkistaa, onko ruvettava käsittelemään kohdekohtaisia laskureita. Näin ollen voidaan esim. prosessorin ylikuormatilanteessa aina luottaa siihen, että jossain vaiheessa kuorman hellittäessä ajastin pääsee laukeamaan ja sen laukaisema talletus- ja nollausprosessi tietää, mitä ·: kulloinkin on tehtävä. Prosessorin jälkeenjääneisyys ratkaistaan siis tavalla 30 joka on helpompi kuin erillisten ajastimien käyttö. Erillisten ajastimien tapauksessa liiallisen prosessorikuorman aiheuttama myöhästyminen kostautuisi, koska ajastin asetetaan aina uudestaan saman aikavälin päähän. Tällöin pitäisi jollain tavalla hoitaa kellonajan ja laukeamishetkien välinen synkronointi.
35 Seuraavassa kuvataan niitä parametreja, jotka ovat oleellisia 13 104600 keksinnön mukaisessa järjestelmässä. Mittauskohderyhmälle yhteisiä parametreja, jotka ovat kunkin mittaustaulun MT otsikkorivillä, ovat:
PARAMETRI SELITYS_ TYYPPI
Moduleldentifier Mittausmoduulin tunniste_ I
Act__Käytössä oleva aktivointiparametri_ B
ActNew__Uusi aktivointiparametri__B_
Interv__Käytössä oleva mittausvälin pituus__I_
IntervNew__Uusi mittausvälin pituus__j_
LatlnterTime__Viimeisin välinvaihtumishetki__|_
SecondlnterTime Toiseksi viimeinen välinvaihtumishetki_ I
ThirdInterTime Kolmanneksi viimeinen välinvaihtumishetki I_
FollInterTime__Seuraava välinvaihtumishetki_ I
LatParityTime Viimeisin pariteetin vaihtumishetki__D_
PreParityTime Toiseksi viimeinen pariteetin vaihtumishetki D_
Parity__Pariteetti__B_
Batch__Kerralla käsiteltävien rivien lukumäärä_ I
TopList Parametri, joka kertoo, tehdäänkö B
mittausmoduulista eniten kutsuttujen __kohteiden lista._
LatFinished Parametri, joka kertoo, onko taulun kaikki rivit B
__käsitelty__
Parametrin tyyppiä on merkitty kirjaimella I siinä tapauksessa, että 5 kysymyksessä on kokonaislukumuuttuja, kirjaimella B siinä tapauksessa, että kysymyksessä on Boolen muuttuja sekä kirjaimella D siinä tapauksessa, että kysymyksessä on todellinen aikaleima (päivämäärä, tunnit, minuutit, sekunnit). Mittausvälin pituus ilmoitetaan minuutteina.
• Käyttäjän aseteltavissa ovat mittausryhmän aktivointiparametri 10 ActNew, mittausvälin pituus IntervNew sekä kerralla käsiteltävien rivien lukumäärä Batch. Muut taulukossa esitetyt parametrit ovat järjestelmän sisäisiä parametreja, jotka eivät ole käyttäjän aseteltavissa. Aikaleimat, jotka indikoivat viimeisimmän mittausaikavälin vaihtumishetken (LatlnterTime), sitä edellisen mittausaikavälin vaihtumishetken (SecondlnterTime) ja sitäkin 15 edellisen mittausaikavälin vaihtumishetkeä (ThirdlnterTime) sekä edessä 1A . 104600 14 olevan mittausaikavälin vaihtumishetken (FollInterTime) ovat edullisesti minuuttilukuindeksejä, joten ne ovat tyypiltään kokonaislukumuuttujia (johtuen siitä, että järjestelmässä käytetty aika on diskretoitu).
Viimeksi tapahtunut pariteetin vaihtumishetki (LatParityTime) ja sitä 5 edellinen pariteetinvaihtumishetki (PreParityTime) täytyy myös säilyttää, koska ne eivät yleensä ole samoja kuin mittausaikavälin määritellyt vaihtumishetket. Tämä johtuu siitä, että jos mittausohjelma käynnistyy esim. 10 s välein, pariteetin vaihtumishetki menee tyypillisesti muutaman sekunnin yli mittausaikavälin määritellystä vaihtumishetkestä. Viime mainittuja parametreja 10 tarvitaan näin ollen, jotta saadaan selville sen aikavälin tarkka pituus, jolta laskuriarvot ovat. Parametri LatFinished kertoo, koska mittaustaulun kaikki rivit on ehditty käsitellä loppuun (tallettaa ja nollata laskurit).
Mittaustaulun yksittäisellä rivillä on ainakin seuraavat mittauskohdekohtaiset parametrit:_
PARAMETRI SELITYS_ TYYPPI
ObjAct__Kohteen aktivointiparametri__B_
LatMade__Rivin viimeisin käsittelyaika__I_
PreMade__Rivin toiseksi viimeisin käsittelyaika__I_ 15
Rivikohtaiset aikaleimat (LatMade ja PreMade) ovat minuuttilukuindeksejä samoin kuin mittausvälinvaihtumishetkiä indikoivat parametrit. Rivikohtaisia aikaleimoja kutsutaan jatkossa leimoiksi P (PreMade) Y ja L (LatMade).
20 Kuviossa 4 on esitetty ne parametrit, jotka ovat kohderivillä ja mittausryhmän otsikkorivillä.
Kuviossa 6 on esitetty vuokaaviona järjestelmän siirtyminen tyhjäkäyntitilasta 600 normaaliin toimintatilaansa eli ns. lämpimään käynnistystään 700. Kun järjestelmä saa ns. kylmäkäynnistyssignaalin (vaihe ’! 25 601), asetetaan moduulikohtainen lippu (parametri Alive) nollaan indikoimaan, että on kysymyksessä kylmäkäynnistys (vaihe 602). Tämän jälkeen asetetaan vaiheessa 603 herätysajastin (TM, kuvio 4) laukeamaan lyhyen herätysaikavälin (WP, kuvio 5a) jälkeen, minkä jälkeen siirrytään lämpimään käynnistyskään 700.
30 Kuvioissa 7a...7d on esitetty vuokaaviona mittausohjelmalohkon suorittaman talletus- ja nollausprosessin kulkua. Kun prosessi on lämpimässä 15 104600 käynnistystilassa ja ajastin TM laukeaa (vaihe 701), lähtee laskurien talletus-ja nollausprosessi käyntiin. Viimeisessä vaiheessa asetetaan ajastin laukeamaan uudelleen (vaihe 745, kuvio 7d) ennalta määrätyn ajan kuluttua. Kun ajastin taas laukeaa, talletusprosessi käydään jälleen läpi ja viimeisenä vaiheena 5 asetetaan ajastin laukeamaan uudelleen. Kuten edellä kuvattiin, laukeamisten välinen aika voi olla esim. 10 sekuntia. Käytännössä proseduurin yksi suorituskerta mittaustaulun yhtä riviä kohti on luokkaa 50 ps, joten esim. käsiteltäessä 100 riviä kerrallaan kymmenessä eri moduulissa, kestää yksi suorituskerta luokkaa 50 ms.
10 Kun ajastin on lauennut siirrytään vaiheeseen 702, jossa haetaan kulumassa olevan ajan arvo sekä moduulin parametrit moduulin otsikkoriviltä. Kulumassa oleva ajanarvo on sama kuin ajastimen käynnistyshetki ja tämä ajanarvo pysyy samana koko sen ajan, minkä käynnistyksen aiheuttama yksi suorituskerta kestää. Ajanarvosta määritetään kulumassa oleva (current) 15 minuuttilukuindeksi (esim. laskettuna tietyn vuoden alusta). Mittaustaulun otsikkoriviltä noudetaan käyttäjän aseteltavissa olevien parametrien ActNew, IntervNew ja Batch arvot. Tämän jälkeen testataan vaiheessa 703a, onko kysymyksessä talousprosessin ensimmäinen käynnistys kylmäkäynnistys-signaalin jälkeen. Tämä tehdään testaamalla, onko em. moduulikohtaisen 20 lipun arvo nolla. Mikäli näin on, testataan vaiheessa 703b, onko käyttäjän aseteltavissa olevan moduulikohtaisen aktivointiparametrin ActNew arvo suurempi kuin nolla (eli onko moduuli aktivoitu). Mikäli ehto on tosi, annetaan mainitulle parametrille arvo ActNew=1, joka indikoi tuoretta käyttäjän suorittamaa moduulin aktivointia, ja käännetään kylmäkäynnistystä osoittava 25 lippu pois päältä eli annetaan parametrille Alive arvo yksi (vaihe 704). Vaiheeseen 704 tullaan siis vain kylmäkäynnistyksen kautta ja moduulin ollessa aktiivinen. Muussa tapauksessa siirrytään vaiheesta 703a tai 703b vaiheeseen 705, jossa testataan, onko kyseessä oleva moduuli jatkuvasti • < ·: passiivisena (mittausta ei ole aktivoitu). Tämä tehdään testaamalla, onko 30 käytössä oleva aktivointiparametri Act pienempi tai yhtäsuuri kuin nolla ja käyttäjän asettama aktivointiparametri ActNew myös pienempi tai yhtä suuri kuin nolla (eli onko moduulin aktivointiparametrin vanha arvo nolla ja myös uusi arvo nolla). Mikäli näin on (eli moduuli on jatkuvasti passiivinen), ohjelma etenee suoraan vaiheeseen 745, jossa herätysajastin TM asetetaan 35 laukeamaan uudelleen.
16 104600
Mikäli näin ei ole, edetään vaiheeseen 706, jossa testataan, onko moduuli mahdollisesti muutettu laskurien talletus- ja nollausprosessin edellisen herätyskerran jälkeen passiiviseksi (mittaus pysäytetty). Tämä tehdään testaamalla, onko käytössä oleva aktivointiparametri Act suurempi kuin nolla ja 5 käyttäjän asettama aktivointiparametri ActNew pienempi tai yhtäsuuri kuin nolla. Mikäli näin on, asetetaan käytössä olevalle aktivointiparametrille arvo nolla. Tämä tehdään vaiheessa 708, mutta tähän vaiheeseen voidaan kuitenkin edetä vain silloin, kun ajanhetki on laskurien arvojen talletus- ja nollausprosessin kannalta sovelias ko. muutoksen tekemiseen. Tätä soveliasta 10 hetkeä testataan vaiheessa 707, jossa testataan, onko kaikki rivit saatu käsiteltyä tai onko mahdollisesti ohitettu seuraava mittausaikavälin vaihtumishetki. Tämä tehdään testaamalla, onko parametrilla LatFinished arvo yksi tai onko käynnistyksen yhteydessä määritetyn parametrin CurrentMinute arvo suurempi tai yhtä suuri kuin parametrin FollInterTime arvo, joka ilmoittaa 15 seuraavan odotettavissa olevan välinvaihtumishetken. Kun mittausmoduuli on pysäytetty vaiheessa 708 asettamalla käytössä oleva aktivointiparametri nollaksi, siirrytään suoraan loppuun, jossa asetetaan ajastin laukeamaan uudelleen.
Jos muutoshetki ei ole vielä sovelias tai moduulia ei oltu pysäytetty (eli 20 moduuli on aktiivinen), vaiheessa 709 testataan, onko moduuli mahdollisesti muutettu edellisen suorituskerran jälkeen aktiiviseksi eli onko moduuli käynnistetty edellisen herätyskerran jälkeen. Tämä tehdään testaamalla, onko käyttäjän asettama aktivointiparametri ActNew pienempi kuin sata (käyttäjän suorittama aktivointi vastaa arvoa yksi, joka yksi indikoi siis sitä, että moduulia 25 ollaan aktivoimassa). Jos näin on, eli moduuli on käynnistetty edellisen herätyskerran jälkeen, siirrytään initialisointivaiheeseen 710. Muussa tapauksessa siirrytään vaiheeseen 711, jossa testataan, onko mittausaikavälin pituus vaihtunut.
Edellä esitetyssä vaiheessa 704 asetetaan siis käyttäjän määräämä 30 aktivointiparametri ActNew keinotekoisesti arvoon yksi, jotta kaikissa tarpeellisissa tapauksissa päästäisiin vaiheesta 709 initialisointivaiheeseen 710. Tällainen tilanne voi olla esim. kahdennetussa tietokonejärjestelmässä tapahtuva puolen vaihto. Varapuolen käynnistyessä (kyimäkäynnistys) varmistetaan tällä tavalla, että talousprosessi etenee initialisointivaiheeseen 35 710 myös, jos käyttäjän määrittämällä moduulikohtaisella aktivointiparametrilla 17 104600 on ollut puolten vaihdon tapahtuessa sellainen arvo, joka tarkoittaa aktiivitilaa (arvo 1 tai 101 tässä esimerkkitapauksessa). Puolten vaihto ei siten vaadi mitään lisätoimenpiteitä, vaan järjestelmä käyttäytyy myös siinä tapauksessa, että mittausryhmä on ollut aktiivinen aivan kuin käyttäjä olisi juuri aktivoinut 5 mittausryhmän.
Initialisointivaiheessa 710 annetaan käytössä olevalle aktivointiparametrille Act käyttäjän määräämän parametrin ActNew arvo, käytössä olevan mittausaikavälin pituuden kertovalle parametrille Interv annetaan parametrin IntervNew arvo, jonka käyttäjä määrää, ja käyttäjän 10 määräämän aktivointiparametrin arvoa kasvatetaan sadalla, jotta vaiheessa 709 huomataan, että enää tämän jälkeen ei ole kysymyksessä juuri tapahtunut moduulin aktivointi. Lisäksi aikaleimoille LatlnterTime, SecondlnterTime sekä ThirdlnterTime ja FollInterTime annetaan arvo, joka on sen hetkinen aika (currentMinute) pyöristettynä ylöspäin seuraavaan tasaminuuttiin.
15 Moduulikohtaiset parametrit on siis initialisoitava käynnistyshetkeä myöhäisempään ajanhetkeen. Tällaisella oikealla initialisoinnilla aikaansaadaan mm. se, että kaikki vanhat rivikohtaiset aikaleimat ovat vanhempia tai yhtäsuuria kuin välinvaihtumishetket, jolloin myös ne epäyhtälöt (kuvataan jäljempänä), jotka määräävät, kirjoitetaanko lokitiedostoon vai ei 20 ovat oikealla tavalla tosia tai epätosia, riippumatta esim. siitä, missä vaiheessa kohdekohtainen mittaus käynnistetään.
Pariteettimuuttujalle Parity annetaan initialisointivaiheessa arvo nolla ja parametrille LatFinished arvo yksi, jotta moduulin käynnistystä seuraavan ensimmäisen vajaan minuutin aikana ei käsiteltäisi mittaustaulun rivejä. Lisäksi 25 järjestelmässä pidetään yllä tietoa kahdesta viimeksi tapahtuneesta pariteetin vaihtumishetkestä. Näille parametreille (LatParityTime ja PreParityTime) annetaan initialisointivaiheessa aikaleima, joka osoittaa sen hetkistä oikeaa aikaa (pvm, tunnit, minuutit, sekunnit).
·; Vaiheessa 711 testataan, kuten aiemmin mainittiin, onko 30 mittausaikavälin pituus vaihtunut. Tämä tehdään testaamalla, onko uusi arvo (IntervNew) yhtä suuri kuin vanha arvo (Interv). Mikäli näin on (eli muutosta ei ole tapahtunut), siirrytään suoraan vaiheeseen 716, jossa testataan, onko odotettavissa oleva mittausaikavälin vaihtumishetki jo saavutettu tai ohitettu.
Mikäli käyttäjä on muuttanut mittausaikavälin arvoa, päivitetään 35 mittausaikavälille sen uusi arvo vaiheessa 713 ja lasketaan seuraavaksi 18 104600 edessä oleva mittausaikavälin vaihtumishetki vaiheessa 715. Nämä toimenpiteet tehdään kuitenkin vain silloin, kun kulumassa oleva ajanhetki on sovelias toimenpiteiden suorittamiseen. Tämä soveliaisuus testataan vaiheessa 712 suorittamalla samanlainen testi kuin vaiheessa 707.
5 Toimenpiteet (vaiheen 713 päivitys) voidaan siis suorittaa vain jos kulumassa olevan mittausvälin aikana on jo ehditty käsitellä kaikki rivit tai jos seuraava mittausaikavälin vaihtumishetki (joka on laskettu mittausaikavälin vanhan pituuden perusteella tai joka on moduulin käynnistyksen tapauksessa initialisoitu seuraavaan tasaminuuttiin vaiheessa 710) on saavutettu tai 10 ohitettu. Mikäli jompi kumpi näistä ehdoista täyttyy, päivitetään mittausaikavälin pituudelle sen uusi arvo vaiheessa 713. Ennen kuin mittausaikavälin edessä olevan vaihtumishetken päivitys (vaihe 715) voidaan suorittaa on kuitenkin täytettävä yksi lisäehto, joka testataan vaiheessa 714. Tässä vaiheessa testataan, onko ensimmäinen täyden minuutin vaihtuminen ohitettu moduulin 15 aktivoinnin jälkeen. Tämä testi suoritetaan testaamalla, onko parametrin FollInterTime arvo sama kuin parametrin LatlnterTime arvo (arvot ovat samoja siihen asti, kunnes ensimmäisen tasaminuutin jälkeinen ensimmäinen herätyskerta tapahtuu; parametria FollInterTime päivitetään heti, kun ensimmäinen tasaminuutti on ylitetty, kuten jäljempänä havaitaan). Mikäli arvot 20 ovat erisuuret, on ensimmäinen minuutti ohitettu ja voidaan suorittaa edessä olevan vaihtumishetken päivitys. Moduulin käynnistyshetken jälkeen ensimmäinen välinvaihtumishetki (FollInterTime) asetetaan siis aina ensimmäisen tasaminuutin kohdalle ja vasta sen jälkeen esim. tasatunteihin, jos uuden mittausaikavälin pituus on tunti. Tämä ensimmäinen 25 välinvaihtumishetki (ensimmäinen tasaminuutti) on siis se ajanhetki, johon välinvaihtumishetkiä indikoivat aikaleimat initialisoitiin vaiheessa 710. Ensimmäinen vajaa minuutti moduulin käynnistämisen jälkeen halutaan olla kokonaan käsittelemättä rivejä. Tätä varten asetettiin parametrille LatFinished arvo ykkönen vaiheessa 710. Tämä johtuu siitä, että rivikohtaiset 30 käsittelyleimat asettuvat kuitenkin seuraavaan minuuttilukemaan, jolloin ensimmäisen vajaan minuutin aikana tapahtuneesta rivien käsittelystä ei ole hyötyä (koska rivikohtaisesta leimasta ei siinä tapauksessa tiedettäisi, onko se vanha vai uusi eli onko se peräisin käynnistystä edeltävältä ajalta vai käynnistyksen jälkeiseltä ajalta). Moduulin aktivoinnin jälkeinen rivien käsittely 35 (laskuriarvojen talletus ja nollaus) aloitetaan siis vasta ensimmäisen * ,9 104600 tasaminuutin jälkeen.
Edessä olevalle välinvaihtumishetkelle lasketaan (vaihe 715) uusi estimaatti siten, että ensin jaetaan sen hetkinen minuuttilukema (currentMinute) mittausvälin pituudella ja otetaan jakojäännös muistiin. Uusi 5 estimaatti saadaan, kun sen hetkisestä minuuttilukemasta vähennetään saatu jakojäännös ja erotukseen lisätään mittausvälin pituus (eli FolllnterTime:=CurrentMinute-mod(CurrentMinute/lnterv)+lnterv). Edessä oleva vaihtumishetki määritetään siis kulumassa olevan kellonajan ja mittausvälin pituuden perusteella. Laskennassa ei siis oteta huomioon 10 parametrin LatlnterTime arvoa, koska esim. ylikuormitustilanteessa prosessori on saattanut jäädä jälkeen, jolloin vastaava jälkeenjääneisyys näkyisi myös edessä olevan vaihtumishetken arvossa.
Tämän jälkeen testataan vaiheessa 716, onko odotettavissa oleva mittausvälin vaihtumishetki jo saavutettu. Tämä tehdään testaamalla, onko 15 parametrin CurrentMinute arvo (eli kellonajasta otettu minuuttilukema, kun sekunteja ei huomioida) suurempi tai yhtä suuri kuin parametrin FollInterTime arvo. Mikäli näin ei ole, edetään suoraan vaiheeseen 720. Muussa tapauksessa edetään kohti vaihetta 718, jossa liuotetaan välinvaihtumishetkiä koskevia aikaleimoja eteenpäin. Tällöin viimeisimmän mittausaikavälin 20 vaihtumishetken ilmoittava parametri LatlnterTime saa arvon CurrentMinute-mod(CurrentMinute/lnterv), sitä edellisen mittausaikavälin vaihtumishetken ilmoittava parametri SecondlnterTime saa parametrin LatlnterTime entisen arvon ja kolmanneksi viimeisen mittausaikavälin vaihtumishetken ilmoittava parametri ThirdInterTime saa parametrin SecondlnterTime entisen arvon. 25 Tässä yhteydessä ei siis sijoiteta parametrin LatlnterTime arvoksi parametrin FollInterTime arvoa (eli ohitetun välinvaihtumishetken arvoa), vaan parametrin LatlnterTime arvo lasketaan em. tavalla kulumassa olevan minuuttilukeman perusteella, jotta mahdollinen prosessorin jälkeenjääneisyys ei vaikuttaisi parametrin arvoon. Parametrin LatlnterTime päivitetään siis arvoon, joka on 30 kulumassa oleva kellonaika pyöristettynä alaspäin tasaminuuttilukemaan, vähennettynä mainitulla jakojäännöksellä, jonka arvo on yleensä nolla ja joka kompensoi mahdollisen jälkeenjääneisyyden.
Aikaleimoja ei kuitenkaan liu’uteta eteenpäin, jos vaiheessa 716 havaittu välinvaihtumishetken havaitaan olevan se välinvaihtumishetki, joka on 35 moduulin aktivoinnin jälkeinen ensimmäinen tasaminuutti. Tämä testataan 20 104600 vaiheessa 717 samanlaisella testillä kuin edellä vaiheessa 714 (eli jos parametrin FollInterTime arvo ei ole tässä vaiheessa yhtäsuuri kuin parametrin LatlnterTime arvo, ensimmäinen tasaminuutti on ylitetty moduulin aktivoinnin jälkeen).
5 Vaiheessa 718 tapahtuvan aikaleimojen liputuksen jälkeen tai vaiheessa 717 tehdyn testin jälkeen siirrytään vaiheeseen 718b, jossa suoritetaan eniten kutsuttujen listan muodostukseen liittyviä toimenpiteitä, joita kuvataan tarkemmin jäljempänä kuviossa 8.
Listan muodostukseen liittyvien toimenpiteiden jälkeen lasketaan 10 vaiheessa 719 uusi arvo odotettavissa olevalle välinvaihtumishetkelle (eli FolllnterTime=CurrentMinute-mod(CurrentMinute/lnterv)+lnterv). Tämä suoritetaan myös siinä tapauksessa, että vaiheessa 717 havaittiin, että välinvaihtumishetki olikin moduulin aktivoinnin jälkeinen ensimmäinen tasaminuutti. Vaiheessa 719 vaihdetaan myös pariteetin arvo ja liputetaan 15 viimeisimmän ja toiseksi viimeisimmän pariteetinvaihtumishetken aikoja eteenpäin, jolloin parametri LatParityTime saa sen hetkisen todellisen aikaleiman arvon ja parametri PreParityTime saa parametrin LatParityTime entisen arvon. Koska lisäksi rivien käsittely on edessä, annetaan parametrille LatFinished tässä vaiheessa arvo nolla, jotta järjestelmä huomaa, että rivien 20 käsittely on kesken. Huomattakoon myös, että vaikka rivien käsittely olisikin kesken ja huomataan, että välinvaihtumishetki on ohitettu, resetoidaan parametri LatFinished uudelleen nollaksi.
Tämän jälkeen testataan vaiheessa 720 (johon voitiin tulla myös suoraan vaiheesta 716), onko rivien käsittelyvaihe valmis eli onko kaikki rivit jo 25 käsitelty. Mikäli näin on, siirrytään suoraan vaiheeseen 745, jossa asetetaan ajastin uudelleen. Mikäli rivien käsittely on kesken tai ei ole vielä alkanutkaan (eli parametrilla LatFinished on arvo nolla), edetään vaiheeseen 721, jossa initialisoidaan rivilaskuri. Sen jälkeen luetaan seuraava rivi moduulin ·. mittaustaulusta. Mikäli uusi rivi luettiin onnistuneesti edetään vaiheeseen 725.
30 Muussa tapauksessa merkitään kaikki rivit luetuiksi (parametri LatFinished saa arvon yksi, vaihe 724) ja edetään vaiheen 724b kautta suoraan vaiheeseen 745, jossa asetetaan ajastin uudelleen. Vaiheessa 724b suoritetaan eniten j kutsuttujen listan muodostukseen liittyviä toimenpiteitä, joita kuvataan tarkemmin jäljempänä kuviossa 9.
35 Vaiheessa 725 haetaan riviltä kohteen parametrit, kuten tilaajan 21 104600 tunniste (OI), kohdekohtainen aktivointiparametri (ObjAct) sekä rivin viimeisimmän käsittelyn aikaleima (LatMade) ja rivin toiseksi viimeisimmän käsittelyn aikaleima (PreMade). Tämän jälkeen kasvatetaan rivilaskurin arvoa yhdellä (vaihe 726). Kun laskurin arvoa on kasvatettu, edetään vaiheeseen 5 727, jossa testataan, onko kyseessä oleva kohde jatkuvasti passiivisessa tilassa. Tämä tehdään testaamalla, onko kohdekohtaisen aktivointiparametrin ObjAct arvo sata (joka on valittu testissä käytettäväksi arvoksi). Mikäli näin on, edetään vaiheen 744 kautta vaiheeseen 722 lukemaan seuraava rivi (jolle päästään rivilaskurin arvon perusteella) tai vaiheeseen 745 asettamaan 10 ajastin. Muussa tapauksessa testataan vaiheessa 728, onko kohde mahdollisesti muutettu edellisen herätyskerran jälkeen passiiviseksi. Tämä tehdään testaamalla, onko kohdekohtainen aktivointiparametri ObjAct pienempi tai yhtäsuuri kuin nolla. Mikäli näin on, asetetaan kohdekohtaiselle aktivointiparametrille arvo sata, joka indikoi tämän jälkeen, että kohde on 15 jatkuvasti passiivinen. Tämä tehdään vaiheessa 729, josta edetään suoraan vaiheeseen 741. Mikäli vaiheessa 728 suoritettavan testin tulos on negatiivinen (eli objekti on aktiivinen), edetään vaiheeseen 730, jossa testataan, onko kohde mahdollisesti muutettu edellisen suorituskerran jälkeen aktiiviseksi eli onko kohteeseen liittyvä mittaus juuri käynnistetty. Tämä 20 tehdään testaamalla, onko kohdekohtaisen aktivointiparametrin ObjAct arvo pienempi kuin sata, mutta suurempi kuin nolla (eli onko se ykkönen). Jos näin on, eli kohde on juuri käynnistetty, siirrytään kohteen initialisointivaiheeseen 732, jossa initialisoidaan rivillä olevat aikaleimat LatMade ja PreMade kulumassa olevaa minuuttilukua seuraavaan minuuttilukuun ja annetaan 25 kohteen aktivointiparametrille arvo, joka vastaa sen aikaisempaa arvoa (yksi) lisättynä sadalla (ObjAct:=ObjAct+100). Tämän jälkeen edetään suoraan vaiheeseen 741, jossa tarkistetaan pariteetin arvo ja siirrytään sen jälkeen nollaamaan jompi kumpi laskurijoukoista (vaihe 742 tai vaihe 743). Nollattava « laskurijoukko riippuu pariteetin arvosta. Näistä vaiheista siirrytään vaiheeseen 30 744, jossa testataan, onko rivilaskuri saavuttanut käyttäjän asettaman, kerralla käsiteltävien rivien lukumäärän (Batch). Mikäli näin on, siirrytään vaiheeseen 745, jossa ajastin asetetaan laukeamaan uudelleen, mutta mikäli näin ei ole, siirrytään takaisin vaiheeseen 722 lukemaan seuraava rivi.
Mikäli vaiheessa 730 havaittiin, ettei ollut kysymyksessä kohteen 35 muutos passiivisesta aktiiviseksi, siirrytään vaiheeseen 734, jossa testataan, 22 104600 onko edellä mainittu, aikaleimaa P (PreMade) koskeva epäyhtälö [ThirdlnterTime]<P<[SecondlnterTime] tosi (missä hakasuluilla on merkitty aikaleimojen arvoja). Mikäli näin on, hypätään suoraan vaiheeseen 736, jossa tarkistetaan pariteetin arvo ja siirrytään sen jälkeen lukemaan joko 5 ensimmäisen tai toisen laskuriryhmän arvot (vaiheet 737 tai 738), riippuen siitä, mikä oli pariteetin arvo. Tämän jälkeen kirjoitetaan lokitiedostoon vaiheessa 739. Mikäli aikaleimaa P koskeva epäyhtälö ei ollut tosi, testataan vaiheessa 735, onko aikaleimaa L (LatMade) koskeva epäyhtälö [ThirdlnterTime]<L<[SecondlnterTime] tosi. Jos näin on, siirrytään vaiheeseen 10 736 tarkistamaan pariteettimuuttujan arvo, josta jatketaan edellä kuvattuun tapaan lokitiedoston kirjoittamisella.
Kirjoittamisen jälkeen suoritetaan eniten kutsuttujen listan päivitys lohkossa 739b. Tätä lohkoa kuvataan tarkemmin jäljempänä kuviossa 10. Lohkosta 739b, tai vaiheesta 735, jos aikaleimaa L koskeva epäyhtälö oli 15 epätosi, siirrytään vaiheeseen 740, jossa päivitetään rivillä olevat käsittelyleimat (P- ja L-leimat). P-leima saa L-leiman entisen arvon ja L-leima saa arvon, joka vastaa kulumassa olevaa minuuttilukemaa pyöristettynä ylöspäin. Aikaleimojen päivityksen jälkeen siirrytään vaiheeseen 741 tarkistamaan pariteetti, josta prosessi etenee edellä kuvattuun tapaan. 20 Rivikohtaiset aikaleimat päivitetään siis sen jälkeen, kun rivi on käsitelty.
Edellä kuvattua laskuriarvojen talletus- ja nollausprosessia käydään siis läpi tihein väliajoin käyttäen kuviossa 5a (tai 5b) esitettyä vuorottelurytmiä, jossa (pariteetti)parametrin arvo määrää kussakin aikavälissä sen, minkä laskuriryhmän arvoja talletetaan kullakin rivillä.
25 Huomattakoon vielä, että edellä kuvattu talletus- ja nollausprosessi kuvasi yhden mittaustaulun käsittelyä. Edellä olevan selityksen täydentämiseksi voidaan lisäksi todeta, että kun talletus- ja nollausprosessi havaitsee moduulin tulleen juuri käynnistetyksi (vaihe 709), aikaleimat
M
: LatlnterTime, SecondInterTime ja ThirdlnterTime initialisoidaan (vaihe 710) 30 edessä olevaan ensimmäiseen tasaminuuttilukemaan eli samaan ajanhetkeen kuin aikaleima FollInterTime. Ensimmäisen tasaminuuttilukeman jälkeisellä herätyskerralla todetaan välinvaihtumishetki FollInterTime ohitetuksi (vaihe 716), mutta välinvaihtumishetkiä LatlnterTime, Second InterTime ja ThirdlnterTime ei tällöin tarvitse päivittää, koska ne ovat jo valmiiksi 35 initialisoidut, eli vaiheesta 717 edetään suoraan vaiheeseen 719 päivittämään 23 104600 odotettavissa olevaa seuraavaa välinvaihtumishetkeä FollInterTime. Talletus-ja nollausprosessi tarvitsee edellä mainitun initialisointiarvon välinvaihtumishetkille LatlnterTime, SecondInterTime ja ThirdlnterTime, jotta yksikään näistä aikaleimoista ei olisi koskaan vanhempi kuin sen 5 herätyskerran kellonaika, jolloin moduulin käynnistys havaitaan tapahtuneeksi. Näin tehdään mahdolliseksi moduulin pysäyttäminen ja uudelleenkäynnistäminen esim. vain muutaman sekunnin kuluttua.
Kuvio 8 havainnollistaa tarkemmin lohkossa 718b suoritettavia toimenpiteitä. Aluksi testataan (vaihe 81), saatiinko kaikki rivit käsiteltyä 10 kuluneen mittausvälin aikana. Tämä tehdään testaamalla, onko parametrin LatFinished arvo yksi. Mikäli havaitaan, että rivien käsittely jäi kesken, hypätään tekemään eniten kutsuttujen lista, muussa tapauksessa edetään suoraan vaiheeseen 719 (piste A2). Edellisessä tapauksessa testataan ensin, halutaanko lista tehtäväksi tämän mittausmoduulin yhteydessä. Tämän 15 selvittämiseksi luetaan moduulikohtaisen parametrin TopList arvo. Jos tämä arvo osoittaa, että listaa ei tehdä, edetään suoraan vaiheeseen 719 (piste A2). Mikäli taas arvo osoittaa, että lista on tehtävä, lajitellaan olemassa oleva lista (vaihe 83) käyttäen jotakin sinänsä tunnettua lajittelualgoritmia. Tämän jälkeen lista talletetaan (rivit kirjoitetaan lajittelun mukaisessa järjestyksessä siihen 20 mittaustauluun, joka on varattu eniten kutsuttujen kohteiden listaa varten) ja lista nollataan valmiiksi rivien seuraavaa läpikäyntiä varten (vaihe 84). Nollaus tarkoittaa sitä, että seuraavaa mittausväliä varten initialisoidaan valmiiksi tieto siitä, että pienimmän listalla olevan kohteen laskuriarvo on nolla. Lajittelualgoritmina voidaan käyttää esim. sinänsä tunnettua 25 standardivaihtomenetelmää (standard exchange method), jota kutsutaan myös kuplalajitteluksi (bubble sort). Tällaista menetelmää kuvataan esim. julkaisussa Korpela, Larmela, Planman: Pascal-ohjelmointikieli, OtaDATA r.y., 1980, ISBN 951-767-034-6, kappale 12.4.1.
t ·
Kuvio 10 havainnollistaa lohkossa 724b suoritettavia toimenpiteitä. 30 Nämä toimenpiteet ovat samoja kuin ne, jotka suoritettiin lohkossa 718b siinä tapauksessa, että rivien käsittely oli kesken. Huomattakoon vielä, että lohkon 724b sisältämät toimenpiteet suoritetaan aina, kun mittausvälin kuluessa on saatu kaikki rivit käsiteltyä, minkä jälkeen eniten kutsuttujen kohteiden mittaustaulu on valmis.
35 Kuvio 11 havainnollistaa lohkossa 739b suoritettavia toimenpiteitä, 24 104600 jotka suoritetaan jokaisessa sellaisessa rivinkäsittelyssä, jossa laskuriarvot todetaan oikeiksi ja kelvollisiksi talletettaviksi. Aluksi testataan, halutaanko lista tehtäväksi tämän mittausmoduulin (vaihe 101) yhteydessä. Tämän selviämiseksi luetaan moduulikohtaisen parametrin TopList arvo. Jos tämä 5 arvo osoittaa, että listaa ei tehdä, edetään suoraan vaiheeseen 740 (piste A7). Mikäli taas arvo osoittaa, että lista on tehtävä, testataan seuraavaksi (vaihe 102), otetaanko laskuriarvoa listalle. Tämä tehdään vertaamalla rivin kutsulaskuriarvoa listalla olevaan pienimpään arvoon, jota ylläpidetään rekisterissä. Mikäli kutsulaskuriarvo on suurempi kuin mainittu pienin arvo, 10 korvataan listan pienin arvo mainitulla kutsulaskuriarvolla, mutta mikäli näin ei ole, hypätään suoraan vaiheeseen 740. Korvauksen jälkeen päivitetään listan pienintä arvoa vastaava indeksi. Tämä tehdään käymällä läpi koko lista ja päivittämällä listalla viimeisenä olevan kohteen indeksi sillä indeksillä, joka vastaa pienintä listalla olevaa arvoa.
15 Järjestelmässä on myös edullista käyttää erillistä moduulikohtaista apumuuttujaa, joka kertoo, sallitaanko laskuriarvojen talletus. Tämä apumuuttuja saa arvon sen mukaan, onko ainakin toinen aikaleimoja koskevista epäyhtälöistä tosi. Apumuuttujan käytön etuna on se, että esim. eniten kutsuttujen listaa koskevassa mittausryhmässä voidaan talletus estää, 20 vaikka epäyhtälöt sen sallisivatkin.
Vaikka keksintöä on edellä selostettu viitaten oheisten piirustusten mukaisiin esimerkkeihin, on selvää, ettei keksintö ole rajoittunut siihen, vaan sitä voidaan muunnella edellä ja oheisissa patenttivaatimuksissa esitetyn keksinnöllisen ajatuksen puitteissa. Periaatteessa on esim. mahdollista tehdä 25 vastaavalla tavalla lista vähiten kutsutuista kohteista, mutta tällaisella listalla ei ole merkitystä kuormituksen rajoituksen kannalta. Periaatetta voidaan myös noudattaa, vaikka rivillä ei käytettäisikään monistettuja laskureita eikä ajan suhteen noudatettaisi edellä kuvattua vuorotteluperiaatetta. Talletusta ja listan • · teko voitaisiin esim. hoitaa eri prosessorilla kuin laskurien kasvatus. 30 Vuorotteluperiaatetta on kuitenkin edullista noudattaa, koska silloin voidaan käyttää yhtä prosessoria ja listan laatiminen häiritsee mahdollisimman vähän laskurien kasvatusprosessia. Vuorotteluperiaate voidaan puolestaan toteuttaa yksinkertaisimmin siten, että käytetään kahdennettuja laskureita.
Claims (10)
1. Menetelmä kuormitustilanteen valvomiseksi palvelutietokanta-järjestelmässä, joka käsittää tietokannan, johon on talletettu mittaustauluja 5 (MT), joissa on peräkkäisiä rivejä (Ri), jolloin yksittäisellä rivillä on yhtä mittauskohdetta koskevia tietoja ja saman mittaustaulun mittauskohteet ovat keskenään saman tyyppisiä muodostaen mittausryhmän, jossa menetelmässä - vastaanotetaan järjestelmään palvelupyyntöjä (SR), joiden käsittelyn kuluessa on tarpeen laskea yhtä tai useampaa mittauskohdetta kohti tulevien 10 tapahtumien lukumääriä, - käynnistetään palvelun tarjonta vasteena palvelupyynnölle, - suoritetaan tapahtumatalletusta kasvattamalla mittauskohde-kohtaista laskuria kutakin tiettyä palvelupyyntöön liittyvää tapahtumaa kohti tietyn ennalta määrätyn pituisen mittausvälin ajan, jonka mittausvälin arvo on 15 käyttäjän määritettävissä, - suoritetaan laskuriarvojen talletusta ottamalla kunkin mittausvälin jälkeen talteen mittauskohdekohtaisia laskuriarvoja, ja - laaditaan talletettujen laskuriarvojen perusteella lista, joka käsittää halutun määrän laskuriarvojen suhteen suurimpia mittauskohteita, 20 tunnettu siitä, että - laskuriarvojen talletusta ja nollausta suoritetaan kussakin mittausaikavälissä yksi mittauskohde kerrallaan, # ' - mainittu lista muodostetaan mittausväleittäin siten, että mittausvälin sisällä kunkin yksittäisen kohteen käsittelyn yhteydessä tarkistetaan, onko 25 kyseisen kohteen laskuriarvo suurempi kuin listalla sillä hetkellä pienimmän laskuriarvon omaavan kohteen laskuriarvo ja mikäli näin on, korvataan listalla pienimmän laskuriarvon omaava kohde kyseistä riviä vastaavalla kohteella, ja - muodostettu lista talletetaan viimeistään mittausvälin päätyttyä.
2. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, 30 että - mittaustaulun kutakin mittauskohdetta vastaavalla rivillä ylläpidetään kutakin mittauslaskuria kahdennettuna siten, että ensimmäinen laskuri kuuluu ensimmäiseen laskurijoukkoon (CG1) ja toinen laskuri kuuluu toiseen laskurijoukkoon (CG2), ja että 35. aika-akseli jaetaan peräkkäisiin mittausväleihin (TP) siten, että joka 26 104600 toisessa mittausvälissä kasvatetaan ensimmäisen laskurijoukon laskureita ja talletetaan sekä nollataan toisen laskurijoukon laskurien arvoja ja joka toisessa mittausaikavälissä kasvatetaan toisen laskurijoukon laskureita ja talletetaan sekä nollataan ensimmäisen laskurijoukon laskurien arvoja,
3. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että yksittäisen rivin käsittelyn yhteydessä tarkistetaan, ovatko laskuriarvot kelvollisia talletettaviksi, ja vain kelvollisia arvoja kelpuutetaan listalle.
4. Patenttivaatimuksen 3 mukainen menetelmä, tunnettu siitä, että 10 -järjestelmässä ylläpidetään mittauskohdekohtaisesti aikaleimaa, joka indikoi viimeisimmän ajanhetken, jolloin mittauskohteen rivillä on suoritettu nollaus ja aikaleimaa, joka indikoi toiseksi viimeisimmän ajanhetken, jolloin mittauskohteen rivillä on suoritettu nollaus, ja mittausryhmäkohtaisesti aikaleimoja, jotka indikoivat kolme viimeisintä mittausvälin vaihtumishetkeä, ja 15 - mittauskohdekohtaisia aikaleimoja verrataan mittausryhmäkohtaisiin aikaleimoihin, ja mittauskohteen laskuriarvot hyväksytään talletettaviksi, mikäli ainakin toinen mittauskohdekohtaisista aikaleimoista on halutulla tavalla toiseksi viimeisintä mittausaikavälin vaihtumishetkeä indikoivan aikaleiman ja kolmanneksi viimeisintä mittausaikavälin vaihtumishetkeä indikoivan 20 aikaleiman välissä.
5. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että lista lajitellaan ja talletetaan tietotauluun lajittelun mukaisessa järjestyksessä silloin, kun - havaitaan, että kaikki kohteet on käsitelty kulumassa olevan 25 mittausvälin aikana, - havaitaan, että mittausväli on vaihtunut, mutta kohteiden käsittelyä ei saatu loppuun edellisen mittausaikavälin aikana.
6. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että tietotaulussa säilytetään lista useamman mittausaikavälin ajalta.
7. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että halutun pituinen lista alustetaan järjestyksessä ensimmäisinä käsitellyistä kohteista asettamalla pienin listalla oleva kutsumäärä nollaksi.
8. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, t 104600 27 että listaa käytetään hyväksi kiellettäessä palvelupyyntöjä ylikuormitustilanteissa.
9. Menetelmä kuormitustilanteen valvomiseksi palvelutietokanta-järjestelmässä, joka käsittää tietokannan, johon on talletettu mittaustauluja 5 (MT), joissa on peräkkäisiä rivejä (Ri), jolloin yksittäisellä rivillä on yhtä mittauskohdetta koskevia tietoja ja saman mittaustaulun mittauskohteet ovat keskenään saman tyyppisiä muodostaen mittausryhmän, jossa menetelmässä - vastaanotetaan järjestelmään palvelupyyntöjä (SR), joiden käsittelyn kuluessa on tarpeen laskea yhtä tai useampaa mittauskohdetta kohti tulevien 10 tapahtumien lukumääriä, - käynnistetään palvelun tarjonta vasteena palvelupyynnölle, - suoritetaan tapahtumatalletusta kasvattamalla mittauskohde-kohtaista laskuria kutakin tiettyä palvelupyyntöön liittyvää tapahtumaa kohti tietyn ennalta määrätyn pituisen mittausvälin ajan, jonka mittausvälin arvo on 15 käyttäjän määritettävissä, - suoritetaan laskuriarvojen talletusta ottamalla kunkin mittausvälin jälkeen talteen mittauskohdekohtaisia laskuriarvoja, ja - laaditaan talletettujen laskuriarvojen perusteella lista, joka käsittää halutun määrän laskuriarvojen suhteen pienimpiä mittauskohteita, 20 tunnettu siitä, että - laskuriarvojen talletusta ja nollausta suoritetaan kussakin mittausaikavälissä yksi mittauskohde kerrallaan, - mainittu lista muodostetaan mittausväleittäin siten, että mittausvälin sisällä kunkin yksittäisen kohteen käsittelyn yhteydessä tarkistetaan, onko 25 kyseisen kohteen laskuriarvo pienempi kuin listalla sillä hetkellä suurimman laskuriarvon omaavan kohteen laskuriarvo ja mikäli näin on, korvataan listalla suurimman laskuriarvon omaava kohde kyseistä riviä vastaavalla kohteella, ja - muodostettu lista talletetaan viimeistään mittausvälin päätyttyä.
10. Patenttivaatimuksen 9 mukainen menetelmä, tunnettu siitä, 30 että - mittaustaulun kutakin mittauskohdetta vastaavalla rivillä ylläpidetään kutakin mittauslaskuria kahdennettuna siten, että ensimmäinen laskuri kuuluu ensimmäiseen laskurijoukkoon (CG1) ja toinen laskuri kuuluu toiseen laskurijoukkoon (CG2), ja että 35. aika-akseli jaetaan peräkkäisiin mittausväleihin (TP) siten, että joka 28 104600 toisessa mittausvälissä kasvatetaan ensimmäisen laskurijoukon laskureita ja talletetaan sekä nollataan toisen laskurijoukon laskurien arvoja ja joka toisessa mittausvälissä kasvatetaan toisen laskurijoukon laskureita ja talletetaan sekä nollataan ensimmäisen laskurijoukon laskurien arvoja. 5 •» f 29 104600
Priority Applications (9)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FI963371A FI104600B (fi) | 1996-08-29 | 1996-08-29 | Kuormitustilanteen valvonta palvelutietokantajärjestelmässä |
| EP97937608A EP0978068A2 (en) | 1996-08-29 | 1997-08-29 | Monitoring of load situation in a service database system |
| BR9711269A BR9711269A (pt) | 1996-08-29 | 1997-08-29 | Processo para realiza-Æo de registros de evento em um sistema de base de dados de servi-o e processo para monitoramento de situa-Æo de carga em um sistema de base de dados de servi-o |
| JP10511324A JP2000517123A (ja) | 1996-08-29 | 1997-08-29 | サービスデータベースシステムにおける負荷状態の監視 |
| PCT/FI1997/000506 WO1998009236A2 (en) | 1996-08-29 | 1997-08-29 | Monitoring of load situation in a service database system |
| AU40176/97A AU728049B2 (en) | 1996-08-29 | 1997-08-29 | Monitoring of load situation in a service database system |
| CN97198253.8A CN1231747A (zh) | 1996-08-29 | 1997-08-29 | 业务数据库系统中负载情况的监测 |
| CA002263596A CA2263596A1 (en) | 1996-08-29 | 1997-08-29 | Monitoring of load situation in a service database system |
| US09/249,862 US6064950A (en) | 1996-08-29 | 1999-02-16 | Monitoring of load situation in a service database system |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FI963371A FI104600B (fi) | 1996-08-29 | 1996-08-29 | Kuormitustilanteen valvonta palvelutietokantajärjestelmässä |
| FI963371 | 1996-08-29 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| FI963371A0 FI963371A0 (fi) | 1996-08-29 |
| FI963371A FI963371A (fi) | 1998-03-01 |
| FI104600B true FI104600B (fi) | 2000-02-29 |
Family
ID=8546552
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FI963371A FI104600B (fi) | 1996-08-29 | 1996-08-29 | Kuormitustilanteen valvonta palvelutietokantajärjestelmässä |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US6064950A (fi) |
| EP (1) | EP0978068A2 (fi) |
| JP (1) | JP2000517123A (fi) |
| CN (1) | CN1231747A (fi) |
| AU (1) | AU728049B2 (fi) |
| BR (1) | BR9711269A (fi) |
| CA (1) | CA2263596A1 (fi) |
| FI (1) | FI104600B (fi) |
| WO (1) | WO1998009236A2 (fi) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FI110655B (fi) * | 1997-07-11 | 2003-02-28 | Nokia Corp | Sanomaliikenteen vähentäminen älyverkossa |
| JP3328208B2 (ja) * | 1998-12-28 | 2002-09-24 | 富士通株式会社 | インテリジェントネットワークシステム |
| ES2407808T3 (es) * | 2002-05-21 | 2013-06-14 | Koninklijke Kpn N.V. | Sistema y método para monitorización de red y red correspondiente |
| US20040220947A1 (en) * | 2003-05-02 | 2004-11-04 | International Business Machines Corporation | Method and apparatus for real-time intelligent workload reporting in a heterogeneous environment |
| AU2003262444B2 (en) * | 2003-11-20 | 2011-04-07 | Fci Holdings Delaware, Inc. | Cable bolt |
| US20060136490A1 (en) * | 2004-12-17 | 2006-06-22 | International Business Machines Corporation | Autonomic creation of shared workflow components in a provisioning management system using multi-level resource pools |
| US7499865B2 (en) * | 2004-12-17 | 2009-03-03 | International Business Machines Corporation | Identification of discrepancies in actual and expected inventories in computing environment having multiple provisioning orchestration server pool boundaries |
| US7953703B2 (en) * | 2005-02-17 | 2011-05-31 | International Business Machines Corporation | Creation of highly available pseudo-clone standby servers for rapid failover provisioning |
| US9830912B2 (en) | 2006-11-30 | 2017-11-28 | Ashwin P Rao | Speak and touch auto correction interface |
| US9922640B2 (en) | 2008-10-17 | 2018-03-20 | Ashwin P Rao | System and method for multimodal utterance detection |
| US9122782B2 (en) | 2011-09-28 | 2015-09-01 | International Business Machines Corporation | Apparatus and computer program product for adaptively determining response time distribution of transactional workloads |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4918593A (en) * | 1987-01-08 | 1990-04-17 | Wang Laboratories, Inc. | Relational database system |
| US5067099A (en) * | 1988-11-03 | 1991-11-19 | Allied-Signal Inc. | Methods and apparatus for monitoring system performance |
| US5446884A (en) * | 1992-02-13 | 1995-08-29 | International Business Machines Corporation | Database recovery apparatus and method |
| US5499358A (en) * | 1993-12-10 | 1996-03-12 | Novell, Inc. | Method for storing a database in extended attributes of a file system |
| US5570410A (en) * | 1994-10-13 | 1996-10-29 | Bellsouth Corporation | Dynamic resource allocation process for a service control point in an advanced intelligent network system |
| US5581610A (en) * | 1994-10-19 | 1996-12-03 | Bellsouth Corporation | Method for network traffic regulation and management at a mediated access service control point in an open advanced intelligent network environment |
| FI98973C (fi) * | 1994-11-22 | 1997-09-10 | Nokia Telecommunications Oy | Menetelmä ryhmätietojen ylläpitämiseksi matkaviestinjärjestelmässä ja matkaviestinjärjestelmä |
-
1996
- 1996-08-29 FI FI963371A patent/FI104600B/fi active
-
1997
- 1997-08-29 CA CA002263596A patent/CA2263596A1/en not_active Abandoned
- 1997-08-29 CN CN97198253.8A patent/CN1231747A/zh active Pending
- 1997-08-29 BR BR9711269A patent/BR9711269A/pt not_active IP Right Cessation
- 1997-08-29 WO PCT/FI1997/000506 patent/WO1998009236A2/en not_active Application Discontinuation
- 1997-08-29 JP JP10511324A patent/JP2000517123A/ja active Pending
- 1997-08-29 EP EP97937608A patent/EP0978068A2/en not_active Withdrawn
- 1997-08-29 AU AU40176/97A patent/AU728049B2/en not_active Ceased
-
1999
- 1999-02-16 US US09/249,862 patent/US6064950A/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| CA2263596A1 (en) | 1998-03-05 |
| FI963371A0 (fi) | 1996-08-29 |
| JP2000517123A (ja) | 2000-12-19 |
| EP0978068A2 (en) | 2000-02-09 |
| CN1231747A (zh) | 1999-10-13 |
| AU4017697A (en) | 1998-03-19 |
| AU728049B2 (en) | 2001-01-04 |
| WO1998009236A2 (en) | 1998-03-05 |
| BR9711269A (pt) | 1999-08-17 |
| US6064950A (en) | 2000-05-16 |
| FI963371A (fi) | 1998-03-01 |
| WO1998009236A3 (en) | 1998-04-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FI104600B (fi) | Kuormitustilanteen valvonta palvelutietokantajärjestelmässä | |
| KR0173052B1 (ko) | 서비스 가입자별 정보료 수납대행 서비스의 정보료 할인율 처리 방법 | |
| FI104597B (fi) | Tapahtumien tallettaminen palvelutietokantajärjestelmässä | |
| FI104599B (fi) | Tapahtumien tallettaminen palvelutietokantajärjestelmässä | |
| FI104595B (fi) | Tapahtumien tallettaminen palvelutietokantajärjestelmässä | |
| FI104594B (fi) | Tapahtumien tallettaminen palvelutietokantajärjestelmässä | |
| FI104598B (fi) | Tapahtumien tallettaminen palvelutietokantajärjestelmässä | |
| FI104596B (fi) | Tapahtumien tallettaminen palvelutietokantajärjestelmässä | |
| FI107978B (fi) | Tallettaminen | |
| KR960011707B1 (ko) | 과금용 자기테이프(mt)를 이용한 전전자 교환기의 트래픽 데이타 분석방법 | |
| US6618471B1 (en) | Method and system for measuring usage of advanced intelligent network services |