Using Click Boards to Access a Free-Topology Network


Linux is the default environment for most software developers and is a popular choice for many embedded solutions. But one of Linux’s greatest strengths, and to some extent its biggest challenge, is that it comes in so many flavors and varieties—each suited to a particular use case.

While most acknowledge the advantages of the Red Hat, SUSE and Ubuntu distributions for general-purpose enterprise use cases, they are generally not suitable for embedded solutions. Compared to general computing, embedded systems have tight constraints, ranging from higher reliability and security requirements to tighter resource availability and the need for engineering support that often spans up to 10 years or more.

Everything starts with the Linux kernel that is available from kernel.org. To build a full operating system for application development and deployment, additional packages are required. Knowing what you are going to build determines what packages are required for your distribution. There is no one-size-fits-all solution, especially for embedded systems. A Linux-based project can be classified into three major categories.

Enterprise Linux 

The general-purpose server and desktop Linux distributions from Red Hat, Ubuntu and others are intended for well-resourced, multi-purpose and often multi-user solutions. As such, they are typically configured to support a wide range of devices with a one-size-fits-most mentality. Although the distributions are supported with available source code, supported customizations are usually limited to package installation and configuration files. This results in a robust user experience, “good enough” reliability for general-purpose use, and an inexpensive support model with a three- to five-year horizon.

Roll-Your-Own or Customized Linux 

The roll-your-own approach involves forking and stripping down a community-based distribution. The thinking behind this model is that the developers can use freely available open source code and then rely upon the existing community for support. However, the reality is that the community knows nothing about the actual fork that has been created and is thus unable to provide significant long-term support. Instead, dedicated engineers who understand this unique Linux-based OS are needed to maintain and support it. That’s not a big burden in the early years of the product life cycle, but as time goes on, this burden grows significantly, and since everything is custom built, there is little benefit from economies of scale to help support the project.

Commercially Supported Embedded Linux 

The third major category of Linux is a commercially supported embedded OS. The major advantages of this approach are very similar to those of enterprise Linux, but the solution is built with embedded use cases in mind. Instead of creating a massive one-size-fits-most distribution, the approach favored by most commercially supported embedded Linux vendors is to create a compact core able to support low-resource environments, greater security requirements, high performance and reliability needs, and a build system that requires only local support for extensions. While it is true that the greatest savings from commercially supported Linux accrue from more efficient support and maintenance over the long haul, it also offers many opportunities to customize the platform, speed up the development process and get products to market faster.

Cloud-native architectures and containers are widely deployed in enterprise IT environments but have been largely missing in action for embedded systems. However, the benefits of containers are equally desirable for embedded systems: 

  • Code reusability
  • Efficient maintenance 
  • Platform independence 
  • Optimized resource utilization 
  • Long-Term savings
  • Support and maintenance

In the long run, commercial offerings that provide a proven embedded Linux with support and maintenance are generally significantly less expensive than maintaining a roll-your-own Linux solution in-house. Linux is large and complicated, and it requires significant effort by engineers to provide support, patches and security vulnerability management over time. While it is difficult to make broad generalizations about the cost of creating and maintaining your own embedded Linux, that cost is always considerable and often underestimated by organizations new to the field.

The primary variables in the long-term cost of maintaining your system are: 

  • The type of embedded device 
  • The lifespan of your devices 
  • Security requirements 
  • Virtualization 
  • Application footprint 
  • Network connectivity 
  • High availability or fault tolerance requirements 
  • Global or purely local deployments 
  • Free open source software or open source policy requirements 
  • If you plan to update devices in the field 
  • Better and cheaper security 

With ever-increasing numbers of interconnected intelligent edge devices and systems, Linux software vulnerabilities have become more widespread than ever. Taking responsibility for identifying vulnerabilities and making the necessary updates to mitigate threats is often beyond the capacity of device manufacturers trying to maintain in-house embedded Linux solutions 

Commercial Linux vendors provide regular product updates and maintenance and security patches. Due to economies of scale, vendors can devote the necessary resources to stay on top of Linux kernel and security updates with regular patch schedules and convenient delivery methods. But that level of expertise can be difficult to justify for most embedded device manufacturers.

There are, however, more than labor and technological costs to consider with embedded Linux. It is also important to understand the legal implications of using Linux in embedded systems and the risks associated with open source licensing, intellectual property and export compliance. 

Creating an embedded device with a Linux runtime system as part of its software is equivalent to distribution under many of the open source licenses used in Linux, including the GNU Public License (GPL). There are on the order of 20 million lines of code for Linux and associated open source tools—a massive code base with a multitude of licenses for organizations to trip over if they are not careful.

With redistribution comes the responsibility to make sure your company is complying with the license requirements, such as providing free access to the source code for the open source portions of your product, including any tools that might ship with the product. 

Preparing products for international export adds another layer of compliance complexity to the documentation of open source software. Along with requirements for license compliance, export compliance largely centers on the disclosure of cryptography software, which presents security concerns in many countries. This is another reason why software suppliers, application developers and device manufacturers need to have formal processes in place for tracking open-source software.

Conclusion

Commercial embedded Linux offers a clear return on investment versus roll-your-own, in-house developed, and maintained Linux. Not only is the total cost of ownership lower, but the technical, business, and legal risks of commercial embedded Linux are much lower. The ability of the commercial embedded Linux vendor to supply training, services, maintenance, security updates and support helps boost productivity. It also reduces the overhead of maintaining your own embedded Linux OS. 

Success in a competitive market means concentrating on what you do best—building great products. That means avoiding the risk and expense of developing platforms that add nothing to your feature set or your bottom line.

Glenn Seiler is vice president of Linux Solutions at Wind River Systems.



Source link