View/Open

Transcription

View/Open

Masterproef:
KNX validatie systeem
Studiegebied
Industriële wetenschappen en technologie
Opleiding
Master in de industriële
wetenschappen: elektrotechniek
Afstudeerrichting
Automatisering
Academiejaar
2010-2011
Tim Gobert
Academische bachelor- en masteropleidingen, Graaf Karel de Goedelaan 5, 8500 Kortrijk
Voorwoord
In dit voorwoord zal ik van de gelegenheid gebruik maken om alle mensen te bedanken die geholpen hebben
met mijn masterproef alsook de mensen die ervoor gezorgd hebben dat ik mijn vierjarige opleiding tot Master
in de Industriële wetenschappen elektrotechniek, optie automatisering aan het PIH tot een goed einde heb
kunnen brengen.
Eerst en vooral wil ik mijn ouders bedanken die mij de keuze en de kans gegeven hebben om deze opleiding te
volgen. Zonder hun emotionele en financiële steun zou dit onmogelijk zijn geweest. Ook wil ik mijn vriendin
bedanken voor de steun en aanmoedigingen die zij door de jaren heen heeft uitgesproken.
Specifiek voor mijn masterproef zou ik alle medewerkers van ON Semiconductor willen bedanken en in het
bijzonder: Stef Servaes mijn externe promotor, Alex Savov en Michiel Verschueren. Bij hen kon ik ieder
moment uitleg vragen over zowel technische als theoretische aspecten van het project. Ook wil ik Heinz
Vervaeke mijn interne promotor bedanken voor de steun, tips en feedback over alle werken die ingediend zijn
met betrekking tot deze masterproef.
Verder zou ik alle docenten aan de Howest, afdeling industriële wetenschappen, willen bedanken voor de hoge
kwaliteit van de opleiding en het aanreiken van inzichten in zoveel mogelijk aspecten van de industriële
wetenschappen. Dit heeft zowel mijn gezichtsveld als dat van mijn medestudenten verbreed wat ervoor zorgt
dat we betere industriële ingenieurs zijn geworden.
Ten laatste volgt waarschijnlijk de belangrijkste groep mensen die ik wil bedanken en dat zijn mijn
medestudenten. Zonder hen zouden de voorbije vier jaar waarschijnlijk niet zo vlug en vlot verlopen zijn. Het
kameraadschap tussen ons zorgde ervoor dat we elkaar op ieder moment en over ieder onderwerp wilden
helpen. Van alle mensen zijn zij het die me het meeste nieuwe inzichten in de materie hebben aangereikt en er
zo voor gezorgd hebben dat ik vrijwel alles kon begrijpen. Daarom nogmaals mijn grootste dank aan mijn
medestudenten en dan specifiek diegene uit de afstudeerrichting automatisering.
II
Inhoudsopgave
1
AFKORTINGEN ............................................................................................................................ 1
2
KNX VALIDATIE SYSTEEM ...................................................................................................... 2
2.1. Inleiding .................................................................................................................................................... 2
2.2. Voorstelling bedrijf .................................................................................................................................... 3
2.3. Doelstellingen ........................................................................................................................................... 5
2.4. KNX Protocol studie ................................................................................................................................... 6
2.4.1. Inleiding ..................................................................................................................................................... 6
2.4.2. OSI Model .................................................................................................................................................. 6
2.4.3. Opstelling .................................................................................................................................................. 8
2.4.4. Fysische laag .............................................................................................................................................. 9
2.4.5. Datalink laag ............................................................................................................................................ 12
2.5. KNXA testspecificaties ............................................................................................................................. 18
2.5.1. Inleiding ................................................................................................................................................... 18
2.5.2. Testspecificaties ...................................................................................................................................... 18
2.6. TTCN-3 ..................................................................................................................................................... 19
2.6.1. Waarom TTCN-3? .................................................................................................................................... 19
2.6.2. An Introduction to TTCN-3 ...................................................................................................................... 20
2.7. TTCN-3 compiler ...................................................................................................................................... 28
2.7.1. OPEN TTCN .............................................................................................................................................. 28
2.7.2. TTCN-3 voor chip testen .......................................................................................................................... 30
2.8. Test Opstelling......................................................................................................................................... 31
2.8.1. KNXA chip ................................................................................................................................................ 32
2.8.2. Host Controller ........................................................................................................................................ 34
2.8.3. Testen ...................................................................................................................................................... 40
2.9. Resultaten ............................................................................................................................................... 46
2.9.1. TTCN-3 software...................................................................................................................................... 46
2.9.2. Test scripts .............................................................................................................................................. 46
2.9.3. Verdere ontwikkelingen in de toekomst ................................................................................................. 48
3
ALGEMEEN BESLUIT .............................................................................................................. 50
4
REFERENTIES ........................................................................................................................... 51
III
Abstract
KNX Validation System
In this document a short description of my thesis will be formulated. The company where this Master thesis
took place will be briefly presented, as well as the framework this assignment started in. Next there will be a
short formulation of the goals that were set and which results were achieved. To finish a conclusion will be
formulated that summarizes the benefits for the company.
The company where this Master thesis took place is ON Semiconductor Belgium; it produces silicon chips that
improve the energy efficiency of all sorts of applications. They are proud of their green character and work
hard to reduce the impact of the energy problems. This seamlessly leads us to the framework where this
Master thesis is set in. Throughout the years different media and the government have made the people
susceptible to use energy more efficiently because it is scarce and we shouldn’t waste it like we do now. KNX,
which is a buildings automation system, helps us to use our energy more efficiently. This leads to significant
energy savings by means of e.g. automatically turning lights of when there is nobody in the room. Research has
proven that KNX is capable of generating a great deal of energy savings, up to fifty percent in some applications
and it is predicted to become the largest building automation system in Europe. With these two things in mind
ON Semiconductor started the development of the KNXA chip that implements the KNX protocol.
The goal of this Master thesis is to test if this KNXA chip works correctly and this by using the testing
technology TTCN-3. TTCN-3 stands for “Testing and Test Control Notation version 3” and is specifically designed
for testing telecommunication systems. The main advantage of this technology is the time profit that it
produces due to the fact that the system is scalable and modular.
I started tackling these goals by first getting comfortable with all the theory behind it like, the KNX protocol, the
KNXA chip and the TTCN-3 technology. Once I had enough knowledge about these things the TTCN-3
technology had to be implemented correctly on chip testing, TTCN-3 is not designed for this kind of testing
which made this task more challenging. After the implementation of the TTCN-3 technology the real
implementation of the test scripts that would eventually test the KNXA chip could start. Twenty-six test cases
where produced that step by step controlled every testable feature of the link layer of the KNX protocol. The
result of these test cases is that there four errors have been discovered in the KNXA chip, these errors where
passed on to engineers in ON Semiconductor who will correct this in their KNXA chip.
We conclude that the TTCN-3 technology can be used for silicon testing and that this will help ON
Semiconductor to make the test phase in the development of a product more reliable and shorter. These are
two advantages that will lead to financial profit in the future and that will make ON Semiconductor more
competitive in their market segment.
IV
Lijst van figuren
Figuur 2-1: Bedrijfslogo ON Semiconductor ............................................................................................................ 2
Figuur 2-2: Doelmarkten ON Semiconductor .......................................................................................................... 3
Figuur 2-3: Belangrijkste waarden .......................................................................................................................... 3
Figuur 2-4: Vestiging Oudenaarde .......................................................................................................................... 4
Figuur 2-5: Het KNX logo ......................................................................................................................................... 6
Figuur 2-6: OSI Model.............................................................................................................................................. 7
Figuur 2-7: Twisted Pair .......................................................................................................................................... 7
Figuur 2-8: opstelling KNX netwerk ......................................................................................................................... 8
Figuur 2-9: KNX voeding .......................................................................................................................................... 8
Figuur 2-10: Schema fysische laag .......................................................................................................................... 9
Figuur 2-11: KNX bustopologie ................................................................................................................................ 9
Figuur 2-12: modulatie van een logische “1” [3] ................................................................................................... 10
Figuur 2-13: modulatie van een logische “0” [3] ................................................................................................... 11
Figuur 2-14: omzetting naar seriële bitstroom [3] ................................................................................................ 11
Figuur 2-15: CSMA principe bij KNX protocol [3] ................................................................................................... 12
Figuur 2-16: Serieel karakter vs. Octet [3] ............................................................................................................. 13
Figuur 2-17: Control Field [3] ................................................................................................................................ 13
Figuur 2-18: L_Data_Standard frametype [3] ....................................................................................................... 14
Figuur 2-19: L_Data_Standard frametype(detail) [3] ........................................................................................... 14
Figuur 2-20: Individueel adres [3] .......................................................................................................................... 14
Figuur 2-21: checksum [3] ..................................................................................................................................... 15
Figuur 2-22: L_Data_Extended frametype [3] ....................................................................................................... 15
Figuur 2-23: L_Data_Extended framtype (detail) [3] ............................................................................................ 15
Figuur 2-24: Extended Control Field [3] ................................................................................................................. 16
Figuur 2-25: L_Poll_Data request frame [3] .......................................................................................................... 16
Figuur 2-26: L_Poll_Data response frame [3] ........................................................................................................ 17
Figuur 2-27: Acknowledgement frame [3] ............................................................................................................ 17
Figuur 2-28: logo TTCN-3 ...................................................................................................................................... 19
Figuur 2-29: Logo ETSI ........................................................................................................................................... 19
Figuur 2-30: Boek "An Introduction to TTCN-3” [3] ............................................................................................... 20
Figuur 2-31: Alternative Statement ....................................................................................................................... 20
Figuur 2-32: Conceptueel model van een TTCN-3 test systeem ............................................................................ 21
Figuur 2-33: Voorbeeld KNX testcase .................................................................................................................... 22
Figuur 2-34: Interactie tussen de test systeem entiteiten ..................................................................................... 23
Figuur 2-35: Type definities ................................................................................................................................... 24
Figuur 2-36: Template definities ........................................................................................................................... 24
Figuur 2-37: Test Case ........................................................................................................................................... 25
Figuur 2-38: Control definities ............................................................................................................................... 25
Figuur 2-39: schema testopstelling ....................................................................................................................... 26
Figuur 2-40: Opbouw parallelle testomgeving ...................................................................................................... 26
Figuur 2-41: Softwarematige opbouw parallelle testomgeving ............................................................................ 27
Figuur 2-42: Logo OpenTTCN ................................................................................................................................ 28
Figuur 2-43: Lay-out OpenTTCN ............................................................................................................................ 29
Figuur 2-44: fysische testopstelling ....................................................................................................................... 31
Figuur 2-45: Diagram van het KNXA silicium ........................................................................................................ 32
V
Figuur 2-46: Implementatie KNX protocol ............................................................................................................. 33
Figuur 2-47: Architectuur KNXA silicium ............................................................................................................... 33
Figuur 2-48: Host controller bord .......................................................................................................................... 34
Figuur 2-49: Doel van het bericht .......................................................................................................................... 35
Figuur 2-50: overzicht berichten host controller ................................................................................................... 35
Figuur 2-51: U_Reset.req bericht .......................................................................................................................... 35
Figuur 2-52: U_State.req bericht ........................................................................................................................... 35
Figuur 2-53: U_Busmon.req commando ............................................................................................................... 36
Figuur 2-54: U_IntRegWr.req bericht .................................................................................................................... 36
Figuur 2-55: U_IntRegRd.req bericht..................................................................................................................... 36
Figuur 2-56: U_L_DataStart.req commando ......................................................................................................... 37
Figuur 2-57: U_PollingState.req commando ......................................................................................................... 38
Figuur 2-58: Doel van het bericht .......................................................................................................................... 38
Figuur 2-59: overzicht berichten KNXA .................................................................................................................. 38
Figuur 2-60: L_Data_Standard.ind service of L_Data_Extended.ind commando .................................................. 39
Figuur 2-61: Foute testopstelling .......................................................................................................................... 40
Figuur 2-62: Correcte testopstelling ...................................................................................................................... 41
Figuur 2-63: Modules ............................................................................................................................................ 41
Figuur 2-64: Test Cases ......................................................................................................................................... 42
Figuur 2-65: Test case KNXA_SendTelegram......................................................................................................... 42
Figuur 2-66: Aanmaken Test Case ......................................................................................................................... 42
Figuur 2-67: Initialiseren en afbreken communicatie ............................................................................................ 43
Figuur 2-68: Function f_phyIni .............................................................................................................................. 43
Figuur 2-69: template phyIni ................................................................................................................................. 43
Figuur 2-70: Ontvangen phyIni .............................................................................................................................. 44
Figuur 2-71: templates request en answer frame ................................................................................................. 44
Figuur 2-72: Frame versturen ................................................................................................................................ 45
Figuur 2-73: Afgewerkte testcases ........................................................................................................................ 46
Figuur 2-74: Testopstelling polling frame testen .................................................................................................. 48
VI
1
Afkortingen
CD
CH
CSMA/CA
CTRL
DA
DNS
DUT
ETSI
KNXA
KNX
MAC
MAU
MTC
OSI
PA
PHY
PTC
SA
SA
SUT
tBit
TCI
TE
TM
TMC
TP
TSI
TSU
TTCN-3
TTCN-3 ATS
TRI
UART
: Coding and Decoding
: Component Handling
: Carrier Sense Multiple Access with Collision Avoidance
: Control karakterframe
: Destination Address
: Domain Name System
: Device Under Test
: Europees Telecommunicatie Standaardisatie Instituut
: De silicium chip ontwikkeld door ON Semiconductor die het KNX protocol implementeert
: Standaard protocol voor gebouwenautomatisering
: Medium Access Control
: Medium Attachment Unit
: Main Test Component
: Staat voor Open Systems Interconnection en beschrijft de verdeling van netwerkfuncties in
zeven lagen. Opgesteld door het ISO.
: Platform Adapter
: Physical layer
: Parallel Test Component
: Source Address
: SUT Adapter
: System Under Test
: De lengte in tijd van één bit, bij KNX is dit 104μs.
: TTCN-3 Control Interface
: TTCN-3 Executable
: Test Management
: Test Management & Control
: Twisted Pair, twee getorste koperdraden die als medium gebruikt kunnen worden
: Test System Interface
: Test System User
: Testing and Test Control Notation 3
: TTCN-3 Abstract Test Suite
: TTCN-3 Runtime Interface
: Universal Asynchronous Receiver and Transmitter
1
2
KNX Validatie Systeem
2.1. Inleiding
Vandaag de dag beïnvloedt het topic energie efficiëntie en het zuinig omspringen met elke energievorm, het
dagelijkse leven. Allerhande media berichten er over, de overheid sensibiliseert de bevolking en bedrijven
nemen maatregelen zodat de stijging van de energieprijzen minder impact heeft op de jaarresultaten. Er kan
dus gesproken worden over een algemene bewustwording van de energieproblematiek.
In deze masterproef zal er getracht worden om een KNX validatie systeem te ontwikkelen. KNX is een
bussysteem voor de gebouwenautomatisering dat als hoofddoel het efficiënter gebruiken van de toegeleverde
energie in gebouwen heeft. Uit onderzoek blijkt dat het toepassen van KNX als controle systeem bij
verlichtingsystemen en verwarmingstoepassingen een significante energiebesparing kan opleveren. Namelijk,
door het detecteren van menselijke aanwezigheid in een lokaal kan er via het KNX netwerk gecommuniceerd
worden om eventuele verlichting of conditioneringsystemen te activeren.
Concreet onderzoek van de hogeschool van Bremen geeft aan dat er tot vijftig procent energiewinst gemaakt
kan worden in vergelijking met conventionele verwarmingstoepassingen. Ook wordt KNX toegepast in de
nieuwe terminal five van Heathrow wat voor zevenduizend ton CO2 per jaar minder uitstoot zorgt. Deze cijfers
geven aan dat KNX potentieel heeft op het gebied van energie efficiëntie. Verder wordt voorspeld dat het KNX
protocol de grootste speler op de domotica markt zal worden. ON Semiconductor (Figuur 2-1), het bedrijf dat
deze masterproef uitschreef, wilde vertrekkend vanuit hun bedrijfsfilosofie deze boot niet missen en begon aan
de ontwikkeling van de KNXA chip. Deze chip implementeert de KNX protocol eigenschappen en zal in iedere
controller, sensor of actor van een KNX netwerk moeten zitten. Dit eindwerk bestaat er in om de KNXA chip te
testen op de juiste werking conform het gestandaardiseerd KNX protocol en dit aan de hand van de codetaal
TTCN-3.
Deze masterproef heeft veel inwerkingtijd en literatuurstudie gevergd. De hoeveelheid standaarden en andere
documenten die doorworsteld moesten worden waren groot, doch mocht het overzicht op het uiteindelijke
doel niet verloren gaan. Daarom moest er behoorlijk wat gefilterd worden in het grote aantal documenten om
uiteindelijk die documenten over te houden die betrekking hadden tot de doelstellingen van deze thesis.
Figuur 2-1: Bedrijfslogo ON Semiconductor
2
2.2. Voorstelling bedrijf
ON Semiconductor (Figuur 2-1) is zoals het zelf zegt: “a premier supplier of high performance silicon solutions
for energy efficient electronics” [1]. Het is dus een chip fabrikant die zich vooral toespitst op het ontwikkelen
van silicium chips die applicaties in al hun doelmarkten (Figuur 2-2) energie efficiënter moeten maken. Zowel in
haar producten als beleid leeft de groene gedachte, om dit nog wat extra kracht bij te zetten stelt ON
Semiconductor zichzelf het doel om ieder jaar 5% minder energie te verbruiken, 5% minder water te verbruiken
en om hun globale CO2 voetafdruk met 5% te verminderen. Alle werknemers van ON Semiconductor trachten
mee te werken aan deze bedrijfsfilosofie, steeds met de bedrijfswaarden in het achterhoofd. Deze zijn respect
hebben voor elkaar, te allen tijde de integriteit behouden en initiatief durven nemen. Figuur 2-3 geeft dit weer.
Figuur 2-2: Doelmarkten ON Semiconductor
Figuur 2-3: Belangrijkste waarden
ON Semiconductor heeft zijn hoofdzetel in Phoenix Arizona in de Verenigde Staten van Amerika en is over drie
continenten sterk verspreid, dit zijn Noord-Amerika, Europa en Azië. Het stelt ongeveer 21.000 mensen tewerk
en heeft een omzet van om en bij de 2 miljard dollar. In België zijn er twee vestigingen, in Oudenaarde (Figuur
2-4) en in Vilvoorde. Op beide sites worden silicium chips ontwikkeld en klantgerichte oplossingen gezocht.
Enkel Oudenaarde heeft ook een eigen productiesite, een Fab genaamd, waar zelf ontwikkelde silicium
geproduceerd wordt.
ON Semiconductor is een grote speler op de markt van halfgeleiders maar heeft niet zelf deze vestigingen in
België opgestart. De geschiedenis gaat terug naar het jaar 1983 met de oprichting van het bedrijf Mietec dat
silicium ontwikkelde en produceerde voor de telecommunicatie- en automobielsector. In 1990 werd Mietec
overgenomen door Alcatel dat op zijn beurt in 2002 overgenomen werd door AMI Semiconductor. In 2007 nam
ON Semiconductor AMI Semiconductor over zodat ook de vestigingen in België onder de naam van ON
Semiconductor zijn verdergegaan.
3
Figuur 2-4: Vestiging Oudenaarde
Door innovatie en continue onderzoeksprogramma’s slaagt ON Semiconductor er in om in iedere sector waar
ze aanwezig is (zie Figuur 2-2) een zo breed mogelijk gamma aan te bieden dat iedere klant individueel kan
helpen. Deze sectoren zijn de automobielsector, de medische wereld, consumentenproducten, de
computerwereld, de verlichtingssector, bedraad en draadloze communicatie en onderzoek naar smart grid
toepassingen. Het KNX project kan bij verschillende van deze sectoren ondergebracht worden zoals de
verlichtingssector of bij consumentenproducten.
Kortom ON Semiconductor is een sterk innoverend bedrijf dat continu op zoek is naar het energie efficiënter
maken van alle mogelijke producten met zijn silicium chips. Om zo slimmer om te springen met onze toch
schaarse en dure energievormen en dit zonder in te boeten op het comfort van de consumenten.
4
2.3. Doelstellingen
Het hoofddoel van deze masterproef is het ontwikkelen van een KNX validatie systeem gebruik makend van de
TTCN-3 technologie. Dit omvat de zoektocht naar, of het eigenhandig ontwikkelen van een geschikte test
omgeving. Alsook het softwarematig implementeren van de functionaliteit van het KNX validatie systeem wat
op zijn beurt het KNX protocol moet volgen.
Onlosmakelijk aan deze doelstellingen verbonden is het onder de knie krijgen van het KNX protocol om de
testspecificaties te begrijpen. Er zal vertrouwd geraakt moeten worden met het KNXA silicium van ON
Semiconductor om het hardwarematig deel van de masterproef aan te kaarten. Ook zal een grondige studie
van de TTCN-3 programmeertaal en technologie vereist zijn. Eens de geschikte test omgeving gevonden is kan
de functionele test software geschreven worden in de TTCN-3 programmeertaal.
5
2.4. KNX Protocol studie
2.4.1. Inleiding
KNX (Figuur 2-5) is een communicatieprotocol dat is opgebouwd volgens het OSI-model. Het protocol beschrijft
hoe de communicatie tussen sensoren, controllers en actuatoren in het netwerk verloopt. Het KNX Device
Network ontstond uit de samensmelting van drie toonaangevende systemen voor gebouwenautomatisering,
deze zijn EIB, EHS en BatiBus.
Figuur 2-5: Het KNX logo
KNX heeft als grote doel om de energie efficiëntie in gebouwen, van gewone huizen tot grote
kantoorgebouwen, sterk te verbeteren. Doordat iedere deelnemer van het netwerk apart kan worden
aangestuurd, zal vermeden worden dat ruimtes zonder onmiddellijke menselijke activiteit niet onnodig verlicht,
verwarmd, afgekoeld, … worden. Het KNX-systeem zorgt er dus voor dat er zuiniger met energie kan
omgesprongen worden zonder in te boeten op het gebied van comfort en gebruiksgemak.
De drie meest voorkomende media waarop het KNX-protocol wordt toegepast zijn Twisted Pair, Power Line en
Radio Frequency. Bij Power Line wordt de datastroom gesuperponeerd op de voedingsstroom en bij Radio
Frequency wordt de datastroom draadloos verspreid over het hele netwerk. In het kader van de deze
masterproef wordt alleen het medium Twisted Pair grondig bestudeerd.
2.4.2. OSI Model
OSI staat voor Open System Interconnection en is ontwikkeld door het ISO, de internationale organisatie voor
standaardisering. Het model beschrijft de communicatie tussen twee gebruikers op een netwerk en bevat
zeven lagen (Figuur 2-6). Hieronder wordt iedere laag kort toegelicht [2]. In verdere paragrafen worden de
fysische en datalink laag uitvoerig besproken omdat deze masterproef enkel betrekking heeft op deze twee
lagen.
6
Figuur 2-6: OSI Model
1.
De Fysische laag voorziet in de mechanische, elektrische of optische entiteiten die nodig zijn om de
fysische verbinding tot stand te brengen. In het van deze masterproef is deze fysische laag het twisted
pair (Figuur 2-7).
Figuur 2-7: Twisted Pair
2.
De Datalinklaag geeft aan hoe frames over het netwerk verstuurd moeten worden. Naast het
toegangsmechanisme voorziet de datalink laag ook foutdetectie- en correctiemechanismen om een
juiste afhandeling van transmissiefouten te hebben.
3.
In de Netwerklaag wordt het vinden van de route door het netwerk en het voorkomen van
opstoppingen geregeld.
4.
De Transportlaag zorgt voor een efficiënt gebruik van het netwerk. Door bijvoorbeeld grote
dataframes opgesplitst in verschillende pakketten te versturen.
5.
De Sessielaag voorziet in de controlestructuur van de sessie tussen twee deelnemers in het netwerk,
alsook het opzetten en verbreken van een sessie.
6.
De Presentatielaag bepaalt hoe data wordt weergegeven.
7.
De Applicatielaag levert diensten aan de toepassingen die draaien op de systemen van het netwerk.
7
2.4.3. Opstelling
Figuur 2-8 toont een standaard opstelling van KNX netwerk [4]. Voeding en data worden op het Twisted Pair
geplaatst. De stroom op het netwerk wordt geleverd door een voeding en een smoorspoel. Figuur 2-9 toont
een KNX voeding zoals die op de markt te verkrijgen is, de smoorspoel zit mee in de behuizing.
Figuur 2-8: opstelling KNX netwerk
Figuur 2-9: KNX voeding
Over de KNX bus is er seriële asynchrone transmissie en de communicatie is half duplex. Met seriële
asynchrone transmissie wordt bedoeld dat de bitsynchronisatie gebaseerd is op de inwendige klok van de
ontvangende deelnemer op het netwerk. Zowel zender als ontvanger heeft een inwendige klok. Half duplex
communicatie stelt dat de informatie in twee richtingen kan stromen. Beide deelnemers kunnen dus zenden en
ontvangen maar er mag slechts één deelnemer tegelijkertijd zenden. Heel wat protocollen gebruiken het
principe van half duplex waarbij ontvangen data bevestigd wordt naar de zender toe. Dit is ook het geval bij het
KNX protocol.
8
2.4.4. Fysische laag
De fysische laag [3] bestaat uit vier blokken die verduidelijkt worden in Figuur 2-10.
1.
2.
3.
4.
Het medium, hier Twisted Pair.
De connector die het toestel koppelt met het medium.
Het MAU (Medium Attachment Unit). Ze zet de analoge informatie verkregen van het medium om in
digitale informatie die verder verwerkt kan worden en omgekeerd zet ze de digitale informatie
verkregen van de hoger gelegen lagen om in analoge signalen die op het medium geplaatst kunnen
worden. Ook ontkoppelt de MAU de datastroom van voedingsstroom.
De Logical unit. Ze zet de seriële bits die het ontvangt van de MAU om in bytes en ook omgekeerd zet
ze bytes van hoger gelegen lagen om in een seriële bitsequentie.
Figuur 2-10: Schema fysische laag
De topologie van het netwerk kan een lijnstructuur, sterstructuur, boomstructuur of alles door elkaar zijn zoals
verduidelijkt in Figuur 2-11.
Figuur 2-11: KNX bustopologie
9
Verdere specificaties worden hieronder kort opgesomd.






Baud Rate = 9600 bits/s
PSU (Power Supply Unit) = 30V
Verbruik per netwerkdeelnemer = 3 tot 12 mA
Maximum aantal netwerkdeelnemers per segment = 256
Maximale kabellengte in één segment = 1000m
Maximale afstand tussen twee netwerkdeelnemers = 700m
2.4.4.1. Modulatie
Modulatie staat voor de manier waarop databits, logische enen en nullen, fysisch op het medium geplaatst
worden. Modulatie verpakt als het ware de data in een ander signaal. Er bestaan veel gestandaardiseerde
modulatietechnieken zoals non-return to zero of manchester code. Toch is de modulatie die wordt toegepast
bij KNX specifiek voor het KNX protocol.
Logische “1”:
Bij een logische 1 verkeert het netwerk in de “idle state”, er gebeurt dus niets. Figuur 2-12 verduidelijkt dit. Een
logische 1 is ondergeschikt aan een logische 0, dit betekent dat als er tegelijkertijd een logische 1 en een
logische 0 op het bussysteem geplaatst wordt, de logische 0 de bovenhand haalt. Uiteindelijk zal er dus een 0
verstuurd worden.
Figuur 2-12: modulatie van een logische “1” [3]
Logische “0”:
Bij een logische nul wordt de busspanning naar beneden getrokken voor 35μs. Daarna schiet de spanning terug
omhoog tot boven de gemiddelde busspanning om zo het te weinig aan vermogen die de deelnemers kregen
tijdens de spanningsdip te compenseren. Dit gedeelte duurt 69μs. Hieruit volgt ook dat de bittijd 104μs lang is
wat conform de baud rate van 9600bits/s is want
. Figuur 2-13 verduidelijkt dit principe. Zoals
hierboven vermeld is de logische 0 dominant t.o.v. een logische 1.
10
Figuur 2-13: modulatie van een logische “0” [3]
Op Figuur 2-14 wordt getoond hoe het analoge bussignaal omgezet wordt naar een seriële bitstroom.
Figuur 2-14: omzetting naar seriële bitstroom [3]
11
2.4.5. Datalink laag
De datalinklaag is de tweede laag van het OSI model, het is de laag tussen de fysische en de netwerklaag. Het
voorziet in de Medium Acces Control (MAC) en de opbouw van de dataframes.
2.4.5.1. MAC
Het KNX protocol werkt met het CSMA/CA (Carrier Sense Multiple Access/ Collision Avoidance) principe. Dit wil
zeggen dat iedere deelnemer in het netwerk het initiatief kan nemen om te zenden (Multiple Access) en dat de
deelnemer die wil zenden eerst het medium beluisterd alvorens een bericht op het bussysteem te plaatsen
(Carrier Sense).
Naargelang de prioriteit of het soort bericht, zie punt 2.4.5.2. , wordt in het KNX protocol het CSMA principe
anders ingevuld. Vooraleer een deelnemer mag zenden moet het medium minstens 50 bittijden (50 * 104μs =
5.2ms) beluisterd worden, als er na 50 bittijden geen enkel bericht op de lijn is gepasseerd mag er begonnen
worden met zenden. Figuur 2-15 verduidelijkt het CSMA principe voor de verschillende soorten berichten die
het KNX protocol rijk is.
Figuur 2-15: CSMA principe bij KNX protocol [3]
Het kan voorvallen dat twee of meer gebruikers tegelijkertijd beginnen te zenden na een wachttijd van 50
bittijden. Hier treedt dan het Collision Avoidance principe in werking.
Als een deelnemer een bericht op het bussysteem plaats wordt er tezelfdertijd ook geluisterd op het medium.
Door het feit dat een logische nul dominant is t.o.v. een logische 1, zal een deelnemer die een logische 1 op het
medium stuurt maar een logische 0 waarneemt, weten dat er een collision gebeurd is. Dit zal er toe leiden dat
de deelnemer onmiddellijk stopt met zenden en enkel nog het medium beluistert. De deelnemer die de
logische 0 op het medium stuurde gaat door met zenden omdat deze geen collision heeft gedetecteerd. Dit
principe zorgt ervoor dat er steeds één van de berichten zeker verzonden wordt wat voor een betere
benuttigingsgraad van het medium zorgt t.o.v. CSMA/CD principe waar CD voor collision detect staat. Bij het
CSMA/CD principe stoppen namelijk alle deelnemers met zenden als er een collision gedetecteerd wordt. Na
een veroveringsfase begint één van de deelnemers dan weer met zenden.
Als beide deelnemers nu een logische 0 op het medium plaatsen, dan gebeurt er niets. Dit gaat door tot één
van de deelnemers een logische 1 stuurt als de andere een logische 0 stuurt. Met andere woorden, de
deelnemer die het frame met de meeste leidende nullen verstuurd zal de hoogste prioriteit hebben.
Bijvoorbeeld: frame1 met octet 0000 0110 zal de prioriteit hebben op frame2 met octet 0000 1000.
12
2.4.5.2. Dataframes
Het KNX protocol over twisted pair omschrijft drie soorten dataframes:



L_Data frametype
L_Poll_Data frametype
Acknowledgement frametype
In de volgende onderdelen worden deze dataframes verder uitgelegd. De figuren van de dataframes zullen
afgebeeld zijn in octet structuur maar er moet rekening mee gehouden worden dat ieder karakterframe een
start, stop en pariteit bit heeft. Figuur 2-16 verduidelijkt dit.
Figuur 2-16: Serieel karakter vs. Octet [3]
Het eerste karakterframe van alle drie de dataframes is het Control field (CTRL). In dit karakterframe wordt
vastgelegd om welk dataframe het gaat, wat de prioriteit is en als het een dataframe is dat meermaals
herhaald moet worden. In Figuur 2-17 wordt dit voorgesteld.
Figuur 2-17: Control Field [3]
L_Data frametype
Zoals te zien is in Figuur 2-17 bestaan er twee soorten L_Data frametypes, het L_Data_Standard frametype en
het L_Data_Extended frametype.
13
L_Data_Standard frametype:
Zoals de naam al doet vermoeden is dit het standaard frame voor het verzenden van relatief korte berichten.
De lengte van het karakterframe ligt vast op maximaal 22 bytes of minder. Wil men een langer bericht
versturen dan moet er overgestapt worden op een L_Data_Extended frametype. Figuur 2-18 & Figuur 2-19
tonen respectievelijk de algemene vorm van een L_Data_Standard frametype en de gedetailleerde voorstelling.
Figuur 2-18: L_Data_Standard frametype [3]
Figuur 2-19: L_Data_Standard frametype(detail) [3]
Het CTRL karakterframe werd eerder al besproken. SA en DA staan voor Source Address en Destination Address
en geven dus respectievelijk aan wat het adres van de zender is en naar welk adres het bericht verzonden moet
worden. Beiden bestaan ze uit 16 bits maar ze zijn opgebouwd uit een 8 bit lang subnetwork address en een 8
bit lang device address. Figuur 2-20 verduidelijkt dit.
Figuur 2-20: Individueel adres [3]
In octet 5 wordt het adres type en de lengte meegegeven. Het adres type geeft weer of het destination address
een individueel of een groepsadres is. De lengte is een integer die het aantal karakters (0 t.e.m. 14) vanaf octet
7 voorstelt. Het laatste octet van het dataframe is dan de checksum. De checksum werkt met oneven pariteit.
Alle octetten worden als het ware op elkaar gestapeld om een tabel te bekomen met 8 kolommen en het
aantal rijen in overeenstemming met het aantal octetten, hier maximaal 22. Dan wordt per kolom gekeken wat
het aantal enen is. Is het aantal even, dan wordt in het checksum octet een 1 geplaatst op de overeenkomstige
plaats van de kolom om zo tot een oneven aantal enen te komen. Figuur 2-21 zal dit verduidelijken.
14
Figuur 2-21: checksum [3]
L_Data_Extended frametype:
Voor het versturen van berichten die de 15 octetten overschrijden of om uitgebreide
adresseringsmogelijkheden te hebben wordt er gebruik gemaakt van het L_Data_Extended frametype. Figuur
2-22 & Figuur 2-23 tonen respectievelijk de algemene vorm van een L_Data_ Extended frametype en de
gedetailleerde voorstelling.
Figuur 2-22: L_Data_Extended frametype [3]
Figuur 2-23: L_Data_Extended framtype (detail) [3]
Het grootste verschil met het vorige dataframe is de toevoeging van het CTRLE karakter. Wat staat voor
“extended control field”. Figuur 2-24 stelt het CTRLE karakter voor.
15
Figuur 2-24: Extended Control Field [3]
Het adrestype geeft ook hier aan of er met een individueel of een groepadres gewerkt wordt. De hop count is
een getal die weergeeft hoeveel keer een bericht op het netwerk geregenereerd mag worden door KNX
repeaters. Het extended frame format geeft weer of er speciale adres formaten of tabellen zullen gebruikt
worden.
De lengte van het L_Data_Extended frametype wordt meegegeven in het LG karakter. Waar de waarde van het
length karakter bij het L_Data_Standard frametype van 0 t.e.m. 14 liep, kan de waarde van 0 t.e.m. 254 lopen.
L_Poll_Data frametype
Figuur 2-25 is een L_Poll_Data request frame. Dit frame wordt verzonden door een Poll Data Master naar al zijn
Poll Data Slaves. Dit bericht wordt gebruikt om data op te vragen van alle deelnemers op het netwerk van
eenzelfde poll groep op een eenvoudige wijze. Iedere deelnemer antwoord met een L_Poll_Data Response
frame. Figuur 2-26 verduidelijkt hoe dit gebeurt.
Figuur 2-25: L_Poll_Data request frame [3]
16
Figuur 2-26: L_Poll_Data response frame [3]
Na het ontvangen van de laatste bit van het L_Poll_Data request frame wordt er 5 bittijden gewacht voor de
eerste poll slave begint te zenden. Iedere slave kent zijn poll groep en zijn plaats in de volgorde van
antwoorden. Een fill karakter wordt verstuurd door de poll master als dit nodig is. Een poll groep kan tot 15 poll
slaves bevatten, het aantal poll slaves zal overeen komen met het aantal verwachte poll data die in octet 5
staat weergegeven op Figuur 2-25.
Acknowledgement frametype
Figuur 2-27 toont de verschillende vormen waarin het acknowledgement frametype voorkomt. Het
acknowledgement frame wordt gestuurd als er een bericht dat op het netwerk werd geplaatst een bevestiging
nodig heeft. Als een acknowledgement frame verwacht wordt zal het netwerk 15 bittijden inactief zijn gevolgd
door het acknowledgement frame.
Figuur 2-27: Acknowledgement frame [3]
Een ACK geeft weer dat het bericht goed ontvangen is, een NACK dat het bericht niet goed ontvangen is en een
BUSY dat het netwerk bezet is en dat er gewacht moet worden.
17
2.5. KNXA testspecificaties
2.5.1. Inleiding
Vooraleer ON Semiconductor de KNXA chip op de markt mag brengen als erkend KNX product moet er eerst
aan een aantal vereisten voldaan worden. Deze vereisten zijn opgesteld door de KNX associatie die er op
toeziet dat alle producten die op de markt komen met het KNX label daadwerkelijk ook voldoen aan de door
hen gestelde eisen.
Er moet voldaan worden aan [5]:
1. Kwaliteitssysteem volgens ISO 9001.
2. Europese standaard EN 50090-2-2 (dergelijke aspecten behandelen zoals EMC, elektrische veiligheid,
milieuvoorwaarden, van busproducten) en een aangewezen productnorm. De naleving kan aan KNX
Association door de voorlegging van een CE- verklaring worden getoond.
3. Volume 3 en Volume 6 van de KNX specificaties, de eerste zijn de KNX protocoleigenschappen, de
laatstgenoemde zijn de toegestane profielen van KNX gebaseerd op toolbox zoals voordien vermeld.
4. KNX interactievereisten betreffende gestandaardiseerde gegevenstypes en (naar keuze) goedgekeurde
functionele blokken.
In het blikveld van deze masterproef wordt er enkel rekening gehouden met het eerste deel van punt drie.
Namelijk Volume 3 van de KNX specificaties die de KNX protocoleigenschappen afhandelen.
2.5.2. Testspecificaties
In bijlage 1 zit het bestand met de testspecificaties, dit bestand is opgebouwd door een medewerker bij ON
Semiconductor en is gebaseerd op het KNX protocol zoals het in paragraaf 2.4. voorgesteld.
Het bestand is opgedeeld in twee delen, enerzijds testspecificaties voor het fysisch deel van de link layer en
anderzijds voor het data gedeelde van de link layer. Concreet beschrijft het eerste deel dus testen die de
correctheid van: pariteitsbits, stopbits, frame prioriteiten en tijdsgerelateerde afspraken volgens Figuur 2-15
nagaan. In het tweede deel worden testen op: controle veld, source adres, destination adres, lengte, check
octet en confirmation veld besproken.
De opbouw en functionaliteit van de geschreven test scripts zal conform dit document moeten zijn.
18
2.6. TTCN-3
TTCN-3, Testing and Test Control Notation versie 3 (Figuur 2-28) is een door het ETSI gestandaardiseerde taal
voor het schrijven van testen in het wijde bereik van computer en telecommunicatie systemen. Het stelt de
gebruiker van de taal in staat om testgedrag van eender welke applicatie ondubbelzinnig voor te stellen en zo
op een correcte manier de applicatie te testen. Iedere nieuwe versie van de taal voegt extra functionaliteiten
toe en maakt de taal gebruiksvriendelijker. De taal heeft zijn oorsprong in telecommunicatiesector en werd
door werknemers van Nokia ontwikkeld. Door de grote tijdswinst die gemaakt werd in de testfase van het
productieproces werd deze taal ontwikkeld zodoende deze geschikt te maken voor allerhande testplatformen.
Figuur 2-28: logo TTCN-3
2.6.1. Waarom TTCN-3?
De keuze om TTCN-3 te gebruiken in deze masterproef is te staven door meerdere argumenten, hieronder
worden de belangrijkste opgesomd [6].

TTCN-3 is een taal die eenvoudig aan te leren is mits enige kennis van standaard programmeertalen
zoals: C, C++, C#, vb.net of Java.

TTCN-3 is specifiek ontworpen voor het testen wat veel voordelen met zich meebrengt.

Het is een door het ETSI (Figuur 2-29) internationaal gestandaardiseerde taal die onderhouden wordt
door experts uit de industrie en academici.
Figuur 2-29: Logo ETSI

Het is een uiterst flexibele test technologie omdat de taal zelf los staat van de
implementatietechnologie en het operating system van het systeem dat getest moet worden.

Het kan voor veel verschillende types van testen gebruikt worden. In deze masterproef staan protocol
testen centraal.

TTCN-3 gaat al een tijd mee. De taal bestaat al 10 jaar en is al die tijd al stabiel, veel functionaliteiten
werden overgeërfd van de TTCN-2 taal die ook al veelvuldig werd toegepast. Ook het feit dat TTCN-3
succesvol werd toegepast in de certificatie voor nieuwe technologieën zoals: IPv6, WiMax en 3GPP
bewijzen de sterkte van de taal.
19
2.6.2. An Introduction to TTCN-3
Voor het bestuderen van de codetaal TTCN-3 werd het boek “An Introduction to TTCN-3” [7] (Figuur 2-30)
aangekocht door ON Semiconductor. Het boek is geschreven door de grondleggers van de TTCN-3 taal en is
specifiek gericht op beginnende gebruikers. De auteurs leggen de TTCN-3 syntax en de structuur van een test
systeem uit aan de hand van het DNS protocol om de link met de realiteit te bewaren. Zo wordt het boek
verstaanbaar en kan er snel inzicht in de materie verworven worden.
Figuur 2-30: Boek "An Introduction to TTCN-3” [3]
2.6.2.1. Basisprincipe TTCN-3
Het basisprincipe van TTCN-3, of van eender welk ander testsysteem, is de mogelijkheid om wat je ontvangt
van de SUT (System Under Test) te vergelijken met wat je verwacht te ontvangen. Hiermee wordt er bedoeld
dat, wanneer er een bepaald commando gestuurd wordt naar de SUT, dan weet de gebruiker welk antwoord er
zou moeten teruggestuurd worden door de SUT. Door het teruggestuurd bericht van de SUT te vergelijken met
dat wat je verwacht kan er een conclusie gemaakt worden door het test systeem.
De manier waarop de TTCN-3 taal dit oplost is door het gebruik van het “Alternative Statement”, afgekort Alt
statement. Figuur 2-31 geeft weer hoe dit softwarematig opgebouwd is aan de hand van het zenden en
ontvangen van een KNX frame.
Figuur 2-31: Alternative Statement
20
Bij het zenden van een KNX_Question_Frame via een poort naar de SUT, wordt er verwacht dat het antwoord
van die SUT een KNX_Answer_Frame zal zijn. Is dit het geval dan krijgt de testcase Send_Receive_KNX_Frame
het verdict “pass”, wat betekend dat de test geslaagd is. Ontvangt het test systeem iets anders op die poort
dan het KNX_Answer_Frame dan zal de testcase het verdict “fail” meekrijgen.
Met deze syntax kan op een korte en duidelijke wijze een bepaalde functie van een systeem getest worden.
2.6.2.2. Opbouw van een test systeem
Eerst zal de opbouw van een volledig test systeem met daarin de codecs, adapters en TTCN-3 executable
uitvoerig besproken worden. Ten tweede wordt er dieper ingegaan op de opbouw van een TTCN-3 abstract test
suite (TTCN-3 ATS) zelf.
2.6.2.2.1. Test systeem
In de vorige paragraaf wordt de term “TTCN-3 Abstract Test Suite” voor het eerst aangehaald. De reden
waarom TTCN-3 test scripts abstract genoemd worden is omdat de coderegels in de scripts geen systeem
specifieke informatie bevatten. Er staat bijvoorbeeld niet in hoe de berichten gecodeerd moeten worden om
de communicatie met het te testen systeem (SUT, System Under Test) tot stand te brengen. In test scripts staat
er niets vermeld van hoe de bits en bytes tussen het test systeem en het SUT verlopen alsook het medium
waarop dit moet gebeuren. Deze abstractie van de taal is handig omdat er in eerste instantie een volledig
onafhankelijk programma geschreven kan worden los van alle systeemeigenschappen, hardware onafhankelijk
dus. Het concreet maken van deze TTCN-3 scripts gebeurt door de TTCN-3 taal uitvoerbaar te maken voor de
PC. Hiervoor moet de TTCN-3 taal geïnterpreteerd of vertaald worden naar een verstaanbare taal voor de PC,
voorbeelden hiervan zijn c, c++, c#, Java, ... .
Figuur 2-32 toont het conceptueel model van een TTCN-3 test systeem. In wat volgt zal iedere entiteit van het
model besproken worden.
Figuur 2-32: Conceptueel model van een TTCN-3 test systeem
21
Een TTCN-3 test systeem bestaat uit verschillende entiteiten die op elkaar inwerken tijdens de uitvoering van
een test suite. Figuur 2-32 geeft de architectuur van een test systeem weer, hierop zijn drie dominante lagen te
zien. Een centrale laag, de TTCN-3 executable (TE), staat in voor de uitvoering van de TTCN-3 scripts. Om te
kunnen werken doet de TE beroep op een aantal diensten van de andere twee dominante lagen. De Test
Management en Control (TMC) entiteit en de SUT en Platform Adapter. De TMC bestaat uit drie onderdelen die
instaan voor het decoderen en coderen van data, de interfacing met de test system user en aspecten die te
maken hebben met gedistribueerde uitvoeringen. Respectievelijk zijn dit: de External Codecs (CD), het Test
Mangement (TM) en de Component handling (CH). Deze entiteiten communiceren met de TE via de TTCN-3
Runtime Interface. Het TM en de CH zullen verder niet meer aan bod komen omdat zij meestal voorzien
worden door de ontwikkelaars van TTCN-3 tools en ze dus niet zelf geschreven moeten worden. De SUT en
Platform Adapter zorgen voor de interface met respectievelijk de SUT en het test system operating systeem. De
communicatie hier verloopt via de TTCN-3 Control Interface (TCI).
Nu zal aan de hand van een klein voorbeeld de communicatie tussen de verschillende entiteiten duidelijk
gemaakt worden om zo nog een beter inzicht in de communicatie van het test systeem te verwerven.
Figuur 2-33: Voorbeeld KNX testcase
Figuur 2-33 toont de code van een eenvoudig voorbeeld met dezelfde functionaliteit als het voorbeeld uit
Figuur 2-31, paragraaf 2.6.2.1. . Figuur 2-34 overloopt de communicatie over en weer tussen de verschillende
entiteiten van het test systeem. Iedere actie uit Figuur 2-34 wordt stap voor stap overlopen. Let vooral op als
de communicatie via TCI of TRI verloopt, de grijze doorzichtige blokken geven weer als een entiteit in actie is.
22
Figuur 2-34: Interactie tussen de test systeem entiteiten
Bij het initialiseren van het test systeem zet de TE de TRI acties Reset_SA en Reset_PA in gang. Eenmaal deze
succesvol bevestigd zijn zal de TE het control gedeelte van de test suite doorlopen, wat de uitvoering van de
testcase met zich meebrengt. Het eerste die gebeurt bij het uitvoeren van de testcase is het map commando
dat zorgt voor de communicatie interface met het System Under Test. De softwarematige poorten worden
hierbij aan fysische poorten gelinkt en de SA is vanaf dit punt actief tot het een unmap commando ontvangt.
Het eerstvolgende dat moet gebeuren is het zenden van een KNX_Question_Frame, vooraleer dit kan gebeuren
moet het KNX_Question_Frame dat een TTCN-3 waarde is gecodeerd worden naar een vorm die door de SUT
Adapter begrepen wordt. Dit gebeurt door het KNX_Question_Frame via de TCI naar de codec te sturen die op
zijn beurt antwoord met de gecodeerde versie van het bericht. Dit bericht wordt dan door de SUT Adapter naar
de SUT gestuurd. In afwachting van een antwoord van de SUT wordt een timer gestart. Timers worden geregeld
door de Platform Adapter dus wordt een commando vanuit de TE naar de PA gestuurd die een timer start en
een bevestiging terugstuurt naar de TE. Na verloop van tijd ontvangt de SA een antwoord van de SUT, dit
bericht wordt in een wachtrij gestopt om dan vervolgens via de TCI met de codec gedecodeerd te worden. Het
gedecodeerde antwoord van de codec kan nu in het Alt Statement vergeleken worden met het verwachte
antwoord om zo een verdict te stellen. De TE geeft het commando aan de PA om de timer te stoppen en de SA
krijgt het commando om de poorten te unmappen.
De rol van de timer t_replyTimer in dit voorbeeld is om de SA niet eeuwig te laten wachten op een antwoord
van de SUT. Als een bericht verstuurd wordt maar de SUT antwoordt om een of andere reden niet, dan zal bij
het aflopen van de timer aan een voorwaarde in het Alt statement voldaan zijn en zal het unmap commando
verstuurd worden.
23
2.6.2.2.2. TTCN-3 test scripts
De TTCN-3 taal neemt op het gebied van syntax dingen over van andere programmeertalen, een basiskennis
van de principes van het programmeren is dus gewenst. Zoals andere talen maakt TTCN-3 ook gebruik van
imports om definities en declaraties te importeren in andere stukken code of functions om frequent gebruikte
handelingen in onder te brengen.
De punten waarop de TTCN-3 taal verschilt van andere talen zijn de alt statements, type definities, template
definities, test cases en control definities.

Alt statements worden al besproken in paragraaf 2.6.2.1. en zullen hier dus niet herhaald worden.

Type definities
De type definities declareren de nodige structuurelementen van een test script. Zij worden doorheen
het programma gebruikt om het test script de nodige functionaliteiten te geven. Figuur 2-35 toont een
codevoorbeeld van hoe de type definities opgesteld worden.
Figuur 2-35: Type definities

Template definities
De template definities stellen de programmeur in staat om van alle mogelijke testscenario’s de te
versturen (input) en de te ontvangen berichten (output) eenduidig vast te leggen. Figuur 2-36 toont
twee template definities van KNX frames. In de TTCN-3 taal wordt een input, “Test Data Definition”
genoemd. Een output “Test Data Matching Rules”.
Figuur 2-36: Template definities
24

Test case
In een test case worden alle voorwaarden om te voldoen aan een bepaalde test opgesomd. Wordt aan
alle voorwaarden voldaan dan krijgt de test case een globale “pass”, is dit niet zo dan is het verdict
“fail”. Figuur 2-37 geeft een test case met voorwaarden weer.
Figuur 2-37: Test Case

Control definities
Hierin wordt het commando gegeven om de test cases die in de control definitie staan uit te voeren.
Figuur 2-38 geeft dit weer.
Figuur 2-38: Control definities
Een TTCN-3 test script is een verzameling van al deze elementen die tot een functioneel geheel leiden. Behalve
de control definitie, die altijd als laatste moet staan, heeft geen enkel element een vaste plaats in de code. Bij
ON Semiconductor is er wel een afgesproken volgorde in de elementen om de leesbaarheid van de TTCN-3
code naar medewerkers toe te verhogen. Deze afspraken zijn gebundeld in een document “ON Semiconductor
TTCN-3 Coding Conventions” en elke werknemer die projecten in TTCN-3 maakt moet zich hieraan houden.
25
2.6.2.3. Parallelle testen
Bij het testen van protocollen wordt vaak beroep gedaan op parallelle testen. Parallelle testen houden in dat er
een netwerk opgebouwd wordt met 2 of meerdere deelnemers. Door communicatie op te bouwen op dit
netwerk kunnen protocoleigenschappen getest worden. Figuur 2-39 toont het schema van de testopstelling die
in deze masterproef gebruikt wordt.
Figuur 2-39: schema testopstelling
Er is te zien dat er een KNX netwerk opgebouwd is uit twee KNXA chips en hun host controller. Door de
techniek van parallelle testen te gebruiken kan er met de PC een commando gegeven worden om berichten op
het netwerk te plaatsen. Ook wordt alle data die op de KNX bus passeert automatisch doorgestuurd naar de
PC. Het is niet de bedoeling om hier de testopstelling te bespreken, dit gebeurt in paragraaf 2.8. . De werking
van parallelle testen wordt voorgesteld in Figuur 2-40.
Figuur 2-40: Opbouw parallelle testomgeving
26
Op Figuur 2-40 zijn drie grote delen te onderscheiden: de Main Test Component (MTC), de Parallel Test
Components (PTC’s) en de Test System Interface (TSI). Deze drie delen dienen softwarematig aangemaakt te
worden in de TTCN-3 code en staan los van de werking van het TTCN-3 test systeem met zijn Codecs, SUT en
Platform Adapter, enz. . Dit parallel testmodel is een structuur voor het programma die het parallelle testen
toelaat.
De MTC dirigeert de werking van het test script. Het zendt de juiste commando’s naar de PTC’s, de
commando’s die de Device Under Test (DUT) PTC ontvangt zijn anders dan die van de Physical Layer PHY PTC,
via de poorten pt_DUT en pt_PHY. Het commando van de MTC wordt door de PTC op poort pt_control
ontvangen, naargelang het commando zal er via de poort pt_serial een bepaald KNX frame verstuurd of
ontvangen worden. De TSI ontvangt het KNX frame op de poorten pt_tsiDUT of pt_tsiPHY om ze dan door het
TTCN-3 test systeem te laten sturen naar de SUT via fysische poorten.
Al de poorten van zowel MTC, PTC of TSI moeten softwarematig aan elkaar gekoppeld worden. Figuur 2-41
toont het stuk code dat dit voor zijn rekening neemt. Poorten van twee test componenten, MTC en PTC,
worden aan elkaar gelinkt met het sleutelwoord “connect”. Dit stelt beide test componenten in staat om
berichten uit te wisselen met elkaar. Poorten van enerzijds een test component en anderzijds een test systeem
interface (TSI) worden verbonden met het sleutelwoord “map”. Dit sleutelwoord heeft als gevolg dat ieder
bericht dat van een test component komt meteen doorgezonden wordt naar de SUT Adapter via de TSI.
Omgekeerd wordt ieder bericht dat de SUT terugstuurt ook meteen doorgezonden naar het overeenkomstige
test component.
Het grote verschil tussen het “connect” en “map” sleutelwoord is dus het feit dat “connect” wordt gebruikt om
componenten aan elkaar te linken en “map” wordt gebruikt op componenten aan de TSI te linken.
Figuur 2-41: Softwarematige opbouw parallelle testomgeving
27
2.7. TTCN-3 compiler
Een TTCN-3 compiler is een programma, dat een structuur aanbiedt om een TTCN-3 test systeem in op te
bouwen en dat zelf al delen van het test systeem heeft geïmplementeerd. De delen die door de ontwikkelaar
van de compiler zijn voorzien zijn de user interface en syntaxcontrole van de TTCN-3 taal. Maar ook een
omgeving om codecs en adapters in te schrijven. Deze laatste twee zijn in programmeertalen zoals C#, C++,
XML, Java, … geschreven. Als alle onderdelen van het test systeem aanwezig zijn kan er gecompileerd worden
om zo de test scripts uit te voeren.
2.7.1. OPEN TTCN
De optie om een gratis TTCN-3 compiler van het internet aan te passen tot een werkend geheel is onderzocht,
met als conclusie dat de maturiteit van gratis TTCN-3 compilers nog te laag ligt. Hierdoor is het vrijwel
onmogelijk om deze tools verder te ontwikkelen omdat deze met zekerheid nooit tot een succesvol werkend
testsysteem zullen leiden. Dit alles leidde tot de aankoop van de TTCN-3 tool OpenTTCN (Figuur 2-42).
Figuur 2-42: Logo OpenTTCN
De redenen waarom er voor OpenTTCN gekozen is, is het feit dat OpenTTCN gebaseerd is op het Eclipse
platform, aangezien enkele medewerkers bij ON Semiconductor reeds vertrouwd zijn met dit platform was dit
een voordeel. De goede support door het bedrijf die OpenTTCN ontwikkeld is een pluspunt. De CEO van het
bedrijf is persoonlijk naar de vestiging van ON Semiconductor in Oudenaarde gekomen om training te geven.
Ook de snelle opvolging bij problemen, de prijs, het feit dat het op zowel Linux als Windows draait en de
invoeging van ideeën van de klant in het product zijn opmerkelijk.
Verder zijn er ook de voordelen die samenhangen met de voordelen van TTCN-3 op zich. Deze zijn: het
modulair kunnen opbouwen van projecten, de schaalbaarheid waarmee bedoeld wordt dat kleine projecten
snel en eenvoudig uitgebreid kunnen worden, het deterministisch karakter wat het opstellen van een tijdlijn
vergemakkelijkt en de geschiktheid van de software voor regressie- en stresstesten. Regressietesten zijn het
soort testen die onderzoeken of het aanpassen van stukken code of het toevoegen van nieuwe
functionaliteiten de oude functionaliteiten niet in de weg staan. Bij stresstesten wordt er gekeken naar wat een
bepaald product allemaal te verduren kan krijgen op het gebied van software, door het bijvoorbeeld enorme
hoeveelheden data te laten verwerken.
2.7.1.1. Lay-out
Figuur 2-43 toont de lay-out van het programma OpenTTCN. De mappenstructuur van de testscripts staat links
met daarnaast centraal de ruimte om TTCN-3 code te schrijven. In de grijze balk onderaan komen de resultaten
van de uitgevoerde testscripts. In dit opzicht lijkt programmeren in TTCN-3 zeer sterk op het programmeren in
andere programmeertalen. Zie Figuur 2-43: Lay-out
28
Figuur 2-43: Lay-out OpenTTCN
2.7.1.2. OpenTTCN bij ON Semiconductor
De rol van OpenTTCN en daarmee ook TTCN-3 bij ON Semiconductor is niet beperkt tot enkel het KNXA project.
Naast het gebruik van OpenTTCN in het KNXA project wordt het ook gebruikt in een ander project, PLCM
genaamd. Ook hier staat de sofware in voor protocol en andere testen van het product. Het belangrijkste in dit
verhaal is dat de ontwikkeling van het test systeem voor beide projecten niet onafhankelijk gebeurd is. Van in
het begin is er geprogrammeerd met de gedachte om zoveel mogelijk code te kunnen hergebruiken. Een
framework werd ontwikkeld waarop alle toekomstige projecten, die getest zullen worden met de TTCN-3 taal,
van start kunnen gaan. Zo wordt er veel tijd in de toekomst gespaard en zal het opstarten van nieuwe
testprojecten vlotter gaan.
Dit is toch wat anders in vergelijking met hoe het vroeger gebeurde. Een testingenieur schreef een
testprogramma in een programmeertaal naar eigen keuze en zonder vaste structuur. Hierdoor is het
controleren van het programma op de juiste werking ervan zeer tijdrovend en dit omdat, programmeertaal,
structuur, wederkerende elementen allemaal niet afgesproken zijn. In de toekomst zal dit dus niet meer het
geval zijn aangezien er getracht zal worden om zoveel mogelijk projecten te testen met de TTCN-3 technologie.
Dit zal ervoor zorgen dat testprogramma’s transparanter worden en dat fouten sneller en efficiënter opgelost
kunnen worden.
29
2.7.2. TTCN-3 voor chip testen
In de vorige paragrafen is alles betreffende de TTCN-3 taal en technologie uitvoerig besproken. Hoe deze
theorie in de praktijk wordt toegepast wordt in wat volgt kort besproken.
Na het opsommen van de voordelen van TTCN-3 in paragraaf 2.6.1. en het voorleggen van de technologie lijkt
het vanzelfsprekend om de TTCN-3 technologie te gebruiken voor de testen die bij ON Semiconductor
gebeuren. Echter, dit zijn testen op silicium chips en TTCN-3 is niet specifiek ontwikkeld voor dit soort testen.
Dit zorgt voor een grotere uitdaging betreffende het correct toepassen van de TTCN-3 technologie.
De codecs en adapters die alles geschikt maken voor het testen van silicium chips zijn aangemaakt door de
medewerkers bij ON Semiconductor. Het grote probleem bij deze ontwikkelingen was het feit dat, voor testen
waar reacties binnen een bepaalde tijd gecontroleerd moeten worden, de nauwkeurigheid van tijdsgebonden
testen bij OpenTTCN wat te wensen over laat.
In het geval van het KNX protocol moet een acknowledgement frame, 15 tBit (= 15 * 104μs = 1,56ms) ± 50μs na
een correct KNX frame verstuurt worden, Figuur 2-15 verduidelijkt dit. De marge van 50 microseconden is
zodanig klein dat de resolutie van de klok waarmee OpenTTCN werkt dit niet kan opmeten. Voor
tijdsgerelateerde testen geeft dit dus een duidelijk probleem. De oplossing hier ligt bij de aanpassing van de
testopstelling zelf die in paragraaf 2.8. besproken wordt. De aanpassing is dat de host controller, die de
communicatie tussen PC en KNXA verzorgt en die wel een snelle inwendige klok bezit, iedere byte die op de
KNX bus voorkomt van een timestamp voorziet. Deze timestamps kunnen wel eenvoudig geïnterpreteerd
worden door de TTCN-3 software waardoor alle tijdsgerelateerde testen correct uigevoerd kunnen worden.
Verder zijn er geen onoverkomelijke problemen gevonden, dit zorgt ervoor dat de TTCN-3 technologie perfect
toegepast kan worden voor het testen van silicium chips.
30
2.8. Test Opstelling
In wat volgt zal de testopstelling alsook de manier van testen uitgelegd worden. Het bouwt verder op wat reeds
kort wordt aangehaald in paragraaf 2.6.2.3. .
Waar Figuur 2-39 de schematische voorstelling van de testopstelling weergeeft, toont Figuur 2-44 de fysische
testopstelling waarop alle ontwikkelde test scripts uitgetest worden. OpenTTCN draait op de PC die op zijn
beurt via twee COM poorten verbonden is met de host controller van zowel de Device under Test (DUT) als de
PHY. Beide testborden zijn met elkaar verbonden met de KNX bus die gevoed wordt met 30V gelijkstroom.
Figuur 2-44: fysische testopstelling
Het verschil in benaming van de twee testborden, namelijk DUT en PHY heeft te maken met het verschil in
functie die de borden hebben. Eerst zal er in paragrafen 2.8.1. en 2.8.2. meer uitleg gegeven worden over
respectievelijk de KNXA chip en de Host Controller. In paragraaf 2.8.3. zal de uitleg van het eigenlijke testen
volgen.
31
2.8.1. KNXA chip
2.8.1.1. Inleiding
Het KNXA silicium is het product dat ON Semiconductor uiteindelijk zal aanbieden aan de fabrikanten van
actuatoren, sensoren en controllers die KNX producten op de markt willen brengen. In de volgende paragrafen
zal de opbouw van het KNXA silicium besproken worden zonder dieper in te gaan op de elektronica, daar dit
niet relevant is voor deze masterproef. Zoals Figuur 2-45 aantoont zou het volledig uitleggen van het KNXA
silicium te uitgebreid en te complex zijn.
VFILT
C2
from VDD1
C3
CEQ1
CEQ2
C4
VDDD
VFILT
VSSD
C9
VBUS1
Bus coupler
SCK
UART
Impedance
Control
KNX
DLL
SPI
Receiver
D2
Master / Slave
C1
CCP
KNX
bus
SDI / RXD
Interface
Controller
CAV
RX
from/to
host
controller
SDO / TXD
CSB
TREQ
MODE1
Tx / Rx
Buffer
R1
D1
TXO
Test
Ctrl
Mode
Ctrl
MODE2
Transmitter
TX
from VFILT
VBUS2
KNX
bus
VIN
VSW1
from VDD1
VDDA
L1
R2
VDD1
KNXA
DC/DC 1
VDD1M
C7
VDD1
C5
VSSA
VSS1
S1
WAKE
V20V
V20V
20 V
LDO
Wake
-up
Bandgap
POR
VSW2
L2
R3
VDD2
C6
VDD2MC
XTAL1
Q1
XTAL2
R4
OSC
OSC
TSD
DC/DC 2
UVD
C8
VDD2MV
VDD2
R5
XSEL
VSS2
XCLK
SAVEB
RESETB
TESTOUT
Figuur 2-45: Diagram van het KNXA silicium
2.8.1.2. Implementatie KNXA silicium
Zoals in de inleiding vermeldt, zal er niet veel uitgewijd worden in deze paragraaf. De implementatie van het
KNX protocol en de architectuur van het KNXA silicium zullen kort besproken worden.
2.8.1.2.1. Implementatie KNX protocol
Op Figuur 2-46 is weergegeven hoe het KNX protocol, dat opgebouwd is volgens het OSI zeven lagen model,
wordt vertaald naar het KNXA silicium. Enkel laag één en het grootste deel van laag twee worden
geïmplementeerd. Dit zijn dus de fysische laag en de datalink laag die in paragraaf 2.4. uitgewerkt zijn.
32
7
Application Layer
6
Presentation Layer
5
Session Layer
4
Transport Layer
3
Network Layer
Host
Controller
Logical Link Control
2
Data Link Layer
Media Access Control
1
KNXA
Physical Layer
Figuur 2-46: Implementatie KNX protocol
Figuur 2-46 geeft de taakverdeling tussen KNXA silicium en de host controller weer. Het KNXA silicium is
verantwoordelijk voor de checksum, de pariteit, de herhaling van een verloren bericht, de timing en de
toekenning. De host controller staat in voor de lengte van het bericht en de adressering. De functionaliteiten
van het KNXA silicium worden voorzien door de ontwikkelaars bij ON Semiconductor.
2.8.1.2.2. Architectuur KNXA silicium
4.7nF
100uF
VFILT
100nF
from VDD1
VDDD
CEQ2
KNX
1uF
CAV
Bus Coupler,
Impedance Control
VBUS1
VSSD
VFILT
RCOSC
XTALOSC
PORB
KNX
Data Link Layer
VFILT
SPI
Master / Slave
TX
Receiver
CCP
SCK
UART
RX
470nF
DIG
RXB
TXB
Interface controller
CEQ1
RX
SDI / RXD
SDO / TXD
CSB
TREQ
27R
TXO
KNX
bus
MODE1
Transmitter
OTP
controller
TX
RAM
Watch
Dog
Test
Ctrl
VDDD
Mode
Ctrl
MODE2
VDDD
BIST
VBUS2
WD
RCOSC
VFILT
ANA
VBUS1
Power switch control,
Over-current
VIN
DC1
from VFILT
VSW1
1R0
VDD1=3.3V
V20V
EN
VAUX
VREF
COMP
10uF
1uF
Flyback switch control
OTP cells
V20V
VSS1
VAUX
Over-voltage
VREF
VDD1M
COMP
WAKE
Wake-Up
Bandgap
Over-current
BIAS
Trimming
COMP
VDD1
VBG_OK
from VDD1
VDDA
VDDA
VSSA
RC
oscillator
100nF
POR
VDDD
XTAL
oscillator
XTAL2
RCOSC
Power switch control,
Over-current
DC2
RCOSC
VSW2
EN
EN
Temp
monitor
VFILT
VBUS1
V20V
WD
EN
Voltage
monitor
XTAL1
16 MHz
PORB
1R0
VDD2=3.3-20V
VREF
COMP
10uF
Flyback switch control
VSS2
EN
XTALOSC
TEMPB
Over-voltage
ANA signals
TESTIN
from
DIG
XSEL
VREF
VDD2MV
COMP
VDD2MC
Over-current
COMP
VDD2
XCLK
SAVEB
RESETB
TESTOUT
Figuur 2-47: Architectuur KNXA silicium
33
Zoals Figuur 2-47 duidelijk maakt bestaat het KNXA silicium uit vier grote delen. Het KNX deel zorgt voor de
zuivere implementatie van het KNX protocol. De digitaal en analoog blok zorgen respectievelijk dat er
communicatie kan gebeuren op digitaal en analoog vlak. Het analoge signaal dat van het bussysteem komt
wordt verwerkt en doorgegeven aan het digitale deel die dan de communicatie naar de hoger gelegen lagen
kan verzorgen. Omgekeerd zal een digitaal bericht komend van de hoger gelegen lagen doorgegeven worden
aan het analoge blok om het dan op de KNX bus te plaatsen. DC1 en DC2 zorgen voor de voeding van de
actuator, sensor of controller waarin de chip geïnstalleerd wordt.
2.8.2. Host Controller
De host controller (Figuur 2-48) is een bord met onder andere een microcontroller waarin een deel van de
datalink laag en alle hoger gelegen lagen tot en met laag zeven geïmplementeerd zijn. De Host Controller is
ontwikkeld door medewerkers van ON Semiconductor, specifiek om de KNXA chip te kunnen testen. Er zijn dus
voorzieningen getroffen om communicatie te hebben met een PC via USB of DB9 connector om zo de
communicatie op de KNX bus te kunnen volgen.
Figuur 2-48: Host controller bord
2.8.2.1. Communicatie tussen Host Controller en KNXA chip
In de volgende paragrafen wordt de communicatie tussen KNXA silicium en host controller weergegeven.
2.8.2.1.1. Diensten van de host controller
Uit het oogpunt van de berichtlengte bestaan er twee soorten berichten:

Een bericht van één byte waar de enige data die verzonden wordt de control byte is.

Een bericht met meerdere bytes.
Uit het oogpunt van het doel van het bericht zijn er ook twee soorten berichten:

Een intern bericht (tussen KNXA en host controller, zie Figuur 2-49) via SPI of UART dat geen
communicatie op het KNX bussysteem veroorzaakt.

Een KNX data bericht dat wel voor communicatie zorgt op het bussysteem.
34
Figuur 2-49: Doel van het bericht
Figuur 2-50 geeft een overzicht van de berichten die de host controller zendt naar het KNXA silicium.
Control field
Service name
7 6 5 4 3 2 1 0
Internal commands - device specific
0 0 0 0 0 0 0 1 U_Reset.req
0 0 0 0 0 0 1 0 U_State.req
0 0 0 0 0 1 0 1 U_Busmon.req
0 0 0 1 0 n b a U_Ackn.req
0 0 1 0 a a a a U_IntRegWr.req
0 0 1 1 a a a a U_IntRegRd.req
KNX transmit data commands
1 0 0 0 0 0 0 0 U_L_DataStart.req
1 0 i i i i i i
U_L_DataCont.req
0 1 l l l l l l
U_L_DataEnd.req
1 1 1 0 s s s s U_PollingState.req
Remark
Extra following data
Bytes
nba=Nack,Busy,Addressed
aaaa=address, 0..15
aaaa=address, 0..15
none
none
none
none
Value to be written into internal register
Value read from internal register
1
1
1
1
2
2
i=index, 1..62
l=last_index+1, 7..63
s=slot_number, 0..14
Control octet (CTRL)
Data octet (CTRLE, SA, DA, AT, NPCI, LG, TPDU)
Check octet (FCS)
PollAddrHigh + PollAddrLow + PollState
2
2
2
4
Figuur 2-50: overzicht berichten host controller
Alle interne commando’s zullen in wat volgt kort besproken worden.
U_Reset.req bericht
Type: Intern bericht van één byte.
Functie: Reset naar initiële status van het toestel (KNXA silicium). Het toestel keert terug naar zijn originele
status en maakt zich klaar voor het ontvangen van berichten komende van de KNX bus of host controller. De
KNXA antwoordt met een U_Reset.ind bericht. Figuur 2-51 stelt dit grafisch voor.
Reset
Host ctrl
KNXA
KNX bus
U_Reset.req
U_Reset.ind
Figuur 2-51: U_Reset.req bericht
U_State.req bericht
Functie: De host controller vraagt de inwendige communicatiestatus van het toestel af. De KNXA antwoordt
met een U_State.ind bericht. Figuur 2-52 stelt dit grafisch voor.
State
Host ctrl
KNXA
KNX bus
U_State.req
U_State.ind
Figuur 2-52: U_State.req bericht
35
U_Busmon.req bericht
Functie: Dit commando activeert de bus monitoring mode. Hierbij wordt alle data die ontvangen wordt op de
KNX bus zonder er iets mee te doen meteen doorgestuurd naar de host controller. Dit commando kan enkel
gestopt worden door een U_Reset.req te sturen. Figuur 2-53 stelt dit grafisch voor.
Bus monitor
Host ctrl
KNXA
KNX bus
U_Busmon.req
Any message
Any message
Any message
Any message
U_Reset.req
U_Reset.ind
Figuur 2-53: U_Busmon.req commando
U_Ackn.req bericht
Functie: Het is een indicatie dat het toestel geadresseerd is. Naargelang de status van het acknowledgement
frame (Figuur 2-27) zal het bericht een ACK, NACK of BUSY status hebben. Na het ontvangen van de data
verkregen van de KNX bus zal dit bericht op de KNX bus geplaatst worden. Dit wel conform met de timing
regels van het KNX protocol. Figuur 2-60 stelt dit grafisch voor.
U_IntRegWr.req bericht
Type: Intern bericht met meerdere bytes.
Functie: Aanvraag tot het schrijven van de daarop volgende data byte in een inwendig register van de KNXA.
Figuur 2-54 stelt dit grafisch voor.
Internal register write
Host ctrl
KNXA
KNX bus
U_IntRegWr.req
Data byte
Figuur 2-54: U_IntRegWr.req bericht
U_IntRegRd.req bericht
Type: Intern bericht met meerdere bytes.
Functie: Aanvraag tot het lezen van het inwendig register van de KNXA. De data byte moet meteen erna naar
de host controller verstuurd worden. Figuur 2-55 stelt dit grafisch voor.
Internal register read
Host ctrl
KNXA
KNX bus
U_IntRegRd.req
Data byte
Figuur 2-55: U_IntRegRd.req bericht
36
Het volgende wat besproken wordt zijn de commando’s die het verzenden van data als gevolg hebben.
U_L_DataStart.req bericht
Type: Twee byte groot commando voor het verzenden van een KNX bericht.
Functie: De tweede byte van dit bericht is de control byte van een nieuw KNX dataframe. Na het ontvangen van
dit bericht moet de KNXA zich voorbereiden op het ontvangen van nog meer data bytes van de host controller.
De KNXA wacht met het bericht te verzenden op de KNX bus tot alle data bytes ontvangen zijn. Figuur 2-56 stelt
dit grafisch voor.
U_L_DataCont.req bericht
Functie: Iedere tweede byte is nu een karakter in het KNX dataframe. Figuur 2-56 stelt dit grafisch voor.
U_L_DataEnd.req bericht
Functie: De tweede byte van dit bericht is de checksum van het te verzenden KNX dataframe. Als de ontvangen
checksum overeenkomt met de zelf berekende dan start het verzenden van het dafarame op de KNX bus. Klopt
de checksum niet dan krijgt de host controller een foutmelding van de KNXA. Figuur 2-56 stelt dit grafisch voor.
Send frame
Host ctrl
KNXA
KNX bus
U_L_DataStart.req
Data byte
U_L_DataCont.req
Data byte
U_L_DataCont.req
Data byte
.
.
U_L_DataEnd.req
Data byte
Control byte
L_Data.ind
Data byte
Data byte
Data byte
.
.
.
Data byte
.
.
.
Checksum
Checksum
Immediate acknowledge
L_Data.con
Figuur 2-56: U_L_DataStart.req commando
U_PollingState.req bericht
Type: Vier byte groot commando voor het verzenden van een KNX bericht.
Functie: De host controller zendt dit bericht na het ontvangen van een aanvraag van de KNXA die op zijn beurt
de aanvraag heeft opgestart na het ontvangen van een control byte van een polling frame (Figuur 2-25). Het
bericht bestaat uit vier bytes die nodig zijn om correct te kunnen antwoorden op het polling frame. Figuur 2-57
stelt dit grafisch voor.
37
Polling frame - slave
Host ctrl
KNXA
KNX bus
Control byte
L_Poll_Data.ind
Source address
U_PollingState.req
Source address
PollAddrHigh
Poll address
PollAddrLow
Poll address
PollState
Slot count
Checksum
Slot 0
Slot 1
Figuur 2-57: U_PollingState.req commando
2.8.2.1.2. Diensten naar de host controller
Iedere data byte die ontvangen wordt van de KNX bus wordt transparant doorgestuurd naar de host controller
(Figuur 2-58). Een uitzondering hierop is de aknowledgement byte, deze wordt enkel doorgestuurd naar de
host controller in bus monitoring mode. Andere nuttige informatie kan ook naar de host controller verstuurd
worden maar enkel op aanvraag door gebruik te maken van inwendige controle berichten.
Figuur 2-58: Doel van het bericht
Figuur 2-59 geeft een overzicht van de berichten die de host controller ontvangt van het KNXA silicium.
Control field
Service name
Remark
Extra following data
7 6 5 4 3 2 1 0
DLL (Layer 2) services - the device is transparent
1 0 r 1 p1 p0 0 0 L_Data_Standard.ind r=1 not repeated, 0 repeated L_Data frame
0 0 r 1 p1 p0 0 0 L_Data_Extended.ind p1,p0=priority
1 1 1 1 0 0 0 0 L_Poll_Data.ind
Acknowledge services - the device is transparent in bus monitor mode
x x 0 0 x x 0 0 L_Ackn.ind
Acknowledge frame
x 0 0 0 1 0 1 1 L_Data.con
x=1 positive, 0 negative confirmation
Control services - device specific
0 0 0 0 0 0 1 1 U_Reset.ind
sc re te pe tw 1 1 1 U_State.ind
sc=slave collision, re=receive error, te=transmit error, pe=protocol error, tw=temperature warning
Figuur 2-59: overzicht berichten KNXA
Ontvangen data van de KNX bus:
L_Data_Standard.ind service of L_Data_Extended.ind service
Type: Een byte groot bericht bij ontvangen van data op KNX bus.
38
Bytes
n
n
n
1
1
1
1
Functie: Bij het ontvangen van de control byte van een KNX karakterframe wordt de data transparant door
gestuurd naar de host controller. Het verwerken van de data is de taak van de host controller. Figuur 2-60 stelt
dit grafisch voor.
Receive frame
Host ctrl
KNXA
KNX bus
Control byte
L_Data.ind
Data byte
Data byte
Data byte
.
.
U_Ackn.req
Data byte
.
.
Checksum
Data byte
.
.
.
.
.
Checksum
Immediate acknowledge
Figuur 2-60: L_Data_Standard.ind service of L_Data_Extended.ind commando
Controle berichten:
U_Reset.ind bericht
Functie: Het antwoord op een U_Reset.req bericht van de host controller. Figuur 2-51 stelt dit grafisch voor.
U_State.ind bericht
Functie: Het antwoord op een U_Stata.req bericht van de host controller. Figuur 2-52 stelt dit grafisch voor.
39
2.8.3. Testen
De testopstelling bestaat uit een KNX netwerk bestaande uit twee deelnemers, de Device Under Test (DUT) en
de PHY. Het verschil in de naam van beide deelnemers ligt aan het feit dat de naam hun functie omschrijft in
het testnetwerk. De DUT is het bord waarop alle protocoleigenschappen getest moeten worden. De PHY staat
voor het feit dat dit bord ieder bericht van de PC afkomstig op de KNX bus zet en omgekeerd dat ieder bericht
op de KNX bus rechtstreeks naar de computer wordt doorgestuurd. De datalink laag van het PHY bord wordt als
het ware overbrugd. Dit is nodig om de protocollen van de datalink laag op een correcte manier te kunnen
testen. Als dit niet het geval zou zijn, en beide borden zijn DUT borden, dan zou een fout in de datalink laag niet
ontdekt worden. Aangezien beide DUT borden dezelfde implementatie zouden hebben van de datalink laag zal
de fout geneutraliseerd worden. De communicatie over de bus zal vlot en zonder fouten verlopen maar dit
betekend niet dat het KNX protocol correct is toegepast. Moest er getest worden op deze manier dan zou het
kunnen gebeuren dat de communicatie met een KNX chip van een andere fabrikant niet werkt door het niet
ontdekken van de foute implementatie van het protocol. Als heel het netwerk opgebouwd is met KNXA chips
van ON semiconductor zou de communicatie wel vlot verlopen, maar het is juist de bedoeling van een open
protocol zoals KNX dat alle KNX producten van verschillende producenten probleemloos met elkaar kunnen
communiceren.
Figuur 2-61 en Figuur 2-62 maken dit nog eens duidelijk met een vereenvoudigd voorbeeld. In Figuur 2-61 is te
zien dat van beide busdeelnemers zowel de datalink als de fysische laag geïmplementeerd is. Het getal 10
wordt verstuurd en doorloopt alle lagen van het KNX protocol volgens het OSI model. Stel nu dat de datalink
laag fout geïmplementeerd werd en dat het verstuurde getal verdubbeld wordt. Het bericht wordt verstuurd
op de bus en bereikt de datalink laag van de andere deelnemer. Aangezien deze op dezelfde wijze
geïmplementeerd is als de andere deelnemer zal dezelfde fout omgekeerd gemaakt worden. Dit wordt
voorgesteld door het halveren van het verstuurde getal. De fout wordt dus ongedaan gemaakt en kan niet
opgespoord worden door het testprogramma.
Figuur 2-61: Foute testopstelling
Figuur 2-62 toont dat, wanneer de datalink laag verwijdert wordt bij de ontvangende deelnemer, de fout aan
het licht gebracht wordt. Ook hier wordt het getal 10 verstuurd, dezelfde fout gebeurt opnieuw in de datalink
laag maar nu wordt deze niet meer ongedaan gemaakt door de ontvangende deelnemer. Het testprogramma
ontvangt het getal 20 terwijl het een bericht met het getal 10 verwacht. De fout wordt dus succesvol
opgespoord.
40
Figuur 2-62: Correcte testopstelling
Bij het eigenlijke testen krijgt de Host Controller een commando van de PC met eventueel bijgevoegde data,
naargelang het commando zal de eventuele data op de KNX bus gezet worden of zullen er instellingen wijzigen
van de Host Controller. Bijlage 2 toont een overzicht van deze commando’s, die zowel naar de Host Controller
van de DUT als PHY gestuurd worden, met hun bijhorende functie. Dit document is opgesteld door een
medewerker bij ON Semiconductor, daar zij ook de Host Controller ontwikkeld hebben.
2.8.3.1. Uitgewerkt voorbeeld
In deze paragraaf wordt een testcase volledig uitgewerkt, dit zou een totaalbeeld moeten geven van hoe de
TTCN-3 code, het test systeem, de parallelle testen en de implementatie van de protocoleigenschappen in
elkaar zitten.
Een testsuite is opgebouwd uit verschillende modules (Figuur 2-63) met elk hun specifieke functionaliteiten.
Aan de hand van deze functionaliteiten worden er test cases (Figuur 2-64) opgebouwd. De test case die hier
uitgelegd zal worden is: “KNXA_SendTelegram”.
Figuur 2-63: Modules
41
Figuur 2-64: Test Cases
Figuur 2-65 toont de code van de test case “KNXA_SendTelegram”, het doel van deze test is om de DUT te
stimuleren om een bericht op de KNX bus te plaatsen. De PHY moet dan controleren of er geen enkele
pariteitbit of stopbit fouten zijn opgetreden.
Figuur 2-65: Test case KNXA_SendTelegram
Iedere test case begint met het importeren van drie andere modules. De eerste twee namelijk: “KNXA_Synch”
en “KNXA_TSI” staan in voor de opbouw van de structuur die nodig is voor het parallelle testen, zie Figuur 2-40.
Zij maken alle componenten (MTC, PTC’s en TSI) aan met hun bijhorende poorten voor communicatie. De
module “KNXA_SendFunctions” bevat de functies die opgeroepen worden in de test case en die instaan voor
het verzenden van de correcte commando’s naar de PTC’s. Als de test case instaat voor het zenden van de
commando’s naar de PTC’s betekend dit dat de test case deel uitmaakt van de Main Test Component (MTC).
Figuur 2-66 verduidelijkt dit door de “runs on” clausule. Ook is er te zien dat er meegegeven wordt wat de Test
System Interface is, want meerde TSI’s zijn mogelijk.
Figuur 2-66: Aanmaken Test Case
42
In dit project bevat iedere test case de functies “fInitializeBoards” en “fTerminateBoards”. De code van
“fInitializeBoards” is te zien in Figuur 2-41 en staat in voor het initialiseren van de testborden. Hiermee wordt
bedoeld dat alle connecties tussen de componenten aangemaakt worden om zo de communicatie ertussen tot
stand te brengen. Bij “fTerminateBoards” worden deze verbindingen terug afgebroken.
Figuur 2-67: Initialiseren en afbreken communicatie
In de test case “KNXA_SendTelegram” zijn drie acties waar te nemen: “f_phyIni”, “f_sendKnxFrame” en
“f_receiveBaudat”. De taak van deze drie functies is respectievelijk: het initialiseren van de PHY, het zenden
van een correct KNX bericht met de DUT en controleren van de door de PHY ontvangen data. Alle drie deze
functies zenden een commando naar de PTC’s, bij ontvangst voert de corresponderende PTC de juiste opdracht
uit.
Hieronder zal stap voor stap uitgelegd worden wat er gebeurt bij het uitvoeren van “f_phyIni”. Alle stappen die
worden doorlopen zijn analoog voor iedere andere functie die opgeroepen wordt vanuit welke test case dan
ook.
Figuur 2-68 toont de functie f_phyIni, de taak van deze functie is het zenden van een “phyIni” bericht naar de
parallelle test component PHY. Ook is te zien dat de MTC een antwoord verwacht van de PTC. Gebeurt dit niet
dan wordt de test case automatisch afgesloten. Het bericht “phyIni” moet op zijn beurt ook aangemaakt
worden. Op Figuur 2-69 is te zien hoe het “phyIni” bericht gedefinieerd wordt.
Figuur 2-68: Function f_phyIni
Figuur 2-69: template phyIni
43
Eens het bericht verzonden is zit de taak van de MTC er op. Figuur 2-70 toont de code die in de PTC instaat voor
het ontvangen van het “phyIni” bericht en wat er moet gebeuren als het bericht ontvangen wordt. Bij
ontvangen van het bericht wordt meteen het OK commando naar de MTC gestuurd om te bevestigen dat het
bericht is aangekomen.
Figuur 2-70: Ontvangen phyIni
Ook wordt de functie “fExchangeFrame” uitgevoerd. Deze functie staat in voor het versturen van KNX frames
naar de Test System Interface (TSI) die ze op zijn beurt meteen doorstuurt naar het PHY bord. De functie is zo
opgebouwd dat zowel het te versturen bericht als het verwachte antwoord moet meegegeven worden. Figuur
2-71 toont het “phy_init_req” frame die het bericht is die verstuurd moet worden en het “phy_init_answer”
frame die het bericht is die ontvangen moet worden. Er is duidelijk te zien dat de frames opgebouwd zijn uit
een commando die door de host controller geïnterpreteerd wordt en eventueel data die op de KNX bus
verstuurd wordt, zoals in paragraaf 2.8.3. vermeld wordt.
Figuur 2-71: templates request en answer frame
Op Figuur 2-72 is de code van de functie “fExchangeFrame” te zien. De “runs on” clausule toont hier aan dat
deze functie daadwerkelijk op de PTC loopt en niet op de MTC. Het request frame wordt verstuurd naar de TSI
en met een alt statement wordt gekeken of het correcte antwoord ontvangen wordt. Is dit het geval dan wordt
het verdict op “pass” gezet en kan er met zekerheid gezegd worden dat het commando correct uitgevoerd is.
Aangezien het PHY bord met het juiste bericht heeft geantwoord. Als het correcte antwoord niet ontvangen
wordt of er wordt geen bericht ontvangen dan zal het verdict op “fail” gezet worden om aan te geven dat er
iets is fout gelopen.
44
Figuur 2-72: Frame versturen
De opeenvolging van de verstuurde berichten, van MTC naar PTC en van PTC naar TSI maken dat beide PTC’s
hun eigen commando’s kunnen verwerken op een correcte manier. Dit maakt alles ook overzichtelijk om te
volgen. Iedere testactie vertrekt vanuit de MTC die zo het hele testgebeuren beheert.
Het uiteindelijke verdict van de test case is het samengesteld resultaat van alle acties die uitgevoerd moeten
worden in die test case. Slechts als alle acties een “pass” opleveren dan kan de test case het verdict “pass”
krijgen. Zo is de test betrouwbaar en worden onvoorziene omstandigheden vermeden.
45
2.9. Resultaten
De aantoonbare resultaten van de masterproef zijn geboekt op twee vlakken. Ten eerste de zoektocht en de
poging om een gratis TTCN-3 tool aan te passen tot software die de TTCN-3 technologie correct toepast. Ten
tweede het produceren van werkende test scripts die de implementatie van het KNX protocol op het KNXA
silicium testen.
2.9.1. TTCN-3 software
Zoals in paragraaf 2.7.1. reeds vermeldt, leidde de initiële zoektocht naar, en aanpassing van een geschikte
gratis TTCN-3 tool, tot de conclusie dat deze gratis tools nog niet over voldoende maturiteit beschikken om
succesvol toegepast te kunnen worden voor de doelstellingen van deze Masterproef. Met dit gegeven zijn de
medewerkers bij ON Semiconductor gestart met de zoektocht naar een geschikte TTCN-3 tool op de software
markt. Hieruit volgde de succesvolle toepassing van de TTCN-3 technologie op het testen van chips. Het meer
praktische werk zoals het implementeren van de codecs en adapters is uitgevoerd door medewerkers van ON
Semiconductor. De reden hiervoor is de hoge complexiteit van het programmeren in C#. Dit past ook niet
volledig in de scope van deze masterproef. De succesvolle toepassing van de TTCN-3 technologie hangt echter
niet alleen af van het programmeren maar ook van het studiewerk die er in gestopt werd. Deze studie zorgt
voor extra “know how” wat de kans op slagen sterk verhoogt.
2.9.2. Test scripts
Het echte fysische resultaat dat bijdraagt tot het behalen van het hoofddoel, namelijk een KNX validatie
systeem, is het afronden een 26-tal testscripts. Deze testscripts implementeren één voor één de testen
conform het “System Verification document”, zie bijlage 1.
Figuur 2-73 toont de mappenstructuur met de afgewerkte testcases. Ze behandelen stuk voor stuk testen van
de link layer.
Figuur 2-73: Afgewerkte testcases
46
2.9.2.1. Conclusies uit de testscripts
Bij het uitvoeren van deze testscripts op het KNXA silicium produceert OpenTTCN een eindverdict “pass” of
“fail”. Deze testscripts gaan dus effectief na dat deze protocoleigenschappen correct geïmplementeerd zijn in
het KNXA silicium. Uit deze testen is gebleken dat er bij vier van de zesentwintig testen iets fout loopt. De fout
kan zich voordoen op twee verschillende vlakken. Ofwel zijn de protocoleigenschappen foutief
geïmplementeerd in het KNXA silicium ofwel is de test foutief beschreven in het “System Verification
document”.
De vier testen waar er iets fout loopt zijn: KNXA_Wait53tBit, KNXA_Wait50tBit, KNXA_Wait150tBit en
KNXA_IncorrectInfoLength. In wat volgt zal van iedere foutieve test kort besproken worden wat er getest
wordt, welke fout er gevonden is en waar de fout verbeterd moet worden.

KNXA_Wait53tBit
Hier moet er gecontroleerd worden dat een frame met lage prioriteit pas ten vroegste 53 tbit (=
53*104μs ≈ 5,5 ms) na het laatste frame verstuurd wordt. Het eerste onderdeel van Figuur 2-15 toont
dit. Deze test krijgt steeds een “fail” aangezien er slechts 50 tbit (= 50*104μs ≈ 5,2 ms) gewacht wordt
om een bericht te zenden. Uit deze test blijkt dus dat dit gedeelte van het KNX protocol fout
geïmplementeerd is in het KNXA silicium.

KNXA_Wait50tBit
Hier moet er gecontroleerd worden dat een frame met normale of hoge prioriteit pas ten vroegste 50
tbit (= 50*104μs ≈ 5,2 ms) na het laatste frame verstuurd wordt. Het tweede onderdeel van Figuur
2-15 toont dit. Deze test krijgt een “pass” maar bij het verder controleren van de timestamps van de
ontvangen bytes is te zien dat alle berichten hier minimum 53 tbit uit elkaar liggen. Er kan dus
geconcludeerd worden dat deze eigenschap van het protocol omgekeerd geïmplementeerd werd met
de vorige besproken eigenschap. Ook dit zal aangepast moeten worden in het KNXA silicium.

KNXA_Wait150tBit
Hier moet er gecontroleerd worden dat wanneer de DUT een frame zend naar de PHY en die
antwoord met een BUSY frame dat dan pas ten vroegste 150 tbit (= 150*104μs ≈ 15,6 ms) na het
ontvangen van die BUSY het frame herhaald mag worden. De fout hier ligt in het mis opstellen van
deze test in het “System Verification document”. In de beschrijving van deze test staat dat er een
gewoon niet herhaald frame verstuurd moet worden. Dit is foutief en moet aangepast worden. Er
moet namelijk een “repeated frame” verstuurd worden om deze test te laten slagen. Deze aanpassing
zal dan ook gemaakt worden.

KNXA_IncorrectInfoLength
Hier wordt gecontroleerd wat er gebeurt als er een frame verstuurt wordt met 3 bytes data terwijl het
info veld voor de lengte aangeeft dat er slecht 1 byte data is. Volgens het “System Verification
document” zou dit bericht totaal niet geacknowledged mogen worden door de DUT. In de test
antwoord de DUT steeds met een NACK. Dit betekent dus dat de DUT reageert op dit frame wat niet
zou mogen volgens het KNX protocol. Het betreft hier dus ook een foute implementatie van het KNX
protocol in het KNX silicium. Ook dit wordt aangepast.
47
De hoofdreden voor de aanwezigheid van deze fouten is het feit dat zowel de implementatie van de KNXA chip,
het opstellen van het “System Verification Document” en de implementatie van de reeds bestaande testen in
een VB/Excel applicatie, door één en dezelfde persoon werden uitgevoerd. Het mis interpreteren van een
protocoleigenschap zorgt voor een fout in alle drie de onderdelen wat het opsporen van deze fout nog
moeilijker maakt.
Alle overige vierentwintig testcases krijgen het verdict “pass” wat betekent dat alles correct conform het KNX
protocol verloopt.
2.9.3. Verdere ontwikkelingen in de toekomst
Enkele testen uit het “System Verification document” die in bijlage 1 terug te vinden is, zijn nog niet
geïmplementeerd. Hiervoor zijn twee redenen. Sommige testen konden niet uitgevoerd worden omdat de
functionaliteit die getest moet worden nog niet geïmplementeerd is op het KNXA silicium. De andere reden is
dat de testopstelling die op dit moment voor handen is niet volstaat om de testen rond polling frames af te
werken.
Eerst en vooral zullen de nog niet geïmplementeerde protocoleigenschappen in het KNXA silicium gestopt
moeten worden om dan nadien deze testen te kunnen uitvoeren. Het gaat over de testen: Start Of Frame:
Receive, IACK Timing: Receive, Repetition Flag: Send en BDUT is a Router. De omschrijving van de eerste twee
testen is al geïmplementeerd in de testcases KNXA_StartOfFrame_Receive en KNXA_IackTiming_Receive. Zodra
deze functies in het KNXA silicium geïmplementeerd zijn kunnen deze testcases gebruikt worden om deze
protocoleigenschappen te testen.
Voor de ontwikkeling van de polling frame testen zal een andere testopstelling vereist zijn. Figuur 2-74 toont de
opstelling die nodig zal zijn. Voor deze testen zijn er meer netwerkdeelnemers nodig. Een deel hiervan zal een
polling Group moeten vormen zodat de DUT polling master of slave kan zijn.
Figuur 2-74: Testopstelling polling frame testen
48
Pas nadat alle bovengenoemde testcases correct geïmplementeerd zijn kan er gesproken worden van een
volledig KNX validatie systeem. Dit systeem kan dan gebruikt worden om de juiste werking van het KNXA
silicium te testen zodat het product gecertificeerd kan worden. Deze certificatie laat toe om het product onder
de noemer KNX te verkopen.
Een extra zaak die in de toekomst kan gebeuren is het ontwikkelen van actuatoren en sensoren met het KNXA
silicium. Door het aanmaken van een demo opstelling waarop een KNX netwerk gesimuleerd wordt waarin de
zelf ontwikkelde sensoren en actoren zich bevinden kan ON Semiconductor iets tastbaarder aan de klanten
voorstellen. Dit lijkt zeer geschikt voor toekomstige masterproef onderwerpen.
49
3
Algemeen besluit
Eerst dient gezegd dat deze masterproef van een zuiver vooropgesteld te halen doel stelselmatig gaandeweg
veranderd is naar meer en meer een onderzoeksopdracht. Onderzoek naar hoe de TTCN-3 technologie kan
toegepast worden om de testfase in de ontwikkeling van silicium chips te vergemakkelijken, standaardiseren en
verkorten bij ON Semiconductor.
De verandering van het zwaartepunt van deze masterproef heeft tot gevolg dat niet veel van de
vooropgestelde doelen die in september 2010 opgemaakt werden zijn behaald. Wel werd de TTCN-3
technologie met succes toegepast op het testen van silicium chips. Ook is er een zeer degelijke basis gelegd
met het aanmaken van de zesentwintig testscripts. Deze basis zal ervoor zorgen dat het KNX validatie systeem
binnen afzienbare tijd afgewerkt kan worden.
In deze thesis is vooral een literatuurstudie gemaakt van het KNX protocol en de TTCN-3 technologie.
De grootste les die getrokken moet worden om in de toekomst de testfase zo correct en vlot mogelijk te laten
verlopen is de volgende. Om het risico op fouten te beperken is het noodzakelijk dat het implementeren van de
silicium chip, het opstellen van het “System Verification document” en de implementatie van de test software
niet door één en dezelfde persoon gedaan worden. Een foute interpretatie van het protocol kan leiden tot een
fout in alle drie de onderdelen zonder dat deze ooit ontdekt wordt. Deze fout wordt ook pas redelijk laat in de
ontwikkelingsfase ontdekt wat catastrofaal is voor de planning van de ontwikkeling van het product. Door deze
drie onderdelen van de testfase door drie verschillende personen te laten uitvoeren is er steeds controle op
elkaar. Een team van personen zal ook minder vlug een foute interpretatie van een protocol maken dan één
persoon alleen. Opsplitsen van de taken en het controleren van elkaars werk is hier dus de oplossing om erger
te voorkomen.
Tot slot kan de meerwaarde die mede dankzij deze masterproef gecreëerd is geformuleerd worden als het
verkorten van de testfase van nieuwe projecten. Het feit dat een nieuwe technologie, namelijk TTCN-3, zijn
intrede gemaakt heeft bij ON Semiconductor, zal ervoor zorgen dat in de toekomst de testfase van vele
projecten sterk verkort zal worden. Dit is vooral door het modulaire en schaalbare karakter van TTCN-3 wat
ervoor zorgt dat het creëren van nieuwe testen sterk vereenvoudigd wordt. Dit brengt tijdswinst en op de
lange termijn financiële voordelen met zich mee.
50
4
Referenties
[1] ON Semiconductor bedrijfspresentatie. (Corporate Overview Presentation[1].ppt)
[2] Ing. Capoen H. ,Cursus Factory and Process Automation (FPA)
[3] The KNX Standard v2.0
 03 Volume 3 System Specifications
 03_02_02 Communication Medium TP 1 v1.1 AS
 03_01_01 Architecture v3.0
 03_03_01 Physical Layer General v1.1 AS
 03_03_02 Data Link Layer General v1.2 AS
 08 Volume 8 System Conformance Testing
 8_0_overv_1_1_AS
 8_2_2_tp1_1_2_AS
[4] KNXA_Product_Specification, document dat bij ON Semicondutor is aangemaakt
[5] KNX Association (2009), Certificatie voor producten
http://www.knx.org/be-nl/knx-certificatie/van-producten/ (datum van opzoeking: 16/04/11)
[6] ETSI’s official TTCN-3 web page (2009), Why use TTCN-3?
http://www.ttcn-3.org/Benefits.htm (datum van opzoeking: 19/04/11)
[7] Willcock C., Deiss T., Tobies S., Keil S., Engler F., Schulz S., An Introduction to TTCN-3, Great Britain: Wiley
2005
51
Bijlagen
I. KNX Testspecificaties
Zie bijgevoegd document: System Verification Document
II. Overzicht commando’s naar Host Controllers
Zie bijgevoegd document: KNXA_Verification_Message_Format
52

View/Open

Transcription

Similar documents

NASIONALE SENIOR SERTIFIKAAT GRADE 12

onweer van 25/26 mei 2009

NASIONALE SENIOR SERTIFIKAAT GRAAD 12 GRAAD 12

plaatje - S.V.A.T. Astatine

journal - KNX Association

Zarafa Collaboration Platform

ontslag vergoeding

IntroCursor 3

scriptie

NASIONALE SENIOR SERTIFIKAAT GRAAD 12 GRAAD 12

zoogdieronderzoek nationaal park galicica