All the possible auxiliary functions that an EMS can be put to,
and all the pin choices available, and all of the pin and IO modes
(ADC, digital in, digital out, PWM out, CANbus in/out, etc.) and
all of the possible algorithm choices to control them amount to a
combinatorical explosion.
This complexity is, I believe, a big factor in the mess that MS
appears to have become. Organic growth, and gradually accruing
features make for a complex, nasty, and incomplete means of
configuring the EMS.
This problem is something that I have been mulling over for some
time. I believe the solution to the problem of configuring a
custom EMS is a small Domain Specific Language[0].
A well designed DSL would maximize the expressive power available
to specify the configuration of a custom EMS. A GUI interface
cannot even come close, though simpler user interfaces could be
built on top of it, and the underlying language would overcome
any shortcomings of the UI if access to the code that the UI
creates is kept open.
Let me quote Greenspun's Tenth Rule of Programming:
"Any sufficiently complicated C or Fortran program contains an
ad-hoc, informally-specified, bug-ridden, slow implementation of
half of CommonLisp."[1]. Let's take care of this one explicitly.
Ultimately, whatever scheme[2] is chosen to allow configuration
of non-core functions, the pins will have to be abstracted, the
parameters will have to be abstracted, and the algorithms will
have to be abstracted. Better to do this explicitly, at the
outset, and have a clean API for hooking shit up.
In the case of an EMS, obviously the overhead of interpreting a
DSL will be too high[3]. On the other hand, a compiled language
can run almost as fast as hard coded values and logic, and
possibly run even faster than a spaghetti mess of rules and
configurable constants. This compilation could occur in the
tuning software[5] to simplify the firmware.
Another advantage is the ability to make some parameters
generically dynamic, for instance, set up a PID loop in such a
way that it gets its P, I and D constants (and the cut-off value
and cut-on, etc) from a pointer, rather than a hard coded value,
or one that is set once in the tuning software. That way a
function can run from time to time to auto-tune the PID
constants[6]. PID constants, or other constants, could also
easily be modified for situations like cold-start, or overheat,
etc.
How would it work? Simply an ASCII stream run through a compiler
that does the backend magic.
Example:
Code: Select all
# Dynamic variables for the eFan PWM PID controller.
object fan_control_params (
integer P
integer I
integer D
)
# Electric Fan control
for pin PT5 (
name "PID PWM fan control"
schedule absolute 1000ms # Run once a second.
input CHT
controller pid(fan_control_params.P, fan_control_params.I, fan_control_params.D, setpoint=100)
#Less to more important.
if input under 80 (
output off
)
if input hysteresis 120 125 (
output on 100%
pin PT6 on # GPIO High speed fan relay
)
if input over 130 (
pin CANBUS.DASH.OHL on # On dash overheat lamp
)
if input under 128 (
pin CANBUS.DASH.OHL off # On dash overheat lamp off
)
[7]
For a User Interface, this kind of output is trivial to produce
for known sensor/set-up combinations. In the event that the
desired configuration is outside the considerations of a GUI (for
example, the CANBUS.DASH.OHL overheat lamp above) manual
editing of the config code makes modifications trivial.
Fred, I'm not suggesting that this is what you need to build. To
me[8], this seems like a masters level dissertation in computer
science. I'd expect it to take a competent programmer six months
to get right[9]. That said, if this kind of design becomes the
ultimate goal, the abstractions required can be built into the
code in a way that it can fairly easily become a virtual machine
for future bytecode. Think to the future. Much of this stuff can
be handled in the present with #defines and constants. So long as
you operate on a memory address, rather than a value, you can use
a compiled DSL to specify and initially populate the value at
that address. I think the MCU has the grunt to handle at least
that much indirection. Think about looking up functions in a table
also.
Respectfully,
sim
[0] Postscript is a Domain Specific Language. So is LOGO, and
BBcode.
[1]
http://c2.com/cgi/wiki?GreenspunsTenthRuleOfProgramming
(For the record, I'm not a Lisper, I may not be smart enough.)
[2] Pun intended.
[3] At least, for now. At some point in the future we can assume
a processor will become available that is fast enough and
cheap enough to control an engine with code written in Visual
Basic[4].
[4] Aiiieeee! Run!
[5] Probably a library, or an external console based program.
[6] Other stuff that we haven't even thought of yet also
becomes possible, possibly even easy.
[7] Consider this a quick sketch of how it might work. I have not
given much thought to the syntax of such a DSL.
Missing is the semantics of how the constants P,I and D are
populated.
[8] I am not qualified to estimate at this level.
[9] Given a lotto win, I'd love to spend six (or twelve) months
on this problem, given reality, it will be a few years before
that is possible.
A PID controlled PWM eFan is one of my pet projects, can you
tell? Water pump is next.
