There are many proponents of the use of open source operating systems in the development of embedded systems. In fact, open embedded systems are found in most consumer electronics, for example Android phones, dishwashers, flat screen TVs and motor cars. Likewise, proprietary operating systems attract their fair share of promoters.
Dataweek spoke to two academic developers, a company supplying embedded hardware, an embedded system developer and a proprietary operating system supplier about the advantages and disadvantages of open source operating systems.
Embedded hardware supplier
Centurion Microelectronics (CME) is a supplier of industrial PC components including chassis, motherboards, single-board computers, industrial keyboards, touch screens, panel PCs, data acquisition, protocol conversion and much more. The company can also assist with customisation of systems for applications that include kiosks, digital signage, in-vehicle systems, mobile computers and embedded systems such as control and instrumentation.
When asked about proprietary and open source operating systems and embedded systems, the company’s Henry Hugo said that the operating system must match the system requirement with regard to speed of response; that is, real-time operation is usually required by machine control systems and machines like robots that must react instantaneously to sensor input. Systems that are just reporting but not controlling do not need to be real-time.
“The operating system must fit within the chosen or available hardware system,” he elaborated. “The available memory and storage space often determines what operating system is chosen. The operating system and development languages used are often interdependent. Drivers for the various hardware components of the system need to be available or must be developed.
“Added to this, interfacing between an embedded system, or any system for that matter, and the user is a very important factor in designing a system and choosing the operating system. Finally, the software development tools for the chosen OS and hardware are very important,” Hugo continued.
“Having said this, the following can be said about proprietary operating systems such as Windows and open source operating systems such as Linux: cost is often a determining factor when choosing an operating system. A proprietary OS is usually a more expensive option. This is particularly the case where a real-time OS is required.
“Developers must consider if the OS chosen has the necessary drivers and interfaces needed. If drivers or other interfaces must be developed because they do not exist for an OS, this can add to the cost, time to market and future support costs of a system,” he added.
As Hugo explained, an open source OS can usually be more easily custom configured to be compact than a proprietary OS. This is important if the end system has (software) size and cost constraints. The choice of development language and tools, together with the choice of OS, has an effect on the size and complexity of the end system.
“A proprietary OS may have more development tools available to speed up the development of a system,” said Hugo. “Open source OS tools are sometimes not as well supported or maintained as proprietary tools. Cost also comes into this; proprietary tools being more expensive. With respect to programmers, programming languages and training, proprietary OS’s generally have more language support than open source.
“Graphics interfacing is becoming important in the development of all embedded systems as small and large touch screens become more commonly used. Drivers and tools to create these interfaces must be available from whatever OS is chosen. Again the factors of support and cost of these drivers and tools must be considered.
According to Hugo, there needs to be more education around the function and configuration of hardware, and its interaction with the OS: “We often find that system designers are configuring hardware and OS that are not necessarily suitable to the end use,” he clarified. “If a system is only measuring temperatures at one second intervals, do you need an i3 CPU? If a system needs the speed of an i7 CPU then don’t limit the RAM to 2 GB. If a system needs real-time operation, Windows is not necessarily the best OS.
“In addition, long-term support is the most critical cost of any system and is often not seriously considered. Will the OS be supported in five or 10 years? Will there be programmers around who support the language and OS that the system was developed in? Will there be hardware with the current interfaces available in five years if the current embedded system fails? We still have enquiries for motherboards that have ISA slots and can run DOS for embedded machines that are controlling huge production systems with millions of Rands of production capacity,” he pointed out.
“Embedded systems are becoming very much a part of everything we use today. Designers and developers need to carefully consider the long-term implications of their choices when configuring hardware, software and the operating system,” Hugo concluded.
Academia
Dr Simon Winberg is a lecturer at the University of Cape Town’s Department of Electrical Engineering and an academic member of the Radar and Remote Sensing Group and the Software Defined Radio Group. He was involved with FPGA-based signal processing for the Rhino platform, focusing on radio astronomy and radio/radar-related processing operations.
Winberg’s areas of expertise include signal processing; embedded systems; hardware description languages and FPGAs; software development; reconfigurable computing; high performance computing (HPC); software engineering; programming in C, C++, Matlab, VHDL, SQL, HTML, Python, Labview, PHP; education research; and electronics.
“In terms of embedded systems, there is a three-part relationship between the components, the development tools and the operating system. In turn, this can be divided into the physical and the knowledge dimensions,” said Winberg.
Within the physical dimension, components would be the embedded hardware (controlling) system; the tools are the logic analysers and other devices as well as software tools; and the choice of either open source or proprietary operating system.
“The knowledge aspect entails what you actually know about these three components, something which comes with experience,” Winberg explained. “At this stage one can then decide what the best options are for the application at hand in terms of maximised operability, functionality and cost effectiveness.
“It is important that there is complete compatibility between the three components and that one considers whether one can actually execute an open source operating system before committing to its use. Factors to consider include the actual engineering costs, which include both the time and effort involved in using the open source operating system,” he cautioned.
According to Winberg, the accrued benefits of an open source operating system are evident in its customisation abilities, the ability to connect it to various ports on a microprocessor, and the ability to test a system before making a firm commitment to it.
He cited a number of projects that have been successfully implemented at UCT using open source operating systems. “We were involved in a project that related to UAVs involving fusion sensor collision avoidance assistance that used an embedded processor running Linux to combine radar and vision sensing input. The objective was partly to use the vision feed to null ground clutter, which is a problem for low-altitude UAV surveillance applications. This UAV was an aeroplane as opposed to a quadcopter.
“On the educational front, we utilise embedded Linux as a practice block upon which students can develop systems. One project, entitled Vibrinet, entailed a system that would cause a 7-segment LED device to vibrate and emit an audible beep whenever a friend (programmed into the system remotely via USB) was in the vicinity,” he added.
The RHINO (Reconfigurable Hardware Interface for computatioN and radiO) project is another open source effort at UCT to provide a hardware platform and software toolchain for SDR (software defined radio). According to Winberg, it is easy to use, easy to learn and affordable. “Rhino follows the same fundamental computer architecture as the current ROACH (Reconfigurable Open Architecture Computing Hardware)-based CASPER hardware; namely a single FPGA element with memory, high-speed communication and I/O expansion slots, all controlled via a processor running the Borph operating system,” he explained.
The Rhino project was started independently of both the South Africa Square Kilometre Array (SKA SA) and the Centre for High Performance Computing (CHPC), as a self-funded open source project by Alan Langman. The goal was to kickstart research in SDR and develop the skills required by large government projects as well many local companies. SKA helped initially with the purchase of components for the first prototypes and then later established a research grant to continue funding the efforts.
“The collaboration with SKA was for the purpose of potentially reusing firmware developed on the one to run on the other, such as both using FMC cards for sampling,” said Winberg. “But the development environment is intentionally different. For Rhino we are attempting to build our own open source tool flow, but SKA is using the CASPER tools that combine Simulink and HDLcode, which are expensive proprietary tools that are admittedly very powerful.”
Alan Langman is a Research Associate at UCT. With a PhD in Electronics Engineering, his specialisation area is the development of advanced radar platforms for subsurface remote sensing. He has developed a number of systems for research, land mine detection and obstacle avoidance for direction drilling. Advanced radar platforms for subsurface radar, digital backends for radio astronomy, technical management, developing technical teams, research, open source hardware, electronic system development form part of his portfolio.
Langman was involved with development work on the SKA project for over five years, utilising Borph. He also started the Digital Backend group and established the South African link to CASPER collaboration and was the first chair of the international steering group for CASPER.
“Open source operating systems such as Linux, are ‘free’, not in the sense of ‘free beer’ but in terms of the freedom to adapt them to your application and to fix the code as bugs emerge,” Langman explained. “It does often require more time to learn and understand due to limited documentation or complex undocumented code; however once understood and mastered, it frees you from the limitations of proprietary code, providing one with brilliant tools that drive innovation.”
Langman worked with UCT student Brandon Hamilton and Sebastien Bordeauducq from the Milkymist and Migen projects. Bordeauducq was able to develop an impressive Python toolbox for building complex digital hardware which was used on Rhino to develop an arbitrary waveform wideband radar platform.
Borph is a component of the Rhino project and was developed by Hayden So Borph as part of his PhD at UC Berkeley. Hamilton then became interested in Borph and reconfigurable computing while completing his undergraduate thesis under Langman’s supervision at the SKA project, and did the initial port of Borph to ROACH for the SKA SA.
Borph is an operating system designed for FPGA-based reconfigurable computers, implemented as an extension of the Linux kernel. Reconfigurable hardware, such as FPGAs, are treated as computational resources within the operating system.
These resources are defined as hardware regions (HWRs), which can be implemented as an entire FPGA, or partially reconfigurable regions within a single FPGA. “Borph aims to provide increased usability for reconfigurable platforms, with a focus on simplifying hardware/software co-design,” said Winberg.
Embedded system developer
Keystone Electronic Solutions provides a range of electronic engineering research and development (R&D) solutions. John Eigelaar, a director at the company, explained that there are two types of open source operating systems: the smaller, lightweight ones, typically running 8-bit processes and characterised by their monolithic application-specific approach; and the application processors such as Linux.
“We evaluated a number of operating systems, most of which are ARM-based. These included freeRTOS (real-time operating system), Micrium’s MicroC/OS-II, eCOS and Microsoft’s .NET microFramework. freeRTOS is a fully functional and full featured RTOS, but with very limited low-level driver support; ports for add-on protocols and support libraries are also very sparse. MicroC/OS-II is not open source, the licensing costs were high and the administration involved with shipping the OS was heavy,” said Eigelaar.
“eCOS is a fairly comprehensive real-time operating system which is currently available under a modified GPL licence. It is highly modular and scalable, as well as easy to put together on a printed circuit board. It supports most 32-bit architectures and the fact that the OS is Posix compatible makes the reuse of other posix compliant code very simple.
“Although we have standardised on eCOS, a move which reduces our development time, we were very impressed with Microsoft’s .NET microFramework. The code loaded onto the processor is a mixture of proprietary binary code and open source glue; it is very powerful and the support is excellent. In addition, the framework is free with no licensing involved,” he added.
According to Eigelaar, at the time the company was considering its options on the application processor side, the two basic choices available were Windows CE, which proved to be resource hungry and expensive; and Linux, which he praised for developing applications and mimics on PCs.
“Linux made more sense to us in terms of licensing. However, having said that, anyone who is utilising open source operating systems needs to be aware of and comply with the GNU General Public Licence (GPL) restrictions and conditions,” he continued.
He pointed out that there are a number of licences applicable when using Linux:
GPL licence, a viral licence whereby the developer needs to make their source code available publicly as soon as it uses or links with any other GPL code or library.
LGPL or Lesser GPL, also known as the Library GPL, whereby one does not need to disclose one’s source when code is linked to LGPL binaries. The same does not apply when the LGPL library is modified in any way or included in source form as part of another body of source code.
Variations on the BSD licence; one can use, reuse and distribute the source without one’s work becoming public property but one needs to disclose that they are using the source.
eCOS. Under the guardianship of the Free Software Foundation, this makes exceptions for its own version of GPL and allows proprietary source links to the eCOS source.
Eigelaar said that Keystone now distributes a Guinnux Starter Kit, comprising an ARM9-based development board, 5 V/220 V a.c. external power supply and MicroSD card for use with the development board. Guinnux is a Linux-based operating system distribution that consists of the Guinnux kernel, root file system images, an application repository of pre-packaged binary applications and utilities, as well as the associated development tools and libraries to enable the development and porting of applications to the Guinnux environment.
“For us, the downsides of open source operating systems are the steep learning curve needed to acquire the requisite skills and the pitfalls that can occur if one is not aware of and compliant with licensing requirements. The advantages are that it provides us with design freedom and flexibility, and the software is free of charge,” he said.
Proprietary systems
For the sake of providing a balanced overview of open source operating systems for embedded systems, it would be unfair to exclude a discussion on the advantages of proprietary operating systems.
Mark Bh;hmer is the embedded computing field application engineer for Arrow Altech Distribution. The company is a distributor of a number of proprietary software operating systems for embedded solutions.
“People often use the licensing costs around proprietary operating systems as a reason not to utilise them,” proffered Böhmer. “A large percentage of the associated licensing cost is assigned to the payment of third party royalties. There is no such thing as a free operating system. For example when companies use the ’free’ Android operating system they often have no idea what or whose intellectual property Google used in creating the operating system, and whether Google paid the necessary licensing.
“This puts companies at huge risk for litigation for copyright infringement. The very reason that licensing costs exist is also the reason why a proprietary system should not be overlooked. As an example, Microsoft provides cover for the company that use its operating system against litigation.”
As he explained, these systems and surrounding development tools benefit from huge investments into their development, to the degree where the time needed to acquire familiarisation with the system is minimal, and the development of new solutions is simple.
“It is critical to consider the total cost of ownership rather than just the cost of owning licences,” Böhmer pointed out. “Several studies indicate that the comparative time to market is often significantly reduced when using proprietary operating systems, which equates to months or even years of reduced engineering man hours which make up a bulk of product TCOE.
“It could take months of development work to develop a prototype, and years to move the product to a production ready state when utilising open source operating systems. The project time is substantially decreased, often by as much as 60%, when using a proprietary operating system.”
He said that one arena where proprietary software such as Microsoft is riding high is the gaming industry. “Proprietary operating systems allowed game developers to use a greater choice of hardware platforms, and a greater selection of gaming engines which would drive their games. Major revisions of the company’s entire games offering were enabled in a mere 16 months, as opposed to an estimated 32 months using Linux.”
Böhmer admitted that there are some limitations to using proprietary operating systems. “In some cases proprietary systems can be slower than open source operating systems, depending on the product, the application and the design of the embedded system and the hardware utilised.
“There are also the skills set limitations that occur when a developer becomes too firmly entrenched in using a specific proprietary system. The solution here is not to concentrate on just one system but rather to match operating system software to the required application, especially when considering the ‘Internet of Things’ and intelligent systems.
“I believe that there is a niche for both proprietary and open source operating systems for use in embedded systems. Very low-level devices (8- and 16-bit platforms) for applications such as sensor networks, will significantly benefit from open source operating systems while higher-end systems such as engine control units, tablets and handheld devices could utilise the best features of both open source and proprietary software,” he concluded.
| Tel: | +27 11 543 5800 |
| Email: | [email protected] |
| www: | www.technews.co.za |
| Articles: | More information and articles about Technews Publishing |
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version