updated 29 june 2019
in the simplest manual control system a physical switch (toggle, pushbutton) is operated by a person making a decision. nice and simple. for things like headlights it may be an ideal solution. brake lights seem simple, until you work in the complexity of turn signals, hazard flashers, headlights, marker lights (it's surprisingly complex). headlights are actually four filaments, left right, high low. ignition is on/off, ideally, but tachometer if present is another sensor and wire. basic safety features like fuel pump off when engine not running (via oil pressure switch) is another switch and another couple of wires. add these up and the most minimal, bare-bones hot rod has a fat and complex wiring harness and dozens of connectors.
traditional car wiring has complexity of a sort called "brittle" -- each component does one or few things. more feetch, more wires more sensors more actuators. for OEMs brittleness plus feature bloat helped set up the Malaise Era of the 1980's; vastly complex, poorly performing, unreliable, difficult to maintain and repair. by the 1990's embedded computer technology reached a scale of development that allowed compressing that complexity into one place -- a computer. (of course OEMs resistance to change, coupled with consumerism, simply expanded feature bloat that harmed the driving experience in other ways). but that's not the fault of computers. they're a great place to put complexity, if it's done right.
the toggle switch that controls headlights in the simplest manner does two things at once: the driver's intent ("lights on") instantly becomes electrical action ("power to headlamps"). to have a computer do it the intent part is divorced from the action part, so that 'intent' becomes the result of either a bunch of decisions based on data from sensors (unlikely for a headlamp) or 'data' generated by a person pushing the HEADLIGHTS ON switch.
in my roadster, as in some OEM car solutions, there is the absolute minimum, one wire, to each sensor (fuel level, temperature, pressure, etc), and each actuated device (fuel pump, headlamps, etc). there are no dedicated contacts or wires for "added" functions such as safety. for specifically headlights, computer involvement doesn't add much (maybe worsens). but for more complex decisions, like under what conditions the fuel pump should operate, there can be much value, increased reliability and safety, and even simplicity. rather than a car-ful of extra devices each performing one function -- oil pressure switch contacts dedicated to the fuel pump, plus attendant wiring -- a computer derives information from other sensors. if the computer is already reading engine RPM it can use that data to determine fuel pump on/off.
done right, complexity moves inside the computer as software. if you've ever tried to puzzle out the strange and complex logic performed by a steering column turn signal/brake light/flasher switching, you might appreciate just how complex these ad hoc solutions can be.
the roadster system has reduced lighting control to the absolute minimum
possible -- one wire (one "filament") on each corner front and rear; one wire
for headlights; one wire to the brake switch; three panel-mounted momentary
SPST contacts ("left", "right", "headlamps") that perform all lighting control:
turn signals, brake lights, hazard flashers, park and headlights. tail light
on/park/bright (brake) is PWM to one light.
this is the one computer that more or less looks like a computer. it is the only "display" in the car. the panel does three sorts of functions: displays data from the other computers; it "owns" the panel controls (left/right/headlamps) that send messages to the other computers to do things; interprets data from the other computer as a "system" and watches for faults (eg. overheating, oil pressure loss while running); logs data to an SDcard and some internal computer-y diagnostical stuff that you'd expect/want in a computer.
one software process looks at the endless stream of data from the other computers for anomalies, warnings, and errors, and controls a (blindingly bright) full-color LED and a clicker/buzzer. there's no need to visually monitor gauges to determine if things are OK (engine getting hot, etc).
the panel does not directly connect to anything in the car except the other two computers. the car runs fine without the panel. he panel logs all sensors and derived data in a spreadsheet, one line per second, about 20 datums at a time. a new log is started with every ignition-on event. logs are date-named.
the panel display is in "pages", with a big chunky switch selecting the
page. the most common is the instrument panel with the usual information bu
fairly exhaustive; MPH, RPM, temperatures, pressures, A/F ratio, etc. the
graphical meters display history of the last few seconds. other pages are a
rally computer with multiple hundredths-mile precision, with settable alarms
and rally features settable with one hand. other pages provide other "views" of
the car, and there is a diagnostic page that makes computer innards visible.
this computer connects directly to oil pressure, oil temperature, engine RPM, chassis MPH sensors and brake light switch. it controls the fuel pump, Accusump, the four corner LEDs (nose and tail lights) and license plate light, and headlights. on these are layered the controlling functions in software. a press of the instrument panel "LEFT" (turn) switch arrives as a "message" (data) sent from the panel computer that means "BLINK LEFT 13 TIMES". the chassis computer sets up those lighting functions based on htat message.
fuel pump action is derived from ignition off-to-on transition ("prime") and engine running status, which in turn is derived from RPM. the Accusump has a similar "prime" (preoil) logic and is otherwise on when running. oil pressure, air/fuel ratio, battery voltage, fuel tank level are read, smoothed as necessay (fuel tank slosh removed) and send to the other computers.
pulses from the ignition are counted as RPM, pulses from the transmission as MPH. (speedometer calibration is stored as a number in the chassis computer; but but peedo calibration can be initialted via panel computer switch presses.) RPM is used to derive "engine running" status and the cooling computer likes to know MPH so that it can turn off the fan above some speed.
the chassis computer is not all that busy, but it has a lot of wires running
to it, so it's main purpose is concentration and wiring simplicity, not
the cooling computer electrical inputs are temperature sensors in the cylinder head, radiator outlet, and oil sump. the outputs are the main cooling pump, a smaller circulation pump, the big radiator fan, and the oil cooler fan. pump/fan speeds are vary slowly and smoothly via PWM, not with the on/off of relays. the cooling computer cools the engine, only, and is computationally complex, and described elsewhere in detail. there is no thermostat; temperature is entirely software-controlled.
the cooling computer accepts data "hints" from the other computers
(aforementioned chassis MPH, battery voltage) and has some manual features
accessible from panel diagnostics but it is otherwise silent.
the final feature of this system is that the three computers are interconnected in a network. each computer listens to all of the others, for data that arrives as messages ("mph is 50") ("oil pressure is 40") and sends whatever sensor or derived data is produces as messages ("cooling fan speed is 30%"). the cooling computer doesn't care about how much fuel is in the tank; the chassis computer has no use for cooling pump speed. but all computers store all data messages even if they are not used.
there are many failsafes built into this system, but an important one is
based upon this data redundancy: whe each computer starts/restarts, it
announces this over the network. when any computer sees this message it
responds by sending it's cache of the most recently-received data collection.
this means that a crashed computer recovers in a tiny fraction of a second,
back to full operating state. this, along with other stateless reliability
design features, was my response to the "Toyota unintended accelleration
problem" in the famous death cases caused by Toyota's bad code.