VEMS Home Products Documentation Wiki Webstore
WikiHome ProjectPage DocsPage UnderDevelopment MembersPage SiteIndex RecentChanges Preferences
OtherTuningSoftware/CommonInfrastructure

This page is for tuningsoftware developers

The common infrastructure will save lots of work.

Aim:

Tools:

Not yet common - every implementation does it's own way

Some of these will never be merged.

Beware: the rest is outdated, feel free to clean up

According to the plans, the minimum required functionality of any tuning software should be:

Also advised (but not absolutely necessary):

The "professional" tuning software is probably going to be written in Java (maybe an improved version of OtherTuningSoftware/JTune). This software should run on every platform, including PDAs, and it should also provide useful tools for advanced tuners (like log file handling, charts, histograms, etc). Other tuning softwares can be very useful (for example, a win-based sw for dumb users), and they should also implement these functions in order to be absolutely parameter-compatible.

header file: global.h

mcd file: a text file containing config_t numbers in numeric form together with their header file names (in "name=value" format). mcd files can be downloaded from the board

via serial connection and then loaded back into the tuning software

config_t numbers: the bits/bytes/words of the config_t structure in the header file

parameter: the humanized representation of config_t data, can be booleans/integers/real number

group: a set of parameters and/or other groups

The layout file consists of:

Data types can be defined and constructed from the following components:

So a parameter can be either a boolean, an integer or a real number, determined by the data type definition. Parameter arrays (one or two-dimensional) can also be used similarly to single parameters (one name, dimension(s) of the array, reference to the config_t bytes, and one data type).

A config file contains, for each property:

And for each group:

Note that the firmware doesn't care about confidence or comments, the user cares - absolutely:

The magic word is maintenance. When someone starts to make his configuration there are config files flying here and there

Natural view

The natural listing of properties is a tree browser. This is a direct view (and controller, as it allows changes too) on the model, very human friendly in this case. (The other view/controller is the mcd file, which is firmware friendly, and relatively close to the model, but not direct).

Eg. the config subtree would hold configuration parameters of an ECU. The leaves are human (rather than mcd) terms, eg. it can be an ON/OFF flag bit that is a separate property, that naturally maps to a bit of a byte in the mcd structure (the same byte would hold other flags too).

There would be an other subtree, called runtime. This would hold entities fetched from engine operation. Most of these cannot be set, only viewed, and collect statistics. But some can be set as well.

Note that having a primary tree structure does not stop the user to make composite controllers and views in any combination. Just drop nodes to a form to collect what you want to see on one form.

The key is to have very simple properties in the leaves that are easy to present, explain and for the user to change, and for us to store the result.

When we have this, the rest is very simple: a composite cockpit (of different type properties os same type, like for the tables) is nothing more than a collection of several, simple views of simple individual properties. Note that the view of a property can be textual or graphical (like a gauge). Both can be packed to the same window if one wants.

This is only a rough draft yet, please add your comments.

Sounds mostly reasonable. A few points I've discovered so far:

Other thoughts:

-- Rich.

First Java class definitions are in the CVS JTune module. Should they be interface definitions from the start, or is it OK to just later extract the interface from the classes when it's needed (to substitute alternative implementations) ? (eclipse helps extraction).

The plan is to model in java (only a tiny bit more work than UML or broken drawing tools, but it needn't be thrown away, maybe just refactored - we use eclipse so that should be easy).

The other logical choice would be defining in XML, as in the (brilliant!) entity engine of http://ofbiz.org . A 3d possibility would be SQL, so CMP EJBs can be generated from them.

the drawing is not here, but I scetch some thoughts from memory

Also check the XML format that http://www.deltasighk.org/miata/winlink/default.aspx uses for similar formulas.

ConfigMetadata can be attached to ConfigElementGroup, or ConfigElement (simple or compound) or an element in the matrix

When we have the [treebrowsing], and the display/set widget for changing the leaf types, we have a nice tuningsoftware. It seems to me we will need the tree structure even on PDAs: the offtheshelf swing implementation doesn't help there, but the child nodes can be displayed and reached with a click from a parent node.

Logging:

We should make a nice module (that heavily uses histograms) that extracts and displays nice info from the log streams (wether they came from rs232 or file coming from mmc or internet).

Useful tools

something between the widget and the physical layer

Also something for navigation (a layout manager) among the large number of parameters, a tree-browser or some other way.

I knew for a long time something is missing from here. Now I know what was missing:

we need a simple object that knows about 2 values of a given parameter and implements sync strategy

The last capability allows huge flexibility:

Some of this SyncManager functionality is needed anyway, it's better not to scatter it all around classes. If we have it separated, it becomes very powerful.

The beauty of it is that both sides around it (the widget and physical side) are simple and the SyncManager itself is also simple.

Note:

The SyncManager is a good place to hook observers, that can (for example) take logs or fire alarms when necessary.

everyone's homework: get a copy from the book "Design Patterns" (Erich Gamma, ..., ISBN 0-201-63361-2) from your tech library, read the

You'll find it absolutely useful. Even though I was somewhat familiar with everything, seeing it written with a nice vocabulary will make sure we can talk about the design easily and makes it easy to find if we are on the right track at a given point.

If you have an electronic file of the book or the given chapters, link here. There is a DesignPatterns wiki somewhere also.

Configuration As a Tree

In order to come up with a clean way of understanding/describing the interface to the genboard, I've been reading MegaTunix's MSNS datamaps. The following is a really rough draft of organizing the genboard's interface as a tree:

\\n
<table name="loadtable" cols="8">	
	<min value="0" />
	<max value="255" />
</table>

<table name="rpmtable" cols="8">
	<conv dir="upload" value="100 *" />
	<conv dir="download" value="100 /" />
	<min value="0" />
	<max value="25500" />
</table>

<fuel>
	<!-- add vital fuel config info here. -->
	<enrichment>
		<priming>
			<max value=25.5 />
			<min value=0 />
			<offset page=0 octet=119 />
			<conv dir="download" value="10 *" />
			<conv dir="upload" value="10 /" />
		</priming>
		<cranking>
			<table name="cranking" cols=2>
				<offset page=0 offset=64 />
				<conv dir="download" value="10 *" />
				<conv dir="upload" value="10 /" />
				<max value=25.5 />
				<min value=0 />
			</table>
		</cranking>

		<warmup>
			<table name="warmup">
				<max value=255 />
				<min value=0 />
				<offset page=0 octet=68 />
			</table>
		</warmup>

		<accel>
			<tpstrigthresh>
				<max value=25.5 />
				<min value=0 />
				<conv dir="download" value="5.12 *" />
				<conv dir="upload" value="5.12 /" />
				<offset page=0 offset=83 />
			</tpstrigthresh>
			<accelenrichdur>
				<max value=25.5 />
				<min value=0 />
				<conv dir="download" value="10 *" />
				<conv dir="upload" value="10 /" />
				<offset page=0 octet=84 />
			</accelenrichdur>

			<coldenrichaddon>
				<max value=25.5 />
				<min value=0 />
				<conv dir="download" value="10 *" />
				<conv dir="upload" value="10 /" />
				<offset page=0 offset=82 />
			</coldenrichaddon>
		
			<coldenrichmult>
				<max value=255 />
				<min value=0 />
				<offset page=0 offset=123 />
			</coldenrichmult>
			

			<table name="accelenrich" cols=4>
				<max value=25.55 />
				<min value=0 />
				<conv dir="download" value="10 *" />
				<conv dir="upload" value="10 /" />
				<offset page=0 offset=78 />
			</table>

			<decel>
				<max value=255 />
				<min vlaue=0 />
				<offset page=0 offset=85 />
			</decel>
		</accel>

		<ego>
			<egoactivetemp>
				<max value=215 />
				<min value=-40 />
				<conv dir="download" value="40 +" />
				<conv dir="upload" value="40 -" />
				<offset page=0 offset=86 />
			</egoactivetemp>

			<egoactiverpm>
				<max value=25500 />
				<min value=0 />
				<conv dir="download" value="100 *" />
				<conv dir="upload" value="100 /" />
				<offset page=0 offset=120 />
			</egoactiverpm>
			<egoswitchingvoltage>
				<max value=5 />
				<min value=0 />
				<conv dir="download" value="51.2 *" />
				<conv dir="upload" value="51.2 /" />
				<offset page=0 offset=122>
			</egoswitchingvoltage>

			<egostep>
				<max value=255 />
				<min value=0 />	
				<offset page=0 offset=88>
			</egostep>
			<egoignevents>
				<max value=255 />
				<min value=0 />	
				<offset page=0 offset=87>
			</egoignevents>

			<egolimit>
				<max value=255 />
				<min value=0 />	
				<offset page=0 offset=89>
			</egolimit>

		</ego>
	
	</enrichment>
	<ve>
		<loadtable page=0 offset=108>
		<rpmtable page=0 offset=100>

		<table cols="8" rows="8" name="vetable">
			<max value="255" />
			<min value="0" />
			<offset page=0 octet=0 />
		</table>
	</ve>
</fuel>


<ignition>
	<!-- add ignition parameters here -->

	<advance>
		<loadtable page=1 offset=72>
		<rpmtable page=1 offset=64>

		<table cols="8" rows="8" name="igntable">
			<max value="89.97" />
			<min value="0" />	
			<conv dir="download" value="2.84 *" />
			<conv dir="upload" value="2.84 /" />
			<offset page=1 octet=0 />
		</table>
	
		<trimangle>
			<max value=89.97 />
			<min value=0 />
			<conv dir="download" value="2.84 *" />
			<conv dir="upload" value="2.84 /" />
			<offset page=1 octet=82>
		</trimangle>

		<fixedangle>
			<max value=89.97 />
			<min value=0 />
			<conv dir="download" value="2.84 *" />
			<conv dir="upload" value="2.84 /" />
			<offset page=1 octet=81>
		</fixedangle>
	</advance>
</ignition>

I've used XML/HTML/SGML-like syntax, because it's something most people understand. I don't particularly care for it; the important part is representing things as a tree.

The other thing that's different is the way I'm representing the conversion step. I'm using postfix notation instead of traditional infix notation (every day algebra). This is because it's easier to parse/execute postfix (using a simple stack) than infix.

-Alexander

libraries we are likely to use

though under evaluation currently

OtherTuningSoftware/CommonInfrastructure/Abeans

interesting programs to get ideas from