www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik System Fehlersuche (Hardware oder Software)


Autor: Daniel Duesentrieb (daniel1976d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Halloechen,

ich habe folgendes Problem und komme einfach nicht richtig weiter...

Wir haben eine Black Box (Single Board Computer + Software) mit 2 
digitalen Eingaengen und einem Countereingang. An den digitalen 
Eingaengen haengen zwei Schalter und an dem Countereingang ein Tacho. 
Der Tacho erzeugt ein Rechtecksignal von 2V mit einer Frequenz von 0 bis 
300Hz.

Die Back Box berichtet manchmal und anscheinend auch recht zufaellig das 
die Schalter geoeffnet sind und sich das Fahrzeug bewegt. Dies ist 
jedoch technisch eigentlich nicht moeglich. Dieses Berichten geschieht 
via GPRS und leider steht uns der Report immer nur einen Tag nach dem 
eigentlichen Ereignis (Schalter offen/Fahrzeug bewegt sich) zu 
Verfuegung. Neben dem Report gibt es leider keine weitere 
Schnittstelle...

Wir haben schon mit einem Oscilloskop alle 3 Signale betrachtet und als 
gut befunden... keine uebermaessigen Stoerungen, Rauschen, Pulse...

Nun zum eigentlichen Problem: Unser Hardware Team glaubt die Software 
verursacht das Problem... das Software Team glaubt es ist die Hardware 
(nicht genug Entstoerung, Schalterdefekt, Steckerproblem usw...)

Habt ihr eventuelle Loesungsvorschlaege und Strategien um festzustellen 
woher der Fehler kommt... Sorry es sieht so einfach aus, aber dieses 
Problem plagt uns schon seit Monaten und ich denke beide Seiten sind 
einfach schon blind durch das ewige Draufgucken...

Vielen Dank schon mal im Vorraus... Hoffe auf zahlreiche Antworten und 
Ideen...

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hund, Katze, Maus, ...

Ist jetzt nicht Dein Ernst, oder?

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie jetzt "Black Box"? Sind die Schaltpläne der Hardware und die 
Quelltexte verfügbar oder nicht? Softwarefehler finden ohne dass man den 
Sourcecode hat kann man weitgehend vergessen. Es sei denn es wäre so 
wenig Code, dass man mit einem Disassembler noch zurande kommt.

Autor: ok, dann eben kein "Gast" (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie war das? Ich glaube Zeile 46 im Programmcode ist falsch oder war´s 
doch ´ne andere?

Autor: Daniel Duesentrieb (daniel1976d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider doch...

Haengt auch noch eine Menge firmeninterne Politik dahinter, die ich hier 
aber nicht weiter ausbreiten will... Sagen wir es so, die SW wird sehr 
stark in Schutz genommen...

Autor: HildeK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel Duesentrieb schrieb:
> Schalter offen/Fahrzeug bewegt sich

"Schalter offen" ist immer kritisch - außer der Eingang ist ausreichend 
niederohmig mit einem Pull-R versehen. In welcher Umgebung wird das 
betrieben?

Da ja offenbar die Schalterzustände falsch gemeldet werden, würde ich 
den Eingang für die Schalter probeweise auf das Potential für 'offen' 
hart anklemmen. Wenn die Black-Box innen nicht zugänglich ist, dann nimm 
zur Not eine kleine Batterie, um das Potential für 'offen' (bzw. 
geschlossen) festzuzurren.
> keine uebermaessigen Stoerungen, Rauschen, Pulse...

Quantitativ? Was sind die Definitionen für die Eingänge?


> Nun zum eigentlichen Problem: Unser Hardware Team glaubt die Software
> verursacht das Problem... das Software Team glaubt es ist die Hardware
> (nicht genug Entstoerung, Schalterdefekt, Steckerproblem usw...)

Warum sollte es bei euch anders zugehen?

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann muss eben derjenige den Fehler ausbügeln, der dieses Gerät 
entwickelt hat und Zugang zu den benötigten Informationen hat. Anders 
macht es keinen Sinn, es sei denn man will viele Ingenieursstunden zum 
Fenster rausschmeißen (was das kostet!)

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel Duesentrieb schrieb:
> Leider doch...
>
> Haengt auch noch eine Menge firmeninterne Politik dahinter, die ich hier
> aber nicht weiter ausbreiten will... Sagen wir es so, die SW wird sehr
> stark in Schutz genommen...

Also wirklich ernsthaft?
- Na gut. Hast oder hattest Du Zugriff auf den Quelltext?
- Ist das Problem auf einen Prototypen begrenzt?
- Tritt das Problem im Labor, im Feld oder überall auf?

Ich glaube nicht, daß Dir hier mit den spärlichen Angaben geholfen 
werden kann. Das kann wirklich alles sein, von Brownout bis Elektrosmog 
...

Autor: Daniel Duesentrieb (daniel1976d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke erstmals... Uih das geht aber schnell...

SW komm ich nicht ran... das Program ist auch relativ gross und 
komplex... OS ist WinCE oder Linux...

Schaltplan ist verfuegbar, jedoch konnten wir bisher keinen Designfehler 
entdecken... die Eingaenge haben Pull Up, Schalter werden gegen GND 
geschaltet und das Ganze ist mit einem OptoCoupler realisiert...

Autor: Daniel Duesentrieb (daniel1976d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmals Danke...

Wie gesagt ich habe kein Zugriff auf den Quelltext...
Das Problem zieht sich mehr oder weniger durch ca. 100 Geraete...
Das Problem tritt im Feld auf und konnte im Labor auch nachgewiesen 
werden, jedoch scheint es hier seltener aufzutreten...

OK, die Geraete sind in Bussen eingebaut und manche Fahrzeuge erzeugen 
einige Fehler pro Tag, andere Busse einige Hunderte usw. Jedoch kommt es 
vor das Bus A heute OK ist, eine Woche spaeter anfaengt Fehler zu 
erzeugen und dies in der zweiten Woche wieder abnimmt und soagar auf 
Null geht... Natuerlich kann es sein das der Bus eine andere Route 
faehrt, der Fahrer wechselt usw...

Autor: Hoschi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel Duesentrieb schrieb:
> dieses Problem plagt uns schon seit Monaten

Dann bleibt nur noch, den unwahrscheinlichen bis unmöglichen Dingen 
nachzugehen, wie z.B. der Report kommt gar nicht von der Blackbox etc.

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh weh, Automotive mit 24 V. Eine wirklich häßlich gestörte Umgebung. 
Aber Optokoppler ist ja schon mal da.

Autor: Maxx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Hard von der Software isolieren und einzeln testen:
Der Software einfach mal zufällig die möglichen Events erzeugen und vor 
die Füße werfen. Timings/Reihenfolge bis an die Definitionsgrenzen und 
dann Stresstesten um die Auswertungen mit dem Testmuster vergleichen.

Die Hardware mal mit minimalistischer, nicht vom Orginal abgeleiteter 
Software testen, die sich nur auf den beobachteten Fehlerzustand 
konzentriert und diesen logged.

Und: die Kommunikation im Betrieb mal auf die Reihe bekommen!

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lutz schrieb:
> Oh weh, Automotive mit 24 V.

Allerdings. Oder gehören Lkw und Busse nicht zum Automotive-Bereich?

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht irgendwelche kapazitive Einkopplungen o. ä.:

Beitrag "Pullup-Widerstand Größe ermitteln"

http://www.elektronik-kompendium.de/public/schaere...

Eine störsichere Eingangsschaltung konstruieren ...

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mark Brandis schrieb:
> Lutz schrieb:
>> Oh weh, Automotive mit 24 V.
>
> Allerdings. Oder gehören Lkw und Busse nicht zum Automotive-Bereich?

Klar tun sie das. Die Frage verstehe ich nicht so ganz.

Hoschi schrieb:
> Daniel Duesentrieb schrieb:
>> dieses Problem plagt uns schon seit Monaten
>
> Dann bleibt nur noch, den unwahrscheinlichen bis unmöglichen Dingen
> nachzugehen, wie z.B. der Report kommt gar nicht von der Blackbox etc.

Da ist wirklich was dran. Vielleicht habt Ihr alle nichts gefunden, weil 
da, wo Ihr gesucht habt, auch gar kein Fehler/Problem ist?
Vielleicht erzeugt der unbekannte Sender (integriert, separat, 
Fremdmodul, ...) oder eines dessen Subsysteme einfach mal Quatsch und 
das Problem liegt gar nicht bei Euch?

Autor: Daniel Duesentrieb (daniel1976d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke fuer die vielen Beitraege...

Leider ist das Testen unseres Systems nicht gerade einfach... meist 
liegt unsere Box irgendwo im Bus und ist sehr schlecht zugaenglich...

Hinzu kommt diese hohe Unregelmaessigkeit und dieser Zeitversatz von 
einem Tag fuers Reporting...

Vor einiger Zeit war ich in einem Bus und habe versucht ein paar 
Messungen mit einem zur Blaxbox im parallel angeschlossenen Datalogger 
zu machen... Verbringe also mal eben 4 Stunden im Bus und nehme 
eigentlich zwei Fahrgaesten den Sitzplatz weg ... komm am naechsten Tag 
ins Buero, check den Report und nicht ein Fehler waehrend ich im Bus 
war... davor und danach hatte ich Fehler... super.

Mein Plan war einen unabhaengigen gekauften Datalogger in Parallel zu 
unserer Black Box zu klemmen und nachher beide Reports zu vergleichen. 
Sollte der Black Box Report sagen "Fehler um 17:45:566 kann ich mir den 
Datalogger Report um 17:45:566 anschaun und das Ergebnis bestaetigen 
oder eben nicht... Sollte es nicht gleich sein, so sieht die Black Box 
etwas was nicht da ist... speziell unter dem Gesichtspunkt das der 
Datalogger nur analoge Eingaenge benutzt und diese hochohmig sind und 
die Schaltung insgesamt nicht beeinflussen sollte...

Ach ja, die PullUps sind 1kOhm... Die Rail ist 3.3V... ich weiss die 
Spannung ist eigentlich zu klein (Wetting current), aber auf die HW habe 
ich keinen Einfluss...

Der Tacho geht direkt auf einen Optocoupler mit 560 Ohm 
Serienwiderstand...

Danke nochmals fuer die vielen konstruktiven Vorschlaege...

Autor: Wegstaben Verbuchsler (wegstabenverbuchsler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Mein Plan war einen unabhaengigen gekauften Datalogger in Parallel zu
> unserer Black Box zu klemmen und nachher beide Reports zu vergleichen.

Eine Korrelation des Ereigniszeitpunkts mit der (näherungsweisen) 
geographischen Lokation wird vermutlich keine Erkenntnisse liefern ... 
(z.B. "in der Nähe der Feuerwache xx häufen sich fahrzeug-unabhängig die 
Ereignisse)

Lässt sich denn der Zeitpunkt der Ereignisse denn nicht erst mal in 
einfachster Form mit der Tachoscheibe korrelieren und dort etwas 
rausspekulieren?

Darüber hinaus würde ich beim Datenloggen noch einige weitere 
(vermutlich reicht digitale) Ereignisse mitprotokollieren. z.B. 
anspringende Lüftermotoren (Bürstenfeuer) können ziemliches Gekratze 
verursachen.

Autor: MarioT (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wegstaben Verbuchsler schrieb:
> Tachoscheibe

Fahrerkarte

Wegstaben Verbuchsler schrieb:
> Darüber hinaus würde ich beim Datenloggen noch einige weitere
> (vermutlich reicht digitale) Ereignisse mitprotokollieren. z.B.
> anspringende Lüftermotoren (Bürstenfeuer) können ziemliches Gekratze
> verursachen.

Kleine "Antenne" unabhängig vom Boardnetz.

Autor: oldmax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
Eine Interessante Diskussion. Da wird ein Produkt gefertigt, ist 
Fehlerhaft und die Entwickler sind nicht zuständig.


>Nun zum eigentlichen Problem: Unser Hardware Team glaubt die Software
>verursacht das Problem... das Software Team glaubt es ist die Hardware
>(nicht genug Entstoerung, Schalterdefekt, Steckerproblem usw...)

Ich kenne so ein Verhalten auch, zwar aus einem anderen Bereich, aber 
ist durchaus vergleichbar. Da kann ich nur sagen: Wo ist euer Chef ? 
Hier ernsthaft von Teams zu sprechen ist glaub ich etwas blauäugig. Eure 
"Teams" sind sowas von unkooperativ, die hätt ich schon längst 
ausgetauscht. Mit diesen Kollegen ist keine Zukunft. Fehlersuche ? Was 
ihr da treibt, ist sinnloses gestochere. Du hast keinen Einfluß auf die 
Hardware und kennst die Software nicht...? na toll. Eure 
"Softwareprofis" sind nicht in der Lage, einen Fehler, ausgelöst von 3 
Eingängen, einzufangen und zu behandeln? Ich habe es mit Großanlagen zu 
tun, die auch manchmal ein etwas eigensinniges Verhalten zeigen. Und 
hier wird's bei Störungen richtig teuer. Da ich nicht "probieren" kann, 
muß ich softwaremäßig mir ständig etwas einfallen lassen, um 
Fehlverhalten "einzufangen" und dann entsprechende Maßnahmen treffen. 
Wir haben längst aufgegeben, die Schuld in irgendeiner Abteilung zu 
suchen, sondern arbeiten im Team an Störungen. Alle Beteiligten, ob 
Produktion ( du bist zu blöd um die Maschine zu bedienen) oder Mechanik 
( da ist ein Kabel dran, das ist elektrisch) haben eingesehen, nur 
gemeinsam werden Störungen wirksam behoben. Also, geh zu den 
Softwarefuzzis und rede mit ihnen Klartext. Versucht Routinen 
einzuarbeiten, die Fehlverhalten registrieren und entsprechend in einen 
Fehlerspeicher festhalten. Ich denke da an sowas wie Stacküberlauf, 
unkontrollierter Reset, fehlerhafter Zugriff auf IO, Bausteinkontolle 
usw.
Gruß oldmax

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Selten auftretende Fehler sind immer die teuersten.
Versuche mal Zeit, Ort und Fahrer in einen Zusammenhang zu bringen.
Es gab schon Leute denen fiel z.B. nur im Hafen das Motormanagement aus.

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel Duesentrieb schrieb:
> Sollte es nicht gleich sein, so sieht die Black Box
> etwas was nicht da ist...

Richtige Schlußfolgerung, aber nicht wirklich weiterführend. Es kann 
dann nur sicher festgestellt werden, ob das Problem von Außen über die 
dafür vorgesehenen Eingänge einwirkt oder in der Black Box erzeugt 
werden. Vor allem "stinkt" es ja schon, wenn Daten gesendet werden, die 
technisch gar nicht möglich sein sollen (z.B. Tachsignale nachts bei 
garantiertem Stillstand etc.).

Daniel Duesentrieb schrieb:
> Leider ist das Testen unseres Systems nicht gerade einfach... meist
> liegt unsere Box irgendwo im Bus und ist sehr schlecht zugaenglich...

Du hattest geschrieben, daß es auch im Labor auftritt, wenn auch 
seltener. Also kann man sich da ordentlich unter definierten Bedingungen 
austoben. Wie findet dort die Testschaltung eigentlich statt? Werden 
irgendwelche Simulationen wie Vibrationen, EMV, Spannungsschwankungen 
etc. durchgeführt? Wenn nicht und der Fehler tritt trotzdem auf: Der 
Fehler liegt in der Box und ihr könnt Euch das Gelogge sparen!
Und das der Report nicht vorher abgefangen bzw. ausgelöst werden kann 
ist wie einiges hier absolut nicht nachvollziehbar. Der Hersteller hat 
die besten Möglichekeiten überhaupt; merkwürdig. Auch kann das System 
nicht so wichtig sein, denn wenn Hunderte Boxen über Monate solche 
Macken haben, kann der bzw. die Kunden an den Ergebnissen kein 
wirkliches Interesse haben; das ließe sich ja wirklich niemand gefallen. 
Das würde auch das Verhalten der Eurer Gesamtfirma erklären. Priorität: 
Egal.
Kurzum: Ich tippe auf einen Fehler in der Box selbst, der mit den 
Eingängen gar nix zu tun hat.

Autor: Daniel Duesentrieb (daniel1976d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Halloechen.... erstmal vielen Dank nochmals fuer die tollen 
Kommentare... Ich sollte euch vieleicht ein bischen Hitergrundwissen 
zukommen lassen bezueglich unserer Firma.
Das Projekt wurde von Brisbane aus gesteuert. Hardwareentwicklung wurde 
vergeben und Software wurde in Brisbane gemacht. Die Implementation fand 
jedoch beim Kunden in Melbourne statt. Nach ein paar 
Anfangsschwierigkeiten lief das System relativ rund und der Kunde konnte 
mit diesen Fehlern leben, dann alles andere (GPRS, GPS usw. 
funktionierte zufriedenstellend. Nun moechte der Kunde nun seit ca. 
einem Jahr das die Tuersensoren (Schalter) vernueftig eingelesen werden 
um aus der Oeffnungsdauer die Passagierzahl abzuschaetzen. Also muss das 
nun auch funktionieren...

Ich wurde aufgrund dieses Problems (mit) eingestellt und arbeite in 
Melbourne relativ weit vom Schuss und schlage mich mit dieser Black Box 
rum... Wichtig ist erstmal festzustellen das die Hardware der Busses 
100%ig funktioniert danach kann ich der SW sagen, sorry euer Problem...
Keine Panik, die Kollegen dort sind sehr hilfsbereit und wir verstehen 
uns praechtig aber die Kollegen arbeiten nun an anderen Projekten und 
werden sich der Sache erst annehmen wenn zu 99% feststeht es ist die 
Software ist.

Nochwas... unser System hat eine gravierende Schwaeche und das ist das 
man kaum vernuentig debuggen kann... am liebsten wuerde ich das System 
auf der Werkbank aufbauen und eben mit ein paar Signalen anregen. Um das 
wirkliche Verhalten zu simulieren muesste sich die Black Box jedoch als 
Bus anmelden... mit allen Waypoints, Zeitplaenen usw usw. Will das hier 
auch nicht im Detail erklaeren... Jedoch wuerde an der Bushaltestelle 
mein Simulations-/Werkbankbus auftauchen, der jedoch nicht real 
existiert. Der Fahrgast waere sauer und unser Kunde entsprechend auch... 
Also das Testen unter realen Bedingungen ist nicht ganz leicht...

Nochmals Danke fuer all die tollen Ideen und Kommentare...

Autor: Daniel Duesentrieb (daniel1976d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry ich wollte eigentlich gar nicht so viel schreiben...

Natuerlich haben wir auch bei den Bussen alles moegliche schon 
gefunden... angefangenen von fehlerhaften Druckschaltern an den Tueren, 
zu wenig Druck im Pneumatischen System, losen Draehten, Wacklern usw 
usw. Ganz zu schweigen vom Servicepersonal der Busbetreiber.. die haben 
keine Hemmungen Leitungen die sie nicht kennen einfach zu kappen... Wir 
hingegen erhalten kein Feedback vom Service der Busbetreiber, da dies 
mehr Arbeit fuer diese erzeugen wuerde...

Jedoch ist es auch schon vorgekommen das unser Service einen Bus besucht 
der eine hohe Fehlerrate hat, alle Stecker abzieht und wieder steckt und 
der Fehler war weg...

Nun aber erstmal Schluss fuer heute ... hatte heute einen langen Tag und 
es ist schon wieder 23 Uhr....

Danke nochmals und gute Nacht...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine persönlichen Gedanken:

Da es sich um ein sporadisches, zunächst mal nicht reproduzierbares 
Problem handelt, würde ich erst mal in Richtung
"da tauchen irgendwelche Glitsches an den Eingängen auf, die die SW 
irrtümlich auswertet"
spekulieren.

Das da jetzt eindeutig SW oder HW zuzuordnen, ist m.E. eine Sackgasse. 
Wenn die Annahme stimmt, kann man das sowohl in Hardware als auch in 
Software lösen. So eine Bustür ist ja nicht gerade ein schnellebiges 
Ding. D.h. ein 0.5 Sekunden geöffnete Tür kann niemals real sein.

Die Softwarefuzzis könnten das ausbügeln, indem sie möglicherweise 
bessere Plausibilitätstests einbauen. Die Hardwarefuzzis könnten das 
ausbügeln, indem sie eine Verzögreung oder eine Glättung des Pulses 
einbauen oder sonst irgendwie dafür sorgen, dass ein entsprechend kurzer 
Impuls nicht bis zum µC durchdringt. Sie könnten auch versuchen die 
Ursache für die Spikes zu finden und diese zu eliminiern etc.

Das alles hilft dir aber nichts, solange es dir nicht gelingt, die 
Abteilungsleiter der Bereiche mit ins Boot zu holen, damit sie dir 
Manpower aus ihrem Bereich zur Verfügung stellen. Du hast ein 
Himelfahrtskommando.

Autor: Daniel Duesentrieb (daniel1976d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Karl heinz Buchegger,

Hab mir doch noch ein Bier ausm Kuehlschrank geholt... Ich versteh deine 
Argumentation wie aber oben beschrieben steht die Hardware und auch die 
Software wird erst geaendert/verbessert wenn ich die HW zu 100% als 
Fehlerquelle ausschliessen kann.

Mir ist klar das ein Low Pass Filter, over voltage protection und ein 
einstellbarer Komparator usw toll waere, jedoch ist das vom Management 
nicht wirklich gewollt. Das Projekt ist ja jetzt schon nicht mehr 
wirklich im Budget...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel Duesentrieb schrieb:
> Hi Karl heinz Buchegger,
>
> Hab mir doch noch ein Bier ausm Kuehlschrank geholt... Ich versteh deine
> Argumentation wie aber oben beschrieben steht die Hardware und auch die
> Software wird erst geaendert/verbessert wenn ich die HW zu 100% als
> Fehlerquelle ausschliessen kann.
>
> Mir ist klar das ein Low Pass Filter, over voltage protection und ein
> einstellbarer Komparator usw toll waere, jedoch ist das vom Management
> nicht wirklich gewollt. Das Projekt ist ja jetzt schon nicht mehr
> wirklich im Budget...

Ist schon klar.
Nur wie willst du die Ursache finden, wenn alles was du hast eine paar 
fehlerhafte Reports sind?

Du bist in meinen Augen schon den richtigen Weg gegangen: In die 
Blackbox hineinschauen und an zentralen Stellen die Signale überwachen.
Ich seh das eigentlich als so ziemlich die einzige Chance an, die dir 
bleibt: Das Testequipment so zu automatisieren, dass es ein paar 
Tage/Wochen mitfahren und protokollieren kann.

Autor: Flo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal so als Frage:
Was wäre denn die vom Betrieb gewünschte Feststellung von dir?

a) Diese Fehler sind durch kosmische Störstrahlung verursacht, da kann 
keiner was für. (Firma glücklich und zufrieden, der liebe Gott ist 
schuld)

b) Die Hardware ist fehlerhaft. (Macht dann das Softwareteam überhaupt 
irgendwas, oder sagen die dann, wir habens ja gesagt...)

c) Die Hardware ist fehlerfrei. (Die Softwaremenschen fangen unter 
Gestöhne an, die Softwarefehler zu finden)
...


Mein Gedanke:
Fuzzy-Logik in der Backbox und das Programm ist ein Zufallsgenerator, 
deshalb wollen die dir nichts zeigen. :D

Autor: Sven K. (svenk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was sieht man im Report ?
Kann man den Fehler nicht so eingrenzen,
im Report steht zB.

- Tür zu.
- 300ms Tür auf.
- Tür wieder zu......

Oder Bus steht und parkt.
- Bus tacho Signal 500ms aktiv
danach Bus parkt.

Mögliches Szenario:

Bus parkt an der Strasse und schwerer Viehtransport donnert
mit 3 oder 4 ;-) Anhängern und mehr als 90km/h am Bus vorbei.

d.h. wie lange sieht man diesen Fehler ?

dann könnte man doch einfach mit einer Software
Änderung das Problem beheben.

Gruß Sven

Autor: Wegstaben Verbuchsler (wegstabenverbuchsler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das ist vermutlich so wie mit dem Tastenprellen:

Man kann es per HW oder per SW beseitigen, aber eigentlich keiner der 
beiden Entwicklungsteams die "Schuld" zuweisen, daß da was nicht richtig 
funktioniert weil eine Taste prellt. 99% der Tasten prellen nun einmal 
und müssen entprellt werden ....

Autor: Daniel Duesentrieb (daniel1976d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen...

@Flo: OK am liebsten waere allen ich finde ein Hardwareproblem... sagen 
wir mal Noise an den Eingaengen und ein Quickfix (Kondensator) an 
besagten Eingaengen loest das Problem. Diese Kondensatoren wuerden dann 
im Laufe der Zeit waehrend der regelmaessigen Wartungsarbeiten 
hinzugefuegt... Voila...

2. schlimmster Fall: Softwareproblem

3. schlimmster Fall: die HW muss modifiziert werden. Man koennte ja die 
Eingaenge sehr viel robuster machen z.B.

4. der Supergau 3 und 4 :)

@Sven: Es gibt verschiedene Reports. Einen fuer GPS Empfang, einen fur 
den Fahrkartenautomaten, einen fuer die Tueren usw. Im Tuer Report steht 
"Front Door Error, Zeit" und "Rear Door Error, Zeit" das ist alles... 
also nicht viel... klar waere es schoen den Report aufzublasen z.B. 
Position, Geschwindigkeit usw. aber da wollen die Herren ja nicht ran...

@Wegstaben Verbuchsler:

Die Schalter werden alle 500ms abgefragt, falls 4 mal hintereinander 
HIGH erkannt wird werd der interne Tuerstatus auf HIGH gesetzt.. das 
selbe fuer LOW... Der Tacho geht auf einen Pin der einen Interrupt 
ausloest, es wird ein Zaehler inkremitiert und der Wert jede Sekunde 
abgefragt und dadurch die Geschwindigkeit ermittelt. Als Zeitbasis wird 
das empfangene GPS Telegram verwendet das dies jede Sekunde aktualisiert 
wird...

Danke nochmals fuer die vielen interessanten Kommentare... werde euch 
auf dem Laufenden halten... :)

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich das so lese würde ich erst mal mechanische Ursachen genauer 
untersuchen:
-Klemmen z.B. Türen oder schließen die Schalter ohne ausreichenden 
Überhub? (Überhub ist die mechanische Sicherheitsreserve, daß der 
Schalter mehr geschlossen ist als zur Kontaktgabe nötig wäre.)

-Ein Tacho, der bei jeder Umdrehung einen Impuls gibt, ist gesund. Wer 
weiß aber, ob der nicht zufällig GENAU auf dem Auslösepunkt steht und 
zufällig bei Erschütterung eine Haaresbreite vor oder zurück bewegt 
wird?

-Was sagt die Betriebsspannung während dieser Zeit? z.B. Kühlschrank an?

Autor: Sven K. (svenk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Daniel,

schade dann kann man ja leider mit den Reports nicht so viel machen.

> Die Schalter werden alle 500ms abgefragt, falls 4 mal hintereinander
> HIGH erkannt wird werd der interne Tuerstatus auf HIGH gesetzt.. das
> selbe fuer LOW...

Bist Du sicher das eine Entprell-Routine eingebaut ist ?
Ohne Böses zu unterstellen, aber wenn die Abfrage
einfach nur den PIN min. 4 mal alle 500ms abgefragt
werden, könnte ja durchaus bei einer Störung
genau zu den Zeitpunkten

t
|-------|-------|-------|-------|
Signal
|------|||------|------||-------|||

eine Meldung erfolgen.
Das ganze tritt so sporadisch auf, das Du das Verhalten
möglicherweise nicht gesehen hast....

Gruß Sven

Autor: Flo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel Duesentrieb schrieb:
> OK am liebsten waere allen ich finde ein Hardwareproblem... sagen
> wir mal Noise an den Eingaengen und ein Quickfix (Kondensator) an
> besagten Eingaengen loest das Problem. Diese Kondensatoren wuerden dann
> im Laufe der Zeit waehrend der regelmaessigen Wartungsarbeiten
> hinzugefuegt... Voila...

Schon probiert, vielleicht bei einem Testgerät die Kondensatoren 
hinzubasteln?
Ist zwar nur Symptom- und keine Ursachenbekämpfung aber deine 
Chefs/Kollegen wollens doch nicht anders?

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum seid Ihr so sicher, daß es keine mechanischen Ursachen sind?
Eine Bustür rüttelt und dehnt sich bei Sonne z.B. auch aus.
Mein kuriosester Fall war eine Garagentür, die sich bei Feuchtigkeit 5mm 
verzogen hat und damit Alarm auslöste...

Autor: Daniel Duesentrieb (daniel1976d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also die Sache mit den Kondensatoren ist schon probiert worden und hat 
nichts am Ergebnis geaendert. Auch wurde ein Odometer Verstaerker bei 
einigen Bussen verwendet. Es wurde danach nicht besser und auch nicht 
schlechter...

Die Turen verwenden Pneumatische Schalter und wir haben mit nem Oscar 
nach Problemen mit den Schaltern gesucht (nicht ausloesen, Vibration 
usw.) alles gesund. Selbst Stoereungen die ich erwartet haette sind sehr 
gering, da wir den Schalter selbst versorgen und auch das GND zur 
Verfuegung stellen. Lediglich der Odometer Sensor ist wirklich kritisch 
da er irgendwo im Fahrzeug sitzt und eben nur das Signal zu uns gefuehrt 
wird ohne das dazugehoerige GND.

@Sven K:
Ja das koennte wirklich der Fall sein. Gestern habe ich einen 
Datenlogger im Bus verwendet und werde das mal gleich auswerten. Soweit 
ich das aber sagen kann ist die Versorgungspannung stabil wie Beton und 
die Schalter funktionierten wunderbar...

@oszi40: Danke fuer den Kommentar mit dem auf der Kipe stehen... jedoch 
koennen wir das relativ sicher ausschliessen da die Busse nur diese 
Berichte generieren wenn sie in Betrieb sind (heist sie sind auf ihrer 
Servive Route und fahren). Den Effekt habe ich bisher nie beobachten 
koennen...

Danke nachmals

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Ich hab schon öfters erlebt, dass ein Bus trotz geöffneter Tür gerollt 
ist.
(Beobachtungsstätte BERLIN!!)

Ist es auszuschließen das es am Fahrer liegt bzw. was verhindert den Bus 
am rollen, wenn eine oder mehrere Türen geöffnet sind ?

MfG

Autor: Daniel Duesentrieb (daniel1976d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke fuer den Tip...

War gestern mit einem der Busse unterwegs und als ich dort war wurden 
keine Fehler registriert. Ich habe welche zur Kontrolle provoziert aber 
waehrend der ca. 3 Stunden nicht ein Fehler... Hatten gestern jedoch 
auch Pech das es sich um einen Expressbus gehandelt hat und der nur alle 
30 Minuten mal stoppt.. :(

Ja das koennte auch der Grund sein. Im Depot wird mit offenen Tueren 
gefahren und das kann ich sogar beweisen.. selber gesehen.. selber schon 
gemacht..
Nun koennte es auch sein das wenn ich an Bord bin der Fahrer einfach 
anders faehrt...

Neuere Busse kann man nicht mit offenen Tueren fahren, jedoch habe ich 
gestern gehoert das das Service Personal diesen Mechanismus ausschalten 
kann, super macht die Sache wieder schwieriger...

Rollen und langsames Fahren sollten keine Fehler ausloesen, da wir einen 
10km Limit haben. Alles unter 10km sollte keinen Fehler erzeugen...

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die seltenen Fehler sind die leider teuersten.
Nimm Dir einen Probanten wo der Fehler öfter auftritt und ersetze dort 
den betroffenen Schalter durch eine Drahtbrücke am Rechner. Wenn es dann 
noch auftritt, ist es zu 60% die Software.

Autor: oldmax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Daniel

>Das Projekt wurde von Brisbane aus gesteuert. Hardwareentwicklung wurde
>vergeben und Software wurde in Brisbane gemacht. Die Implementation fand
>jedoch beim Kunden in Melbourne statt. Nach ein paar
>Anfangsschwierigkeiten lief das System relativ rund und der Kunde konnte
>mit diesen Fehlern leben, dann alles andere (GPRS, GPS usw.
>funktionierte zufriedenstellend. Nun moechte der Kunde nun seit ca.
>einem Jahr das die Tuersensoren (Schalter) vernueftig eingelesen werden
>um aus der Oeffnungsdauer die Passagierzahl abzuschaetzen. Also muss das
>nun auch funktionieren...

Na ja, das ist kein leichtes Brot.... Schlamperei von gestern 
aufzuarbeiten ohne das dafür jemals einer Danke sagen wird.
 An dieser Stelle will ich  mein Posting nicht wiederholen, aber auch 
wenn die Kollegen nett sind, einen Erfolg werdet ihr nur haben, wenn 
eine gemeinsame Bereitschaft besteht, gegen einen Fehler anzugehen. Die 
Aussge "Schließ erst mal Hardwarefehler aus, dann machen wir weiter" ist 
schlichtweg eine Frechheit. Welche Möglichkeiten hast du denn? Mit einem 
Schreiber die Türkontakte und das Tachosignal mitzuschreiben und auf 
kritische Zustände zu überprüfen. Ehrlich meine Meinung ? Wenn ihr das 
ausbügeln wollt, dann Soft- und Hardwareteam an einen Tisch und 
gemeinsames brainstorming. Vielleicht ist's gar nicht so schwer, 
Kontrollfunktionen in die Software zu bringen und durch 
Analysefunktionen eine Fehlerbehandlung in der Blackbox durchzuführen.
Aber wenn ich da lese, das Budget ist schon verbraten und jetzt sucht 
man einen "Dummen", der alte Schlamperei ausbügelt, am besten für 
nothing...
na ja.
Tschuldige die harten Worte, aber was nutzen Schmeicheleien....
Gruß oldmax

Autor: Daniel Duesentrieb (daniel1976d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke nochmals auch fuer die harten Worte...

Ach ja, noch eine Sache die ich kurz berichten wollte. Vor einer Woche 
haben wir bei einigen Bussen die Tuerkontakte ueberbrueckt... Voila, 
keine Fehlermeldungen mehr...

Nun doch HW? Oder doch die Software und Tuertask und Odometertask sind 
nicht synchronisiert... Noch eine Moeglichkeit waere der Busfahrer 
selber...  einige der Busfahrer brauchen ja nur mit offener Tuer 
rollen...

Wir haben heute einen weiteren Versuch gestartet und bei einigen Bussen 
die Geschwindigkeitsgrenze von 10km/h auf 20km/h erhoeht... Sollte es 
sich um gleichverteilte Tuerschalterfehler handeln sollte sich die 
Anzahl der Fehler nicht veraendern, oder?

Werde euch auf dem Laufenden halten...

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Viele Fehler haben mechanische Ursachen. Entweder 
Kontaktfehler/Prellen/kein Überhub oder evtl. Kondenswasser/Druckabfall 
im Luftkanal?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel Duesentrieb schrieb:
> Nun zum eigentlichen Problem: Unser Hardware Team glaubt die Software
> verursacht das Problem... das Software Team glaubt es ist die Hardware
> (nicht genug Entstoerung, Schalterdefekt, Steckerproblem usw...)


Früher hat man gerne mal viel in Hardware gegossen, das ist aber sehr 
aufwendig und unflexibel.
Daher erwartet man heutzutage von der Software, daß sie mit Signalen aus 
dem realen Leben zurecht kommen muß.
Und ich bin der Meinung, zu recht.

Die Rechenleistung ist da und auch die bewährten Programmierlösungen.
Ich stehe daher auf dem Standpunkt, es ist zu 99,9% ein Softwareproblem.

Frag die Leute mal nach "Debounce", "Atomic", "Volatile".
Wenn sie eins davon nicht kennen, dann ist es ein Softwarefehler.

Viele können auch nur ein "poor-mans debounce" (= Delay), das ist 
Lichtjahre weit von einem professionellen Debounce entfernt. Es gibt 
fast nichts, was noch schlechter funktioniert.


Peter

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter was nützen 1000 Prozessoren wenn z.B. der Druckschalter nur 
halb schließt?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oszi40 schrieb:
> Hallo Peter was nützen 1000 Prozessoren wenn z.B. der Druckschalter nur
> halb schließt?

Halb gibt es nicht. Entweder die CPU liest 0 oder 1 ein.

Es ist natürlich möglich, daß in einem Fahrzeug durch Erschütterungen 
ein geschlossener Kontakt kurz mal öffnet. Oder durch Schalten einer 
Last auf dem Bordnetz die Spannung kurz einbricht.
Daher ist eben das Entprellen nicht nur beim Schließen, sondern auch 
beim Öffnen wichtig. Das wird leider in vielen Anwendungen vergessen, 
weil die Softwerker sowas nicht lernen.

In der Realität sind alle Signale störbehaftet und die Software muß die 
Störungen herausfiltern.
Die Hardware muß die Signale nur soweit aufbereiten, daß eine sichere 
Unterscheidung zwischen Störung und Signal möglich ist.


Peter

Autor: oldmax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
Wenn es um die Erkennung der Türkontakte geht (kopfschüttel...) wie 
lange  muß ein Kontakt mindestens öffnen/ schließen, um eine offene Tür 
anzuzeigen ? Ich versuch mir grad vorzustellen, wie eine Bustür für 1 
Sekunde öffnet und schließt( eine Ewigkeit für einen Controller ), und 
ein Softwareanlalyseprogramm daraus die zu- oder ausgestiegene 
Personenzahl ermittelt....... Also, ich würd mich nicht trauen, glaub 
ich, dieses Ergebnis jemandem zu präsentieren. Aber natürlich kann man 
ja noch eine Menge Stunden damit zubringen, das Ganze zu analysieren. Da 
gibt's rollende Busse, weil die Strecke leichtes Gefälle hat, schlechte 
holprige Straßen, undichte Türgummis, schwergewichtige Fahrgäste, die 
beim Betreten des Türbereiches leichte Beben erzeugen .... , viel Spaß
gruß Oldmax

Autor: Hauke Sattler (hauke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vorschlag:
Baue einen Logger (kleinen ATmega auf 3,3V) in die Blackbox.
Logge direkt an der Blackbox CPU die Zustände der Tür-IO-Pins und 
Tacho-Pins
Schneide die GRPS Daten von der Blackbox mit und werte die noch im 
Logger nach unmöglichen Zuständen aus.
Lass eine Wartungs/Kontroll-Leuchte anzeigen, wenn ein Fehlerevent 
detektiert wurde.

Warum das ganze?
Es wäre interessant zu wissen was die Blackbox-CPU selber für Signale 
bekommt. (Also nach!!! der HW-Signalaufbereitung)
Du kannst von außen sehen (bzw. wirst benachrichtigt) wann und unter 
welchen Umständen der Fehler kommt.

Dann dürfte es eigentlich nur noch drei mögliche Ergebnisse geben:

Es kommt kein Fehler mehr:
Super Problem gelöst 8-P
(OK Ingenieurstechnisch unbefriedigend aber dafür rechnungstechnisch)

Es wird ein Fehler gemeldet ohne das IO-Pin-Events auftraten:
Die Bitschubser antreten und auf Käferjagd gehen lassen.

Es wird ein Fehler gemeldet uns gab passende IO-Pin-Events:
Den Leiterbahnflechtern sagen, dass sie ihre Lötkolben anheizen können.


Ich weiß natürlich nicht ob das in deinem Fall so geht, aber ich hoffe 
trotzdem, dass es dir hilft.

cu
Hauke

Autor: oldmax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
@Hauke Sattler
Nun, dein Vorschlag ist gut, aber dann hat auf jeden Fall Daniel den 
schwarzen Peter, denn er muß der Soft- und der Hardware-Elite 
nachweisen, das seine Soft -und Hardware ! fehlerfrei arbeitet. Der 
Punkt ist doch, es gibt ein System, welches von Anfang an Macken hatte. 
Wie immer hat's den Kunden (noch) nicht interessiert und den Hersteller 
dazu veranlaßt, auch nix mehr zu tun. Bis dann plötzlich aus ganz 
wichtigen Gründen diese Macken nicht mehr akzeptabel sind. Und statt 
alle an einen gemeinsamen Tisch zu holen und alle in die Verantwortung 
zu ziehen, darf so ein armes Schw... wie Daniel nun sein Talent 
beweisen.
Meine ehrliche Meinung dazu:
Daniel, rede mit deinen Chefs, das du den runden Tisch willst und alle! 
sich eingebunden fühlen, bzw. das ihnen bewußt wird, wenn sie Qualität 
liefern wollen, muß das Gerangel Software - Hardware aufhören und 
Lösungen müssen auf den Tisch.
Es sind bereits Vorschläge in die Richtung gekommen, das die Software 
ein leichtes damit haben sollte, herauszufiltern, welches gute und 
schlechte Informationen sind. Wenn ich eine Plausibilität auf 1, 2 oder 
vielleicht sogar 5 Sek setzen kann, verdammt noch mal, da wird doch ein 
Softler kein Problem mit haben, das nebenbei beim Kaffeetrinken 
hinzubiegen. Stunde Einsatz und gut is. (erst mal) Es sei denn, ich hab 
das Problem völlig falsch verstanden, aber dann können wir noch 
monatelang rätseln.....
Gruß oldamx

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist ja ein ziemlich langer Thread.

Also die 4-fach Abtastung auf beide Kontaktflanken halte ich prinzipiell 
für ausreichend.
Im KFZ hatte ich aber noch keine Anwendung. Da könnten schon durch 
Erschütterungen und Resonanzen höhere Anforderungen bestehen.
Es sollte auch kein großer Aufwand sein, die Anzahl zu erhöhen.

Bauchschmerzen hätte ich bei der Kontaktspannung von nur 3,3V. 
KFZ-Kontakte sind leider oft sehr billig aufgebaut, da wären 12..24V 
besser.

Zum Testen könnte man auch einfach 2 Geräte in einem Bus parallel an die 
Kontakte legen. Da ja ein OS drauf läuft, sollte ein SW-Bug nicht bei 
beiden exakt gleichzeitig auftreten. Zusätzlich das eine erst etwas 
später einschalten.


Peter

Autor: Hauke Sattler (hauke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Oldmax

Daniel hat leider so oder so den Schwarzen Peter.
Er soll doch den Fehler finden.
Und Support von den Entwicklern bekommt er erst, wenn er einer der 
beiden Gruppen einen Fehler nachweist.
Und im Gegensatz zu den Entwicklern, kann er seinen Logger in HW wie SW 
Quelloffen für die Entwickler auslegen. Wenn dann die HW oder SW Elite 
ihm einem Fehler vorwerfen, dann müssen die Ihm den auch aufzeigen 
können.
Gesetz dem Fall der Logger wäre Fehlerfrei, hätte er eine serh viel 
stärkere Position zum argumentieren. Momentan hat er nur das, welches er 
durchs "Herumstochern" zufällig heraus gefunden hat.

cu
Hauke

Autor: Daniel Duesentrieb (daniel1976d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke nochmals fuer die vielen Kommentare...

OK, das mit dem uC parallel zum eigentlichen Prozessor ist nicht ganz 
einfach... die digitalen Eingaenge werden 1-8 multiplext und die Kiste 
in der das Ganze sitzt ist relativ klein und daher wuerde das Ganze 
ziehmlich frickelig plus das ich nachweisen muesste das das funktioniert 
HW & SW...
Daher meine Idee mit der wenigstens gekauften HW. Sw habe ich selber in 
LabVIew geschrieben... aber wirklich das einfachste vom einfachsten... 
Lese die Pinne und den Counter, Urhzeit dran und dann alles in eine 
Datei speichern... voila...

Wie schon erwaehnt oeffnet und schliesst so eine Tuer in ca. 1 
Sekunde... also nichts dramatisches, eigentlich...

Nun habe ich jedoch heute ein paar neue Erkenntnisse gewonnen...

1) Es gibt wirklich ein SW Fehler... Bei hoher Beschleunigung der Busses 
kann es zu einem Fehlern kommen... mein Benchtest hat das gezeigt und 
unser SW Mann hat das auch schon bestaetigt... :)

Ach ja, der Benchtest benutzt eine IO Karte die das Schliessen der 
Tueren und den Tacho simulieren. Mein Program faehrt ein zufaelliges 
Profil und wenn der Bus zum Halten kommt oeffne ich die Tueren, warte 
ein paar Sekunden, schliesse die Tueren und fahre dann wieder los...

2) Ich habe ein Kabel von unserem Zulieferer entdeckt welches falsch war 
und kein GND fuer den Tacho zur Verfuegung gestellt hat... leider haben 
wir bisher nur eins gefunden...

3) Am Freitag habe ich meine HW/SW in einem der Busse benutzt und 
geloggt... ich konnte keine Fehler sehen, jedoch der Fehlerreport von 
Freitag zeigt eindeutig Fehler... ich mochte das jedoch nochmal 
wiederholen um wirklich sicher zu sein...

Fuehl mich wie in
http://de.wikipedia.org/wiki/Die_haarstr%C3%A4uben...

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel Duesentrieb schrieb:
> 3) Am Freitag habe ich meine HW/SW in einem der Busse benutzt und
> geloggt... ich konnte keine Fehler sehen, jedoch der Fehlerreport von
> Freitag zeigt eindeutig Fehler... ich mochte das jedoch nochmal
> wiederholen um wirklich sicher zu sein...

Wenn Deine HW z.B. resistentER gegen Störimpulse ist, werden die Fehler
in der Black Box trotzdem nicht einfacher. Es könnte an ungünstigen 
Eingängen, Bordnetz oder an der SW liegen ...

Wenn die Kontakte gebrückt waren, traten ja auch keine Fehler auf. Meine 
Glaskugel meint: erst mal beim schlimmsten Fall die Kontakte tauschen 
und deren Beschaltung genauer ansehen.

Autor: Daniel Duesentrieb (daniel1976d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Idee mit den zwei parallelen Geraeten ist gut jedoch geht das leider 
nicht so einfach... ein Geraet representiert einen Bus.. zwei Geraete 
representieren zwei Busse... heisst mit anderen Worten an der 
Bushaltestelle werden zwei Busse direkt hintereinander angezeigt... 
ansonnsten eine gute Idee...

Autor: Daniel Duesentrieb (daniel1976d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach noch was... wir haben ein neues Geraet (neue Generation von HW) und 
auch dies erzeugt Fehler...

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>zwei Busse direkt hintereinander angezeigt

Wie wird das Signal zur Anzeige gesendet? Funk?

2. Antenne durch einen Ersatzwiderstand  z.B. Dummy 
http://www.funkbox.ch/images/MFJ-260C.jpg ersetzen, würde die Abstahlung 
unheimlich verringern.

Sollte etwa ein Funksignal die Eingänge zustopfen?

Autor: Fabian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem tritt auf, wenn der Bus Hupt!

Autor: Hauke Sattler (hauke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Daniel
Das mit den Gemultiplexten Eingängen sollte eigendlich kein Problem 
darstellen. Entweder nimmt man das noch vor den Multiplexern ab, oder 
man nimmt die Steuerungausgänge vom Multiplexer noch mit hinzu.
Hardwaremäßig muss das nicht aufwändig sein. Einen ATmega mit 'nen paar 
Abblock-Cs. z.B. nen Mega128A oder nen Mega1284
(Haben beide 4kB eeprom, letzteren gibt es sogar als PDIP.)
Softwareseitig das KISS Prinzip einhalten. Keep It Stupid Simple.
Eingänge pollen, auswerten, und gegebenenfalls in EEPROM speichern.

bis dann
Hauke

Autor: Daniel Duesentrieb (daniel1976d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Die Geraete senden vie GPRS die Informationen zum Backend. Wenn nur ein 
Geraet eine Antenne haette so wuerde sich das Geraet ohne Antenne 
ueberhaupt nicht anmelden und auch keinen Fehlerreport senden...

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur mal so als Idee:

Dass dein Testsystem als eigener Bus auf der Anzeige erscheint lässt 
sich sicherlich verhindern. Ich bin sicher, dass es eine Vorkehrung 
gibt, dass Busse im "Testsystem" laufen und nicht auf den Anzeigen 
erscheinen. Erkundige dich doch mal. Eine "hartverdrahtete" Anzeige gibt 
es doch bei den heutigen softwarebasierten Systemen nicht mehr...

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sicher wird der Bus sich mit einer ID am System melden, die man 
irgendwie mit SW am Zentralrechenr ausfiltern könnte bevor was angezeigt 
wird.

Große Frage ist aber, ob bei Parallelschaltung der 2 Boxen der Fehler 
überhaupt noch auftritt, da sich z.B. Leitungskapazitäten und andere 
Werte ändern werden. Ein guter Ingenieur müßte den verdächtigen Wert 
herausmessen, mindestens aber vergleichen können.
Sind die Leitungen zur Blackbox abgeschirmt? Rostige Masseverbindungen??

Autor: Daniel Duesentrieb (daniel1976d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo... wollte mich kurz noch mal melden...

Wir arbeiten gerade daran das wir ein Testgeraet ueberhaupt mal dazu 
bringen sich im Backend anzumelden... sozusagen als erweiterter 
Benchtest mit GPS Feed usw... Das kann sich dann wirklich im System 
anmelden... Mal schauen ob das GPRS Modem irgendetwas komisches macht 
bzw verursacht...


Am Mittwoch bin ich mit einem alten Bus mitgefahren... Am Donnerstag kam 
dann der Fehlerreport... 17 Fehler, wobei ich 12 mit meinem Logger 
bestaetigen konnte... Der Fahrer hat einfach die Tuer schon weit vor der 
Bushaltestelle geoeffnet... die andere Fehler traten vor meiner Mitfahrt 
auf...

Jedoch hatte ich im Fehlerreport auch einen Bus der es gar nicht erlaubt 
mit offenen Tueren zu fahren... Ist die Tuer auf kann man nicht 
losfahren, faehrt man gehen die Tueren nicht auf...


Ich bin nun soweit das ich den Herren Management einen ordentlichen EMV 
Test vorschlagen werde... mehr Richtung Immunity... Die Ganze Testerei 
im Bus... wir koennen gar nicht alle Faelle durchgehen... solange der 
Bus normal faehrt sehen alle Signale gut aus, aber was passiert wenn der 
Bus Rueckwaerts faehrt, blinkt, hupt, hupt und dabei rechts abbiegt, die 
Klimaanlage angeht, die Heizung angeht, der Fahrer das Radio anschaltet 
usw. usw. Das ist wie die Suche im Heuhaufen... und ist ja nicht so das 
wir permanent einen Bus haetten und einen Fahrer... nein wir muessen 
immer ins Depot, unser Equipment aufbauen und dann einfach mitfahren... 
wobei ich nicht mal eben sagen kann Fahrer mach mal dies mach mal das... 
plus das er auch nicht auf alle Dinge des Busses direkten Einfluss 
hat...

Was denkt ihr?

Autor: Hauke Sattler (hauke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wow,
Ein professionelles Gerät für den Einsatz in kommerziellen 
Kraftfahrzeugen ohne EMV Test zu vertreiben. Das nenne ich mutig. Also 
wenn ihr das noch nicht gemacht habt, dann ist es WIRKLICH sinnvoll das 
jetzt nachzuholen.

cu
Hauke

Autor: Daniel Duesentrieb (daniel1976d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja das ist wirklich mutig... Ich arbeite ja in Australien und ich muss 
sagen die Damen und Herren hier haben ein sehr grosses 
Selbstbewusssein...


Das Schreckliche ist das wir nun schon das Geraet in der zweiten Version 
haben und der Fehler tritt immer noch auf.... Die erste Generation wurde 
von einer kleinen Elektronikbude entwickelt... die zweite Generation 
wurde nun von einem grossen rennomierten Unternehmen entwickelt...

Wenn wir schon dabei sind werd ich direkt auch einen Vibrationstest 
vorschlagen... ich glaube da liebt auch was im Argen...

Autor: Hauke Sattler (hauke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Evt. wäre auch ein Klimatest zu empfehlen.
Ich war noch nicht in Australien, und ich weiß nicht wo genau ihr die 
Dinger einsetzt. Aber ich glaube gehört zu haben das in Wüstengebieten 
die Temperaturunterschiede zwischen Tag und Nacht extrem sind. Oder 
falls ihr an der Küste seid, dann tut salzhaltige Luft auch ihr übriges.

Falls dann das ganze noch in rohS Produziert ist dann ist das richtig 
witzig in Bezug auf kalte Lötstellen.

cu
Hauke

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein EMV-Test könnte auch ein glatter Durchfaller werden. Wie hier schon 
im Forum zu lesen war, gibt es auch gute Tester, die nützliche Hinweise 
zur Fehlerbehbung haben und die meisten Sünden schon vorher kennen.

ERSTE kleine eigene Forschungen mit Wagnerschem Hammer oder einem 
modifiziertem Piezo-Feuerzeug sind bestimmt nützlich, um die gröbsten 
Fehler schon vorher abstellen zu können. Wenn da schon was faul ist, 
kannst Du sicher sein, daß die Baustelle etwas größer wird.

Autor: shaun (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
EMV schön und gut. Die Hardware sollte vor äusseren Einflüssen soweit 
geschützt werden, dass keine Betriebsparameter verletzt werden. Aber die 
Plausibilität eines Events zu prüfen obliegt in einem softwaregestützten 
System doch eher der Software.
Aber in so einem Umfeld - A schimpt B und umgekehrt und C, der keine 
Ahnung von beidem hat, nimmt einen von beiden in Schutz. Dass Ver.2 von 
einer "renommierten" Firma dieselben Fehler hat wie die Version aus der 
"Bude" lässt nur wenige Schlüsse zu: renommierte Firma hat einfach das 
Design mit seinen Schwächen abgekupfert, der Fehler steckt bereits im 
System oder die haben ihre Hausaufgaben auch nicht gemacht.

Autor: Anja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel Duesentrieb schrieb:
> die haben
> keine Hemmungen Leitungen die sie nicht kennen einfach zu kappen...

Verstehe ich das richtig: Da wird eine Sensor oder Aktor-Leitung 
abgeschnitten und Eure Steuerung macht keinen Fehlerspeichereintrag 
"Sensor XY open load" ?

Wenn dem so sein sollte seid Ihr noch weit von der Serie entfernt.

Gruß Anja

Autor: Hauke Sattler (hauke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde so etwas nicht abkupfern nennen.
Kann ja genauso gut sein das die die Version 1 einfach nur 
weiterentwickeln sollten. Es gilt ja eigentlich "Never change a running 
system". Nur das der Krempel anscheinend noch nie zu 100% funktioniert 
hat.
Eine renommierte große Firma macht im Prinzip auch nur das was bestellt 
bzw. bezahlt wird. Deshalb würde es mich nicht wundern, wenn die sich 
einfach so eine  Baustelle nicht ans Bein binden wollten.

cu
Hauke

Autor: Daniel Duesentrieb (daniel1976d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke fuer die wertvollen Kommentare...

Das Geraet der 1. Generation wurde vor geraumer Zeit entwickelt aber nie 
wirklich getestet (EMV, ESD, Klima, Vibration)...

Die 2. Generation wurde von NEC entwickelt und auch hier bin ich mir 
sicher das keine oder wenn nur wenige Tests durchgefuehrt wurden... werd 
da mal nachhacken... dia haben das Design nicht abgekupfert, da schon 
eine menge Aenderungen eingeflossen sind...

Ich kenn das ja bisher auch nur so... Prototype, Funktionstest, 
Software, neuer Prototype aus der Produktion und dann die ganze 
Breitseite an Tests... und immer wieder ein paar Samples aus der 
Produktion nehmen und wieder testen und nochmals testen... in der 
Produktion natuerlich auch schnell noch mal InCircuit Test und End of 
Line Test...

@Anja... sorry ich muss jetzt ein wenig lachen.. So schlau war da keiner 
das vorzusehen... Man muss ja auch sagen das hier in Australien 
(Melbourne) kaum einer wirklich Ahnung von automotive Elektronik hat, 
ausser Robert Bosch, Continental und Holden (Opel)...

Natuerlich zweifel ich an mir selber, ob ich irgendwas uebersehen habe 
oder so.. die Erwartungen vom Management sind schon ein wenig so in die 
Richtung... der Neue schaut da mal drueber, ein bischen Testen hier und 
da, Fehler finden und die Sache ist fuer immer erledigt... Wenn ich 
jetzt mit der Breitseite Tests komme, ist ja klar das mein Manager 
eigentlich nicht seine Hausaufgaben gemacht hat... :)

Habe das Gefuehl das je tiefer ich grabe, desto schlimmer wird die 
Sache... :(

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn dieser Türkontakt so wichtig ist, dann muß man ihn eben überwachen.

Erstmal kriegt er die vollen 24V, basta.
Dann schaltet man nen Widerstand parallel, damit ein Grundstrom fließt. 
Diesen Strom überwacht dann das Kontrollgerät und weiß nun, daß das 
Kabel o.k. ist.
Noch besser, man nimmt nen Umschaltkontakt und 2 Anschlüsse zum 
Kontrollgerät oder 2 verschiedene Widerstände.


Ohne Hardwareänderung ist also nichts zu machen.


Peter

Autor: Walter Tarpan (nicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Erstmal kriegt er die vollen 24V, basta.
> Dann schaltet man nen Widerstand parallel, damit ein Grundstrom fließt.
> Diesen Strom überwacht dann das Kontrollgerät und weiß nun, daß das
> Kabel o.k. ist.
> Noch besser, man nimmt nen Umschaltkontakt und 2 Anschlüsse zum
> Kontrollgerät oder 2 verschiedene Widerstände.

Normalerweise nimmt man für Fahrzeugsensoren in zweileitertechnik zwei 
unterschiedliche Widerstandswerte, die ein gewisses Detektionsfenster 
bieten. Verläßt der vom "Empfänger" gemessene Widerstandswert das obere 
Fenster nach oben, liegt ein Kabelbruch vor, ist der empfangene 
Widerstand kleiner als das untere Fenster, liegt ein Kurzschluß vor.

Für Dreileitertechnik gilt sinngemäß das Gleiche, wobei dann auf eine 
Spannungs- oder Strommessung umgeschwenkt werden kann mit den 
entsprechenden Fenstern.

Sehr schön ist das alles übrigens beschrieben im Vieweg Handbuch der 
Kraftfahrzeugtechnik.

Grüße
Nicolas

Autor: Anja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sag mal Daniel,

das ist doch immer noch dasselbe Problem von hier oder?

Beitrag "Schalter einlesen.so einfach, doch so schwierig"

Langsam glaube ich daß dein Chef gar nicht will daß Du den Fehler 
findest. Deine primäre Aufgabe ist es wahrscheinlich als Prellbock vor 
Ort den Kunden bei Laune zu halten damit der Rest der Firma ungestört an 
anderen Projekten weiterarbeiten kann. Anders kann ich mir nicht 
erklären wie mann mehrere Monate einen Ing. bezahlt (mit Reisekosten) 
wenn nicht anderswo mehr Geld zu verdienen ist.

Gruß Anja

Autor: Andreas Wolff (crazywolff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hätte da noch eine Frage:

Du schriebst:

> Am Mittwoch bin ich mit einem alten Bus mitgefahren... Am Donnerstag kam
> dann der Fehlerreport... 17 Fehler, wobei ich 12 mit meinem Logger
> bestaetigen konnte... Der Fahrer hat einfach die Tuer schon weit vor der
> Bushaltestelle geoeffnet... die andere Fehler traten vor meiner Mitfahrt
> auf...

> Jedoch hatte ich im Fehlerreport auch einen Bus der es gar nicht erlaubt
> mit offenen Tueren zu fahren... Ist die Tuer auf kann man nicht
> losfahren, faehrt man gehen die Tueren nicht auf...

Diese Schaltung, die ein öffnen der Tür bei der Fahrt verhindert, nimmt 
die das gleiche Quellsignal wie der Logger, oder wird das eventuell wo 
anders generiert?

Wenn das Signal wo anders herkommt, dann kann die Türsperre eventuell 
einen Sekundenbruchteil früher freigegeben werden als Dein Logger 
annimmt und so wird ein Fehler geloggt.

Zumindest da wo ich herkomme sind die Busfahrer sehr schnell mit dem 
Türen öffnen.

CU,
Crazy

Autor: Wegstaben Verbuchsler (wegstabenverbuchsler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mal eine praktische Frage bzw. Problem-Findungs-Ansatz:

macht es Sinn (d.h. ist es schaltungstechnisch, und auch räumlich vor 
Ort machbar) diese Wunderelektronik versuchsweise spannungsmäßig vom 
Bordnetz zu trennen (also seperate 24V Batterie zum Versorgen)?

Autor: Benni L. (sutter_cain)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du Möglichkeiten kleine Modifikationen an einem Bus vorzunehmen? 
Ein paar Bauteile zuätzlich, Werkzeug, ggf. Oszi, etc.

Dann könntest du versuchen mal ein Tiefpass einzubauen, den Schalter 
nicht floaten lassen, sondern auf definiertes Potential legen, ...

Wenn es denn dann so eine simple Lösung ist, wird das Management 
bestimmt nichts dagegen haben eine kleine Zusatzschaltung einzubauen ;)

Autor: Daniel Duesentrieb (daniel1976d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Halloechen ... nachmals Danke fuer die vielen Antworten und 
Vorschlaege...

Anja... ja sehr richtig beobachtet das war ich... dieses Problem schlepp 
ich schon seit letztes Jahr Oktober mit mir rum... es gab mal eine Phase 
da war ich an anderen Dingen am arbeiten, jedoch ist unserem Management 
nun ploetzlich eingefallen das das Projekt nun mal zu Ende gefuehrt 
werden muss, denn es haengen weitere Auftraege dran...

Die Logik das die Tueren nur aufgehen wenn der Bus steht benutzt eigene 
Sensoren an die wir auch nicht dran duerfen... :). Unsere Schalter 
benutzen den pneumatischen Druck um die Tuere zu oeffnen...

Die Idee mit der Batterie liesse sich bei einigen Bussen ohne Probleme 
durchfuehren.

Das mit der zusaetzlichen Hardware waere auch eine Moeglichkeit... 
bekommen die Tueren eben einen Tiefpass... und das Tachosignal eben 
einen Komparator... kein Problem... Das waere immerhin eine einfache und 
relativ kostenguenstige Loesung... werde da mal einfach was aufbauen...

Kopfzerbreichen macht mir jedoch immer noch die vielen Unbekannten... 
Fahrer die eventuell zu frueh die Tuer oeffnen, Wartungscrews die 
eventuell wissen wie man die Sicherheitslogik ueberschreibt, einfach 
unsere Leitungen kappen, andere Geraetschaften in den Bus einbauen usw 
und das alles ohne das wir davon erfahren... oft passiert es das wir 
tagelang einen Bus ohne Fehlermeldugen haben und uns schon freuen um 
dann nach Tagen zu erfahren das der Bus nur zur Reperatur war und 
dementsprechend keine Fehler gesendet hat... Dann natuerlich die 
Hardware selber, die Software usw. usw. Ich bin mir nicht sicher ob ich 
alleine mit einer Flotte von ca. 150 Bussen weiterkomme...

Autor: oldmax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
Ich hatte es bereits beschrieben, Tür Auf und Bus fährt noch, ist 
relativ einfach festzustellen, es muß sich halt nur sie 
Softwareabteilung in die Pflicht genommen fühlen und endlich mal 
abchecken: ist's ein Impuls kleiner 1 Sekunde, dann dürfte es wohl nicht 
am Bus bzw. Fahrer liegen, da wohl kaum die Tür in 1 Sekunde öffnet und 
schließt. Am besten, du packst die Jungs bei ihrer Ehre...: " na ja, es 
ist schon sehr schwierig, abzufragen, ob die Tür nur ein paar ms oder 
vielleicht gar länger geöffnet bleibt. Das können ja auch nur 
Spezialisten mit der goldenen Diskette in der Kravattennadel...." . 
Solche Worte können richtig ins Gespräch eingestreut Wunder wirken. Mal 
eine Frage, Daniel, wie lange möchtest du dieses Problem noch 
ignorieren. Hol endlich alle ins Boot oder setz dich hin und schreib 
einen Bericht...
von den 3 % der Fehler sind 89% auf das Verhalten der Fahrer, 7% der 
Strecke und 4 % Murphy zuzuschreiben. Die 89% sind durch Fahrerschulung 
und entsprechende Hinweise aus Diszipinarverfahren auszumerzen, 7% 
lassen sich durch Reparaturen an Straßen beseitigen und die restliche 4 
sind wiederum auf die 3 % Fehlervorfälle nur 0,12 % und deshalb in der 
Toleranzgrenze...

So, nun lege deine Statistik so, das du bei den besagten 3 % landest, 
oder setz deine Toleranzgrenze hoch.
Gruß oldmax

Autor: Daniel Duesentrieb (daniel1976d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo... Wollte mich noch mal melden...

Nach ein paar Fahrten und dem Loggen der Daten kommen wir immer mehr zu 
dem Schluss das unsere HW funktioniert... immer wenn ich da sitzte 
passiert nichts... bzw wie es sein sollte... Bus steht, Tuer auf/zu... 
Bus faehrt an... Nun ja wir konnten das bisher real nur an 5 Bussen 
testen und eben nur zeitlich begrenzt denn irgendwann ist halt der Akku 
leer...

Wir haben das Ganze nun gestoppt und ich schreibe erstmal nun einen 
groesseren Bericht... der eben alles zusammenfasst und auch einige 
Empfehlungen enthalten wird, auch SW Aenderungen...

Diese werden dann implementiert und dann sehen wir mal weiter...

Gruesse

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.