Sviluppo di dispositivi KNX

Dall’idea originaria al prodotto finito, per un novizio di KNX l’elenco di domande su come implementare KNX in un nuovo dispositivo può essere piuttosto lungo:

Quale mezzo trasmissivo KNX (ad esempio doppino intrecciato o radiofrequenza) dovrebbe essere usato?
Quali requisiti software sono richiesti da KNX?
Quali oggetti di comunicazione – formati dati – dovrebbero essere impiegati e come vengono programmati?
Quali sono i requisiti hardware per il dispositivo?
Vi sono componenti standard?
Come verrà messo in servizio il dispositivo, ad esempio, quali modi di configurazione dovrebbero essere supportati?
Vi è supporto tecnico per l’assistenza durante lo sviluppo?
Come si svolge il processo di certificazione?

Per valutare quale sia soluzione migliore per lo sviluppo di un dispositivo, è utile conoscere quali siano i componenti standard KNX disponibili sul mercato per i differenti mezzi trasmissivi.

Per maggiori informazioni sui dispositivi KNX disponibili, vi preghiamo di contattare i membri KNX seguenti:

Eelectron

Opternus Components GmbH

Tapko Technologies GmbH

Weinzierl Engineering GmbH

www.eelectron.com

www.opternus.com

www.tapko.de

www.weinzierl.de

Aspetti di realizzazione di dispositivi KNX TP

Esistono una serie di termini tecnici che sono comuni sul mercato come “BCU“, “BIM“, “SIM“, “TPUART“, “chipset“ e “communication stack“: questi termini corrispondono a differenti possibilità di sviluppo di un dispositivo KNX TP.

BCU “Bus coupling units“
Si tratta di dispositivi di sistema che comprendono il circuito di accoppiamento a KNX ed un microprocessore e sono forniti in una custodia. Lo sviluppatore deve limitarsi a sviluppare il modulo applicativo, l’hardware ed il software applicativo.

BIM “Bus Interface Modules“
Sono moduli di interfaccia costituiti fondamentalmente dall’interno di una BCU e dispongono di porte di I/O aggiuntive. Le BIM vengono vendute come moduli che possono essere saldati direttamente alla piastra a circuito stampato. Sono disponibili versioni con memoria flash per il software applicativo da 8 fino a 48 kbyte. Lo sviluppo software avviene per mezzo di un ambiente di sviluppo che consiste di un “Evaluationboard“, un “On-Chip Debug Emulator“ e di un compilatore per linguaggio C.

SIM “Serial Interface Modules“
I moduli SIM contengono il sistema di comunicazione completo senza applicazioni; l’hardware ed il software applicativo sono collegati con la parte di comunicazione per mezzo di un’interfaccia seriale. I SIM vengono venduti sotto forma di moduli che possono essere saldati direttamente alla piastra a circuito stampato.

BAOS “Bus Access Object Server“
Il modulo BAOS (Bus Access and Object Server) serve come interfaccia verso KNX tanto a livello di telegramma (Link Layer KNX) quanto a livello di datapoint (Application Layer KNX). Il formato del telegramma corrisponde a FT1.2. Per la comunicazione a livello di datapoint è disponibile un protocollo seriale ottimizzato.

Chipset
I chipset delle BIM vengono offerti separatamente per aggirare i vincoli meccanici delle BIM. Dal punto di vista software non vi sono differenze fra BIM e chipset.

TPUART
La TPUART contiene solo il vero e proprio accoppiamento a KNX. Il software di comunicazione è fornito da un microcontrollore collegato La TPUART è stata sviluppata da un lato per evitare al microcontrollore il compito di codifica e decodifica dei bit e dall’altro per consentire l’accoppiamento a KNX per mezzo di diversi microcontrollori.

Communication Stack
Per piccole quantità di prodotto si raccomandano i moduli (BIM, SIM BAOS). Si distinguono per i bassi costi di sviluppo e certifi cazione e sono ideali per avviare uno sviluppo KNX. Se non c’è spazio o crescono le quantità prodotte, il chipset è un’alternativa interessante. I costi iniziali sono solo un po’ più alti in confronto al modulo BIM. TPUART è la soluzione più utilizzata per i dispositivi prodotti in serie in grandi quantità. La TPUART si distingue per bassi costi unitari ma comporta costi elevati di sviluppo e certifi cazione. In certi casi può essere opportuno optare per un bit transceiver (FZE1066).

Aspetti di realizzazione di dispositivi KNX PL

Analogamente a KNX Twisted Pair, BCU e moduli (PIM) standardizzati sono disponibili anche per KNX PL (110).

BCU “Bus coupling units“
Si tratta di dispositivi di sistema che comprendono il circuito di accoppiamento a KNX ed un microprocessore e sono forniti in una custodia. Lo sviluppatore deve limitarsi a sviluppare soltanto il modulo applicativo, l’hardware ed il software applicativo.

PIM „Powerline Interface Modules“
I moduli PIM sono costituiti fondamentalmente sulla parte a bassa tensione della BCU. I PIM sono moduli che vengono saldati alla piastra a circuito stampato insieme agli altri componenti di accoppiamento alla rete.

ASIC con Communication Stack
Un ASIC per PL110 è responsabile dell’invio e della ricezione dei bit. Per costruire un dispositivo KNX basato su ASIC,è necessario uno stack KNX per Powerline (communication software). Un communication stack contiene le interfacce per la programmazione dell’applicazione.

Qual’è la soluzione giusta?

Le BCU sono particolarmente indicate per produzione di piccole quantità per sviluppare dispositivi in modo efficiente dal punto di vista dei costi. Per prodotti caratterizzati da quantità medie, sono raccomandati i moduli PIM ed uno schema del circuito è disponibile. Lo sviluppo di dispositivi PL con ASIC e communication stack richiede maggiori investimenti in confronto a BCU e PIM ed è perciò effettuato da costruttori con volumi di produzione elevati.

Aspetti di realizzazione di dispositivi KNX RF

Lo sviluppo di dispositivi KNX RF non richiede componenti speciali KNX. Per ridurre tempi e costi di sviluppo, può essere vantaggioso l’impiego di moduli RF pronti; ciò avviene di solito nel caso di piccole quantità. Un nodo KNX RF consiste fondamentalmente degli elementi seguenti:

Transceiver Chip
Per KNX RF non è necessario un chip dedicato. Attualmente sono disponibili un paio di chip che possono essere impiegati per implementare un nodo KNX RF. Per dispositivi unidirezionali sono disponibili chip a basso costo per la sola trasmissione.



Circuito RF
Il transceiver forma, insieme ad una coppia di componenti passivi, il circuito RF. Basato sul progetto di riferimento del costruttore del chip, un circuito può essere progettato ed ottimizzato per i requisiti KNX RF.



Microcontrollore
Il cuore di ogni dispositivo KNX è un microcontrollore che controlla la comunicazione ed i compiti applicativi. Per la trasmissione RF uno dei requisiti più importanti è il basso consumo di energia. La logica di interfacciamento per connettere il transceiver dovrebbe essere presente nella maggior parte dei controllori odierni.



Communication stack
Lo standard KNX definisce un complesso protocollo che porta ad uno sforzo elevato di implementazione e certificazione. Il communication stack è il software di sistema per un dispositivo KNX RF; controlla il transceiver e gestisce completamente la comunicazione, compresa la procedura di configurazione. Il communication stack fornisce un’interfaccia (API) per lo sviluppo applicativo.

Aspetti di realizzazione di dispositivi KNX IP

La trasmissione di telegrammi KNX per mezzo di Ethernet è defi nita come serie di protocolli KNXnet/ IP ed è parte dello standard KNX. Fino ad ora le specifi che prevedevano l’utilizzo di questo mezzo per le interfacce PC ed i router. I router IP sono paragonabili agli accoppiatori di linea ma utilizzano Ethernet per la linea principale. Ora in aggiunta è possibile integrare dispositivi terminali KNX direttamente via IP nella rete KNX. In questo modo Ethernet o IP (Internet Protocol) diviene a pieno titolo un mezzo trasmissivo KNX. Per lo sviluppo di dispositivi KNX IP non sono necessari componenti KNX Bauteile speciali. Un nodo KNX IP consiste principalmente degli elementi seguenti:

Controller Ethernet
I Controller Ethernet sono disponibili presso diversi produttori di semiconduttori. Le esigenze di KNX IP sono di norma soddisfatte senza problemi. Sono suffi cienti nella maggior parte dei casi Controller mit einer velocità di 10 MBit/s.

Microcontrollore
La scelta del microcontrollore dipende fondamentalmente dalla potenza di calcolo necessaria al dispositivo. In linea di principio, il protocollo KNXnet/IP può essere implementato su un controllore ad 8 bit. A seconda dell’applicazione, possono essere necessari anche controllori con prestazioni superiori. Numerosi controllori offrono già un’interfaccia Ethernet sul chip, in modo che debba essere completato solo il livello fi sico.

Communication stack
Il software di sistema per un dispositivo KNX IP è costituito da due stack di protocollo. Per la comunicazione mediante Ethernet è necessario uno stack IP con UDP (User Datagram Protocol), poichè KNXnet/IP si basa su una comunicazione wireless. Vengono utilizzati sia telegrammi Unicast che Multicast. Sullo stack IP/UDP viene disposto lo stack KNX. Questo è il kernel comune KNX che naturalmente deve essere implementato in modo speziale per ogni modello di dispositivo. Lo stack KNX utilizza lo stack IP/UDP come interfaccia verso il sistema. La traduzione di telegrammi KNX in telegrammi UDP è stabilita mediante KNXnet/IP. L’applicazione KNX ha accesso all’API (Application Programming Interface) dello stack KNX per comunicare con l’intero sistema.