Multi-processor Engine Management

[Bernd Felsche]

John Dammeyer writes:

>>From: Bernd Felsche <bernie at perth.dialix.com.au>

>>>>From: "Jack E. James" <indyjj at indy.net>

>>That's actually done in many multi-bank engines. Only recently has
>>there been sufficient "processing power" been available to run a V8
>>as well on a single CPU - according to the big makers anyway. ;-)

>Depends on the level of controllability desired I guess.  For
>emissions control I suspect that is true but for engine control
>less so.

The other problem was of course the range of operation of the
air-flow meters... a smaller size allows better control at low
engine speeds. It's like adding an extra bit of resolution.

>>>>flow loss.  Or one controller for part throttle and another for
>>>>full throttle.  Just curious about multiple processors, having
>>>>thought about using some of the faster PIC,s for each cylinder.

>>Running each cylinder on its own is probably not that good an idea
>>IMHO as it's the whole engine you need to control. The necessary
>>interchange of information is probably going to be the limiting
>>factor.

>This is what I was referring to later on in my previous posting.
>By the time you add the input filtering for each of the sensors for
>the individual boards your costs and complexity go way up.  If you
>have common filters for the sensors and supplied the values to the
>individual processors as linearized and scaled all on one board
>you're at the point where the question is... why bother with a
>bunch of little processors and just use a big one instead.

If the big one lack inputs/output or a particular facility, then it
may be wise to use a separate processor with the necessary
facilities; instead of using dedicated hardware or cooking up
external multiplexing, etc.

It's a way of minimising the complexity, but allowing for expansion.
You could use the same main controller for one, two, three or four-
cylinder operation, then add identical "co-processors" to handle
engines with more cylinders. (A 32-bit RISC controller could
probably handle 8 cylinders with ease. But it would struggle with
18.) You could also add on auxiliary processors to handle
supplementary functions which don't fit well into the core function
of engine management - e.g. OBD-II, data logging, CAN, etc.

That means you use the same core for all engines - it, and the
co-processors become a building blocks for future projects.
Each building block is relatively simple to implement. That improves
reliability as the interaction of functions, and the inherent
problems arising are reduced.

One processor per cylinder (or function) is probably the extreme 
in terms of cost.

>[snip]
>>Nor is it useful because all injectors wired in parallel and
>>separate wiring would require another output (which is "available")
>>and a separate harness/connector-pin to group the injectors.

>I've always considered 'proper' fuel injection as multi-port
>sequential so I tend to forget that it's also possible to bank fire
>on each 360 crank stroke.

You won't forget after this discussion. :-)

>>>i.e. With a one cylinder engine and a 720 degree cycle you have a
>>>total of 4 events to manage; Injector on/off and coil current
>>>on/off.
>[snip]

>>You could use a common interrupt (clock) for crank position. Each
>>PIC can be told to watch for a particular clock tick for each event.
>>There is the constraint of feeding counter information quickly to
>>the PICs in time.  It's conceivable though, that a "broadcast" to
>>all the PICs could be used to give base information and to have each
>>perform some simple arithmetic to determine appropriate trigger
>>values. Think of it as having a scalable number of counters with
>>multiple output-compare registers (OCRs).

>>With a small number of cylinders and "common" events, that's not
>>necessary, especially if you can reset the OCRs quickly enough.

>Now who does the broadcast?  Another PIC?  That's 7 PICs for a 6
>cylinder engine.

It would have to be a more complex management unit. Mainly due to
the limited arithmetic capabilities of PICs.

>>>Now let's talk cost.

>>Read about internal packaging option below.

>>>Just throwing two MAP sensors into the engine for two controllers

>>If you look at the possibilities presented by high-speed
>>inter-processor busses and cheap packaging options such as SIMM,
>>then a scalable option, at least for the data-acquisition and driver
>>sections becomes attractive.

>>The high-level control strategy is probably better achieved by
>>a "proper" CPU with sufficient address and physical memory space as
>>well as crunch capability, driving the slave processors.

>Well... that same scalability is also there with a C167C 16 bit
>RISC processor architecture though and it has a heap of OCR type
>timers.  It has enough to dedicate one to each event (injector and
>ignition) and is fast enough to handle everything.

I'm not familiar with the scalability of the C167C; I will look it
up though... how do you add extra OCR's/counters to extend your
two-cylinder controller to run 18 cylinders, for the sake of
argument? Got a URL?

>I used the Philips 80C592 because it had 5 OCRs.  Even then I ran
>into timer sharing problems because I used sequential injection and
>there are times when the new pulse width for cyl. X will suddenly
>need to start before the pulse for cyl. Y by 5 or 6 clock ticks.

>By the time the new compare values are installed and handled cyl X
>injector may turn on but the turn on point for cyl Y is passed so
>the injector misses a cycle and results in an engine miss.

Ah - so you had a scalability problem. :-)

>>I initially brought up the possibility of using multi-processors as
>>a means of expanding capabilities of the specialised chips which,
>[snip]

>Most of the smaller specialized chips (PIC in particular) are
>really poor at 16 bit math operations and if your counter needs to
>handle timing between TDC and BDC at Cranking and at 7000RPM you
>need to be able to manipulate 16 bit values.  Add to that the math

Good point. Something as simple as a PIC would however be relegated
to watching the common clock and toggling outputs for ignition and
fuel. The appropriate clock tick can be calculated by the PIC as its
offset from the "distributed" value provided in the broadcast from
the main processor. (For tight control - each PIC could have presets
provided by the main processor for cylinder-specific spark timing
and fuel trimming.)

>to handle enrichments and 32 bit results become a reality and the
>small 8 bit processors fall flat on their face.  It can be done.  I

Those high-level functions should be handled by the high-level
controller.

>just had to write a specialty 32 bit library of routines for  a PIC
>used in a Oil Well Down hole operation (sin, cos, arcsin and square
>root).  Physically the board was large enough to hold a C505C from
>Infinion but without the Flash ability there would need to be a
>large program storage device.

I don't believe that sort of complex arithmetic is required for
engine control. Given the low resolution of inputs and outputs,
those sorts of functions can be approximated by up to second- and
third- order terms of Fourier series if they became absolutely
necessary.

>>The question of scalability remains: If you run out of capacity, do
>>you perform a leap in architecture, or do you use tandem processors
>>for the required functions?

>I'll do the leap in architecture.  The C167C can use an 8 bit
>external bus for program storage and there are some nice FLASH
>parts around for holding code.  So if I do another
>ignition/injection system,  I'd use the 167.  I'd have the RISC
>speed like a PIC,  large program addressability and 16 bit math
>operations plus the built in A/D and OCRs.

So you reckon it'll run a W18 engine with a single controller? :-)
Currently takes 3 Motronic units. One per V6.

>For the bigger 8 bit family check out www.lawicel.com for the C505C
>with WSI FLASH/EEROM/RAM/PLD as an example of what can be done
>inexpensively.  With the Keil or Tasking compiler 32 bit longs (and
>floats) (although still clumsy) are available.

I can do 32-bit arithmetic using 8-bit registers. No need for a
fancy compiler. :-)

>>The trick may be to gaze into the crystal ball and see where that
>>wall is located - and see if it matters.

>I have one of those....  but it's opaque.

All the more reason to consider scalability.

-- 
Real Name: Bernd Felsche
    Email: nospam.bernie at perth.DIALix.com.au
	http://www.perth.dialix.com.au/~bernie - Private HP
----------------------------------------------------------------------------
To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes)
in the body of a message (not the subject) to majordomo at lists.diy-efi.org