[agl-discussions] 3.0 released features?

Takashi Matsuzawa tmatsuzawa at xevo.com
Thu Jan 12 03:09:46 UTC 2017


I will want for the guideline draft anyway, but here is my concern.  Sorry not well written.

BSP can be configured whatever way through yocto build systen, and today BSP (layers close to H/W) are different to the boards.
Kernel versions may not be the same among the boards.  Available gstreamer pulgins are different.  Though I understand very well to expect exactly the same BSP configuration is meaningless to support multiple boards.
Good to avoid fragmentation in the sense allowing customization is good.  Everyone starts from the same BSPs, reduce development cost, etc.
But what kind of / how much customization is good to call it AGL system is, difficult?

As solution vendor background, I am also interested in how AGL brand will relate to the 3rd party components in the system.
(The condition, or policy to call a solution familiar to AGL platform.)
3rd party provided services / components needed to be installed/maintained by the application/security framework since they can be 'non-trusted high level applications' or, they can be treated as 'low level BSP trusted services running at low level'.
Or even for 'trusted services', security framework can have impact?, etc.  Mandatory use of certain APIs?
This may be just each OEM policy, though.

________________________________
From: automotive-discussions-bounces at lists.linuxfoundation.org <automotive-discussions-bounces at lists.linuxfoundation.org> on behalf of Dominig Ar Foll <dominig.arfoll at fridu.net>
Sent: Sunday, January 8, 2017 2:53 PM
To: automotive-discussions at lists.linuxfoundation.org
Subject: Re: [agl-discussions] 3.0 released features?

For info

I just dig in my "Tizen time" to find out how we installed Tizen
branding and Name usage.
I did run the process for TV twice.

The branding was pretty simple an was defined in a document (see as
example Tizen 2.4 link)
   https://download.tizen.org/misc/Tizen-Brand/01-Guidelines/Tizen-Brand-Guidelines-v2_4.pdf

The name usage was a bit more complex because, in Tizen we did not
want to enforce a certification model, which as stated by Dan, induces
fragmentation, but on the other side, we wanted to enforce :
   - compatibility with the echo system
   - respect of core feature and principle (such as the security coverage).
   - clarity of the version compatibility claimed.

The second aspect was covered by having the Technical Steering Group
(TSG) select an individual who was given the responsibility to check
that that the required fundamentals and echosystem compatibility where
respected by the submitting team.

For example, I had the task to under-sign Samsung request to brand
their TV as "Tizen". In order to be able to give my approval, Samsung
TV team  provided me with the their test results showing the
 - compatibility with the required App API for Tizen TV (the minimum
list was defined by the architecture committee)
 - compatibility with the selected optional API
 - coverage of the security requirement (Smack, Cynara, key management)
 - the availability of the SDK.

Once those documents provided and check, I did provide my OK.

The process was pretty simple and light by was efficient enough to not
let the brand be devalued by unfit products.

Regards

Dominig

2017-01-07 21:16 GMT+01:00 Dan Cauchy <dcauchy at linuxfoundation.org>:
> We are in the process of creating AGL brand usage guidelines with the
> LF legal team, which will be approved by the AGL board, and announced
> afterwards. Stay tuned.
>
> My opinion: I strongly believe that compliance testing leads to
> fragmentation, with multiple different code base being "compliant" but
> all different. Let's not go down that path.
>
> And to answer the original question: yes the whole point of AGL is to
> make it customizable. Production projects start with AGL UCB and add
> the apps/components/GUI as needed.
>
> Dan.
>
>
>> On Jan 7, 2017, at 9:01 AM, Fulup Ar Foll <fulup.arfoll at iot.bzh> wrote:
>>
>> How to allow or not someone to use AGL brand is a real question. Nevertheless as today they is no AGL compliance test, no plan to create one and thus no option to claim AGL compatibility. For CES and AGL/3.0, the main constrain was for projects to be integrated with the application framework, the homescreen and the security model.
>>
>> Defining who and under which conditions a solution can claim to be "powered by AGL" is clearly something that need to be addressed. Supporting out of the box references/demo applications through the applications framework and with AGL security model active could be a first set of minimal requirements, nevertheless having a reference tests suite would also create a lot of value.
>>
>> This being said, defining the right to use AGL brand for a given product is going far being technical only issues. This problem needs 1st to be address by the board before the architecture group may start working of how a technology could help in giving any form of approval.
>>
>> Fulup
>>
>>
>>
>>> On 06/01/17 23:45, Takashi Matsuzawa wrote:
>>> Thank you , so list of changes (or link to them) will be there soon.
>>>
>>>
>>> What confuses me a bit is relationship with the released features list,
>>> UCB/BSP sources, and  what OEMs use in their products.
>>>
>>> My understanding is that we do not use BSP as it is, and
>>> re-configure/make changes to the configuration ro real products. And as
>>> long as it is 'based' on UCB, we are running AGL and can claim AGL
>>> compatible?
>>>
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Jan-Simon Möller <dl9pf at gmx.de>
>>> *Sent:* Friday, January 6, 2017 8:07 PM
>>> *To:* automotive-discussions at lists.linuxfoundation.org
>>> *Cc:* Takashi Matsuzawa
>>> *Subject:* Re: [agl-discussions] 3.0 released features?
>>>
>>> https://wiki.automotivelinux.org/agl-distro/release-notes
>>> will contain the list.
>>>
>>> --
>>>
>>> Dipl.-Ing.
>>> Jan-Simon Möller
>>>
>>> jansimon.moeller at gmx.de
>>>> On Friday 06 January 2017 04:37:00 Takashi Matsuzawa wrote:
>>>> Hello AGL.
>>>>
>>>> I am looking into the 3.0 Chinook release news statement:
>>>> >https://www.automotivelinux.org/news/announcement/2016/12/automotive-grade->
>>>> linux-releases-open-infotainment-platform-built
>>>> Is there easy way to map some of the following 3.0 features to jira tickets
>>>> or Yocto recipes so that I can know them preciesly (what are AGL specific
>>>> inventsions or integration).
>>>>
>>>> e.g.
>>>> I do not think there is no SmartDeviceLink recipe in AGL BSP but just sowed
>>>> by using external (meaning, not part of BSP/UCB) components, though it can
>>>> be referred in GENIVI code? Rear views and simultaneous display is
>>>> supported by particular components (may be added in AGL) and apps need to
>>>> take advantage of them?
>>>> >- A brand new home screen and window manager
>>>> >- An improved application framework and application launcher
>>>> >- A new SDK for rapid application development
>>>> >- Reference applications including media player, tuner, navigation,
>>>> >Bluetooth, WiFi, HVAC control, audio mixer and vehicle controls -
>>>> >Integration with simultaneous display on instrument cluster
>>>> >- Smart Device Link for mobile phone integration
>>>> >- Rear view camera and rear seat entertainment on MOST ring
>>>> >- Wide range of hardware board support including Renesas, Qualcomm
>>>> >Technologies, Intel, Texas Instrument, NXP and Raspberry Pi
>>>
>>>
>>>
>>> _______________________________________________
>>> automotive-discussions mailing list
>>> automotive-discussions at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions
>>>
>>
>> _______________________________________________
>> automotive-discussions mailing list
>> automotive-discussions at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions
> _______________________________________________
> automotive-discussions mailing list
> automotive-discussions at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions



--
Dominig ar Foll
Senior Software Architect
Intel Open Source Technology Centre
_______________________________________________
automotive-discussions mailing list
automotive-discussions at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/automotive-discussions/attachments/20170112/171a2762/attachment-0001.html>


More information about the automotive-discussions mailing list