May 07, 2007
DATE 2007 Part 2 – Special Days, Frustrating Hours
Please note that contributed articles, blog entries, and comments posted on EDACafe.com are the views and opinion of the author and do not necessarily represent the views and opinions of the management and staff of Internet Business Systems and its subsidiary web-sites.
The morning sessions were quite informative and included presentations from Airbus and EADS offering respective reviews of best practices, evolution, and future trends in embedded systems for Aeronautics and Space. I realized there, to my amazement, that the use of SoCs is not really common practice yet in either of these industries, because a system-on-a-chip is not quite a proven’ technology. Where fail-safe, mission-critical applications rule the day, discrete components – processors, memory, etc. – are still the norm.
That may be changing, however, per the Thursday morning presentations at DATE. The Aerospace industry may soon decide to start relying on the highly complex, highly proven, off-the-shelf type components that are currently driving the mad, mad, mad world of every-day electronics into the hands of billions of consumers. The world of Aerospace may begin to acknowledge and utilize the products that everybody else knows and loves.
The use of Open Source software may be a bit longer in coming, however. At least that was my impression from the panel I moderated late Thursday afternoon, “Towards Total Open Source in Aeronautics and Space?”
The participants on my panel included:
Eric Bantegnie from Esterel Technologies,
Gerard Ladier from Airbus,
Erick Lansard from Thales Alenia Space,
Ralph Mueller from Eclipse Europe,
Franco Gasperoni from AdaCore, and
Alex Wilson from Wind River.
There was great potential for this panel, a discussion of the intriguingly orthogonal topics of Aerospace, Open Source, and EDA. Unfortunately, the conversation devolved during the session into something scattered, agitated, and unorganized. I hold myself responsible for poor orchestration of the event (and have outlined the problems below for those who are interested), but learned quite a bit nonetheless during the discussion. I would summarize my impressions this way.
Aeronautics and Space are industries populated by large organizations, and include systems that are both mission-critical and characterized by long shelf life. As it is turning out, some aircraft may be in service for upwards of 75 years. In Space, interplanetary explorers must function reliably for decades on end in order to fulfill their missions. Layer on top of these circumstances, the dynamics of Open Source and you have an interesting situation developing.
The problem – and one that I believe was a sub-context for the panel discussion at DATE – is that many people do not understand what “Open Source” software is all about. Some people see Open Source software as “free” software, where there is no revenue stream to support a developer community and consequently there’s no accountability. If this were the case, Open Source clearly wouldn’t work in mission-critical Aerospace.
In fact, however, there have been numerous, large, long-running Open Source projects (e.g., Linux, Apache, and Eclipse) that have addressed these concerns – albeit, not necessarily in the same way – and that’s why they have been successful.
Still, large organizations tend to distrust Open Source, because they don’t see an accountable organization behind the software. They perceive that if there’s a problem, there’s nobody to go to. They may also have the perception that there is this amorphous population of nights-and-weekend hobbyist who are contributing to the Open Source code base on a haphazard, ad-hoc basis. There have, in fact, been many Open Source projects that were run this way, but nobody knows about them because they’ve disappeared. The successful Open Source software that is long standing and well known does not work this way.
There are substantial corporate entities behind successful Open Source projects that essentially fund the development community by paying their employees to contribute code. In addition, users of these products have a choice of support models, ranging from providing their own support by participating in the projects, to outsourcing support from a range of vendors (e.g., Red Hat for Linux).
For instance, if a particular feature or capability is needed in an Open Source application, there is no actual vendor to go to request its inclusion in a future release. A user, therefore, has two choices – implement the feature themselves and take on the ongoing maintenance responsibilities, or find an external party that is willing to do it and fund that party going forward. For each of these options there are also two choices – implement the feature as your own modification, or contribute the feature to the code base making it available to anyone else who wants to use it.
This is a process that is not well established as yet, however, nor does it make people comfortable if they are involved in industries where traditional documentation, RFPs, and vendor selection is the norm. Clearly the use of “Open Source” software is a process that many people in the Aerospace industry (and the EDA industry?) may be unfamiliar with.
Some 30 years ago, there was no Open Source. Nobody had thought about it. But now this new model is emerging over time and threatening to replace the traditional, proprietary software model – if not in all areas, at least in some areas.
All the details of how it could, or should, work have not yet been worked out in a universal way, but clearly Eclipse is pushing the model, Linux is pushing, etc. Some may say, as a result, the old proprietary model is doomed. But how we get to the final, complete, Open Source state in the software world is not clear. And, in fact, is not in itself the point.
The point is to get adequate compensation to the contributors who add value through a mechanism that is efficient and competitive, and that protects the users from vendor lock-in and monopolistic practices. The legal, contractual, and business practice issues have to be sorted out, and they are being sorted out slowly.
How all of this applies to Aeronautics and Space is a complex discussion, and the panel participants at the Open Source Panel at DATE were just getting into the conversation when our 90 minutes was up. That there was disagreement between the panelists was clear, particularly with regards to the “open” or “not open” nature of the Esterel software, in comparison to Eclipse and Ada and the mixed-model of Wind River.
I would wish for a time in the future when all of the gentlemen on the panel could reconvene and start up where we left off. We were just getting to a point where the context of the conversation had been framed. Further conversation was needed to push the envelope of understanding into new and productive territory.
And, perhaps that is the highest form of praise for a conference. That more discussion is needed. That some questions were addressed, while many more questions were raised.
If DATE was about EDA, then the discussion of a body of proprietary, closed, closely-licensed software that may (or may not) retard growth of an industry is an important one.
If DATE was about a specific end-application such as Aerospace, then my take-away is that a mixed-used model of some Open Source software and some proprietary software is what is needed to drive the industry forward.
Okay, enough! Have I proved that this last hour of the last day at DATE was a muddled, confused, agitating conversation? Have I proved that this last hour of the last day at DATE was perhaps the most fascinating of all?
A Morality Tale for Panel Moderators
The panel I moderated on the Special Day for Aeronautics and Space Panel was a logistical disaster for these reasons:
1) There were 6 panelists, far too many for fruitful dialog.
2) Panelists were restricted to 5 slides max, but one guy showed up with 13 – a poor choice, particularly as many were marketing slides for his company.
3) Slides were due to me by email no later than 10 days prior to DATE. Not all could oblige, but Mr. 13 delivered his slides to me on a data stick just 2 hours prior to the panel.
4) Due to DATE regulations, I had to deliver all 6 sets of slides to the Audio-Visual Room (which was far away) 90 minutes prior to the session. I was required to linger there to do Q&A on presentation functionality, time I was not able to spend attending sessions. It was only then I saw the 13 slides, whereby I should have eliminated 8.
You can find the full EDACafe event calendar here.
To read more news, click here.
-- Peggy Aycinena, EDACafe.com Contributing Editor.
Be the first to review this article