This page is left from an early program stage and is outdated on several items

OOBD is written in Java ™ to reach the most major platforms. It consists of an UI independent core and different interfaces. The actual platforms are:

• Desktop (Netbeans)
• Mobile (JavaME & LCDUI) (outdated, not supported anymore)
• Android

Some elements & functions are optional and not available on all platforms

Also the functionality is different

To keep the concept as flexible as possible, the different elements are as generic as possible (we could also call them stupid) - only in the context in which they are running they are doing something senseful.

In normal programming speech, such elements would be called modules. But as we'll have also electronic modules in the vehicle in the end, I call them elements instead.

The following elements are foreseen:

The Core provides abstract interfaces to

• the filesystem
• a kryptosystem for encrypted data
• lookup functions for databases
• user dialogs

A scriptengine provides the interface to a list of functions which can be called by the visualizers. It also provides information about the Menu Structure.

The functions are programmed in lua. When a function is called, the function call is supported with a set of parameters (packed as an Onion):

• the previous value
• the reason of the call (in most cases this info is obsolete, but at least the script could handle these different cases)
  • Init - the function is called the first time, the visualizer wants to initalize the output
  • manual update: the user asks for an value update
  • automatic update: a cyclic update, requested by the UI
  • change: A new value is requested to be set

* the ID of the calling element

after the function call has been proceeded, the script engine returns a set of results (again as an Onion):

• the ID of the calling element
• the raw data
• an error code (0=ok, everything < 0 is an error)
• the processed value
• the unit
• the minimal value
• the maximal value

Please keep in mind, that such a function result is given to all visualizers, just because only a visualizer itself can decide if this data might be useful for him or not (Hopefully that will not give us a performance problem…)

The visualizers are the interface between the user interaction, when he's doing testing, and the system itself.

When a new script is loaded through the core, the scriptengine tells the core what kind of visualizers are foreseen by the script, and then the core tries to load and place these visualizers. more details

Connectors do two things at a time

• they support the possibility to connect to another remote instance of SKDS
• they listen for any incoming connection request

Each connector supports only one communication protocol (like local, Telnet, Skype, Jabber or whatshowever) and do both build up outgoing connections as also answer incoming calls.

To make this principle work between different programs, where one program is the local and the other program is the remote side, the data flow between local and remote side is standardized in the so called OOBD protocol. This protocol has to be followed to guaranty the compatibility between different programs.

A connection is started when a scriptengine reqests a connection to a protocol & bus. Each Scriptengine can have several connections at a time, represented by a connectionhandle. The core is managing these handles and release them on request or when the scriptengine is terminated.

1. the scriptengine tells either a fully qualified connection URI or just parts of it, but at least protocol & bus must be specified.
2. when no connector is given, the user is requested to choose one of the available connectors
3. if no connection identifier is given, the chosen connector than requests additional parameters like destination IP- Address, user name & password through an configuration dialog.
4. then the connector tries to connect to the remote side. If this succeeds, the remote connector reports if the requested protocol/bus combination is available.
5. if the connections fails, the user is informed by the 'userinfo' text string about the reason. Also with a positive result this message can be displayed.

The protocol translates the incoming byte stream into the format which is required on the bus that the modules in the car understands the message.

On request, the protocol requests from the local available buses which buses are available. The buses then answers with a “provide” answer which buses are actual available. The protocol then chooses the first bus which fulfills the incoming request. This repeats each time when a new bus type is requested, as it could be that a bus driver can control different bus types or speeds (like 11-500kbCAN and 29-125kbCAN) at the same time or not.

the protocol keeps track about which bus format it has already allocated and forward all incoming data to that bus.

A bus is the interface between the protocol and the physical hardware which puts the messages on the vehicle bus. This can be a simple IO- control for a K-line or an complex driver which sends the telegrams via Bluetooth to a hardware device.

Onions are the generic datatype which is used to transfer the necessary information in the chain from one element to the next.

From the logical view an onion is similar to an XML structure, but as xml is much too complex to be handled by e.g. simple microcontroller on a hardware device, we use something more simple.

An onion is a hash array, means a set of key:value, where a key is always a string type, and each value is either a base type (string or integer,called leaf) or another hash array, called node.

The onion class provides all methods and properties to encapsulate the generation, modification and deletion of these object (as the internal structure can always be changed in the future)

The menu description below is outdated

The title “menu structure” might be a little bit misleading, but the name “menu” came from the old SKDS, where each measuring value was called a “menu item”. Where is it about?

In SKDS we want to use the same functionality in the scripts on different devices. On a full featured desktop application we want to have screens filled with diagrams, tables, buttons and wizards, while on a mobile we'll have nothing more as a simple list of values.

To realize this, we need to have to make things a little bit complex:

# the surface, on which all actual menu items are visible, we call call a page. This also means that a page contains list of menu items. # before leaving the previous page, the scriptengine is asked to run the function “pageexit_<pagename>”. Only if the result is true, the old page is left # before loading a page, the scriptengine is asked to run the function “pageload_<pagename>”. Only if the result is true, the new page is loaded # When a scriptengine is loaded, the scriptengine is initially asked for the menu items of the page “root”. # when loading a page, the scriptengine returns an onion- object about the menu items of that page containing the following data: ## type ##* page (goes to another page) ##* return (goes back one step in the page history) ##* 1 of n: If read-only, than it's only a string. If changeable, that it could be drop down or radio button group ##* Boolean: A special case of the 1 of n. ##* string (where the given minimal value field can be used as a regex filter ##* numeric (float or integer) ## the Caption (used for labeling) ## Description ## the initial value ## the unit ## the minimal value ## the maximal value ## the icon name - is there an icon to be shown (ICON_NONE if not) ##* the icon with that name is first searched in the script directory ##* and than in the program/script folder (recommended) ##* if the icon couldn't be found, icon ICON_NOT_FOUND is used instead ## and the layout information ##* column, row, width, height and alignment

On a simple device, the page layout just lists the above received value and descriptions and shows them one below the other.

A desktop page layouter will place all visualiers accourding to the given row, column, width and height onto the page cell grid and will try to find the best adjustment for row and column sizes.

During startup, the client first scans through the included package directories for bus-, protocol-, script engines-, connector- and visualizer classes, load them and store their names and other parameters in its internal lists.

Then it adds the script engines found to the users selection menu as the starting point for the user.

To start operating, the user selects the type of script engine he want to use. The script engine will then be loaded and takes over control.