CAN-bus inbouwen oude auto

[LauPro]

Met een vriend van mij ben ik bezig om een auto op te knappen. Het betreft een Bertone. We hebben echter heel veel massaproblemen. Ik heb al een keer een middag alle contractjes met een vijl langsgelopen en her en der is er wat verbetering maar zelfs na een dag zoeken werken de knipperlichten rechts bijvoorbeeld nog niet.

Toen kwamen we op het idee om de auto op afstand te kunnen starten en bijvoorbeeld te lichten aan te kunnen doen. Dit is met een simpele handzender en wat relais te fixen, echter willen we ook inbouwen dat je kan zien of een lamp stuk is.

Om het wiel niet opnieuw uit te vinden kwam ik vrij snel uit op de CAN-bus. Echter waar ik eigenlijk naar op zoek ben is een regelunit die de basisfuncties zoals verlichting e.d. kan schakelen (liefst zonder relais) maar welke ook op afstand aanstuurbaar is.

En we zitten met een aantal situaties die niet zomaar kunnen worden opgelost: stel dat we op afstand de motor starten (hiervoor moeten het injectiecircuit & de startmotor aan), de motor vervolgens draait maar als je dan wil wegrijden dan klikt naar 5 meter het stuurslot erop, levensgevaarlijk dus . Liever dat er dan een lampje is aan geeft dat je nog wel het stuurslot eraf moet halen.

Eigenlijk wil ik al dit soort functies in een microprocessor stoppen en die dan met de CAN-bus aan kunnen sturen, in ieder geval voor de verlichting. De volgende stap is om ook een beetje motor management te doen, er is bijvoorbeeld een blower op de verdeler die aan moet als de temperatuur te hoog is, we willen dan op het dashboard deze temperatuur tonen en tonen of de blower aan is (en een alarm als de temperatuur te hoog is).

Omdat de auto al een bepaalde indeling heeft en ik niet alle draden naar 1 punt wil gaan trekken tel ik momenteel 4 punten waar we willen schakelen.

Koplamp linksvoor:
- Grootlicht / dimlicht / stadlicht
- Knipperlicht
- Ruitenwissers
- Sensor remvloeistof
- Sensor ruitenwisservloeistof

Koplamp rechtsvoor:
- Grootlicht / dimlicht / stadlicht
- Knipperlicht
- Claxon
- Temperatuur radiator
- Ventilator radiator
- Sensor voorklep open
- Openen voorklep

Achterbak:
- Achterlicht + kentekenverlichting
- Achteruitrijlicht
- Remlicht
- Knipperlicht
- Achterbak openen
- Sensor achterbak open
- Verlichting achterbak

Motorbak:
- Sensor motorbak open
- Motorbak openen
- Temperatuur verdeler
- Blower verdeler
- Brandstofverbruiksmeter (flowmeter)
- Temperatuur luchtaanvoer
- Temperatuur uitlaat
- Toerental motor
- Oliedruk
- Temperatuur motor
- Benzineniveau
- Injectiesysteem aan/uit
- Startmotor aan/uit (apart circuit?)

Interieur (links + rechts):
- Sensor deur open
- Deurontgrendeling
- Deuropener
- Raam omlaag/omhoog
- Interieurverlichting

Interieur overig:
- Interieurverlichting
- Verwarming aan/uit
- Blower stand (liefst via PWM)
- Blower blaasrichting (beneden/boven)
- Achterruitverwarming
- Spiegelverwarming
- Binnentemperatuur
- Buitentemperatuur

Dan heb ik nog lang niet alle functies genoemd. Wat ik eigenlijk wil maken is een CAN-controller met bijvoorbeeld 8 uitgangen, 8 ingangen en een paar ADC/DAC. Als ik daar dan 4-5 van maak dan kan ik alle verschillende zaken daar aan hangen. Een CAN-bus kan tot 250k, sensoren kan je pollen.

Ik ben al op zoek geweest naar wat open source projecten maar die zijn weinig te vinden. Arduino heeft wel een shield voor CAN dus dat zou een uitgangspunt kunnen zijn. Maar met ruim 50 euro per shield zou ik dan tegen de 500 euro kwijt zijn. Ik zit meer te denken aan 250 euro voor alle elektronica. Niet alle dingen hoeven uitgelezen kunnen worden maar het zou wel fijn zijn.

De AVR AT90CAN128 lijkt wel interessant, hij is 10 euro per stuk en er zit veel I/O op, met een redelijk simpele print zou ik dan al een eind moeten kunnen komen.

Zijn er mensen met tips en tricks? Of kent iemand vergelijkbare projecten?

[kELAL]

First things first: VERHELP JE MASSAPROBLEEM; ook als je alles hebt omgezet naar CAN krijg je de gekste storingen!

Speltip 13: Weet waar je grenzen liggen. En weet waar je in hemelsnaam mee begint: bereid je alvast voor op vele, vele, vele uren debuggen!

.

- Brandstofverbruiksmeter (flowmeter)

Je weet dus duidelijk niet hoe benzine-injectie werkt.
In een notendop: De brandstofpomp pompt continu op volle capacteit brandstof in de ene kant van de injectorrail. Aan de andere kant van de rail loopt alles wat niet door de injectors is uitgestroomd via een overdrukventiel en retourleiding terug je tank in.
Met een flowmeter meet je dus constant de zelfde waarde

Verbruik meet je door de tijd dat een injector openstaat te tellen.

[LauPro]

kELAL schreef op maandag 08 april 2013 @ 11:56:
First things first: VERHELP JE MASSAPROBLEEM; ook als je alles hebt omgezet naar CAN krijg je de gekste storingen!

Ik wil naar alle elektronica aparte massadraden gaan leggen.

Speltip 13: Weet waar je grenzen liggen. En weet waar je in hemelsnaam mee begint: bereid je alvast voor op vele, vele, vele uren debuggen!

True.

Je weet dus duidelijk niet hoe benzine-injectie werkt.
In een notendop: De brandstofpomp pompt continu op volle capacteit brandstof in de ene kant van de injectorrail. Aan de andere kant van de rail loopt alles wat niet door de injectors is uitgestroomd via een overdrukventiel en retourleiding terug je tank in.
Met een flowmeter meet je dus constant de zelfde waarde

Verbruik meet je door de tijd dat een injector openstaat te tellen.

Ik kan toch twee flowmeters gebruiken en dan het verschil meten? Ik wil eigenlijk niet gaan rommelen met het injectiesysteem zelf.

[luccie]

LauPro schreef op maandag 08 april 2013 @ 12:05:
[...]
Ik wil naar alle elektronica aparte massadraden gaan leggen.
[...]
True.
[...]
Ik kan toch twee flowmeters gebruiken en dan het verschil meten? Ik wil eigenlijk niet gaan rommelen met het injectiesysteem zelf.

Dat 1e kunt je nu ook al doen, vanaf je accu een goed verdeelpunt maken met een blok. Vandaaruit draaden naar overal waar je ergens massa op de carosserie aansluit.

2x flowmeter = duur?

Erg ambitieus, maar ik heb hem gebookmarked om te kijken wat ervan komt.
Houdt rekening met goede ontstoringsbeveiligingen op al je controllers.
Bobine en dynamo maken er een zooitje van op de massa van je auto. Hang er maar eens een scope aan.

[kELAL]

luccie schreef op maandag 08 april 2013 @ 12:18:
2x flowmeter = duur?

En behoorlijk onnauwkeurig bij lagere verbruikswaarden. Bovendien: dingen die kapot kunnen plaatsen in je brandstofleiding? Eek!

Dan is het via een optocoupler* aftappen van een injectorsignaal een heel stuk makkelijker en veiliger!
*) Want je wilt natuurlijk uitsluiten dat er een of andere aardlus de boel op stelten zet

edit:
Of nog minder invasief: met een gevoelige hall sensor de stroom door een injectordraad meten

[ Voor 9% gewijzigd door kELAL op 08-04-2013 12:44 ]

[joopv]

LauPro schreef op maandag 08 april 2013 @ 12:05:
[...]
Ik wil naar alle elektronica aparte massadraden gaan leggen.
[...]

Om massa issues op te lossen die je niet kunt vinden vanwege de auto constructie of de staat van de auto (corrosie) moet je naar alle *elektriciteitsverbruikers* massadraden leggen.
Dat zou dan in het ideale geval een ster-aarde moeten worden: ieder apparaat zijn eigen aardlijn naar de accu minpool. En die draad moet dan ook voldoende mm² koper hebben voor de betreffende stroom.
Dat zal wel teveel gevraagd zijn maar ik noem het toch.

Ster-aarde gebruik je om te voorkomen dat de stroom van belasting A het aardpotentiaal optilt van een andere belasting B.

[Zer0]

LauPro schreef op maandag 08 april 2013 @ 00:59:
En we zitten met een aantal situaties die niet zomaar kunnen worden opgelost: stel dat we op afstand de motor starten (hiervoor moeten het injectiecircuit & de startmotor aan), de motor vervolgens draait maar als je dan wil wegrijden dan klikt naar 5 meter het stuurslot erop, levensgevaarlijk dus . Liever dat er dan een lampje is aan geeft dat je nog wel het stuurslot eraf moet halen.

Ik zou me veel meer zorgen maken over de mogelijkheid te starten terwijl de auto nog in een versnelling staat...

[LauPro]

luccie schreef op maandag 08 april 2013 @ 12:18:
[...]
Dat 1e kunt je nu ook al doen, vanaf je accu een goed verdeelpunt maken met een blok. Vandaaruit draaden naar overal waar je ergens massa op de carosserie aansluit.

Dat was ook wel het plan, om naar alle aardkransjes een draad naar de accu te leggen met ditto dikte.

2x flowmeter = duur?

Ik heb geen idee, die sensors (en dat valt buiten die 250 imo) zullen best wat geld kosten maar het is natuurlijk wel gaaf als je gewoon kan zien hoeveel kilometer je nog kan rijden of wat je verbruik is, waarschijnlijk wel om te huilen maar dan kan ik het altijd nog in gallons of teaspoons tonen .

Erg ambitieus, maar ik heb hem gebookmarked om te kijken wat ervan komt.
Houdt rekening met goede ontstoringsbeveiligingen op al je controllers.
Bobine en dynamo maken er een zooitje van op de massa van je auto. Hang er maar eens een scope aan.

Dit is een goede opmerking inderdaad, ik zat zelf te denken om gewoon een paar dikke condensatoren bij elke unit te hangen en dan een goede dc-dc converter zodat ze 10 seconden aan blijven na stroomafval (en relais uit). Dan zal ook bij het starten van de motor het eea uitleesbaar zijn.

kELAL schreef op maandag 08 april 2013 @ 12:28:
En behoorlijk onnauwkeurig bij lagere verbruikswaarden. Bovendien: dingen die kapot kunnen plaatsen in je brandstofleiding? Eek!

Dan is het via een optocoupler* aftappen van een injectorsignaal een heel stuk makkelijker en veiliger!
*) Want je wilt natuurlijk uitsluiten dat er een of andere aardlus de boel op stelten zet

edit:
Of nog minder invasief: met een gevoelige hall sensor de stroom door een injectordraad meten

Ik sta open voor alle suggesties. De flow meter leek mij het makkelijkst. En er zit nu ook al een brandstofpomp e.d. in die leiding dus ik zie het probleem van een flowmeter niet zo. Het is een oude auto dus er zal toch voor elke lange rit even alles gecheckt moeten worden.

Maar ik snap wel dat ik de injectie uit zou kunnen lezen, alleen hoe weet ik dan hoeveel brandstof hij per keer spuit? En ik neem aan dat als er gas wordt gegeven er nog meer brandstof wordt gespoten, dus dan ben ik eigenlijk bezig om een interface op het injectiesysteem te bouwen. Misschien dat hier wel wat op zit. Het is een zilvergrijs kastje, ik heb geen merk maar dat kan ik opzoeken.

Sowieso is de injectie gaar want nu lopen er maar 3 cilinders van de 4 dus daar moeten we ook nog naar kijken.

Eerste prioriteit is eigenlijk de verlichting en we willen dan gaandeweg meer en meer sensoren aan het systeem hangen. Het kan ook zijn dat je misschien nog een hele andere motor in komt bijvoorbeeld, dus alles zal flexibel moeten zijn.

Edit:
Ik heb een leuke starterset gevonden met veel IO: https://www.olimex.com/Products/AVR/Development/AVR-CAN/

[tonschong]

Goedkoopste oplossing lijkt mij een auto van de sloop halen en daar dan alles van overbouwen. Heb je alle benodigde basis-electronica en benodigde opnemers.

[houthakker]

Tja, volgens mij vergeet je nog een ding. Autoelectronica word normaal onderworpen aan een behoorlijk pakket eisen, testen voor de nodige certificering etc. (emc/esd eisen zijn vergeleken met industriele toepassingen al heel wat zwaarder). Ik denk persoonlijk dat je eisenpakket al hoog gegrepen is, en als je het aan de praat krijgt je nog heel wat problemen te wachten staat. Hoewel ik denk, omdat je een bestaand voertuig verbouwd kwa electronica - hetwel meevalt; je normaal gesproken dit niet technisch gekeurd zou krijgen (RDW). Maar je moet nog wel even denken aan je 'persoonlijke veiligheid'. Alles is mogelijk, maar ik zou goed kijken naar andere andere projecten (als deze zo uitgebreid al bestaan).

[real[B]art]

LauPro schreef op maandag 08 april 2013 @ 17:12:
Dit is een goede opmerking inderdaad, ik zat zelf te denken om gewoon een paar dikke condensatoren bij elke unit te hangen en dan een goede dc-dc converter zodat ze 10 seconden aan blijven na stroomafval (en relais uit). Dan zal ook bij het starten van de motor het eea uitleesbaar zijn.

Vergeet dan ook niet een diode ervoor te zetten. Anders trek je tijdens het starten al je condensatoren alsnog leeg via je voedingslijnen, die daar ook nog eens te dun voor zijn. Je hebt wel een spanningsval over de diode, houd met je keuze voor een dc-dc converter er dus rekening mee dat je ook toe moet kunnen met een input van <12V.
Verder zul je een weerstand (simpel) of verdere elektronica (lastiger) nodig hebben om te zorgen dat bij het inschakelen van het contact niet in één klap al je condensatoren zich volle mep opladen.

Maarre, waarom moet het specifiek een CAN-bus zijn? Waarom niet een RS485-bus met een eigen protocol? Is dat omdat je kant-en-klare CAN-bus modules aan wilt kunnen sluiten?

Daarnaast zul je sowieso erg veel aandacht aan het ontwerp en de implementatie moeten besteden in het kader van fail-safes. Je wilt niet midden in de nacht op een onverlichte snelweg ineens zonder verlichting zitten omdat je spul een bugje blijkt te hebben.

Kortom, tof project, maar weet waar je aan begint Ik ben heel benieuwd, veel succes

[joopv]

LauPro schreef op maandag 08 april 2013 @ 17:12:
[...]
Dit is een goede opmerking inderdaad, ik zat zelf te denken om gewoon een paar dikke condensatoren bij elke unit te hangen en dan een goede dc-dc converter zodat ze 10 seconden aan blijven na stroomafval (en relais uit). Dan zal ook bij het starten van de motor het eea uitleesbaar zijn.

Een condensator heeft alleen nut als je zeker weet dat de aarde/massa "schoon" is. En een zeer lage impedantie heeft.

Voor beide eigenschappen heb ik mijn twijfels als ik jouw posts in dit draadje doorlees.

Verder zoals al door meer mensen gezegd: leuk hobbyproject, maar voor een object waar levens en veiligheid van afhankelijk zijn moet je toch andere maatstaven aanhouden. Daar kun je geen risico's mee nemen.

ps: in V&A op circuitsonline.net staat een advertentie met goedkope flowmeters. Maar of ze geschikt zijn voor brandstof..?

[Dogooder]

real[B]art schreef op dinsdag 09 april 2013 @ 01:45:
[...]

....

Maarre, waarom moet het specifiek een CAN-bus zijn? Waarom niet een RS485-bus met een eigen protocol? Is dat omdat je kant-en-klare CAN-bus modules aan wilt kunnen sluiten?

...

Volgens mij is CAN een RS-485 bus, RS-485 is enkel laag 1, daar waar CAN ook laag 2 van het OSI model biedt.
Voordeel van CAN vs een eigen protocol is de prioritizing en error managament.

[LauPro]

tonschong schreef op maandag 08 april 2013 @ 19:33:
Goedkoopste oplossing lijkt mij een auto van de sloop halen en daar dan alles van overbouwen. Heb je alle benodigde basis-electronica en benodigde opnemers.

Dit is een idee inderdaad, maar dan blijf ik wel met het punt zitten dat ze bijvoorbeeld bepaalde zaken op afstand willn kunnen regelen en we willen ook kunnen zien of er een lamp stuk is, de vraag is of zo'n systeem van een sloopauto dit allemaal heeft. Een schadeauto zou nog kunnen maar dan is waarschijnlijk het onderdeel nog steeds aan de prijs maar ik ga het zeker uitzoeken.

houthakker schreef op maandag 08 april 2013 @ 22:32:
Tja, volgens mij vergeet je nog een ding. Autoelectronica word normaal onderworpen aan een behoorlijk pakket eisen, testen voor de nodige certificering etc. (emc/esd eisen zijn vergeleken met industriele toepassingen al heel wat zwaarder). Ik denk persoonlijk dat je eisenpakket al hoog gegrepen is, en als je het aan de praat krijgt je nog heel wat problemen te wachten staat. Hoewel ik denk, omdat je een bestaand voertuig verbouwd kwa electronica - hetwel meevalt; je normaal gesproken dit niet technisch gekeurd zou krijgen (RDW). Maar je moet nog wel even denken aan je 'persoonlijke veiligheid'. Alles is mogelijk, maar ik zou goed kijken naar andere andere projecten (als deze zo uitgebreid al bestaan).

Ik wil alleen maar kant en klare (gekeurde) componenten gebruiken, voor relaymontage zoveel mogelijk DIN-railsystemen. Voor zover ik kan vinden bij de RDW is eigenlijk de enige eis dat accu goed vast zit en dat alle bedrading degelijk is geïsoleerd. Ik wil alle systeembekabeling in ieder geval dubbel isoleren. Het enige printje dat ik moet gaan maken zullen de drivers zijn van de relais en de lampendefectindicatie.

Er zijn hier kant en klare IC's van: U479B en U2480B echter deze zijn alleen leverbaar per 1000 . Dus ik zal zelf een schakeling moeten maken.

Vooralsnog zou ik het niet erg vinden als de lampentest het alleen doet als de lamp aan is wanneer dit veel elektronica scheelt.

real[B]art schreef op dinsdag 09 april 2013 @ 01:45:
Vergeet dan ook niet een diode ervoor te zetten.

Zal ik zeker doen!

Maarre, waarom moet het specifiek een CAN-bus zijn? Waarom niet een RS485-bus met een eigen protocol? Is dat omdat je kant-en-klare CAN-bus modules aan wilt kunnen sluiten?

Omdat ik niet een compleet nieuw protocol wil bedenken, CAN voorziet in vanalles zoals priority messages, bus arbitrage, failsafe wanneer een node stuk of uit is. Dat is bij een RS485-bus allemaal maar de vraag, een defect device die de lijn open houdt kan alle communicatie blokkeren, bij CAN hebben ze dit in de driver voorzien.

Daarnaast zul je sowieso erg veel aandacht aan het ontwerp en de implementatie moeten besteden in het kader van fail-safes. Je wilt niet midden in de nacht op een onverlichte snelweg ineens zonder verlichting zitten omdat je spul een bugje blijkt te hebben.

Helemaal mee eens, ik heb al zitten denken om in ieder geval voor dimlicht, achterlichten en de knipperlichten een overbruggingsbedrading aan te sluiten die kan worden geactiveerd met de 'gevarenknop' (dus helemaal los van het CAN-systeem).

Een condensator heeft alleen nut als je zeker weet dat de aarde/massa "schoon" is. En een zeer lage impedantie heeft.

Voor beide eigenschappen heb ik mijn twijfels als ik jouw posts in dit draadje doorlees.

Dit zal ik moeten testen, ik maak gewoon een print met zo'n condensator en dan hang ik het geheel eens aan de scope wat er gebeurt bij het opstarten. Ik zal de plaatjes hier tzt posten.

Verder zoals al door meer mensen gezegd: leuk hobbyproject, maar voor een object waar levens en veiligheid van afhankelijk zijn moet je toch andere maatstaven aanhouden. Daar kun je geen risico's mee nemen.

Ook met de modernste auto's kan het voorkomen dat door een defect in een aanstuursysteem niets meer werkt. Zo had iemand een tijdje terug een gloednieuwe auto en hij drukte op start en er gebeurde niets. Dat zou ook op de snelweg kunnen gebeuren. Ik zal zeker het systeem ontwerpen met veiligheid in gedachten, daarom hamer ik bijvoorbeeld op die lampendetectie en heb zelfs zitten denken om te detecteren of een relais (of solid state switch) wel schakelt, qua GPIO heb ik genoeg per device.

Zou bijvoorbeeld kunnen doen:
PORTA: Output control
PORTB: Relay feedback
PORTC: Lamp feedback

ps: in V&A op circuitsonline.net staat een advertentie met goedkope flowmeters. Maar of ze geschikt zijn voor brandstof..?

Ik koop liever dergelijke cruciale componenten nieuw maar ik ga zeker even kijken!

[Garyu]

houthakker schreef op maandag 08 april 2013 @ 22:32:
Tja, volgens mij vergeet je nog een ding. Autoelectronica word normaal onderworpen aan een behoorlijk pakket eisen, testen voor de nodige certificering etc. (emc/esd eisen zijn vergeleken met industriele toepassingen al heel wat zwaarder). Ik denk persoonlijk dat je eisenpakket al hoog gegrepen is, en als je het aan de praat krijgt je nog heel wat problemen te wachten staat. Hoewel ik denk, omdat je een bestaand voertuig verbouwd kwa electronica - hetwel meevalt; je normaal gesproken dit niet technisch gekeurd zou krijgen (RDW). Maar je moet nog wel even denken aan je 'persoonlijke veiligheid'. Alles is mogelijk, maar ik zou goed kijken naar andere andere projecten (als deze zo uitgebreid al bestaan).

Ik werk bij een ontwikkelaar van (o.a.) auto-communicatie-electronica en houthakker hier heeft natuurlijk gewoon gelijk. Een zelf-gefabriceerde oplossing mag nooit en te nimmer de weg op, als het kritische systemen kan bereiken. Een HMI voor de radio mag je mee doen wat je wilt, maar op afstand de motor starten? Dat ga je er nooit doorheen krijgen, tenzij je een flinke berg tijd en geld in de hand neemt. Lees voor de grap eens de ISO-26262 standaard, verplichte lectuur voor kritische auto-software en electronicacomponenten.

Bij een onderdeel dat de motor aanstuurt hebben we het definitief over de zwaarste categorie, ASIL-D, waar je elke mogelijke case en interactie moet hebben getest en geverificeerd dat het onder geen enkele omstandigheid fout kan gaan. Met CAN betekent dat bijvoorbeeld, dat je zult moeten nagaan dat je nooit, ook niet onbedoeld, de bus kan verstoppen door bijvoorbeeld een lange reeks highest priority messages te sturen. Je applicatie moet met alle mogelijke soorten van fouten (onbedoelde inputs, onbedoelde outputs, programmeerfouten) om kunnen gaan, en je code moet door een onafhankelijk iemand gereviewed worden. Dat hele proces moet je van tevoren beschrijven en tijdens het doorlopen ervan documenteren. Voor die documentatie moet je weer een quality-certificering hebben, die ook weer geld kost.

Voor de openbare weg zou ik hier dus never-nooit-niet aan beginnen, voor je eigen veiligheid en die van anderen, die regels hebben namelijk wel een bepaalde achtergrond.

Als hobbyproject in de garage kan je natuurlijk doen wat je wilt, maar serieus met een houtje-touwtje-oplossing gaan rijden?

[LauPro]

Over het op afstand starten: natuurlijk hebben we nagedacht over veiligheid, zo willen we checken:
- Dat de motor niet gestart is.
- Zijn de deuren ontgrendeld.
- Staat de versnelling in zijn vrij.
- Staat de handrem erop.

En ook belangrijk is dat de auto na het starten niet mag bewegen anders moet de routine meteen worden afgebroken.

Verder zal het starten alleen de startmotor aan zetten, stel dat dit tijdens het rijden zou gebeuren dan zouden we daarmee alleen de startmotor mollen.

Het is niet zo dat we het remsysteem of de gashendel met de CAN-bus gaan aansturen, dit blijft gewoon zoals het is.

Verder ben ik zeer benieuwd hoe ze bij de RDW kunnen checken of wij de motor op afstand kunnen starten. We zullen er een nieuwe zekeringbox in zetten maar dat lijkt mij vrij normaal bij een dergelijke aanpassing. Alle basisfuncties moeten gewoon werken zoals ze horen werken.

Eigenlijk wil ik de priority messages sowieso niet gaan gebruiken. Ik heb liever 1 master die gewoon lekker gaat pollen over wat er aan de hand is, dan kan je qua bus timings nooit collisions krijgen (tenzij je twee apparaten hebben die op hetzelfde ID reageren). En het enige dat ik wil doen is een actie zetten of een actie uitlezen. Ik zie niet in hoe gevaarlijk dit kan zijn.

Dat het in een volwaardige auto met ESP, ABS, airbags etc allemaal wat tandjes hoger gaat snap ik maar daar is geen sprake van. En verder zijn vrijwel alle sensoren bij de motor gewoon op statistiek uit te lezen, op de blower bij de verdeler na, maar dat is alleen bij filerijden of bij een stoplicht het geval.

[Garyu]

Een keuring zou dit moeten constateren en de auto afkeuren vanwege ondeugdelijke electronica. Een startmotor verkeerd aansturen kan ook nogal een probleem opleveren als dat op de snelweg gebeurt. Ook al is de kans klein, een programmeerfoutje zit in een klein hoekje, en die ga je niet vinden tot het te laat is. Ook kleine kansen worden door de RDW niet geaccepteerd (10^-9 is bijvoorbeeld de tolereerbare grens voor HW-fouten).

[Damic]

Neem een wagen met een can bus en een start knop, kun je de starter al niet mollen want dan zodra de motor loopt word de start een stop knop (kijk maar naar Renault enzo).

[Anoniem: 239824]

joopv die zij het al heel mooi, ga niet klooien in die oude bak maar zorg dat al je massa draden, en ja ik bedoel draden en geen(!) koets op de zelfde plek bijeenkomen.
Scheelt je een hoop gezijk en het werkt altijd.
Kortom ga niet klooien maar houd het ouderwetsch...

[LauPro]

Garyu schreef op dinsdag 09 april 2013 @ 22:28:
Een keuring zou dit moeten constateren en de auto afkeuren vanwege ondeugdelijke electronica. Een startmotor verkeerd aansturen kan ook nogal een probleem opleveren als dat op de snelweg gebeurt. Ook al is de kans klein, een programmeerfoutje zit in een klein hoekje, en die ga je niet vinden tot het te laat is. Ook kleine kansen worden door de RDW niet geaccepteerd (10^-9 is bijvoorbeeld de tolereerbare grens voor HW-fouten).

Deze opmerkingen zijn misschien van toepassing bij typekeuringen maar niet bij reguliere keuringen voor zover ik kan vinden:

quote: http://www.apkkeuringseis...ngseisen-voor-verlichting

Koplampen moeten bij de apk keuring naar behoren werken. APK keuringseis is werkende functie van stadslicht, dimlicht en grootlicht bij beide lampen. Kleur van de lichten moet wit of geel zijn. Bij de APK wordt ook de hoogte van de lichten gemeten. Indien deze vanuit de auto af te stellen zijn voor bijvoorbeeld rijden met aanhanger, dan dient deze functie te werken. Een andere eis van de APK keuring is dat linker en rechterlamp evenveel verlichting moeten geven.
Achterlichten dienen allebei te werken. APK keuringseis is dat de kleur rood is, wit licht mag door scheuren en dergelijke niet zichtbaar zijn.
Remlichten, deze mogelijk zowel rood als ambergeel zijn. Bij de APK keuring is een derde remlicht pas verplicht vanaf 30 december 2001. Daarvoor is een derde remlicht niet noodzakelijk. Indien aanwezig moet deze gecentreerd boven de gewone remlichten gemonteerd zijn.
Knipperlichten en alarmlichten dienen correct te werken. Niet alleen de verlichting is een APK keuringseis ook de bediening vanuit de auto is verplicht.
Nummerplaat verlichting is een APK keuringseis.
Mistlampen, voor indien aanwezig en achter minimaal 1 werkende. Ook het lampje op het dashboard in de auto moet hiervan werken.
Reflectoren dienen aanwezig en heel te zijn
APK keuringseis aan de staat van de verlichting is dat alles vochtdicht moet zijn en het lichtbeeld niet vertekend mag zijn. Glazen dienen helder te zijn, ongeverfd en mogen minimaal voor 25% afgeschermd zijn

Damic schreef op dinsdag 09 april 2013 @ 23:03:
Neem een wagen met een can bus en een start knop, kun je de starter al niet mollen want dan zodra de motor loopt word de start een stop knop (kijk maar naar Renault enzo).

De vraag is hoeverre die knop bij Renault puur een CAN-knop is of ook diep zit versmolten met de hele ECU. En de procedure die ik beschrijf zijn misschien 15 regels code, zijn we nou Tweakers of niet .

[Damic]

Start knop zit (denk ik) aan de teller unit die met can bus aan de ecu hangt

Trouwens je lampen e.d. is een comfort module die je apart via can kunt aanspreken (om met te spelen zeg ik maar).

[Dogooder]

Ik zou zeggen schuif dat start stop systeem even op de lange baan. CAN kan je vrij makkelijk uitbreiden achteraf dus waarom probeer je niet eerst een blower via CAN aan te sturen op een breadboard. Ik denk dat je hierbij heel veel leert wat misschien de implementatie van een start stop systeem vergemakkelijkt.
Zeker als je deze blower als een kritisch component behandeld. Maak wat oefen cases, dat CAN alles kan afhandelen wil nog zeker niet zeggen dat het makkelijk is.

[LauPro]

Ik heb inmiddels de AT90CAN128 binnen en super handig dingetje, een kleine testopstelling gemaakt en het werkt meteen. Het geheel kan eenvoudig met flatcables of headers op een andere print worden geplaatst.

In eerste instantie wil ik het volgende gaan maken:
• Print met relais.
• Bewaking op dat relais schakelt.
• Bewaking op dat gebruiker 'aan' is.

Waar ik echter een beetje tegenaan loop is dat de CAN bus voor auto's niet echt open is, ik heb nog geen duidelijk document of database gevonden met MOb's (Message Objects). Natuurlijk kan ik zelf wat verzinnen maar het liefst heb ik dat het conform de standaard is.

Ik heb geen zin om hele middagen zoet te zijn met in een bestaande auto rond te gaan rijden en te gaan sniffen wat alle waardes precies zijn, verder heb ik ook het idee dat het nog wel eens per auto wil verschillen. Er zijn bijvoorbeeld al wel libraries om een BMW dashboard aan te sturen, dat zou een optie kunnen zijn als uitgangspunt.

Wat ik nu zou willen doen is alle messages in een soort class te zetten welke de berichten inkapselt of uitkapselt.

Dit soort dingetjes krijg je dan:

Maar eigenlijk willen wij het geheel compatibel houden met het bestaande dashboard.

Ik zie ook dat OBD een standaard is naar buiten toe om de auto uit lezen maar binnen CAN (Automotive) is er volgens mij niet echt een standaard...

[ Voor 5% gewijzigd door LauPro op 13-04-2013 12:32 ]

[Damic]

Can bus is per maker verschillend soms hetzelfde wat betref berichten.

Als je met verschillende merken zit moet je eigenlijk bibliotheken aanmaken die dan als standaard kunnen gebruikt worden.

[Dogooder]

In de ruimtevaart wordt veel afgeleid van CANopen misschien kan je daar is op doorneuzen.

[LauPro]

Layer 1 / 2 geloof ik het allemaal wel maar ik ben echt op zoek naar specifieke layer 3 implementatie voor automotive.

Zoals het er nu naar uit ziet blijven daar inderdaad grote verschillen per merken.

[Garyu]

Dat is zeker afhankelijk van het merk, en binnen het merk per auto soms verschillend, aangezien dit soort systemen door verschillende leveranciers worden gemaakt.

[Dogooder]

Ik zou je toch nog een keer willen wijzen op CANopen. De CAN open specificatie richt zich op de hogere lagen van het OSI model. Lagere lagen is toch meestal gewoon RS-485. Er is dus geen specifiek model voor de automotive of aerospace (als het er wel is dan is dat closed source ) en zul je dus zelf moeten nadenken. Verder heeft CANopen specificaties voor redundancy en switch procedures en alles wat je maar nodig hebt om absoluut fail safe te werken.

[heuveltje]

LauPro schreef op dinsdag 09 april 2013 @ 22:04:
Over het op afstand starten: natuurlijk hebben we nagedacht over veiligheid, zo willen we checken:
- Dat de motor niet gestart is.
- Zijn de deuren ontgrendeld.
- Staat de versnelling in zijn vrij.
- Staat de handrem erop.

En ook belangrijk is dat de auto na het starten niet mag bewegen anders moet de routine meteen worden afgebroken.

Zet er ook een timer op dat ie na zoveel sec wel moet bewegen !
Je wilt niet dat die auto per ongeluk start als je je snachts je sleutels weglegt, en vervolgens die auto heel de nacht uitlaatgassen je garage inspuw !


Goed das een beetje worst-case doemdenken. maar je snapt mijn punt hoop ik

[ Voor 5% gewijzigd door heuveltje op 15-04-2013 09:53 ]

[LauPro]

Dogooder schreef op maandag 15 april 2013 @ 09:30:
Ik zou je toch nog een keer willen wijzen op CANopen. De CAN open specificatie richt zich op de hogere lagen van het OSI model. Lagere lagen is toch meestal gewoon RS-485. Er is dus geen specifiek model voor de automotive of aerospace (als het er wel is dan is dat closed source ) en zul je dus zelf moeten nadenken. Verder heeft CANopen specificaties voor redundancy en switch procedures en alles wat je maar nodig hebt om absoluut fail safe te werken.

In principe wil ik gewoon CANopen met pakketstructuur en CRC-checks handhaven.

Veel meer zal er niet aan de hand zijn. De CAN bus zal de registers bij de 'startmotorcontroller' vullen en zodra alle condities zijn bereikt zal de 'startmotorcontroller' daadwerkelijk de motor starten.

Ik zou eigenlijk alleen nog een bewaking op de registers willen hebben zodat als een register al enige tijd niet is gevuld deze errort.

C:

struct rval{
    uint16 value;
    uint16 timeout;
};

struct Register{
   rval motor_off;
   rval handbrake;
   rval doors_unlocked;
   rval gear_neurtral;
};

De rval.timeout zal bijvoorbeeld elke 10ms worden verhoogd met een maximum van 500. Met een wrappertje zou ik dan heel eenvoudig kunnen checken of de data nog valide is:

C:

bool is_valid(rval &v) {
    return (v.value == 1) && (v.timeout < 500);
}

Als ik het in C++ doe kan het mooi OO.

De functie die het register vult (CAN bus listener) zal bij het vullen de timeout op 0 moeten zetten en er mag geen race condition optreden tussen deze twee functies.

[Dogooder]

In CANopen is een heartbeat 'protocol' gedocumenteerd. Hiermee controleer je of al je nodes er nog zijn of andersom. Data die weggeschreven is in de registers wordt meestal een CRC check gedaan, of een parity bit, om te kijk of de data nog steed valide is.

Verder zou ik alles fail safe maken ipv van fault tolerant. Als er ergens iets fout gaat moet je kunnen vertrouwen op de oude simpele mechanica en electronica.

[LauPro]

Dat heartbeat protocol is meer gebaseerd op een beetje pollen. CRC op Eeprom had ik ook al bedacht.

Als ik een sensor heb die moet meten of een deur open is of dicht, en die sensor faalt, de vraag is dan hoe ver je hiermee moet gaan. Als ik het helemaal nerdie zal moeten maken dan zou ik bij elke schakelaar of sensor zowel het NO alswel NC-contact moeten gebruiken .

De sensor/schakelaar moet dan bij beide standen kunnen meten. Alleen in het geval dat de schakelaar mechanisch in de tussenstand zit dat er niets wordt gemeten heb je dan een situatie met twee mogelijkheiden:
- De schakelaar is losgekoppeld of een draadbreuk.
- De schakelaar zit precies op de tussenstand, deur niet goed gesloten zou dit kunnen zijn (dit mag pas optreden na 100ms).

Dan zijn er 4 statussen per schakelaar:
- Hoog 1 (NC hoog, NO laag)
- Laag 0 (NC laag, NO hoog)
- Fout 2 (NO en NC beiden laag zijn)
- Fout 3 (NO en NC beiden hoog zijn, mag nooit voorkomen, defecte schakelaar oid)

Op dit moment ben ik bezig om een uitbreidingsprintje te ontwerpen met bijvoorbeeld 8 uitgangen en 4 ingangen. Het kan zijn dat ik toch even iets kant en klaars pak maar veel van deze bordjes zitten aan de prijs en ik wil het liefst de lampcontrole er ook op hebben zitten.

Ik zit nog met een paar mechanische uitdagingen hoe we bijvoorbeeld gaan detecteren dat hij in zijn vrij staat. Het liefst zou ik ook willen detecteren in welke versnelling de auto staat. Ik kom dan bijna uit op een soort lichtsluismatrix van 3x4.

Tbc!