IoT i CIoT-enheter - smarte løsninger

LoRaWAN & GSM - Smart City





iSys - intelligente systemer







UTKAST

Innholdsfortegnelse

1. Introduksjon. 3

1.1 @City (IoT / CIoT) Kommunikasjon 4

1.2. Maskinvareressurser for IoT / CIoT Devices 4

0..4 programmerbare binære innganger 4

0..4 programmerbare binære utganger 4

0..4 telleinnganger (ikke-flyktige tellere) 4

0..4 dimmere utganger (PWM eller 0..10V) 5

Infrarød inngang + utgang 5

0..4 måleinnganger (ADC) 5

serielle grensesnitt SPI / I2C / UART / CAN 5

1.3. @City GSM-enheter 6

1.4. @City LoRaWAN-enheter 9

Modulen uten LoRaWAN-modem og prosessor kan fungere som MEM-sensormodul for @City GSM, WiFi, Ethernet og andre arkitekturer (3v3..3v6 DC-drevet) 10

2. Generelle bruksbetingelser @City (LoRaWAN, GSM) Systems 11

2.1. Eksklusive vilkår for @City GSM. 11

2.2. Eksklusive betingelser for @City LoRaWAN. 12

3. @City (LoRaWAN, GSM) kontrollerkonfigurasjon 13

3.1. @City Controller Configuration - Tilordne navn 13

3.2. Generell konfigurasjon av @City LoRaWAN & GSM-kontrollere 14

3.2.1 Generell konfigurasjon av @City GSM-enhet 14

3.2.2. Generell konfigurasjon av @City LoRaWAN-kontrollere 17

3.3. Konfigurasjon av binære innganger 18

3.4. Konfigurasjon av binære utganger 19

3.5. Konfigurasjon av ADC-måleinnganger og tilleggssensorer (XIN) 21

3.6. Dimmerkonfigurasjon PWM / 0..10V 22

3.7. Konfigurasjon av kalenderplanlegger 24

4. LoRaWAN-nettverksinfrastrukturkonfigurasjon 26

4.1. LoRaWAN Gateway-konfigurasjon. 26

4.1.1. Grunnleggende konfigurasjon av LoRaWAN gateway 26

4.1.2. Semtech Packet Forwarder (SPF) Configuration 27

4.2. LoRaWAN Network / Application Server Configuration 28

4.2.1. LoRaWAN Network Server Configuration 29

5. Arbeidstilstand for @City GSM / LoRaWAN-enheter 31


1. Introduksjon.

De @By system støtter et antall elektroniske enheter (kontrollere) - kalt som node, mote, device. Mange typer kommunikasjon (kablet og trådløs) er tilgjengelig, avhengig av tilgjengelig infrastruktur, krav og forhold.

Enhetstyper tilgjengelig i @City-systemet:

Alle enhetene er integrert med hverandre via @By sky og det er en mulighet for hybrid samarbeid avhengig av tilgjengeligheten av en gitt kommunikasjonsinfrastruktur.

For bygninger og tilgjengelighet av LAN eller WiFi koblet til Internett kan vi bruke eHouse løsninger via eHouse.PRO server (som kan sende / motta data til @By Sky):

Følgende dokument beskriver GSM og LoRaWAN enheter basert på en enkeltbrikke-mikrokontroller (mikroprosessor) og et eksternt kommunikasjonsmodem. Dette gjør at systemet kan standardiseres til tross for forskjellen i kommunikasjonsmodem.

For andre kommunikasjonsvarianter, se eHouse dokumentasjon.



Dette gjør det mulig å oppnå lignende funksjonalitet og utstyr, samt enkel migrering til andre kommunikasjonsvarianter eller versjoner.

1.1 @City (IoT / CIoT) kommunikasjon

@City-systemet bruker for øyeblikket en av de valgte kommunikasjonsmodulene (modemene):

1.2. Maskinvareressurser for IoT / CIoT Devices

Hele "intelligens" av systemet ligger i mikrokontroller (mikroprosessor) og er ikke veldig avhengig av kommunikasjonstypen. Maskinvareressursene til IoT / CIoT-enheter (mikroprosessor) er som følger:

1.3. @City GSM-enheter

@City GSM Enheter kobles gjennom mobilnettet til GSM-mobiloperatøren gjennom en eller flere teknologier og tjenester. Disse tjenestene faktureres og avhenger av operatørene og tjenestene individuelt. Tjenesten er autorisert på samme måte som i mobiltelefoner via aktive SIM-kort:

Tilgjengeligheten av utvalgte tjenester avhenger av kommunikasjonsoperatøren og det innebygde GSM-modemet i produksjonsfasen:

1) 2G (alle operatører)

2) 2G / LTE CATM1 (Orange) - det er 2G tilbakefallsmulighet når CATM1 ikke er tilgjengelig.

3) 2G / NBIoT (T-Mobile / Deutsche Telecom) - det er 2G tilbakefallsmulighet når NBIoT ikke er tilgjengelig og operatøren tillater det.

4) 2G / 3G (alle operatører)

5) 4G / LTE (alle operatører)

6) Andre tjenestekombinasjoner kan også være tilgjengelige, avhengig av tilgjengelig modem og innstillinger.

De tre første løsningene fungerer på samme modem (NBIoT / CATM1 + fallback 2G). Ved bruk "plast" Nano SIM-kort er det mulig å bytte ut kortet og eksternt konfigurere enheten til å fungere skikkelig i en annen tjeneste. Når det gjelder MIM (SIM-kort i form av en chip (IC)), tas beslutningen på produksjonsstadiet for enheten, og det er ikke mulig å endre operatør eller tjeneste. NBIoT er dedikert til en veldig liten mengde overførte data ~ 512 kB per måned (vennligst forhandle denne verdien til operatøren), noe som er en betydelig hindring for noen CIoT / IoT-løsninger.

Løsning 4, 5 krever installasjon av andre modemer i produksjonsfasen.

Enhetens strømforbruk avhenger av tjenesten og vises fra laveste til høyeste:

- NBIoT

- CATM1

- LTE

- 3G

- 2G / SMS / USSD / GPRS / EDGE

Dataoverføringshastighet fra laveste til høyeste:

- NBIoT

- CATM1

- 2G / SMS / USSD / GPRS / EDGE

- 3G

- LTE



Alle @City GSM-enheter kan utstyres med en GPS-mottaker for geolokalisering og automatisk posisjonering på kart. De kan også fungere mobile når det er behov for målinger eller arbeide i bevegelse.




1.4. @City LoRaWAN-enheter

LoRaWAN er en lang rekkevidde kommunikasjonsløsning (opptil ca. 15 km) som arbeider i åpne ISM-bånd (f.eks. 433MHz, 868MHz, etc. ). Svært store områder krever imidlertid en betydelig reduksjon i overføringshastighet og datapakkelengde (f.eks. for det høyeste området opptil 250 bits per sekund og maksimalt 51 byte data - nyttelast). Overføring med repetisjoner og bekreftelser kan ta veldig lang tid, noe som kan eliminere LoRaWAN i noen løsninger. Antall LoRaWAN-gateways er også viktig for å sikre et godt utvalg av enheter, som lar deg jobbe med høyere hastigheter, færre feil og mindre repetisjoner.

LoRaWAN-enheter kommuniserer med @City sky via LoRaWAN Gateways, som må gi dekning på det nødvendige nivået for alle tilgjengelige LoRaWAN-enheter. I tillegg må disse gatewayene være koblet til LAN eller Internett via en hvilken som helst lenke for å kunne sende data til LoRaWAN-nettverket / applikasjonsserveren (NS / AS).

Webserveren brukes til toveiskommunikasjon med LoRaWAN-gateways og for å sende informasjon til / fra LoRaWAN-enheter.

Nettverks- / applikasjonsserveren kan være lokalisert local eller i tjenesteleverandørens datasenter. Data fra enhetene sendes fra nettverks- / applikasjonsserveren via integrasjonsprotokoller til @City sky (via webhook). Dette muliggjør direkte integrering av @City LoRaWAN system med @City databaser.



Applikasjonsserveren kan i tillegg implementere utvidet logikk og BIM (informasjonsmodellering) for systemet, behandle data ved mottak og sende kontrollkommandoer (hendelser) til individuelle enheter som svar.

@City LoRaWAN-enheter inneholder tilleggsfunksjoner som:


Modulen uten LoRaWAN-modem og prosessor kan fungere som MEM-sensormodul for @City GSM, WiFi, Ethernet og andre arkitekturer (3v3..3v6 DC-drevet)

2. Generelle bruksbetingelser @City (LoRaWAN, GSM) -systemer

MERK FØLGENDE! Feil innstilling av hovedparametre for kommunikasjonsgrensesnitt kan føre til ødeleggelse eller permanent blokkering av enheten (som vi ikke har fysisk tilgang til).

Eventuell kontrollerens oppdatering av en firmware og endelig konfigurasjon må utføres og testes (for alle enheter og i minst en uke for flere enheter) før du installerer dem på destinasjonsstedet.

Produsenten er ikke ansvarlig for feil konfigurering / programvareoppdatering utført av uautoriserte personer, samt utførelse på steder for installasjon av individuelle kontrollere.

Alle kostnadene ved avinstallering, tjenester, reparasjon, erstatning, reinstallasjon dekkes av systembrukeren (ikke produsenten).

For å oppdatere fastvaren og konfigurasjonen er det nødvendig å sikre et tilstrekkelig signalnivå og tilgjengeligheten av de nødvendige tjenestene. Ovennevnte aktiviteter kan være umulige på de endelige installasjonsstedene til kontrollerne og i deres innhegninger. De kan også avhenge av årstid, vær og forplantning av radiobølger.

Alle kostnader for tjenester relatert til konfigurasjon / firmwareendring bæres av brukeren (tilleggsavgifter for dataoverføring, mulig avinstallering, installasjon av enheter, opplåsing, erstatning osv. ).

Maksimal rekkevidde er rent teoretisk, målt under ideelle radioforplantningsforhold og refererer til drift av enheter (med eksterne og matchede antenner) i synsfeltet (uten hindringer i signalstrålen). Avhengig av urbanisering av området, trær, vær, beliggenhet og installasjonsmetode, kan rekkevidden være verre flere hundre ganger enn dataene ovenfor.

2.1. Eksklusive vilkår for @City GSM.

Brukeren bærer kostnadene og er ansvarlig for rettidig betaling av GSM-operatørabonnement og @City server hosting. Manglende kontinuitet i tjenesten kan forårsake irreversible endringer av kritiske overføringsparametere og blokkering av hele systemet (f.eks. endring av statisk IP-adresse, tap av internettdomene, tap av data / konfigurasjon på serveren, tap av programvare, sikkerhetskopier, etc. ).

I tilfelle brukeren betaler de ovennevnte beløpene som en fast pris til produsenten av @City-systemet, er ikke produsenten ansvarlig for endringene i tilbudet eller avslutningen av tjenester utført av eksterne enheter.

Systemprodusenten er ikke ansvarlig for kvaliteten på tjenestene som tilbys av tredjeparter, inkludert GSM-operatøren, ekstern @City-hosting. Produsenten er ikke ansvarlig for forverring av rekkevidden for radiobølgeutbredelse (f.eks. på grunn av opprettelsen av nye bygninger, endringer i plasseringen av GSM kringkastingsstasjoner (BTS), trær osv. ).

I tilfelle av dataoverføringsgrenser (spesielt for NBIoT), bør programvarekonfigurasjon og oppdatering utføres i begynnelsen av abonnementsperioden, med lavest mulig dataforbruk. Ellers er det mulig å blokkere enheten til slutten av faktureringsperioden på grunn av blokkeringer knyttet til overskridelse av overføringsgrensen.

GSM-operatøren er ansvarlig for kvaliteten på GSM-tilkoblingen, ikke produsenten av @City-systemet.

Brukeren erklærer at han / hun godtar følgende informasjon og godtar den.

2.2. Eksklusive betingelser for @City LoRaWAN.

Brukeren bærer kostnadene og er ansvarlig for rettidig betaling av leie- og installasjonsgebyrer for LoRaWAN gateway, LoRaWAN Network / Application Server og @City server hosting. Manglende kontinuitet i tjenesten kan føre til irreversible endringer av kritiske overføringsparametere og permanent systemblokkering (f.eks. endring av statisk IP-adresse, tap av domene, tap av data / konfigurasjon på serveren, tap av programvare, sikkerhetskopier, etc. ).

I tilfelle brukeren legger de ovennevnte forpliktelsene på en fast pris til @City-produsenten, er ikke produsenten ansvarlig for å endre vilkårene eller avslutte tjenestene som tilbys av eksterne enheter.

Systemprodusenten er ikke ansvarlig for tjenester levert av eksterne enheter, inkludert noen LoRaWAN-operatører, som er vert for LoRaWAN-nettverket / applikasjonsserveren, ekstern @City-serverhosting. Produsenten er ikke ansvarlig for forverring av rekkevidden for radiobølgeutbredelse (f.eks. på grunn av opprettelsen av nye bygninger, endringer i plasseringen av LoRaWAN gateways, skader på LoRaWAN gateways, strømbrudd, trær, interferens, signaltap osv. ).

I tilfelle av dataoverføringsgrenser, bør programvarekonfigurasjon og oppdatering utføres i begynnelsen av abonnementsperioden, med minst mulig dataforbruk. Ellers er det mulig å blokkere enheten til slutten av faktureringsperioden på grunn av blokkeringer knyttet til overskridelse av overføringsgrensen. Oppdateringen skal utføres en kontroller fra begynnelse til slutt og teste korrektheten av arbeidet. Å kjøre oppdateringen for alle kontrollere kan føre til at radiobåndet blokkeres helt i mange dager.

LoRaWAN bruker offentlig tilgjengelig "åpne radioband" (433 eller 868 MHz for EU), som kan bli forstyrret eller okkupert av andre enheter som fungerer på de samme frekvensene. Produsenten er ikke ansvarlig for kvaliteten på kommunikasjonen i ovennevnte tilfelle.

Brukeren er ansvarlig for å dekke området med riktig antall LoRaWAN-porter og deres plassering for å oppnå riktig signalnivå for alle enheter og hele @City LoRaWAN-systemet.

@City GSM-enheter kan brukes på steder som er sterkt utsatt for signalinterferens.

Brukeren erklærer at han / hun godtar følgende informasjon og godtar den.

3. @City (LoRaWAN, GSM) kontrollerkonfigurasjon

Systemkonfigurasjon utføres via nettgrensesnittet. Konfigurasjon er veldig viktig for @City-kontrollere, og feil innstillinger kan føre til at systemet blokkeres helt. Det anbefales at full malkonfigurasjon (standardinnstillinger) blir utført og testet av @City-systemprodusenten.

3.1. @City Controller Configuration - Tilordne navn


Kontrollerens adresse 000000000000000 (15 nuller for GSM / 16 for LoRaWAN) er standardadressen som gjelder alle kontrollere i familien (dvs. for det samme Leverandørkoden og Filkode, og samme type LoRaWAN / GSM-kontroller. Hvis kontrolleren ikke har definert sin egen individuelle konfigurasjon, lastes standardkonfigurasjonen inn i den.

Når det gjelder GSM-kontrollere, tilsvarer denne adressen det unike IMEI-nummeret (15 tegn) som er tildelt av produsenten av GSM-modemet.

Når det gjelder LoRaWAN-kontrollere, tilsvarer denne adressen det unike "Dev EUI" nummer gitt av produsenten av LoRaWAN-modemet (16 tegn i heksadesimal kode).

Leverandørkoden - er en unik parameter for kunden (bruker)

Filkode - er en parameter som angir typen firmware (avhengig av utstyr og tilgjengelige algoritmer)

I de fleste tilfeller er det tilstrekkelig å konfigurere denne enheten (standard) for hele systemet eller som en mal for andre drivere. Når du oppretter en ny kontrollerkonfigurasjon, kopieres disse innstillingene fra malen.

Både fastvare og konfigurasjoner for alle installasjoner (forekomster) ligger på serverne til @City-systemprodusenten som er tilgjengelig via WWW, som brukeren kan ha begrenset tilgang til. Den riktige konfigurasjonen er imidlertid veldig kritisk, og det anbefales ikke å gjøre endringer uten å teste på flere enheter med full fysisk tilgang (på pulten). For mer informasjon, vennligst sjekk de generelle vilkårene for @City-systemet og de spesifikke vilkårene for en bestemt måte å kommunisere på.

3.2. Generell konfigurasjon av @City LoRaWAN & GSM-kontrollere

3.2.1 Generell konfigurasjon av @City GSM-enhet

Før du starter konfigurasjonen, må du lese de generelle vilkårene for @City-systemet og systemspesifikke betingelser for @City GSM.




Leverandørkoden - inneholder 8 tegn lagret i heksadesimal kode dedikert til en kunde (bruker). Det gis på produksjonsstadiet for kontrolleren. Et forsøk på endring kan forårsake permanent skade på kontrolleren.

Filkode - inneholder 8 tegn lagret i heksadesimal kode, dedikert til en firmwareversjon av kontrolleren. Det gis på produksjonsstadiet for kontrolleren og kan avhenge av typen kommunikasjon (GSM / LoRaWAN) og tilleggsutstyr, f.eks. sensorer, antall innganger / utganger og individuelle algoritmer. Endringen kan forårsake permanent skade eller blokkering av kontrolleren.

PIN-nr. - 4-sifret pin-nummer hvis det er angitt for SIM-kortet. Det anbefales ikke å angi PIN-koder. For SIM-kort av plast kan du fjerne dem på mobiltelefonen. Innføring av feil SIM-kort kan føre til permanent blokkering av kortet i enheten (som vi til slutt ikke vil ha fysisk tilgang til).

SMS-nr. - SMS-nummer når du sender status via SMS. Dette alternativet er tilgjengelig avhengig av tjenesten og operatøren (2G / CATM1 / NBIoT). Det krever også å slå på flagget: SMS aktivert.

USSD Str - USSD-kommando for sending av statuser via USSD. Dette alternativet er bare tilgjengelig for utvalgte typer GSM-modemer (2G / 3G + GPS). Valget: USSD aktivert kreves. Operatøren må tilby og aktivere USSD-tjenesten.

APN - Navn på tilgangspunkt. Navnet på internettilgangspunktet, f.eks. internett (for spesielle tjenester som LTE-M1 eller NB-IoT kan den tildeles individuelt av operatøren).

WWW-adresse - nettadresse (domene eller IP) for HTTP-tilgang.

WWW-side - nettsideadresse, der kontrollerstatus og kommandoer sendes.

HTTP aktivert - Aktiverer HTTP-dataoverføring. Denne metoden genererer mange ganger mer dataoverføring enn alle andre kommunikasjonsmetoder, noe som kan føre til økte kostnader som overskrider overføringsgrensen eller manglende evne til å bruke noen tjenester, for eksempel NBIoT.

TCP / UDP-adresse - IP-adressen til @City-serveren for mottak og overføring av data mellom skyen og enhetene. Det anbefales å bruke en fast IP-adresse, ikke en internett-domeneadresse.

TCP-port - TCP / IP-port for kommunikasjon

TCP aktivert - Lar deg aktivere TCP / IP-overføring. Overføringsrammer og TCP-bekreftelser øker datamengden i forhold til UDP-overføringer, men de sørger for korrekte data, bekreftelser og garanterer levering, hvis kommunikasjon er tilgjengelig.

UDP-port - Port for mottak av status via UDP

UDP aktivert - Slå på overførings-UDP

Aux-adresse, Aux-port, Aux-aktivering - fremtidige applikasjoner

Aux2-adresse, Aux2-port, Aux2 aktivert - fremtidige applikasjoner

Aktivering av sensorstøtte (de må være fysisk montert på @City-modulen). Ellers kan enheten fungere mye tregere og mindre stabil. Sensorer er installert på produksjonsstadiet for hele produksjonsserien.

Temp, presure, fuktighet, gass - integrert sensor for temperatur, trykk, fuktighet og luftkvalitet

Temp + Presure - Integrert temperatur- og trykksensor

Gyroskop - Gyroskopføler i 3 akser (X, Y, Z)

Magnetometer - Magnetisk sensor i 3 akser (X, Y, Z)

Akselerometer - Akselerasjon / vibrasjonssensor i 3 akser (X, Y, Z)

Farge - Fargesensor (R, G, B, IR, G2)

Ambient + proximeter - integrert lysnivå og (10 cm rekkevidde) proksimetersensor

GSM-kommandoer - tilleggskommandoer for initialisering av modem

Hash-kode - En ekstra krypteringskode. Ikke forandre.

HTTP-overføring - Ytterligere HTTP-kommunikasjonsalternativer

Global adresse - Den globale adressen til kontrolleren for enhet-til-enhet-kontroll.

GSM-modus - GSM-kommunikasjonsmodus (kun 2G, bare LTE, CATM1, NBIoT, 2G + CAT M1, LTE 800, LTE 1800). Feil innstilling av kommunikasjonsmodus kan føre til permanent blokkering av enhetskommunikasjon.

3.2.2. Generell konfigurasjon av @City LoRaWAN-kontrollere

De fleste alternativene er de samme som i GSM-kontrolleren. I prinsippet brukes ikke alle felt relatert til GSM-kommunikasjon under drift av LoRaWAN-kontrolleren. LoRaWAN-enheter har forskjellig firmware som støtter LoRaWAN-modulen i stedet for GSM.

På @City LoRaWAN på enhetssiden, er konfigurasjonen veldig enkel:

Søknad EUID - Program-ID for LoRaWAN-server (16 tegn i heksekode) - applikasjon definert på LoRaWAN Network / Application Server som vi sender data til.

Søknadsnøkkel - autorisasjonsnøkkel for søknad for LoRaWAN-server (som ovenfor)

Deaktiver adaptiv datahastighet - Deaktiverer valg av adaptiv hastighet. Dette lar deg tvinge en konstant hastighet på enheten. I noen situasjoner kan dette føre til store kommunikasjonsproblemer. Det bør tas i betraktning at når RSSI- og SNR-parametrene forbedres i adaptiv modus, øker hastigheten betydelig. Dette reduserer tiden for dataoverføring via radio betydelig "On The Air Time" og mye oftere kan informasjon overføres mellom enheten og serveren og omvendt.

Datahastighet (DR) - Valg av LoRaWAN-koblingshastighet. Denne hastigheten gjelder ikke Bootloader. I tilfelle kontrolleren fungerer i den adaptive hastighetsinnstillingsmodusen, er det bare startverdien, fordi kontrolleren etter flere forsøk på overføring automatisk velger den optimale hastigheten for å begrense tiden for meldingsoverføring i luften.

Oppdater innstillinger - lagrer startkonfigurasjonen av kontrolleren - alle innstillinger



Resten av @City LoRaWAN-konfigurasjonen ligger i de gjenværende elementene i LoRaWAN-konfigurasjonsskjermene i kapittel 4.

3.3. Konfigurasjon av binære innganger




Binære innganger har en rekke funksjoner og parametere som muliggjør autonom drift av kontrolleren:

Inverter - inngangsnegasjon når sensorer "normalt tilkoblet" (NC) er tilkoblet.

Alarm - aktivering av alarmfunksjonen.

Alarmforsinkelse - Alarmforsinkelsestid. Hvis inngangstilstanden går tilbake til sin opprinnelige tilstand før denne tiden har utløpt, vil ikke alarmen bli aktivert.

Husk staten - På tide å huske endringen av inngangstilstanden.

Deaktiver kjøring - Blokkering av løpende hendelser relatert til innspillene.

Løpe - Kjør kommandoen for inngangskonfigurasjon (Ad-Hoc)

Kopiere - Kopier kommandoen for inngangskonfigurasjon til utklippstavlen

Arrangement på - Beskrivelse av hvordan du kjører hendelsen for høyt inngangsnivå (1)

Direkte begivenhet på - Hendelseskode som skal kjøres når inngangen er på (0 => 1)

Event Off - Beskrivelse av hendelsesaktivering for lavt inngangsnivå (0)

Direkte begivenhet av - Hendelseskode som skal kjøres når inngangen er av (1 => 0)

Alarmhendelse - Beskrivelse av alarmhendelsen.

Direkte alarmhendelse - Hendelseskoden som skal utløses når det oppstår en alarm

Oppdater innstillinger - lagrer oppstartskonfigurasjonen for alle innstillinger

3.4. Konfigurasjon av binære utganger




Intelligente binære utganger kan fungere som enkle eller doble. Skjemaet lar deg opprette en oppstartskonfigurasjon for kontrolleren (hvis du bekrefter den med Oppdater-knappen).

Skjemaet fungerer også som en hendelsesoppretter for utganger som kan startes ved å trykke på Run-knappen eller kopiere til utklippstavlen for bruk i kontrollerkonfigurasjonen, f.eks.



Konfigurasjon av enkeltutganger:

Deaktiver - Blokkering av utdata i enkeltmodus (f.eks. hvis den brukes til å kontrollere drivenheter for ikke å skade rulleskodder, porter, aktuatorer)

Administrator - Et administrativt flagg kreves når du endrer kritiske innstillinger

Stat - statusvalg (innledende konfigurasjon eller start av hendelsen med "run" knapp)

Gjentar seg - Antall repetisjoner (konjunkturendringer)

Tid på - Tid for aktivering av utgang

Fritid - Tid for å slå av utgangen (det er viktig når du gjentar hendelser)

Løpe - Kjør arrangementet for avslutning

Kopiere - Kopier hendelsen til utklippstavlen

Oppdater innstillinger - lagrer oppstartskonfigurasjonen for alle innstillinger

Dobbel utgangskonfigurasjon:

Deaktiver - Lås ut et par utganger i dobbel modus (f.eks. hvis det brukes som enkeltinnganger)

Administrator - Et administrativt flagg kreves når du endrer kritiske innstillinger som kjøremodus

Somfy - stasjonsmodus (avkrysset => Somfy / ukontrollert => Direkte servo)

Stat - statusvalg (for innledende konfigurasjon eller lunsj på arrangementet med "run" knapp)

Gjentar seg - Antall repetisjoner (syklisk endring av tilstander)

Tid på - Tid for sving på den gitte staten

Deaktiver tid - Tid til å blokkere utganger (minimum tid mellom utgangsendringene) for å beskytte stasjoner mot skade.

Fritid - Tid for å slå av utgangen (det er viktig når du gjentar hendelser)

Løpe - Kjør arrangementet for kjøreturen

Kopiere - Kopier hendelsen til utklippstavlen

Oppdater innstillinger - lagrer oppstartskonfigurasjonen for alle innstillinger

3.5. Konfigurasjon av ADC-måleinnganger og tilleggssensorer (XIN)




Inverter - invertert skala (100% -x) av ADC-inngangen

Alarm L - Aktivering av muligheten for å generere en alarm når verdien faller under min. terskel

Alarm H - Aktivering av muligheten for å generere en alarm når verdien overstiger maks. terskel

Alarmforsinkelse - Alarmforsinkelsestid. Hvis inngangsstatusen går tilbake til "OK" nivå før tiden går, vil ikke alarmen bli aktivert.

Event Deaktiver - Blokkering av gjennomføring av hendelser

Administrator - adminflagg som muliggjør endring av konfigurasjonen for måleinngang

LAV begivenhet - beskrivelse av hendelsen som ble utført da den lave terskelen ble overskredet

LAV direkte - hendelseskode som skal utføres etter å ha senket verdien under den nedre terskelen

Lavt nivå - Nivå av nedre terskel (min)

OK hendelse - Beskrivelse av "OK" begivenhet

OK direkte - hendelseskode som skal utføres etter at du har angitt "OK" område

HØY begivenhet - Beskrivelse av arrangementet for øvre terskel

HIGH Direct - hendelseskode som skal utføres etter å ha overskredet den øvre terskelverdien

Høy level - Nivå av øvre terskel (maks)

Løpe - kjører konfigurasjonshendelsen (endring av ADC Ad-Hoc-konfigurasjon)

Oppdater innstillinger - lagrer den opprinnelige konfigurasjonen for ADC-inngangene

3.6. Dimmerkonfigurasjon PWM / 0..10V




Inverter Demping av polaritet (100% - x)

Administrator - Et administrativt flagg som lar deg endre kritiske alternativer

Deaktiver - Blokkerer dimmerutgangen

En gang - Endre dimmerinnstillingene en gang (så stopp dimmeren)

Verdi Min - minimumsverdien for dimmerinnstillinger

Verdi - dimmerens målverdi

Modus - Dimmerinnstillingsmodus (Stopp / - / + / Sett)

Steg - Trinn for å endre dimmernivåverdien

Verdi Maks - maksimumsverdien for dimmerinnstillingen

Løpe - Kjører den dimmere begivenheten

Kopiere - Kopier hendelsen til utklippstavlen



RGBW-dimmeren henter innstillingsverdiene fra individuelle farger.

I tillegg lar den deg aktivere kontinuerlig fargeskiftemodus ved å bruke forhåndsinnstillingene til enkeltdimmere.

Oppdater innstillinger - lagrer oppstartskonfigurasjonen for alle innstillinger





Knapper:

Oppdater innstillinger - lagring av konfigurasjonen i @City-systemet

Alle kontrollere - en liste over alle kontrollere

Innstillinger - innstillinger for gjeldende kontroller

Endre navn - endre navnet på den nåværende kontrolleren

Planlegger - planlegger-kalenderredaktøren til den nåværende kontrolleren

Skriv Config * - sende en kommando for å laste ned konfigurasjonen av kontrolleren

Fastvareoppgradering * - sende en kommando for å laste ned firmware av kontrolleren

Tilbakestill kontroller * - sende tilbakestillingskommando for nedlasting av kontrolleren

Tilbakestill kontrolleren - kopier - kopi av tilbakestillingshendelsen til kontrolleren til utklippstavlen

Logg ut - avlogging av brukeren (av sikkerhetsmessige årsaker bør du også lukke alle åpne forekomster av nettleseren som kan lagre innloggingsparametrene i hurtigbufferen).

* - å sende kommandoen betyr å legge til hendelseskøen. Ved å koble kontrolleren til @City-systemet laster kontrolleren ned disse hendelsene.

3.7. Konfigurasjon av kalenderplanlegger


Kalenderplanleggeren tillater autonom utløsning av repeterende eller planlagte hendelser (kommandoer). Et eksempel kan være for eksempel å slå på gatelykten klokka 17 og slå av klokken 7 (om vinteren).

Slett (Slett) - sletter tidsplanen.

En. (Muliggjøre) - Aktiver tidsplanelement (bare de posisjonene vil bli utført som har Aktiver flagg satt)

Navn - Navn på hendelsen (du kan beskrive hendelsen på en gjenkjennelig måte)

Hendelseskode - hendelseskode i heksadesimal kode (kopiert fra utklippstavlen når du oppretter kommandoer)

Månedsfelt (Ja, Fe, .., No, De) - måneder januar ... Desember der arrangementet vil bli startet

Dag - Dag. Du kan velge hvilken som helst dag i måneden eller "*" for alle (kjører arrangementet hver dag).

Hverdagsfelt (Mo, Tu, .. Su) - du kan velge ukedagene der arrangementet skal utføres.

Time - Timen. Du kan velge hvilken som helst time eller "*" for alle (kjører arrangementet hver time).

Min - Minutt. Du kan velge hvilket som helst minutt eller "*" for alle (kjører arrangementet hvert minutt).



Logisk "og" algoritmen er implementert mellom alle felt (unntatt Navn ), så de må alle være oppfylt for at hendelsen skal gjennomføres.



F.eks. Slå på gatelyktene ( November, desember, januar, februar ) kl 17.01 uten Søndager.

En - valgt

Event code - 00002101010000000000 // kjøring av første binære utgang

Måneder felt - kun Nei, De, Ja, Fe er merket

Dag - valgt "*" for hver dag i måneden

Time - valgt tid er 17

Min - valgt minutt 01

Hverdagsfelt - alt utenom Su valgt

4. LoRaWAN Network Infrastructure Configuration

Dette kapitlet gjelder bare LoRaWAN-kommunikasjon. Når det gjelder systemer som bruker andre overføringsmetoder, kan det utelates.

I henhold til LoRaWAN-nettverksspesifikasjonen kobles kontrolleren indirekte til @City-skyen gjennom:

4.1. LoRaWAN Gateway-konfigurasjon.

Det er mange LoRaWAN-gateways på markedet som samtidig kan inneholde en rekke ekstra alternativer:

4.1.1. Grunnleggende konfigurasjon av LoRaWAN gateway

LoraWAN-gatewayen skal være tilgjengelig fra minst en konfigurasjonsstasjon.

Når du installerer via Ethernet / WiFi og kun konfigurerer fra et lokalt LAN / WLAN, er gatewayens sikkerhet ikke veldig kritisk (med mindre vi gir tilgang til gatewayen utenfra, dvs. internettet).

I tilfelle LoRaWAN-gatewayen bare er koblet til via GSM / LTE, er det nødvendig å sikre gatewayen mot tilgang og ulike typer angrep.

- Hvis vi vil kunne koble oss til LoRaWAN-gatewayen eksternt, må den ha en offentlig + statisk IP-adresse og SSH-tjeneste tilgjengelig. Ellers må du fysisk koble til gatewayen via et Ethernet- eller WiFi-grensesnitt.

- det er nødvendig å angi kompliserte tilgangspassord for alle brukere på enheten.

- deaktiver alle ubrukte tjenester som Telnet, FTP, POP, SMTP, IMAP, WWW etc. det kan være målet for angrep "okkuperende" porten med andre prosesser som påloggingsforsøk.

- du kan begrense muligheten for innlogging, bare fra stasjoner med utvalgte statiske IP-adresser, noe som er ganske effektiv beskyttelse mot hacking. Dette gjelder også tilsynelatende ubetydelige tjenester som ICMP (ping), HTTP, FTP, etc.

- etter full konfigurering og mange uker med systemtester, kan vi blokkere alle eksterne tjenester og ekstern tilgang, som imidlertid vil hindre tjenesten, søke og sjekke gatewayloggene.

4.1.2. Semtech Packet Forwarder (SPF) Configuration

SPFs oppgave er å sende LoRaWAN-pakker til LoRaWAN-nettverksserveren gjennom IP-nettverket (UDP-protokoll) til den nødvendige adressen til LoRaWAN-nettverksserveren.

LoRaWAN Gateway med SPF er gjennomsiktig og sender alle pakker i begge retninger.

Det behandler eller godkjenner ikke datapakker i noen retning.

Konfigurasjon av SPF er veldig enkel og involverer "regi" den til den nødvendige LoRaWAN-nettverksserveren.

Logg på via SSH til LoRaWAN-gatewayen ved hjelp av brukernavnet og passordet som er spesifisert av produsenten av enheten.

Installer SPF i henhold til LoRaWAN gateway-produsentens instruksjoner.

SPF-konfigurasjonskatalogen er "/ bruker / spf / etc /" avhengig av LoRaWAN gateway-produsenten, kan det imidlertid være lokalisert på andre steder.

Hovedkonfigurasjonen til SPF er i filen "/user/spf/etc/global_conf.json", som skal redigeres med den tilgjengelige redigereren (f.eks. vi eller nano). Vi endrer verdien av parameteren: "server adresse" ved å angi den faste IP-adressen til nettverksserveren eller domenenavnet (Krever en ekstra riktig konfigurert DNS-klienttjeneste).

Standard returkommunikasjonsport er 1700 (hvis du planlegger å endre dem, må du gjøre det samme på LoRaWAN-nettverksserveren) ved å angi identiske verdier.

Loggene til SPF-pakken ligger i "/ bruker / spf / var / logger /" katalog i spf.log filen og dens arkivkopier.

Nettverkskonfigurasjonen til LoRaWAN-gatewayen på Linux OS er normalt i katalogen "/etc/", der du kan aktivere / deaktivere standard nettverkstjenester og sikre serveren.

Du bør også endre passordene til alle brukere som er tilgjengelige på systemet med passwd kommando for å sikre mot uautorisert tilgang fra uvedkommende. Du må også endre brukerpassordet for nettbasert støtte.

Det er også best å deaktivere WiFi-kommunikasjon, da inntrengere kan prøve å bruke angrep via dette overføringsmediet.

Etter å ha fullført denne konfigurasjonen, tilbakestill gatewayen med start på nytt kommando.



4.2. LoRaWAN Network / Application Server Configuration

Det er mange løsninger for nettverks- og applikasjonsservere (inkludert gratis). Hver av dem har sin egen måte å integrere med eksterne tjenester og systemer (f.eks. skyer som @By ). Av denne grunn, @By systemet må ha et grensesnitt for integrering med den installerte LoRaWAN NS / AS-serveren.

I tilfelle et produksjonssystem kan vi bruke gratis tjenesten "The Things Network", så lenge vi er innenfor svært store daglige grenser definert for hver enhet {spesielt "On The Air Time" (30s **) og et lite antall kommandoer sendt til enheten (10 **)}.

** Veiledende gjeldende daglige enhetsgrenser kan endres.

Hvis du trenger å laste inn ny firmware og konfigurasjon, er det nødvendig å bruke din egen LoRaWAN-server (nettverk + applikasjon).

Dette gir oss flere alternativer:

På noen systemer er firmware + -konfigurasjonen løst (for alle tilgjengelige kontrollere i systemet) og startet på trinnet med den første systemkonfigurasjonen, noe som forenkler valget.

(*) - i disse tilfellene er det nødvendig å ha en annen LoRaWAN-gateway satt på den andre serveren for konfigurasjon og firmwareoppdatering for at produksjonsmiljøet skal fungere kontinuerlig. For lite kritiske applikasjoner kan du endre konfigurasjonen til en LoRaWAN gateway dedikert LoRaWAN-server, som imidlertid vil føre til tap av kommunikasjon med produksjonsmiljøet og feil drift av disse enhetene.

Det skal innse at programvareoppdateringen til en enkelt LoRaWAN-kontroller tar omtrent en time, med godt rekkevidde (DR> = 4), så det er verdt å bruke en ekstra gateway for å oppgradere fastvaren og konfigurasjonen. Ved lav dekning (DR <4) er ikke firmwarekonfigurasjon og oppdatering mulig og krever en gateway med LTE-kommunikasjon nær de oppdaterte enhetene.

4.2.1. LoRaWAN Network Server Configuration

På LoRaWAN-nettverksserveren legger du til LoRaWAN-kommunikasjonsgatewayen (adressen er plassert på omslaget eller i filen "bruker / spf / etc / local_conf.json", eller vises i loggene "/bruker/spf/var/log/spf.log". Sjekk i webserverloggene at kommunikasjonsgatewayen kobles til serveren.

De neste trinnene er konfigurasjonen av applikasjonsserveren (den ligger vanligvis på samme enhet som nettverksserveren).

De neste trinnene som skal utføres, avhenger av applikasjonsserverløsningen som brukes, og tilgjengeligheten av Back-End / Front-End-grensesnittet. Grensesnittet forenkler "første steg" og systemkonfigurasjon.

Generelt sett bør du:

 







5. Arbeidstilstand for @City GSM / LoRaWAN-enheter

Temperatur - 40C .. + 65C

Fuktighet 0..80% RF ingen kondens (enhet)

GSM Strømforsyning 5VDC @ 2A ±0,15 V (for PPM-sensor og ved tilkobling av releer)

3.5VDC..4.2VDC @ 2A (i andre tilfeller)


LoRaWAN power supply 5VDC @ 300mA ± 0,15 V (for PPM-sensor og ved tilkobling av releer)

3VDC..3.6VDC @ 300mA (i andre tilfeller)


GSM + GPS-enheter:

Antenneinngang 50ohm

SIM nano-SIM eller MIM

(valg på produksjonsstadiet - MIM pålegger en nettoperatør)

Modem Approval Orange (2G-CATM1), T-Mobile / DT (2G-NBIoT), 2G Andre operatører


BANDER (Europa) Klasseutgangseffektfølsomhet

B3, B8, B20 (CATM1 - 800MHz) ** 3 + 23dB ±2 < -107.3dB

B3, B8, B20 (NB-IoT - 800 MHz ) ** 3 +23dB ±2 < -113.5dB

GSM850, GSM900 (GPRS) * 4 + 33dB ±2 <-107dB

GSM850, GSM900 (EDGE) * E2 + 27dB ±2 <-107dB

DCS1800, PCS1900 (GPRS) * 4 + 30dB ±2 < -109.4dB

DCS1800, PCS1900 (EDGE) * E2 +26dB ±2 < -109.4dB

Når du bruker en ekstern smalbånds antennefrekvensmatchet for et gitt bånd.


* bare for Combo-modem: 2G, CATM1, NB-IoT

Sertifikater:



GPS / GNSS:

driftsfrekvens: 1559..1610MHz

antenneimpedans 50ohm

maksimal følsomhet * -160dB stasjonær, -149dB navigasjon, -145 kaldstart

TTFF 1s (varm), 21s (varm), 32s (kald)

A-GPS ja

Dynamikk 2g

minimal oppdateringsfrekvens 1 Hz


* matchet ekstern smalbåndsantenne



LoRaWAN-enheter 1.0.2 (8 kanaler, TX-effekt: + 14dBm) Europa (863-870MHz)

DR T modulering BR bit / s Rx Sensitivity Rx Tester

0 3min SF12 / 125kHz 250 -136dB -144dB

1 2min SF11 / 125kHz 440 -133,5dB

2 1min SF10 / 125kHz 980 -131dB

3 50-tallet SF9 / 125kHz 1760 -128.5dB

4 (*) 50-talls SF8 / 125kHz 3125 -125.5dB

5 (*) 50-talls SF7 / 125kHz 5470 -122.5dB

6 (*) 50-talls SF7 / 250kHz 11000 -119dB

7 FSK 50kbs 50000 -130dB

(*) Parametere som kreves for å oppgradere firmwaren til systemet via OTA

(DR) - Datahastighet

(BR) - Bithastighet

T - Minste periode med dataoppdatering til @City-skyen




LoRaWAN praktiske dekningstester:


Testbetingelser:

LoRaWAN Kerlink ifemtocell Intern gateway

passiv utendørs bredbåndsantenne plassert ute i en høyde av ~ 9m over bakkenivå Wygoda gm. Karczew (~ 110 moh).

LoRaWAN-enhet med tvungen DR0 med en ekstern bredbåndsmagnetisk antenne plassert 1,5 meter over bakken på biltaket.

Landlige områder (enger, felt med små trær og sjeldne bygninger)


Det lengste resultatet var Czersk ~ 10,5 km (~ 200 m over havet) med RSSI lik -136dB (dvs. med maksimal følsomhet for LoRaWAN-modemet garantert av produsenten)