Examensarbete, 15 hp
Högskoleingenjörsprogrammet i Elektronik och datorteknik, 180 hp
Vt 2021
SIMULERINGSMODELL AV
TRÖGHETSNAVIGATOR
Simulation model of Inertial Navigation System
Markus Bergendorff
Abstract
When time for development of new products is shortened, testing and verification must be performed at an earlier stage of development. By simulating the system, tests can be performed without access to the actual system and thus the development process can be accelerated.
BAE Systems Hägglunds manufacture combat vehicles and use an Inertial Navigation System (INS) to calculate the combat vehicle’s position without external references.
Testing and verification of navigation with this unit in the test bench is not entirely possible.
The aim of this thesis is to enable realistic tests, in a test bench in the development phase, by simulating the navigator’s functions. Since communication with the Vehicle Control System (VCS) must take place in real time at the same time as navigation data must be read from external program, the model is required to have sufficient performance to provide a realistic simulation.
The overall question in this thesis is whether a model realized on a microcontroller (MCU) has sufficient performance to be used for simulation of an INS. To answer the question at issue, hardware for adapting the interface between the VCS, MCU and external program as well as software for simulating an INS have been created. Thereafter, the model has been verified by measuring the time for selected processes.
Not all functions of the navigator have been implemented in the simulation model, but the results show that the model can be used for realistic tests in the test bench.
Sammanfattning
När tiden för utveckling av nya produkter kortas ner måste testning och verifiering utföras i ett tidigare utvecklingsstadie. Genom simulering av systemet kan tester utföras utan tillgång till det faktiska systemet och därmed kan utvecklingsprocessen accelereras.
I BAE Systems Hägglunds stridsvagnar används en tröghetsnavigator som kan beräkna stridsvagnens position utan externa referenser. Test och verifiering av navigation med denna enhet i testbänk är ej fullt möjligt.
Syftet med detta arbete är att kunna genomföra verklighetstrogna tester, i testbänk i utvecklingsfasen, genom att simulera navigatorns funktioner. Eftersom kommunikation med fordonssystemet ska ske i realtid samtidigt som navigationsdata läses från ett externt program, så ställs krav på att modellen har tillräcklig prestanda för att ge en
verklighetstrogen simulering.
Den övergripande frågeställningen i detta examensarbete är om en modell realiserad på en mikrokontroller (MCU) har tillräcklig prestanda för att användas vid simulering av en tröghetsnavigator. För att besvara frågeställningen har hårdvara för anpassning av gränssnittet mellan fordonssystem, MCU och externt program samt mjukvara för att simulera en tröghetsnavigator skapats. Därefter har modellen verifierats genom att mäta tiden för utvalda processer.
Alla funktioner hos navigatorn har inte implementerats i simuleringsmodellen men resultaten visar att modellen kan användas för verklighetstrogna tester i testbänk.
Förord
Jag skulle vilja tacka BAE Systems Hägglunds i Örnsköldsvik för att jag fått möjligheten att vara Co-op student samt utföra mitt examensarbete hos dem. Jag vill även tacka alla på SIL-avdelningen där Co-op samarbetet och examensarbetets utförts på. De har gett
värdefulla insikter i ingenjörsyrket samt möjligheten att fortsätta min kompetensutveckling under utbildningens sommaruppehåll.
Jag vill särskilt tacka Stefan Ladänges som varit min handledare på avdelningen och som hjälpt mig genom hela arbetet. Ett stort tack ska även riktas till Markus Dahlberg som även assisterat mig med utrustning, expertis och tester. Jag vill även rikta ett särskilt tack till Mikael Söderberg som stöttat samt hjälpt till med sekretess- och administrativa frågor.
Till sist vill jag även tacka min universitetshandledare Nils Lundgren som givit värdefull feedback och tips genom hela arbetet.
Innehåll
1. Introduktion ... 1
1.1. Frågeställning ... 1
1.2. Syfte ... 2
1.3. Mål ... 2
1.3.1. Övergripande målet ... 2
1.3.2. Delmål ... 2
1.4. Kravspecifikation ... 2
2. Teori ... 3
2.1. Tröghetsnavigatorn ... 3
2.2. RS-422 ... 4
2.3. Controller Area Network ... 4
2.4. STM32L476RG ... 4
2.4.1. General-purpose timers ... 4
3. Systembeskrivning ... 6
3.1. Metod ... 6
3.2. Program ... 6
3.2.1. STM32CubeIDE ... 6
3.2.2. Docklight ... 7
3.2.3. Kvaser’s CanKing ... 7
3.2.4. CANoe ... 7
3.3. Hårdvara ... 7
3.3.1. Maxim integrated MAX488CPA ... 7
3.3.2. CAN-BUS Shield ... 7
3.3.3. STM32L476RG ... 7
3.3.4. VScom USB-COM-I ... 8
3.3.5. Kvaser USBcan II HS/HS ... 8
3.4. Mjukvara ... 8
3.4.1. Timers ... 8
3.4.2. Gränssnitt initiering ... 9
3.4.2.1. SPI1 ... 9
3.4.2.2. USART2 ... 9
3.4.3. CAN-BUS Shield ... 9
3.4.4. Simuleringsmodell ... 9
4. Resultat ... 12
4.1. Hårdvara ... 12
4.2. Mjukvara ... 13
4.3. Verifiering av prestanda ... 13
5. Diskussion ... 17
5.1. Metod ... 17
5.2. Resultat ... 17
5.3. Sändnings- och timerprocess ... 17
5.4. Receivemeddelanden ... 18
5.5. Felhantering ... 18
6. Slutsats ... 19
7. Referenser ... 20
1
1. Introduktion
Möjligheten att simulera modeller och system är en viktig del i utvecklingen av en produkt. Utvecklingstiden av produkter blir allt kortare vilket medför att testning och verifiering av delsystem måste utföras i tidigare utvecklingsstadie. Genom simulering av system kan tester utföras utan tillgång till det faktiska systemet. Detta möjliggör tester av systemet i en verklighetstrogen simulerad miljö, som kan medföra mer kostnad- och tidseffektiv produktutveckling. [1].
En tröghetsnavigator utnyttjar en metod för att navigera utan användning av externa referenser. Genom användning av interna system i form av exempelvis gyroskop och accelerometer tillsammans med en utgångspunkt, kan tröghetsnavigatorn avgöra dess position. Tack vare att systemet kan navigera utan externa referenser så blir den väldigt störningstålig och kan inte avlyssnas. Detta gör att tröghetsnavigatorn är väldigt attraktiv i system där störningar och avlyssning inte får inträffa eller i största mån minimeras.
Områden där dessa navigatorer förekommer kan vara inom militären, fartyg, ubåtar, flygplan, rymdskepp, mm. men förekommer alltmer i vardagsprodukter som exempelvis mobiler [2]. Mer komplexa INS (Inertial Navigation System) kan var kostnads- och tidsödande att testa, vilket inte är önskvärt vid produktion. Därför kan dessa
tröghetsnavigatorer simuleras och därmed skapa mer effektiva test- och verifieringsmetoder.
I detta arbete ska en modell av en tröghetsnavigator för stridsvagn simuleras och det kommer utföras på försvarsindustriföretaget BAE Systems Hägglunds. Företaget är lokaliserat i Örnsköldsvik där en av dess avdelningar är System Integration Labratory (SIL). SIL:s uppgift är att integrera, verifiera och testa vetroniken (elektronik och mjukvara) i deras fordonssystem i utvecklingsfasen. Eftersom det inte är ekonomiskt, tidseffektivt eller möjligt att verifiera och testa allt på ett fysiskt fordon, så görs många av dessa tester inomhus i testbänkar. Detta tillför även till en ökad ekologisk hållbarhet då ett fysiskt test kan kräva många resurser.
Denna tröghetsnavigator är en av de enheter som utgör en del i stridsvagnens kompletta system och är viktig att kontrollera funktionen hos. Eftersom många tester utförs inomhus i testbänkar så kan det försvåra vissa tester på denna INS. Möjligheten att verifiera korrekt position under alla förhållanden kan exempelvis vara ett av problemen att testa i testbänk.
Därför skall en simuleringsmodell av denna tröghetsnavigator skapas, för att möjliggöra tester i en mer verklighetstrogen miljö.
Ett försök att implementera denna simuleringsmodell på dator har tidigare gjorts dock utan godkänt resultat, på grund av operativsystems brist på realtidskontroll. Därför skall det testas på nytt med hjälp av MCU (mikrokontroller), vilket kan möjliggöra en mer realtidsbaserad kontroll av systemet. Tanken är att MCU:n skall agera som
tröghetsnavigatorns processeringsenhet och gränssnitt mellan de externa enheterna. Ett externt program vid namn CANoe skall mata MCU:n med information om startposition, hastigheter och riktning, vilket kommer att agera som sensorerna i navigatorn. MCU:n och CANoe kommer tillsammans utgöra den simuleringsmodell som skall föreställa den faktiska enheten.
1.1. Frågeställning
Är en MCU prestandamässigt tillräcklig för att återskapa en verklighetstrogen simuleringsmodell av en tröghetsnavigator?
2 1.2. Syfte
Syftet med detta arbete är att möjliggöra mer verklighetstrogna tester av tröghetsnavigatorn i testbänk i utvecklingsfasen.
1.3. Mål
1.3.1. Övergripande målet
Skapa en simuleringsmodell på mikrokontroller som efterliknar den specifika tröghetsnavigatorn, vilket ska ge bättre realtidskontroll.
1.3.2. Delmål
• Logga och analysera informationsutbytet mellan tröghetsnavigatorn och fordonssystemet.
• Anpassa gränssnitt mellan MCU och övriga system för kompatibla dataöverföringar.
• Framställa mjukvaran till MCU:n som kommer agera som tröghetsnavigatorns processeringsenhet och gränssnitt.
• Testa och verifiera produktens funktioner i det kompletta systemet.
1.4. Kravspecifikation
Denna produkt utvecklas för att möjliggöra tester av tröghetsnavigatorn i en mer
verklighetstrogen miljö. Därför kommer den inte att tillverkas i större mängder eller säljas, utan enbart användas som testverktyg på SIL avdelningen. Det finns inga ekonomiska eller miljöpåverkande krav, utan störst vikt ligger på funktion och prestanda hos
produkten. Eventuell sammanställning av användardokumentation kan skapas för fortsatt arbete med produkten. Krav och dess prioritering kan ses i tabell 1.
Tabell 1. Kravspecifikation för produkten.
Krav nr Kravbeskrivning Prioritet
1 Gränssnitten mellan delsystemen är kompatibel. 1
2 Återskapa tröghetsnavigatorns funktioner på simuleringsmodellen 1
3 Prestandamässigt tillräcklig hårdvara och mjukvara hos simuleringsmodellen för
att återskapa tröghetsnavigatorn. 1
4 Enkel övergriplig användardokumentation över produktens funktion. 2
3
2. Teori
2.1. Tröghetsnavigatorn
All kommunikation mellan tröghetsnavigatorn och fordonsystemet initieras alltid av fordonsystemet. Det är alltså fordonssystemet som är master och tröghetsnavigatorn som är slav. Fordonssystemet kan skicka två olika meddelande typer, Receive och Transmit request. Dessa skiljer sig åt utifrån dess meddelande ID och meddelandeuppbyggnad.
Ett meddelande initieras alltid med en startsekvens följt av ett ID och avslutas alltid med checksumma tillsammans med en slutsekvens. Resterande block i meddelandena kan se olika ut beroende på vilket typ av meddelande samt vilket riktning meddelandet har. En enklare översikt av meddelandevarianterna kan ses i figur 1.
Figur 1. Enkel översikt av meddelandevarianterna.
Beskrivning av blocken i meddelande kan ses i tabell 2.
Tabell 2. Blockbeskrivning av meddelande.
Block Beskrivning
Start seq. Initieringssekvens
ID Beskriver meddelandetyp och meddelandeadress
Status Information om fel
Init. Information om överföringsfrekvens
Data Information om INS inställningar, begärd data från tröghetsnavigator eller sänd data till fordonssystemet
Checksum Kontrollsumma för upptäckt av fel i meddelandet
End seq. Avslutningssekvens
Ett receivemeddelande kan antingen innebära en viss inställning för tröghetsnavigatorn eller att fordonssystemet begär en specifik information från tröghetsnavigatorn. Då fordonssystemet begär data med ett receivemeddelande skickar tröghetsnavigatorn alltid tillbaka datan via ett transmitmeddelande EN gång. För att kräva periodisk information skickas en transmit request, som innehåller vilken information som skall sändas samt med vilken periodicitet. Responsen på en transmit request besvaras alltid med ett
4 transmitmeddelande och sänds med periodiciteten angiven i transmit request meddelandet.
Det finns fem olika periodiciteter och dessa kan ses i tabell 3.
Tabell 3. Tröghetsnavigatorns transmitperiodiciteter.
Periodicitet Överföringsfrekvens
1s 1Hz
100ms 10Hz
50ms 20Hz
25ms 40Hz
10ms 100Hz
2.2. RS-422
RS-422 är en teknisk standard skapad av Electronic Industries Alliance och specificerar elektriska karakteristiken av en digital signalkrets. Denna standard var tänkt att ersätta den äldre RS-232 standarden, vilket skulle erbjuda högre hastigheter, bättre brusimmunitet och längre kabellängder.
Detta gränssnitt är differentiellt och har en maximal överföringshastighet på 10 Mbit/s.
Det är ett fullt duplex gränssnitt med möjlighet att ansluta upp till 10 enheter, 1 driver och 10 receivers, på en buss. Varje buss skall termineras med 100 – 150 Ω och skall endast termineras vid den yttersta enheten [3].
2.3. Controller Area Network
CAN är en standard avsedd för fordon och utvecklad av Bosch. Det är ett av de vanligaste gränssnitten för databussöverföringar i fordonsindustrin och har på senare tid blivit
vanligare i andra sammanhang.
Signalerna skickas över en differentiell databuss och ett flertal noder kan parallellt anslutas till bussen. Den klarar överföringshastigheter upp till 1 Mbit/s vid kabellängder mindre än 40 meter, men kan skicka över längre sträckor vid lägre hastigheter. Varje buss skall termineras med 120 Ω vid bussens ändnoder [4, 5].
2.4. STM32L476RG
STM32L476RG är en mikrokontroller utvecklad av STMicroelectronics och som är baserad på ARM Cortex-M4 processorn. Den har en maximal klockfrekvens på 80 MHz och erbjuder en rad olika funktioner, vilket tillämpar sig för många olika applikationer.
Den har flera olika kommunikationsgränssnitt, där USART och SPI var av störst vikt för detta projekt. Den är även utrustad med CAN, dock krävs en extern transceiver för att konvertera signalen till differentiell. Tillgång till flera timers har även varit nödvändigt för att utföra detta projekt, vilket denna MCU är utrustad med [6].
Denna mikrokontroller finns även tillgänglig på STMicroelectronics utvecklingskort, vid namn NUCLEO-L476RG, och är det som använts under projektets gång. Detta
möjliggjorde enklare utveckling av produkten, genom dess medföljande programmerare samt dess enkla åtkomst till I/O portarna. Vissa av dessa I/O portar är även anpassade för att passa Arduinos pinutformning, vilket varit en praktisk funktion vid utvecklingen av produkten [7].
2.4.1. General-purpose timers
Flera olika timers har använts i detta projekt. Det är viktigt att dessa är initierade korrekt så att de har rätt funktion och rätt periodicitet. För inställning av timers periodicitet är det
5 tre register som är av störst betydelse, Count Register (CNT), Prescaler Register (PSC) och Auto-Reload Register (ARR). Count Register är det register som håller räknarvärdet och räknaren kan initieras i olika lägen (ex. incremental, decremental). Prescaler Register håller det värde räknarklockan (CLK) skall skalas ned med i förhållande till dess
periferiklockfrekvens. Auto-Reload Register håller värdet räknaren skall räkna till innan exempelvis timer reset [8]. Med dessa tre register, tillsammans med
räknarklockfrekvensen, kan timerns frekvens (f) beräknas enligt följande formel.
𝑓 = 1 ((𝑃𝑆𝐶 + 1) ∗ (𝐴𝑅𝑅 + 1) 𝐶𝐿𝐾⁄ ⁄ ) (1)
6
3. Systembeskrivning
3.1. Metod
En stor del av arbetet har varit att identifiera vad som behövs och förstå hur
tröghetsnavigatorn fungerar. Inledningsvis identifierades vilka gränssnitt som krävdes och därefter kontrollera ifall MCU är kompatibel med dessa. Eftersom dessa gränssnitt ej var kompatibel krävdes adapters, vilket var nästa steg i arbetet. Konstruera, applicera och kontrollera att dessa fungerade, gjordes med hjälp av terminalprogram. Därefter loggades data mellan fordonssystemet och tröghetsnavigatorn. Denna information användes, tillsammans med tröghetsnavigatorns användarmanual, för att förstå hur navigatorn fungerade. Utifrån detta kunde sedan en simuleringsmodell utformas för att återskapa tröghetsnavigatorn. Ett grovt blockschema över projektet kan ses i figur 2.
Figur 2. Blockschema över simuleringsmodellen av tröghetsnavigatorn.
3.2. Program
3.2.1. STM32CubeIDE
STM32CubeIDE är en, allt-i-ett, utvecklingsmiljö för STMicroelectronics 32-bitars mikrokontrollers och mikroprocessorer [9]. Det har flera funktioner som underlättar utvecklingen, där grafisk gränsyta och debugging är några av de viktigare.
Den grafiska gränsytan är ett enkelt verktyg för initieringar av portar, klockor, gränssnitt, timers, mm. där initierings kod genereras via gränsytan. Detta underlättar och accelererar initieringsarbetet med en mikrokontroller, då det inte krävs samma grundläggande förståelse med initieringar.
Debugging verktyget är ett nödvändigt verktyg, vilket ger utvecklaren möjlighet att stega igenom ens program. Detta kan ge kritisk information om värden i register eller ifall något går snett.
7 3.2.2. Docklight
Docklight är ett terminalprogram för seriell kommunikation [10]. Det kan kommunicera eller lyssna över två COM portar samtidigt, vilket har varit en viktig funktion för detta projekt. En viktig funktion har varit att kunna ange mottagna sekvenser, vilket möjliggjort generering av olika respons. Det har exempelvis genererat nya rader ifall ett meddelande slutar med en viss sekvens, vilket underlättat analyseringen av data. Programmet klarar även av att skicka angivna sekvenser med specifik periodicitet, vilket använts för att efterlikna fordonssystemet.
3.2.3. Kvaser’s CanKing
CanKing är ett CAN-buss kontrollverktyg, för kommunikation över CAN [11]. Det har använts för att kontrollera att kommunikation över CAN fungerar korrekt samt att MCU kan hantera frekventa mängder data snabbt nog.
3.2.4. CANoe
CANoe är ett mjukvaruverktyg för utveckling och testning, främst riktat mot
fordonsindustrin [12]. Detta verktyg är en del i den kompletta simuleringsmodellen, vilket skall agera som själva sensorerna i tröghetsnavigatorn. Det ska exempelvis skicka
information om position, riktning och hastighet.
3.3. Hårdvara
3.3.1. Maxim integrated MAX488CPA
Fordonssystemets gränssnitt till tröghetsnavigatorn är RS-422, vilket inte är ett
kompatibelt gränssnitt till mikrokontrollern. RS-422 och USART har vissa likheter och därför finns det enkla sätt att konvertera mellan dessa gränssnitt. MAX488CPA är en enkel IC duplex transceiver som kan konvertera åt båda hållen.
Denna IC finns i DIP kapsel, vilket underlättar konstruktion på perfboard. Denna IC fanns även tillgänglig på labbet, vilket var en av anledningarna till valet av den. Kretsens RS- 422 sida ansluts till en 9 pin D-sub för enkel anslutning [13].
3.3.2. CAN-BUS Shield
Gränssnittet mellan det externa programmet CANoe och mikrokontroller sker över CAN.
STM32L476RG är utrustad med CAN-controller och nödvändiga protokoll, däremot krävs en CAN-transceiver för att konvertera signalerna till differentiella samt ge signalerna rätt amplitud.
Eftersom en sådan transceiver ej fanns tillgänglig på labbet så användes en CAN-BUS Shield från Sparkfun, vilket fanns tillgängligt. Denna enhet består av en CAN-controller tillsammans med en CAN-transceiver. Den kan konvertera datan mellan SPI och CAN, vilket kan ge alla mikrokontroller med SPI möjligheten att kommunicera med CAN.
Denna enhets pinutformning är anpassad för att passa Arduino, vilket då även passar NUCLEO-kortet. Tack vare detta blev det en enkel fysisk installation. CAN anslutningen på detta kort sker via en 9 pin D-sub, där CAN High är pin 3 och CAN Low är pin 5 [14].
För att skapa en kompatibel anslutning med den använda CAN-utrustningen kontakterades dessa om till CAN High pin 7 och CAN Low pin 2.
3.3.3. STM32L476RG
Eftersom relativt stora mängder data med förhållandevis höga periodicitet skulle överföras och mottagas, så krävdes det hårdvara som var prestandamässigt tillräcklig. Valet att
8 implementera denna simuleringsmodell på mikrokontroller var framför allt egenskapen till mer realtidsbaserad beräkning och kontroll [15]. Till skillnad ifrån mikroprocessorer, där kontroll över när beräkningen utförs bestäms av operativsystemet, så fås bättre kontroll med mikrokontroller.
NUCLEO-kortet med dess Arduino pinutformning har varit en viktig funktion i projektet.
Både CAN-BUS Shield och konstruerade RS-422 adaptern är utformade för att passa Arduino pinutformningen. För att möjliggöra USART kommunikation på önskad Arduino port krävdes omlödning av vissa jumpers. Detta åstadkoms genom att jumper SB62 och SB63 är på medan SB13 och SB14 är av [7].
En layout över NUCLEO-kortets pinutformning kan ses i figur 3.
Figur 3. Pinutformning för NUCLEO-L476RG.
3.3.4. VScom USB-COM-I
För konvertering av data mellan RS-422 och USB, vid utveckling, användes VScom USB- COM-I. Det är en enkel adapter som kan konfigureras via jumpers på kretskortet, vilket ger möjlighet att ställa in adaptern för olika ändamål [16].
3.3.5. Kvaser USBcan II HS/HS
För konvertering av data mellan CAN och USB, vid utveckling, användes Kvaser USBcan II HS/HS [17]. Tillsammans med Kvaser’s CanKing kan en enkel CAN kommunikation åstadkommas mellan dator och MCU.
3.4. Mjukvara
All mjukvaruutveckling i detta projekt är utvecklat i STM32CubeIDE samt skrivet i C.
Initierings och gränssnitt relaterade funktioner utnyttjar HAL, vilket underlättar och påskyndar arbetet med dem [18].
3.4.1. Timers
I MCU implementationen sker all periodisk kommunikation med hjälp av interrupt styrda timers, för att få så precis timing som möjligt. Mikrokontrollern har fem olika
överföringsfrekvens, 1 Hz, 10 Hz, 20 Hz, 40 Hz, 100 Hz, som alla är aktiverade samtidigt.
9 Ett transmitmeddelande begär att information skall periodiskt överföras med någon av dessa fem olika frekvenser. Flera meddelanden med antingen samma eller olika överföringsfrekvens kan vara aktiva samtidigt.
Initierings värdena för dessa timers samt dess överföringsfrekvens, baserat på ekv.(1), kan ses i tabell 4.
Tabell 4. Timer initieringsvärden.
Timer CLK (MHz) PSC ARR Frekvens (Hz) NVIC prio
TIM1 80 7999 9999 1 2
TIM2 80 7999 999 10 2
TIM3 80 7999 499 20 2
TIM4 80 7999 249 40 2
TIM15 80 7999 99 100 2
3.4.2. Gränssnitt initiering 3.4.2.1. SPI1
SPI1 initierades enligt Motorola format, med 8 bits data storlek. Baud rate sattes till 10 MBits/s genom klocknedskalning med 8. DMA för både transmit och receive, tillsammans med SPI interrupt, ansattes. NVIC prioriteten för SPI avbrottet sattes till 1 och DMA sattes till 0.
3.4.2.2. USART2
USART2 initierades med 8 bits data storlek, ingen paritet och en stopp bit. Baud rate sattes till 115200 Bits/s. Interrupt initierades med en NVIC prioritet på 1.
3.4.3. CAN-BUS Shield
Sparkfuns CAN-BUS Shield finns tillgänglig med bibliotek anpassade för Arduino på Github. För att tillämpa dessa till den använda mikrokontrollern, krävdes en del
justeringar och anpassningar. Det var delvis omskrivning från C++ till C kod, men även anpassa portar från Arduino till STM32L476RG [14].
Alla CAN-BUS Shield initieringar och kommunikation är baserade på exempel från dess Github. Där ett pollat exempel för inhämtning av data från CAN sker genom att avläsa en pinne på kortet, vilket indikerar ifall det finns ett meddelande i buffern. För att göra detta interrupt styrt sattes denna pinne till ett EXTI interrupt. Detta möjliggör inhämtning av data endast då meddelande finns tillgängligt och kräver ingen pollad övervakning. Detta EXTI interrupt har en NVIC prioritet på 1.
3.4.4. Simuleringsmodell
Som tidigare nämnts så agerar tröghetsnavigatorn som slav, vilket även denna
simuleringsmodell gör. Den skickar alltså ingen data förrän den fått ett kommando från fordonssystemet. Efter initieringar är systemet redo att ta emot meddelanden från fordonssystemet. När ett sådant meddelande mottags bearbetas det och besvaras med korresponderande meddelande. Beroende på vilken meddelandetyp som mottogs, som anges i ID, hanteras dessa olika. En överföringsfrekvens ansätts beroende på
meddelandetyp samt vad som angetts i det mottagna meddelandet. Receivemeddelanden skickas alltid EN gång medan transmitmeddelanden skickas med periodiciteten som anges i init. i transmit request. Denna mottagning- och sammanställningsprocess kan ses i figur 4. Denna process skickar inget meddelande utan bara sammanställer ett
responsmeddelande.
10
Figur 4. Mottagnings- och sammanställningsprocess av meddelanden.
Det är sedan timer interrupt som bestämmer när dessa sammanställda
responsmeddelanden skall skickas. Alla timers är aktiverade samtidigt och alla har en egen process för att kontrollera ifall ett meddelande skall skickas med dess överföringsfrekvens.
Ifall ett meddelande har en angiven överföringsfrekvens sätts en flagga, som anger att det är redo för sändning, i dess motsvarande timer interrupt. Endast i avbrottsrutinen för TIM15 skickas meddelanden som är redo, via pollad USART sändning. Denna sändnings- och timerprocess kan ses i figur 5.
Figur 5. Sändnings- och timerprocess för meddelanden.
Information om position, hastighet och riktning skall hanteras av CANoe, som sedan skickas till MCU via CAN. Denna information hämtas endast vid indikation från CAN- BUS Shield kortet som är kopplat till ett EXTI interrupt. Vid indikation läggs datan i
11 motsvarande variabler, som sedan kan hämtas vid meddelande sammanställningen. En enkel översikt över denna process kan ses i figur 6.
Figur 6. CANoe inhämtningsprocess.
12
4. Resultat
Krav uppfyllda från kravspecifikationen kan ses i tabell 5. Krav nummer två och tre är endast delvist uppfyllda, vilket baseras på att vissa funktioner saknas samt att mjukvaran ej är prestandamässigt optimerad.
Tabell 5. Uppnådda krav från kravspecifikationen.
Krav nr Kravbeskrivning Uppfyllt
1 Gränssnitten mellan delsystemen är kompatibel. Ja
2 Återskapa tröghetsnavigatorns funktioner på simuleringsmodellen Delvis
3 Prestandamässigt tillräcklig hårdvara och mjukvara hos simuleringsmodellen för
att återskapa tröghetsnavigatorn. Delvis
4 Enkel övergriplig användardokumentation över produktens funktion. Nej
4.1. Hårdvara
Kretsschemat för RS-422 till USART adaptern kan ses i figur 7. Termineringsmotståndet på 120 Ω placeras endast på mottagande sida och för utgående sida läggs ansvaret på termineringsmotstånd till den parade enheten.
Figur 7. Kretsschema för RS-422 konstruktionen.
Konstruktionen av slutprodukten för simuleringsmodellen kan ses i figur 8.
Figur 8. Slutprodukten av simuleringsmodellen.
13 Kretsschemat för slutprodukten kan ses i figur 9. Alla matningsspänningar förhålls till NUCLEO-kortet. Matningsspänning för CAN-BUS Shield förhåller sig till dess konstruktion och matas via Arduino pinnarna.
Figur 9. Kretsschemat för slutprodukten.
4.2. Mjukvara
Eftersom den ansatta Baud raten för USART är på 115200 Bits/s samt att tidsintervallet för sändning beror på överföringsfrekvensen, så får varje överföringsfrekvens ett maximalt antal sända tecken. En uppställning av maximalt antal sända tecken per period kan ses i tabell 6, och är baserad på att varje tecken består av 10 bitar (en startbit, 8 databitar och en stoppbit).
Tabell 6. Maximalt antal sända tecken i förhållande till överföringsfrekvens.
Överföringsfrekvens Period Baud rate Teckenhastighet Max antal sända tecken/period
1 Hz 1000 ms 115200 bits/s 11520 tecken/s 11520
10 Hz 100 ms 115200 bits/s 11520 tecken/s 1152
20 Hz 50 ms 115200 bits/s 11520 tecken/s 576
40 Hz 25 ms 115200 bits/s 11520 tecken/s 288
100 Hz 10 ms 115200 bits/s 11520 tecken/s 115.2
4.3. Verifiering av prestanda
Verifiering av frekvensen för de fem olika timers har utförts med hjälp av oscilloskop genom mätning av växlande pinne i timer avbrottet. Dessa frekvensverifieringar kan ses i figur 10 – 14.
14
Figur 10. Verifiering av frekvens för TIM1.
Figur 11. Verifiering av frekvens för TIM2.
Figur 12. Verifiering av frekvens för TIM3.
Figur 13. Verifiering av frekvens för TIM4.
Figur 14. Verifiering av frekvens för TIM15.
15 Tidsåtgång för mottagnings- och sammanställningsprocessen av två olika
meddelandetyper. Ett receivemeddelande kan ses i figur 15 och en transmit request i figur 16. Denna mätning är utförd med oscilloskop tillsammans med en växlande pinne i början och i slutet av processen.
Figur 15. Tidsåtgång mottagnings- och sammanställningsprocessen av ett receivemeddelande.
Figur 16. Tidsåtgång mottagnings- och sammanställningsprocessen av en transmit request.
Tidsåtgång för CAN inhämtningsprocessen kan ses i figur 17. Denna mätning är utförd med oscilloskop tillsammans med en växlande pinne i början och i slutet av processen.
Figur 17. Tidsåtgång för CAN inhämtningsprocessen.
Tidsåtgång för sändningsprocessen vid körning i testbänk, kopplat till fordonssystemet, kan ses i figur 18 och 19. Det är tre meddelanden som sänds periodiskt, två med 10Hz överföringsfrekvens och ett med 40Hz överföringsfrekvens. I figur 18 kan tidsåtgången för sändning av 40Hz meddelandet (Transmit) ses, vilket tar ca 6.5ms.
16
Figur 18. Tidsåtgång för 40Hz meddelandet vid körning i testbänk.
I figur 19 kan tidsåtgången för sändning av alla meddelanden (de två 10Hz meddelanden och ett 40Hz meddelandet) ses.
Figur 19. Tidsåtgång för alla meddelanden vid körning i testbänk.
Denna sändning tar ca 15.4ms och detta innebär att det tar för lång tid ifall något av dessa meddelanden skulle skickas med 100Hz överföringsfrekvens. Detta syns även på den gröna signalen (100Hz) då den fortfarande är i avbrottsrutinen när den vill skicka på nytt, alltså den är något utdragen. Detta påverkar inte funktionen för dessa meddelanden då överföringstiden ej överstiger en period av den turkosa signalen (40Hz), alltså det meddelande med högst överföringsfrekvens.
17
5. Diskussion
5.1. Metod
Metoden som använts för att förstå tröghetsnavigatorn samt ta fram resultatet har fungerat väldigt bra. Analysen av kommunikationen tillsammans med användarmanualen till tröghetsnavigatorn har givit tillräckligt med information för att möjliggöra framställningen av denna simuleringsmodell. Hårdvaruanpassningarna av gränssnitten har enkelt
framställts och fungerat felfritt. Genom successiv implementation av tröghetsnavigatorns funktioner har simuleringsmodellen börjat ta form, vilket även varit tillräckligt för att möjliggöra tester i testbänk.
5.2. Resultat
Det funktionella och prestandamässiga resultatet av denna produkt uppfyller delvis de satta kraven. Genom att implementera navigatorns samtliga funktioner och optimera mjukvaran är det möjligt att uppfylla även resterande krav. Lösningen är än så länge begränsad men tillräckligt komplett för att nyttjas i en testbänk.
Hårdvarumässigt har produkten tillräcklig prestanda och de nödvändiga funktionerna för att utföra sin uppgift. Processorhastigheten är tillräcklig för att hantera all information och kommunicera med övriga system som krävs för att återskapa simuleringsmodellen.
Ett fullskaligt test där CANoe tillsammans med mikrokontroller kommunicerar med fordonssystemet har ej utförts. Därför kan inte simuleringsmodellens fullständiga funktion bekräftas. Däremot har tester där mikrokontroller och CanKing kommunicerar med
fordonssystem utförts, vilket fungerat utan problem. Eftersom skillnaden i själva
kommunikationen mellan CanKing och CANoe är väldigt liten, så antas det fungera även med CANoe.
Som komplement till denna rapport kommer en fullständig användarmanual att tas fram för internt bruk hos BAE Systems Hägglunds.
5.3. Sändnings- och timerprocess
Det är viktigt att informationen som ska skickas periodiskt faktiskt skickas med den periodicitet som angetts. Detta kan vara krävande ifall det är flera stora meddelanden med höga överföringsfrekvenser. Lösningen för denna sändnings- och timerprocess fungerar för det faktiska fallet som körs i testbänk. Däremot kan den få konsekvenser vid högre överföringsfrekvenser och stora meddelanden. I figur 19 så syns det att sändning av alla meddelanden tar för lång tid för att skickas under en 10ms period (gröna). Eftersom denna process är utformad så att alla meddelanden som är redo skickas under TIM15
avbrottsrutinen (100Hz) samt att det är pollad överföring, så skapas en viss problematik.
Ifall en sändning tar längre tid än angiven periodicitet så kommer meddelanden falla bort och därmed ej uppfylla den angivna överföringsfrekvensen. Det finns några
förbättringsförslag till denna process som bör implementeras för att optimera den.
En förbättring hade varit att byta till överföring med hjälp av DMA istället för pollat.
Detta skulle medföra att själva sändningen över USART ej behöver vänta på att all data skickats och därmed ej låsa själva avbrottsrutinen. Detta tillsammans med att ändra NVIC prioriteterna för de olika timer avbrotten, högst överföringsfrekvens får högst prioritet och lägst överföringsfrekvens får lägst prioritet. Ett försök att implementera dessa ändringar misslyckades, vilket är anledningen till valet av pollad överföring.
En annan förbättring hade varit att fördela ut sändningen av meddelanden med viss periodicitet till respektive timer avbrottsrutin. Detta tillsammans med ändringar i NVIC
18 prioriteter skulle innebära att sändningstiderna blir kortare och mer utspridda istället för längre sändningstider och allt sänds i ett stycke.
För att undvika onödiga avbrott kan timeravbrott som ej skickar något meddelande stängas av, vilket avlastar processorn samt gör att pågående avbrott ej påverkas av avbrott som ej har någon funktion.
Att öka Baud raten för USART skulle medföra kortare överföringstider, vilket även skulle innebära att fler tecken kan skickas under en period. För att detta skall fungera måste även Baud raten i fordonssystemet matchas.
5.4. Receivemeddelanden
Tanken med receivemeddelandena är att de skall möjliggöra ändringar i inställningar samt begära specifik information från tröghetsnavigatorn. Detta innebär att det finns många fall som måste hanteras. För närvarande besvaras ett receivemeddelande med ett receive response, men utgör ingen funktion.
5.5. Felhantering
I tröghetsnavigatorn hanteras flera olika fel som kan inträffa och vissa av dessa skall anges i Status blocket. I simuleringsmodellen har viss felhantering implementerats, men ej alla.
För nuvarande anges inga av dessa fel i Status blocket samt att inga felmeddelanden skickas till fordonssystemet. Ifall ett fel inträffar kommer simuleringsmodellen inte skicka något meddelande och fordonssystemet vet ej ifall det blivit fel. Detta är något som bör implementeras för att göra systemet mer robust.
19
6. Slutsats
Denna mikrokontroller är prestandamässigt tillräcklig för att återskapa
simuleringsmodellen av den specifika tröghetsnavigatorn. Realtidskontrollen som erbjuds med hjälp av mikrokontroller är tillräcklig för att möjliggöra kommunikation mellan fordonssystemet och simuleringsmodellen.
Mjukvaran är tillräcklig för enkla tester i testbänk, men återger inte en komplett
simuleringsmodell av den specifika tröghetsnavigatorn. Hantering av receivemeddelanden samt optimering av sändningsprocessen är två viktiga delar för att öka prestandan och utöka funktionen hos simuleringsmodellen. Dessa två delar bör prioriteras vid fortsatt arbete med produkten.
20
7. Referenser
[1] S. Johansson, “Simulation Driven Product Development : How it can be combined with Lean Philosophy to achieve increased product development efficiency,” KTH, Dissertation, 2012.
[2] A. King, “Inertial Navigation – Forty Years of Evolution,” GEC review, vol. 13, no.
3, p. 140 – 149, 1998.
[3] ITU-T, “Electrical characteristics for balanced double-current interchange circuits operating at data signalling rates up to 10 Mbit/s,” 10 1996. [Online]. Available:
http://handle.itu.int/11.1002/1000/3925. [Accessed 11 May 2021].
[4] Analog Devices, “Controller Area Network (CAN) Implementation Guide,” Dr.
Conal Watterson, Application Note AN-1123 Rev. A.
[5] CAN in Automation, “History of CAN technology,” [Online]. Available:
https://www.can-cia.org/can-knowledge/can/can-history/. [Accessed 11 May 2021].
[6] STMicroelectronics, “Ultra-low-power Arm® Cortex®-M4 32-bit MCU+FPU,”
Datasheet DS10198 Rev 8, June 2019.
[7] STMicroelectronics, “STM32 Nucleo-64 boards (MB1136),” User Manual UM1724 Rev 14, August 2020.
[8] STMicroelectronics, “STM32L47xxx, STM32L48xxx, STM32L49xxx and
STM32L4Axxx advanced Arm®-based 32-bit MCUs,” Reference Manual RM0351 Rev 7, April 2020.
[9] STMicroelectronics, “STM32CubeIDE,” [Online]. Available:
https://www.st.com/content/st_com/en/products/development-tools/software- development-tools/stm32-software-development-tools/stm32-
ides/stm32cubeide.html. [Accessed 11 May 2021].
[10] Docklight, [Online]. Available: https://docklight.de/. [Accessed 11 May 2021].
[11] Kvaser, “CanKing,” [Online]. Available: https://www.kvaser.com/canking/.
[Accessed 11 May 2021].
[12] Vector, “CANoe,” [Online]. Available:
https://www.vector.com/int/en/products/products-a-z/software/canoe/. [Accessed 11 May 2021].
[13] Maximintegrated, “Low-Power, Slew-Rate-Limited RS-485/RS-422 Transceivers,”
Datasheet Rev 10, September 2014.
[14] Sparkfun, “CAN-BUS Shield, DEV-13262,” [Online]. Available:
https://www.sparkfun.com/products/13262. [Accessed 11 May 2021].
[15] Electronicsforu, “Microcontroller vs Microprocessor,” [Online]. Available:
https://www.electronicsforu.com/technology-trends/learn-electronics/difference- between-microprocessor-and-microcontroller. [Accessed 11 May 2021].
[16] VScom, “VScom USB-COM-I,” [Online]. Available:
https://www.vscom.de/download/multiio/winXP/info/RS-422+485_setting.pdf.
[Accessed 11 May 2021].
21 [17] Kvaser, “USBcan II HS/HS,” [Online]. Available:
https://www.kvaser.com/product/kvaser-usbcan-ii-hshs/. [Accessed 11 May 2021].
[18] STMicroelectronics, “Description of STM32L4/L4+ HAL and low-layer drivers,”
User Manual UM1884 Rev 8, February 2020.
