Date
1 - 20 of 75
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!
toggle quoted messageShow quoted text
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.
On Nov 8, 2012, at 6:18 AM, Juha-Matti Liukkonen <juha-matti.liukkonen@...> wrote:
|
||
|
|
||
|
Konstantin A. Khait <khait@...>
Hi All,
toggle quoted messageShow quoted text
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
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
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! With regards to HMI, I expect that most automotive companies have their ownHMI 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 UIEFL? 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 virtualizationThere 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 andI 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. -- ============================================= 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,
toggle quoted messageShow quoted text
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.
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
|
||
|
|
||
|
Jeremiah C. Foster
Hi Todd,
On Fri, Nov 9, 2012 at 10:32 PM, Todd Fuchs <tfuchs@hostconcepts.com> wrote: Jeremiah,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 :-)
toggle quoted messageShow quoted text
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,
|
||
|
|
||
|
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;
toggle quoted messageShow quoted text
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, --
============================================= 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 andMy 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, -- ============================================= 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 As a general note Juha-Matti, the classic open source model is often a 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!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, 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: Okay, thanks for the info Jussi! I'll keep my eyes open for an ARM AGL release. Cheers, Jeremiah Cheers, -- ============================================= 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,
toggle quoted messageShow quoted text
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
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 otherReally? 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 standardsReally? I know of at least one GENIVI stack already in production. Moreover, GENIVI doesn't have a goal to make a kind of common softwareWell, 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 OEMReally? You mean that an Autosar stack is not common amongst many OEMs? So, the question of Jeremiah must be rephrased to "which market demandsA head unit is not a phone. 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. =============
|
||
|
|