Hi all,
I've been asked to note some observations here for discussion, in regards
the tizen.vehicle api exposed into the Tizen 3 wrt. Please cross-reference
TIVI-2294.
The AMB WRT plugin portion of wrt-plugins-ivi exports the vehicle namespace
into Javascript as tizen.vehicle. Within this namespace, the plugin makes
available the following API functions:
supported()
listZones(string Name)
get(string Name, optional number Zone)
set(string Name, optional object containing Value and Zone, optional
callback Error)
subscribe(string Name, optional callback Success, optional number Zone)
getHistory(string Name, optional number Zone, optional time Begin, optional
time End, optional callback Success, optional callback Error)
The function supported() returns an array of strings representing valid
names. The function get() accepts one valid name, and optionally a zone,
returning vehicle data in a result tuple of the general form
{valueName:x,sequence:y,time:z}. This set of functions is intended to be
used to in Javascript for a WRT widget to retrieve arbitrary vehicle data,
in the sense that a WRT widget is to use this API to retrieve data of a
type not necessarily known to the AMB maintainer at compile time.
There is some awkwardness in the separation of Name and Zone, in that both
must be present to uniquely identify a datum of interest; in database
terms, Name and Zone are components of a multi-field key. There is also
some additional oddness in the manner in which Zone is implemented; in
get(), the zone is provided as a parameter, while in set(), the zone is
provided as a field of an object. Instead of having an API with multi-field
keys, in which the multiple fields occur in different parameters and in
different formats from call to call, it would be preferable to use a system
having a single-field key.
The Zone field is implemented around the assumption that it is advisable,
or even possible, for the plugin maintainer to determine the segmentation
of all vehicular data areas industry-wide. The existing implementation
requires the AMB maintainer to define a matrix to accommodate all possible
zones for all possible vehicles, which in turn mandates that all possible
OEM-proprietary zones are included in GPL-licensed source code. This
approach then requires the OEM plugin designer to assign every signal to
some node of the AMB matrix of zones.
While a certain Front/Middle/Back, Left/Center/Right segmentation is
natural and obvious to web programmers familiar with such terms, those
terms in no way capture the divisions of sensor categories in current
vehicles. For example, accelerometry sensors subdivide into
linear/rotational, x-axis/y-axis/z-axis, and primary/secondary. They may
also subdivide into front-left, front-right, rear-left, and rear-right, if
a vehicle has an independent accelerometry sensor set at each wheel. An AMB
maintainer may not know whether or not any such vehicle exists; but any
such lack of knowledge does not preclude the existence of such a vehicle.
It is not advisable for Tizen to limit the segmentation of vehicle sensor
classes to only those subdivisions of which any given maintainer is aware.
Meanwhile, at the HMI level, a Javascript writer can only write explicit
code the handle each independent case. Code written to handle such explicit
cases frequently proves to be brittle when exposed to situations for which
it was not explicitly designed.
So overall, except for the omission of an unsubscribe() call, and issues of
the assignment of signals into zones for use with a non-vehicle-specific
HMI, and the requirement that all zone information from all OEMs be built
into GPL-licensed source code, the API would work for circumstances in
which the vehicle is completely known prior to AMB compilation. The
resulting Javascript code will be complex, awkward to port across multiple
vehicles, and use coding styles that are believed to produce buggy
implementations. This situation is not believed ideal.
A preferred approach alters the supported() function, with minor changes to
set() and get(), minor simplification of subscribe() and getHistory(),
addition of unsubscribe(), and removal of listZones(). The resulting API is
more generalized. It absolves AMB from having any specific knowledge about
how the signals passed through it relate to physical locations in the
vehicle, while still allowing OEM plugins and HMI interfaces to communicate
about zone-like locations via either a common, standards-based structure,
or an OEM-specific proprietary structure, or both within the same vehicle.
This preferred approach would be for the call to supported() to return
objects, each object containing a unique identifier (UID) to be used in
later calls, and a set of attributes or properties sufficient to
individually describe a specific vehicle datum. In common popular parlance,
each object would have a UUID and a tag cloud. For example, a vehicle
accelerometer list, as a partial return from supported(), might be:
[{uid:“00000001”,tags:[”Accelerometry”,”directionOfTravel”,”linear”,”primary”]},
{uid:“00000002”,tags:[”Accelerometry”,”directionOfTravel”,”linear”,”secondary”]}
,
{uid:“00000003”,tags:[”Accelerometry”,”roll”,”rotational”,”primary”]},
{uid:“00000004”,tags:[”Accelerometry”,”pitch”,”rotational”,”primary”]}]
The text nature of tags allow for field extension of the API by OEMs
without requiring a fork and recompilation of AMB. From the standpoint of
AMB passing data between sources and sinks, the tag cloud is a single text
string (or array) originating in a source and delivered to a sink. AMB does
not need to know or care that the tag cloud has any particular internal
structure. AMB only needs to know that a message provided by a source has
two text fields, one called uid and the other called tags.
Using non-vendor-specific UIDs as primary keys into each vehicle datum
simplifies the API in actual use, while using a flexible, text-based tag
cloud approach allows a vehicle to communicate its actual sensor set from
its AMB CAN plugins to the HMI independently of the knowledge level of the
AMB maintainer. With this approach, the API function set consists of:
supported() returns array [{uid:, tags:[]},{uid:, tags:[]},{uid:,
tags:[]},...]
get(string UID), returns {value:, status:, sequence:, time:}
set(string UID, object {value}) returns boolean
subscribe(string UID, callback Success) returns handle
unsubscribe(handle returned from subscribe) returns boolean
getHistory(string UID, time Begin, time End, callback Success, callback
Error) returns undefined
An appropriately chartered open standards committee would create a tag
dictionary defining SI-based data formats to be exported to the HMI, and
defining a set of location tags which collectively span, or form a basis
for, the largest practical metric space in terms of different
data-independent axes on which vehicle sensor signals may be described. As
an example of the former, an open standards definition of the tag
“Accelerometry” might state that an “Accelerometry” defines a data format,
for which the data value is a signed integer in the range -4000 to +4000
inclusive, representing an acceleration in centimeters per second squared.
As an example of the latter, an open standards definition of the tag
“secondary” might state that “secondary” refers to a sensor which is a
backup to a primary sensor.
An OEM working with this API would create an AMB CAN plugin, which would
extract CAN signals from appropriate offsets within CAN frames as known to
that OEM, apply the appropriate linear transformation of CAN data to
conform to the relevant open standards data type, apply tags as appropriate
to uniquely describe the CAN signal, and apply any UID which is unique
within the vehicle. The OEM's use of open standards tags and data formats
would maximize that OEM's ability to interface its data with any HMI also
developed to the open standard tag set. An OEM needing customization of
either data format, or location, not covered by the open standard, would be
able to incorporate such customization into its AMB CAN plugin without
needing to alter AMB itself. Such customization could complement and
coexist with open standards tags.
An HMI interacting with this API would begin by calling
tizen.vehicle.supported(), and receiving an array of all objects available
from registered sources. The HMI would search the tags of returned objects
to determine which objects represent vehicle data of interest to the HMI.
An HMI which parses object tag clouds for open standard tags would be
maximally interoperable with multiple OEMs, but an HMI would not be
restricted to parsing only open standard tags. If an HMI developer had
knowledge of OEM-specific tags, the HMI could search for those tags as
well, and modify its display according to that OEM-specific knowledge.
Following HMI isolation of those objects with relevant tags, the HMI would
extract the UID from each such object and use that UID in subsequent
interactions with the API. Since the UIDs are discovered by the HMI at
runtime, an OEM may alter, add, or remove UIDs in its AMB CAN plugin at any
compilation thereof without affecting the operation of any subsequently
connecting HMI. The ability of any OEM to add proprietary tags allows the
API to operate at a dual level, in which the open standard tag set supports
a common API, while each OEM retains the ability to extend an OEM-specific
API not subject to outside disclosure.
Sample pseudocode for a straightforward setting operation in the HMI would
resemble:
var allItems = tizen.vehicle.supported();
var hvacItem = myTagFilter( allItems, [“HVAC”, “Temperature”, “Left”,
“Front”, “Seat”] );
var success = tizen.vehicle.set( hvacItem.uid,{value:22});
A similar, but not necessarily identical, possible operation is:
var allItems = tizen.vehicle.supported();
var hvacItem = myTagFilter( allItems, [“HVAC”, “Temperature”, “Driver”,
“Seat”] );
var success = tizen.vehicle.set( hvacItem.uid,{value:22});
The above example would locate the driver's seat correctly whether used in
a right-hand-drive or in a left-hand-driver vehicle, while the earlier
example would locate a specific seat positionally. In different
circumstances, either may be desirable.
As industry adopts the API, OEMs may propose specific tags to be considered
for addition into the open standard without needing to alter AMB itself.
This removal of zone-like information from AMB greatly reduces the
maintenance burden on AMB, and frees industry from a dependency on AMB
patches. This better enables Tizen to reach its stated goals, as presented
in conference presentations in San Francisco and in Edinburgh, of moving
away from past patterns of rigid, proprietary solutions and towards
flexible frameworks within which solutions can be reused, leading to more
cost-effective solutions coming to market in more reasonable timeframes.
Thanks,
Steve Gerken
-------------------
Linux Developer
MSX, as broker for Jaguar Land Rover
One World Trade Center, 121 SW Salmon Street, 11th Floor, Portland, Oregon,
97204
Email: [email protected]
_______________________________________________
IVI mailing list
[email protected]
https://lists.tizen.org/listinfo/ivi
