W3C home > Mailing lists > Public > public-autowebplatform@w3.org > February 2014

Re: Comments on Climate Draft

From: Rees, Kevron <kevron.m.rees@intel.com>
Date: Tue, 11 Feb 2014 14:38:19 -0800
Message-ID: <CAFW5wYaTwbiH7qsoatgmnRxgXvtoko7NqJLcibYriL-yAWe=Uw@mail.gmail.com>
To: "jongseon.park@lge.com" <jongseon.park@lge.com>
Cc: "public-autowebplatform@w3.org" <public-autowebplatform@w3.org>
On Tue, Feb 11, 2014 at 5:05 AM, 박종선(Justin Park) <jongseon.park@lge.com> wrote:
> Hi Kevron,
>
>> -----Original Message-----
>> From: Rees, Kevron [mailto:kevron.m.rees@intel.com]
>> Sent: Tuesday, February 11, 2014 6:59 AM
>> To: public-autowebplatform@w3.org
>> Subject: Comments on Climate Draft
>>
>> I will follow up this email with a patch, but wanted to ask a few
>> questions first.
>>
>> 1. Why is there a different interface for WiperStatus and
>> WiperSetting?  Can we consolidate them into just WiperStatus?
>
> Actually, Paul asked the same question before.
> I'm attaching the part to answer your question.
>
> o       Wipers
>        Wouldn't it make more sense to have one wiper interface instead of two as they both have to do with wiper?
>        Why do we have wiper setting and speed?  Their seems to be overlap.  I get that their is a correlation between the two.  Just want to make sure we are being explicit about it.
>
> ==> Unlike other attributes, wiper is hard to have a common interface for both ‘get’ and ‘set’. Since ‘once’ and ‘auto’ exist in only setting status. In ‘auto’ setting, wiper speed varies depending on the rain intensity. So, I thought it needs to be separated.

Okay, so this is the same situation as Transmission where the shift
position is different than the actual transmission gear.  Correct?

If this is the case, we could add a separate attribute for
wiperSpeedSetting to the same interface?  Something like this:

interface Wiper
{
  attribute Setting wiperSpeedSetting; /// auto, 1, 2, etc
  attribute short wiperSpeed /// 1, 2, 3, etc
}

>
>
>> 2. Defrost is strongly correlated with a window.  In tizen we made
>> this an attribute of the Window interface
>> (https://github.com/otcshare/automotive-message-
>> broker/blob/master/docs/amb.idl#L478).
>>  We could do the same here.
>
> Usually, defrost is supported for Wind Shield, Rear Window and side mirrors.
> We can apply zone for it with 'Front', 'Rear', but side mirror is not much matched.
> And Side windows usually are only for 'Openness'. So, even though all are 'windows', but the usage is different.
>

Good point.  Rear windows can have an openness, but not always and
certainly the windshield doesn't.  And side mirrors can have a defrost
but side-mirrors are not a window.  Can we add (presuming we don't
already have one) an interface for side mirror and have it contain a
defrost attribute as well?  Something like this:

interface Window
{
  attribute short ? openness;
  attribute boolean ? defroster;
  attribute Zone zone;
}

interface SideMirror
{
  attribute boolean ? defroster;
  /// postition attributes
  attribute Zone zone;
}


>
>> 3.  Likewise with 2, SideWindow could be merged with a more generic
>> Window interface and take advantage of the Zones attribute for left
>> and right sides.
>> 4. Like with 1, ClimateControl could be merged with HVAC.
>
> I intended separating airRecirculationg and steeringWheelHeater attributes not associated to zone from HVAC.
> Overall, we need to find-tune the granularity of interfaces.
>

These could be part of the same interface but with a Zone.none value
for zone.  So if there were 2 zones, there would actually be 3 items
returned for that interface: none, driver and passenger.  The HVAC
item for zone "none" would have airRecirculation etc which don't have
a zone concept.

>
>> Thanks,
>> Kevron
>
Received on Tuesday, 11 February 2014 22:38:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:52:52 UTC