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...
Hund, Katze, Maus, ... Ist jetzt nicht Dein Ernst, oder?
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.
Wie war das? Ich glaube Zeile 46 im Programmcode ist falsch oder war´s doch ´ne andere?
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...
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?
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!)
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 ...
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...
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...
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.
Oh weh, Automotive mit 24 V. Eine wirklich häßlich gestörte Umgebung. Aber Optokoppler ist ja schon mal da.
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!
Lutz schrieb: > Oh weh, Automotive mit 24 V. Allerdings. Oder gehören Lkw und Busse nicht zum Automotive-Bereich?
Vielleicht irgendwelche kapazitive Einkopplungen o. ä.: Beitrag "Pullup-Widerstand Größe ermitteln" http://www.elektronik-kompendium.de/public/schaerer/pullr.htm Eine störsichere Eingangsschaltung konstruieren ...
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?
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...
> 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.
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.
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
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.
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.
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...
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...
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.
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...
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.
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
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
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 ....
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... :)
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?
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
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?
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...
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
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
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...
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.
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
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...
Viele Fehler haben mechanische Ursachen. Entweder Kontaktfehler/Prellen/kein Überhub oder evtl. Kondenswasser/Druckabfall im Luftkanal?
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
Hallo Peter was nützen 1000 Prozessoren wenn z.B. der Druckschalter nur halb schließt?
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
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
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
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
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
@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
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%A4ubende_Reise_in_einem_verr%C3%BCckten_Bus
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.
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...
Ach noch was... wir haben ein neues Geraet (neue Generation von HW) und auch dies erzeugt Fehler...
>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?
@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
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...
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...
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??
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?
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
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...
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
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.
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.
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
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
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... :(
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
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
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
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
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)?
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 ;)
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...
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
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
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.