Design an ECU project?

I am not "in" because of time constraints and too many other projects in the fire. However, I've been thinking about doing this for several years for the following reasons:
1) It would be fun. I've seriously considered ripping the ECU out of a used Honda Civic and building one from scratch just for a learning exercise.
2) I hope to own a 360 someday and know that at some point in the future ECUs will start to fail.
3) I salvaged the 7.3L turbo diesel from my previous truck after it was totalled and would like to design an ECU so I could play with the engine.

My tact will be to start from scratch with a standalone microcontroller because I have experience there and don't want to deal with constraints from someone else's design. This requires programming in C (or some of its object-oriented variants) or assembly language. I've designed many real-time controllers in the past, but nothing recently so am not real familiar with the latest and greatest hardware. The web site you listed looks like a good start. Another good community to tap into is based around this magazine:
www.circuitcellar.com

For starters, regardless of how you proceed, I suggest that you begin by analyzing your timing requirements and diagram the processes you wish to implement. By "timing" I am not referring to ignition timing, although that will be included, but how long and how often the real time processes you want to implement need to occur.

My method for doing this is always to envision "slowing the world down." Imagine you can make time slow down by several orders of magnitude for everything but your own sensory system and brain. Now you can walk around and think about things as they occur in slow motion. I also strongly advise you become familiar with the concept of state machines. If that term is new to you don't let it scare you. It is simply a logical way to keep track of the state of different things going on and is often the key to breaking up a complex system of operations into a collection of simple tasks. State machines are easy to implement on a microcontroller and are often used in timing-critical processes. They also make it easy to debug a system and spit out error codes, so implementing a rudimentary OBDII diagnostic system would fall right into place here.

Lastly, start simple and don't even think about traction control for now. That will involve control theory and sophisticated feedback algorithms and is a huge project compared to just making the engine run and respond like you want. Not only will it require more compute power, but it will require a good knowledge of math and control theory.

OK I said I'm not in, but if you decide to implement state machines and need help designing them, I can pitch in there. That really should happen before you think about anything else.

I see from your profile that you are an ME so I am likely preaching to the choir re. most of the above. If that is the case, I envy you because this sounds like an awfully fun project, especially designing traction control. Glad you are doing this! I don't have your expertise with engines so I will be following closely and hope to learn a lot from your efforts.

 

I'm definately in.

 

Just as an aside - as many of the specialized cars age, those electronic components are going to need replacements.

This might be a good idea for an enterprising technical developer. Perhaps something of a "generic" set of control computers could be developed which could take the place of the hyper-expensive or just unavaliable original circuitry?

They could be specifically "programmed" for each application, but might not need much hardware changes.

Hot button issue with me, BTW - my 1995 Rolls Royce Silver Dawn has just lost the environmental computer in such a way that it would not run the AC compressor. Replacement part lists for around $4,000 and is currently NOT AVAILABLE.
We had to wire across it so as to run compressor all the time in the AC mode. Sponsor RUF Autocenter heroically came up with a specialist who could do this and took care of it for me as a new owner!

Yes, I know - Rifledriver is going to see this and say "I told you so." But, I reply -

If you cannot take the jealous ridicule, you should not be driving the flying lady!!!

 

Don't worry I'll just watch. Sounds like you got a good place taking care of you though.


I do think there will be a market for generic programmable 4-6-8 cyl units. Makes a lot of sense especially since Ferrari, Benz and Bosch all go up in price exponentially as the cars get older.

If designed with optional inputs for different systems and maybe a way to set baseline injector time etc. Seems like there is a future, possibly even a current market.

 

Agreed - I remember the hot rodder's lament back in the early 70s when they started to phase in smog control, some early fuel injection systems, electronic ignitions: HOT RODDING IS DEAD - they have killed us with robotics!

Now look at how far the aftermarket has come in electronic performance aids - chips, injection units, etc...I think that if it happens, it will probably be led by some of the more innovative SEMA suppliers who realize that there is a potential market.

BTW, they are still working on the Silver Dawn, and all of a sudden my "Immobilizer" fouled up on the 993 (by GAWD - if I were in Porsche marketing I would have come up with something else to call your security system) - so anyway, I am driving the old primative Testarossa this week - with it's brand new timing belts and so on.

Hans thinks I caused the Rolls Royce troubles myself by speaking in jest about Lucas Electrics.

 

Sorry. My dog occasionally runs after rabbit while we are hunting quail, too.

 

How about two HALTECH 6 cyl units, fly wheel fired...?

 

They'd have been OK if they did it the other way around.

 

What do the two fuel outputs per cylinder do? Why do you not need 12 ignition outputs? Educate me please.

So you have three tubes each going into four collectors?

Can you list ALL input and output sensors you will need please. Everything from throttle position to cam sensors, temp sensors, etc.

One suggestion for approaching this project is to break it up into 4 sequential steps:

1) Analyze and document. List all I/O requirements and document with flowcharts and state diagrams everything that will be happening. You might want to read up on UML (Universal Modeling Language), but it can be intimidating reading if this is not your area. Not to fear, it is just a simple concept that looks intimidating because it has become formalized to death by anal managers. It is a good concept though. There are formal documentation tools designed specifically for this, but MS Word and MS Visio will work just fine to do the same thing.

2) With timing, memory, and I/O requirements documented in step 1, choose a microcontroller board, keeping in mind cost of development tools (compiler, debugger, etc.).

3) Design a software framework to implement the necessary processes. At this point other design goals come into play, namely ensuring that the code is robust and easy to debug. It needs to have a watchdog timer and fall back to failsafe default outputs to all I/O pins if it loses its brain.

4) Code the application. I recommend C++, but I can't help here.

There are other approaches that may be better. This is just what comes to mind for me, based on my experience. I wouldn't worry about anything but #1 at this point and I and others can help with that. I do think it's important to begin by thoroughly documenting the process you want to control. I've seen many projects falter and suffer and drag on seemingly forever because there was no clearly defined detailed master plan for everyone to fall back on and use as a basis for communication and head-scratching. If something doesn't work right it is a lot easier to go back and look at state diagrams and think things through than look at software. If there is a problem it is easy then to see if it is a design problem or a software bug.

 

WoW !!!!

Don't have a clue what you are talking about but I am pressing my pants and shining my shoes for school.

DRIVE ON !!!! (pun intended)

 

And you think putting together the V12 is taking time... I will assume you already have talked to the various aftermarket ECU makers and they have no interest in what's you're doing. Being in the software develpment business for over 30 years, I hate to re-invent the wheel (or ECU in this case). Perhaps if you could find a product that does the bulk of what you want, you can put together an agreement that will allow you access to source code in exchange for (1) signing a non-disclosure and (2) turning over the rights to final product. Of course, the above assumes you have no designs on turning this into a business / money maker.

As stated before, the first step is the functional flow chart start to finish (again, if you have someone else's source code, this this phase will be significally easier - you will know what has been proven to work - I'm sure you understand reverse engineering). Anyway, once you have the functional specs, you will be in a good position to evaluate your options.

Fun stuff... as a hobby.

 

I'm throwing a monkey wrench at you here Mark, I know you ended up with practically a newly machined engine. any chance of making the heads DI, you can go back to 1 injector for your needs as the direct injection cools the combustion and requires far less fuel.

 

I am just going to throw a couple of ideas in here...... don't know how practical they are....
Possibility - 2 ECUs - one very simple one controlling idle circuit, one controlling throttle circuit. Use a couple of injectors spraying into the plenum for idling purposes, then an injector on each cylinder for the throttle duties. Idle circuit runs all the time and is pretty much a set and forget system only requiring engine temp. inputs to lean off as temp. rises.... in theory. Then use an off the shelf solution to handle the throttle duties as you no longer require multiple outputs.

OR - split the engine in two and run two ECUs essentially running a V6 or in line 6 each... split it bank for bank or cross the banks, whatever works for firing order. A two ECU system definately works (eg 348) and bypass's the difficulties of having a multiple output ECU which may enable you to source an off the shelf solution... may even be able to switch off an ECU and run on 6 in an 'economy' mode to get high MPG!

OR rip the engine management off an exisitng set up where a manufacturer has done all the hard work for you!! Example, pull all the injection stuff off a BMW 750 or similar and then re-map to suit, would be an awful lot easier.... Hey, if the BMW V12 is good enough for the McLaren F1 it should be good enough for Fcars and the McLaren F1 ran two injectors per cylinder on the V12 although I don't know what the rest of the injection system was based on- some research in that area perhaps? I bet it would be standard parts Bosch or similar...

I am big fan of not trying to re-invent the wheel... injecting performance V12s has been done, so it must be possible to adapt an exisitng set up to your application. Starting afresh with a new ECU is admirable, but a tough solution... you only have to look at the amount of work the Megasquirt guys have done to get to where they are now, literally thousands of hours of development by numerous individuals, some of them highly qualified - do you really want to start that process from the beginning again? Just thoughts.....

 

Maybe you should talk to these guys. They're running a Merlin V12 with a megasquirt. 24 injectors, 24 plugs and a lot of noise.

Redline's a -lot- lower though.

http://www.youtube.com/watch?v=j1X4-fBQFzE