and microprocessors, the possibilities for embedded product designs are exploding. Leveraging a myriad of connectivity interfaces and integrating advanced graphical user interfaces and multimedia formats requires the availability of supporting software stacks from the underlying operating system. And, more than ever before, embedded software teams are turning to open source software and embedded Linux as the platform on which to base these systems in the "Internet of Things." But while open source has proved itself incredibly technology enabling, it can also make the workflow excessively unwieldy. The good news is that solutions and best practices exist to help development teams improve their software development workflow when open source
is an increasingly large part of the mix.

In the early days of embedded Linux development (circa Y2K), a significant part of the effort was to port the open source code to run on the hardware platform being targeted. Unless engineers were running code on an Intel x86 board, it was not a trivial effort to develop the Board Support Package (BSP) and cross-compile the open source middleware to run on the hardware. In the years since, an increasing number of hardware companies have discovered that providing free Linux BSPs is necessary to ensuring the wide adoption of their hardware into embedded applications. Whereas in the early days it might have taken weeks or months to get to a Linux shell prompt over a console port, these days it should only take a few hours.

With a wide variety of proven open source software now readily available to run on the target hardware, the platform engineer’s typical day-to-day tasks instead focus on configuration, customization, and integration of existing open source software, rather than design and development of software from scratch. Given this transition, let’s review the following four major product life-cycle workflow challenges to consider when deciding whether to build a product based on open source software:

1. Creating a customized Software Development Kit (SDK) for the application team;
2. Keeping track of open source software updates;
3. Rebuilding a platform from source code; and
4. Managing open source software obligations associated with a variety of licenses.

Creating a customized SDK

As engineers increasingly view embedded Linux as a common software platform that can be reused across many of their company’s products, creating a customized SDK becomes more important than creating a BSP. Application developers love Android and iOS because Google and Apple do a great job of building and maintaining custom, yet powerful and easy-to-use SDKs for their phone and tablet platforms. Who’s building that foundation for development engineers building apps for your hardware platform? A company is ahead of the curve if it has an engineer who is officially responsible for creating and maintaining a custom SDK for the application development teams. If the company has someone responsible for this ongoing task, managers should be able to answer the following questions:

• How well is the engineer doing their job?
• How much time are they spending doing it?
• How do they distribute the SDK to other team members?
• If this person (or a key person on the platform team) left the company, could someone step in and take over this role effectively?

Creating a customized SDK basically comes down to selecting the set of libraries and APIs that application developers should use, and then ensuring that they are built into the application development toolchain in a version-controlled way. If the application will take advantage of dynamic linking, then this also means ensuring consistent versions are built for the developers’ desktops as well as into the runtime target images. Delivering the SDK in an easily installable format helps to ensure consistency across all application developers.

Keeping track of open source updates

Who on the team is responsible for keeping track of updates made to the open source software running inside company product? How do they do this, and how often? What kind of updates are they looking for? Do security patches and bug fixes get the same level of attention as new feature releases? How do they share those updates consistently with the rest of the team?

We work with one customer who tackles this particular issue by having three engineers work through lunch one day each week. In an effort to ensure they are aware of all recent updates to the open source software packages they are using in their company’s products, the three engineers project a laptop display onto a screen in a conference room, and surf various websites, changelogs, GIT trees, mailing list archives, and download sites. While this isn’t necessarily the most effective methodology, it does illustrate a proactive effort to stay current – and also illustrates the engineering time investment required to do so.

Automation can be helpful in this area. Subscribing to websites such as Timesys LinuxLink service (linuxlink.timesys.com), CERT mailing lists (forms.us-cert.gov/maillists), or Freecode (formerly freshmeat.org), (see Figure 1), can put some structure around this effort and save time by streaming relevant, filtered open source updates directly into a Web browser or email inbox.

Rebuilding a platform from source code

Ever try to rebuild a desktop distribution from RPM or Debian sources? Good luck. While the distribution folks do provide source code (it’s open source, after all), rebuilding from sources is definitely not a use case that they typically support. In most cases, after rebuilding from source packages, the resulting system wouldn’t be considered the same distribution and therefore is unlikely to be supported by the vendor.

While this might be acceptable for enterprise or desktop Linux environments, it’s not acceptable for embedded product companies. Typical embedded products are in the field for years, and they often need to be maintained and updated after shipping. It’s critical to keep a detailed manifest of all of the software included in every shipping build of an embedded product, as well as the tools and scripts that were used to build it. A number of modern Linux build engines provide this capability today, so make sure to select one that does.

Managing open source software obligations

As with most typical embedded products built upon an open source platform, it’s likely that the development team will have to keep track of the obligations incurred across many different open source licenses, not just a single license. As one example, we provide “small footprint starting points,” which are prebuilt embedded Linux images typically only a few megabytes in size and which simplify getting up and running quickly and easily with embedded Linux. As shown in Figure 2, a small footprint starting point might only include seven open source packages, but those seven packages actually fall under four different open source licenses.

As another example, consider what might be viewed as a relatively straightforward wireless digital picture frame offered by Sony (www.docs.sony.com/release/VGFCP1_qs.pdf). As shown in Figure 3, this product is based upon 20 different open source packages (www.sony.net/Products/Linux/VAIO/VGF-CP1.html), again spanning a variety of different open source licenses.

The use of each type of open source license in an embedded product design imposes a unique set of obligations on the development team that is incorporating this software into their products. Because of this, some companies maintain a list of open source licenses approved for use by their developers. Other companies go further, explicitly listing which specific version of each open source package has been approved for possible incorporation into the company’s products.

Ensuring that the development team is aware of – and in compliance with – the obligations associated with each of these open source licenses takes time and effort. Tools that can help to identify and track the underlying licenses that apply and enable license obligations to be met can prove quite valuable when trying to hit aggressive product development milestones.

Consider workflow from the start

The use of open source brings a new set of workflow challenges to the overall embedded product development life cycle. By considering these challenges at the beginning of new product development, by designating appropriate engineers to be responsible for the various issues, and by outfitting engineers with the proper tools, managers can ensure a more successful project by minimizing unexpected impact to the schedule.

Al Feczko is VP of Sales and Field Engineering at Timesys. Prior to joining Timesys, he held a variety of increasingly responsible roles in project engineering and management of embedded real-time control systems in the process automation/control and defense industries. He received his MS in Computer Science from Johns Hopkins University and his BS in Electrical Engineering from the University of Notre Dame.

Timesys [email protected] www.timesys.com

Follow: Twitter LinkedIn YouTube