FI104595B - Tapahtumien tallettaminen palvelutietokantajärjestelmässä - Google Patents

Tapahtumien tallettaminen palvelutietokantajärjestelmässä Download PDF

Info

Publication number
FI104595B
FI104595B FI963366A FI963366A FI104595B FI 104595 B FI104595 B FI 104595B FI 963366 A FI963366 A FI 963366A FI 963366 A FI963366 A FI 963366A FI 104595 B FI104595 B FI 104595B
Authority
FI
Finland
Prior art keywords
measurement
time
group
counter
counters
Prior art date
Application number
FI963366A
Other languages
English (en)
Swedish (sv)
Other versions
FI963366A (fi
FI963366A0 (fi
Inventor
Pekka Lehtinen
Original Assignee
Nokia Networks Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Networks Oy filed Critical Nokia Networks Oy
Publication of FI963366A0 publication Critical patent/FI963366A0/fi
Priority to FI963366A priority Critical patent/FI104595B/fi
Priority to CA002263594A priority patent/CA2263594A1/en
Priority to AU40171/97A priority patent/AU728567B2/en
Priority to JP10511319A priority patent/JP2000517118A/ja
Priority to BR9711263A priority patent/BR9711263A/pt
Priority to EP97937603A priority patent/EP0922261A2/en
Priority to CN97198251.1A priority patent/CN1231745A/zh
Priority to PCT/FI1997/000501 priority patent/WO1998009231A2/en
Publication of FI963366A publication Critical patent/FI963366A/fi
Priority to US09/249,871 priority patent/US6292793B1/en
Application granted granted Critical
Publication of FI104595B publication Critical patent/FI104595B/fi

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/4228Systems providing special services or facilities to subscribers in networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/22Arrangements for supervision, monitoring or testing
    • H04M3/36Statistical metering, e.g. recording occasions when traffic exceeds capacity of trunks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M2201/00Electronic components, circuits, software, systems or apparatus used in telephone systems
    • H04M2201/12Counting circuits
    • YGENERAL 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
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99931Database or file accessing

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Debugging And Monitoring (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

104595
Tapahtumien tallettaminen palvelutietokantajärjestelmässä
Keksinnön ala 5 Keksintö liittyy yleisesti palvelutietokantajärjestelmään, ja erityisesti menetelmään, jonka avulla voidaan suorittaa erilaisia tapahtumamittauksia 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 palveluio-’ giikan 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ä 104595.
2 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:lle. 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.IIe 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ä 104595 3 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 SCP:stä ja SSP:stä 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 104595 4 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.IIe.
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ää 104595 5 prosessointia. Mittausohjelmalohko ei siis suorita työtään kutsukohtaisesti kuten paivelulogiikkaohjelma, 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älläistä 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äijestelmä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 (m'rttaus)objektit) muodostuvat tietokantajärjestelmän tietotaulujen yksittäisistä riveistä, joita prosessori käsittelee. Järjestelmässä talletetaan pyyntöjen lukumäärät ja tietyt 7 y tapahtumat määrätyn pituisten mittausaikavälien aikana.
30 Kohteet voidaan luokitella kohdeluokkiin siten, että kussakin luokassa 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 104595 .
6 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.
Konventionaalisissa palvelutietokantajärjestelmissä käytetään kumulatiivisia laskureita ja erotusten laskeminen on toteutettu erillisen prosessorin avulla. Erotuksia ei kuitenkaan ole voitu laskea luotettavasti tai .· ainakin luotettavien laskuriarvojen takaaminen on ollut vaikeaa. Tämä johtuu 30 siitä, että kahden talletetun arvon välillä on voinut sattua jotain poikkeavaa (esim. kahdennettua prosessoriyksikköä käyttävässä järjestelmässä prosessoriyksikköjen vaihto). Lisäksi järjestelmän hallinnan puolella on oltava ylimääräistä älykkyyttä moduulin/objektin aktivoinnin jälkeisen ensimmäisen mittausvälin käsittelyyn, koska näissä tapauksissa ei edeltäviä laskuriarvoja ole 35 lainkaan, eikä erotuksia voida näin ollen laskea.
7 104595
Laskureiden ympäripyörähtäminen on lisäksi ollut ongelma erityisesti silloin, kun laskuritietueita menetetään jostakin syystä esim. siirtoyhteydellä (jonka kautta erotukset siirretään hallintajärjestelmään).
Lisäksi eri kohteille tulee tällaisessa järjestelmässä eripituisia 5 mittausaikavälejä siinä tapauksessa, että osa tietotaulun riveistä jää jatkuvasti käsittelemättä. Tämäkin vaikeuttaa järjestelmän hallintaa.
Keksinnön yhteenveto
Keksinnön tarkoituksena on eliminoida edellä kuvatut epäkohdat ja 10 saada aikaan järjestelmä, joka takaa sen, että (a) laskuriarvojen talletus voidaan toteuttaa yksinkertaisesti ja tehokkaasti ja (b) että vain oikeita laskuriarvoja saadaan kaikissa olosuhteissa talteen.
Tämä päämäärä saavutetaan keksinnön mukaisella menetelmällä, joka on määritelty itsenäisessä patenttivaatimuksessa.
15 Keksinnön ajatuksena on ylläpitää tietokannassa, jossa kukin kohde on varustettu usealla laskurijoukolTa, joita käytetään vuoroväleittäin toisaalta laskurien kasvattamiseen ja toisaalta laskuriarvojen tallettamiseen, kohdekohtaisesti ainakin kahta viimeisintä rivinkäsittelyaikaleimaa. Näitä kohdekohtaisia aikaleimoja verrataan niihin välinvaihtumishetkiin (joita myös 20 ylläpidetään järjestelmässä), jotka rajaavat sen aikavälin, jonka kuluessa kyseisellä hetkellä talletettavana ja nollattavana oleva laskurijoukko on edellisen kerran ollut mahdollista nollata. Mikäli jompikumpi aikaleimoista on halutulla tavalla ko. välinvaihtumishetkien välissä, voidaan olla varmoja, että kyseisen kohteen passiivilaskurijoukko on asianmukaisesti nollattu ennen 25 viimeisintä kokonaista mittausaikaväliä.
Erittäin edullisen suoritusmuodon mukaisesti yksittäistä mittauslaskuria ylläpidetään kahdennettuna, jolloin ensimmäinen laskuri kuuluu ensimmäiseen laskurijoukkoon ja toinen laskuri kuuluu toiseen .· laskurijoukkoon, ja joka toisessa mittausaikavälissä kasvatetaan ensimmäisten * 30 laskurijoukkojen laskureita ja talletetaan sekä nollataan toisten laskurijoukkojen laskurien arvoja ja joka toisessa aikavälissä kasvatetaan toisten laskurijoukkojen laskureita ja talletetaan sekä nollataan ensimmäisten laskurijoukkojen laskurien arvoja.
Se, että tallettaminen voidaan sallia vain jomman kumman ehdoista 35 toteutuessa perustuu siihen, että kyseistä passiivilaskuriryhmää on viimeksi 104595 8 käsitelty, ei edeltävässä, vaan sitä edeltävässä kokonaisessa mittausaikavälissä (tai vieläkin aikaisemmin, mikäli laskurijoukkoja on useampi kuin kaksi), jolloin ei ole väliä sillä, onko edeltävässä mittausaikavälissä päästy ko. riville asti vai ei. Toisin sanoen, esim. kahdennettujen laskurien 5 tapauksessa voidaan sallia, että myös viimeisin rivinkäsittelyleima on toiseksi viimeisen ja kolmanneksi viimeisen välinvaihtumishetken välissä.
Keksinnön erään toisen edullisen suoritusmuodon mukaisesti järjestelmässä käytetty aika on diskretoitu siten, että kaikki käytetyt aikaleimat ovat kokonaislukuja, jotka ilmaisevat minuuttilukemia. Diskretointiväli (minuutti) 10 vastaa lyhintä mahdollista mittausaikaväliä.
Kuvioluettelo
Seuraavassa keksintöä ja sen edullisia suoritusmuotoja kuvataan tarkemmin viitaten oheisten kuvioiden 4-11 e mukaisiin esimerkkeihin oheisissa 15 piirustuksissa, joissa kuvio 1 havainnollistaa älyverkon toiminnallista arkkitehtuuria, kuvio 2 havainnollistaa älyverkon fyysistä arkkitehtuuria, kuvio 3 havainnollistaa SCP-solmun tapahtumamittauksen kannalta oleellisia osia, 20 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ä 25 vuorotteluperiaatetta, jota noudatetaan kuvion 4 järjestelmässä, kuvio 6 on vuokaavio, joka esittää järjestelmän siirtymistä tyhjäkäyntitilasta normaaliin toimintatilaansa, kuviot 7a...7d muodostavat vuokaavion, joka kuvaa laskurien talletus-ja nollausprosessin kulkua, 30 kuviot 8a...8e esittävät aika-akseleilla ensimmäistä tapahtumasarjaa, jossa laskuriarvojen oikeellisuus todetaan, kuviot 9a... 9d esittävät aika-akseleilla toista tapahtumasarjaa, jossa laskuriarvojen oikeellisuus todetaan, kuviot 10a... 10e esittävät aika-akseleilla kolmatta tapahtumasarjaa, 35 jossa laskuriarvojen oikeellisuus todetaan, ja 104595 9 kuviot 11a...11e esittävät aika-akseleilla neljättä tapahtumasarjaa, jossa laskuriarvojen oikeellisuus todetaan.
Keksinnön yksityiskohtainen kuvaus 5 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.
10 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 15 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ä). 20 Parametrien arvot ovat käyttäjän aseteltavissa.
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, 25 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 30 useita eri mittaustauluja.
Mittaustaulun otsikkorivillä HR ovat ne parametrit, jotka ovat yhteisiä koko mittausryhmälle. Nämä parametrit kuvataan jäljempänä.
Palvelulogiikkaohjelmainstanssi SLPi lukee perustaulun BT rivejä, joten perustaulun riveillä on myös sellaisia parametreja, joita käytetään 35 palvelun tuottamiseen. Koska ne eivät kuitenkaan kuulu tämän keksinnön 104595 .
10 piiriin, ei niitä kuvata tässä yhteydessä tarkemmin.
SSP:n lähettämä palvelupyyntö SR sisältää tilaajan (kohteen) tunnisteen. Kun SCP saa tällaisen palvelupyynnön luodaan palvelulogiikkaohjelmasta palvelulogiikkaohjelmailmentymä SLPi, joka ryhtyy 5 palvelemaan ko. palvelupyyntöä. Tämä tehdään sinänsä tunnetulla tavalla siten, että järjestelmässä oleva palvelulogiikan suorituslohko SLE luo palvelulogiikkailmentymän SLPi ottamalla kopion palvelulogiikkamalleista, jotka on talletettu lohkoon SLPT. Tämä kopio (eli SLPi) asetetaan vastaanotetun palvelupyynnön käyttöön. Palvelupyynnöt palvelulogiikan 10 suorituslohko SLE noutaa puskurista BF, johon tulevat palvelupyynnöt talletetaan.
SLPi lukee palvelupyynnöstä tilaajan tunnisteen, minkä jälkeen se pystyy lukemaan tunnistetta vastaavan rivin perustaulusta. Riviltä SLPi saa selville parametrien ObjActj (j=1,2...) arvot. Mikäli kohde on aktiivinen, SLPi 15 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 sekä kohde että mittausryhmä ovat aktiivisia, SLPi kasvattaa mittaustaulun ko. kohteen rivillä olevan yhden tai useamman laskurin arvoa. Kuten kuviossa 4 20 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ä.
Mittaustaulun riveillä olevat laskurit on edullisesti kahdennettu siten, että riville muodostuu kaksi laskuriryhmää, joita on merkitty viitemerkeillä CG1 25 ja CG2. Ryhmissä on samat laskurit (yksi tai useampi laskuri ryhmässä) 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 mittausaikaväleihin TP, joista joka toista on merkitty viitemerkillä F ja joka toista viitemerkillä T. Mittausaikavälien F aikana kasvatetaan esim.
30 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 otsikkoriveillä. Lukiessaan mittaustaulun otsikkoriviä SLPi lukee myös pariteettiparametrin arvon, jolloin se tietää, kumpaa mittaustaulun rivillä olevaa : 35 laskuria sen on kasvatettava. Pariteettiparametri on Boolen muuttuja, joka voi 104595 11 saada arvot T(rue) tai F(alse), mistä syystä joka toista aikaväliä on kuviossa merkitty viitemerkillä T ja joka toista puolestaan viitemerkillä F.
Edellä esitetty vuorotteluperiaate vastaa keksinnön edullisinta suoritusmuotoa, jossa laskurit on kahdennettu. Vuorotteluperiaatetta voitaisiin 5 kuitenkin noudattaa myös siten, että laskureita monistetaan useampi kuin kaksi. Tätä yleistä periaatetta on havainnollistettu kuviossa 5b, jossa kutakin laskuria on N kappaletta, jolloin mittauskohdetta vastaavalla mittaustaulun rivillä on N kappaletta laskurijoukkoja (joista jokaisessa on yksi tai useampi laskuri). Kun monistettujen laskurien lukumäärä on suurempi kuin kaksi, aika-10 akseli on edelleenkin jaettu peräkkäisiin mittausaikaväleihin (TP) siten, että kussakin mittausaikavälissä kasvatetaan vain tietyn laskurijoukon laskurien arvoja ja kasvatettavaa laskurijoukkoa vaihdetaan mittausaikavälistä toiseen. Koska laskurijoukkoja on N kappaletta, samaa laskurijoukkoa kasvatetaan N mittausaikavälin välein. Yksittäisen laskurijoukon laskurien talletus ja nollaus 15 suoritetaan niiden mittausaikavälien aikana, jotka jäävät niiden mittausaikavälien väliin, joiden aikana kyseisen laskurijoukon laskureita kasvatetaan. Se, kuinka talletus ja nollaus jaetaan ko. mittausaikaväleihin voi myös vaihdella. Tietyn laskuriryhmän talletus- ja nollaus voidaan esim. tehdä aina yhden mittausaikavälin kuluessa. Jos talletus- ja nollaus jää kesken, on 20 sitä kuitenkin mahdollista jatkaa toisessa mittausaikavälissä, mikäli kyseisessä mittausaikavälissä on jo ehditty suorittaa ko. mittausaikaväliä vastaavien laskurijoukkojen talletus ja nollaus. Tällä tavoin voidaan käytettävissä oleva aika hyödyntää tehokkaasti, mutta suorituslogiikasta tulee monimutkaisempi.
Koska laskurien kahdennus on kuitenkin edullisin toteutusvaihtoehto, 25 käytetään sitä jatkossakin esimerkkinä. On kuitenkin huomattava, että mittausryhmäkohtaisia mittausvälin vaihtumishetkiä on talletettava sitä enemmän, mitä suurempi N on. Lisäksi N:n kasvaessa muuttuvat ne aikaleimat, jotka rajaavat sen aikavälin, jonka kuluessa talletettavana ja nollattavana oleva laskurijoukko on edellisen kerran ollut talletus- ja 30 nollausvuorossa. Esim. jos N=3, rajaavat neljänneksi viimeinen ja kolmanneksi viimeinen mittausaikavälin vaihtumishetki kyseisen aikavälin (olettaen, että tietyn laskuriryhmän talletus- ja nollaus voidaan esim. tehdä aina vain yhden mittausaikavälin kuluessa).
Palvelulogiikkaohjelmainstanssi SLPi hoitaa riveillä olevien : 35 tapahtumalaskureiden kasvattamista itsenäisesti, mikä tarkoittaa sitä, että se 12 104595 kasvattaa sokeasti laskureiden arvoja, mikäli havaitsee kyseisen mittausryhmän ja -kohteen aktiivisiksi. Mittausohjelmalohko hoitaa sen sijaan riveillä olevien laskureiden talletusta ja nollausta. Mittausohjelmalohkossa voi olla omat alilohkonsa CRj jokaisen mittausryhmän laskurien talletusta ja 5 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 niissä mittausaikaväleissä, joissa SLPi kasvattaa laskuriryhmän CG2 10 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 laskurien talousprosessi työskentelee. Jatkossa nimitetään niitä laskureita, 15 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 käsiteltiin edellisen mittausaikavälin aikana. (Huomattakoon, että vaikka tässä 20 yhteydessä puhutaan talletus- ja 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ä 25 nollausta, vaan molemmat voidaan ohittaa tai suorittaa ainoastaan nollaus.) Järjestelmään kuuluu lisäksi oleellisena osana herätysajastin TM, jonka avulla asetetaan prosessori PR käynnistämään mittausohjelmalohko (laskurien talletus ja nollaus) pienin väliajoin WP (kuviot 5a ja 5b). Herätysaikavälin pituus voi olla esim. 10 sekuntia eli herätysaikaväli on hyvin 30 lyhyt verrattuna mittausaikaväliin TP. Herätysajastin 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. Tästä : 35 parametrista käytetään jatkossa nimitystä Batch. Jos kaikkien kohteiden 104595 .
13 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 5 talletus- ja nollausprosessi herätetäänkin edelleen tihein välein herätysajastimen avulla, ei mittausobjekteja enää käsitellä kyseisessä aikavälissä.
Kuten edellä todettiin, on edullista, jos sama prosessori suorittaa sekä mittausohjelmaa että palvelulogiikkaohjelmaa SLPi. Kuviossa 4 tätä yhteistä 10 prosessoria on merkitty viitemerkillä PR. Mittausohjelman suoritus käynnistetään ajastimen TM avulla aina, kun aikaväli WP on kulunut.
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 15 järjestelmässä on kaksi prosessoria siten, että toinen suorittaa palvelulogiikkaohjelmaa ja toinen käsittelee levyllä ylläpidettäviä laskuriarvoja.
Joka tapauksessa prosessoriin liittyy tietyt muistialueet MA1...MA3, joilla mittausohjelmalohko, palvelulogiikkaohjelmalohko sekä tietokanta tietotauluineen ovat. Palvelun suorituslohkon muistialuetta on merkitty 20 viitemerkillä MA4 ja palvelulogiikkamallien muistialuetta viitemerkillä MA5. Kuten edellä kuitenkin mainittiin, on vasteaikojen kannalta edullista käyttää RAM-muistia ja yhtä prosessoria.
, Jos kaikkien kohteiden (tilaajien) passiivilaskurijoukkoja ei ehditä käsitellä, esim. prosessoriylikuorman takia, käytettävissä olevan 25 mittausaikavälin TP kuluessa, jätetään loput kohteet käsittelemättä.
Periaatteena on, että tekemättömän työn ei anneta kasautua. Talletus- ja nollausprosessi merkitsee kuitenkin rivikohtaisilla aikaleimoilla ne rivit, jotka on ehditty käsitellä. (Jos rivejä jää käsittelemättä, jäävät laskurit myös nollaamatta, eikä lokitiedostoon kyetä kirjoittamaan.) 30 Palvelulogiikkaohjelmainstanssi kasvattaa sokeasti kaikkia laskureita, myös käsittelemättä jääneillä riveillä. Näitä rivejä ei kuitenkaan voida käsitellä jatkossa, koska niiden arvot eivät enää ole mittausaikavälin pituiselta ajalta, esim. 5 min. pituiselta ajalta. Kun mittausohjelma rupeaa käsittelemään rivejä, tarkistetaan erikseen, voiko laskuriarvon kirjoittaa lokitiedostoon. Laskuriarvoja 35 kasvatetaan siis sokeasti, mutta seuraavassa käsittelyaikavälissä tarkistetaan, 104595 14 onko arvo kelvollinen kirjoitettavaksi lokitiedostoon vai ei.
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 5 mittausryhmillä on, vaan järjestelmässä on yksi ainoa laskuri, joka herättää mittausohjelman tiheästi, esim. 10 s välein. Jokaisella herätyskerralla mittausohjelma tarkistaa, onko ruvettava käsittelemään (tallettamaan ja nollaamaan) kohdekohtaisia laskureita. Näin ollen voidaan esim. prosessorin ylikuormatilanteessa aina luottaa siihen, että jossain vaiheessa kuorman 10 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 joka on helpompi kuin erillisten ajastimien käyttö. Erillisten ajastimien tapauksessa liiallisen prosessorikuorman aiheuttama myöhästyminen kostautuisi, koska ajastin 15 asetetaan aina uudestaan saman aikavälin päähän. Tällöin pitäisi jollain tavalla hoitaa kellonajan ja laukeamishetkien välinen synkronointi.
Seuraavassa kuvataan niitä parametreja, jotka ovat oleellisia keksinnön mukaisessa järjestelmässä. Mittauskohderyhmälle yhteisiä parametreja, jotka ovat kunkin mittaustaulun MT otsikkorivillä, ovat: 20 ___
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__j_
SecondlnterTime Toiseksi viimeinen välinvaihtumishetki__I_
ThirdlnterTime 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
* i ___________ __ _i_____ 104595 15
LatFinished Parametri, joka kertoo, onko taulun kaikki rivit B
__käsitelty__
Parametrin tyyppiä on merkitty kirjaimella I siinä tapauksessa, että 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).
5 Mittausvälin pituus ilmoitetaan minuutteina.
Käyttäjän aseteltavissa ovat mittausryhmän aktivointiparametri 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 10 indikoivat viimeisimmän mittausaikavälin vaihtumishetken (LatlnterTime), sitä edellisen mittausaikavälin vaihtumishetken (SecondInterTime) ja sitäkin edellisen mittausaikavälin vaihtumishetkeä (ThirdlnterTime) sekä edessä olevan mittausaikavälin vaihtumishetken (FollInterTime) ovat edullisesti minuuttilukuindeksejä, joten ne ovat tyypiltään kokonaislukumuuttujia, johtuen 15 siitä, että järjestelmässä käytetty aika on diskretoitu.
Viimeksi tapahtunut pariteetin vaihtumishetki (LatParityTime) ja sitä 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, 20 pariteetin vaihtumishetki menee tyypillisesti muutaman sekunnin yli mittausaikavälin määritellystä vaihtumishetkestä. Viime mainittuja parametreja 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) kulumassa olevan 25 aikavälin aikana.
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_ 104595 16
Rivikohtaiset aikaleimat (LatMade ja PreMade) ovat minuuttilukuindeksejä samoin kuin mittausvälinvaihtumishetkiä indikoivat parametrit. Rivikohtaisia aikaleimoja kutsutaan jatkossa leimoiksi P (PreMade) ja L (LatMade).
5 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äynnistyskään 700. Kun järjestelmä saa ns. kylmäkäynnistyssignaalin (vaihe 10 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, kuviot 5a ja 5b) jälkeen, minkä jälkeen siirrytään ns. lämpimään käynnistyskään 700.
15 Kuvioissa 7a...7d on esitetty vuokaaviona mittausohjelmalohkon suorittaman talletus- ja nollausprosessin kulkua. Kun prosessi on lämpimässä 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 WP kuluttua. Kun 20 ajastin taas laukeaa, talousprosessi käydään jälleen läpi ja viimeisenä vaiheena 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 25 suorituskerta luokkaa 50 ms.
Kun ajastin on lauennut siirrytään vaiheeseen 702, jossa haetaan kulumassa olevan ajan arvo sekä moduulin (eli mittausryhmän) parametrit moduulin otsikkoriviltä. Kulumassa oleva ajanarvo on sama kuin ajastimen ;; käynnistyshetki ja tämä ajanarvo pysyy samana koko sen ajan, minkä 30 käynnistyksen aiheuttama yksi suorituskerta kestää. Ajanarvosta määritetään kulumassa oleva (current) minuuttilukuindeksi (esim. laskettuna tietyn vuoden alusta). Kuten aiemmin todettiin, järjestelmässä käytetty aika on diskretoitu. Edullinen diskretointiväli on yksi minuutti, joka on samalla myös lyhyin mahdollinen mittausaikaväli.
35 Mittaustaulun otsikkoriviltä noudetaan käyttäjän aseteltavissa olevien 104595 17 parametrien ActNew, IntervNew ja Batch arvot. Tämän jälkeen testataan vaiheessa 703a, onko kysymyksessä talousprosessin ensimmäinen käynnistys kylmäkäynnistyssignaalin jälkeen. Tämä tehdään testaamalla, onko em. moduulikohtaisen lipun arvo nolla. Mikäli näin on, testataan vaiheessa 5 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 lippu pois päältä eli annetaan parametrille Alive 10 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 käytössä oleva aktivointiparametri Act pienempi tai yhtäsuuri kuin nolla ja 15 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 laukeamaan uudelleen.
20 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 käyttäjän asettama aktivointiparametri ActNew pienempi tai yhtäsuuri kuin 25 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 :! hetkeä testataan vaiheessa 707, jossa testataan, onko kaikki rivit saatu 30 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 seuraavan odotettavissa olevan välinvaihtumishetken.
35 Kun mittausmoduuli on pysäytetty vaiheessa 708 asettamalla 18 104595 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 moduuli on aktiivinen), vaiheessa 709 testataan, onko moduuli mahdollisesti 5 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 indikoi siis sitä, että moduulia ollaan aktivoimassa). Jos näin on, eli moduuli on käynnistetty edellisen 10 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ä aktivointiparametri ActNew keinotekoisesti arvoon yksi, jotta kaikissa 15 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ä (kylmäkäynnistys) varmistetaan tällä tavalla, että talletusprosessi etenee initialisointivaiheeseen 710 myös, jos käyttäjän määrittämällä moduulikohtaisella aktivointiparametrilla 20 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 mittausryhmän.
25 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 '.I määräämän aktivointiparametrin arvoa kasvatetaan sadalla, jotta vaiheessa 30 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.
Moduulikohtaiset parametrit on siis initialisoitava käynnistyshetkeä 35 myöhäisempään ajanhetkeen. Tällaisella oikealla initialisoinnilla 1β 104595 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 ovat oikealla tavalla tosia tai epätosia, riippumatta esim. siitä, missä vaiheessa 5 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 järjestelmässä pidetään yllä tietoa kahdesta viimeksi tapahtuneesta pariteetin 10 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 mittausaikavälin pituus vaihtunut. Tämä tehdään testaamalla, onko uusi arvo 15 (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 mittausaikavälille sen uusi arvo vaiheessa 713 ja lasketaan seuraavaksi 20 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.
Toimenpiteet (vaiheen 713 päivitys) voidaan siis suorittaa vain jos kulumassa 25 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 ;| ohitettu. Mikäli jompi kumpi näistä ehdoista täyttyy, päivitetään mittausaikavälin 30 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 aktivoinnin jälkeen. Tämä testi suoritetaan testaamalla, onko parametrin ' 35 FollInterTime arvo sama kuin parametrin LatlnterTime arvo (arvot ovat samoja 104595 20 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 ovat erisuuret, on ensimmäinen minuutti ohitettu ja voidaan suorittaa edessä 5 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 välinvaihtumishetki (ensimmäinen tasaminuutti) on siis se ajanhetki, johon 10 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 käsittelyleimat asettuvat kuitenkin seuraavaan minuuttilukemaan, jolloin 15 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 (laskuriarvojen talletus ja nollaus) aloitetaan siis vasta ensimmäisen 20 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 estimaatti saadaan, kun sen hetkisestä minuuttilukemasta vähennetään saatu 25 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 ;j parametrin LatlnterTime arvoa, koska esim. ylikuormitustilanteessa prosessori 30 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 ' parametrin CurrentMinute arvo (eli kellonajasta otettu minuuttilukema, kun i \ . 35 sekunteja ei huomioida) suurempi tai yhtä suuri kuin parametrin FollInterTime 104595 21 arvo. Mikäli näin ei ole, edetään suoraan vaiheeseen 720. Muussa tapauksessa edetään kohti vaihetta 718, jossa liputetaan välinvaihtumishetkiä koskevia aikaleimoja eteenpäin. Tällöin viimeisimmän mittausaikavälin vaihtumishetken ilmoittava parametri LatlnterTime saa arvon CurrentMinute-5 mod(CurrentMinute/lnterv), sitä edellisen mittausaikavälin vaihtumishetken ilmoittava parametri SecondInterTime saa parametrin LatlnterTime entisen arvon ja kolmanneksi viimeisen mittausaikavälin vaihtumishetken ilmoittava parametri Third InterTime saa parametrin SecondlnterTime entisen arvon. Tässä yhteydessä ei siis sijoiteta parametrin LatlnterTime arvoksi parametrin 10 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 kulumassa oleva kellonaika pyöristettynä alaspäin tasaminuuttilukemaan, 15 vähennettynä mainitulla jakojäännöksellä, jonka arvo on yleensä nolla ja joka kompensoi mahdollisen jälkeenjääneisyyden.
Aikaleimoja ei kuitenkaan liputeta eteenpäin, jos vaiheessa 716 havaittu välinvaihtumishetken havaitaan olevan se välinvaihtumishetki, joka on moduulin aktivoinnin jälkeinen ensimmäinen tasaminuutti. Tämä testataan 20 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). Vaiheessa 718 tapahtuvan aikaleimojen liputuksen jälkeen lasketaan * vaiheessa 719 uusi arvo odotettavissa olevalle välinvaihtumishetkelle (eli 25 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 ' i: viimeisimmän ja toiseksi viimeisimmän pariteetinvaihtumishetken aikoja « 30 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 käsittely on kesken. Huomattakoon myös, että vaikka rivien käsittely olisikin 35 kesken ja huomataan, että välinvaihtumishetki on ohitettu, resetoidaan 104595 22 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 käsitelty (onko parametrilla LatFinished arvo yksi). Mikäli näin on, siirrytään 5 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. Muussa tapauksessa merkitään kaikki 10 rivit luetuiksi (parametri LatFinished saa arvon yksi, vaihe 724) ja edetään suoraan vaiheeseen 745, jossa asetetaan ajastin uudelleen.
Vaiheessa 725 haetaan riviltä kohteen parametrit, kuten tilaajan tunniste (OI), kohdekohtainen aktivointiparametri (ObjAct) sekä rivin viimeisimmän käsittelyn aikaleima (LatMade) ja rivin toiseksi viimeisimmän 15 käsittelyn aikaleima (PreMade). Tämän jälkeen kasvatetaan rivilaskurin arvoa yhdellä (vaihe 726). Kun laskurin arvoa on kasvatettu, edetään vaiheeseen 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, 20 edetään vaiheen 744 kautta vaiheeseen 722 lukemaan seuraava rivi (jolle päästään rivilaskurin arvon perusteella) tai vaiheeseen 745 asettamaan 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 25 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 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 30 testataan, onko kohde mahdollisesti muutettu edellisen suorituskerran jälkeen aktiiviseksi eli onko kohteeseen liittyvä mittaus juuri käynnistetty. Tämä 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 35 732, jossa initialisoidaan rivillä olevat aikaleimat LatMade ja PreMade 104595 23 kulumassa olevaa minuuttilukua seuraavaan minuuttilukuun ja annetaan 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 5 nollaamaan jompi kumpi laskurijoukoista (vaihe 742 tai vaihe 743). Nollattava laskurijoukko riippuu pariteetin arvosta. Näistä vaiheista siirrytään vaiheeseen 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, 10 siirrytään takaisin vaiheeseen 722 lukemaan seuraava rivi.
Mikäli vaiheessa 730 havaittiin, ettei ollut kysymyksessä kohteen muutos passiivisesta aktiiviseksi, siirrytään vaiheeseen 734, jossa testataan, onko edellä mainittu, aikaleimaa P (PreMade) koskeva epäyhtälö [ThirdlnterTime]<P<[SecondlnterTime] tosi (missä hakasuluilla on merkitty 15 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 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 20 vaiheessa 735, onko aikaleimaa L (LatMade) koskeva epäyhtälö [ThirdlnterTime]<L<[SecondlnterTime] tosi. Jos näin on, siirrytään vaiheeseen 736 tarkistamaan pariteettimuuttujan arvo, josta jatketaan edellä kuvattuun . . tapaan lokitiedoston kirjoittamisella. Lokitiedostoon kirjoitetaan moduulin ja kohteen tunnisteiden sekä rivillä olleiden kohdekohtaisten laskuriarvojen lisäksi 25 edellä kuvattujen parametrien arvoja.
Kirjoittamisen jälkeen, tai vaiheesta 735, jos aikaleimaa L koskeva epäyhtälö oli 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ä 30 ylöspäin. Aikaleimojen päivityksen jälkeen siirrytään vaiheeseen 741 tarkistamaan pariteetti, josta prosessi etenee edellä kuvattuun tapaan. 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 esitettyä vuorottelurytmiä, jossa 35 pariteettiparametrin arvo määrää kussakin aikavälissä sen, kumman 104595 .
24 laskuriryhmän arvoja talletetaan.
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 5 havaitsee moduulin tulleen juuri käynnistetyksi (vaihe 709), aikaleimat LatlnterTime, SecondInterTime ja ThirdlnterTime initialisoidaan (vaihe 710) edessä olevaan ensimmäiseen tasaminuuttilukemaan eli samaan ajanhetkeen kuin aikaleima FollInterTime. Ensimmäisen tasaminuuttilukeman jälkeisellä herätyskerralla todetaan välinvaihtumishetki FollInterTime ohitetuksi (vaihe 10 716), mutta välinvaihtumishetkiä LatlnterTime, SecondlnterTime ja
ThirdlnterTime ei tällöin tarvitse päivittää, koska ne ovat jo valmiiksi initialisoidut, eli vaiheesta 717 edetään suoraan vaiheeseen 719 päivittämään odotettavissa olevaa seuraavaa välinvaihtumishetkeä FollInterTime. Talletus-ja nollausprosessi tarvitsee edellä mainitun initialisointiarvon 15 välinvaihtumishetkille LatlnterTime, SecondlnterTime ja ThirdlnterTime, jotta yksikään näistä aikaleimoista ei olisi koskaan vanhempi kuin sen 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.
20 Seuraavassa esitetään, alkaen kuvioista 8a...8e, esimerkkitapauksina aika-akseleilla erilaisia tapahtumasarjoja, joissa tarkistetaan laskuriarvojen oikeellisuus edellä kuvatun prosessin avulla. Esimerkkitapauksissa oletetaan, . että talletus- ja nollausprosessi ehtii jokaisen mittausvälin sisällä käynnistyä ainakin kerran, jolloin se kykenee liuottamaan eteenpäin aikaleimoja 1-3. Jos 25 talletus- ja nollausprosessi ei ehdi käynnistyä kertaakaan mittausvälin sisällä, tulee yhdestä mittausvälistä epänormaalin pituinen, mutta muita muutoksia ei aiheudu seuraaviin tarkasteluihin.
Kuvioissa on ympyröidyllä ykkösellä merkitty viimeisintä mittausaikavälin vaihtumishetkeä (LatlnterTime), ympyröidyllä kakkosella 30 toiseksi viimeistä mittausaikavälin vaihtumishetkeä (SecondlnterTime) ja ympyröidyllä kolmosella kolmanneksi viimeisintä mittausaikavälin vaihtumishetkeä (ThirdlnterTime). Näitä kutsutaan jatkossa aikaleimoiksi 1, 2 ja vastaavasti 3. Ensimmäisen mittausvälin alkupuolella on pieni neliö, joka tarkoittaa sitä, että mittausryhmä on aktivoitu ryhmänä eli aktivointiparametri 35 on asetettu päälle. Kun talletus- ja nollausprosessi käynnistyy ensimmäisen 104595 25 kerran aktivointihetken jälkeen, se havaitsee muutoksen. Tällöin talletus- ja nollausprosessi initialisoi aikaleimat 1-3 käynnistysajanhetken minuuttilukemaan (pyöristettynä ylöspäin, vertaa vaihe 710 edellä). Kuvioissa tarkastellaan tilannetta yksittäisen mittauskohteen kannalta, joka on tietty rivi 5 taulussa, jolla on tietty mittauskohde esim. tietty tilaaja. Koska talletus- ja nollausprosessi käynnistyy pienin välein, se ehtii yleensä pääsemään käsiksi kyseiseen riviin. Tätä hetkeä on kuviossa 8a merkitty mustalla ympyrällä. Mittaustaulun yksittäisellä rivillä on, kuten edellä kuvattiin, kaksi aikaleimaa PreMade ja LatMade, jotka prosessi initialisoi objektin initialisoinnin 10 tapauksessa (tässä esimerkissä oletetaan, että myös objekti on juuri initialisoitu) ko. hetkeen (minuuttilukema pyöristettynä ylöspäin, vrt. vaihe 732). Tämän jälkeen ensimmäinen, vajavainen mittausaikaväli päättyy ja siirrytään tarkastelemaan kuviota 8b, jossa samaa riviä käsitellään toistamiseen. Sitä ennen, mittausaikavälin todellisen vaihtumishetken jälkeen talletus- ja 15 nollausprosessi on liuottanut ympyrällä merkittyjä mittausryhmäkohtaisia parametreja (vaihe 718), jolloin aikaleima 1 siirtyy eteenpäin. Jos jompi kumpi leimoista P tai L on ThirdlnterTime-leiman ja SecondlnterTime-leiman välissä siten, että joko yhtälö [ThirdlnterTime]<P<[SecondlnterTime] tai yhtälö [ThirdInterTime] < L < [SecondlnterTime] pätee, voidaan kyseinen laskuriarvo 20 kirjoittaa lokitiedostoon. Toisin sanoen, jos jompi kumpi yhtälöistä pätee, on laskuri nollattu silloin kun se pitääkin nollata ja laskurin arvo on siis luotettava. Koska oleellista on ainoastaan se, että laskuri on nollattu ThirdlnterTime ja ; : SecondlnterTime-leimojen välillä, riittää että toinen yhtälöistä pätee.
Ensimmäisessä kokonaisessa mittausaikavälissä (kuvio 8b) tehty 25 vertailu osoittaa, että kumpikin epäyhtälöistä on epätosi. Vertailua on merkitty merkitty kaksipäisellä nuolella.
Vertailun jälkeen päivitetään P- ja L-aikaleimojen arvoja (vaihe 740), jolloin aikaleima L siirtyy eteenpäin sen hetkiseen rivinkäsittelyhetkeen ja ' aikaleima P saa aikaleiman L entisen arvon (kuvio 8b).
30 Seuraava mittausaikaväli eli toinen kokonainen mittausväli (kuvio 8c) on sellainen, että sen kuluessa ei ehditä käsitellä kyseistä riviä (josta merkkinä aikavälissä on valkoinen ympyrä). Tästä huolimatta aikaleimat 1 ja 2 liukuvat eteenpäin, koska talletus- ja nollausprosessi ehtii mittausaikavälin vaihtumishetken jälkeen käynnistyä ainakin kerran ja suorittaa liputuksen. Sen 35 sijaan kohteen aikaleimat P ja L eivät päivity, koska vertailutilanteeseen asti ei 104595 26 päästä. Tämän jälkeen siirrytään kuvioon 8d, joka kuvaa kyseisen rivin kolmatta käsittelykertaa (mustilla ympyröillä on merkitty niitä ajanhetkiä, jolloin riviä päästään käsittelemään). Nyt ovat aikaleimat P ja L jääneet jälkeen (kuvio 8c), koska edellisessä mittausaikavälissä ei ehditty käsitellä kyseistä riviä. Kun 5 tätä riviä tullaan käsittelemään, on mittausaikavälien vaihtumishetkiä osoittavilla aikaleimoilla jo kuviossa 8d esitetyt arvot (koska ne päivitetään vaiheessa 718), kun sen sijaan aikaleimoilla P ja L on vielä entiset arvonsa, jotka näkyvät kuviossa 8c. Tässä tapauksessa aikaleima L on aikaleimojen 3 ja 2 välillä, joten kirjoitus lokitiedostoon voidaan sallia. Aikaleima P ei sen 10 sijaan ole aikaleimojen 2 ja 3 välillä.
Kun siis rivinkäsittely alkaa, verrataan rivillä olevia aikaleimoja (P ja L) sillä hetkellä voimassa oleviin aikaleimoihin 1-3, jotka on jo ehditty päivittää uusiksi silloin, kun talletus- ja nollausprosessi käynnistyy ensimmäisen kerran kulumassa olevan mittausaikavälin aikana.Vasta vertailun jälkeen liputetaan 15 yksittäisellä rivillä olevia aikaleimoja (P ja L) eteenpäin. Kun kyseistä riviä käsitellään seuraavan kerran (ympyrällä merkitty kohta kuviossa 8e), on aikaleimoilla 1-3 kuviossa 8e näkyvät arvot, koska niitä on liputettu kulumassa olevan mittausaikavälin alussa, mutta aikaleimoilla P ja L on kuviossa 8d näkyvät arvot. Kun näitä verrataan aikaleimoihin 2 ja 3, havaitaan, ettei 20 kumpikaan ole aikaleimojen 2 ja 3 välissä, joten lokitiedostoon ei voida kirjoittaa. Tämä johtuu siitä, että edellisessä käsittelyaikavälissä ei ehditty nollata laskuria.
Kuvioissa 9a... 9d on esitetty toisena esimerkkitapauksena tapahtumasarja, jossa alku on vastaavanlainen eli ensimmäisen vajaan 25 mittausaikavälin kuluessa ehditään riviä käsitellä (kuvio 9a). Myös seuraavassa mittausaikavälissä onnistutaan pääsemään ko. riville asti (kuvio 9b). Lokitiedostoon ei kuitenkaan voida kirjoittaa, koska em. epäyhtälöt eivät ole tosia. Kun riviä päästään käsittelemään kolmannen kerran (kuvio 9c), on I sen hetkinen aikaleima P aikaleimojen 3 ja 2 välissä, joten lokitiedostoon voi 30 kirjoittaa. Samoin seuraavassa mittausaikavälissä, koska myös tällöin aikaleima P on aikaleimojen 3 ja 2 välissä. Jos siis jokaisessa mittausaikavälissä ehditään käsitellä ko. rivi, on aikaleima P jatkuvasti aikaleimojen 3 ja 2 välissä.
Kuvioissa 10a... 10e on esitetty kolmantena esimerkkitapauksena 35 edellisestä hieman poikkeava tapahtumasarja. Ensimmäisen, vajaan 104595 27 mittausaikavälin kuluessa ehditään käsitellä ko. rivi ja mittausaikavälin vaihtumishetket ehditään liu’uttaa eteenpäin. Sitä seuraavassa mittausaikavälissä (kuvio 10b, valkoisella ympyrällä merkitty aikaväli) ei sen sijaan ehditä suorittaa ko. rivin käsittelyä. Kun päästään seuraavaan 5 mittausaikaväliin (kuvio 10c) ehditään käsittely jälleen suorittaa. Tällöin havaitaan, että sekä aikaleima P että aikaleima L on aikaleimojen 3 ja 2 välissä, joten lokitiedostoon voi kirjoittaa. Seuraavan mittausaikavälin (kuvio 10d) aikana päästään jälleen käsittelemään riviä, mutta nyt havaitaan, että kumpikaan leimoista P tai L ei ole aikaleimojen 3 ja 2 välissä. Lokitiedostoon ei 10 siis saa kirjoittaa. Sitä seuraavassa mittausaikavälissä (kuvio 10e) päästään jälleen ko. riviä käsittelemään, jolloin osoittautuu, että rivillä olevista aikaleimoista aikaleima P on aikaleimojen 3 ja 2 välissä.
Kuvioissa 11a...11e on esitetty neljäntenä esimerkkitapauksena sellainen tapahtumasarja, jossa kaksi peräkkäistä mittausaikaväliä (kuviot 11b 15 ja 11c) ovat sellaisia, että niiden kuluessa ei ehditä mittaustaulun käsittelyssä ko. riville asti. Kun näitä seuraavassa aikavälissä päästään ko. riville asti, havaitaan, ettei kumpikaan aikaleimoista P tai L ole aikaleimojen 2 ja 3 välissä. Sitäkin seuraavassa aikavälissä ehditään riviä käsitellä, mutta silloinkaan eivät aikaleimat P tai L ole aikaleimojen 2 ja 3 välissä.
20 Menetelmä toimii myös, vaikka mittauskohde olisikin ollut aktiivinen moduulin käynnistyshetkellä. Tällöin leimat P ja L ovat korkeintaan aktivointia seuraavan välinvaihtumishetken suuruisia (jos kysymyksessä on uudelleen . aktivointi saman aikavälin kuluessa ja rivi on ehditty käsitellä aktivointiaikavälin kuluessa ennen passivointia ja mainittua uudelleen aktivointia).
25 Kuten edellä mainittiin, menetelmä toimii myös vaikka olisi sellainenkin mittausaikaväli, jonka kuluessa talletus- ja nollausprosessi ei ehdi käynnistyä kertaakaan, jolloin myös mittausaikavälin vaihtumishetket jäävät liuottamatta. Jos näin tapahtuu, tulee aikaleimojen välinen etäisyys ! epänormaalin pitkäksi, mutta muuta haittaa ei tästä ole. Jos talletus- ja 30 nollausprosessi ei käynnisty lainkaan mittausaikavälin kuluessa, ei myöskään pariteetti vaihdu, vaan yksi mittausaikaväli tulee vain epänormaalin pitkäksi, minkä jälkeen toiminta jatkuu aivan normaalisti.
Vaikka keksintöä on edellä selostettu viitaten oheisten piirustusten mukaisiin esimerkkeihin, on selvää, ettei keksintö ole rajoittunut siihen, vaan 35 sitä voidaan muunnella edellä ja oheisissa patenttivaatimuksissa esitetyn „ 104595 28 keksinnöllisen ajatuksen puitteissa. Esim. se, hyväksytäänkö aikaleimojen P ja L epäyhtälöissä yhtäsuuruus vai ei, riippuu siitä kumpaan suuntaan aikaleimoja pyöristetään. Tämän takia on oheisissa vaatimuksissa maininta “halutulla tavalla niiden mittausryhmäkohtaisten aikaleimojen välissä, jotka 5 rajaavat sen aikavälin, jonka kuluessa talletettavana ja nollattavana oleva laskurijoukko on edellisen kerran ollut talletus- ja nollausvuorossa ollessaan mahdollista nollata.” Edellä esitetyssä esimerkissä hyväksyttiin yhtäsuuruus aikaleiman 2 osalta, koska pyöristys tapahtui ylöspäin. Välttämätöntä ei myöskään ole se, että aikaleimoja ylläpitää ja niiden vertailua suorittaa talletus-10 ja nollausprosessi, joskin on edullista tehdä samassa yhteydessä kuin muukin rivinkäsittely. Järjestelmässä voidaan myös ylläpitää apumuuttujaa, joka kertoo sallitaanko lasku harvojen talletus vai ei. Tämän apumuuttujan arvon määrää edellä kuvattuun tapaan se, onko edes toinen aikaleimoja koskevista epäyhtälöistä tosi. Apumuuttujan käytön etuna on se, että tietyissä tilanteissa 15 voidaan esim. talletus kieltää kokonaan, vaikka epäyhtälöt sen sallisivatkin. Mittaustaulun rivillä voidaan myös käyttää laskurijoukkokohtaisesti aikaleimoja, jotka indikoivat joukon viimeisimmän ja toiseksi viimeisimmän käsittelyajankohdan. Tässäkin tapauksessa järjestelmässä on kuitenkin aikaleimat, jotka indikoivat viimeisimmän ja toiseksi viimeisimmän ajanhetken, 20 jolloin mittauskohteen rivillä on suoritettu nollaus (joskin näiden lisäksi on muitakin mittauskohdekohtaisia aikaleimoja, yhteensä 2N aikaleimaa, kun N on monistuskerroin.). Talletuksessa voi myös olla lisäehtoja, esim. siten, että . vain tietyn raja-arvon ylittävät, oikeiksi todetut laskuriarvot talletetaan.
• « • · 9

Claims (8)

104595 29
1. Menetelmä tapahtumamittausten suorittamiseksi 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, ja 15. suoritetaan laskuriarvojen talletusta ottamalla kunkin mittausvälin jälkeen talteen mittauskohdekohtaisia laskuriarvoja, tunnettu siitä, että - mittaustaulun kutakin mittauskohdetta vastaavalla rivillä ylläpidetään yksittäistä mittauslaskuria N kappaleeksi monistettuna siten, että kukin N:stä 20 laskurista kuuluu eri laskurijoukkoon, jolloin riville muodostuu N laskurijoukkoa, - aika-akseli jaetaan peräkkäisiin mittausaikaväleihin (TP) siten, että kussakin mittausaikavälissä kasvatetaan vain tietyn rivillä olevan laskurijoukon . laskurien arvoja ja kasvatettavaa laskurijoukkoa vaihdetaan mittausvälistä toiseen, 25. laskuriarvojen talletusta ja nollausta hoidetaan mittausvälissä mittauskohde kerrallaan käsittelemällä mittaustaulun rivejä rivi kerrallaan siten, että yksittäisen laskurijoukon laskurien talletus ja nollaus suoritetaan niiden mittausvälien aikana, jotka jäävät niiden mittausvälien väliin, joiden aikana kyseisen laskurijoukon laskureita kasvatetaan, 30. järjestelmässä ylläpidetään mittauskohdekohtaisesti aikaleimoja, jotka indikoivat ainakin viimeisimmän ja toiseksi viimeisimmän ajanhetken, jolloin mittauskohteen rivillä on suoritettu laskurijoukon nollaus, ja mittausryhmäkohtaisesti aikaleimoja, jotka indikoivat ainakin kolme viimeisintä mittausvälin vaihtumishetkeä, ja 35. mittauskohdekohtaisia aikaleimoja verrataan mittausryhmäkohtaisiin 104595 30 aikaleimoihin, ja mittauskohteen laskuriarvot hyväksytään oikeiksi, mikäli ainakin toinen mittauskohdekohtaisista aikaleimoista on halutulla tavalla niiden mittausryhmäkohtaisten aikaleimojen välissä, jotka rajaavat sen aikavälin, jonka kuluessa talletettavana ja nollattavana oleva laskurijoukko on edellisen 5 kerran ollut talletus- ja nollausvuorossa ollessaan mahdollista nollata.
2. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että - mittaustaulun kutakin mittauskohdetta vastaavalla rivillä ylläpidetään kutakin mittauslaskuria kahdennettuna, jolloin ensimmäinen laskuri kuuluu 10 ensimmäiseen laskurijoukkoon (CG1) ja toinen laskuri kuuluu toiseen laskurijoukkoon (CG2) ja joka toisessa mittausvälissä kasvatetaan ensimmäisten laskurijoukkojen laskureita ja talletetaan sekä nollataan toisten laskurijoukkojen laskurien arvoja ja joka toisessa mittausvälissä kasvatetaan toisten laskurijoukkojen laskureita ja talletetaan sekä nollataan ensimmäisten 15 laskurijoukkojen laskurien arvoja, ja - mittauskohteen laskuriarvot hyväksytään talletettaviksi, mikäli ainakin toinen mittauskohdekohtaisista aikaleimoista on halutulla tavalla toiseksi viimeisintä mittausvälin vaihtumishetkeä indikoivan aikaleiman ja kolmanneksi viimeisintä mittausvälin vaihtumishetkeä indikoivan aikaleiman 20 välissä.
3. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että aikaleimojen ylläpitoa ja vertailua suorittaa laskuriarvojen talletusta ja . nollausta suorittava prosessi, joka käynnistetään yhden mittausvälin kuluessa * 1' toistuvasti lyhyin väliajoin ja joka käsittelee yksittäisen rivin korkeintaan kerran 25 mittausvälin aikana.
4. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että järjestelmässä käytetty aika on diskretoitu siten, että kaikki mainitut aikaleimat ovat kokonaislukuja, jotka ilmaisevat minuuttilukemia. V, 5. Patenttivaatimuksen 4 mukainen menetelmä, tunnettu siitä, 30 että aikaleima, joka ilmoittaa viimeisimmän ajanhetken, jolloin mittauskohteen rivillä on suoritettu nollaus asetetaan rivinkäsittelyn yhteydessä kulumassa olevaan ajanhetkeen pyöristettynä ylöspäin seuraavaan minuuttilukemaan.
6. Patenttivaatimuksen 5 mukainen menetelmä, tunnettu siitä, että päivitettäessä mittausryhmäkohtaisia aikaleimoja mittausvälin vaihtumisen 35 jälkeen asetetaan viimeisintä välinvaihtumishetkeä osoittava aikaleima 104595 31 kulumassa olevan kellonajan perusteella minuuttilukemaan, joka on mainittua kellonaikaa pienempi.
7. Patenttivaatimuksen 5 mukainen menetelmä, tunnettu siitä, että käynnistettäessä mittausryhmää koskeva mittaus asetetaan 5 mittausryhmäkohtaiset aikaleimat arvoon, joka vastaa kulumassa olevaa ajanhetkeä pyöristettynä seuraavaan kokonaiseen minuuttilukemaan.
8. Patenttivaatimuksen 7 mukainen menetelmä, tunnettu siitä, että käynnistettäessä mittauskohdetta koskeva mittaus mittausryhmässä asetetaan kohdekohtaiset aikaleimat arvoon, joka vastaa kulumassa olevaa 10 ajanhetkeä pyöristettynä seuraavaan kokonaiseen minuuttilukemaan. 1 a * « 32 104595
FI963366A 1996-08-29 1996-08-29 Tapahtumien tallettaminen palvelutietokantajärjestelmässä FI104595B (fi)

Priority Applications (9)

Application Number Priority Date Filing Date Title
FI963366A FI104595B (fi) 1996-08-29 1996-08-29 Tapahtumien tallettaminen palvelutietokantajärjestelmässä
BR9711263A BR9711263A (pt) 1996-08-29 1997-08-29 Processo de realiza-Æo de registros de evento em um sistema de base de dados de servi-o
AU40171/97A AU728567B2 (en) 1996-08-29 1997-08-29 Event recording in a service database system
JP10511319A JP2000517118A (ja) 1996-08-29 1997-08-29 サービスデータベースシステムにおける事象記録
CA002263594A CA2263594A1 (en) 1996-08-29 1997-08-29 Event recording in a service database system
EP97937603A EP0922261A2 (en) 1996-08-29 1997-08-29 Event recording in a service database system
CN97198251.1A CN1231745A (zh) 1996-08-29 1997-08-29 业务数据库系统中的事件记录
PCT/FI1997/000501 WO1998009231A2 (en) 1996-08-29 1997-08-29 Event recording in a service database system
US09/249,871 US6292793B1 (en) 1996-08-29 1999-02-16 Event recording in a service database system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FI963366 1996-08-29
FI963366A FI104595B (fi) 1996-08-29 1996-08-29 Tapahtumien tallettaminen palvelutietokantajärjestelmässä

Publications (3)

Publication Number Publication Date
FI963366A0 FI963366A0 (fi) 1996-08-29
FI963366A FI963366A (fi) 1998-03-01
FI104595B true FI104595B (fi) 2000-02-29

Family

ID=8546547

Family Applications (1)

Application Number Title Priority Date Filing Date
FI963366A FI104595B (fi) 1996-08-29 1996-08-29 Tapahtumien tallettaminen palvelutietokantajärjestelmässä

Country Status (9)

Country Link
US (1) US6292793B1 (fi)
EP (1) EP0922261A2 (fi)
JP (1) JP2000517118A (fi)
CN (1) CN1231745A (fi)
AU (1) AU728567B2 (fi)
BR (1) BR9711263A (fi)
CA (1) CA2263594A1 (fi)
FI (1) FI104595B (fi)
WO (1) WO1998009231A2 (fi)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1003096A1 (en) * 1998-11-19 2000-05-24 Alcatel Mediation device development method
WO2001097553A2 (en) * 2000-06-15 2001-12-20 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for obtaining measurement data for performance analysis in a radio network
US20020143901A1 (en) * 2001-04-03 2002-10-03 Gtech Rhode Island Corporation Interactive media response processing system
US10445312B1 (en) * 2016-10-14 2019-10-15 Google Llc Systems and methods for extracting signal differences from sparse data sets

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4446336A (en) * 1981-02-09 1984-05-01 Bell Telephone Laboratories, Incorporated Method for recording and updating stored messages in an announcement system
US4918593A (en) * 1987-01-08 1990-04-17 Wang Laboratories, Inc. Relational database system
JP2510696B2 (ja) * 1988-09-26 1996-06-26 株式会社日立製作所 計算機システム自動運転制御方式
US5067099A (en) * 1988-11-03 1991-11-19 Allied-Signal Inc. Methods and apparatus for monitoring system performance
US4998272A (en) * 1989-06-15 1991-03-05 Digital Voice Technologies, Inc. Personal voice mail system
US5065321A (en) * 1989-06-15 1991-11-12 Pulse Electronics, Inc. Solid state event recorder
US5140436A (en) * 1989-11-02 1992-08-18 Eastman Kodak Company Pre-event/post-event recording in a solid state fast frame recorder
JP3126225B2 (ja) * 1991-07-12 2001-01-22 富士通株式会社 データベース・システム
US5446884A (en) * 1992-02-13 1995-08-29 International Business Machines Corporation Database recovery apparatus and method
US5657077A (en) * 1993-02-18 1997-08-12 Deangelis; Douglas J. Event recording system with digital line camera
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ä
US6092067A (en) * 1996-05-30 2000-07-18 Microsoft Corporation Desktop information manager for recording and viewing important events data structure
US5857190A (en) * 1996-06-27 1999-01-05 Microsoft Corporation Event logging system and method for logging events in a network system

Also Published As

Publication number Publication date
FI963366A (fi) 1998-03-01
AU4017197A (en) 1998-03-19
WO1998009231A2 (en) 1998-03-05
BR9711263A (pt) 1999-08-17
JP2000517118A (ja) 2000-12-19
CA2263594A1 (en) 1998-03-05
FI963366A0 (fi) 1996-08-29
WO1998009231A3 (en) 1998-04-16
EP0922261A2 (en) 1999-06-16
US6292793B1 (en) 2001-09-18
AU728567B2 (en) 2001-01-11
CN1231745A (zh) 1999-10-13

Similar Documents

Publication Publication Date Title
FI104600B (fi) Kuormitustilanteen valvonta palvelutietokantajärjestelmässä
FI104597B (fi) Tapahtumien tallettaminen palvelutietokantajärjestelmässä
FI104595B (fi) Tapahtumien tallettaminen palvelutietokantajärjestelmässä
FI104599B (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ä
CN117132278A (zh) 一种交易链路确定方法、装置、设备和介质