@City IoT Cloud Platform

iSys - Intelligente systemer IoT Løsninger

IoE.Systems

1. Introduksjon.

@City IoT Cloud Platform er dedikert "mikro-sky" system for individuelle kunder. Plattformen kan ikke deles, og bare én kunde har tilgang til fysisk eller virtuell server (VPS eller dedikerte servere). Kunden kan velge et av dusin datasentre i Europa eller i verden.

1.1 Støttede enhetstyper.

@City IoT-plattformen er dedikert til å følge iSys.PL-produkter

• IoT - RF / LoRaWAN (tingenes internett)

• CIoT - GSM / 2G / 3G / 4G / CATM1 / NBIoT (tingenes internett)

• WiFi

• Ethernet

1.2. Støttede produkttyper.

@City (eCity) Cloud IoT Platform er forskjellige størrelsessystemer for IP IoT-produkter (kalt sammen som @City maskinvare eller CioT-enheter ):

• @By

• @Lys

• @Metering

• @Spor

• @AirQ

• @Bin

1.3. Støttede kommunikasjonsprotokoller

@City IoT plattform støtter følgende protokoller for kommunikasjon:

• UDP - foreslått for CIoT-sensorer / enheter (spesielt NBIoT) - lavest dataanvendelse

• TCPIP - foreslått for enheter med toveiskommunikasjon - håndtrykk / bekreftelse

• HTTP - kun anbefalt for datatilgang / visualisering / eksport / "sky til sky"

• HTTP Webhooks - for LoRaWAN-kommunikasjon mellom LoRaWAN Network / Application Server og @City Cloud.

Data sendt fra kontroller til skyserver og omvendt krypteres i unikt binært format for lavest datastørrelse og økt sikkerhet. Hver partner får sin egen unike krypteringsnøkkel for enhetsgodkjenning, datagyldighetskontroll, etc.

For ikke-eHouse / eCity-enheter kan vi levere individuelle krypteringsalgoritmer ( "C" kildekode) for hver partner for mikroprosessor for å beskytte data før kommunikasjon.

I dette tilfellet er data helt sikre under toveiskommunikasjon over offentlige kommunikasjonsmedier (internett, Air, etc.) ).

1.4. Støttet kommunikasjonsteknologi for enhetene

@City IoT plattform støtter:

• GSM: 2G, 3G, 4G (LTE), CATM1 (LTEM1), NBIoT - enheter (UDP / TCPIP-kommunikasjon)

• LoRaWAN-enheter (HTTP Webhooks) - via LoRaWAN gateway og LoRaWAN nettverks- / applikasjonsservere

• Ethernet-kontrollere (UDP / TCP-kommunikasjon)

• WiFi-kontrollere (UDP / TCP-kommunikasjon)

• Fremtidige IP-produkter

• Ikke IP-produkter via ekstra lokale @ City / eHouse.PRO Hardware Gateway

@City IoT Platform er dedikert til enheter / noder:

• Native iSys-produkter:

  • CIoT (GSM / 2G / 3G / 4G / CATM1 / NBIoT)

  • IoT (LoRaWAN)

  • WiFi - dedikerte produkter for @City Platform

  • Ethernet - dedikerte produkter for @City Platform

• Samproduksjonsprodukter (produsert av tredjeparter under iSys-lisens og eksternt merke)

• Franchiseprodukter (produsert av tredjeparter under iSys-lisens med iSys-logoer)

1.5. @City Cloud Server

@City-programvaren fungerer på Linux-basert VPS (Virtual Private Server) eller Dedikert server på internetsiden, avhengig av ønsket ytelse til Server (kalt senere Server):

• privat / offentlig tilgang

• samlede enheter teller

• oppdatering av enhetens statusfrekvens

• dataoppdateringsfrekvens

Flere varianter av VPS finnes avhengig av:

• Pris

• datasenterets geolokalisering

• Virtuelle prosessorkjerner (1-8)

• Virtuelt RAM (1-32 GB)

• SSD-disk (20 GB-1 TB)

Dusinvis av dedikert server eksisterer avhengig av:

• Pris

• datasenterets geolokalisering

• Prosessorkjerner (4 .. 32)

• RAM (16 .. 512GB)

• SSD / HDD (256 GB .. 8TB)

Plattformen @City is er dedikert til enkeltkunder:

• lokale myndigheter og myndigheter (by, samfunn, land)

• B2B (for tredjepartseier)

Fordi det ikke kan deles server mellom kunder, forenkler det sikkerhetsadgang og ytelsesproblemer. Av denne grunn er det kun kunden som er ansvarlig for effektiv sikkerhet, stabilitet, effektivitet, datakapasitet osv. Ved utilstrekkelig ytelse kan kunden kjøpe høyere plan (VPS eller dedikert server), mer optimal enn forventet funksjonalitet og ytelse.

I spesielle tilfeller "Cloud to cloud" kommunikasjon kan implementeres for globalisering og sentralisering av data til større områder i stedet for sky for flere kunder.

1.5.1. Server- og kommunikasjonsportaler

Kommunikasjon av @City Server realiseres basert på applikasjon på lavt nivå for ytelsesmaksimalisering.

Hovedfunksjonene i @City Server-applikasjonen er:

• motta asynkront data fra enheter (via protokoller: UDP, TCP IP, HTTP)

• minimere dataanvendelse og kostnadene mellom enheter og Cloud (ved å bruke kommunikasjonsprotokoller med lavt nivå UDP, TCP IP)

• motta kryptert status på enheter (via ethvert kommunikasjonsmedium)

• autorisasjon og validering av data fra enheter ved å dekryptere statusene deres

• dekoding av enhetsstatus og oppdatering til MariaDB / MySQL-tabeller direkte (i rådataformat)

  • nåværende datatabell (inneholder bare nyeste status for hver enhet)

  • historisk datatabell (inneholder alle statuser for en enhet)

• sende ventende kommandoer (hendelser) til enheter

• sikre håndtrykk, bekreftelse og bekreftelser

@City Server-programvaren er den samme for hver bruker og kan ikke tilpasses for forskjellige kunder.

1.5.2 HTTP LoRaWAN-integrasjon

LoRaWAN-kontrollere er integrert med @City-skyen via HTTP-grensesnittet (webhooks) tilgjengelig på LoRaWAN-nettverket / applikasjonsserveren.

Flere typer nettverks- / applikasjonsserver støttes:

TTN (begrenset tid "On The Air" og maksimalt antall kommandoer som sendes til driveren og ikke støtter fastvareoppgradering)

LoraWAN-Stack (Krever hosting på en fysisk enhet med internettilgang).

LoraServer.Io (Krever hosting på en fysisk enhet med internettilgang - bare sender data til serveren og støtter ikke firmwareoppgradering)

@City Cloud for LoRaWAN-kontrollere er delt på samme måte som for andre grensesnitt. Det er diskutert i forrige kapittel.

1.5.3. Front-end grensesnitt

Front-end-grensesnitt er realisert med PHP-skript for å trekke ut tilpassede data fra @City Cloud Database. Den bruker veldig elastisk søkemekanisme, basert på originale SQL-spørsmål for å begrense ønsket data. Interface leverer søkeresultater i JSON-format for videre dekoding og behandling av JavaScript Front-end Web "applikasjon".

Det originale frontgrensesnittet er det samme for hver bruker og kan ikke tilpasses for forskjellige kunder.

Overleggsgrensesnitt kan opprettes av personalet vårt eller i samarbeid for å sikre kundetilpasning.

1.5.3. Server tilgangsrettigheter

Kunders tilgangsrettigheter (til fysisk Server) er begrenset.

Filtilgang bare for "maler" -katalogen (innfødte tekstfiler - .txt, .js, .css, .html):

• legge til, fjerne, modifisere rene HTML-filer (Front-End GUI / Interface Development)

• legge til, fjerne, modifisere rene JavaScript filer (Front-End GUI / Interface Development and Algorithms)

• legge til, fjerne, modifisere rene CSS-filer (Front-End - tilpassede visninger / temaer)

• legge til, fjerne, modifisere tekstfiler i maler (Front-End GUI)

• legge til, fjerne, endre faner, snarveier, lenker til dateresultater

Andre tilgangsrettigheter:

• Full tilgang til @City Cloud Database MySQL / MariaDB der alle enhetsdata lagres

• Tilgang til webtjenester er definert (legitimasjon) for kunden.

• Kunden har ikke lov til å gi legitimasjon til tredjeparter (flere tilganger til resultatene kan påvirke ytelse, stabilitet og sikkerhet for det samlede systemet)

• Under spesielle omstendigheter og bruk av dedikert server med høy ytelse, kan det være satt opp offentlig konto for å observere de fleste aktuelle data (ikke historiske).

• Brukeren kan duplisere data til sin egen MySQL-server og utføre egne dataanalyser og -behandling, for ikke å påvirke ytelsen til @City Server

iSys - Intelligent Systems-ansatte - har ubegrenset tilgang til hele serveren inkludert root-konto og full DB-tilgang for vedlikehold.

Under visse omstendigheter kan iSys gi ytterligere begrensede rettigheter til kunder (PHP-skript, filer) etter å ha sjekket kildekoden, kjørt tester, hvis det ikke påvirker den generelle systemsikkerheten, stabiliteten og ytelsen.

1.6. Smarte enheter

1.6.1. CIoT - GSM-enheter

Enhetene våre inneholder mikrokontroller og GSM / GPS / GNSS-modul (2G..4G, NBIoT, CATM1) for kommunikasjon. Microcontroller inneholder kryptert bootloader for sikker OTA fastvareoppgradering. Dette gjør det mulig å lage mange systemvarianter basert på det samme "CIoT Smart-enhet".

1.6.3. BAS, BMS, IoT - Ethernet- og WiFi-enheter

Ethernet- og WiFi-kontrollere tillater IP-basert kommunikasjon til systemet (uten betaling for dataoverføring til GSM-operatøren). Disse enhetene har også kryptert bootloader, og enheter kan oppdateres via det opprinnelige grensesnittet. For WiFi har den OTA-firmwareoppgradering fra hovedserveren

1.6.2. IoT - LoRaWAN-enheter

LoRaWAN muliggjør dataoverføring over veldig lange avstander (opptil ca. 15 km). Dette området avhenger av hastigheten på dataoverføring, datamengden, urbaniseringen av området og effektiviteten til radiobanene til enhetene.

Enhetene våre inkluderer en mikrokontroller og LoRaWAN-modul for kommunikasjon. Mikrokontrolleren inneholder en kryptert bootloader for sikker OTA-programvareoppdatering. Dette lar deg lage flere systemvarianter basert på det samme "IoT smart device". Enhetene fungerer i det åpne ISM-båndet uten ekstra abonnementsgebyrer. Det er nødvendig å bruke LoRaWAN Gateways for å dekke hele området med tilgang til Internett. Når det gjelder eksisterende LoRaWAN-porter innen enhetsområdet (konfigurert for TTN-server), er det mulig å sende informasjon gjennom dem. Firmware-oppgradering krever eget LoRaWAN-server / nettverk og et godt utvalg for kommunikasjon.

1.7. Business to Business (B2B) -alternativer

Det er flere muligheter for virksomhet og samarbeid:

• importere / eksportere klare produkter (sentralbord, enheter) - sluttprodukter

• importere / eksportere OEM-produkter (PCB, kontrollere, etc) - mellomprodukter, reservedeler

• franchise - produksjon basert på lisensen vår for lokale markeder (vi leverer kun programmerte mikrokontrollere) under iSys - Intelligent Systems Brands

• Samproduksjon - (som ovenfor), men under eksterne merker

2. @City IoT Plattformfunksjonalitet

@City-plattformen støtter tilpassbar Front-End-mal for datavisualisering, spørring, begrensning og prosessering (Gjeldende / historikkdata):

• visualisere valgte data på kartet (geolokalisering)

• viser utvalgte data og resultater i tabellene

• viser valgte data i søylediagrammer

• viser utvalgte data i historiske diagrammer

• eksportere data til tredjepartsapplikasjoner og videre behandling

• annen funksjonalitet vil bli oppdatert på individuelle forespørsler.

Brukerens front-end er tilgjengelig via statisk IP- eller DNS-omdirigeringsdomene / underdomener / fil hvis tilgjengelig.

Eksemplarisk og demoinstallasjon (Den er bare aktivert for potensielle kunder).

Vennligst informer oss når du vil teste det - for å gi offentlig tilgang til plattformen.

Det kan kreve statisk IP på den eksterne datamaskinen for å muliggjøre kommunikasjon til @City-plattformen.

3. Hovedside

Hovedsiden er tom med vilje av sikkerhetsmessige årsaker: http: //% YourIP% / IoT /

Det kan aktiveres og redigeres individuelt og inneholder lenker til alle tilgjengelige tjenester fra @City IoT Plattform hvis det er nødvendig

4. Hovedskjema

Hovedskjema er ment å lage nye forhåndsinnstillinger og faner: http: //%IP%/IoT/que.php

Dette er det første skjemaet for å lage resultater, visninger og faner for hver konfigurasjon

Beskrivelser (fra topp og venstre til høyre retning)

4.1. Overskrift

4.1.1. Hjemmekobling - (åpner faktisk resultattabell)

4.1.2. "X" avkrysningsrute - åpner / lukker spørringsskjema

4.1.3. "V" avkrysningsrute - åpner / lukker feltskjema

4.1.4. Grafiske ikoner - lenker til visualiseringsresultater (redigerbar)

4.2. Skjema:

4.2.1. "X" avkrysningsrute - åpner / lukker hele spørringsskjemaet

4.2.2. CSS - Velg Visualiseringstema

Modify Visualization Theme CSS file must exist in "maler / css /" katalog - automatisk oppført.

4.2.3 Synlige felt avkrysningsrute - viser / skjuler feltfilterliste

4.2.4. Tab: Fanenavn for å legge til eller fjerne

4.2.5. Legg til fjern Knapper - Legg til eller fjern faner med navnet i Tab felt

4.2.6. Velg Core Knapp

Velg hovedfelt som er synlige på bordet. Den er oppdatert automatisk.

4.2.7. Opphev alle Knapp

Fjern merket for alle felt (må følges ved å velge noen av dem manuelt)

4.2.7. Velg alle Knapp

Velg alle felt (må følges ved å fjerne merkingen for noen av dem manuelt)

4.2.8. Skjul filter - Skjul hele skjemaet

Dette tilsvarer alle (X) avmerkingsbokser

4.2.9. Henrette Knapp - Endre parameterinnstillinger

4.2.10. "V" avkrysningsrute - vis / høyfilterfelt.

4.3. Faner

Individuelt opprettet faner med navn og forhåndsinnstillinger (lagret i cfg / tabs.cfg fil).

Filen inneholder faktisk navn og URL (atskilt med tabulatortegn).

4.4. Innhold i tabellen

Viser alle felt som er begrenset av feltfilter.

Felter i tabellen:

4.4.1. Løpe - viser resultattype

kart- kartleggingsresultater på kartet (ett eller flere felt kan velges)

historie - historiske diagrammer (ett eller flere felt kan velges)

tab - viser tabell (hvilken som helst kombinasjon av felt kan velges)

bar - bare ett felt vises i søylediagrammet

Når du trykker på en av verdien, åpnes det nye resultater med valgte felt (for gjeldende rad).

4.4.2. Kopier (+/- lenker)

Legge til / fjerne en fane med navnet satt i Tab felt. Den bruker bare felt valgt i samme rad i tabellen.

4.4.3. Tabellcellekoblinger

Hvis du trykker på et hvilket som helst annet feltnavn, startes datavisualisering av valgt felt for valgt rad.

4.5. Datarekkefølge

Rekkefølgen på viste felt er som rekkefølgen i feltform (dog tm feltet sendes alltid til slutten av teksten). Denne rekkefølgen kan bare endres ved direkte redigering av URL-parametere (feltbestillingsdel).

4.6. Eksempel

For eksempel: Innstillingsfane med Sporing av aktiva navn og inneholder kart med tid og hastighet på kartet

All beskrivelse med henvisning til rad hvor "Map" teksten er i "Løpe" kolonne.

1. Skriv inn navn "Sporing av aktiva" i Tab felt (uten anførselstegn)

2. Forsikre deg om at alle kolonnene ikke er valgt i raden

3. å velge tm, gps_hastighet_km bare på rad

4. trykk + knappen der på rad

5. Kart

Kart kan lanseres fra MainForm med forhåndskonfigurasjon

5.1. Kartinitialisering

Kartinitialisering utføres manuelt når den kjøres direkte med lenke: > http: //%IP%/IoT/maps.php

1. 
   Brukeren bør fjerne merket for alle felt (trykk på Fjern markeringen Knapp)

2. Trykk på noen avkrysningsruter for viste felt (f.eks. Ain5 (for Smog-nivå) og tm (for måledato / tid)

3. trykk "V" avkrysningsruten for å skjule feltform

4. trykk Henrette -knappen for å kjøre DB-spørring og vise gjeldende informasjon fra alle sensorer / enheter

5. Kart med data oppdateres etter 30 sekunder eller mer.

5.2. Valgfrie innstillinger for spørring

Innstillinger beskrevet fra venstre til høyre (på skjermbildet ovenfor).

5.2.1. Endre MAP-skala (zoomnivå)

1. Zoomnivået kan endres ved hjelp av (+/-) knappene for skala (henholdsvis gjeldende skala * 2 eller gjeldende skala / 2). Ved å trykke på en av disse knappene endres skalaen automatisk.

2. En annen måte er å velge Zoomnivå inn Zoom Kombinasjonsfelt og trykk Henrette knapp. I dette tilfellet lastes hele kartet på nytt og oppdateres (tar litt tid under initialisering).

5.2.2. IMEI (Velg enhetsfelt)

IMEIfeltet inneholder enhets-unik ID eller unikt alias for en enhet. Standardinnstillingen er * (stjerne) som viser de nyeste verdiene og geolokaliseringen for hver enhet.

Hvis du setter IMEI til en hvilken som helst annen verdi, vises historiske data for valgt enhet. Det har bare mening for mobile og bevegelige sensorer, ellers overlapper resultatene på kartet i samme posisjon.

5.2.3. Lon, Lat (Lengdegrad, koordinatfelt for breddegrad)

Still inn midtposisjonen til kartet. Dette feltet er satt til markørposisjon når museknappen trykkes på kartet.

5.2.4. Endre MAP-stil (tema)

Kartstil / tema kan velges fra Map ComboBox-felt (f.eks. Mørk, grå, topografisk).

Ulike karttemaer kan ha forskjellige maksimale zoomnivåer, slik at det kan håndheve riktig tema for å øke kartskalaen.

5.2.5. HVOR Klausul

Hvor klausul brukes til ytterligere spørringsstreng {WHERE part} for MySQL / MariaDB.

Denne paragrafen blir tatt i betraktning for å konstruere komplett QUERY-streng for databaseresultat. Det kan begrense data, tid og andre verdier ved å begrense antall resultater. Originale tabellfeltnavn (ikke alias) må brukes i dette feltet. F.eks.

1. gps_speed_km> 10 // hastighet er mer enn 10 km / t

2. ain5> 3 // ain5 er større enn 3 (holder 2,5um partikler teller - smog nivå)

3. gps_speed_km> 10 og ain6> 5 // hastighet er mer enn 10 km / t og ain6 er større enn 5 (holder 10um partikler teller - smog nivå)

5.2.6. Henrette (Kjør spørringsknapp)

Å trykke på denne knappen er nødvendig for å endre innstillinger, parametere (unntatt å trykke på +/- knappene).

Kart er lastet fra begynnelsen med nye forhåndsinnstillinger.

Kart er ikke lastet i det hele tatt når ingen data er tilgjengelig for gjeldende spørring.

5.2.7. Opphev alle (Fjern alle feltene fra spørringen)

Etter å ha trykket på denne knappen, må minst ett felt velges manuelt for å vise resultatene på kartet.

5.2.8. "V" Avkrysningsrute (Åpne / lukk feltskjema)

Denne avkrysningsboksen brukes til å vise / skjule velgeren for feltene som skal vises.

5.2.9. "X" Avkrysningsrute (Vis / skjul spørringsskjema)

Denne avkrysningsruten aktiverer skjul hele skjemaet bortsett fra ( +/- knapper)

Resultatene på kartet oppdateres kontinuerlig og oppdateres med nye verdier

5.3. Eksempel

Eksempelvis Smog-resultater (Sensor installert på bilen): Smog-nivå 2.5um partikler (Ain5), Hastighet (gps_hastighet_km), Dato / tid (tm), kart (2 - topografisk), zoomnivå 16,

Hvor klausul:

"gps_fix = 3 og tm> "2019-02-18 00:00:00" og tm <"2019-02-19 00:00:00" og gps_speed_km> 0".

// GPS = gyldige 3D-resultater & dato = 2019-02-18 & hastighet> 0 km / t

6. Vis resultater i tabellen

Vis resultater i tabellen.

På "Hovedskjema" trykk "bord" etter å ha valgt noen felt for å vise forhåndskonfigurert tabell

6.1. Initialisering av tabellen

Når bordet er åpent fra lenken http: //%IP%/IoT/que.php? func = faner det krever forhåndsinitialisering av innstillingene.

Du kan velge synlige felt (ved å trykke på "Synlige felt" ) avkrysningsruten.

1. Trykk på alle nødvendige avmerkingsbokser for viste felt

2. Trykk avkrysningsruten "Synlige felt" for å skjule feltform

3. Trykk på Utfør-knappen for å kjøre DB-spørring og visningstabell

6.2. Valgfrie innstillinger for spørring

Innstillingene er beskrevet fra venstre til høyre (på skjermbildet).

6.2.1. Sorter - sortere felt og rekkefølge stigende / synkende

Sorteringsfelt tilsvarer å trykke på kolonneoverskrift.

6.2.2. DB / IMEI - Velg Enhet

IMEIfeltet inneholder enhets-unik ID eller unikt alias for en enhet. Med tom verdi viser den tabellen over de siste verdiene.

Hvis du setter IMEI til en hvilken som helst annen verdi, vises historiske data for valgt enhet.

6.2.3. CSS - velg stil (Visualiseringstema)

6.2.4. Synlige felt - Vis / skjul feltform

6.2.5. Fjern tom - Ikke vis tomme kolonner

6.2.6. "X" Avkrysningsrute (Vis / skjul spørringsskjema)

6.2.7. Hvor Klausul (for databegrensning)

Dette er sufix for MySQL / MariaDB ekstra spørringsstreng {WHERE part}

Denne paragrafen blir tatt i betraktning for å konstruere fullstendig QUERY-streng for databaseresultat. Det kan begrense data, tid og andre verdier ved å begrense antall resultater. Originale tabellfeltnavn (ikke alias) må brukes i dette feltet. F.eks.

1. gps_speed_km> 10 // hastighet er mer enn 10 km / t

2. ain5> 3 // ain5 er større enn 3 (holder 2,5um partikler teller - smog nivå)

3. gps_speed_km> 10 og ain6> 5 // hastighet er mer enn 10 km / t og ain6 er større enn 5 (holder 10um partikler teller - smog nivå)

6.2.8. Velg Core Knapp (Aktiver de vanligste feltene)

6.2.9. Opphev alle Knapp (Fjern alle feltene fra spørringen)

Etter å ha trykket på denne knappen, må minst ett felt velges manuelt for å vise resultatene på kartet.

6.2.10. Henrette (Kjør spørringsknapp)

Å trykke på denne knappen er nødvendig for å endre innstillinger, parametere (unntatt å trykke på +/- knappene).

Tabellen lastes om fra begynnelsen med nye forhåndsinnstillinger.

6.2.11. "V" Avkrysningsrute (Åpne / lukk feltskjema)

Denne avkrysningsboksen brukes til å vise / skjule velgeren for feltene som skal vises.

Resultatene i tabellen er sortert etter Sortere feltinnstilling. Sorteringsrekkefølgen kan endres ved å trykke på radoverskrift (en gang i en retning to ganger i en annen retning).

Noen resultater i kolonner lenker til ytterligere visualiseringsskjermbilder (hardkodet).

Når du viser historiske data for enheten, bør det være begrenset for ikke å vise hele historikkinformasjonen, fordi det kan føre til ytelse eller problemer med minne.

7. Søyle diagram.

Søylediagrammer skal utføres fra hovedskjema ved å trykke på ett felt i "Linje" -raden.

Den viser sorterte søyler normalisert til maksimal verdi, og viser fra høyeste til laveste rekkefølge.

Det er nyttig for rask kontroll av ekstreme resultater og tiltak.

Mouse Over-hendelsen vil vise tilleggsinformasjon for enheten.

8. Historiske diagrammer.

Historiske diagrammer kan startes fra MainForm når du trykker på valgt kolonne i "Historikk" -raden (for ett felt).

For flere felt i "Historikk" -raden må ønskede felt kontrolleres og "Historikk" -koblingen må trykkes i "Kjør" -kolonnen.

Historiske resultater er begrenset til siste 24 timer + neste 24 timer (for eventuelle oppdateringsdiagrammer), da ingen grenser ble satt opp.

8.1. Initialisering av historiske kart

Historiske diagrammer når de åpnes fra hovedlenken krever initialisering som andre resultater, når de er åpne fra lenken uten preferanseparametere.

Flere felt kan velges for å vise forskjellige elementer. Den kan også angis i feltfilterform.

1. Trykk på alle nødvendige avmerkingsbokser for viste felt

2. Trykk avkrysningsruten "Synlige felt" for å skjule feltform

3. Trykk på Utfør-knappen for å kjøre DB-spørring og vise tabellen

8.2. Valgfrie innstillinger av historiske diagrammer

Elementer beskrevet fra toppen og fra venstre til høyre (på skjermbildet).

8.2.1. IMEI - (Velg enhet for å vise historiske data)

IMEIfeltet inneholder enhets-unik ID eller unikt alias for en enhet. Med * (asterix) -verdien viser den tabellen over de siste verdiene som ikke har noen mening.

Hvis du setter IMEI til en hvilken som helst annen verdi, vises historiske data for valgt enhet.

8.2.2. Min - begrense minimumsverdien av første felt

8.2.3. Maks - begrense maksimumsverdien for første felt

8.2.4. "V" - Vis / skjul feltform

8.2.5. Fra: angi minimal dato / tid (*)

8.2.6. Til: angi maks dato / klokkeslett (*)

8.2.7. "X" Avkrysningsrute (Vis / skjul spørringsskjema)

8.2.8. "Hvor" Klausul

Klausul for å begrense dateresultatene MySQL / MariaDB ekstra spørringsstreng {WHERE part}.

Denne paragrafen blir tatt i betraktning for å konstruere komplett QUERY-streng for databaseresultat. Det kan begrense data, tid og andre verdier ved å begrense antall resultater. Originale tabellfeltnavn (ikke alias) må brukes i dette feltet og gyldig SQL-syntaks. F.eks.

1. gps_speed_km> 10 // hastighet er mer enn 10 km / t

2. ain5> 3 // ain5 er større enn 3 (holder 2,5um partikler teller - smog nivå)

3. gps_speed_km> 10 og ain6> 5 // hastighet er mer enn 10 km / t og ain6 er større enn 5 (holder 10um partikler teller - smog nivå)

8.2.9. Opphev alle Knapp (Fjern alle feltene fra spørringen)

Etter å ha trykket på denne knappen, må minst ett felt velges manuelt for å vise historiske resultater.

8.2.10. Henrette (Kjør spørringsknapp)

Å trykke på denne knappen er nødvendig for å endre innstillinger, parametere (unntatt å vise felt eller spørringspanel). Tabellen lastes om fra begynnelsen med nye forhåndsinnstillinger.

8.2.11. "V" Avkrysningsrute (Åpne / lukk feltskjema)

Denne avkrysningsboksen brukes til å vise / skjule velgeren for feltene som skal vises.

8.3. Barer Variant: (viser bare tilgjengelige data)

8.4. Kontinuerlige variant (med samme data):

Musepekeren viser målinger og dato / klokkeslett.

9. Nettleser Kompatibilitet

* - Firefox støtter ikke dato / klokkeslett (tekstfeltet må redigeres manuelt med riktig datoformat).

Internet Explorer støttes ikke (bruk Kant i stedet)

Andre nettlesere ble ikke testet.

10. Temaer Tilpasning

Nettsider er basert på generell malfil som ligger på "maler" katalog "* .template".

I tillegg inneholder hver sidetype:

1. "* .head" -fil som lagrer sidehode på siden (lenker, importert CSS, JavaScript filer osv. )

2. "* .foot" -filer som lagrer bunntekst på siden (lenker osv. )

Visualiseringstema kan endres i henhold til brukerinnstillinger ved å kopiere og endre CSS-filer. CSS-filer ligger i "maler / css" katalog. Ulike nettsidetemaer kan brukes til å lage optimalisert for f.eks. utskrift, SmartPhones, PAD-maler.

Table visninger - har valgbart felt for å velge CSS-fil for fullstendig endring av temaet (lagret i "maler / css / faner" katalog).

Map utsikt - generelt tema er valgt av "kart" skriv kombinasjonsboks. I tillegg er det standard CSS-fil "maler / css / map.css" som inneholder litt ekstra funksjonalitet som å skjule / fargelegge resultater basert på verdiene. Resten av denne CSS-filen er praktisk talt begrenset til spørrings- og feltformer.

Mest av @City-plattformen PHP-filer for visualisering godtar cssparameter med verdien av filnavnet for temaet (uten utvidelse). Filen må være plassert i katalogen "maler / css", og navnet skiller mellom store og små bokstaver.

Noen elementer i temavisning er plassert direkte i JavaScript-filen i "mal / js" katalog.

Hoved @By manus"@ City.js" ligger i øvre katalog. Det er ingen modifikasjonsmuligheter i dette plassering, men skriptet kan kopieres til "maler / js" katalog og endret der. Bruk av individuelt skript krever oppdatering av alle headerfiler.

11. Algoritmer oppdatering

Noen unike sensorer kan kreve dedikerte beregningsfunksjoner.

Det er ingen mulighet for å oppdatere og vedlikeholde flere varianter av @City Server-programvare, Front-end PHP-grensesnitt, som ville forårsake mange problemer, versjoner, feil.

Den beste og enkleste måten å oppnå det på er å oppdatere over "overlegg" -filer for riktig visning av verdien / beskrivelsen.

Originale JS-skript er åpne tekstfiler og kan bli tatt i bruk etter kundenes behov. Som nevnt i forrige kapittel, må de kopieres til "maler / js" katalog der kunden har tilgangsrettigheter for endring.

Teknisk aspekt ved programmering av @By systemet er ikke gjenstand for dette dokumentet, men webutvikler med grunnleggende kunnskap om HTML og JS kan tilpasse Front-end-applikasjon til individuelle kundebehov.

12. Databasestruktur

@City Database med navn "IoT" eller "* IoT" er delt inn i tabeller (hvor asterix er prefiks, avhengig av hosting-server - om nødvendig). DataBase kan bli observert i PHPAdmin (webapplikasjon) på link http: //% IP% / phpmyadmin

Tabeller angitt for hver enhet (hvor * {asterix} er IMEI-adresse - unik ID):

• "* _t" - tokens for autorisasjon for nåværende brukere (brukes ikke til skyer med en kunde)

• "* _c" - kommandoer (hendelser) kø - som skal sendes til enheten

• "*" - alle dekodede statusresultater.

Andre tabeller:

• "ithings_" tabell - inneholder avkodet gjeldende status for alle enheter (den kopieres under oppdatering av noen av "*" tabeller). Struktur av ithings_ bordet er nesten det samme som "*" bord. "ithings_" har flere felt for postadresse og beskrivelser.

• "brukere" -tabellen er begrenset og bør endres.

12.1. "ithings_" og "*" tabellstruktur

• "idx" - indeks

• "tm" - automatisk tidsstempel

• "dt" - unix tidsstempel

• "imei" - unik enhetsadresse

• "rssi" - RSSI signalnivå

• "rsrp" - RSRP-signal

• "arrangementer" - ventende hendelser som skal sendes til kontrolleren

• "ut1" .. "ut16" - dekodet utgangsstatus

• "in1" .. "in16" - dekodet inngangsstatus

• "ain1" .. "ain8" - dekodede ADC-verdier (RAW)

• "sens1" .. "sens8" - konverterte sensorverdier (avhenger av enhetstype)

• "dimm1" .. "dimm8" - dekodede dimmerverdier (avhenger av enhetstype)

• "int1" .. "int6" - dekodede tellere (avhenger av enhetstype)

• "tekst1" .. "tekst6" - dekodede tekstverdier (avhenger av enhetstype)

• "opprettelse" - dato / klokkeslett for oppretting av enheten

• "siste" - siste dato / tid

• "bruker" - fremtidig bruk

• "pass" - fremtidig bruk

• "sn" - gsm serienummer

• "status" - gjeldende kontrollerstatus ikke dekodet i hex-format

• "hash_code" - fremtidig bruk

• "addr" - kort enhetsadresse

• "fwnr" - firmware nr

• "deaktivert" - deaktivert enhet (ikke utført)

• "gsm_nr" - CIoT gsm-nummer

• "leverandør" - leverandørkode (for franchise / samproduksjon)

• "tidssone" - tidsforskyvning

• "dst" - Bruk daglige sparingsinnstillinger

• "gps_lat" - GPS Latitude

• "gps_long" - GPS lengdegrad

• "gps_hdop" - GPS HDOP

• "gps_alt" - GPS-høyde

• "gps_fix" - GPS-fiksering (må være 3 - for gyldige resultater)

• "gps_cog" - GPS tannhjul

• "gps_hastighet_km" - GPS-hastighet i [km / t]

• "gps_sat" - GPS-satellitter funnet

• "kontinent", "land", "region", "underregion", "underregion", "by", "distrikt", "gate", "street_nr", "item_nr" - Kundeadresse og beskrivelsesfelt (!!!! Ikke tilgjengelig for "*" historiske tabeller)

• "logg" - loggdata
  
  Feltnavnene er viktige for å opprette SQL-spørringer for å øke søkefunksjonaliteten fordi originalt navn må brukes i SQL Statement.
  
  

12.2. Enhetskommandoer (hendelser) kø "* _c" tabellstruktur

Denne tabellen er hendelse / kommandokø for hver enhet og har følgende struktur:

• "kommando" - kommando som skal sendes eller allerede sendes til kontrolleren

• "bekreftet" - bekreftelsesflagg hvis det allerede var sendt og bekreftet

• "date" - unix tidsstempel for hendelsen

• "oppdatert" - automatisk oppdateringsflagg (tidsstempel dato / klokkeslett)

12.3. Få tilgang til resultater fra databaser - Midtnivå (lesedata)

Data kan være tilgjengelig uten Front-end webapplikasjon. @City-systemet inneholder skript med mellomnivåfunksjoner. Resultatene returneres i JSON-format.

12.3.1. Få gjeldende statuser for alle enhetene

http: //%IP%/IoT/que.php? func = devsjson

Spørringen returnerer hel "_ithings" tabell (nåværende status for alle enheter) i JSON-format:

[{ "land":"", "by":"", "kontinent":"", "land":"", "region":"", "underregion":"", "underregion":"", "by":"", "distrikt":"", "gate":"", "gate_nr":"", "vare_nr":"", "gps_lat":"0000.0000N", "gps_long":"00000.0000E", "tm":"2019-02-10 12:56:23", "opprettelse":"2019-02-09 18:12:38", "siste":"0000-00-00 00:00:00", "arrangementer":"", "bruker":"", "sende":"", "imei":"351580051067110", "sn":"", "status":"73000200000f360033026800240000002c002c002dffffffffffffff5b63000001c1000001c2000000000000000009250a4f0a760a7a0a750a780a7e0000031d032205fc34029b025c025600460eb305320000", "hash_code":"", "addr":"", "fwnr":"", "funksjonshemmet":"", "gsm_nr":"", "Leverandør":"", "tidssone":"", "dst":"", "rssi":"91", "rsrp":"99", "gps_lat":"0000.0000N", "gps_long":"00000.0000E", "gps_hdop":"", "gps_alt":"", "gps_fix":"4", "gps_cog":"", "gps_hastighet_km":"", "gps_sat":"", "arrangementer":"", "ut1":"0", "ut2":"0", "ut3":"0", "ut4":"0", "ut5":"0", "ut6":"0", "ut7":"0", "ut8":"0", "ut9":"0", "ut10":"1", "ut11":"0", "ut12":"0", "ut13":"0", "ut14":"0", "ut15":"0", "ut16":"0", "in1":"0", "in2":"0", "in3":"0", "in4":"0", "i5":"0", "in6":"0", "in7":"0", "in8":"0", "i9":"0", "i10":"0", "i11":"0", "i12":"0", "i13":"0", "i14":"0", "i15":"0", "in16":"0", "ain1":"3894", "ain2":"51", "ain3":"616", "ain4":"36", "ai5":"0", "ain6":"44", "ain7":"44", "ain8":"45", "sens1":"0", "sens2":"0", "sens3":"0", "sens4":"0", "sens5":"0", "sens6":"0", "sens7":"0", "sens8":"0", "dimm1":"255", "dimm2":"255", "dimm3":"255", "dimm4":"255", "dimm5":"255", "dimm6":"255", "dimm7":"255", "dimm8":"255", "int1":"-16776767", "int2":"450", "int3":"", "int4":"", "int5":"", "int6":"0", "tekst1":"", "tekst2":"", "tekst3":"", "tekst4":"", "tekst5":"", "tekst6":"" }]

12.3.2. Få historiske data for enheten

Spørrehistoriske data for enkelt enhet av IMEI nr:

http: //%IP%/IoT/que.php? func = imeijson & imei = 356345080018095

Fordi hele tabellen kan inneholde millioner av rader, bør den begrenses med WHERE-setningen for ikke å legge på serveren.

Flere parametere url-parametere:

func - imeijson

imei - IMEI for enheten

felt - felt som skal vises i resultatene (komaseparert liste)

min - minimumsverdi for det første feltet fra listen

maks - maksimumsverdi for det første feltet fra listen

sellert - felt for sortering

tm - felt legges automatisk til resultatene.

where - hvor klausul om å begrense data

Eksempel:

Vi ønsker å få følgende resultat

for enhet med imei=356345080018095

Vis felt: ain5, ain6, gps_lat, gps_long

og begrense ai5 innen rekkevidde ( 1, 10000 ) - må være det første feltet i listen

og GPS har gyldige data (gps_fix = 3)

og dato / tid (tm) from2019-02-14 23:00:19 to 2019-02-15 00:00:00

Konstruert URL-streng:

http: //%IP%/IoT/que.php? func =imeijson& imei =356345080018095& felt =ai5, ain6, gps_lat, gps_long& min =1& maks =1000& hvor =gps_fix = 3 og tm> "2019-02-14 23:00:19" og tm <"2019-02-15 00:00:00"

Spørringsresultater:

[{ "ai5":"66","ain6":"68","gps_lat":"5202.7326N","gps_long":"02115.8073E","tm":"2019-02-14 23:04:31" }, { "ai5":"67","ain6":"76","gps_lat":"5202.7328N","gps_long":"02115.8075E","tm":"2019-02-14 23:05:42" }, { "ai5":"63","ain6":"77","gps_lat":"5202.7328N","gps_long":"02115.8074E","tm":"2019-02-14 23:06:05" }, { "ai5":"58","ain6":"77","gps_lat":"5202.7328N","gps_long":"02115.8075E","tm":"2019-02-14 23:06:32" }, { "ai5":"58","ain6":"68","gps_lat":"5202.7328N","gps_long":"02115.8076E","tm":"2019-02-14 23:06:55" }]

12.3.3. Få en liste over enheter - enkelt felt fra gjeldende statuser med begrensning

Denne funksjonen returnerer begrensede data fra "_ithings" -tabellen

http: //%IP%/IoT/que.php? func = fieldjson & field = ain5 & min = 13 & max = 5000

Parametere:

func - fieldjson

felt - felt som skal vises i resultatene - imei og tm blir automatisk lagt til

min - minimumsverdi for feltet

maks - maksimal verdi for feltet

For ovennevnte spørringsstreng returnerer den resultater av ain5, imei, tm Enger:

hvis ai5 er innen rekkevidde (13,5000)

Spørringsresultater:

[{"imei":"353080090069142", "tm":"2019-03-14 11:51:01", "ai5":"14" },

{"imei":"356345080018095", "tm":"2019-02-20 09:13:04", "ai5":"115" },

{"imei":"karczew", "tm":"2019-03-07 13:08:22", "ai5":"103" }]