SE512140C2 - Diagnossystem och diagnosfunktionsmodul i ett motorstyr system - Google Patents

Description

15 20 25 30 5,12 140 2 tiska kontroller skall utföras. Det finns sålunda standardiserade körcykler un- der vilka samtliga diagnostiska kontroller måste klaras av. Lagstiftningen fö- reskriver även att om vissa fel skulle detekteras under två pà varandra föl- jande körcykler, skall sådana fel permanent upptecknas i ett minnen för att senare vara tillgängliga i verkstaden.

Exempel pà motorstyrsystem inkluderar en motorstyrmodul, ett avgas- recirkulationssystem, ett system för att processa förångat bränsle, ett se- kundärt luftsystem och ett övervakningssystem för katalytisk omvandlare.

Ytterligare komponenter som kan erfordra övervakning inkluderar en tempe- ratursensor för motorkylmedium, en sensor för luftmassflödesmätare, en motorhastighetssensor, etc. Även om funktionen för vissa av komponenterna kan kontrolleras tillsynes oberoende av motorns driftsförhàllanden, kan vissa komponenter och system enbart kontrolleras när vissa driftsparametrar före- ligger, exempelvis motorbelastning, temperatur, motorhastighet, etc.

Sålunda har diagnossystem utvecklats där vissa diagnostiska kontroller prio- riteras i förhållande till andra. I exempelvis US-A-5 331 560 beskrivs ett prio- ritetssystem där vissa diagnostiska kontroller kan avbrytas om driftsförhàl- landena dikterar att en diagnostisk kontroll kan utföras på ett motorstyrsy- stem där de erforderliga driftsparametrarna enbart uppkommer sällan. Så snart den existerande diagnostiska kontrollen har avbrutits, kan den priorite- rade kontrollen därefter utföras.

Beroende pà det inbördes sambandet mellan många komponenter och sub- system som utgör motorns styrsystem, och om driftsförhàllandena är sådana att en diagnostisk kontroll kan utföras på en komponent eller subsystem, är det nödvändigt att avbryta diagnostiska kontroller pà andra komponenter eller subsystem som annars kan komma att påverka giltigheten för resultatet av den diagnostiska kontrollen. l konventionella diagnostiska system betyder detta, att om en komponent eller subsystem tillförs eller elimineras måste det diagnostiska systemet omprogrammeras för tillförsäkrande av att det är med- 10 15 20 25 30 5,12 140 3 vetet om inverkan av den nya/eliminerade komponenten eller subsystemet på resten av motorstyrsystemet. Samma problem uppkommer naturligtvis om det är önskvärt att implementera samma diagnossystem i en annan fordons- modell.

Ovan nämnda inbördes samband mellan olika komponent och subsystem medför dessutom att om fel skulle detekteras i en komponent kan inverkan av detta fel återges under diagnostiska kontroller utförda på ett antal kompo- nenter eller subsystem. Det är sålunda önskvärt att arrangemang finns till- gängligt för att noggrant bestämma där roten till ett fel ligger och att inga fals- ka felsignaler upptecknas.

Detta inbördes samband betyder även att det kan finnas motorstyrfunktioner (EC), vars exekvering skulle kunna interferera med exekveringen av en eller flera diagnostiska funktioner. Av detta skäl är det önskvärt att det diagnostis- ka systemet kan förhindra den simultana exekveringen av diagnostiska funk- tioner och motorstyrfunktioner som interfererar med varandra.

För att assistera verkstaden eller tillverkaren med att fastlägga varför ett visst fel har uppkommit skulle det vara användbart att kunna erhålla information hänförande sig till de faktiska driftsförhàllandena för fordonet fràn tidpunkten då felet uppkom fram till tidpunkten då felet detekterades. Denna möjlighet har ej funnits fram till nu.

SAMMANFATTNING AV UPPFINNINGEN Det är sålunda ett syfte med uppfinningen att tillhandahålla ett diagnossy- stem som snabbt identifierar fel, speciellt i komponenter eller subsystem re- laterade till avgasemission, och som enkelt kan anpassas till olika motor- och fordonsmodeller.

Detta syfte uppnås med ett system enligt kravet 1. 10 15 20 25 30 512140 4 Genom att gruppera allt som erfordras för varje komponent eller subsystem i en specifik DF modul för (i) bestämning av den prioritet varmed den evalue- ringsrutin som är associerad med denna DF modul skall exekveras, (ii) ut- förande av en evalueringsrutin för att detektera ett fel, (iii) statistisk lagring av de evaluerade resultaten (iv) filtrering av de evaluerade resultaten för att be- stämma när DTC-data skall skapas och, företrädesvis, (v) i fallet med giltig rapportering bestämning av när DTC-datan skall lagras eller raderas och när MIL skall tändas eller släckas, och genom styrning av exekveringsföljden av evalueringsrutinerna för samtliga DF moduler i diagnossystemet från en enda dynamisk schemaläggare, kan diagnossystemet snabbt anpassas till föränd- ringar av komponenter eller subsystem eftersom varje DF modul kommer att vara oberoende av de övriga.

Ett ytterligare syfte med uppfinningen är att tillhandahålla en DF modul som innehåller tillräckliga medel för att oberoende kunna bestämma huruvida viss data skall lagras.

Detta syfte uppnås med DF modulen enligt kravet 12.

Föredragna utföringsformer av uppfinningen finns detaljerat angivna i de be- roende kraven.

KORTFATTAD BESKRIVNING AV RITNINGARNA .

Uppfinningen kommer nu att beskrivas mera i detalj, enbart i form av exem- pel och med hänvisning till bifogade ritningar, där Fig. 1 är blockschema av ett diagnossystem enligt föreliggande uppfin- ning; Fig. 2 schematiskt visar en diagnostisk felkod genererad i diagnossy- stemet enligt föreliggande uppfinning; 10 15 20 25 30 Fig. 3 Fig. 4 Fig. 5 Fig. 6 Fig. 7 Fig. 8 Fig. 9 Fig. 10 512 140 5 visar en möjlig schemaläggar-tabell för användning i en schema- läggare placerad i diagnossystemet enlig föreliggande uppfinning; visar en möjlig schemaläggar-lista för användning i diagnossyste- met enligt föreliggande uppfinning; visar en möjlig frysramtabell och utvidgad frysramtabell för an- vändning i ett DTC-dataomràde lokaliserat i diagnossystemet en- ligt föreliggande uppfinning; visar ett exempel på ett DTC-block för användning i diagnossy- stemet enligt föreliggande uppfinning; visar schematiskt en roterande buffert för användning i en data- kollektor lokaliserad i diagnossystemet enligt uppfinningen; är ett exempel pà en utvidgad frysram; är en valldator-uppsättningslista och motsvarande validator- checklista, och visar ett flödesdiagram för initiering av en validator-checklista.

DETALJERAD BESKRIVNING AV FÖREDRAGNA UTFÖRINGSFORMER I Fig. 1 anger hänvisningssiffran 10 allmänt ett diagnossystem enligt förelig- gande uppfinning. Systemet inkluderar ett antal diagnosfunktionsmoduler (i det följande benämnda DF moduler) 20, 202 20", där varje DF modul verkar som komponent eller subsystem, och vars driftstatus skall evalueras. Exem- pel på sådana komponenter och subsystem är syresensor i avgasröret, de- tekteringskrets för luftläckage, bränslelnjektorer, recirkulationssystem för av- gaser, temperatursensor för motorkylmedium, sensor för luftmassflöde, tom- gångsstyrventil, absoluttrycksensor för grenrör, motorhastighetssensor, 10 15 20 25 30 512 140 6 bränsletankstängningsventil, etc. På sätt som senare kommer att beskrivas, är varje DF modul, 20, 20', 20" arrangerad för att evaluera dess tillhörande komponent/subsystem och för att generera en diagnostisk felkod (i det föl- benämnd DTC) ten/subsystemet. På sätt som ävenledes kommer att beskrivas senare, är jande som anger driftsfelstatus för komponen- dessutom varje DF modul 20, 202 20" arrangerad för att beräkna den prioritet varmed dess tillhörande komponent/subsystem skall evalueras.

Ett föredraget DTC format, allmänt betecknat med hånvisningssiffran 200, finns visat i Fig. 2 och består av en 16 bit kod uppdelad i tre delar. En första del 201 består företrädesvis av 8 bitar och tjänar till att ange inom vilket mo- torsubsystem, exempelvis tändsystemet, bränsle och luftdoseringssystemet, etc., ett fel föreligger. En andra del 202 består företrädesvis av 4 bitar och tjänar till att ange inom vilken komponent i subsystemet ett fel föreligger. En tredje del 203, även bestående av 4 bitar, används slutligen för att ange den typ av fel som har inverkan på andra komponent/subsystem, exempelvis långsam reaktion hos en 02 sensor, katalysatoromvandlarfel beroende på misständning, lämnad öppen ventil, etc.

Beroende på det faktum att motordiagnossystemet enligt uppfinningen är arrangerat att evaluera driftstatus för ett antal komponenter och subsystem, och att flera av dessa komponent/subsystem enbart kan evalueras när vissa driftsvillkor är uppfyllda, innefattar systemet 10 dessutom en dynamisk schemaläggare 30. Syftet med schemaläggaren är att koordinera exekve- ringen av de olika evalueringsrutiner som skall körs av respektive DF modu- ler, och motorstyrfunktioner (EC) så att det tillförsäkras att så många evalue- ringsrutiner som möjligt kan fullbordas, beroende av existerande driftsvillkor, inom en given tidsrymd, samtidigt som inga två evalueringsrutiner tillåts att äga rum samtidigt om det föreligger risk för att detta kan resultera i att felak- tig DTC genereras. Exempel på två evalueringsrutiner som ej skall utföras samtidigt är en läckagedetekteringskontroll med användning av en bränsle- tanksugventil och övervakning av det katalytiska omvandlingsförhållandet. 10 15 20 25 30 7512 140 l 7 Eftersom många av de diagnostiska funktionerna kommer att medföra exe- kvering av vissa motorfunktioner, är den dynamiska schemaläggaren även försedd med ett interface mot motorns styrfunktioner för att tillåta eller för- hindra exekveringen av motorstyrfunktioner (EC) som skulle interferera med en motorstyrfunktion eller en evalueringsrutin som samtidigt exekveras. Ett exempel på en evalueringsrutin och en motorstyrfunktion som samtidigt ej kan köras är läckagekontrolltestet och tankrengöringsfunktionen: Läckagekontrolltestet utförs för att kontrollera huruvida det finns nâgra läcka- ge i fordonets evaporeringssystem. Detta görs genom att man stänger eva- poreringssystemet, en procedur som inkluderar stängning av samtliga förbin- delser som leder från tanken. Luft utdras därefter från systemet, till det att trycket når en viss förutbestämd nivå. Läckagekontrolltestet övervakar därvid trycket inuti det nu stängda systemet, för att se om trycket förändras, vilket sålunda anger närvaro eller frånvaro av läckage.

Tankrengöringsfunktionen utförs för att göra tanken fri från bränsle som ej kan användas, och som annars skulle avges till atmosfären och medföra oönskade emissioner. Tanken rengörs genom att omgivningsluft införs i mo- torn, genom tanken. Eventuellt i tanken kvarvarande bränsle kommer att för- brukas i motorn, tillsammans med omgivningsluften som användes för att "rena" tanken. Denna motorstyrfunktion kan uppenbarligen ej utföras samti- digt som den ovan beskrivna låckagetestfunktionen.

Det finns uppenbarligen många andra kombinationer av evalueringar och motorstyrfunktioner (EC) som skulle komma att "kollidera" med varandra.

Den dynamiska schemaläggaren 30 kan sålunda sägas ha både funktion ”inhibering pà grund av fel" och en ”kollision-styr” del. 10 15 20 25 30 _512_14o 8 Om ett fel detekteras av en DF modul, tjänar dessutom den dynamiska schemaläggaren till att stoppa evalueringsrutiner som annars skulle påverkas av felet, dvs. dessa stoppade evalueringsrutiner skulle annars "föranleda" att det skulle uppfattas som om att fel ävenledes existerar i deras system, trots att några verkliga fel ej existerar i dessa system. l händelse av att en sådan påverkad DF modul utför sin evalueringsrutin in- nan evalueringsrutinen på den komponent/subsystem som har det verkliga felet har utförts, kommer därvid den berörda DF modulen att generera DTC angivande ett fel i komponentlsubsystemet associerat med denna DF modul.

Det är sålunda nödvändigt att diagnossystemet 10 har tillgång till tillräckligt med information för att kunna veriflera huruvida DTC är giltig eller ej. Syste- met 10 måste med andra ord vara kapabelt att bestämma huruvida det aktu- ella felet ligger i det komponent/subsystem som evalueras av den DF modul som har gett initial DTC, eller huruvida DF modulen har "blivit föranledd" be- roende på ett föreliggande men ännu ej detekterat fel i annan kompo- nent/subsystem.

För att ge systemet 10 information om fordonets driftstillstànd innan tidpunk- ten när DTC genererades, inkluderar systemet dessutom en datakollektor- modul 40. På sätt som senare kommer att beskrivas, är datakollektormoduler arrangerade för att hantera skapandet av frysramar och utvidgade frysramar.

En frysram är ett prov på ett antal parametrar som är specifika för aktuell DTC, exempelvis den aktuella motortemperaturen och motorhastigheten vid tidpunkten när DTC genererades. En utvidgad frysram innehåller ett antal prov på några parametrar specifika för aktuell DTC från tidpunkten när DTC genererades och bakåt i tiden. Baserat på denna information, genererar da- takollektormodulen 40 ett DTC-block innehållande DTC och denna informa- tion.

För att vilka som helst DTC-block genererade av datakollektormodulen 40 skall kunna lagras, är systemet 10 försett med en DTC-data-areamodul 50. 10 15 20 25 30 512 140 9 Pà sätt som senare kommer att beskrivas, kommer när DTC-data- areamodulen 50 mottar en begäran från datakollektormodulen 40 att spara ett DTC-block, modulen 50 att spara blocket och sända ett DTC-sparat svar till datakollektormodulen.

För att bestämma huruvida det sparade DTC-blocket är giltigt eller ej, dvs. om ett fel verkligen existerar eller ej i den komponent/subsystem som kon- trollerats av den DF modul som generade denna DTC, är systemet 10 försett med en validator 60. Validatorn 60 mottar informationen att ett icke-validerat DTC-block sparats fràn DTC-data-areamodulen 50 och, genom att ställa upp en validator-checklista (som skall beskrivas senare), är det möjligt att avgöra huruvida DTC-blocket skall anses vara giltigt eller ej.

Om Validatorn 60 avgör att ett DTC-block är giltigt, innebär detta att en kom- ponent eller system fungerar felaktigt. Beroende på vilken komponent eller system som berörs, kan det vara önskvärt att informera föraren av fordonet om denna felfunktion. Systemet 10 är sålunda försett med en hanteringsmo- dul för felfunktionslampa (i det följande benämnd MIL) som kan informera föraren om felfunktion genom att presentera en felsymbol eller meddelande pà fordonets instrumentbräda.

För att motordiagnossystemet 10 skall kunna kommunicera med externa testanordningar som nyttjas i verkstäder, inkluderar systemet 10 företrädes- vis en hanteringsmodul 80 för extern kommunikation (i det följande benämnd ECH) Slutligen är systemet 10 försett med en styrmodul för diagnostiskt system (i det följande benämnd DSM) som ansvarar för uppstartningen av diagnossy- stemet sà snart fordonets tändning slagits till och för att stoppa systemet när motorstyrsystemet avslutat samtliga övriga operationer efter att tändningen slagits från. Detta àstadkoms genom en samverkan med både diagnossy- stemet och motorstyrsystemet, båda placerade i fordonets motorstyrmodul. 10 15 20 25 30 512 140 10 För att bättre förstå diagnossystemets 10 enligt uppfinningen funktion, kom- mer varje modul eller enhet 20, 30, 40, 50 och 60 att beskrivas mera i detalj i det följande.

DF modulen 20 Såsom tidigare nämnts, betjänar varje DF modul 20, 20', 20" en komponent eller subsystem vars driftstatus skall evalueras. Var och en av DF modulerna 20, 20', 20" är sålunda arrangerad för att evaluera dess associerade kompo- nent/subsystem och för att generera en diagnostisk felkod (DTC) som anger driftstatus för komponenten/systemet. Varje DF modul är för detta syfte ka- pabel att processa all information som erfordras för evalueringen av en fel- fungerande komponent eller subsystem såsom sensor, emissionskomponent, EVAP system, etc. Varje DF modul är dessutom arrangerad för att evaluera den prioritet varmed den assicierade komponentenlsubsystemet skall evalue- TGS.

För detta syfte, och såsom framgår av figur 1, omfattar varje DF modul 20, 20' och 20" ett antal submoduler inkluderande ett DF interface 21, en fysika- lisk diagnos 22 (i det följande benämnd PD), en DF logger 23, en DF styren- het 24 och en DTC hanterare 25.

DF interface 21 är en DF submodul som hanterar överföring av kommunika- tion från och till DF submodulerna till andra moduler i diagnossystemet. Ef- tersom den DTC som har genererats av en viss DF modul är unik för denna modul, används DTC som identifierare av andra moduler i systemet för kommunikation med denna speclfika DF modul. DF interface 21 är sålunda kapabelt att igenkänna samtliga signaler adresserade till en DF modul med den identifierare som är relaterad till den DF modul vari nämnda DF interface finns och tillordnar dessa signaler till den korrekta DF submodulen. Samtliga signaler som har sänts från DF submodulen till den dynamiska schemalägg- 10 15 20 25 30 512 140 11 gren 30, datakollektorn 40, DTC-data-area 50, validatorn 60, MIL hanteraren 70 eller ECH modulen 80 överförs via DF interface 21.

PD 22 är en DF submodul som innehåller en evalueringsrutin för varje DTC som är relaterad till den specifika DF modulen. PD 22 är kapabel att igen- känna när motorns driftstillstànd ärr uppfyllda, vilket möjliggör för DF modu- len 21 att evaluera dess associerade subsystem eller komponent. Varje gång dessa villkor är uppfyllda, informerar PD 22 DF styrenheten 24 att det är möj- ligt att utföra evalueringsrutinen. PD väntar tills att DF styrenheten ger till- stånd innan evalueringsrutinen exekveras.

Om under en evalueringsrutin, motordriftvillkoren ändras sä att villkoren ej längre sammanfaller med de som är nödvändiga för att utföra evalueringsru- tinen, avbryter PD rutinen. På motsvarande sätt, om DF styrenheten 24 återtar tillståndet att exekvera evalueringsrutinen, avbyter PD rutinen.

För att avgöra huruvida ett möjligt fel föreligger, kommer varje gång en eva- lueringsrutin är fullbordad, PD 22 att producera ett rankingvärde som indika- tor på status hos den kontrollerade komponentenlsubsystemet. Varje ran- kingvärde ligger företrädesvis i intervallet fràn 1 till 255, med värdet 128 sva- rande mot en normal komponent eller subsystem, exempelvis det ideala luft- anpassningsvärdet lika men en kalibrerad referens. Värdet 255 svarar mot en komponent eller subsystem som ej arbetar överhuvudtaget, exempelvis tom- gàngsluftanpassningsvärdet pá maximum. Varje komponent/subsystem är tillordnad en hög felgräns och förutsatt att rankingvärdet ligger under den höga gränsen, kommer inget fel att detekteras och en evaluerad ”icke-fel” datasignal genereras. lfall att rankingvärdet skulle överskrida höggränsen, genereras en evaluerad ”fel” datasignal.

Varje gäng evalueringsrutinen är avslutad, sänds den evaluerade datasigna- len till DF styrenheten 24 och rankingvärdet sänds till DF logger 23. 10 15 20 25 30 512 140 '12 DF logger 23 är en DF submodul som mottar rankingvärdena och använder det högsta av ett visst antal av rankingvärden för att statistiskt processas och resultaten lagras för användning som information till verkstaden.

DF styrenhet 24 är en DF submodul som styr PD 22. När PD informerar DF controllern att det är möjligt att köra evalueringsrutinen sänds ett svar till den dynamiska schemaläggaren att evalueringsrutinen är inhiberad, tillsammans med information beträffande prioriteten för denna evalueringsrutin. När/om den dynamiska schemaläggaren 30 sänder ett svar att evalueringsrutinen kan utföras, tillåter DF styrenheten 24 PD att köra rutinen. Om den dynamis- ka schemaläggaren 30 sänder en begäran för inhibering av evalueringsruti- nen tar DF styrenheten tillbaka tillståndet att köra evalueringsrutinen och när evalueringsrutinen har stoppats, sänder den ett "inhiberaF-svar till den dy- namiska schemaläggaren.

DF styrenheten 24 mottar även samtliga evaluerade datasignaler och infor- merar den dynamiska schemaläggaren 30 om eventuell ändring i status hos de evaluerade datasignalerna definierat som den senast evaluerade datasig- nalen. DF styrenheten begär att ett konsekutivt antal av evaluerade ”fel” da- tasignaler genereras innan den producerar en kontrollerad "fel" datasignal.

Det erforderliga antalet konsekutiva signaler som erfordras för att få denna ändring i tillstànd är specifikt för varje DTC som skall genereras. vid tändning ställs den kontrollerade datasignalen på ”ej utfört” och vid den första evalue- rade ”ej fel” datasignalen ställs den kontrollerade datasignalen på "ej fel”.

Så snart DF styrenheten 24 producerar en kontrollerad ”feP-datasignal, sän- der den en begäran till datakollektormodulen 40 för alstring av DTC-data. Så snart den är inställd, är det ej möjligt att ändra den kontrollerade "fel"- datasignalen under återstoden av körcykeln (fram till tändning från).

Såsom ovan nämnts, beräknar även DF styrenheten 24 den prioritet varmed evalueringsrutinerna associerade med denna speciflka DF modul skall exe- 10 15 20 25 30 512 140 13 kveras. Denna prioritet kommuniceras till den dynamiska schemaläggaren 30. l en föredragen utföringsform baseras prioritetsberäkningen på när eva- luerlngsrutinen associerad med denna specifika DF modul senast exekvera- des. l en speciell utföringsform arrangeras evaluerlngsrutinerna företrädesvis i fyra grupper i prioritetsordning: 1) Evalueringsfunktioner som ej har exekverats under föreliggande eller fö- regående körcykel. 2) Evalueringsfunktioner som ej har exekverats under föreliggande körcykel, men som exekverades under den föregående körcykeln. 3) Evalueringsfunktioner som har exekverats under föreliggande körcykel, men ej under den föregående körcykeln. 4) Evalueringsfunktioner som har exekverats både under föreliggande kör- cykel och den föregående körcykeln.

Det finns ytterligare två prioritetsnivåer där båda är högre än de fyra ovan nämnda nivåerna. Dessa två nivåer är den så kallade "certifieringsfönstefï nivån och "snabbtest"-nivån. Av dessa två har "snabbtesF-nivån den högre prioriteten, dvs. "snabbtest"-prioritetsnivån är den högsta av samtliga priori- tetsnivàer.

"Certifieringsfönster"-prioritetsnivån tjänar till att tillförsäkra att evaluerings- funktionen utförs under ett specificerat "fönstefl i tiden. Detta fönster är van- ligtvis en tidsperiod, faslagd genom exempelvis lagstiftning, under vilken den aktuella funktionen måste evalueras.

"Snabbtest"-nivån används exempelvis i en verkstad, efter att reparationer har utförts på aktuellt subsystemlkomponent, för att snabbt fastlägga huruvi- da reparationerna varit lyckade. 10 15 20 25 30 _s12 140 14 DTC hanteraren 25 är en DF submodul som är ansvarig för att ta beslut efter att diagnossystemet 10 har validerat ett DTC-block såsom varande giltigt.

Dess funktion inkluderar beslut avseende permanent lagring av DTC-block, sändning av begäran för att tända eller släcka den felfunktion angivande lampan i MIL hanteringsmodulen 70 och avgöra när DTC-blocket skall rade- ras om felet ej längre detekteras.

Dynamisk sohemaläggarmodul 30 Den dynamiska schemaläggarmodulen 30 hanterar schemaläggningen av evalueringsrutinerna och motorstyrfunktionerna (EC). Den dynamiska sche- maläggarmodulen 30 mottar begäran att köra motorstyrfunktioner (EC) och mottar begäran.från DF modulerna 20, 202 20" för att exekvera evaluerings- rutiner och besluta vilka av dessa motorstyrfunktioner (EC) och evaluerings- rutiner som skall utföras, och i vilken ordning, med beaktande av: - huruvida evaluerad ”fel” datasignaler föreligger, - prioriteten för de evalueringsrutinerna som har begärts, - prioriteten för de motorstyrfunktioner som begärts för exekvering, - oönskade ”kollisioner” mellan motorstyrfunktioner (EC) och evaluerings- rutiner, och - huruvida driftsvillkoren som erfordras för denna specifika motorstyrfunk- tion eller evalueringsrutin är uppfyllda.

Den dynamiska schemaläggarmodulen 30 tar i beaktande vilket som helst senast evaluerad data som den mottar fràn DF modulerna och beslutar huru- vida denna evaluerade data medför att vissa evalueringsrutiner och/eller motorstyrfunktioner påverkade av felet skall inhiberas. Den dynamiska schemaläggaren kan även ta i beaktande huruvida en DF modul informerar den dynamiska schemaläggarmodulen att en evalueringsrutin har stoppats beroende pá att villkoren för köring av evalueringsrutinen ej längre är uppfyll- 10 15 20 25 30 512 140 15 da, eller inhiberade på begäran från den dynamiska schemaläggaren eller beroende på att den dynamiska schemaläggaren ännu ej sänt kör svaret.

För att kunna uppfylla dessa krav, kräver den dynamiska schemaläggarmo- dulen 30 access till information relaterad till vad som skall göras under varje evalueringsrutin. Denna information kan ingå i en schemaläggartabell. Ett exempel på en möjlig schemaläggartabell finns i Fig. 3. Denna schemaläg- gartabell innehåller samtliga evalueringsrutiner för diagnossystemet och fö- reskriver företrädesvis: att prioritetsnivån för samtliga evalueringsrutiner är dedicerade vissa specifi- cerade prioritetsgrupper så att dendynamiska schemaläggarmodulen kan bestämma vilken av de begärda körrutinema som har prioritet inom varje pri- oritetsgrupp, och vilka andra evalueringsrutiner som skall inhiberas i händelse av att den se- nast evaluerade datan från DF modulen indikerar ett fel.

För att fungera effektivt behöver den dynamiska schemaläggarmodulen även information beträffande aktuell status för evalueringsrutinerna i diagnossy- stemet. Denna information ges av en schemaläggarlista. Såsom framgår av Fig. 4, innehåller en sådan schemaläggarlista fyra sublistor, nämligen en in- hibit-lista, en körlista, en senast evaluerad datalista och en för hantering-lista. lnhibit-listan indikerar vilka evalueringsrutiner som begärt möjligheten att köra men som icke tillåtits att köra. Flaggor i denna lista är placerad för evalue- ringsrutiner som har rapporterat att de är inhiberade och återställts för de evalueringsrutiner som har indikerat att de har upphört beroende på det fysi- kaliska tillståndet i DF modulen eller att de har slagits från av den dynamiska schemaläggarmodulen. 10 15 20 25 30 512 140 16 Körlistan, såsom namnet anger, indikerar vilka evalueringsrutiner som för närvarande körs. Flaggor i körlistan är utsatta för de evalueringsrutiner som den dynamiska schemaläggarmodulen har tillåtit påbörja körning, och åter- ställda för de evalueringsrutiner som har rapporterats vara stoppade, inhibe- rade eller frånslagna av de relaterade DF modulerna.

Listan senast evaluerad data indikerar det aktuella tillståndet för evaluerad data för varje evaluering. Flaggor i denna lista år utsatta för varje evalue- ringsrutin som har sänt en senast evaluerad “feP-datasignal, och återställda för varje evalueringsrutin som har sänt en senast evaluerad “ej fel"- datasignal.

Listan för hantering används av den dynamiska schemaläggarmodulen som arbetslista för att hålla sig à jour med evalueringsrutiner som kvarstår att hantera beroende på prioritet, tid och evaluerad "feF-datasignaler. Varje gång den dynamiska schemaläggaren har avslutat processa prioritetshanteraren 35, är de flaggor som kvarstår ”utställda” i listan avseende för hantering indi- kationer på att de associerade evalueringarna skall köras, och flaggor som är ”återställda” är indikationer att de associerade evalueringarna skall stoppas eller inhiberas.

Ovan, och i det följande, och i beskrivningarna av tabellerna i Figurema 3 och 4 har av enkelhetsskäl enbart evalueringsrutinerna inkluderats i tabeller- na. Om så erfordras och så är önskvärt, kan naturligtvis tabellerna inkludera motsvarande data avseende motorstyrfunktioner (EC).

För att exekvera de erforderliga funktionerna och såsom framgår av Fig. 1 består den dynamiska schemaläggaren av ett antal submoduler inkluderande DFS interface 31, DFS controller 32, inhiberingshanterare 33 och prioritets- hanterare 35. 10 15 20 25 30 512 140 17 Samtliga signaler som sänds från DF modulerna 20, 202 20" och ECH mo- dulen 80 till den dynamiska schemaläggarmodulen 30 identifieras i DFS in- terface 31 och överförs till de korrekta dynamiska schemaläggar- submodulerna. Samtliga signaler som sänds fràn de dynamiska schemaläg- gar-submodulerna till DF modulerna och ECH modulen överförs via DFS in- terface 31.

Samtliga signaler som sänds till den dynamiska schemahanterarmodulen 30 kontrolleras af DFS controllern 32. DFS controllern uppdaterar den inhibera- de lista, körlistan och den senast evaluerade datlistan för signaler som sänts från DF modulema 20, 20', 20” till den dynamiska schemahanterarmodulen 30. Om någon av de tre listorna har uppdaterat verkar DFS controllem 32 enligt följande: Kopiera den inhiberade listan och körlistan till lista för hantering.

Starta inhiberingshanteraren 33.

När inhiberingshanteraren 33 är färdig, starta prioritetshanteraren 35.

När prioritetshanteraren är färdig, utför en "stopp" rutin, dvs. DFS controllern 32 sänder inhibit-begäran till evalueringsrutinema som körs enligt körlistan (flaggor är uppställda) men som ej skulle köras enligt listan för hantering (flaggor är àterställda), och ställer upp flaggorna i den inhiberade listan som indikation att den dynamiska schemaläggaren har begärt att dessa evalue- ringar skall inhiberas.

När ”stopp” rutinen är avslutad, utförs en "start" rutin, dvs. DFS con- trollern sänder ett körsvar till var och en av evalueringarna som skall köras enligt listan för hantering och var och en är associerad med en prioritetsgrupp enligt schemaläggartabellen i vilken inga andra evalu- 10 15 20 25 30 V512 140 18 eringar körs enligt körlistan. För varje körsvar som sänds, sätter DFS controllem motsvarande flagga i körlistan.

När avslutat, kontrollera om det finns någon signal som har sänts till den dynamiska schemaläggaren och om så är fallet starta arbeta igen.

När en begäran att stoppa samtliga evalueringsrutiner sänds från varje ECH modul 80, verkar DFS controllern 32 enligt följande: Rensa listan för hantering och starta arbeta (inhiberingsbegäran sänds till samtliga evalueringsrutiner som körs).

När avslutat, uppdatera senast evaluerad datalista, körlistan och den inhiberade listan enligt samtliga signaler sända till den dynamiska schemaläggaren men starta ej arbeta som i normal operation.

När samtliga flaggor i körlistan är återställda, sänd svaret att samtliga evalueringsrutiner har stoppats till ECH modulen 80.

Vänta enbart för en begäran att återta normal operation från ECH modulen 80.

När begäran att återta normal operation mottagits, kopiera listan för hantering och starta arbete som normalt.

När en begäran om frånslagning av samtliga evalueringsrutiner mot- tagits från diagnossystemstyrmodulen (DSM) 90, verkar DFS con- trollern 32 enligt följande: Sänd begäran om frånslagning till samtliga evalueringsrutiner. 10 15 20 25 30 512 14o 119 Uppdatera senast evaluerade datalista, körlista och listan om begä- ran om körning enligt samtliga signaler sända till den dynamiska schemaläggaren.

När samtliga flaggor i körlistan och den inhiberade listan är återställ- da, sänd ett svar till DSM modulen 90 att samtliga evalueringsrutiner har slagits fràn.

Vänta enbart för en allmän svarssignal från DSM modulen 90 för att starta diagnossystemet 10 innan återstart av normalt arbete. Ingen verksamhet under väntetid. lnhiberingshanteraren 33 agerar enbart pà en startbegäran mottagen från DFS controllern 32. lnhiberingshanteraren 33 kontrollerar först den senast evaluerade datalistan för att bestämma vilka evaluerings- rutiner som genererat senast evaluerade "feW-datasignaler. För de evalueringsrutiner som genererat sådana signaler, kontrollerar inhi- beringshanteraren 33 schemaläggartabellen (fig. 3) för att avgöra vil- ka evalueringsrutiner för inhibering beror på rapporterade fel. lnhibe- ringshanteraren 33 återställer flaggorna i listan för hantering svaran- de mot de evalueringsrutiner som skall inhiberas. När detta är färdigt, sänder lnhiberingshanteraren en "färdig"-signal till DFS controllern 32.

Prioritetshanteraren 35 reagerar enbart på en begäran att starta från DFS controllern 32. Prioritetshanteraren kontrollerar listan för han- tering för att förvissa sig om vilka evalueringsrutiner som skall hante- ras. Med användning av denna lista och schemaläggartabellen, är prioritetshanteraren 35 kapabel att avgöra vilka av evalueringsruti- nerna som skall hanteras är i samma prioritetsgrupp, startande med prioritetsgrupp nr 1 i schemaläggartabellen (exempelvis X) (fig. 3).

Prioritetshanteraren återställer motsvarande flagga i listan för han- 10 15 20 25 30 512 140 20 tering för evalueringsrutiner som har lägre prioritetsnivàer än de evalueringsrutiner som skall hanteras och som har den högsta prio- ritetsnivän inom prioritetsgruppen, När det är färdigt med den första prioritetsgruppen, fortsätter priori- tetshanteraren 35 med prioritetsgrupp nr 2 (exempelvis Y) osv tills att samtliga prioritetsgrupper har kontrolleras .

Om en evalueringsrutin är tillordnad fler än en prioritetsgrupp, hante- ras den som del av varje prioritetsgrupp. Prioritetsnivàn används därvid individuellt i varje prioritetsgrupp.

Eftersom den dynamiska schemaläggarmodulen 30 har interface mot fordonets motorstyrfunktioner (EC), skall de funktioner hos dessa kalkyleringsrutiner i motorstyrfunktionema som kommunicerar med den dynamiska schemaläggarmodulen 30, kortfattat beskrivas i det följande: För var och en av de aktuella motorfunktionerna kalkyleras ett priori- tetsvärde. Denna kalkylering tar i beräkning: - tidsperioden som ovan benämnts ”certifieringsfönster” - huruvida villkoren erforderliga för utförande av den aktuella mo- torstyrfunktionen är uppfyllda - prioritetsnivàn som ovan nämnts ”snabbtest”.

Eftersom de prioritetsnivàer som kalkylerats av två eller flera motor- styrfunktioner eller evalueringsrutiner kan vara lika, ges varje kalkyle- ringsrutin eller motorstyrfunktion en så kallad "statisk prioritet”. Om två eller flera kalkylerade prioriteter är lika, kalkyleras en totalprioritet, 10 15 20 25 30 512 140 '21 där totalprioriteten är summan av den kalkylerade och statiska prio- riteten.

Datakollektor modulen 40 På begäran fràn en DF modul 20, 20', 20" för att skapa DTC-data, är datakollektor modulen 40 anordnad att utföra följande funktioner: Skapa en frysram (i det följande benämnd FRZF) med DTC-specifik data.

Kombinera F RZF med viss information för att bilda ett DTC-block.

Skapa en utvidgad FRZF (mätt över tid) med DTC-specifik data.

Sänd DTC-data (DTC-block och utvidgat FRZF) till DTC-data- areamodulen 50.

Datakollektor modulen 40 kan med fördel även verka som en intern svart låda pä begäran fràn ECH modulen 80.

För att uppfylla dessa krav kräver datakollektor modulen 40 informa- tion beträffande de specifika parametrarna för varje evalueringsrutin som skall utföras i DF modulerna 20, 20', 20". Denna information finns i en FRZF tabell och en utvidgad FRZF tabell. Ett exempel pà en FRZF tabell och en utvidgad FRZF tabell finns i figur 5. Varje tal i tabellerna anger en specifik parameter.

Enligt vad som nämnts ovan, genererar datakollektor modulen 40 ett DTC-block. Ett DTC-block är ett datablock som innehåller information i form av parametrar hänförande sig till driftstillständen vid tidpunkten när DTC genererades. Ett exempel pä ett möjligt DTC-block finns vi- sat i figur 6. DTC-blocket bestàr sålunda av viss DTC-specifik infor- 'lO 15 20 25 30 512140 22 mation (DTC, senaste och initial DTC-subkod och FRZF fördröj- ningstid) tillsammans med FRZF och slutligen en visare till utvidgad FRZF.

För att kunna skapa utvidgat FRZF, som är en mätning över tiden av DTC-relevant data, är datakollektor modulen 40 försedd med ett cir- kulerande minne i form av en roterande buffert. Såsom visas i figur 7, är den roterande bufferten allmänt betecknad med hänvisningssiffran 110 och är i form av en trumma 111 som i det visade exemplet är uppdelad ifyra olika tidsbaser 112, 113, 114 respektive 115.

Ett exempel på en utvidgad frysram visas i figur 8.

En global data area, betecknad med hänvisningssiffran 120 i figur 1, är belägen utanför diagnossystemet 10 i motorstyrsystemdelen av motorstyrmodulen och innehåller aktuell information om värden pä samtliga parametrar för evalueringsrutiner. Varje parameter är identi- fierbar med en unik identifieringssiffra i den globala data arean 120 och är tillordnad en av tidsbasema 112, 113, 114, 115. Den roteran- de bufferten 110 uppdateras varje gång en tidsbas utgår med para- metervärden associerade med den utgängna tidsbasen överkopierat från den globala dataarean 120 och dessa parametrar lagras i sina respektive tidsbaser. En visare 116, 117, 118, 119 för att ange se- naste sampling som skall överkopieras placeras framför den senaste samplingen i varje tidsbas. När en tidsbas hos den roterande buffer- ten 110 är full, skrivs den äldsta samplingen över i denna tidsbas.

Den roterade bufferten 110 bildar på detta sätt ett cirkulerande minne med ett antal tidsbaser, var och en med lika minnesdjup men med specifikt tidsdjup.

För att generera DTC-data som därefter skall sändas till DTC-data- areamodulen 50 och hanteringsbegäran sända fràn ECH modulen, är 10 15 20 25 30 512 140 23 datakollektormodulens 40 funktion uppdelad i submoduler, dvs DC interface 41, DC controllern 42, FRZF kollektor 43, utvidgad FRZF kollektor 44 och bufferthanterare 45.

Samtliga signaler som sänds från DF modulerna 20, 20', 20" och ECH modulen 80 till datakollektormodulen 40 identifieras av DC in- terface 41 och överförs till korrekta datakoliektor-submoduler. Samt- liga signaler sända fràn datakollektor-submodulerna till DTC-data- areamodulen 50 och ECH modulen 80 överförs via DC interface 41.

Vid mottagande av en begäran från en DF modul 20, 20', 20" för att skapa DTC-data, begär DC controllern 42 att FRZF kollektom 43 skall skapa en FRZF. Vid mottagande av denna begäran, kontrollerar FRZF kollektorn 43 FRZF tabellen (figur 5) för att fatta avgörande om vilka parametrar specifika för denna DTC som skall kopieras över fràn den globala dataarean 120. FRZF kollektorn fortsätter att kopie- ra parametrarna från global dataarea och placerar dessa i den ord- ning som specificerats av FRZF tabellen. När detta är avslutat, in- formerar FRZF kollektom DC controllern 42 att FRZF har skapats.

När FRZF kollektorn 43 informerat DC controllern 43 att FRZF har skapats frågar DC controllern den utvidgade FRZF kollektorn 44 om skapande av ett utvidgat FRZF.

Vid mottagande av denna begäran, utför den utvidgade FRZF koll- ektorn 44 följande åtgärder: Stoppar den roterande bufferten genom att sända en stoppbegäran till bufferthanteraren 45. 10 15 20 25 30 512 S140 ' '24 Skapar en tom utvidgad FRZF av korrekt storlek, där den tomma ut- vidgade FRZF inkluderar parameteridentiflkationstal specificerade av den utvidgade FRZF tabellen.

Vid mottagande av bekräftelse att den roterande bufferten har stop- pats, överkopiering av samtliga parametervärden svarande mot iden- tifieringssiffrorna i den utvidgade FRZF som matchar identifierings- siffrorna specificerade i den roterande bufferttabellen fràn den ro- terande bufferten.

Starta den roterande bufferten genom att sända en startbegäran till bufferthanteraren 45.

Sänd ett svar till DC controllern 42 att utvidgad FRZF har skapats.

Med användning av bland annat information tillhandahàllen i FRZF och den utvidgade FRZF, skapar DC controllem 43 DTC-data i form av DTC-block (se figur 6) modifierat för att ta hänsyn till nämnda ut- vidgade FRZF.

Så snart DTC-data har skapats, sänder DC controllern 42 en begä- ran till DTC-data-areamodulen 50 att spara DTC-data.

Efter att nämnda begäran sänts, väntar DC controllem 42 pà bekräf- telse från DTC-data-areamodulen att DTC-data har sparats innan åt- gärd vidtas avseende eventuell ny begäran att skapa DTC-data.

DTC-data-areamodulen 50 DTC-data-areamodulen 50 är uppdelad i fyra submoduler, nämligen DA interface 51, DTC-block area 52, utvidgad FRZF area 53 och DA controllem 54. 10 15 20 25 30 'S12 140 ' '25 Samtliga signaler som sänds till DTC-data-areamodulen 50 från ECH modulen 80, datakollektormodulen 40, validatorn 60 och DF modu- lerna 20, 20', 20" identifieras av DA interface 51 och överförs till den korrekta DTC-data-area-submodulen_ Samtliga signaler som sänds frän DTC-data-area-submodulerna till validatorn 60 och datakollek- tormodulen 40 överförs via DA interface 51.

DTC-block area 52 används för lagring av DTC-block. Det antal DTC-block som kan lagras i denna area varierar från applikation till applikation, men ett typiskt antal är 10. DTC-block arean 52 är alltid kapabel att lagra åtminstone maximalt antal DTC-block plus ett. Det ytterligare ena blocket representerar ett temporärt utrymme som an- vänds för att buffra inkommande data fràn datakollektormodulen 40.

DTC-block arean 52 använder en frilista för att hälla sig ajour med det fria DTC-block, och en temporärvisare för att hälla sig ajour med det temporära utrymmet.

Utvidgad FRZF area 53 används för lagring av utvidgad FRZF. Den utvidgade FRZF arean 53 är alltid kapabel att lagra ett förutbestämt maximalt antal av utvidgade FRZF plus ett. Nämnda ytterligare ett representerar ett temporärt utrymme som används för att buffra in- kommande data från datakollektormodulen 40. Nämnda utvidgade FRZF area 53 använder en frilista för att hålla sig ajour med fria ut- vidgade FRZF, och en temporärvisare för att hålla sig ajour med det temporära utrymmet.

DA controllern 54 styr DTC-blocket 52 och utvidgad FRZF area 53.

Den mottar ett DTC-block och utvidgad FRZF via DA interface 51 från datakollektormodulen 40 och DTC-blocket och utvidgade FRZF sparas i applicerbara data-areor. 10 15 20 25 30 512140 26 När DA controllern 53 mottar en begäran från datakollektormodulen 40 att spara DTC-data, sparar DA controllern DTC-blocket och asso- cierad utvidgad FRZF och, när detta är gjort, informeras validerings- modulen 60 att ett icke validerat DTC-block har sparats och väntar för mottagningsbekräftelse svar eller någon begäran från valideraren.

Om valideraren sänder ett bekräftande svar, informerar DA control- lern datakollektormodulen 40 att DTC-data har sparats.

Om den relaterade DF modulen sänder ett bekräftelsesvar, informe- rar DA controllern datakollektormodulen 40 att DTC-data har sparats.

När så begärs av valideringsmodulen 60 att ändra DTC-data blocksstatus från icke validerat till validerat, eller att radera icke vali- derat eller validerat DTC-block, gör DA controllem 54 sålunda och informerar den relaterade DF modulen om att giltigt DTC-block har raderats och väntar för bekräftelse svar eller någon form av begäran från den relaterade DF modulen.

När det från en DF modul begärs ändring av DTC-block status från giltigt till lagrat, eller radering av giltigt eller lagrat DTC-block, gör DA controllem sålunda och informerar valideringsmodulen 60 att ett gil- tigt eller lagrat DTC-block har lagrats eller raderats.

Om, efter sändning av ett svar att DTC-data har sparats, det tillgäng- liga utrymmet ej är nog för nästa DTC-block, dvs inget temporärt ut- rymme är fritt, raderar DA controllern 54 DTC-blocket och associera- de utvidgad FRZF med lägsta prioritet och informerar valideringsmo- dulen 60 och relaterade DF modul 20, 20', 20" att det specifika DTC- blocket har raderats. Om det finns enbart ej tillräckligt utrymme för nästföljande utvidgade FRZF, raderar DA controllern den utvidgade FRZF som har lägsta prioritet och raderar koppling emellan det rade- 10 15 20 25 30 512 140 27 rade utvidgade FRZF och associerat DTC-block men sänder ej nå- gon information om denna händelse.

På begäran att radera samtliga DTC sända från ECH modulen 8, ra- derar DA controllem 54 samtliga DTC-block och, för varje raderat DTC-block informeras valideraren 60 och relaterad DF modul.

Valideringsmodulen 60 Syftet med valideringsmodulen 60 är att avgöra rotorsaken till ett fel.

Med andra ord, är det till exempel möjligt att fyra DTC-block med ut- vidgade FRZF genereras av datakollektormodulen 40, även om i själva verket enbart ett DTC-blocken är den sanna indikatorn på fel.

Detta beror på att felet ar beroende av de övriga involverade evalue- ringsrutinerna, så att felaktiga "feV-signaler sänds från berörda DF moduler till datakollektormodulen 40. Valideraren undersöker sålun- da vart och ett av de fyra DTC-blocken (med associerade utvidgade FRZF) för att avgöra i vilken komponent eller system det faktiska fe- let ligger.

När sålunda valideringsmodulen 60 informeras av DTC-data- areamodulen 50 att ett sparat DTC-block föreligger, sätter validera- ren upp en checklista som innehåller samtliga möjliga rotorsakseva- lueringsrutiner som skall utföras och rapporteras med kontrollerad data såsom ”ej fel” innan validering av korrekt DTC, dvs pekar ut det DTC-block som är roten till felet. Innehållet i valideringschecklistan lagras vid frånslagning av tändning, dvs valideringen är oberoende av tändning till/fràn.

Av valideraren uppställda listor används för att beställa upp och initi- era checklistor. Varje uppställd lista innehåller DTC för validering och en specifikation av vilka evalueringar som skall kontrolleras innan va- 10 15 20 25 30 5112140 28 lidering av den DTC som skall valideras. En för validering uppställd lista och motsvarande valideringschecklista finns visad i figur 9.

En checklista uppställs enligt dess uppställnlngslista på följande sätt.

När valideringsmodulen 60 informeras av DTC-data-areamodulen 50 att ett DTC-block har sparats, söker valideringsmodulen uppställ- ningsllstan för en för validering avsedd DTC som svarar mot DTCn i DTC-blocket. Om denna DTC ej àterfinns l någon för validering av- sedd DTC-position i någon av uppställningslistorna, gör valideraren omedelbart DTC-blocket giltigt genom att begära att DTC-data- areamodulen 50 ändrar status på DTC-blocket från ej validerat till gil- tigt.

Om DTC àterfinns, används validerarens uppställningslista inne- hållande det matchande DTC-till-validera för att sätta upp en valide- rar-checklista specifik för detta DTC. Checklistan omfattar följande delar: Rubrik som specificerar DTC som valideras (detta länkar checklistan till dess uppställningslista).

Tidsstámpel (förfluten realtid avläst från global dataarea 120).

Flaggor som indikerar status för varje evaluering-till-check i validera- rens uppställningslista, en flagga sätts ut för kontrollerat icke-fel och àterställning så länge som kontrollerat icke-fel ej har rapporterats.

EvaIuering-till-check länkad till varje flagga är definierat i uppställ- ningslistan. 10 15 20 25 30 512 140 29 En validerar-uppställningslista som har en validerar-checklista länkad till sig, kommer i det följande att benämnas aktiv validerar- uppställningslista.

Validerarchecklistorna uppdateras enbart pà begäran sänd fràn DSM modulen 90 vid slutet av varje körcykel. Under uppdateringsprocedu- ren, begär validerarmodulen, kontrollerad data från varje DF modul 20, 20', 20" som definierats i den aktiva validerar-uppställningslistan, Varje DF modul svarar med dess aktuella kontrollerade datatillstànd, dvs icke kontrollerat, kontrollerat fel eller kontrollerat icke-fel. Svaret "kontrollerat icke-fel" sätter upp en motsvarande flagga i validerarens checklista. Svaren ”ej kontrollerat" och ”kontrollerat fel" återställer motsvarande flagga i checklistan.

När samtliga flaggor i validerarens checklista har ställts upp beslutas att det DTC-block som är associerat med DTC-till-validera är giltigt DTC-data- areamodulen med begäran om ändring av DTC-blockets status från och valideringsmodulen 60 sänder en signal till icke-validerat till giltigt. DTC-data-areamodulen 50 ändrar status och sänder därefter en signal till den applicerbara DF modulen att status för ett DTC-block har ändrats till giltigt.

Såsom visas i figur 10, när valideringsmodulen 60 mottar en andra icke-validerad DTC-block sparad signal (checklista A) från DTC-data- areamodulen som svarar mot en evaluering-till-check i en aktiv vali- derar-uppställningslista med associerad validerarchecklista (check- lista B), betraktas det DTC-block som genererade denna aktiva vali- derarchecklista ej vara rotorsaken. Ett sådant DTC-block och valide- rarchecklista (checklista B) raderas därför. Detta åstadkoms genom att en signal sänds till DTC-data-areamodulen med begäran att DTC- blocket relaterat till rubriken i validerarchecklistan raderas. Vid mott- agande av svaret att DTC-blocket har raderats, raderar valideraren 10 15 20 25 30 siz 140 30 den relaterade validerarchecklistan. En ny validerarchecklista sätts upp för det andra DTC-blocket som orsakade dessa händelser.

När validerarmodulen 60 mottar en signal från DTC-data- areamodulen 50 att status för ett DTC-block har ändrats fràn giltigt till lagrat, raderas motsvarande validerarchecklista.

För att garantera relevansen hos informationen i validerarmodulen 60, är en àterställfunktion implementerad för validerarchecklistan. Återställfunktionen återställer samtliga flaggor när validerarchecklis- tan är äldre än en förutbestämd tidsperiod, exempelvis åtminstone 168 timmar.

Normal total funktion för diaanossvstemet 10 när inget fel föreligger Den normala totala funktionen för körning av de olika evalueringarna med korrekt system (dvs inget fel) beskrivs nedan: Vid mottagande av signalen sänd från DSM modulen 90 för start av diagnossystemet, kommer varje DF modul så snart de fysikaliska villkoren är uppfyllda för körning av dess evaluering, sända priorite- ten för dess associerade evaluering till den dynamiska schemaläg- garmodulen 30. Den dynamiska schemaläggarmodulen 30 kommer även att från ett antal motorfunktioner motta begäran att köra.

När den dynamiska schemaläggarmodulen mottar denna information, fastlägger den ordningen för verkställande av evalueringarna och motorstyrfunktionerna och sänder körsvar till motorstyrfunktionema och relaterade DF moduler som innehåller evalueringar som är tillàt- na att köra. De DFmoduler och motorstyrfunktionen (EC) som mottar körsvar från den dynamiska schemaläggarmodulen kommer nu att köras/verkställas. Evaluerad data från DF modulerna används för att avgöra huruvida eller ej fel föreligger i den kontrollerade komponen- 10 15 20 25 30 512 140 31 ten/subsystemet och även för att besluta huruvida eller ej DTC-data skall skapas.

Om en evalueringsrutin skall avbrytas beroende pà ändringar i dess fysikaliska tillstànd (exempelvis motorhastighet) eller exempelvis av- slutas för resten av körcykeln, tar relaterad DF modul hänsyn till detta vid kalkylering av prioriteten för denna evalueringsrutin.

När den dynamiska schemaläggarmodulen mottar svar att en evalue- ring eller motorstyrfunktion har stoppats, fastlägger den dynamiska schemaläggaren prioritetsordnlngen för evaluerlngarna som inhibe- rats beroende på prioritet förutom de evalueringar som fortfarande kör och, om sä är tillåtet, sänds körsvar till de relaterade DF moduler som innehåller evalueringar som nu ej längre skall inhiberas beroen- de på prioritet. Detta upprepas tills att DSM modulen 90 sänder en signal med begäran att bryta samtliga evalueringar, dvs stoppa dia- gnossystemet. Begäran från motorstyrfunktioner som ej kör om att köra hanteras pà liknande sätt.

Detta fullbordar den normala totala funktionen för diagnossystemet när inget fel föreligger.

Normal total funktion när ett eller flera fel föreligger i diagnossyste- mät Den normala totala funktionen för att inhibera påverkade evaluering- ar och lagra korrekt DTC (tillsammans med MIL tändning) i diagnos- systemet 10 med ett eller flera fel föreliggande beskrivs i följande: Om, under den ovan beskrivna totala funktionen när inget fel förelig- ger, en evalueringsrutin i en DF modul detekterar fel och genererar evaluerad data som "fel", sänder därefter den relaterade DF modulen 10 15 20 25 30 512 140 32 senast evaluerad data som ”fel” till den dynamiska schemaläggar- modulen 30.

När den dynamiska schemaläggarmodulen mottar senast evaluerad data som "fel", inhiberar den först de evalueringar som är påverkade av detta fel och därefter fastläggs en prioritetsordning mellan åter- stående evalueringar som ej är påverkade av felet, dvs evalueringar- na som är inhiberade beroende på prioritet såväl som de evaluering- ar som kör.

Om en annan evaluering mottar senast evaluerad data som "fel”, in- hiberar den dynamiska schemaläggarmodulen 30 de evalueringar som är påverkade av denna andra evaluering etc för varje evaluering som rapporterar senast evaluerad data som "fel".

När en specifik filtrering av evaluerad data som ”fel” avslutats, insätts kontrollerad data som ”fel” i den relaterade DF modulen för återsto- den av körcykeln. Så snart kontrollerade data är satt som ”fel” sänder relaterad DF modul en begäran till datakollektormodulen 40 att skapa DTC-data.

Vid mottagande av begäran att skapa DTC-data, skapar datakollek- tormodulen 40 ett DTC-block tillsammans med utvidgad FRZF och, när detta är klart, sänds en begäran till DTC-data-areamodulen 40 att spara denna DTC-data (med status "ej validerat“).

På begäran att spara DTC-data, sparar DTC-data-areamodulen DTC-blocket tillsammans med nämnda utvidgade FRZF och, när detta är klart, sänds information till validerarmodulen 60 att ett icke validerat DTC-block har sparats. och därefter sänds till datakollek- tormodulen 40 svaret att DTC-blocket har sparats. 10 15 20 25 30 512 140 33 När validerarmodulen 60 fràn DTC-data-areamodulen 50 mottar in- formationen beträffande det sparade DTC-blocket, ställer den upp en validerarchecklista som innehåller samtliga evalueringar som behö- ver utföras, pà begäran, för att svara till valideringsmodulen att de har sin kontrollerade data som icke-fel innan valideringsmodulen av- gör att DTC-blocket är giltigt.

Validerarchecklistan uppdateras vid slutet av varje körcykel på begä- ran sänd från DSM modulen.

När checklistan är fullbordad och DTC-blocket beslutats vara giltigt, validerar valideringsmodulen det icke-validerade DTC-blocket genom att till DTC-data-areamodulen 50 sända en begäran att ändra DTC- blockets status fràn icke-validerat till giltigt.

Vid begäran sänd från validerarmodulen 60 att ändra DTC-blockets status fràn icke-validerat till giltigt, ändrar DTC data-area modulen 50 DTC-blockets status från icke-validerat till giltigt och, när detta är klart, sänds till relaterad DF modul informationen att DTC-blocket är giltigt.

När DF modulen mottar informationen att ett relaterat DTC-block har status "giltigt”, initierar och styr DF modulen en DTC-lagringsprocess och, när detta är klart, sänds en begäran till DTC-data-areamodulen 50 att ändra DTC-blockets status från giltigt till lagrat.

När DTC-data-areamodulen från relaterad DF modul mottar begäran att ändra DTC-blockstatus fràn giltigt till lagrat, ändrar DTC-data- areamodulen DTC-blockstatus från giltigt till lagrat och sänder till va- liderarmodulen 60 informationssignalen att DTC-blocket har ändrad status till lagrat. 10 15 20 25 30 512 140 34 När valideringsmodulen mottar informationen att ett DTC-block har ändrat status till lagrat, raderar modulen den relaterade checklistan.

När DF modulen mottar information att det relaterade DTC-blocket har status lagrat i DTC-data-areamodulen, kommer modulen, i till- lämpbara fall, sända en begäran till MIL hanteringsmodulen 70 för att tända MIL.

När MIL hanteringsmodulen mottar begäran fràn DF modulen att tända MIL, tänds MIL.

Det ovan beskrivna skapandet, sparandet och stätusändringen av DTC-data utförs även om en annan DF modul sänder en annan be- gäran att skapa DTC-data. Hantering av aktuell DTC-data avslutas emellertid innan nästa hantering, etc för varje DF modul i diagnossy- stemet. Sålunda, med andra ord, så snart DTC-data-areamodulen mottagit en bekräftelsesignal fràn validerarmodulen eller, om det ak- tuella DTC-blockets status har ändrats till giltigt, kommer en bekräf- telsesignal från den aktuella DF modulen i DTC-data-areamodulen att hantera varje ny begäran att spara DTC-data.

Om DTC-data-areamodulen rapporterar att ett ytterligare nytt icke- validerat DTC-block har sparats, kontrollerar valideringsmodulen 60 huruvida motsvarande evaluering av detta nya DTC-block återfinns som en evaluering som skall kontrolleras i den aktuella checklistan.

Om så är fallet, är den aktuella checklistan och associerat DTC-block ej längre den möjliga roten till felet och validerarmodulen sänder en begäran till data-areamodulen att radera det aktuella DTC-blocket och uppställer därefter en annan checklista för det nya DTC-blocket, etc tills att status för något DTC-block är ändrat till lagrat i DTC-data- areamodulen 50. 10 5121140 35 Om status för ett DTC-block har ändrats till lagrat, raderar validerar- modulen den associerade checklistan.

Detta fullbordar den normala totala funktionen för inhibering av pà- verkade evalueringar och för lagring av korrekt DTC tillsammans med tändning av MIL i diagnossystemet 10 med ett eller flera fel exi- sterande.

Uppfinningen är ejbegränsad till de ovan beskrivna och pà ritningar- na visade utföringsformerna, utan variationer är möjliga inom ramen för de bifogade kraven. . . . - . f

Claims (14)

10 15 20 25 30 512440 36 107677 VG/MAH 1998-11-26 PATENTKRAV

1. Diagnossystem (10) i ett motorstyrsystem för generering av en diagnostisk felkod (DTC) för att indikera driftstatus hos en komponent eller subsystem som evalueras av nämnda diagnossystem, varvid diagnossyste- met omfattar: en diagnosfunktionsmodul (DF modul) (20; 20'; 20") för varje DTC eller grupp av relaterade DTC, varvid DF modulen inkluderar anordning (22) för exekve- ring av en evalueringsrutin för att evaluera driftsstatus hos en komponent eller subsystem vartill DTC för den specifika DF modulen är relaterat, och en dynamisk schemaläggare (30) för att fatta avgörande om vilken evalue- ringsrutin associerad med en DF modul (20; 20'; 20") kan tillåtas exekveras vid viss tidpunkt; varvid varje DF modul omfattar, anordning (24) för att fatta avgörande om den prioritet varmed evalueringsru- tinen associerad med denna DF modul skall exekveras.

2. Diagnossystem enligt krav 1, ytterligare omfattande: anordning (22) för àstadkommande av rankingvärde beroende av driftsstatus hos komponenten eller subsystemet som evalueras, varvid ett rankingvärde genereras varje gång en evalueringsrutin utförs; anordning (23) för att processa och lagra statistiska resultat för de ranking- värden som erhållits under ett antal evalueringsrutiner; 10 15 20 25 30 512 140 37 anordning (22) för att evaluera nämnda statistiska resultat för att alstra eva- luerad data i form av antingen en evaluerad icke-felsignal eller en evaluerad felsignal, och anordning (24) för transmission av nämnda evaluerade signal till nämnda dynamiska schemaläggare när en ändring i nämnda signaler uppkommer.

3. System enligt krav 1 eller 2, där nämnda dynamiska schemaläg- gare (30) omfattar anordning verkande i beroende av en evaluerad felsignal för att förhindra andra DF moduler att utföra evalueringar om dessa andra DF moduler kan pâverkas av nämnda evaluerade felsignal.

4. System enligt något av föregående krav, där nämnda dynamiska Schemaläggare (30) omfattar anordning arbetande i beroende av signaler fràn motorstyrfunktioner och DF moduler, som förhindrar exekvering av mo- torstyrfunktioner, eller evaluering med DF moduler, om dessa motorstyrfunk- tioner eller evalueringar med DF moduler skulle interferera med en styrfunk- tion eller en evaluering med en DF modul som utförs samtidigt.

5. System enligt nàgot av föregående krav, där nämnda anordning i DF modulerna för att fatta avgörande om den prioritet varmed modulernas associerade evalueringsrutiner skall exekveras omfattar en kalkylering base- rad på när den med denna DF modul associerade evalueringsrutinen senast exekverades.

6. System enligt nàgot av föregående krav, där nämnda DF modul (20; 20'; 20") ytterligare omfattar anordning (24) för jämförelse av nämnda evaluerade data med tidigare genererad data relaterad till evalueringar av komponent eller subsystem vartill DTC för den specifika DF modulen är re- laterad, och i händelse av att en evaluerad felsignal genereras, jämförelse av nämnda signal med därefter alstrade evaluerad data, för att därigenom gene- rera antingen en kontrollerad felsignal eller en kontrollerad icke-felsignal. 10 15 20 25 30 _5l2 140 '38

7. System enligt krav 6, där nämnda system inkluderar en datakol- lektormodul (40), och nämnda DF modul omfattar anordning (24) för att sän- da begäran till nämnda datakollektormodul för att skapa DTC-data när en kontrollerad felsignal genereras i nämnda DF modul.

8. System enligt krav 7, där nämnda datakollektormodul (40) om- fattar anordning för att skapa nämnda DTC-data, varvid nämnda DTC-data är i form av ett DTC-block innehållande DTC och information hänförande sig till driftsvillkor för motorn när nämnda DTC genererades.

9. System enligt krav 8, där nämnda datakollektormodul (40) om- fattar anordning för att transmittera nämnda DTC-block till en validerarmodul (60).

10. System enligt krav 9, där nämnda validerarmodul omfattar an- ordning för att fatta avgörande om vilka komponenter eller subsystem det evaluerade och därefter genererade DTC-blocket är beroende av, och an- ordning för att erhàlla data hänförande sig till driftsstatus för nämnda kompo- nenter eller subsystem av vilka nämnda kontrollerade icke-felsignal är bero- ende.

11. System enligt krav 10, där nämnda validerarmodul (60) omfattar anordning för att evaluera nämnda data hänförande sig till driftsstatus hos nämnda komponenter eller subsystem av vilka nämnd kontrollerad icke- felsignal är beroende för att därigenom avgöra huruvida nämnda DTC-block är giltigt.

12. System enligt krav 11, där nämnda valideringsmodul 60 fattar anordning för ändring av DTC-blockstatus till giltigt i händelse av att DTC- blocket bedöms vara giltigt, och anordning för radering av DTC-blocket i händelse av att DTC-blocket bedöms vara ej giltigt. 10 15 20 25 30 512 140 39

13. DF modul (20; 20'; 20") för exekvering av en evalueringsrutin under en körcykel för att detektera ett fel i en komponent eller subsystem i ett motorstyrsystem och för att generera en diagnostisk felkod DTC för att indi- kera driftstatus för nämnda komponent eller subsystem, varvid modulen om- fattar anordning (24) för att bestämma den prioritet varmed den till den specifika DF modulen associerade evalueringsrutinen skall exekveras.

14. DF modul enligt krav 13, ytterligare omfattande: anordning (22) för att exekvera en evalueringsrutin för att evaluera driftstatus för nämnda komponent eller subsystem till vilken DTC för den specifika DF modulen är relaterat, anordning (22) för att åstadkomma ett rankingvärde beroende av driftstatus för den komponent eller subsystem som evalueras, varvid ett rankingvärde genereras varje gäng en evalueringsrutin utförs; anordning (23) för att processa och lagra statistiska resultat för rankingvär- den erhållna under ett antal evalueringsrutiner; anordning (22) för att evaluera nämnda statistiska resultat för att åstadkom- ma evaluerad data i form av antingen en evaluerad icke felsignal eller en evaluerad felsignal; anordning (24) för mottagning av nämnda evaluerade signaler från nämnda anordning (22) för evaluering av nämnda statistiska resultat för att åstad- komma en kontrollerad felsignal vid mottagande av ett förutbestämt antal av evaluerade felsignaler; 512 140 40 anordning (25) för att bestämma huruvida nämnda kontrollerade felslgnal skall lagras i form av DTC-data för återstoden av körcykeln; anordning (25) för att bestämma huruvida lagrad DTC-data skall raderas, och anordning (25) för att bestämma huruvida en felfunktion angivande lampa skall tändas eller släckas i beroende av lagrad DTC-data.