Hoe te beginnen met ontwikkelen
KNX is het enige bussysteem in de wereld dat het volledige veld van transmissiemedia voor gebouwencontrolesystemen aanbiedt: Twisted Pair, Powerline, Radio Frequnecy and Ethernet IP. Transmissiemedia kunnen makkelijk aan elkaar gekoppeld worden met de KNX Media Couplers. De KNX busdeelnemers worden beheerd met ETS, het producent- en productonafhankelijke werktuig.
Vanaf het idee tot het afgewerkt product, de vragenlijst voor een KNX beginneling omtrent hoe KNX in een nieuw apparaat te implementeren kan behoorlijk lang zijn:
- Welk KNX medium (vb. Twisted Pair of Radio Frequency) moet ik gebruiken?
- Wat zijn de softwarevereisten van KNX?
- Welke communicatieobjecten – dataformaten – moeten gebruikt worden en hoe worden deze geprogrammeerd?
- Wat zijn de hardwarevereisten voor het apparaat?
- Zijn er standaardcomponenten?
- Hoe zal het apparaat in werking gesteld worden, welke configuratiemodus moet ondersteund worden?
- Is er technische ondersteuning dat mij kan bijstaan tijdens de ontwikkeling?
- Hoe verloopt het certificatieproces?
Het is nuttig om te weten welke KNX standaardcomponenten er voor de verschillende media op de markt beschikbaar zijn, om aldus een beter beeld te krijgen op de geschikte manier voor de ontwikkeling van een bepaald apparaat.
Voor meer informatie over de beschikbare KNX busdeelnemers, neemt u best contact op met:
Eelectron | Opternus Components GmbH | Tapko Technologies GmbH | Weinzierl Engineering GmbH |
Implementatieaspecten bij KNX TP Busdeelnemers
Er zijn verscheidene technische termen die gemeengoed zijn op de markt, zoals „BCU“, „BIM“, „SIM“, „TPUART“, „chipset“ en „communication stack“. Deze termen geven de verschillende mogelijkheden weer om een KNX TP busdeelnemer te ontwikkelen.
BCU „Bus coupling units“
Dit zijn systeemapparaten met een KNX koppelingscircuit, een microprocessor en ze worden geleverd met het huis. De ontwikkelaar moet enkel een toepassingsmodule, de hardware en de software ontwikkelen.
BIM „Bus Interface Modules“
Deze zijn op dezelfde manier opgebouwd als de binnenkant van een BCU met extra I/O poorten. BIMs worden verkocht als modules, die rechtstreeks op het circuitbord gesoldeerd kunnen worden. Er zijn versies beschikbaar met een flashgeheugen van 8kbyte of 48kbyte voor de apparaatsoftware. De softwareontwikkeling wordt uigevoerd in een ontwikkelingsomgeving, bestaande uit „Evaluationboard“, „On-Chip Debug Emulator“ en C-Compiler.
SIM „Serial Interface Modules“
Deze bevatten het volledige communicatiesysteem met toepassingen. De apparaathardware en software zijn gekoppeld met het communicatieonderdeel via een seriële interface. SIMs worden verkocht als modules die direct op het circuitbord worden gesoldeerd.
BAOS „Bus Access and Object Server“
The BAOS is zowel een KNX interface op telegram-niveau (KNX Link Layer) als op DataPoint-niveau (KNX Apllication Layer). Het telegramformaat is TF1.2 conform. Een optimaliseert serieel protocol op DataPoint-niveau is beschikbaar .
Chipset
Chipsets van BIMs worden aangeboden om de mechanische beperkingen van BIMS te omzeilen. Er is geen verschil tussen BIMs en chipsets op het vlak van software.
TPUART
De TPUART bevat enkel een koppeling met KNX. De communicatiesoftware wordt voorzien door een microcontroller. De TPUART werd enerzijds ontwikkeld om de microcontroller van de taken bit-codering en decodering te ontheffen, en anderzijds om de koppeling met KNX met andere microcontrolleres mogelijk te maken.
Communication Stack
Om een KNX busdeelnemer met de TPUART te ontwikkelen, is een communication stack noodzakelijk. Dit soort koppeling is de meest doeltreffende, flexibele en goedkoopste manier om een KNX busdeelnemer te ontwikkelen. Om te vermijden dat de ontwikkelaar zich volledig vertrouwd moet maken met de details van KNX communicatie, bieden verkopers van KNX systemen de KNX communication stack aan. De koppeling met KNX wordt verzorgd door een externe KNX koppelaar zoals TPUART, FZE1066. De KNX communication stack biedt extra interfaces om de eigenlijke toepassing te programmeren.
Wat is de beste oplossing?
Bij kleine productiehoeveelheden worden de modules (BIM, SIM en BAOS) aanbevolen, vanwege de lage ontwikkeling- en certificatiekosten. Indien de werkplek te klein wordt of de productiehoeveelheid toeneemt, is het aanbevolen om de chipset te integreren in het bestaande elektronische circuit. De initiële kosten zijn enkel een kleine beetje hoger in vergelijking met BIM.
Implementatieaspecten voor KNX PL Busdeelnemers
Gestandaardiseerde BCUs en modules (PIM) zijn ook beschikbaar voor KNX PL (110), vergelijkbaar met Twisted Pair.
BCU „Bus coupling units“
Dit zijn systeemapparaten met een KNX coupling circuit, een microprocessor en ze worden geleverd bij het huis. De ontwikkelaar moet enkel een application module, de hardware en de software ontwikkelen.
PIM „Powerline Interface Modules“
Deze bestaan feitelijk uit de laagspanningsonderdelen van de BCU. PIMs zijn modules die in het circuitbord gesoldeerd worden, tezamen met onderdelen van andere netwerkkoppelaars.
ACIS with Communication Stack
Een ASIC voor PL110 is verantwoordelijk voor het verzenden en ontvangen van bits. Om een KNX busdeelnemer te ontwikkelen op basis van ASIC is een KNX Stack voor Powerline (communicatiesoftware) noodzakelijk. Een communication stack bevat de interfaces voor het programmeren van de toepassing.
Wat is de beste oplossing?
BCU is de beste keuze bij een klein productievolume van een busdeelnemer, vanwege een hogere kostenefficiëntie. Bij een medium productievolume worden PIMs aanbevolen. De ontwikkeling van PL-busdeelnemers met Asic met Communication Stack vragen grotere investeringen, in vergelijking met BCUs en PIMs, en zijn eerder geschikt voor hoge productievolumes.
Implementatieaspecten voor KNX RF Busdeelnemers
De ontwikkeling van KNX RF busdeelnemers vergt geen speciale KNX componenten. Om echter de ontwikkelingstijd en –kosten te beperken, kan het zinvol zijn om gebruik te maken van ready-made RF modules – zeker bij lage productievolumes. Een KNX RF busdeelnemer bestaat in hoofdzaak uit volgende elementen :
Transceiver Chip
Voor KNX RF is geen specifiek chip noodzakelijk
Tegenwoordig zijn er een aantal chips op de markt die kunnen gebruikt worden om een KNX RF knooppunt te installeren. Voor unidirectionele apparaten bestaan er goedkope chips die enkel uitzende.
RF circuit
De transceiver vormt samen met een aantal passieve componenten het RF circuit. Gebaseerd op het referentiedesign van de chipproducent, kan een circuit ontworpen en geoptimaliseerd worden naar de KNX RF vereisten.
Microcontroller
De kern van elk KNX busdeelnemer is een microcontroller die zowel de communicatie als de eigenlijk taak van het busdeelnemer op zich neemt. Een van de belangrijkste vereisten voor RF is een laag energieverbruik. In de meeste van de hedendaagse controllers zou een interfacelogica moeten zitten om verbinding te maken met transceiver.
Communication stack
De KNX standaard bepaalt een complex protocol, wat leidt tot een complexe implementatie en certificatie. De communication stack is de systeemsoftware van een KNX RF busdeelnemer. Het beheert de transceiver en zorgt volledig voor de communicatie, inclusief de configuratieprocedure. De communication stack zorgt voor een interface (API) voor de ontwikkeling van toepassingen.
Implementatieaspecten bij KNX IP
De overdracht van KNX telegrammen via Ethernet is als KNXnet/IP vastgelegd en maakt deel uit van de KNX Standaard. Tot nu toe bevatten de specificaties het gebruik van dit medium voor PC interfaces en routers. IP routers gedragen zich net zoals lijnkoppelaars, alleen dat ze Ethernet voor de hoofdlijn gebruiken. Daarenboven is het tegenwoordig ook mogelijk om gewone KNX busdeelnemers rechtstreeks via IP met een KNX netwerk te verbinden. Dit verklaart waarom Ethernet resp. IP (Internet Protocol) een volwaardig KNX medium is. De ontwikkeling van KNX IP busdeelnemers vereist geen specifieke KNX componenten. Een KNX IP busdeelnemer bestaat in hoofdzaak uit de volgende elementen .
Ethernet controller
Ethernet controllers worden door verschillende halfgeleiderfabrikanten aangeboden. Ethernet controllers zijn over het algemeen KNX IP conform. Controllers met een 10 MBits bitrate zijn over het algemeen voldoende krachtig.
Microcontroller
De keuze voor een microcontroller hangt hoofdzakelijk af van de vereiste rekencapaciteit. KNXnet/IP kan in princiep op basis van een 8-bit controller geïmplementeerd worden. Afhankelijk van de toepassing kunnen ook krachtigere controllers vereist zijn. Veel controllers hebben standaard een ingebouwde interface voor Ethernet, zodanig dat u enkel nog de physical layer moet voorzien.
Communicatie stack
De systeemsoftware van een KNX IP busdeelnemer bestaat uit twee protocol-stacks. Communicatie via Ethernet vergt een op UDP (User Datagram Protocol) gebaseerde stack omdat KNXnet/IP op verbindingsloze communicatie gebaseerd is. Unicast en multicast telegrammen worden beide via UDP overdragen. De KNX Stack is bovenop de IP/UDP Stack geplaatst. Dit is de algemene KNX Kernel, die voor elk busdeelnemertype moet geïmplementeerd worden. De KNX Stack maakt gebruik van de IP/UDP stack als interface voor het systeem. De vertaling van de KNX telegrammen naar UDP telegrammen gebeurd via KNXnet/IP. De KNX applicatie maakt gebruik van de KNX stack API (Application Programming Interface) , om in communicatie de treden met het ganse systeem.
Wat is de beste oplossing?
De keuze voor de geschikte hardware hangt vooral af van het type van de toepassing. Hardware specifiek voor KNX IP busdeelnemers is al op de markt beschikbaar. Stacks op zich worden ook aangeboden. Hoewel, voor complexe busdeelnemers kan het beter zijn om krachtigere besturingssystemen zoals Linux te gebruiken omdat deze reeds voorzien zijn van een IP Stack met UDP. In zulke gevallen moet enkel nog de KNX stack samen met het overeenstemmende toepassingsprogramma voorzien worden.


