Examensarbete 20 poäng D-nivå UTVECKLING AV KOMMUNIKATIONSMODUL FÖR INLOGGNING I TIDSKRITISKA SYSTEM Reg.kod: Oru-Te-EXA037-Mag106/05 Adis Redzovic och Elmin Dindic Magisterprogrammet/-elektronik 160 p Örebro vårterminen 2005 Examinator: Dag Stranneby DEVELOPMENT OF COMMUNICATION MODULE FOR LOGIN IN TIME CRITICAL SYSTEMS Örebro universitet Örebro University Institutionen för teknik Department of technology 701 82 Örebro SE-701 82 Örebro, Sweden
Sammanfattning Stoneridge Electronics tillverkar instrumentpaneler till lastbilar. Då man testar sina produkter, som bygger på en typ av seriell kommunikation som heter K-lina, har man problem att logga in i dom. Inloggning innehåller en sekvens höga och låga pulser som skapas av en maskinvarulösning varefter datorn tar över och kommunicerar med produkten. Problemet är att maskinvarulösningen inte genererar tillräckligt exakta pulser och att samarbetet mellan maskinvarulösningen och datorn inte är tillräckligt bra beroende på operativsystem och belastning. Vår lösning ersätter maskinvarulösningen med en processor som styr inloggningen genom direktiv den får från datorn. Lösningen klarar alla operativsystem och kan användas till alla produkter. Examensarbetet har resulterat i att inloggningen fungerar enligt krav på säkerhet, stabilitet, kostnad och tid. Summary Stoneridge Electronic manufactures instrument panels for the trucks. When they are testing their products, a type of serial communication named K-line is used, problems emerge at login. Login contains a sequence of high and low pulses that are created by a hardware solution. After the login, the computer takes over and communicates with the product. The problem is that the hardware solution doesn t generate accurate pulses depending on the operating system and the load of work. Our solution compensates the hardware solution with a processor that controls login through directives from the computer. The solution manages all operating system and can be used on all products. The result of the project is a functional login procedure in accordance with the demands regarding safety, stability, cost and time. 2
Förord Vi vill tacka vår handledare Sören Forsmark, Stoneridge Electronics Örebro, för hans hjälp, engagemang och goda råd under arbetets gång trots hans fullbokade schema. Vår handledare Kjell Mårdensjö och examinator Dag Stranneby, på Örebro universitet, ska ha ett tack för all stöd, tips och idéer under examensarbetet. Ett stort tack riktas även till all personal vid Stoneridge Electronics som såg till att vi trivdes på företaget. Vi har blivit vänligt bemötta och alla har välvilligt ställt upp med sin dyrbara tid. Till sist vill vi säga att detta var ett väldigt roligt och intressant uppdrag. Vi har fått tillämpa kunskapen vi har fått dom senaste fyra åren i ett praktiskt arbete och det kommer vi ha stor nytta av i framtida arbeten. Örebro maj 2005 Adis Redzovic Elmin Dindic 3
Innehållsförteckning 1. Inledning... 5 1.1 Bakgrund... 5 1.2 Syfte... 5 2. Företagspresentation... 6 2.1 Stoneridge Electronics... 6 2.2 Historik... 6 3. Kommunikation... 8 3.1 K-lina... 8 3.1.1 Meddelandeformat... 8 3.1.2 Dataformat:... 8 3.1.3 Kommunikation... 8 3.1.4 Wake up pattern (WUP)... 10 3.1.5 Starta kommunikationen... 10 3.1.6 Starta kommunikationen positivt gensvar... 10 3.2 Agilent VEE Pro... 10 4. Befintliga metoder... 11 4.1 Flödesschema... 11 4.2 Krav... 13 5. Vår lösning... 14 5.1 Programflödet... 14 5.2 Programflödet för processorkoden... 17 6. Testteknik... 18 7. Resultat... 20 8. Referenser... 22 8.1 Manualer... 22 8.2 Litteratur... 22 8.3 Internetlänkar... 22 9. Bilagor... 23 Bilaga 1. Befintliga testplattan med switchar.... 24 Bilaga 2. Kretsen på den befintliga testplattan... 24 Bilaga 3. Testenhet från Scania.... 25 Bilaga 4. STK500, spänningsförstärkaren och testenheten... 26 Bilaga 5. Slutresultatet... 27 Bilaga 6. Befintliga maskinvarulösningen innehållande timerkretsen... 28 Bilaga 7. Vår maskinvarulösning innehållande en processor som sköter inloggningen.... 29 4
1. Inledning I rapportens första kapitel förklaras examensarbetets bakgrund och syfte lite närmare. 1.1 Bakgrund Alla seriösa elektroniktillverkare testar sina produkter innan dessa levereras till distributörer och kunder. Testen, vars syfte är att verifiera att produkten fungerar blir ibland svår att utföra på grund av att timingen i PC: ns operativsystem inte är stabil. Problemet kommer sig av att när man använder sig av seriell kommunikation, en K-lina, så måste timingen i de initierande inloggningspulserna vara enligt de specificerade tidsgränserna som finns definierade, annars upprättas inte kommunikationen på ett korrekt sätt. Vid användandet av en normal PC så sköter operativsystemet timingen mellan olika arbetsuppgifter. Då det är denna PC-timing som används för K-lina-kommunikationen så inträffar det ofta att timingen blir felaktig och att kommunikationen inte blir av. Detta gör att proceduren för att upprätta kommunikationen måste upprepas ett ospecificerat antal gånger vilket skapar irritation hos operatörer och kostar företaget pengar i form av ökad testtid. För att komma förbi detta timingproblem så vill företaget att den kommunikationsenhet som tas fram i exjobbet har en separat mikroprocessor/mikrokontroller som sköter denna timing och som är oberoende av operativsystem. Lösningen ska vara generell på så sätt att enheten genom konfiguration kan användas i alla produkter som använder K-lina. Uppgiften sträcker sig från att undersöka vad som krävs av denna kommunikationsenhet till att utveckla och ta fram en industrimässig lösning. Lösningen ska vara flexibel och kunna användas till flera nuvarande samt framtida produkter. 1.2 Syfte Syftet med exjobbet är att Stoneridge Electronics ska få ett kommunikationsgränssnitt som är generellt och flexibelt och som fungerar utan problem i samtliga aktuella produkter. Om tiden räcker till ska ett arbete om den nuvarande och framtida utvecklingen av informationsöverföring inom fordonsindustrin göras. Syftet är också att erbjuda två studenter möjligheten att slutföra sin magisterutbildning och få en inblick i ett elektronikföretags verksamhet. 5
2. Företagspresentation I detta kapitel ges en beskrivning över företagets organisation. Informationen kommer från Stoneridge Electronics årsrapport. 2.1 Stoneridge Electronics Stoneridge Electronics är en ledande leverantör av komponenter till lastbilar, bussar och offroad marknaden. Produkterna sträcker sig allt från telematiska system, förarinformation, färdskrivare elektroniska kontrollmoduler och förarkabin kontaktmoduler. Företaget är väletablerat i Europa och arbetar med kunder från hela världen. 2.2 Historik Stoneridge Electronics (figur 2.1) startade i samband att Berifors AB grundades år 1988. Volvo lastbilar var huvudkunden. Organisationen bestod av en liten teknikavdelning samt försäljningskontor i Kista och en tillverkningsfabrik i Örebro. Omsättningen låg på cirka 10 miljoner SEK. Berifors hade begränsad kunskap beträffande exportmarknaden och inte tillräckligt med teknisk expertis för att tillverka mera komplexa elektroniska moduler således formerades en strategisk allians med Japanska Kansei. Stoneridge bryter sig loss från Berifors 1992 då företaget börjar tillverka instrument till Mercedes-Benz tunga lastbilar. Detta var den första elektroniska, CAN-baserade, instrumentutvecklingen i Europa och första gången Mercedes anlitar en icke Tysk leverantör för en teknikprodukt. Detta projekt öppnade vägen för tillväxt i lastbilsindustri i övriga Europa. Omsättningen låg då på cirka 500 miljoner SEK. Figur 2.1 Stoneridge Electronics 6
Figur 2.2 Stoneridge Electronics spridning i Europa Lastbilsindustrin minskade med 20 %, SEK/USD valutan gick från 7,50 till 11 samt en stor miss i tillverkningen gjorde så att företaget tappade mycket av sitt goda rykte hos kunderna och alla faktorer ihop gjorde så att företaget hade en väldigt tuff tid fram till 2001. Stoneridge Electronics AB (figur 2.2) består nu av produktutveckling och försäljning i Bromma och två tillverkningsfabriker i Örebro och Tallinn Estland. På figuren ovan ser man företagsspridningen över Europa. Dom största kunderna är Volvo, Scania, Man och Daimler Chrysler. 7
3. Kommunikation 3.1 K-lina K-lina är en kommunikationsbuss som förbinder ett instrument till en eller flera testenheter. Instrumenten är normalt master på K-linabussen där man har möjligheten att ansluta upp till åtta testenheter. K-lina Manager (KLMAN) är programvaran som ansvarar för K-lina bussen inne i instrumenten. 3.1.1 Meddelandeformat Ett meddelande ska bestå av Header, Data och Checksum, se tabell 3.1 och 3.2. 3.1.2 Dataformat: 10400 bit per sekund överföringshastighet 1 startbit, låg 8 databits, LSB först Ingen paritet 1 stoppbit, hög Header Data Checksum Fmt TA SA SI Data CS Tabell 3.1 Meddelandeformat Fält Längd Beskrivning (bytes) Fmt 1 Format on byte TA 1 Target adress (adressen dit den ska) SA 1 Source address (adressen till källan) SI 1 Service Identification Data 1-63 Data (information) CS 1 Checksum (checksumma) Tabell 3.2 Beskrivning av meddelandeformat 3.1.3 Kommunikation För att starta kommunikation med en slav måste mastern ta initiativet till att sända data. Därefter kan mastern begära ytterligare kommunikationsutbyte med slav. 8
Efter att master har tagit emot begärd information måste dataöverföringen stängas. Dataöverföringen mellan en master och en slav ser ut som följande, se figur 3.3 Kommunikation initierad Wake up pattern (WUP) från master till slav Starta kommunikation begärd från master till slav Positivt gensvar från slav till master Utbyte av information Information begärd från master till slav Information svar från slav till master Information begärd från master till slav Stänga av kommunikationen Stoppa kommunikation begärd från master till slav Stoppa kommunikation positivt svar från slav till master Master WUP Start communication request Slave Start communication positive response Application request Application response Application request Application response Stop communication request Stop communication positive response Time Figur 3.3 Exempel på kommunikationssektion 9
After initialisation Initialisation >60 ms WUP 50 ms <355 ms Request answer Service request 25 ms Start communication response Start communication request Figur 3.4 Regler för korrekt inloggningsprocedur 3.1.4 Wake up pattern (WUP) Innan en master kan skicka WUP så måste K-linan gå på tomgång i 5 ms, se figur 3.4. För att utfärda wake up pattern måste master sätta K-linan låg i 25 ms och sedan hög i 25 ms. 3.1.5 Starta kommunikationen Efter att wake up pattern (WUP) är skickad så ska master anhålla om att starta kommunikationen med en slav. 3.1.6 Starta kommunikationen positivt gensvar Efter att ha tagit emot begäran skall slav svara inom 355 ms. 3.2 Agilent VEE Pro Agilent VEE Pro är en kraftfull, produktivt och lätt använd grafisk programmeringsmiljö designad för att spara tid vid utveckling av testprogram. För att skapa ett program så väljer man grafiska objekt från menyn och kopplar samman dom med trådar. Den kommunicerar med mätinstrumenten genom GPIB, LAN, USB, RS232, VXI och andra vanliga protokoll. 10
4. Befintliga metoder I detta kapitel ges en beskrivning om hur den nuvarande program- och maskinvarulösningen ser ut. Detta kapitel ligger som grund för arbetet och beskriver utgångsläget. Här beskrivs problemen och kraven företaget ställer. 4.1 Flödesschema DTR och DSR är två signaler som finns i datorns seriella port och dom användes i befintliga lösningen för att skapa WUP-signalen. Då man startar login så triggas DTR Låg, se figur 4.1. Triggsignalen går till timerkretsen vars pulstid bestäms av RC-nätet, se figur 4.2. Det är här man får den första begränsningen. RC-nätet består av två maskinvarukomponenter vilket innebär att man måste ha en unik lösning varje gång man vill ändra WUP-tiden det vill säga till varje ny produkt. DTR Hög signalen går hög och återställer DTR till nästa inloggning. DSR signalen går hög då WUP är skapad och triggar Break. Starta login 4 Fail Exit User Object DTR Låg DTR Hög DSR Låg Break Fail Operativsystem Parametrar OK Exit User Object Figur 4.1 Flödesschema på befintliga lösningen 11
Nästa steg är ett försök att förbättra inloggningen genom att man har laborerat sig fram till olika tidsfördröjningar som uppstår i olika operativsystem. Detta är ytterligare en begränsning för systemet då alla datorer där man testar sina produkter måste ha samma operativsystem eller så måste man programmera om VEE-koden. Den första parametern skickas. Svar tas emot men bearbetas ej. Om inget svar kommer så får man en sekunds fördröjning på grund av timeout. Andra parametern skickas. Om inget svar kommer så får man ytterligare en sekunds fördröjning och ett nytt inloggningsförsök startar. Detta innebär att för varje loop så får man två sekunders fördröjning. Snittet ligger på tre försök per lyckad inloggning. Efter fyra misslyckade försök så avbryter programmet inloggningen. Om svar fås så jämförs det med förprogrammerade. Om det är korrekt så hoppar man ut ur programmet genom Exit User Object. Figur 4.2 visar maskinvarulösningen, se även bilaga 1. Första kopplingen består av två delar. Den första delen är kopplingen mellan PC och kretsen i figuren 4.2. I den andra delen ändrar man spänningsnivån från 5V till den spänningen som matas in på POW28. Max232CPE kopplas ihop med PC:n, k-lina är in och utgången till testenheten och POW28 är matningsspänningen. WUP Figur 4.2 Kretsschema på befintliga lösningen med spänningsförstärkaren 12
TRIGGER TRIGGER WUP Figur 4.3 Kretsschema på befintliga lösningen med timerkretsen Figur 4.3 visar kretsen där WUP-signalen skapas. Triggern reagerar på låg flank i DTR. Timerkretsen skapar pulsen med förbestämd tid med hjälp av RC-nätet, komponenterna R113, R112 och C107. Fyrdubbla optokopplaren används för att galvaniskt skilja signalerna. 4.2 Krav Examensarbetet består av två delar. Den första delen är obligatorisk medan den andra skulle göras i mån av tid. Första delen var att ta fram ett förslag på lämpligt kommunikationsgränssnitt som löser problemen med timingen. Detta inkluderade maskinvara, programvara och dokumentation. Resultatet som fås fram ska vara generellt så att enheten genom konfiguration kan användas i alla produkter som använder K-lina och klarar av att ge en flexibel kommunikation utan störningar. Man ska kunna utföra följande utan att behöva programmera om enheten Hantera baudrate, default 10400 Ställa in pulslängden med 1 ms upplösning WUP Ändra loginmeddelandet 13
5. Vår lösning I detta kapitel beskrivs maskin-och programvaran vi använde för att lösa timingproblemet. 5.1 Programflödet Då man startar VEE-programmet (se figur 5.1) så laddas konfigurationer till processorn. Det är wuptiden, antal tecken i första inloggningsmeddelandet, baudrate och första meddelandet som sparas i processorn. Detta görs endast då strömmen slås på. KWP2000 är ett internt bibliotek som används på Stoneridge Electronics och DEADBABE är internt vanligt förekommande namn på startkoder. Konfigurationerna ska vara WRITE TEXT och kan skrivas i string, byte eller hex-format. Informationen ska skrivas inom citattecken och skiljas åt med ett kommatecken. Konfigurationen skrivs wuptiden, antal byte i första inloggningsmeddelandet, baudrate. Figur 5.1 Inställningar på konfigurationer i programmet VEE 14
Därefter skickas DEADBABE (se figur 5.2). Detta meddelar processorn att skapa WUPsignalen samt skicka första och det andra inloggningsmeddelandet. DEADBABE skickas på samma sätt som meddelandet ovan men endast i byte-, string- och hexformat. De två senare fungerar endast då de skickas utan EOF (End Of Line). Om meddelandet och svar från testenheten är korrekta så lämnas inloggningsfunktionen. Annars stoppas kommunikationen och processorn väntar på ny DEADBABE. Start Endast då programmet startas Öppna biblioteket KWP2000 Ladda ner wuptid, antal tecken i första meddelandet och baudrate Ladda ner första meddelandet Starta DEADBABE Väntar på ny test Första och andra meddelandet skickas OK Exit User Object Fail Stop Communication Figur 5.2 Flödesschema för lösningen med mikrostyrenhet 15
P re te s t T e s ts e k v e n s P o s tte s t Figur 5.3 Flödesschema för slutgiltliga programmet Nedladdning av konfigurationer kommer att skötas automatiskt då vår lösning kommer i bruk. Konfigurationerna kommer att finnas i Pretest som laddar ner dem då programmet startar. Därefter kommer man in i testsekvensen där alla tester utförs. Då testerna är klara hamnar man i Posttest där man slår av matningsspänningen och tar ut testenheten (se figur 5.3). Figur 5.4 visar den nya maskinvarulösningen. Här används inte DTR utan processorn sköter WUP-tiden samt första meddelandet. Därefter släpper den igenom all information. Kretsen består av själva kopplingen till PC, processorn och spänningsnivåomvandlare. Figur 5.4 Kretsschema inehållande mikrostyrenhet 16
5.2 Programflödet för processorkoden I detta kapitel beskrivs programflödet för processorkoden. Figur 5.5 beskriver programflödet. Initiering av en digitalutgång, baudrate, pinne D1, USART samt inläsning och bearbetning av strängen t sker bara då programmet startas. Om man ska ändra på wuptiden och baudrate till en annan testenhet som inte har samma parametrar måste strömmen slås av och på. Man får då ladda in den önskade wuptiden och baudraten, se figur 5.5. Initiering utav en digital utgång och en delayobjekt Programmet väntar nu på att få medelandet "DEADBABE" för att sedan skapa wupen Stänga av USART-en för att kunna använda pinne D1 som en digital utgång Baudrate sätts till 10400 bit/s default Initiering av pinne D1 till en digital utgång på processorn Initierar USART-en med den bithastighet som finns sparad i variabeln wu[1] Signalen går låg och förblir det i det antal millisekunder som delayobjektet wuptid är initierad till Initiering utav USART för att erhålla den seriella kommunikationen Initierar värdet som variabeln wu[0] innehåller till delayobjektet wuptid Signalen går hög och förblir det i det antal millisekunder som delayobjektet wuptid är initierad till Läser strängen "t", wuptiden, antal bytes och baudrate Beräknar antal tecken i strängen "t" Väntar på att få det antal tecken som wu[2] variabeln visar att det ska komma i det första loginmedelandet och sparar dom i strängen init USART-en initieras igen och första logindatat som finns lagrat i strängen init skickas till testenheten Bearbetar strängen t, gör om strängen till tal och lägger in wuptiden, antal bytes och baudrate på rätt plats i vektorn wu Multiplicerar data i wu[0] (som är wuptiden) med 1000 för att få den i millisekunder Loopen körs så länge man inte får Stop communication medelandet från VEE Figur 5.5 Programflödet 17
Den digitala utgången D1 är en fysisk utgång på processorn och t är strängen som skickas från datorn innehållande wuptiden, antal bytes och baudrate. Funktionen i processorn arbetar i mikrosekunder och för att heltalsvariabeln wu[0] skall fås i millisekunder så måste den multipliceras med 1000. Variabeln wu[0] ska vi ha i millisekunder då wuptiden anges i millisekunder. Programmet avslutas då man får meddelandet Stop communication från programmet VEE. 6. Testteknik I detta kapitel beskrivs hur vi testade vår lösning. För att vara säkra på vår lösning så utfördes tre olika tester. 1 Logga in i enheten och begära serienummer och artikelnummer 2 1000 inloggningar i enheten 3 Logga in manuellt och begära serienummer och artikelnummer varefter man loggar ur Test ett och två är långtidstest av att kommunikationen genom processorn är stabil, se bilaga 2. Test ett går ut på upprepade inloggningar i enheten och begär serienummer. Om svaret är korrekt så ska artikelnummer begäras. Testen utfördes i programmet VEE och i figurerna ovan visar resultatet av ett lyckat och ett misslyckat inloggningsförsök. Figur 6.1 visar att vi frågar efter artikelnummer och serienummer 150 gånger som sedan skrivs ut. 150 står för antal begärda serienummer, 020530 för serienummer och 1498713 för artikelnummer. Det är olika serie- och artikelnummer för varje enhet, se bilaga 3. På detta sett ser man omedelbart om programmet fungerar och om svaret från testenheten är korrekt. Figur 6.2 visar en misslyckad inloggning. Vi loggar in en gång och får svaret -1 på serie och artikelnumret vilket står för inkorrekt inloggning. Test två går ut på att skapa en loop där programmet loggar in, kontrollerar om det är korrekt inloggning och loggar ut ur enheten. Denna test visar stabiliteten i inloggningssekvensen. Test tre testar samma sak som test ett. Skillnaden är att inloggningen och begäran om serieoch artikelnumret sköts manuellt. 18
Figur 6.1 Testutförandet med korrekt svar i VEE Figur 6.2 Testutförandet med fel svar i VEE Figur 6.3 visar hur en korrekt inloggning ser ut för den befintliga samt den nya lösningen innehållande en mikrostyrenhet. Man skickar först wuptiden som ligger på 25 ms för denna produkt. Sedan skickas första inloggningsparametern och svar tas emot. Därefter skickas den andra inloggningsparametern och svar tas emot. Efter detta kan man fritt kommunicera med testenheten. Figur 6.3 Befintliga och nya hela korrekta inloggningar 19
Figur 6.4 Misslyckat inloggningsförsök utan svar Om ingen information skickas under 5 sekunder så behöver man skicka meddelandet Stop communication till processorn och ny inloggning krävs om man vill fortsätta informationsutbytet. Figur 6.4 visar en misslyckad inloggning eftersom wuptiden är ändrad till 18 ms. Man ser parametrarna som skickas men inget svar fås tillbaka. 7. Resultat I detta kapitel beskrivs vårt resultat. Det framgår hur mycket tid respektive kostnader företaget sparar. Målet för företaget är att man ska ha Yield som ligger över 95 %. Som det ser ut nu så tappar man 1 % bara på inloggningen, då ett misslyckande där registreras som ett fel och varje fel kostar företaget pengar och tid. Enheten som vi testade tillhör en produkt som tillverkas i låg produktion just nu. Denna produkt tillverkas nu endast till reservdelar, se bilaga 4. Bilaga 5 visar slutresultaten, våran lösning på timingspproblemet. Mellan 15: e februari 4 maj, 2005 tillverkades 892 enheter. Av dessa 892 enheter så fanns det 7 loginfel. 885 892-7 = 885 Yield = = 99% 892 Vår lösning garanterar 100 % rätt inloggning. Varje loginförsök innebär ytterligare 2 sekunders fördröjning. I snitt krävs det 3 till 4 försök innan man loggar in i produkten. Tidsvinsten är 8 sekunder/enhet eftersom vi alltid loggar in på första försöket. 20
Som det ser ut nu så har företaget 50 olika produkter och strax över 800 000 enheter men vi vet inte hur många av dem som använder K-lina. K-lina finns i alla produkter men man har valt att inte använda sig av den på grund av timingproblemet. Man måste dock fortfarande använda sig utav K-lina i äldre produkter som tillverkas som reservdelar. Om vi räknar på att 10% av enheterna använder K-lina, det vill säga 80 000 enheter, skulle det innebära följande: Detta innebär att på ett år tjänar man in 80 000 8 = 640 000 sekunder = 178 timmar. Detta innebär att man kan testa 7100 fler enheter/år eftersom det tar ca en 90 sekunder att testa en enhet. 80000 8 Ö7100 90 Testtiderna varierar mellan 30 sekunder för en enkel enhet till 7 minuter för dom äldre produkterna. Snittiden ligger på 1,5 minuter det vill säga 90 sekunder. Företaget tjänar inte stora summor pengar på dessa reservdelar men dom är väldigt viktiga för att hålla kunden nöjd. 21
8. Referenser 8.1 Manualer Atmega 16 Atmel Corporation 2003 Atmel Instruction Set Atmel Corporation 2001 avr-libc Reference Manual Generated by Doxygen 1.2.18 2003 Efficient C Coding for AVR Atmel Corporation 2003 GCC-AVR Inline Assembler Cookbook Version 1.6 2001 Software GmbH Inbyggda system och Objektorienterad Modellering 2004 Kjell Mårdensjö INBYGGDA SYSTEM MED AVR RISC PROCESSORER 2003 Kjell Mårdensjö STK500 User Guide Atmel Corporation 2000 Stoneridge Electronics STRATEGIC BUSINESS PLAN 2005-2009 KLMAN FUNCTION BLOCK SPECIFICATION Stoneridge Electronics K-LINE Communication Stoneridge Electronics KWP2000 SERVICES Stoneridge Electronics 8.2 Litteratur VEE Pro, Advanced Programming Techniques Edition 1, 2000 8.3 Internetlänkar http://www.edtnscandinavia.com/tek/showarticle.jhtml?articleid=22101238 http://www.elfa.se 22
9. Bilagor 23
Bilaga 1. Befintliga testplattan med switchar som används för att logga in och testa enheterna. Bilaga 2. Kretsen på den befintliga testplattan. 24
Bilaga 3. Testenhet från Scania. Kommunikationen mellan enheten och testutrustningen går genom K-linan. Matningsspänningen ligger på 28V. 25
Bilaga 4. STK500, spänningsförstärkaren och testenheten. Visar lite hur vi arbetade, hur kopplingen såg ut under arbetsgången. 26
Bilaga 5. Slutresultatet. Vår lösning på timingproblemet. Ingångarna är RS232, VCC på 5V, jord, 28V matningsspänning och K-lina. 27
Bilaga 6. Befintliga maskinvarulösningen innehållande timerkretsen. 28
Bilaga 7. Vår maskinvarulösning innehållande en processor som sköter inloggningen. 29