1,If all faults that are stored in the fault memory are confirmed faults, the software shall delete the confirmed fault with the lowest priority and if there are more than one low priority faults, the last logged low priority fault shall be erased.
2,If there is at least one fugitive fault in the fault memory, the software shall delete the fugitive fault with the lowest priority and if there are more than one low priority faults, the one with the lowest counter value shall erased. If there are several of them, the last logged low priority fault shall be erased.
my understanding for
fault memory = 10 faults
1, case 1: induce 9 equal faults and one low priority fault(i.e 10 fault). now fault memory is full. so if u induce 11 th fault of high priority then it will over write 10 fault. case 2: induce 8 equal faults and 2 low priority fault( i.e 9,10 fault). now fault memory is full. so if u induce 11 th fault of high priority then it will over write 9 fault as it last logged low priority fault. case 3: induce 10 equal faults . now fault memory is full. so if u induce 11 th fault of same priority then it will over write 10 fault or 1st fault or it won't log.
2,similarly in fugitive Case. Regards rajesh
As it is importent to know the status of the fault . A confirmed DTC means that its corresponding counter is set to 40 A fugitive DTC means that its corresponding counter is set between 1 and 39 A not present DTC means that no counter and no associated context are linked to a DTC
If it over writes the 10 fault DTC ,how it is logical with respect practical application. if feel it should over 1st fault DTC or it should not log at all.
My question is could any one give their real time experence on the fault management and where can i get more information for the above issues?
I'm still not clear on what fugitive fault is and Google doesn't help. I'm guessing it is a fault that has been flagged by one sensor but not by another which is supposed to be monitoring the same thing.
Does the 1-39 give your the priority of the DTC? How do you handle the priority of a confirmed DTC? I would be inclined to store the counter and an identifier of what raised the DTC together in one of the ten locations.
In fault handling I would use a LIFO method on same priority faults working on the assumption that if you ignored the fault when it happened and more have arrived then you might as well let the new ones go. However, you should ask why you have a priority system when everything comes in at the same priority.
I think you should take a step back and think about the philosophy of your fault log. Can you afford to miss a fault? How about a low priority one? It depends on your application but my instinct would say that the confirmed faults are what you want to take notice of and, if the log is full of confirmed faults, I would reject new confirmed faults because I think the first few entries would tell you the most about a confirmed fault. However, on the lower priority faults I would only keep the most recent because they may be a result of another more important fault and so are not the main problem.
Google is good for a search. Try "Fault Management Strategy" maybe. Also searching the archives of this group could prove useful.
For a real-world example say I wanted to read a number of files from my MMC card. However, someone has stolen the card to use in their camera (which, incidentally, is why I don't let my system boot without a card in it!). I would get a lot of low priority errors about "file not found" and more high priority errors about "MMC card not found." I would want to know when the first card not found error happened in case the card had crashed half-way through the operation and I could tell which read caused the problem.
However, the file not found errors are not so important unless they happen without another bigger fault to cause it. In that case then I would either be interested in the first occurance or none of them. It is either important enough to handle immediately or not important enough to worry about the fault log order.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.