There are many sources of both existing hardware and software that can be incorporated into new designs available from the open source community. Commercially viable open-source artifacts range from operating systems software such as Linux to physical hardware devices such as BeagleBoard. While basic building blocks of this sort can generally be used without charge, they are still subject to the terms under which the original creator released the design, whether that be the GNU Public License, Apache, or similar.

The main disadvantage in extensibility is that the traditional paradigm is to build one board support package (BSP) for the underlying hardware platform and then build all applications on top of the tested software platform that has abstracted the hardware from the application developer. If the underlying hardware eventually needs to change in the field, then in most instances, housings need to be opened, circuit boards replaced, and a new BSP must be built, tested, and installed.

The first step to overcome this disadvantage is to tightly define a set of lowest-level hardware interfaces that can be exposed through detailed electrical and mechanical documentation and supported at the lowest layers by locked-down driver code that becomes part of a published BSP. This needs to be planned for and accommodated in a product's industrial design. In most cases, this implies more than simply selecting a ubiquitous USB connector and assuming extensibility has been accounted for. USB can pose practical environmental issues in many markets, such as lack of suitability to high-vibration usage for an example. There is also a potential negative impact to the aesthetics of the product when a previously unknown USB device is attached as a new protrusion from the core device.

The approach of defining a common electrical and mechanical expansion interface has been used successfully in the past by the personal computer industry. The earliest models of PC machines shared ISA bus commonality between IBM's offerings and the many clones that followed. Unfortunately, current PC expansion slot strategies do not translate well into most embedded applications for a variety of physical reasons, and embedded designs lack the commonality of a PC BIOS to make disparate hardware look relatively uniform to a software developer. Accordingly, deployment of software support for field-added hardware can be more difficult for embedded products.

The PC model for deploying driver software is also still generally better than what is industry standard in embedded products. Modern PC operating systems including Microsoft-based and various Linux distributions automatically read device information as new hardware enumerates and retrieve the associated software drivers from a central repository automatically. To an end user, this is usually a very satisfying experience that needs to be recreated if field extensible embedded devices are to be successful.

The combination of easy to develop hardware coupled with software support that is easy to deploy with minimal impact to a field installer has been lacking from the embedded space on top of which most end products are actually developed. With a well-thought-out design approach that considers both platform independence of hardware expansion options as well as a centralized mechanism to deploy software, it is possible to replicate the PC approach in the embedded space within a family of products.

Although this approach to creating customizable devices from standardized platforms can be applied to many devices that need field configurability, it is particularly important in devices centered on connectivity for the Internet of Things (IoT) space. When considering a generic monitoring and control application, it is easy to design a communications gateway that implements a few standard interfaces, but it is far more difficult to be able to supply one that communicates with every sort of sensor and actuator in existence. The standard approach has been to pick a market and utilize the interfaces that are most common within that market. With field extensible platforms, the OEM no longer has to pick a particular market to pursue. If additional sensors or actuators need to be supported, then a new expansion card can be created to augment the original system and any new enabling software can be quickly deployed – the underlying physical interfaces are already natively supported at the lowest level with the API for the low-level drivers having already been made available freely.

Figure 1 shows an open IoT gateway product that is extensible only through GPIO, USB, or other interfaces that are fixed at the time of manufacture. As a traditional embedded device, it has a customized Linux BSP in order to make the most of the flexibility offered by the hardware and does not have significant post-release expansion capability. USB offers a route for adding features, but, as discussed previously, imposes limitations for practical field deployment.

Taking a new approach for a second-generation product, expansion ports have been created so that in addition to a traditional USB port that could be used in those instances where it is mechanically practical, there are also many other interfaces available to be exposed on expansion cards including USB itself, UART, SDIO, I2C, Wi-Fi, and others. This helps to ensure that the gateway architecture will enjoy a reasonable degree of longevity in the platform design by being able to accept new expansion port cards as they become available. As an open strategy, generally the OEM will want to document and publish the definition of the accessory port as well as providing the interface software support freely so that external sources both including end-customers and also other OEMs can develop additional hardware that the original hardware vendor had not thought of at product inception.

The next step is to identify reasonable ways to leverage this standardized hardware interface while providing a level of abstraction that allows other software developers to create applications without having to develop low-level drivers or build a new BSP from the ground up.

For a less computationally intensive device, ARM has a great answer with their mbed approach, which has been created to support their Cortex-M series of devices. The SDK is provided to the community by ARM under the Apache 2.0 open source license and feels very familiar to those who have worked with OS and non-OS embedded software development in the past. With mbed, software support for hardware can be placed in a central repository for any potential user to retrieve and build with their application. ARM themselves provide a level of platform independence at the processor I/O level through mbed, so it is possible to migrate code from one supported mbed device to another, even when the devices come from different microprocessor vendors. User-created software with the right platform support can then be built easily with ARM's tools, or with other third party development environments that are available for sale commercially. ARM's native deployment mechanism for deploying mbed code is as easy as drag-and-drop over a USB interface but the OEM may choose to extend deployment in a way more suitable to their own need if the devices tend to be deployed remotely and get field upgrades.

Since computationally intensive applications may not run well on a Cortex-M processor, an alternate approach may also need to be considered. Linux is one obvious choice as most providers of higher-end embedded processors tend to release an initial BSP for their own development kits into the community and often alongside open source hardware made available at initial release. The challenge in this approach is in recognizing that either an embedded Linux savvy software engineer will be needed for any customizations or an abstraction layer will need to be built. A hybrid model is to support both enablement of the more limited set of embedded Linux developers who are comfortable with building a full platform on their Linux development system as well as engineers who operate a level above that in Java, Python, Perl or other languages.

Figure 2 shows a MultiTech gateway that is one of a family available in late 2014 that will have openly documented hardware expansion slots. The expansion interface is common to multiple gateway products, and all supporting low-level driver code will be open and provided for both mbed and Linux. This allows both OEM and third parties to create new expansion boards that are easy to bring up and deploy into a much wider array of applications.

The expansion cards shown in Figure 2 are defined with a mechanism for personality so that the platform knows what driver resources are required and if any additional software needs to be retrieved from a cloud-based repository. The same cards work in any platform within the product line, allowing the end developer to select what level of processing capability is most appropriate to the individual application. In both cases, a general embedded software engineer would feel comfortable developing for these as the model follows the traditional PC paradigm of expandable standard hardware interfaces with software that exists on the main device natively or is download automatically from a central repository. The key advantage is that this approach creates platforms that are easy to understand by a wide range of software engineers and are based in open source artifacts that already have widespread community support. This results in products that can be rapidly customized both before and after initial field deployment in a vastly reduced amount of time. Although the examples provided center on IoT applications, the general approach maps well to any application where field configurability and support of a wide variety of known and unknown features needs to be considered.

Scott Wilken is Chief Technology Officer at MultiTech Systems.

MultiTech Systems www.multitech.com @MultiTechSys linkedin.com/company/ multi-tech-systems