Masterproef: KNX validatie systeem

Transcriptie

1 Masterproef: KNX validatie systeem Studiegebied Industriële wetenschappen en technologie Opleiding Master in de industriële wetenschappen: elektrotechniek Afstudeerrichting Automatisering Academiejaar Tim Gobert Academische bachelor- en masteropleidingen, Graaf Karel de Goedelaan 5, 8500 Kortrijk

2 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. KNX validatie systeem II

3 Inhoudsopgave 1 AFKORTINGEN KNX VALIDATIE SYSTEEM Inleiding Voorstelling bedrijf Doelstellingen KNX Protocol studie Inleiding OSI Model Opstelling Fysische laag Datalink laag KNXA testspecificaties Inleiding Testspecificaties TTCN Waarom TTCN-3? An Introduction to TTCN TTCN-3 compiler OPEN TTCN TTCN-3 voor chip testen Test Opstelling KNXA chip Host Controller Testen Resultaten TTCN-3 software Test scripts Verdere ontwikkelingen in de toekomst ALGEMEEN BESLUIT REFERENTIES KNX validatie systeem III

4 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. KNX validatie systeem IV

5 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] Figuur 2-13: modulatie van een logische 0 [3] Figuur 2-14: omzetting naar seriële bitstroom [3] Figuur 2-15: CSMA principe bij KNX protocol [3] Figuur 2-16: Serieel karakter vs. Octet [3] Figuur 2-17: Control Field [3] Figuur 2-18: L_Data_Standard frametype [3] Figuur 2-19: L_Data_Standard frametype(detail) [3] Figuur 2-20: Individueel adres [3] Figuur 2-21: checksum [3] Figuur 2-22: L_Data_Extended frametype [3] Figuur 2-23: L_Data_Extended framtype (detail) [3] Figuur 2-24: Extended Control Field [3] Figuur 2-25: L_Poll_Data request frame [3] Figuur 2-26: L_Poll_Data response frame [3] Figuur 2-27: Acknowledgement frame [3] Figuur 2-28: logo TTCN Figuur 2-29: Logo ETSI Figuur 2-30: Boek "An Introduction to TTCN-3 [3] Figuur 2-31: Alternative Statement Figuur 2-32: Conceptueel model van een TTCN-3 test systeem Figuur 2-33: Voorbeeld KNX testcase Figuur 2-34: Interactie tussen de test systeem entiteiten Figuur 2-35: Type definities Figuur 2-36: Template definities Figuur 2-37: Test Case Figuur 2-38: Control definities Figuur 2-39: schema testopstelling Figuur 2-40: Opbouw parallelle testomgeving Figuur 2-41: Softwarematige opbouw parallelle testomgeving Figuur 2-42: Logo OpenTTCN Figuur 2-43: Lay-out OpenTTCN Figuur 2-44: fysische testopstelling Figuur 2-45: Diagram van het KNXA silicium KNX validatie systeem V

6 Figuur 2-46: Implementatie KNX protocol Figuur 2-47: Architectuur KNXA silicium Figuur 2-48: Host controller bord Figuur 2-49: Doel van het bericht Figuur 2-50: overzicht berichten host controller Figuur 2-51: U_Reset.req bericht Figuur 2-52: U_State.req bericht Figuur 2-53: U_Busmon.req commando Figuur 2-54: U_IntRegWr.req bericht Figuur 2-55: U_IntRegRd.req bericht Figuur 2-56: U_L_DataStart.req commando Figuur 2-57: U_PollingState.req commando Figuur 2-58: Doel van het bericht Figuur 2-59: overzicht berichten KNXA Figuur 2-60: L_Data_Standard.ind service of L_Data_Extended.ind commando Figuur 2-61: Foute testopstelling Figuur 2-62: Correcte testopstelling Figuur 2-63: Modules Figuur 2-64: Test Cases Figuur 2-65: Test case KNXA_SendTelegram Figuur 2-66: Aanmaken Test Case Figuur 2-67: Initialiseren en afbreken communicatie Figuur 2-68: Function f_phyini Figuur 2-69: template phyini Figuur 2-70: Ontvangen phyini Figuur 2-71: templates request en answer frame Figuur 2-72: Frame versturen Figuur 2-73: Afgewerkte testcases Figuur 2-74: Testopstelling polling frame testen KNX validatie systeem VI

7 1 Afkortingen CD : Coding and Decoding CH : Component Handling CSMA/CA : Carrier Sense Multiple Access with Collision Avoidance CTRL : Control karakterframe DA : Destination Address DNS : Domain Name System DUT : Device Under Test ETSI : Europees Telecommunicatie Standaardisatie Instituut KNXA : De silicium chip ontwikkeld door ON Semiconductor die het KNX protocol implementeert KNX : Standaard protocol voor gebouwenautomatisering MAC : Medium Access Control MAU : Medium Attachment Unit MTC : Main Test Component OSI : Staat voor Open Systems Interconnection en beschrijft de verdeling van netwerkfuncties in zeven lagen. Opgesteld door het ISO. PA : Platform Adapter PHY : Physical layer PTC : Parallel Test Component SA : Source Address SA : SUT Adapter SUT : System Under Test tbit : De lengte in tijd van één bit, bij KNX is dit 104μs. TCI : TTCN-3 Control Interface TE : TTCN-3 Executable TM : Test Management TMC : Test Management & Control TP : Twisted Pair, twee getorste koperdraden die als medium gebruikt kunnen worden TSI : Test System Interface TSU : Test System User TTCN-3 : Testing and Test Control Notation 3 TTCN-3 ATS : TTCN-3 Abstract Test Suite TRI : TTCN-3 Runtime Interface UART : Universal Asynchronous Receiver and Transmitter 1

8 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 CO 2 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

9 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 CO 2 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 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

10 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

11 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

12 2.4. KNX Protocol studie 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 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

13 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

14 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

15 Fysische laag De fysische laag [3] bestaat uit vier blokken die verduidelijkt worden in Figuur Het medium, hier Twisted Pair. 2. De connector die het toestel koppelt met het medium. 3. 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. 4. 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 Figuur 2-11: KNX bustopologie 9

16 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 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 hierboven vermeld is de logische 0 dominant t.o.v. een logische 1.. Figuur 2-13 verduidelijkt dit principe. Zoals 10

17 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

18 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 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 , 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 zal de prioriteit hebben op frame2 met octet

19 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

20 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

21 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

22 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

23 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 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

24 2.5. KNXA testspecificaties 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 Europese standaard EN (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 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

25 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 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

26 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 Basisprincipe TTCN-3 Figuur 2-30: Boek "An Introduction to TTCN-3 [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

27 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 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 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

28 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 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

29 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

30 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 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

31 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

32 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 De werking van parallelle testen wordt voorgesteld in Figuur Figuur 2-40: Opbouw parallelle testomgeving 26

33 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

34 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 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 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

35 Figuur 2-43: Lay-out OpenTTCN 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

36 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 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

37 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 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 en meer uitleg gegeven worden over respectievelijk de KNXA chip en de Host Controller. In paragraaf zal de uitleg van het eigenlijke testen volgen. 31

38 Interface Controller KNXA chip 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 from VDD1 C2 C3 C4 CEQ1 CEQ2 VFILT VDDD VSSD C9 CAV Bus coupler SCK KNX bus D1 D2 R1 VBUS1 C1 CCP TXO Impedance Control Receiver Transmitter RX KNX DLL Tx / Rx Buffer UART SPI Master / Slave Test Ctrl Mode Ctrl SDI / RXD SDO / TXD CSB TREQ MODE1 MODE2 from/to host controller TX KNX bus VBUS2 VIN from VFILT from VDD1 VDDA C5 KNXA DC/DC 1 VSW1 VDD1M VDD1 L1 R2 C7 VDD1 VSSA VSS1 S1 WAKE V20V C6 Q1 V20V XTAL1 XTAL2 XSEL 20 V LDO OSC OSC Wake -up Bandgap TSD POR UVD DC/DC 2 VSW2 VDD2MC VDD2MV VDD2 VSS2 L2 R3 R4 R5 C8 VDD2 XCLK SAVEB RESETB TESTOUT Figuur 2-45: Diagram van het KNXA silicium 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 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

39 Interface controller 7 Application Layer 6 Presentation Layer 5 4 Session Layer Transport Layer Host Controller 3 Network Layer 2 Logical Link Control Data Link Layer Media Access Control KNXA 1 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 Architectuur KNXA silicium 4.7nF VFILT 100uF 100nF from VDD1 CEQ1 CEQ2 VFILT VDDD VSSD 1uF CAV VBUS1 Bus Coupler, Impedance Control VFILT KNX RCOSC XTALOSC PORB KNX Data Link Layer UART RXB TXB DIG SCK SDI / RXD 470nF CCP Receiver RX RX TX SPI Master / Slave SDO / TXD CSB TREQ 27R KNX bus TXO VBUS2 Transmitter TX OTP controller RAM BIST WD Watch Dog Test Ctrl Mode Ctrl MODE1 MODE2 VDDD VDDD V20V 1uF V20V VFILT VAUX VBUS1 OTP cells ANA RCOSC EN Power switch control, Over-current Flyback switch control DC1 COMP VREF VIN VSW1 VSS1 from VFILT 1R0 VDD1=3.3V 10uF VAUX Over-voltage COMP VREF VDD1M WAKE Wake-Up Bandgap BIAS Trimming Over-current COMP VDD1 from VDD1 16 MHz 100nF VDDA VSSA XTAL1 XTAL2 VDDA RC RCOSC oscillator VDDD EN XTAL EN oscillator XTALOSC VBG_OK Temp Voltage monitor monitor TEMPB POR PORB VFILT VBUS1 V20V WD EN ANA signals RCOSC EN Power switch control, Over-current Flyback switch control Over-voltage DC2 VREF COMP VREF COMP VSW2 VSS2 VDD2MV 1R0 VDD2=3.3-20V 10uF XSEL TESTIN from DIG Over-current COMP VDD2MC VDD2 XCLK SAVEB RESETB TESTOUT Figuur 2-47: Architectuur KNXA silicium 33

40 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 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 Communicatie tussen Host Controller en KNXA chip In de volgende paragrafen wordt de communicatie tussen KNXA silicium en host controller weergegeven 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

41 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 Remark Extra following data Bytes Internal commands - device specific U_Reset.req none U_State.req none U_Busmon.req none n b a U_Ackn.req nba=nack,busy,addressed none a a a a U_IntRegWr.req aaaa=address, Value to be written into internal register a a a a U_IntRegRd.req aaaa=address, Value read from internal register 2 KNX transmit data commands U_L_DataStart.req Control octet (CTRL) i i i i i i U_L_DataCont.req i=index, Data octet (CTRLE, SA, DA, AT, NPCI, LG, TPDU) l l l l l l U_L_DataEnd.req l=last_index+1, Check octet (FCS) s s s s U_PollingState.req s=slot_number, PollAddrHigh + PollAddrLow + PollState 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 Type: Intern bericht van één byte. 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

42 U_Busmon.req bericht Type: Intern bericht van één byte. 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 Type: Intern bericht van één byte. 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

43 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 Type: Twee byte groot commando voor het verzenden van een KNX 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 Type: Twee byte groot commando voor het verzenden van een KNX 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 L_Data.ind Data byte Data byte... Checksum Control byte Data byte Data byte... Checksum L_Data.con Immediate acknowledge 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

44 Polling frame - slave Host ctrl KNXA KNX bus L_Poll_Data.ind U_PollingState.req PollAddrHigh PollAddrLow PollState Control byte Source address Source address Poll address Poll address Slot count Checksum Slot 0 Slot 1 Figuur 2-57: U_PollingState.req commando 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 Bytes 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 n 0 0 r 1 p1 p0 0 0 L_Data_Extended.ind p1,p0=priority n L_Poll_Data.ind n Acknowledge services - the device is transparent in bus monitor mode x x 0 0 x x 0 0 L_Ackn.ind Acknowledge frame 1 x L_Data.con x=1 positive, 0 negative confirmation 1 Control services - device specific U_Reset.ind 1 sc re te pe tw U_State.ind sc=slave collision, re=receive error, te=transmit error, pe=protocol error, tw=temperature warning 1 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

45 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 L_Data.ind Data byte Data byte.. U_Ackn.req Data byte.. Checksum Control byte Data byte 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 Type: Intern bericht van één byte. Functie: Het antwoord op een U_Reset.req bericht van de host controller. Figuur 2-51 stelt dit grafisch voor. U_State.ind bericht Type: Intern bericht van één byte. Functie: Het antwoord op een U_Stata.req bericht van de host controller. Figuur 2-52 stelt dit grafisch voor. 39

46 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

47 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 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

48 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 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

49 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

50 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 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

51 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

52 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 TTCN-3 software Zoals in paragraaf 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 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

53 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

54 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 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