Topics

Getting started


Juha-Matti Liukkonen <juha-matti.liukkonen@...>
 

Hello all!

Now that we got the initial Expert Groups kicked off in Barcelona, I thought to post some notes to help everyone get started. Please do clarify, correct or question what I'm saying as needed -- these instructions, as Open Source in general, follows the principles of Kaizen :-)

First, it is good to remind ourselves of what we are doing. A key quote from [1]:

"All work is carried out by the AGL Workgroup members directly within upstream projects. The upstream projects are then integrated into an AGL reference distribution."

We have agreed to work on upstream projects, and use Tizen IVI as the reference distribution -- our test bed for development and integration. This is because Tizen IVI has already covered a lot of the groundwork we need. There is no added value for generating yet another Linux distribution from scratch, so we aim to work with the Tizen project as much as possible.

(a) Updates to components in the distribution should be made to the upstream projects (e.g. pulseaudio, wayland, kernel), which then get pulled in to the reference distribution as part of the normal process.

(b) Modifying existing components, or introducing new components for your own use is easy. Just follow the getting started instructions [2], [3]; the gbs tool will build a local repository that you can install packages from, and the mic tool will build custom system images with any packages you want.

(c) If there is a need to add new components to wider use, we should follow a 3-step process:

1) Build the components locally and use them from your own repositories, as mentioned in (b).

2) If the new components are of interest to all AGL users (e.g. testing tools or the reference UI), we will put them in an AGL component repository. These components can then be pulled in to target installations using zypper, or included in system images built with mic.

3) If (2) happens, we should probably open a discussion in the tizen-ivi mailing list [4] to discuss whether these components would make sense to be included in the Tizen IVI profile. Some may, some may not. Please be mindful of the Tizen system architecture [5], it is based on considered design choices.

I encourage everyone to go and get the reference hardware [6] and get working on the code! See what's already in there, what works for you and what doesn't, what challenges do you have with the workflow, what kind of documentation or support would you need to be successful with Linux in your automotive applications. Please share your findings with the mailing list -- together we can learn and solve the challenges.

Also, please don't hesitate to ask the mailing list if there are any questions or problems. Most likely someone in here has encountered the same issue, and has insight and information to share - or at least knows where to forward the questions.

Cheers,
- Jussi Liukkonen

[6] see Step 3 in [2], [3]

--
Juha-Matti Liukkonen
Technology Director, Embedded software


Todd Fuchs <tfuchs@...>
 

Thanks for the info!

At Host Concepts, we are already working on a streamlined, beautiful, intuitive reference UI using the reference hardware (NexCom VTC1000). Should anyone need help or want to discuss any UI-related issues regarding the pieces they are working on, please feel free to let us know either via email or through the mailing list and we will be happy to coordinate the efforts in getting it built into the reference UI.

We are looking forward to getting AGL off the ground and into the cars of tomorrow. It was a pleasure meeting everyone at the meeting and hope that travels were safe.

Todd Fuchs
Chief Software Architect
O: (855) 344-6368
C: (561) 715-7166

On Nov 8, 2012, at 6:18 AM, Juha-Matti Liukkonen <juha-matti.liukkonen@...> wrote:

Hello all!

Now that we got the initial Expert Groups kicked off in Barcelona, I thought to post some notes to help everyone get started. Please do clarify, correct or question what I'm saying as needed -- these instructions, as Open Source in general, follows the principles of Kaizen :-)

First, it is good to remind ourselves of what we are doing. A key quote from [1]:

"All work is carried out by the AGL Workgroup members directly within upstream projects. The upstream projects are then integrated into an AGL reference distribution."

We have agreed to work on upstream projects, and use Tizen IVI as the reference distribution -- our test bed for development and integration. This is because Tizen IVI has already covered a lot of the groundwork we need. There is no added value for generating yet another Linux distribution from scratch, so we aim to work with the Tizen project as much as possible.

(a) Updates to components in the distribution should be made to the upstream projects (e.g. pulseaudio, wayland, kernel), which then get pulled in to the reference distribution as part of the normal process.

(b) Modifying existing components, or introducing new components for your own use is easy. Just follow the getting started instructions [2], [3]; the gbs tool will build a local repository that you can install packages from, and the mic tool will build custom system images with any packages you want.

(c) If there is a need to add new components to wider use, we should follow a 3-step process:

1) Build the components locally and use them from your own repositories, as mentioned in (b).

2) If the new components are of interest to all AGL users (e.g. testing tools or the reference UI), we will put them in an AGL component repository. These components can then be pulled in to target installations using zypper, or included in system images built with mic.

3) If (2) happens, we should probably open a discussion in the tizen-ivi mailing list [4] to discuss whether these components would make sense to be included in the Tizen IVI profile. Some may, some may not. Please be mindful of the Tizen system architecture [5], it is based on considered design choices.

I encourage everyone to go and get the reference hardware [6] and get working on the code! See what's already in there, what works for you and what doesn't, what challenges do you have with the workflow, what kind of documentation or support would you need to be successful with Linux in your automotive applications. Please share your findings with the mailing list -- together we can learn and solve the challenges.

Also, please don't hesitate to ask the mailing list if there are any questions or problems. Most likely someone in here has encountered the same issue, and has insight and information to share - or at least knows where to forward the questions.

Cheers,
- Jussi Liukkonen

[6] see Step 3 in [2], [3]

--
Juha-Matti Liukkonen
Technology Director, Embedded software

_______________________________________________
automotive-discussions mailing list
automotive-discussions@...
https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions


Konstantin A. Khait <khait@...>
 

Hi All,

First of all, I have to say "sorry" from the name of our company. We planned delegating a person to Barcelona congress, however had to cancel this visit due to the reasons we were unable to predict. We also had rather poor phone connection, therefore we have no chance to participate actively (although we have enough passion (thanks to Rudolf for the word) to contribute to AGL). So, to compensate this lack of communication I wanna present some ideas and raise topics by email.

1. We consider that actually multimedia segment is elaborated rather well, however some other segments are not having enough community attention. First of all it is about V2X connectivity. As V2X is one of our core businesses, we are ready to become a contributor and if necessary coordinator of the corresponded activity. However I'd expect a separate EG is required for this particular branch because the scope of the topic is rather wide.

2. We think that HMI is still a hot topic being not yet completely resolved in the automotive Linux world. It seems that the most of the community agree that HTML5+JS is cool and right concept, however the only existing reference implementation is Tizen, which is heavy enough, hard for portability and has no alternatives. Our intention is to review and elaborate alternate [especially lighter and more community-driven] solutions, especially WebOS. Having nothing against Tizen, we consider that AGL shouldn't be so heavily dependent on one multimedia-oriented and heavyweight distribution, so finally the only high level HMI interfaces (plus browser engine for sure) should remain there. Actually Compo needs to work on this area for our current market projects and ready to contribute the results to AGL, but we need to understand the best way to plan and coordinate this activity within the community.

3. Actually we have to do our multimedia on Android, because the end user wants Android and Android apps. However, Android is not automotive quality OS (OMG, it's very far from it) and we spend extremely high efforts to make it reliable, fast and ergonomical even for aftermarket products. So, we consider that it is very fruitful idea to use virtualization (like OpenVZ to share Linux kernel and avoid extra resources consumption) to run Android in a sandbox under AGL and minimize its impact to system stability (and other characteristics) remaining all the benefits of existing apps and buzzword. If folks shares this opinion, we're ready to contribute mid-term efforts to this initiative.

Thanks in advance for your feedback,
Kostia


-----
Konstantin A. Khait
Componentality Oy
Tel: +358(0)465662016
+7(921)9005780
Skype: kostia.khait
E-Mail: khait@...
53100 Finland
Ratakatu 47
Lappeenranta 



Thanks for the info!

At Host Concepts, we are already working on a streamlined, beautiful, intuitive reference UI using the reference hardware (NexCom VTC1000). Should anyone need help or want to discuss any UI-related issues regarding the pieces they are working on, please feel free to let us know either via email or through the mailing list and we will be happy to coordinate the efforts in getting it built into the reference UI.

We are looking forward to getting AGL off the ground and into the cars of tomorrow. It was a pleasure meeting everyone at the meeting and hope that travels were safe.

Todd Fuchs
Chief Software Architect
O: (855) 344-6368
C: (561) 715-7166
www.HostConcepts.com
tfuchs@...

On Nov 8, 2012, at 6:18 AM, Juha-Matti Liukkonen <juha-matti.liukkonen@...> wrote:
Hello all!

Now that we got the initial Expert Groups kicked off in Barcelona, I thought to post some notes to help everyone get started. Please do clarify, correct or question what I'm saying as needed -- these instructions, as Open Source in general, follows the principles of Kaizen :-)

First, it is good to remind ourselves of what we are doing. A key quote from [1]:

"All work is carried out by the AGL Workgroup members directly within upstream projects. The upstream projects are then integrated into an AGL reference distribution."

We have agreed to work on upstream projects, and use Tizen IVI as the reference distribution -- our test bed for development and integration. This is because Tizen IVI has already covered a lot of the groundwork we need. There is no added value for generating yet another Linux distribution from scratch, so we aim to work with the Tizen project as much as possible.

(a) Updates to components in the distribution should be made to the upstream projects (e.g. pulseaudio, wayland, kernel), which then get pulled in to the reference distribution as part of the normal process.

(b) Modifying existing components, or introducing new components for your own use is easy. Just follow the getting started instructions [2], [3]; the gbs tool will build a local repository that you can install packages from, and the mic tool will build custom system images with any packages you want.

(c) If there is a need to add new components to wider use, we should follow a 3-step process:

1) Build the components locally and use them from your own repositories, as mentioned in (b).

2) If the new components are of interest to all AGL users (e.g. testing tools or the reference UI), we will put them in an AGL component repository. These components can then be pulled in to target installations using zypper, or included in system images built with mic.

3) If (2) happens, we should probably open a discussion in the tizen-ivi mailing list [4] to discuss whether these components would make sense to be included in the Tizen IVI profile. Some may, some may not. Please be mindful of the Tizen system architecture [5], it is based on considered design choices.

I encourage everyone to go and get the reference hardware [6] and get working on the code! See what's already in there, what works for you and what doesn't, what challenges do you have with the workflow, what kind of documentation or support would you need to be successful with Linux in your automotive applications. Please share your findings with the mailing list -- together we can learn and solve the challenges.

Also, please don't hesitate to ask the mailing list if there are any questions or problems. Most likely someone in here has encountered the same issue, and has insight and information to share - or at least knows where to forward the questions.

Cheers,
- Jussi Liukkonen

[1] http://automotive.linuxfoundation.org/what-is-automotive-grade-linux
[2] http://automotive.linuxfoundation.org/sites/automotive.linuxfoundation.org/files/AGL-UserInstructions-en-v2.pdf
[3] http://automotive.linuxfoundation.org/sites/automotive.linuxfoundation.org/files/AGL-UserInstructions-jp-v2.pdf
[4] https://lists.tizen.org/listinfo/ivi
[5] https://source.tizen.org/documentation/architecture-overview
[6] see Step 3 in [2], [3]

--
Juha-Matti Liukkonen
Technology Director, Embedded software
juha-matti.liukkonen@...
www.reaktorfusion.fi
_______________________________________________
automotive-discussions mailing list
automotive-discussions@...
https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions


Konstantin A. Khait
 

Hi All,

First of all, I have to say "sorry" from the name of our company. We planned delegating a person to Barcelona congress, however had to cancel this visit due to the reasons we were unable to predict. We also had rather poor phone connection, therefore we have no chance to participate actively (although we have enough passion (thanks to Rudolf for the word) to contribute to AGL). So, to compensate this lack of communication I wanna present some ideas and raise topics by email.

1. We consider that actually multimedia segment is elaborated rather well, however some other segments are not having enough community attention. First of all it is about V2X connectivity. As V2X is one of our core businesses, we are ready to become a contributor and if necessary coordinator of the corresponded activity. However I'd expect a separate EG is required for this particular branch because the scope of the topic is rather wide.

2. We think that HMI is still a hot topic being not yet completely resolved in the automotive Linux world. It seems that the most of the community agree that HTML5+JS is cool and right concept, however the only existing reference implementation is Tizen, which is heavy enough, hard for portability and has no alternatives. Our intention is to review and elaborate alternate [especially lighter and more community-driven] solutions, especially WebOS. Having nothing against Tizen, we consider that AGL shouldn't be so heavily dependent on one multimedia-oriented and heavyweight distribution, so finally the only high level HMI interfaces (plus browser engine for sure) should remain there. Actually Compo needs to work on this area for our current market projects and ready to contribute the results to AGL, but we need to understand the best way to plan and coordinate this activity within the community.

3. Actually we have to do our multimedia on Android, because the end user wants Android and Android apps. However, Android is not automotive quality OS (OMG, it's very far from it) and we spend extremely high efforts to make it reliable, fast and ergonomical even for aftermarket products. So, we consider that it is very fruitful idea to use virtualization (like OpenVZ to share Linux kernel and avoid extra resources consumption) to run Android in a sandbox under AGL and minimize its impact to system stability (and other characteristics) remaining all the benefits of existing apps and buzzword. If folks shares this opinion, we're ready to contribute mid-term efforts to this initiative.

Thanks in advance for your feedback,
Kostia


-----
Konstantin A. Khait
Componentality Oy
Tel: +358(0)465662016
+7(921)9005780
Skype: kostia.khait
E-Mail: khait@...
53100 Finland
Ratakatu 47
Lappeenranta 



Thanks for the info!

At Host Concepts, we are already working on a streamlined, beautiful, intuitive reference UI using the reference hardware (NexCom VTC1000). Should anyone need help or want to discuss any UI-related issues regarding the pieces they are working on, please feel free to let us know either via email or through the mailing list and we will be happy to coordinate the efforts in getting it built into the reference UI.

We are looking forward to getting AGL off the ground and into the cars of tomorrow. It was a pleasure meeting everyone at the meeting and hope that travels were safe.

Todd Fuchs
Chief Software Architect
O: (855) 344-6368
C: (561) 715-7166
www.HostConcepts.com
tfuchs@...

On Nov 8, 2012, at 6:18 AM, Juha-Matti Liukkonen <juha-matti.liukkonen@...> wrote:
Hello all!

Now that we got the initial Expert Groups kicked off in Barcelona, I thought to post some notes to help everyone get started. Please do clarify, correct or question what I'm saying as needed -- these instructions, as Open Source in general, follows the principles of Kaizen :-)

First, it is good to remind ourselves of what we are doing. A key quote from [1]:

"All work is carried out by the AGL Workgroup members directly within upstream projects. The upstream projects are then integrated into an AGL reference distribution."

We have agreed to work on upstream projects, and use Tizen IVI as the reference distribution -- our test bed for development and integration. This is because Tizen IVI has already covered a lot of the groundwork we need. There is no added value for generating yet another Linux distribution from scratch, so we aim to work with the Tizen project as much as possible.

(a) Updates to components in the distribution should be made to the upstream projects (e.g. pulseaudio, wayland, kernel), which then get pulled in to the reference distribution as part of the normal process.

(b) Modifying existing components, or introducing new components for your own use is easy. Just follow the getting started instructions [2], [3]; the gbs tool will build a local repository that you can install packages from, and the mic tool will build custom system images with any packages you want.

(c) If there is a need to add new components to wider use, we should follow a 3-step process:

1) Build the components locally and use them from your own repositories, as mentioned in (b).

2) If the new components are of interest to all AGL users (e.g. testing tools or the reference UI), we will put them in an AGL component repository. These components can then be pulled in to target installations using zypper, or included in system images built with mic.

3) If (2) happens, we should probably open a discussion in the tizen-ivi mailing list [4] to discuss whether these components would make sense to be included in the Tizen IVI profile. Some may, some may not. Please be mindful of the Tizen system architecture [5], it is based on considered design choices.

I encourage everyone to go and get the reference hardware [6] and get working on the code! See what's already in there, what works for you and what doesn't, what challenges do you have with the workflow, what kind of documentation or support would you need to be successful with Linux in your automotive applications. Please share your findings with the mailing list -- together we can learn and solve the challenges.

Also, please don't hesitate to ask the mailing list if there are any questions or problems. Most likely someone in here has encountered the same issue, and has insight and information to share - or at least knows where to forward the questions.

Cheers,
- Jussi Liukkonen

[1] http://automotive.linuxfoundation.org/what-is-automotive-grade-linux
[2] http://automotive.linuxfoundation.org/sites/automotive.linuxfoundation.org/files/AGL-UserInstructions-en-v2.pdf
[3] http://automotive.linuxfoundation.org/sites/automotive.linuxfoundation.org/files/AGL-UserInstructions-jp-v2.pdf
[4] https://lists.tizen.org/listinfo/ivi
[5] https://source.tizen.org/documentation/architecture-overview
[6] see Step 3 in [2], [3]

--
Juha-Matti Liukkonen
Technology Director, Embedded software
juha-matti.liukkonen@...
www.reaktorfusion.fi
_______________________________________________
automotive-discussions mailing list
automotive-discussions@...
https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions   


Juha-Matti Liukkonen <juha-matti.liukkonen@...>
 

Hi!

Thanks for raising a number of good topics, and joining in the discussion!

I also believe V2V/V2I are significant and interesting. This is also a good point to remind that AGL is not only about IVI or Tizen, it's about bringing relevant open source components to automotive grade.

With regards to HMI, I expect that most automotive companies have their own HMI solutions that they wish to use in product configurations. This is why the discussion has focused on providing an UI primarily for testing and demoing purposes - and to provide AGL its own "face". 

However, the point you raise about UI toolkits is interesting: which UI toolkits are really applicable in the automotive context right now? Which ones you can get developers for now, and support in 10 years' time. EFL? Qt? HTML5? Where are these toolkits headed, and are there other significant contenders?

Regarding virtualization, we could perhaps first discuss virtualization techniques in general? Consider available alternatives, the needs and requirements in automotive use, think how does the container interface with the host system (audio routing, data access, security etc), how are software updates handled, and so on.

Your input, ideas and experiences are much welcomed.

Cheers,
- Jussi

--
Juha-Matti Liukkonen
Technology Director, Embedded software


Jeremiah C. Foster
 

On Fri, Nov 9, 2012 at 2:31 PM, Juha-Matti Liukkonen
<juha-matti.liukkonen@reaktor.fi> wrote:
Hi!

Thanks for raising a number of good topics, and joining in the discussion!

I also believe V2V/V2I are significant and interesting.
With regards to HMI, I expect that most automotive companies have their own
HMI solutions that they wish to use in product configurations. This is why
the discussion has focused on providing an UI primarily for testing and
demoing purposes - and to provide AGL its own "face".
HMI is a key differentiator for OEMs. Tizen won't be successful, nor
AGL, if it does not allow for an OEM to create their own look and
feel.

However, the point you raise about UI toolkits is interesting: which UI
toolkits are really applicable in the automotive context right now? Which
ones you can get developers for now, and support in 10 years' time. EFL? Qt?
HTML5? Where are these toolkits headed, and are there other significant
contenders?
EFL? I know that Samsung has done some work with EFL, but that
framework has a miserable toolkit with fundamentally broken
architecture. No one really uses EFL, not even community distros.

Qt is widely used and automotive grade, see Qt IVI.

HTML5 vehicle APIs are being defined already, and that work is best
done in the W3C where it is happening:
http://www.w3.org/2012/08/web-and-automotive/
If you're interested I would get involved in the W3C at your earliest
convenience since that train is leaving the station. Connection to
various sensors through a web browser is always going to be somewhat
problematic so HTML5 is not the silver bullet many think it is.

Regarding virtualization, we could perhaps first discuss virtualization
techniques in general?
There are some seriously good RTOSes out there which work on a variety
of architectures, ARM is coming with new virtualization techniques
based on Xen (http://www.xen.org/products/xen_arm.html) and there are
Linux Virtual Containers which are a very effective solution. I can't
imagine there is much room in the marketplace for many alternatives
beyond those and the commercial RTOSes, which already have
relationships with the OEMs.

Why would AGL be discussing virtualization anyway? It seems orthogonal
to GNU/Linux userland and app discussion.

Consider available alternatives, the needs and
requirements in automotive use, think how does the container interface with
the host system (audio routing, data access, security etc), how are software
updates handled, and so on.
I don't think we're going to be talking about ECU to ECU and CPU
boundaries in AGL are we? Aren't those rather low level hardware
details that a beyond the scope? If they are in scope, then I really
think we need to have an ARM based reference design before you start
drawing architecture dependent boundaries.

I note that there is not much participation from ARM licensees on this
list. Is there a reason? Can we encourage their participation?
Otherwise discussion on low-level hardware solutions is moot.

Regards,

Jeremiah

Your input, ideas and experiences are much welcomed.

Cheers,
- Jussi

--
Juha-Matti Liukkonen
Technology Director, Embedded software
juha-matti.liukkonen@reaktor.fi
www.reaktorfusion.fi


_______________________________________________
automotive-discussions mailing list
automotive-discussions@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions


--
=============================================
Jeremiah C. Foster エレミア フォスター
Open Source Technologist
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)730 93 0506
E-Mail: jeremiah.foster@pelagicore.com
=============================================

=== NOTE ===
The information contained in this E-mail message is
intended only for use of the individual or entity
named above. If the reader of this message is not
the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited.
=============


Todd Fuchs <tfuchs@...>
 

Jeremiah,
Thanks for the feedback and contributions. I would like to remind everyone who is part of AGL that while OEMs will always want to adopt their own UI as a differentiator, they will still need to see the functionality of everything AGL/Tizen has to offer. You can't sell a product to an OEM without "showing it off" first. This is the purpose of the reference UI, and my role as the UI Expert Group Lead. I find that this is a big mistake many companies make, even in my industry (hospitality). Such minimal effort is put into a base UI because the client will ultimately "Skin" their own version, yet when the platform is demonstrated it doesn't get purchased because it doesn't showcase it's true abilities with it's own UI.

Tizen & AGL both must have a compelling UI, even in never adopted, if they are to succeed in an increasingly competitive space. All of the efforts coming from the AGL participating companies must be shown off in the reference, not simply "explained" in a written document. Just as OEMs need to differentiate themselves from each other, so do AGL and Tizen in order to get the OEM on board to begin with.

Just wanted to throw my two cents in there, for those of you that feel AGL/Tizen do not need a robust UI. They do in my opinion.


Todd Fuchs
Chief Software Architect
O: (855) 344-6368
C: (561) 715-7166

On Nov 9, 2012, at 1:50 PM, Jeremiah Foster <jeremiah.foster@...> wrote:

On Fri, Nov 9, 2012 at 2:31 PM, Juha-Matti Liukkonen
<juha-matti.liukkonen@...> wrote:
Hi!

Thanks for raising a number of good topics, and joining in the discussion!

I also believe V2V/V2I are significant and interesting.

With regards to HMI, I expect that most automotive companies have their own
HMI solutions that they wish to use in product configurations. This is why
the discussion has focused on providing an UI primarily for testing and
demoing purposes - and to provide AGL its own "face".

HMI is a key differentiator for OEMs. Tizen won't be successful, nor
AGL, if it does not allow for an OEM to create their own look and
feel.

However, the point you raise about UI toolkits is interesting: which UI
toolkits are really applicable in the automotive context right now? Which
ones you can get developers for now, and support in 10 years' time. EFL? Qt?
HTML5? Where are these toolkits headed, and are there other significant
contenders?

EFL? I know that Samsung has done some work with EFL, but that
framework has a miserable toolkit with fundamentally broken
architecture. No one really uses EFL, not even community distros.

Qt is widely used and automotive grade, see Qt IVI.

HTML5 vehicle APIs are being defined already, and that work is best
done in the W3C where it is happening:
http://www.w3.org/2012/08/web-and-automotive/
If you're interested I would get involved in the W3C at your earliest
convenience since that train is leaving the station. Connection to
various sensors through a web browser is always going to be somewhat
problematic so HTML5 is not the silver bullet many think it is.

Regarding virtualization, we could perhaps first discuss virtualization
techniques in general?

There are some seriously good RTOSes out there which work on a variety
of architectures, ARM is coming with new virtualization techniques
based on Xen (http://www.xen.org/products/xen_arm.html) and there are
Linux Virtual Containers which are a very effective solution. I can't
imagine there is much room in the marketplace for many alternatives
beyond those and the commercial RTOSes, which already have
relationships with the OEMs.

Why would AGL be discussing virtualization anyway? It seems orthogonal
to GNU/Linux userland and app discussion.

Consider available alternatives, the needs and
requirements in automotive use, think how does the container interface with
the host system (audio routing, data access, security etc), how are software
updates handled, and so on.

I don't think we're going to be talking about ECU to ECU and CPU
boundaries in AGL are we? Aren't those rather low level hardware
details that a beyond the scope? If they are in scope, then I really
think we need to have an ARM based reference design before you start
drawing architecture dependent boundaries.

I note that there is not much participation from ARM licensees on this
list. Is there a reason? Can we encourage their participation?
Otherwise discussion on low-level hardware solutions is moot.

Regards,

Jeremiah

Your input, ideas and experiences are much welcomed.

Cheers,
- Jussi

--
Juha-Matti Liukkonen
Technology Director, Embedded software
juha-matti.liukkonen@...
www.reaktorfusion.fi


_______________________________________________
automotive-discussions mailing list
automotive-discussions@...
https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions




--
=============================================
Jeremiah C. Foster   エレミア フォスター
Open Source Technologist
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)730 93 0506
E-Mail: jeremiah.foster@...
=============================================

=== NOTE ===
The information contained in this E-mail message is
intended only for use of the individual or entity
named above. If the reader of this message  is not
the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited.
=============
_______________________________________________
automotive-discussions mailing list
automotive-discussions@...
https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions


Jeremiah C. Foster
 

Hi Todd,

On Fri, Nov 9, 2012 at 10:32 PM, Todd Fuchs <tfuchs@hostconcepts.com> wrote:
Jeremiah,
Thanks for the feedback and contributions. I would like to remind everyone
who is part of AGL that while OEMs will always want to adopt their own UI as
a differentiator, they will still need to see the functionality of
everything AGL/Tizen has to offer. You can't sell a product to an OEM
without "showing it off" first. This is the purpose of the reference UI, and
my role as the UI Expert Group Lead. I find that this is a big mistake many
companies make, even in my industry (hospitality). Such minimal effort is
put into a base UI because the client will ultimately "Skin" their own
version, yet when the platform is demonstrated it doesn't get purchased
because it doesn't showcase it's true abilities with it's own UI.
I don't disagree with you. Demos always need to be shiny. :-)

What we ought not to forget is the underlying API. That is where the
value is. If car company A can create a fully functional system on top
of the AGL APIs that looks completely different from the design of car
company B, then the car companies will find AGL compelling. There
needs to be robust and plentiful automotive software connected to
stable, easy to understand APIs for that to happen.

Evangelizing for one HMI toolkit over the other seems a bit wrong-way
round. Shouldn't we have the actual software to interface to first?
Shouldn't we be talking about what is actually in the stack?

Cheers,

Jeremiah

[snip]


Todd Fuchs <tfuchs@...>
 

I agree 100%. Unfortunately we are not an underlying, core-services or API development company. We are simply the last stop once the software is near complete. So, you're right, the software and API's should always come first, as they will ultimately define what the functions of the UI are. We are merely the visual glue that puts it all together in the end on the screen :-) 

My only point was that as you develop these robust, easy to understand APIs, our UI should showcase their abilities. This is where the reference UI comes into play;  a "showroom", as Rudi put it, for AGL to be proud of, which is the sole purpose of Host Concepts' contributions. And of course we are available to any of the other contributing companies who may be working on non-API modules for AGL, such as media players, telephony components, etc, that are stand-alone, extended versions of what Tizen may offer out of the box.


Todd Fuchs
Chief Software Architect
O: (855) 344-6368
C: (561) 715-7166

On Nov 9, 2012, at 5:32 PM, Jeremiah Foster <jeremiah.foster@...> wrote:

Hi Todd,

On Fri, Nov 9, 2012 at 10:32 PM, Todd Fuchs <tfuchs@...> wrote:
Jeremiah,
Thanks for the feedback and contributions. I would like to remind everyone
who is part of AGL that while OEMs will always want to adopt their own UI as
a differentiator, they will still need to see the functionality of
everything AGL/Tizen has to offer. You can't sell a product to an OEM
without "showing it off" first. This is the purpose of the reference UI, and
my role as the UI Expert Group Lead. I find that this is a big mistake many
companies make, even in my industry (hospitality). Such minimal effort is
put into a base UI because the client will ultimately "Skin" their own
version, yet when the platform is demonstrated it doesn't get purchased
because it doesn't showcase it's true abilities with it's own UI.

I don't disagree with you. Demos always need to be shiny. :-)

What we ought not to forget is the underlying API. That is where the
value is. If car company A can create a fully functional system on top
of the AGL APIs that looks completely different from the design of car
company B, then the car companies will find AGL compelling. There
needs to be robust and plentiful automotive software connected to
stable, easy to understand APIs for that to happen.

Evangelizing for one HMI toolkit over the other seems a bit wrong-way
round. Shouldn't we have the actual software to interface to first?
Shouldn't we be talking about what is actually in the stack?

Cheers,

Jeremiah

[snip]


Konstantin A. Khait
 

Colleagues,

Regarding HMI, I am talking about a slightly different thing. HMI is almost always OEM property, that's clear for all of us. It doesn't mean that AGL (in particular) shouldn't provide a framework for HMI development and exposure. It can be Qt (which is good, but deflating), it can be Adobe AIR (which is also down), it can be HTML5 (which is the most promising) plus many of APIs. That's clear and it is not what I would like to provoke a discussion about.
My statement (second of three) is we need to elaborate several HMI frameworks to offer it in frames of AGL. Tizen is one of these frameworks, it is mostly oriented to high-end systems with big enough resource capacities. However, my understanding AGL is not GENIVI, it is not IVI only and it is not Tizen-centric (it is what we discussed with Rudy upon our initiation to Steering Committee). We offer to elaborate WebOS as an alternate framework. Why? Because our devices are mid-class (and will become low-end since the market changes). Tizen is too heavy for it. And Tizen-focused community is still narrow and not open enough.
I don't want to say Tizen is bad. I say AGL can't be equal to Tizen even in HMI framework portion. That's my message and I am looking for if anybody has pros and contras to it prior to go ahead.

Thanks,
Kostia

-----
Konstantin A. Khait
Componentality Oy
Tel: +358(0)465662016
+7(921)9005780
Skype: kostia.khait
E-Mail: khait@...
53100 Finland
Ratakatu 47
Lappeenranta 

> On Fri, Nov 9, 2012 at 2:31 PM, Juha-Matti Liukkonen
> <juha-matti.liukkonen@...> wrote:
>> Hi!

>> Thanks for raising a number of good topics, and joining in the discussion!

>> I also believe V2V/V2I are significant and interesting.

>> With regards to HMI, I expect that most automotive companies have their own
>> HMI solutions that they wish to use in product configurations. This is why
>> the discussion has focused on providing an UI primarily for testing and
>> demoing purposes - and to provide AGL its own "face".

> HMI is a key differentiator for OEMs. Tizen won't be successful, nor
> AGL, if it does not allow for an OEM to create their own look and
> feel.

>> However, the point you raise about UI toolkits is interesting: which UI
>> toolkits are really applicable in the automotive context right now? Which
>> ones you can get developers for now, and support in 10 years' time. EFL? Qt?
>> HTML5? Where are these toolkits headed, and are there other significant
>> contenders?

> EFL? I know that Samsung has done some work with EFL, but that
> framework has a miserable toolkit with fundamentally broken
> architecture. No one really uses EFL, not even community distros.

> Qt is widely used and automotive grade, see Qt IVI.

> HTML5 vehicle APIs are being defined already, and that work is best
> done in the W3C where it is happening:
> http://www.w3.org/2012/08/web-and-automotive/
> If you're interested I would get involved in the W3C at your earliest
> convenience since that train is leaving the station. Connection to
> various sensors through a web browser is always going to be somewhat
> problematic so HTML5 is not the silver bullet many think it is.

>> Regarding virtualization, we could perhaps first discuss virtualization
>> techniques in general?

> There are some seriously good RTOSes out there which work on a variety
> of architectures, ARM is coming with new virtualization techniques
> based on Xen (http://www.xen.org/products/xen_arm.html) and there are
> Linux Virtual Containers which are a very effective solution. I can't
> imagine there is much room in the marketplace for many alternatives
> beyond those and the commercial RTOSes, which already have
> relationships with the OEMs.

> Why would AGL be discussing virtualization anyway? It seems orthogonal
> to GNU/Linux userland and app discussion.

>> Consider available alternatives, the needs and
>> requirements in automotive use, think how does the container interface with
>> the host system (audio routing, data access, security etc), how are software
>> updates handled, and so on.

> I don't think we're going to be talking about ECU to ECU and CPU
> boundaries in AGL are we? Aren't those rather low level hardware
> details that a beyond the scope? If they are in scope, then I really
> think we need to have an ARM based reference design before you start
> drawing architecture dependent boundaries.

> I note that there is not much participation from ARM licensees on this
> list. Is there a reason? Can we encourage their participation?
> Otherwise discussion on low-level hardware solutions is moot.

> Regards,

> Jeremiah

>> Your input, ideas and experiences are much welcomed.

>> Cheers,
>> - Jussi

>> --
>> Juha-Matti Liukkonen
>> Technology Director, Embedded software
>> juha-matti.liukkonen@...
>> www.reaktorfusion.fi


>> _______________________________________________
>> automotive-discussions mailing list
>> automotive-discussions@...
>> https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions




Juha-Matti Liukkonen <juha-matti.liukkonen@...>
 

Hello!

I would like to recap one thing from the SC meeting: particularly the EG leads should first focus on understanding the use cases and constraints in their domains. This should lead into understanding of the necessary APIs and the software stack needed to implement them, which allows us to see how that stack and API could be improved to fulfill the automotive industry needs.

In this forum, we now have a number of Tier 1s and OEMs following and contributing to the discussion. Let's use this opportunity.

I would prefer to understand what we need to build before we focus on ways to build it. I have experience and opinions on Qt, WebOS and many other things, but I don't really know what's relevant until we have an understanding of what we need to do…  This being the -discussions list, it is good to see wild ideas thrown in, but let's remember the focus :-)

Kostia: The goal is not to be too Tizen-centric, it's just our agreed-upon default testbed. I can definitely see e.g. Yocto-built compact systems benefiting from the work should accomplish here.

Jeremiah: I expect to have an ARM reference board support ready and announced any day now, and we should have more rather soon. I won't guesstimate yet whether that means any shift of focus towards ECUs, but ARM based reference solutions are obviously needed.

Cheers,
- Jussi

--
Juha-Matti Liukkonen
Technology Director, Embedded software


Jeremiah C. Foster
 

But how does WebOS solve automotive needs? Specifically;

1. Where is the automotive software (do you plan to make WebOS run
Autosar or GENIVI software, i.e. a port?)
2. Where is the community of developers you get with GNU/Linux? (i.e.
Fedora, Debian, Ubuntu, Linux Mint, Tizen, etc.)

WebOS doesn't seem to run on much production hardware or even seem to
be backed by HP with many resources. While I think it offers a
reasonably good HTML5 framework, you're likely not going to be able to
build an ecosystem around that, or at least Palm and HP haven't been
able to yet.

Cheers,

Jeremiah

On Mon, Nov 12, 2012 at 6:39 AM, Kostia Khait <khait@mail.ru> wrote:
Colleagues,

Regarding HMI, I am talking about a slightly different thing. HMI is almost
always OEM property, that's clear for all of us. It doesn't mean that AGL
(in particular) shouldn't provide a framework for HMI development and
exposure. It can be Qt (which is good, but deflating), it can be Adobe AIR
(which is also down), it can be HTML5 (which is the most promising) plus
many of APIs. That's clear and it is not what I would like to provoke a
discussion about.
My statement (second of three) is we need to elaborate several HMI
frameworks to offer it in frames of AGL. Tizen is one of these frameworks,
it is mostly oriented to high-end systems with big enough resource
capacities. However, my understanding AGL is not GENIVI, it is not IVI only
and it is not Tizen-centric (it is what we discussed with Rudy upon our
initiation to Steering Committee). We offer to elaborate WebOS as an
alternate framework. Why? Because our devices are mid-class (and will become
low-end since the market changes). Tizen is too heavy for it. And
Tizen-focused community is still narrow and not open enough.
I don't want to say Tizen is bad. I say AGL can't be equal to Tizen even in
HMI framework portion. That's my message and I am looking for if anybody has
pros and contras to it prior to go ahead.

Thanks,
Kostia

-----
Konstantin A. Khait
Componentality Oy
Tel: +358(0)465662016
+7(921)9005780
Skype: kostia.khait
E-Mail: khait@componentality.com
53100 Finland
Ratakatu 47
Lappeenranta

On Fri, Nov 9, 2012 at 2:31 PM, Juha-Matti Liukkonen
<juha-matti.liukkonen@reaktor.fi> wrote:
Hi!
Thanks for raising a number of good topics, and joining in the
discussion!
I also believe V2V/V2I are significant and interesting.
With regards to HMI, I expect that most automotive companies have their
own
HMI solutions that they wish to use in product configurations. This is
why
the discussion has focused on providing an UI primarily for testing and
demoing purposes - and to provide AGL its own "face".
HMI is a key differentiator for OEMs. Tizen won't be successful, nor
AGL, if it does not allow for an OEM to create their own look and
feel.
However, the point you raise about UI toolkits is interesting: which UI
toolkits are really applicable in the automotive context right now? Which
ones you can get developers for now, and support in 10 years' time. EFL?
Qt?
HTML5? Where are these toolkits headed, and are there other significant
contenders?
EFL? I know that Samsung has done some work with EFL, but that
framework has a miserable toolkit with fundamentally broken
architecture. No one really uses EFL, not even community distros.
Qt is widely used and automotive grade, see Qt IVI.
HTML5 vehicle APIs are being defined already, and that work is best
done in the W3C where it is happening:
http://www.w3.org/2012/08/web-and-automotive/
If you're interested I would get involved in the W3C at your earliest
convenience since that train is leaving the station. Connection to
various sensors through a web browser is always going to be somewhat
problematic so HTML5 is not the silver bullet many think it is.
Regarding virtualization, we could perhaps first discuss virtualization
techniques in general?
There are some seriously good RTOSes out there which work on a variety
of architectures, ARM is coming with new virtualization techniques
based on Xen (http://www.xen.org/products/xen_arm.html) and there are
Linux Virtual Containers which are a very effective solution. I can't
imagine there is much room in the marketplace for many alternatives
beyond those and the commercial RTOSes, which already have
relationships with the OEMs.
Why would AGL be discussing virtualization anyway? It seems orthogonal
to GNU/Linux userland and app discussion.
Consider available alternatives, the needs and
requirements in automotive use, think how does the container interface
with
the host system (audio routing, data access, security etc), how are
software
updates handled, and so on.
I don't think we're going to be talking about ECU to ECU and CPU
boundaries in AGL are we? Aren't those rather low level hardware
details that a beyond the scope? If they are in scope, then I really
think we need to have an ARM based reference design before you start
drawing architecture dependent boundaries.
I note that there is not much participation from ARM licensees on this
list. Is there a reason? Can we encourage their participation?
Otherwise discussion on low-level hardware solutions is moot.
Regards,
Jeremiah
Your input, ideas and experiences are much welcomed.
Cheers,
- Jussi
--
Juha-Matti Liukkonen
Technology Director, Embedded software
juha-matti.liukkonen@reaktor.fi
www.reaktorfusion.fi

_______________________________________________
automotive-discussions mailing list
automotive-discussions@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions

--
=============================================
Jeremiah C. Foster エレミア フォスター
Open Source Technologist
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)730 93 0506
E-Mail: jeremiah.foster@pelagicore.com
=============================================

=== NOTE ===
The information contained in this E-mail message is
intended only for use of the individual or entity
named above. If the reader of this message is not
the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited.
=============


Jeremiah C. Foster
 

On Mon, Nov 12, 2012 at 9:01 AM, Juha-Matti Liukkonen
<juha-matti.liukkonen@reaktor.fi> wrote:
Hello!
[snip]

Jeremiah: I expect to have an ARM reference board support ready and
announced any day now, and we should have more rather soon. I won't
guesstimate yet whether that means any shift of focus towards ECUs, but ARM
based reference solutions are obviously needed.
My impression is that we have all the ARM references we need right now
running a variety of solid software stacks, so yet _another_ ARM
reference is probably not what the market needs. Rather, any
discussion going forward ought to ensure that there is strong support
for cross-platform solutions no matter what software is created.

As a general note Juha-Matti, the classic open source model is often a
wide ranging discussion, at least to begin with. You may not want to
limit people's contribution to the list, it really should be open to
what they're interested in. I realize you want structure and focus,
but those things will come once there is code. :-)

Regards,

Jeremiah

Cheers,
- Jussi

--
Juha-Matti Liukkonen
Technology Director, Embedded software
juha-matti.liukkonen@reaktor.fi
www.reaktorfusion.fi


--
=============================================
Jeremiah C. Foster エレミア フォスター
Open Source Technologist
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)730 93 0506
E-Mail: jeremiah.foster@pelagicore.com
=============================================

=== NOTE ===
The information contained in this E-mail message is
intended only for use of the individual or entity
named above. If the reader of this message is not
the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited.
=============


Juha-Matti Liukkonen <juha-matti.liukkonen@...>
 

Hi!

On 12.11.2012, at 11:50, Jeremiah Foster <jeremiah.foster@...> wrote:

My impression is that we have all the ARM references we need right now
running a variety of solid software stacks, so yet _another_ ARM
reference is probably not what the market needs. Rather, any
discussion going forward ought to ensure that there is strong support
for cross-platform solutions no matter what software is created.

In this particular case, there was specific market demand. Several parties wanted to see the AGL stack (as its current embodiment) running on ARM platforms -- as proof of cross-platform applicability. This enforces your point, cross-platform support is important, for both individual components and the reference platform too.

As a general note Juha-Matti, the classic open source model is often a
wide ranging discussion, at least to begin with. You may not want to
limit people's contribution to the list, it really should be open to
what they're interested in. I realize you want structure and focus,
but those things will come once there is code. :-)

Also very much agreed. Free discussion is the point of this list and very much encouraged. Merely reminding the EG leads in particular of what the steering committee was looking for.

Cheers,
- Jussi (almost every Juha in Finland is nick-named Jussi…)

--
Juha-Matti Liukkonen
Technology Director, Embedded software


Jeremiah C. Foster
 

On Mon, Nov 12, 2012 at 11:11 AM, Juha-Matti Liukkonen
<juha-matti.liukkonen@reaktor.fi> wrote:
Hi!

On 12.11.2012, at 11:50, Jeremiah Foster <jeremiah.foster@pelagicore.com>
wrote:

My impression is that we have all the ARM references we need right now
running a variety of solid software stacks, so yet _another_ ARM
reference is probably not what the market needs. Rather, any
discussion going forward ought to ensure that there is strong support
for cross-platform solutions no matter what software is created.

In this particular case, there was specific market demand. Several parties
wanted to see the AGL stack (as its current embodiment) running on ARM
platforms -- as proof of cross-platform applicability. This enforces your
point, cross-platform support is important, for both individual components
and the reference platform too.
When you say "AGL stack," does this mean Tizen IVI on ARM? If so,
where are the repos for that stack since I presume a lot of it is GPL
software and ought to be open, unless it was never distributed.

Cheers,

Jeremiah

--
=============================================
Jeremiah C. Foster エレミア フォスター
Open Source Technologist
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)730 93 0506
E-Mail: jeremiah.foster@pelagicore.com
=============================================

=== NOTE ===
The information contained in this E-mail message is
intended only for use of the individual or entity
named above. If the reader of this message is not
the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited.
=============


Juha-Matti Liukkonen <juha-matti.liukkonen@...>
 


On 12.11.2012, at 12:14, Jeremiah Foster <jeremiah.foster@...> wrote:

When you say "AGL stack," does this mean Tizen IVI on ARM? If so,
where are the repos for that stack since I presume a lot of it is GPL
software and ought to be open, unless it was never distributed.

Yes it does. I've been told the repos should soon be open, to act as a reference build for AGL. Not done by us though so I don't have control over the procedure.

Cheers,
- Jussi

--
Juha-Matti Liukkonen
Technology Director, Embedded software


Jeremiah C. Foster
 

On Mon, Nov 12, 2012 at 11:23 AM, Juha-Matti Liukkonen
<juha-matti.liukkonen@reaktor.fi> wrote:

On 12.11.2012, at 12:14, Jeremiah Foster <jeremiah.foster@pelagicore.com>
wrote:

When you say "AGL stack," does this mean Tizen IVI on ARM? If so,
where are the repos for that stack since I presume a lot of it is GPL
software and ought to be open, unless it was never distributed.


Yes it does. I've been told the repos should soon be open, to act as a
reference build for AGL. Not done by us though so I don't have control over
the procedure.
Okay, thanks for the info Jussi! I'll keep my eyes open for an ARM AGL release.

Cheers,

Jeremiah

Cheers,
- Jussi

--
Juha-Matti Liukkonen
Technology Director, Embedded software
juha-matti.liukkonen@reaktor.fi
www.reaktorfusion.fi


--
=============================================
Jeremiah C. Foster エレミア フォスター
Open Source Technologist
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)730 93 0506
E-Mail: jeremiah.foster@pelagicore.com
=============================================

=== NOTE ===
The information contained in this E-mail message is
intended only for use of the individual or entity
named above. If the reader of this message is not
the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited.
=============


Konstantin A. Khait
 

Hm... As a permanent memeber of GENIVI, Telematics Update and other industrial events, I can say the following (with high level of confidence):

1. There's no ready to use GENIVI software. GENIVI makes set of standards for Linux components, this process is very far from the end and GENIVI baselines are just references which nobody plans using as a software stack now. Moreover, GENIVI doesn't have a goal to make a kind of common software baseline, but just a set of specifications defining which software is GENIVI compliant and which is not.

2. There's no unified "automotive software" on this market yet. Every OEM and Tier 1 does its own software with almost nothing common except technology intensive libraries like speech recognition, browser, navigation core and few more.

So, the question of Jeremiah must be rephrased to "which market demands WebOS can respond".
My answers are following:

- Ready to use HMI framework (not HMI itself!), based on HTML/JS
- Ready to use OS APIs with high level of robustness
- Light and open operating system framework with enough level of quality

And let's be clear. After 12 years in automotive I know as well as you know: automotive software is not a kind of space shuttle software. It has some specific like drivers (CAN, MOST...), quality requirements and ergonomics (which is very special, but now under number of discussions), but generally it is just a kind of high level embedded software. Head Unit becomes more or less like a big tablet and if something (except HMI, but not HMI framework) is good for tablet and has enought reliability, it is also good for automotive.

Thanks,
Kostia

-----
Konstantin A. Khait
Componentality Oy
Tel: +358(0)465662016
       +7(921)9005780
Skype: kostia.khait
E-Mail: khait@...
53100 Finland
Ratakatu 47
Lappeenranta

> But how does WebOS solve automotive needs? Specifically;

> 1. Where is the automotive software (do you plan to make WebOS run
> Autosar or GENIVI software, i.e. a port?)
> 2. Where is the community of developers you get with GNU/Linux? (i.e.
> Fedora, Debian, Ubuntu, Linux Mint, Tizen, etc.)

> WebOS doesn't seem to run on much production hardware or even seem to
> be backed by HP with many resources. While I think it offers a
> reasonably good HTML5 framework, you're likely not going to be able to
> build an ecosystem around that, or at least Palm and HP haven't been
> able to yet.

> Cheers,

> Jeremiah

> On Mon, Nov 12, 2012 at 6:39 AM, Kostia Khait <khait@...> wrote:
>> Colleagues,

>> Regarding HMI, I am talking about a slightly different thing. HMI is almost
>> always OEM property, that's clear for all of us. It doesn't mean that AGL
>> (in particular) shouldn't provide a framework for HMI development and
>> exposure. It can be Qt (which is good, but deflating), it can be Adobe AIR
>> (which is also down), it can be HTML5 (which is the most promising) plus
>> many of APIs. That's clear and it is not what I would like to provoke a
>> discussion about.
>> My statement (second of three) is we need to elaborate several HMI
>> frameworks to offer it in frames of AGL. Tizen is one of these frameworks,
>> it is mostly oriented to high-end systems with big enough resource
>> capacities. However, my understanding AGL is not GENIVI, it is not IVI only
>> and it is not Tizen-centric (it is what we discussed with Rudy upon our
>> initiation to Steering Committee). We offer to elaborate WebOS as an
>> alternate framework. Why? Because our devices are mid-class (and will become
>> low-end since the market changes). Tizen is too heavy for it. And
>> Tizen-focused community is still narrow and not open enough.
>> I don't want to say Tizen is bad. I say AGL can't be equal to Tizen even in
>> HMI framework portion. That's my message and I am looking for if anybody has
>> pros and contras to it prior to go ahead.

>> Thanks,
>> Kostia

>> -----
>> Konstantin A. Khait
>> Componentality Oy
>> Tel: +358(0)465662016
>> +7(921)9005780
>> Skype: kostia.khait
>> E-Mail: khait@...
>> 53100 Finland
>> Ratakatu 47
>> Lappeenranta

>>> On Fri, Nov 9, 2012 at 2:31 PM, Juha-Matti Liukkonen
>>> <juha-matti.liukkonen@...> wrote:
>>>> Hi!

>>>> Thanks for raising a number of good topics, and joining in the
>>>> discussion!

>>>> I also believe V2V/V2I are significant and interesting.

>>>> With regards to HMI, I expect that most automotive companies have their
>>>> own
>>>> HMI solutions that they wish to use in product configurations. This is
>>>> why
>>>> the discussion has focused on providing an UI primarily for testing and
>>>> demoing purposes - and to provide AGL its own "face".

>>> HMI is a key differentiator for OEMs. Tizen won't be successful, nor
>>> AGL, if it does not allow for an OEM to create their own look and
>>> feel.

>>>> However, the point you raise about UI toolkits is interesting: which UI
>>>> toolkits are really applicable in the automotive context right now? Which
>>>> ones you can get developers for now, and support in 10 years' time. EFL?
>>>> Qt?
>>>> HTML5? Where are these toolkits headed, and are there other significant
>>>> contenders?

>>> EFL? I know that Samsung has done some work with EFL, but that
>>> framework has a miserable toolkit with fundamentally broken
>>> architecture. No one really uses EFL, not even community distros.

>>> Qt is widely used and automotive grade, see Qt IVI.

>>> HTML5 vehicle APIs are being defined already, and that work is best
>>> done in the W3C where it is happening:
>>> http://www.w3.org/2012/08/web-and-automotive/
>>> If you're interested I would get involved in the W3C at your earliest
>>> convenience since that train is leaving the station. Connection to
>>> various sensors through a web browser is always going to be somewhat
>>> problematic so HTML5 is not the silver bullet many think it is.

>>>> Regarding virtualization, we could perhaps first discuss virtualization
>>>> techniques in general?

>>> There are some seriously good RTOSes out there which work on a variety
>>> of architectures, ARM is coming with new virtualization techniques
>>> based on Xen (http://www.xen.org/products/xen_arm.html) and there are
>>> Linux Virtual Containers which are a very effective solution. I can't
>>> imagine there is much room in the marketplace for many alternatives
>>> beyond those and the commercial RTOSes, which already have
>>> relationships with the OEMs.

>>> Why would AGL be discussing virtualization anyway? It seems orthogonal
>>> to GNU/Linux userland and app discussion.

>>>> Consider available alternatives, the needs and
>>>> requirements in automotive use, think how does the container interface
>>>> with
>>>> the host system (audio routing, data access, security etc), how are
>>>> software
>>>> updates handled, and so on.

>>> I don't think we're going to be talking about ECU to ECU and CPU
>>> boundaries in AGL are we? Aren't those rather low level hardware
>>> details that a beyond the scope? If they are in scope, then I really
>>> think we need to have an ARM based reference design before you start
>>> drawing architecture dependent boundaries.

>>> I note that there is not much participation from ARM licensees on this
>>> list. Is there a reason? Can we encourage their participation?
>>> Otherwise discussion on low-level hardware solutions is moot.

>>> Regards,

>>> Jeremiah

>>>> Your input, ideas and experiences are much welcomed.

>>>> Cheers,
>>>> - Jussi

>>>> --
>>>> Juha-Matti Liukkonen
>>>> Technology Director, Embedded software
>>>> juha-matti.liukkonen@...
>>>> www.reaktorfusion.fi


>>>> _______________________________________________
>>>> automotive-discussions mailing list
>>>> automotive-discussions@...
>>>> https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions



Konstantin A. Khait
 

Hi,
I believe that actually FreeScale iMX53 ARM Cortex A8 is the most common CPU in automotive. GENIVI is focused on iMX53 QSB and I'd recommend the same for AGL whether we want just one reference platform. However as the automotive HW is still a zoo (ARM, Intel, Hitachi, even PowerPC and MIPS), any lack of portability will be definitely a disadvantage.

And I still concern if AGL really should be focusing on IVI so close...

Thanks,
Kostia

-----
Konstantin A. Khait
Componentality Oy
Tel: +358(0)465662016
       +7(921)9005780
Skype: kostia.khait
E-Mail: khait@...
53100 Finland
Ratakatu 47
Lappeenranta



Hi!

On 12.11.2012, at 11:50, Jeremiah Foster <jeremiah.foster@...> wrote:

My impression is that we have all the ARM references we need right now
running a variety of solid software stacks, so yet _another_ ARM
reference is probably not what the market needs. Rather, any
discussion going forward ought to ensure that there is strong support
for cross-platform solutions no matter what software is created.

In this particular case, there was specific market demand. Several parties wanted to see the AGL stack (as its current embodiment) running on ARM platforms -- as proof of cross-platform applicability. This enforces your point, cross-platform support is important, for both individual components and the reference platform too.

As a general note Juha-Matti, the classic open source model is often a
wide ranging discussion, at least to begin with. You may not want to
limit people's contribution to the list, it really should be open to
what they're interested in. I realize you want structure and focus,
but those things will come once there is code. :-)

Also very much agreed. Free discussion is the point of this list and very much encouraged. Merely reminding the EG leads in particular of what the steering committee was looking for.

Cheers,
- Jussi (almost every Juha in Finland is nick-named Jussi…)

--
Juha-Matti Liukkonen
Technology Director, Embedded software
juha-matti.liukkonen@...
www.reaktorfusion.fi



Jeremiah C. Foster
 

On Mon, Nov 12, 2012 at 2:45 PM, Kostia Khait <khait@mail.ru> wrote:
Hm... As a permanent memeber of GENIVI, Telematics Update and other
industrial events, I can say the following (with high level of confidence):

1. There's no ready to use GENIVI software.
Really? What about these repos and projects hosted at the Linux Foundation:
http://www.genivi.org/projects
http://git.projects.genivi.org/

GENIVI makes set of standards
for Linux components, this process is very far from the end and GENIVI
baselines are just references which nobody plans using as a software stack
now.
Really? I know of at least one GENIVI stack already in production.

Moreover, GENIVI doesn't have a goal to make a kind of common software
baseline, but just a set of specifications defining which software is GENIVI
compliant and which is not.
Well, kinda sorta. GENIVI does have a goal to make a baseline, (I
know, I've helped create every single one since Apollo :)
The baselines are not public, at least not officially and not directly
from GENIVI. But if you look at Yocto you can find a meta-ivi layer
which will help you build something that actually comes pretty darn
close to an official baseline.

2. There's no unified "automotive software" on this market yet. Every OEM
and Tier 1 does its own software with almost nothing common except
technology intensive libraries like speech recognition, browser, navigation
core and few more.
Really? You mean that an Autosar stack is not common amongst many OEMs?

So, the question of Jeremiah must be rephrased to "which market demands
WebOS can respond".
My answers are following:

- Ready to use HMI framework (not HMI itself!), based on HTML/JS
- Ready to use OS APIs with high level of robustness
- Light and open operating system framework with enough level of quality

And let's be clear. After 12 years in automotive I know as well as you know:
automotive software is not a kind of space shuttle software. It has some
specific like drivers (CAN, MOST...), quality requirements and ergonomics
(which is very special, but now under number of discussions), but generally
it is just a kind of high level embedded software. Head Unit becomes more or
less like a big tablet and if something (except HMI, but not HMI framework)
is good for tablet and has enought reliability, it is also good for
automotive.
A head unit is not a phone.

Cheers,

Jeremiah


Thanks,
Kostia

-----
Konstantin A. Khait
Componentality Oy
Tel: +358(0)465662016
+7(921)9005780
Skype: kostia.khait
E-Mail: khait@componentality.com
53100 Finland
Ratakatu 47
Lappeenranta

But how does WebOS solve automotive needs? Specifically;
1. Where is the automotive software (do you plan to make WebOS run
Autosar or GENIVI software, i.e. a port?)
2. Where is the community of developers you get with GNU/Linux? (i.e.
Fedora, Debian, Ubuntu, Linux Mint, Tizen, etc.)
WebOS doesn't seem to run on much production hardware or even seem to
be backed by HP with many resources. While I think it offers a
reasonably good HTML5 framework, you're likely not going to be able to
build an ecosystem around that, or at least Palm and HP haven't been
able to yet.
Cheers,
Jeremiah
On Mon, Nov 12, 2012 at 6:39 AM, Kostia Khait <khait@mail.ru> wrote:
Colleagues,
Regarding HMI, I am talking about a slightly different thing. HMI is
almost
always OEM property, that's clear for all of us. It doesn't mean that AGL
(in particular) shouldn't provide a framework for HMI development and
exposure. It can be Qt (which is good, but deflating), it can be Adobe
AIR
(which is also down), it can be HTML5 (which is the most promising) plus
many of APIs. That's clear and it is not what I would like to provoke a
discussion about.
My statement (second of three) is we need to elaborate several HMI
frameworks to offer it in frames of AGL. Tizen is one of these
frameworks,
it is mostly oriented to high-end systems with big enough resource
capacities. However, my understanding AGL is not GENIVI, it is not IVI
only
and it is not Tizen-centric (it is what we discussed with Rudy upon our
initiation to Steering Committee). We offer to elaborate WebOS as an
alternate framework. Why? Because our devices are mid-class (and will
become
low-end since the market changes). Tizen is too heavy for it. And
Tizen-focused community is still narrow and not open enough.
I don't want to say Tizen is bad. I say AGL can't be equal to Tizen even
in
HMI framework portion. That's my message and I am looking for if anybody
has
pros and contras to it prior to go ahead.
Thanks,
Kostia
-----
Konstantin A. Khait
Componentality Oy
Tel: +358(0)465662016
+7(921)9005780
Skype: kostia.khait
E-Mail: khait@componentality.com
53100 Finland
Ratakatu 47
Lappeenranta
On Fri, Nov 9, 2012 at 2:31 PM, Juha-Matti Liukkonen
<juha-matti.liukkonen@reaktor.fi> wrote:
Hi!
Thanks for raising a number of good topics, and joining in the
discussion!
I also believe V2V/V2I are significant and interesting.
With regards to HMI, I expect that most automotive companies have their
own
HMI solutions that they wish to use in product configurations. This is
why
the discussion has focused on providing an UI primarily for testing and
demoing purposes - and to provide AGL its own "face".
HMI is a key differentiator for OEMs. Tizen won't be successful, nor
AGL, if it does not allow for an OEM to create their own look and
feel.
However, the point you raise about UI toolkits is interesting: which UI
toolkits are really applicable in the automotive context right now?
Which
ones you can get developers for now, and support in 10 years' time.
EFL?
Qt?
HTML5? Where are these toolkits headed, and are there other significant
contenders?
EFL? I know that Samsung has done some work with EFL, but that
framework has a miserable toolkit with fundamentally broken
architecture. No one really uses EFL, not even community distros.
Qt is widely used and automotive grade, see Qt IVI.
HTML5 vehicle APIs are being defined already, and that work is best
done in the W3C where it is happening:
http://www.w3.org/2012/08/web-and-automotive/
If you're interested I would get involved in the W3C at your earliest
convenience since that train is leaving the station. Connection to
various sensors through a web browser is always going to be somewhat
problematic so HTML5 is not the silver bullet many think it is.
Regarding virtualization, we could perhaps first discuss virtualization
techniques in general?
There are some seriously good RTOSes out there which work on a variety
of architectures, ARM is coming with new virtualization techniques
based on Xen (http://www.xen.org/products/xen_arm.html) and there are
Linux Virtual Containers which are a very effective solution. I can't
imagine there is much room in the marketplace for many alternatives
beyond those and the commercial RTOSes, which already have
relationships with the OEMs.
Why would AGL be discussing virtualization anyway? It seems orthogonal
to GNU/Linux userland and app discussion.
Consider available alternatives, the needs and
requirements in automotive use, think how does the container interface
with
the host system (audio routing, data access, security etc), how are
software
updates handled, and so on.
I don't think we're going to be talking about ECU to ECU and CPU
boundaries in AGL are we? Aren't those rather low level hardware
details that a beyond the scope? If they are in scope, then I really
think we need to have an ARM based reference design before you start
drawing architecture dependent boundaries.
I note that there is not much participation from ARM licensees on this
list. Is there a reason? Can we encourage their participation?
Otherwise discussion on low-level hardware solutions is moot.
Regards,
Jeremiah
Your input, ideas and experiences are much welcomed.
Cheers,
- Jussi
--
Juha-Matti Liukkonen
Technology Director, Embedded software
juha-matti.liukkonen@reaktor.fi
www.reaktorfusion.fi

_______________________________________________
automotive-discussions mailing list
automotive-discussions@lists.linuxfoundation.org

https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions


--
=============================================
Jeremiah C. Foster エレミア フォスター
Open Source Technologist
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)730 93 0506
E-Mail: jeremiah.foster@pelagicore.com
=============================================

=== NOTE ===
The information contained in this E-mail message is
intended only for use of the individual or entity
named above. If the reader of this message is not
the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited.
=============