ALS: Automotive Grade Linux
Did you know...? LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net. |
Using Linux in cars is a hot topic, even if the market is less visible to most developers than tablets or mobile phones. The Linux Foundation (LF) announced an initiative at the second Automotive Linux Summit in Gaydon, UK, however, that may result in a higher profile for automotive Linux development. The initiative is called Automotive Grade Linux (AGL), and its goal is to produce a distribution tuned for deployment throughout a vehicle, including in-dash systems, instrument clusters, and even safety-critical engine control units. A number of automakers and industry players are on board — which sparked some confusion at the announcement, because many of the same companies are also involved with existing Linux-based automotive efforts like GENIVI.
AGL announced
LF Executive Director Jim Zemlin announced AGL in an Automotive Linux Summit keynote on September 19. Three automakers are founding participants: Toyota, Nissan, and Jaguar Land Rover. They are joined by a number of electronics and silicon vendors, including Texas Instruments, Intel, Samsung, and Fujitsu. Officially, AGL is a "workgroup," as distinguished from a software project. Zemlin likened it to Carrier Grade Linux, a workgroup started by telecommunications companies in 2002 to address that industry's needs as it migrated its equipment to Linux from proprietary operating systems.
The AGL announcement states that the workgroup
"will facilitate widespread industry collaboration that advances
automotive device development, providing a community reference
platform that companies can use for creating products
". That
reference platform, it continues, will be a Tizen-based distribution
"optimized for a broad set of automotive applications ranging
from Instrumentation Cluster to In-Vehicle-Infotainment (IVI) and
more.
" The announcement specifically mentions fast boot and
extended lifecycle support for automotive products as features, and
says that the workgroup will support other industry efforts like
GENIVI and the W3C's Web and
Automotive workshop.
During the Summit, a number of people — speakers included
— expressed puzzlement about AGL, specifically with regard to
what its ultimate "deliverables" will be, and to how exactly it
competes or cooperates with the other automotive Linux efforts like
GENIVI and Tizen's IVI platform. Zemlin noted in his keynote
that there is no automotive-focused equivalent to the community-based
distributions like Debian and Fedora, and said that as a result it is
much more difficult for interested community developers to get started
working on the automotive-specific problems faced by carmakers and product
vendors. There is now an AGL site alive at automotive.linuxfoundation.org,
which provides a bit more detail, and references that same issue on
its "About" page. It compares the community-managed Debian and Fedora
to the commercially-supported Ubuntu and Red Hat Enterprise Linux, and
says "In a similar manner, AGL is seeking to become the upstream
Linux distribution for automotive use by facilitating cooperation
between multiple industries and the open-source communities.
"
So, then, the "product" to be produced by AGL would appear to be a
full-fledged Linux distribution, rather than a suite of platform
packages or a specification. As to the scope of the project, the site
also says AGL is not limited to IVI systems, but also encompasses
"instrument clusters, climate control, intelligent roadway
instrumentation, etc.
" The site also sets out a project
structure, including a steering committee, steering committee
coordinator, and various expert groups tasked with developing specific
features. The makeup of the committee and the specifics of the expert
groups have not been announced; there are, however, two public mailing
lists available (in addition to a private one for the steering committee).
Whither GENIVI?
Although the announcement and site both say that AGL is not a challenger to GENIVI, it is not difficult to see why some people (particularly those working on GENIVI) either perceive the projects as potential competitors or fear a duplication of effort. Both, after all, are automotive industry associations attempting to build a Linux-based platform that meets the shared requirements of car manufacturers and tier-one equipment makers (and indeed quite a few industry players are members of both efforts). Both target Linux and core services that need to be adapted from the desktop/server/mobile markets where Linux is already established, and both envision their software as some sort of "reference implementation." GENIVI's output is a baseline which is "respun" into other distributions, while AGL's is an "upstream" distribution intended to be adapted and optimized in products.
Still, as similar as that language sounds, there are some arguably important details that distinguish the two projects' goals. First, GENIVI is ultimately a compliance-driven specification: the baseline software that it creates en route is simply a means to that end. This process can be confusing, in large part because both the specification itself and the compliance process are closed to non-GENIVI members. Consequently, those on the outside primarily see the commercial products and distributions that reach compliance.
Second, GENIVI is targeting a middleware platform only. That is to say, the purpose of certifying a particular software stack as GENIVI compliant is that it offers guarantees regarding application- and service-level compatibility. As Visteon's Pavel Konopelko explained in his session, the specification includes numerous "abstract" and "placeholder" components. For example, the Bluetooth stack could be Linux's native BlueZ or a proprietary replacement; either would qualify as long as it implements the required functionality. In addition, GENIVI has not tackled lower-level topics like Controller Area Network (CAN) bus support. CAN bus is a common transport mechanism, but it sits well below the application layer.
Of course, CAN bus may be on its way out; the protocol offers no security and certainly lacks the flexibility of standard TCP/IP. But because GENIVI is also focused on IVI systems specifically, inter-device communication is a bit of a tangent. A third difference between the projects is that AGL draws a wider circle, encompassing non-IVI components. Over the course of the Summit, there were talks about other automotive computing issues, such as communicating with intelligent roadways — e.g., to automatically relay speed limit information or safety reports. Jaguar Land Rover operated an exhibit at the summit's venue, the British Motor Heritage Center, that focused on its new vehicles' automatic adjustments to suspension, braking, and handling in response to off-road conditions. Such things are certainly outside the purview of IVI and, like engine control units (ECUs), probably even more meticulously scrutinized by company lawyers.
The other side to the answer is that AGL bills itself as an open collaboration project, while GENIVI is still members-only. There appears to be movement toward additional openness from GENIVI, and several GENIVI speakers alluded to forthcoming progress on that front at the summit. Of course, AGL has yet to get rolling; it is always possible that the corporate membership will be more secretive than the volunteer free software contributor community would like as well.
Tizen, workgroups, and collaboration
Another factor worth assessing is how AGL will affect the Tizen project. Tizen's two main supporters, Intel and Samsung, are AGL members as well, and the AGL project has already announced that it will use Tizen as the basis of its distribution. On the one hand, this seems to make AGL both an "upstream distribution" to its corporate adopters and a "downstream distribution" to the Tizen Project, which otherwise appears unchanged. On the other hand, perhaps seeing Tizen used as the basis of AGL's distribution work will make Tizen's insistence that it is a "platform" and not a distribution itself a little easier to parse.
Then again, what constitutes a platform and what constitutes a distinct distribution is largely a word game (for proof of that, consider the ever-expanding litany of X-as-a-Service acronyms generated by the cloud computing sector). Tizen remains committed to offering a Linux system that consumer device makers can build on in multiple categories. Tizen (and MeeGo before) it have been advertising such flexible functionality for two years or so, but the automotive market has always seemed to be the ripest for adoption. We may not see Tizen-based phones in the near future, and TVs or set-top boxes are likely to not sport platform branding at all, so perhaps focusing on automotive Linux is the quickest path to success anyway. The difficulty will be managing AGL's insistence that it is building a distribution for IVI and non-IVI automotive computing. The Tizen and MeeGo efforts were explicitly IVI-focused, and skeptics could be forgiven for wondering if Tizen's HTML5 application platform is sufficient for safety-critical uses like dashboard instrument clusters.
One attendee at the summit joked privately that AGL was probably formed because Toyota wanted to be in the driver's seat (pardon the expression). That is a bit cynical if taken at face value, but even if it were true, the LF does exist to accommodate companies that are new to collaborating around Linux. Periodically that may mean hosting a workgroup (such as Carrier Grade Linux or the Consumer Electronics workgroup (CELF)) that seems quite a ways outside the mainstream community. What matters in the long run, however, is that most of these companies eventually become mainstream contributors to the kernel and other parts of the standard Linux stack. Those companies may have unease about working with free software, or about collaborating with their competitors, but often these industry efforts produce work that benefits the rest of the community. The Long Term Support Initiative, for example, grew out of CELF.
It was clear from the Automotive Linux Summit that the car industry is ready to migrate to Linux as quickly as it can manage the transition; the costs of developing and supporting proprietary systems add up more quickly in automotive than they do in most other fields, in no small part because of the decade-long lifecycle of the automobile. Car-buyers expect their vehicles to be serviceable (and, in fact, dealer-serviceable) for ten or more years, a situation that Matt Jones of Jaguar Land Rover said led to his company's current burden of simultaneously supporting three unrelated IVI platforms at different times in recent years. At the moment, the launch of AGL may seem to crowd in on GENIVI, but there is no shortage of development to be done. Besides, who knows? Three or four years from now the two projects may have enough in common to work hand-in-hand or to merge — yet that will still be less than halfway through the lifespan of a typical automotive computer.
[The author would like to thank the Linux Foundation for travel assistance to ALS.]
Index entries for this article | |
---|---|
Conference | Automotive Linux Summit/2012 |
(Log in to post comments)
ALS: Automotive Grade Linux
Posted Sep 26, 2012 20:01 UTC (Wed) by aleXXX (subscriber, #2742) [Link]
...but it comes with timing guarantees, which you probably want to have when things like the braking system etc. use it for communication.
Alex
ALS: Automotive Grade Linux
Posted Sep 27, 2012 4:24 UTC (Thu) by smurf (subscriber, #17840) [Link]
The bells and whistles should be replace-able with TCP/IP very easily.
The low-level stuff, not so much, obviously.
ALS: Automotive Grade Linux
Posted Sep 27, 2012 16:39 UTC (Thu) by alison (subscriber, #63752) [Link]
As someone who has participated in GENIVI, I am excited about the new AGL and look forward to learning more. I am delighted that the previously quiet Toyota is stepping up to provide leadership alongside Samsung and Intel with Tizen. Linux is winning big in automotive, which will be an increasingly vital arena as autonomous vehicles become inevitable. California has made self-driving cars legal within the week, so we shouldn't squabble, but roll up our sleeves and get to the work.
The article is yet more great coverage of Linux IVI by Nate Willis and Michael Kerrisk. Thank you LWN!
ALS: Automotive Grade Linux
Posted Sep 27, 2012 18:43 UTC (Thu) by dmk (guest, #50141) [Link]
ALS: Automotive Grade Linux
Posted Oct 6, 2012 6:26 UTC (Sat) by alison (subscriber, #63752) [Link]
http://she-devel.com/Mazda3_Controller_Area_Network_Exper...
My vehicle dates to 2005, so newer cars likely do have better security, although the kind of inter-bus communication I report is observed in many newer models as well.
ALS: Automotive Grade Linux
Posted Sep 27, 2012 14:57 UTC (Thu) by giggls (subscriber, #48434) [Link]
Sven
ALS: Automotive Grade Linux
Posted Sep 27, 2012 19:59 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
ALS: Automotive Grade Linux
Posted Sep 27, 2012 4:45 UTC (Thu) by pabs (subscriber, #43278) [Link]
http://wiki.debian.org/DebianAutomotive
http://bugs.debian.org/688629
http://bugs.debian.org/688627
http://bugs.debian.org/688586
http://bugs.debian.org/568303
http://bugs.debian.org/486470
http://bugs.debian.org/505551
ALS: Automotive Grade Linux
Posted Sep 27, 2012 19:48 UTC (Thu) by daglwn (guest, #65432) [Link]
ALS: Automotive Grade Linux
Posted Sep 28, 2012 10:34 UTC (Fri) by pabs (subscriber, #43278) [Link]
ALS: Automotive Grade Linux
Posted Sep 28, 2012 15:38 UTC (Fri) by daglwn (guest, #65432) [Link]
I assume that one would have to do some custom work to integrate navit or monav (or any application) into this IVI system. As I understand it, these packages basically act as a compositor. Code providing the actual information and interfaces exists as separate applications. I was hoping some of those applications written with these base libraries in mind might be available as Free Software.
ALS: Automotive Grade Linux
Posted Sep 28, 2012 16:22 UTC (Fri) by n8willis (subscriber, #43041) [Link]
I'm afraid there aren't a whole heck of a lot of them out there. Alison is certainly more knowledgeable on the subject than I, however.
David Anders has also started a resource section on the elinux.org wiki that lists a few packages worth exploring. It is a post-ALS creation, though, so it may take time before contributors manage to link in all the extant options, many of which are one-developer projects at this stage.
Nate
ALS: Automotive Grade Linux
Posted Oct 6, 2012 6:37 UTC (Sat) by alison (subscriber, #63752) [Link]
http://icculus.org/obdgpslogger/
I also recommend having a look at mp3car.com forums, scantool.net forums, #linuxice IRC on freenode and (until elinux.org page Nate mentions exists):
http://wiki.openivi.org/index.php?title=Main_Page
There were working Ubuntu and Debian packages for nobdy and libobd before the maintainer fell far behind, but I hear she hopes to catch up over Thanksgiving.
ALS: Automotive Grade Linux
Posted Oct 1, 2012 18:46 UTC (Mon) by miahfost (guest, #51602) [Link]
- GENIVI created a proof of concept using navit and standardized GENIVI APIs, so yes, navit should work "out of the box" on a GENIVI based IVI system.
- Navigation is one of those differentiating areas, and it is hard to do well (ask Apple.)
ALS: Automotive Grade Linux
Posted Sep 28, 2012 4:47 UTC (Fri) by liam (subscriber, #84133) [Link]
Each of the big automotive companies, and even some of the smaller ones like Mazda or Hyundai, seem to want their own systems. The results are, in my experience, universally terrible.
If they would at least offer an option for a standardized in-dash docking mechanism we could slap in a tablet and let it communicate with the rest of the system (but only control non-safety critical systems like IVI, climate control, or whatever) through a webview, or whatever Afloat/Genocide/whoever else decides upon.
Just give me my massive, bright, multi-touch friendly screen sitting in the dash which I can fondle at my leisure.
ALS: Automotive Grade Linux
Posted Oct 1, 2012 18:48 UTC (Mon) by miahfost (guest, #51602) [Link]