Vejdirektoratet. Kompetencecenter for Trafikledelse. System for detektordataopsamling. Designspecifikation. 3800not232, Rev. 1,

Transkript

1 Vejdirektoratet Kompetencecenter for Trafikledelse System for detektordataopsamling Designspecifikation 3800not232, Rev. 1, Udført: ELP/SSH Kontrolleret: SSH/ELP Godkendt: PS

2 Side 1 1. Indledning Dette dokument giver en mere detaljeret specifikation af Detektordataopsamlingssystemet. Systemet består af decentrale computerer med software kaldet DataOpsamlingsKlient (forkortet DOK), og en central server med software kaldet DataOpsamlingsServer (forkortet DOS). Systemets opbygning kan ses nedenfor.

3 Side 2 2. DataOpsamlingsKlient (DOK) DOK ens (Data Opsamlings Klient) formål er at hente data fra det fælles interface (MySQL), behandle data ved at beregne kø varsling, spøgelses bilister, gennemsnits data over 30 og 60 sekunder og videre sende data til DOS (Data Opsamlings Server). DOK en skal også i tilfælde af netværks udfald kunne blive ved med at håndtere modtagende data, og gemme dem i en længere periode. Disse egenskaber er opnået ved at indbygge flere niveauer af buffer i programmet, som i tilfælde af netværks udfald kan benytte DOC (Data Opsamlings Computer) disk plads til midlertidigt at lagre data.

4 Side 3 DOK ens hoved komponenter som beskrives i dette dokument er MySQLInterface, CalculateUnit og CommunicationInterface. MySQLInterface MySQLInterface opgaver er opdelt i hentning af data fra Database, konvertering af data til binært format og overføre data til Buffer internt i applikationen. Databasen bliver pollet med 10 sek. mellemrum og op til 1000 af de nyest poster vil blive hentet. De data som hentes består i statusbeskeder fra detektorerne og enkeltkøretøjsdata. Data i databasen, bliver først slettet når alle de hentede data er blevet verificeret. Data leveres fra MySQL i et standard text format. For at de skal kunne benyttes til beregninger, skal de konverteres til binært format. Dette gøres når alle de hentede poster er verificeret. Applikationen har to buffere, som bruges til indgående data, Status MessageBuffer som bruges til at gemme statusbeskeder og Single- VehicleBuffer som bruges til at gemme enkeltkøretøjsdata. Bufferen er af typen Vector, og der er oprettet et unikt objekt til at indeholde Status og enkeltkøretøjsdata.

5 Side 4 CalculateUnit CalculateUnit er beregnings komponenten i DOK en, CalculateUnit henter løbende data fra SingleVehicleBuffer og sortere data efter detektorid, derefter dubleres data i 30 og 60 sek intervaller. Efter sortering og dublering beregnes gennemsnits data for hvert af intervallerne, samt Sliding Windows statistik på hastigheden. Data bliver herefter analyseret for kø eller spøgelsesbilist advarsler, og sendt i kø til at blive transmitteret på netværket.

6 Side 5 CommunicationInterface Kommunikationen med DOS en foregår igennem CommunicationInterface. Kommunikationen starter når der enten kommer en besked fra DOS en om at sende Status og Enkelt køretøjs beskeder, hvor efter data hentes i Polldata buffer, eller der kommer data i Express køen i form af kø advarsel, spøgelsesbilist advarsel eller IntervalData. I begge situationen, sendes data til Network Stream Unit, som konvertere data til en binær streng som kan sendes over netværket. Herefter bliver data stregen sendt igennem en af to komponenter, alt efter om det er en poll eller en express transmission der er tale om. Buffere Alle buffere består af STL Vector Buffere, Disse buffere er tråd sikre, og kan benytte en SWAP fil til midlertidigt at gennem data hvis der skulle løbes tør for hukommelse.

7 Side 6 3. DataOpsamlingsServer (DOS) I det følgende beskrives designet af DOS en, som den ser ud i version 3.0. Nedenfor vises en skematisk oversigt over de moduler, som DOS en består af. På figuren er kun vist to DOK er, men der kan i princippet være et vilkårligt antal. Alle output-interfaces er ikke nødvendigvis i brug på samme tid. DOS en konfigureres i hvert enkelt tilfælde til at anvende de interfaces, der er brug for, og i det antal instanser, der er brug for. 3.1 Moduler DetectorInterface DOK erne sender data til DetectorInterfacet på to forskellige forbindelser, en ExpressSocket og en PollingSocket. Begge forbindelser er TCP-sockets, hvor der sendes efter protokollen specificeret i Ref. 1. ExpressSocket bruges til intervaldata, kø-meddelelser, spøgelsesbilist-meddelelser og statusmeddelelser. Det er data, der ikke må forsinkes og bliver sendt fra DOK en, så snart de er genereret. PollingSocket bruges til enkeltkøretøjsdata, som DOS en forespør-

8 Side 7 ger ( poller ) på hos DOK en. Disse data er ikke tidskritiske og DOS en henter dem, når den har tid til det. DetectorInterfacet sender data videre til datakøer, svarende til de output-interfaces, hvor dataene skal sendes videre. Statusmeddelelser bruges til at holde øje med detektorernes tilstand. Specielt kan en statusmeddelelse være et heartbeat, der blot fortæller at alt er ok. Statusmeddelelser bliver skrevet i DOS ens log. DetectorInterfacet indeholder en watchdog, som holder øje med, om detektorerne aktuelt sender data (målte data eller statusmeddelelser/heartbeats). Hvis der ikke sendes data indenfor et givet tidsinterval, regnes detektoren for at være fejlramt. Hvis der ikke sendes data fra nogen af de dektektorer, der er tilsluttet en DOK, regnes DOK en også for at være fejlramt. Dette tidsinterval er aktuelt sat til 5 minutter. I den situation sendes en meddelelse om nedbrudet til de interfaces, der har brug for at vide, om en detektor aktuelt er fejlramt eller ej. Det drejer sig om DynDbInterface, SlmInterface, M3FelsInterface, ScadaInterface og Am2Interface. Hvis en detektor er fejlramt, kan det godt skyldes, at kommunikationen mellem DOK og DOS er afbrudt. Det betyder, at detektoren rent faktisk måler det den skal, men data bliver bufret i DOK en indtil kommunikationen igen er oppe og data kan sendes til DOS en. Derfor kan man komme ud for den situation, at DOK en regnes for at være fejlramt, men detektoren leverer data, som bare først modtages i DOS en på et senere tidspunkt. Disse data kan ikke bruges til de modtagere, som har brug for aktuelle data, dvs. DynDbInterface, SlmInterface, M3FelsInterface, ScadaInterface og Am2Interface. Derfor vil dataene blive ignoreret. DbInterfacet har derimod ikke behov for at dataene er aktuelle, da de blot gemmes i databasen til senere brug. Derfor bruger DbInterfacet en anden måde at afgøre, om en detektor er fejlramt. Den kigger på dataenes tidsstempler, og ser om der er huller i datastrømmen. Se mere om det nedenfor. DynDbInterface DynDbInterfacet videresender intervaldata til den Dynamiske Database (forkortet DynDB). Kommunikationen er baseret på webservices, se Ref. 4 for flere detaljer. De intervaldata, der sendes til DynDbInterfacet udregnes for et interval på 1 minut, og tidsstemples med sluttidspunktet for det givne interval. Intervallerne går altid fra sekund 00 til 00.

9 Side 8 Dataene for et helt anlæg (f.eks. M3) sendes samlet. Da dataene fra detektorerne modtages i DOS en i vilkårlig rækkefølge og i princippet med vilkårlig alder, sørger DynDbInterfacet for at samle dataene sammen for hvert anlæg. Interfacet holder styr på hvilke detektorer der hører til i et givet anlæg, og venter med at videresende data indtil alle data for anlægget er ankommet til DOS en. Hvis der mangler data i et anlæg, venter den eller opgiver efter følgende skema: Inden for det første minut efter tidsstemplet: Så snart alle data er tilgængelige, sendes de. Inden for det andet minut efter tidsstemplet: Så snart 90 % af dataene er tilgængelige, sendes de. De resterende 10 % smides ud når/hvis de bliver tilgængelige. Når det andet minut er gået: De tilgængelige data sendes uanset hvor mange der mangler. De resterende smides ud når/hvis de bliver tilgængelige. Ovenstående grænser er sat ud fra en vurdering af, at dataene skal bruges dynamisk, men samtidig skal være så komplette som muligt. Grænserne og tiderne kan når som helst ændres i DOS ens konfiguration. Hvis der i et interval ikke er detekteret nogen biler, er den gennemsnitlige hastighed egentlig udefineret. I så tilfælde sættes antallet af biler til 0 og status for hastigheden til nodata. Når DynDbInterface modtager en meddelelse om, at detektoren er fejlramt, vil dette markeres med error i de næste ordinære intervaldata, der sendes videre. Det sker indtil DynDbInterface igen modtager en meddelelse om at detektoren er ok igen. SlmInterface SlmInterfacet videresender intervaldata til SignLogicModule (forkortet SLM), der pt. er ved at blive udviklet til TL-styresystemet til M70 i Ålborg. Kommunikationen er baseret på webservices, se Ref. 2 for flere detaljer. De intervaldata, der sendes til SlmInterfacet udregnes for et interval på 30 sekunder, og tidsstemples med sluttidspunktet for det givne interval. Intervallerne placeres efter klokkeslettet fra sekund 00 til 30 og fra sekund 30 til 00. Ligesom i DynDbInterface sendes dataene samlet for et helt anlæg. Hvis der mangler data i et anlæg, venter den eller opgiver efter et konfigurerbar tidsinterval. Hvis der i et interval ikke er detekteret nogen biler, er den gennemsnitlige hastighed udefineret og udelades af den sendte pakke.

10 Side 9 Når SlmInterface modtager en meddelelse om, at detektoren er fejlramt, vil dette markeres med error i de næste ordinære intervaldata, der sendes videre. Det sker indtil SlmInterface igen modtager en meddelelse om at detektoren er oppe igen. DbInterface DbInterfacet videresender intervaldata og enkeltkøretøjsdata til Detektordatabasen. Kommunikationen sker med en Oracle- DBconnection. De intervaldata, der sendes til DbInterfacet udregnes for et interval på 1 minut, og tidsstemples med sluttidspunktet for det givne interval. Intervallerne placeres efter klokkeslettet fra sekund 00 til 00. Dataene sendes individuelt så snart de er ankommet til DOS en. For at spare netværks- og databaseresurser bliver de dog indsat vha. en batch-indsættelse, med normalt 30 records i hver batch. Intervaldata indsættes i tabellen log_measures, og enkeltkøretøjsdata indsættes i tabellen single_vehicle til brug for MASTRA. MASTRA kræver, at data indsættes i blokke, som omkranses af en Begin-markering og en End-markering (se beskrivelse i Ref. 3). Hver gang en detektor har været fejlramt, så den ikke har kunnet levere gyldige data, begynder en ny blok, når der atter er data. Desuden begyndes altid på en ny blok hver midnat. Der regnes med dataenes tidsstempel, ikke ankomsttidspunktet til DOS en. Da data fra detektorerne kan ankomme til DOS en i vilkårlig rækkefølge og i princippet med vilkårlig alder, indeholder DbInterfacet en speciel proces, som holder styr på, i hvilke tidsperioder der er data. Processen arbejder med et tidsvindue, hvor vinduets slutpunkt er det aktuelle klokkeslæt, og begyndpunktet ligger så langt tilbage i tiden, at man ikke regner med, at der ankommer data, der er ældre end det. Efterhånden som data ankommer og bliver sendt til databasen, markeres indenfor vinduet, hvor der er data. Og efterhånden som vinduet rykker fremad, indsættes Begin-markeringer og Endmarkeringer efter hvor der er data og efter hvornår det er midnat. Hvis der skulle ankomme data, der er ældre end vinduets begyndpunkt, udvides vinduet midlertidigt, så disse data kan inkluderes. De Begin- og End-markeringer der allerede findes i databasen indenfor det udvidede tidsinterval, bliver først slettet. M3FelsInterface M3FelsInterfacet videresender intervaldata, kø-meddelelser og spøgelsesbilist-meddelelser til trafikledelsessystemet for M3 og

11 Side 10 M10 (Sterias system). Kommunikationen er baseret på JMS (Java Message Service) De intervaldata, der sendes til M3FelsInterface udregnes for et interval på 30 sekunder, og tidsstemples med sluttidspunktet for det givne interval. Intervallerne går altid fra sekund 00 til 30 og fra sekund 30 til 00. Dataene for hvert snit sendes samlet. Da dataene fra detektorerne modtages i DOS en i vilkårlig rækkefølge og i princippet med vilkårlig alder, sørger M3FelsInterfacet for at samle dataene sammen for hvert snit. Interfacet holder styr på hvilke detektorer der hører til i et givet snit, og venter med at videresende data indtil alle data for snittet er ankommet til DOS en. Hvis alle data for snittet med et givet tidsstempel ikke er ankommet indenfor 8 sekunder efter tidsstemplet, sendes de data, der allerede er ankommet, og resten markeres som manglende. De 8 sekunder er valgt efter, at data skal være ankommet til trafikledelsessystemet inden 10 sekunder efter tidsstemplet. Hvis der i et interval ikke er detekteret nogen biler, er den gennemsnitlige hastighed egentlig udefineret. I så tilfælde genfremsendes den udregnede hastighed fra det sidste interval, hvor der blev detekteret biler. Antallet af biler sættes dog til 0. Kø-meddelelser sendes så snart der detekteteres kø, hvilket kan ske på vilkårlige tidspunkter uafhængig af beregningsintervallerne. Hvis bare der detekteres kø i ét af sporene i et detektorsnit, sendes en kø-meddelelse, der dækker alle spor i snittet. Omvendt afmeldes køen i et snit først, når den sidste detektor i snittet afmelder sin kødetektering. Sammen med kø-meddelelsen sendes de aktuelle værdier for hastighed og antal biler. Hvis der detekteres en spøgelsesbilist, sendes der straks en meddelelse om det. Meddelelsen indeholder også den detekterede hastighed for bilen. Efter 30 sekunder sender DOS en igen en meddelelse til trafikledelsessystemet, hvor advarslen afmeldes igen. Når M3FelsInterface modtager en meddelelse om, at detektoren er fejlramt, vil dette markeres i næste ordinære intervaldata, der sendes videre. Det sker indtil M3FelsInterface igen modtager en meddelelse om at detektoren er ok igen. ScadaInterface ScadaInterfacet videresender kø-meddelelser til et Scada-system. Andre data sendes ikke.

12 Side 11 For hvert detektorsnit konfigureres en kommando, der kan sætte en digital udgang, når der detekteres kø, og en kommando, der kan sætte udgangen, når køen igen er ophævet. Disse udgange kan derefter læses af et Scada-system. Hvis bare der detekteres kø i ét af sporene i et detektorsnit, regnes der for at være kø i snittet. Kommandoen repeteres hver gang DOS en modtager intervaldata fra den pågældende detektor. Kø-meddelelsen bliver sendt umiddelbart, så snart den ankommer til DOS en. Men er den ældre end en konfigurerbar timeout (normalt 10 sekunder), ignoreres den. Interfacet er baseret på at kommunikere med en Moxa iologik E4200, men kan i princippet kommunikere med enhver IO-server, der styres med kommandoer baseret på http GET. Am2Interface Am2Interfacet videresender intervaldata til TRIM-systemet via AM2-serveren. Dataene sendes til et FTP-interface på AM2- serveren. De intervaldata, der sendes til Am2Interfacet udregnes for et interval på 1 minut, og tidsstemples med sluttidspunktet for det givne interval. Intervallerne går altid fra sekund 00 til 00. Am2Interfacet er lavet, så det altid snylter på en eksisterende leverandør til TRIM-systemet. Dvs. hvert minut læses den tilsendte fil fra leverandøren, og de ekstra data fra DOS en tilføjes. Herefter uploades filen igen. Timestamp på filen fremskrives så meget, at filen med de tilføjede data altid er den nyeste, og dermed læses af TRIM-systemet. Derved er det muligt at sende data til TRIMsystemet uden at skulle igennem en besværlig omkonfigurering af det. Data sendes samlet, når de er klar indenfor en konfigurerbar timeout. Data der ikke er tilgængelige inden denne timeout, markeres som manglende. Watchdog DOS en indeholder en watchdog, der holder øje med, at de forskellige interfaces ikke går i stå. Hvis det sker, genstarter den interfacet og reetablerer kommunikationen efter bedste evne. 3.2 Brugerinterface DOS en betjenes via det grafisk brugerinterface, der kører på serverens konsol. Her er det muligt at starte og stoppe overførsler fra DOK er og enkelt-detektorer. Desuden kan man for hver detektor

13 Side 12 vælge, hvilke output-interfaces de pågældende data skal sendes til. De enkelte output-interfaces kan også startes og stoppes efter behov. En nærmere beskrivelse kan ses i Ref Log Alle aktuelle hændelser ifm. DOS ens kørsel, bliver skrevet til en log. Loggen er en tabel i en database. De seneste log-meddelelser kan ses i et vindue i GUI en. 4. Referencer 1. System for detektordataopsamling, DOK/DOS Kommunikationsprotokol, dok. nr. 3800not226, rev. 0, Sign Logic Module, Module Communication Interfaces, dok. Nr. DH ICD Interface Control Document M3/MASTRA (dokument fra etableringen af trafikledelsessystemet på M3). 4. Levering af trafikdata til Dynamisk Database, Vejdirektoratet System for detektordataopsamling, brugervejledning, dok. nr. 3800not231, rev. 1,