You are currently browsing the category archive for the 'Linux' category.
lien : http://www.embedded.com/columns/guest/204300438?_requestid=825265
traduction par translate.google : lien
Search for embedded Linux patents
(11/29/07, 03:21:00 PM EST)
In many cases, “free” isn’t really free.
As an electrical engineer with an automotive background, when I think of Linux, I think of servers, PCs, supercomputers, and so forth. Embedded applications don’t really come to mind when I consider Linux. However, Linux is used as an operating system for many phones, games, and other devices with embedded software.
Computer programs, often protected by copyright or trade secrets, can’t be directly patented unless they’re used for something tangible, such as signal processing or hardware control. For example, an operating system could be patented as a business method or a method to control computer hardware. Even though Linux is open source (free), certain companies could have patents that could be infringed by people using Linux in embedded applications.
Linux is generally considered free software, but is its use in embedded devices protected by U.S. patents? A patent consists of several parts, including the abstract, specification, and claims. The abstract is a concise summary of the specification while the specification is a complete description of the invention. The claims are where the majority of the legalese is found and are generally difficult for a nonlawyer to understand. Reviewing patent specifications and claims can give insight into the popularity and application of certain technologies throughout the years.
The claims are the most important part of a patent from a legal point of view because they define exactly what part or aspect of the invention is patented and, therefore, legally protected. From a technical point of view, the specification is often the most useful as it’s a complete technical description of the invention and usually has less of the legalese that’s found in the claims. If a feature is found in the claims, it’ll definitely be in the specification. However, a feature may be discussed in the specification but not in the claims.
Patent office databases
The United States Patent and Trademark Office (USPTO) makes a lot of patent information available online at www.uspto.gov/patft/index.html. You can actually look at patents dating back to 1790 (Abe Lincoln’s patent #6,469 for “A Device for Buoying Vessels Over Shoals,” on May 22, 1849, is in the online database!). Published patent applications can also be searched and viewed using the site. Patent applications are usually published on the site 18 months after they’re filed. Batches of applications are published every Tuesday.
Patents are assigned to certain technical classes based on the nature of the invention. Each class has multiple subclasses that can be used to further specify the type of invention. You can see the patent classes at www.uspto. gov/go/classification/selectnumwithtitle.htm. As an example, patents related to operating systems might be contained in class 713, Electrical computers and digital processing systems: support; or class 719, Electrical computers and digital processing systems: interprogram communication or interprocess communication.
You can search for patents by looking in the appropriate classes and subclasses if you can determine them. However, embedded Linux applications could be located in many different classes because they can be classified by the end system’s application.
Another way the databases can be searched is by keywords in the abstract, specification, or claims. The databases can also be searched by inventor, assignee, filing date, or several other parameters. You can combine the different search parameters logically using AND, OR, and the appropriate parentheses.
Finding embedded Linux
I searched the issued patent database, on 10/26/07, for titles, specifications, claims, or abstracts containing “linux” and “embedded” using the search logic ttl/(LINUX and embed$) OR abst/(LINUX and embed$) OR ACLM/(LINUX and embed$) OR spec/(LINUX and embed$) where $ represents a wildcard. This resulted in 1,445 hits. However, this included many patents discussing such things as embedded URLs and embedded images, which aren’t really of interest for our topic.
By eliminating the specification from the search and limiting it to the title, abstract, or claims, I reduced the chaff, leaving only patents strongly related to Linux and embedded systems. Again, I searched the issued patent database for titles, claims, or abstracts containing “linux” and “embedded” using the search logic ttl/(LINUX and embed$) OR abst/(LINUX and embed$) OR ACLM/(LINUX and embed$). This resulted in just five hits.
I searched the pending patent publication database for titles, specifications, claims, or abstracts containing “linux” and “embedded” using the search logic ttl/(LINUX and embed$) OR abst/(LINUX and embed$) OR ACLM/(LINUX and embed$) OR spec/(LINUX and embed$). This resulted in 6,289 hits. However, like the issued patents, most of these weren’t of interest. So, again I eliminated the specification from the search parameters to reduce the chaff.
I searched the pending patent publication database for titles, claims, or abstracts containing “linux” and “embedded” using the search logic ttl/(LINUX and embed$) OR abst/(LINUX and embed$) OR ACLM/(LINUX and embed$). This resulted in 56 hits.
Because patent application publications are left in the database even after the patent issues, you’ll find some repetition of inventions between the issued patent and patent application databases (although the application and the patent often differ substantially after the examiner gets through with them). After eliminating the replication and remaining nonrelevant patents, only around 29 patents/publications were left. Table 1 shows some examples of relevant U.S. patents and publications related to embedded Linux as of 10/26/07.
The patent documents located reveal that a variety of companies/investors are involved with embedded Linux. There isn’t one company that really dominates the list and several of them are foreign companies. So, if you work with embedded Linux, searching patents can provide you with a nice target list of companies.
Most of these patent applications were filed in the 2002 to 2005 timeframe, although two were filed in 2000. Figure 1 shows a graph of the number of documents per filing year. Applications from 2006 aren’t fully represented in the data due to the 18 month delay between filing and publication of the application. So the 2006 applications related to embedded Linux are likely much higher than represented by the data.
In summary, most of the patent documents related to embedded Linux located in this search were filed between 2002 and 2005. No one company dominates the list of assignees but, rather, several companies from across the world. The number of U.S. patent applications filed related to the subject has seen as generally upward trend over the last few years, indicating increased popularity. Finally, even though Linux is a free-software operating system, it would be wise to search the U.S. patent database before commercially using Linux in an embedded application. Of course, refer to a licensed patent attorney if there is any doubt.
Danny Graves is a freelance patent analyst, patent agent, engineer, college instructor, author, and inventor with two U.S patents. He was a finalist for the 2001 Charles C. Gates Award for Excellence. He has researched numerous inventions across a wide range of technologies. Graves can be reached at dannygraves@bellsouth.net.
lien : http://www.embedded.com/columns/guest/204801349?_requestid=825259
traduction par translate.google: lien
Embedded OS trends points to Linux…sometimes
(12/11/07, 03:16:00 PM EST)
While the use of Linux continues to sail along at a nice clip, the number of people kicking the tires is shrinking, for all the right reasons.
The Linux operating system (OS) has earned strong interest and adoption from those in the embedded software development community who are looking for cost-effective OS support for their latest embedded devices. In parallel, proprietary real-time OSs (RTOSs) offering robust arrays of services that are comparable to those in Linux have gained attention for safety-critical systems and large-scale telecommunications networks. In such applications, these complex RTOSs provide the capabilities that are needed, often including virtual memory, multiple independent levels of security (MILS), and volumes of middleware for security, communications protocols, and support for an array of development systems.
While Linux and complex RTOS products offer such attractive capabilities, they’re also correspondingly difficult to learn and use due to these robust arrays of services. Linux includes hundreds of system services, virtual memory, and tens of millions of lines of open-source code. High-end commercial RTOSs also include many features and lots of code, making them (and Linux) a challenge to master.
Linux’s complexity has created an industry dedicated to configuring and supporting it for use in embedded applications. These companies, most notably Wind River Systems and MontaVista, charge for their services, and their fees are well justified. Likewise, complex commercial RTOSs with hundreds of services, are generally expensive to license, often burdened with run-time royalties, and are relatively difficult to learn and use. For many high-end applications in defense and telecommunications, these complex OSs are necessary, and serve those needs well.
But what about the majority of applications where low-cost development and fast time-to-market are the primary goals and the system’s technical requirements are relatively modest? Many companies developing electronic devices staff such projects with a few engineers in the hopes of containing cost. In these cases, there may be no room in the budget for commercial Linux support or in-house Linux gurus, nor for expensive proprietary solutions. Achieving fast time-to-market and low-cost development demand a simpler approach. There’s little time to sort out configuration complexities, or to learn which of the many services are actually needed.
While Linux and complex RTOSs with similar features deliver abundant capabilities, they also occupy a fair bit of memory. If available memory is limited by physical footprint, cost, or power consumption constraints, or if low overhead and a rapid real-time response are needed, then it may be time to take an alternate approach. In such circumstances, a large Linux image or a complex RTOS might not cut it. What might be better is a smaller, simpler, more efficient solution, one that still meets the needs of the application, but doesn’t impose unnecessary complexity on top. For such needs, a small-footprint, low-overhead, simpler RTOS might very well be more suitable.
One of the newer trends in embedded software involves designing simpler solutions for applications that don’t need all the features. This concept applies to many embedded systems as they may not require virtual memory or hundreds of system services. Instead, many embedded real-time applications need just a few basic capabilities, such as priority-based preemptive scheduling, dynamic memory allocation and recovery, inter-task message passing, interrupt management, resource-locking semaphores, and timers.
Addressing these basic needs enables a simple RTOS to satisfy a large number of applications in consumer electronics, medical devices, industrial automation, test and measurement equipment, and wireless networking devices. Developers of these systems can minimize development time by choosing an RTOS that addresses their needs without excess complexity. Shortening development time pays additional dividends in lower development costs, faster time to market, and greater market share. For these applications, “less” actually is better, and delivers “more” for the developer.
The “less is more” adage is supported by findings in recent survey of embedded developers by Embedded Market Forecasters (EMF). This survey reveals that developers who recently used certain RTOSs tended to complete their projects on time or ahead of schedule more frequently than those who used other OS. This observation indicates that the RTOS used plays a role in the timely completion of embedded development projects.
By limiting the complexity of the RTOS, fewer services have to be learned and used, and this makes them more likely to be used correctly. Certainly, some applications require virtual memory and other complex features, but many don’t. It’s better to determine the needs of the application, and then use an RTOS that meets those needs without overkill. Several small, simple RTOSs are available commercially, and most offer full source code, royalty-free licensing, and commercial support. These offerings are generally simpler and easier to use than “full-featured” OSs with their large repertoire of services.
Another recent survey of embedded developers, this one by CMP, indicates that developers may already be taking steps away from complex systems. As the figure below indicates, the number of developers not considering Linux for their next project jumped from 34% in 2006 to 48% this year.
(Figure from “Annual study uncovers the embedded market,”Richard Nass, Embedded Systems Design, Sept. 2007.)
While one could conclude that Linux is losing its overall appeal, these results don’t necessarily indicate that. The results may imply that Linux is settling into the application areas for which it’s the best fit, and not being considered in other areas as much as it used to be. Developers initially caught up with the hype of a “free” OS may have come to realize that the complexity and downstream costs more than offsets the zero initial product cost, and therefore have turned to simpler approaches that ended up successful. Hence, they’re not considering Linux for future systems because they’ve found a better approach. Based on their experience, those developers will have a better knowledge of when and where Linux makes most sense and will be less willing to use Linux in the future unless it’s absolutely needed.
Recent comments on this survey data by leading editors who cover the embedded systems space support the conclusion that embedded developers are beginning to consider alternatives to Linux. For example, Rich Nass, editor-in-chief of Embedded Systems Design (ESD), in reflecting on the CMP survey data indicated that the industry has turned the corner on the embedded Linux hype in a report covering the embedded systems market. ESD Editorial board member Bill Gatliff seconded that motion in stating, “We’re finally turning the hype corner on Linux and realizing it’s not right for all applications.”
Michael Barr, a former ESD editor-in-chief, concurred with Nass and Gatliff, commenting, “There always seem to be some interesting new technologies, but they are not always adopted. But Linux actually succeeded, and a lot of people were using it in telecomm apps and so on, for stuff that looks like a PC. Clearly that trend is continuing, but obviously at a slower pace.”
Matt Assay of C|Net points to the unexpected cost of Linux as being a factor. “When I was involved in embedded Linux, the No. 1 drivers of adoption were cost and flexibility. …embedded developers were adopting Linux because it was perceived to be free. In fact, I can remember more than one occasion when a big OEM opted not to go with Lineo because we charged for commercial support, tried to go it alone, and came back to us to purchase support six to nine months later after they failed. Good service always costs money, whether you do that service yourself or pay someone else to do it. Either you pay in terms of your own time/resources or you pay in terms of someone else’s. There really is no free lunch.”
The “less is more” approach attracts developers that otherwise might opt to use Linux or a complex OS solution-not because Linux or large OSs aren’t good technology and ideal for many applications, but because they’re not the best choice for all applications, and developers are getting wise to this distinction. In many cases, developers realize that such large-scale solutions either can’t handle hard real-time, small footprint, low-cost requirements, or they’re overkill for those requirements and hinder rapid development. Projects with modest requirements are common, and those projects might be better suited to one of the many small RTOSs on the market.
For fast time to market, truly, less is more.
John A. Carbone is the vice-president of marketing at Express Logic Inc. He can be reached at jcarbone@expresslogic.com.
lien : http://www.embedded.com/columns/guest/207402542?_requestid=825240
en français par google.translate: lien
Si les champions de Linux embarqué disent que Linux embarqué est terrible, pourquoi tout le monde veut risquer leur produits ou leur entreprise? [...]
If embedded Linux champions are saying that embedded Linux is terrible, why would anyone want to risk their products or their company on it?
(05/07/08, 12:00:00 AM EDT)
Embedded Linux is the most hyped embedded operating system ever. It is promoted as inexpensive, high quality, high productivity, reliable, widely available, and well supported. It is none of these things, as two of its greatest proponents have recently pointed out. Wind River Systems and MontaVista Software, companies that each describe themselves as “the leader” in embedded Linux, have both initiated marketing campaigns touting the horrors of using embedded Linux.
In the January/February 2008 issue of Military Embedded Systems, Jim Ready, the founder and chief technology officer of MontaVista, says “a [develop-it-yourself] embedded Linux distribution [is] a significant investment (read ‘big bucks’) in time and money.” He estimates the three-year cost of a large scale embedded Linux deployment at $19,623,750. Here are some other quotes from the article:
“To keep abreast of the changes occurring on a daily basis a developer needs to monitor the email traffic of 11 different and unsynchronized open source projects… up to 5,000 messages a day with 1,000 of these being patches that need to be evaluated and possibly applied to the source base. Simply ignoring the traffic, figuring that the system in use seems to be working well enough, can lead to disastrous consequences later.
“A recent security patch that took all of 13 lines of code to implement against an embedded Linux system would have taken more than 800k lines of source patches to implement, if the previous trail of patches had been ignored. It’s a classic case of pay now or really pay later.
“If there ever were a situation where the ’software money pit’ could really take hold, it’s in owning 30 million lines of constantly changing source code. Even in the simplest case, the development costs are typically in the millions of dollars.”
Wind River delivers the same message in a recent full-page advertisement. It asks: “Choosing Linux as your next device operating system?” It answers: “CHAOS” in large crooked letters, followed by “fatal error,” “system crash,” “game over,” and “panic.”
Even the greatest critics of embedded Linux have never been so harsh. The experts say that embedded Linux is “CHAOS” and “a money pit.” With friends like these, who needs enemies?
One would expect Wind River and MontaVista to tout the advantages of their embedded Linux support, but why trash the product on which their business is based? If they are being unfair to embedded Linux, the Linux community will rise up to denounce them, destroying their embedded Linux support business.
It’s more likely that Wind River and MontaVista are telling it as they see it–for marketing purposes. Marketing usually puts forward a problem (bad breath, headaches) that many potential customers will relate to, and then promises a solution. Why would Wind River and MontaVista put forward the problem of embedded Linux nightmares in marketing materials unless they think many potential customers have experienced those nightmares and need a solution? Wind River and MontaVista are certainly in a position to know how hard it is to use embedded Linux, because they are using it, supporting it, and selling it. And since their business is trying to pick up the pieces for companies that have already failed with embedded Linux, they have heard plenty of horror stories.
Wind River and MontaVista each say that they can tame the embedded Linux monster and make it work for customers. But can they? Trying to fix embedded Linux for eight years, MontaVista is reported to have lost over $60,000,000, going through five rounds of venture capital, three rounds of layoffs, and three CEOs in the last two years. Since jumping on the Linux bandwagon, Wind River has gone from profitability to losses, recently announcing a layoff of 7% of their staff.
So why are Wind River and MontaVista bashing embedded Linux? Each year, Embedded System Design magazine carries out a survey of embedded systems developers. Over a two year period from 2005 to 2007, the percentage of developers using embedded Linux and the percentage planning to use embedded Linux have both declined. And even more important, the percentage not interested in embedded Linux has nearly doubled.
According to ESD’s analysis, most of those who are reasonable targets for embedded Linux (those with PC-like applications) have already adopted it. The rest have learned it is not appropriate and are moving on. See the article “Annual study uncovers the embedded market” (Richard Nass, www.embedded.com/design/opensource/201803499?pgno=2) for details of survey.
It seems clear what is happening: Wind River and MontaVista are trying to get the dwindling number of disenchanted embedded Linux users to pay them “big bucks” to escape the embedded Linux nightmare. They hope that if they can get enough customers signed up, they will finally get enough money to tame the beast.
But what happens if they cannot? There are indications that they may have exhausted the market. If Wind River fails to stem the tide, they will need to drop their support for embedded Linux to return to profitability. And if MontaVista doesn’t show some sign of stemming their losses soon, their investors will pull the plug. When Wind River and MontaVista abandon embedded Linux, their customers will have to live the embedded Linux nightmare that Wind River and MontaVista are telling them–all too clearly–that they will have.
This embedded Linux bashing from embedded Linux’s strongest proponents should give pause to those who are thinking through their embedded operating system strategy. If embedded Linux champions are saying that embedded Linux is terrible, why would anyone want to risk their products or their company on it?
Why would anyone use a product that its proponents say is awful? Would you buy a car from a salesman who admitted the car was a piece of junk just because he said he had a great service department? That’s what embedded Linux’s friends suggest that you do. With friends like these, who needs enemies?
Dan O’Dowd is the founder and chief executive officer of Green Hills Software. Prior to Green Hills Software, O’Dowd managed compiler and operating systems development at National Semiconductor, where he designed the architecture for the NS32000 32-bit microprocessor. O’Dowd holds a bachelor of science in engineering from the California Institute of Technology.
