Software is key differentiator for IoT dev kits

September 11, 2015 OpenSystems Media

Off-the-shelf development kits have become a keystone for many Internet of Things (IoT) developers, as their integrated hardware, software, and connectivity serve as the platform for engineers looking to design connected products quickly and inexpensively. However, though these kits are intended to provide a head start that allows designers to focus on value-added features, considering the long-term consequences of open source software, software licensing, and product differentiation when selecting a development kit is critical for successful IoT products, with implications that span from initial development through product launch, market adoption, and life cycle maintenance.

The Internet of Things (IoT) market offers unprecedented opportunity. The numbers alone are staggering. Analysts at Gartner Inc. estimate that 4.9 billion connected devices will be in use by the end of 2015, up 30 percent from 2014. Five years from now, they expect that number to increase to 25 billion. By then, Gartner analysts expect 10 billion connected devices (excluding PCs, smartphones, and tablets) will ship each year into a market that researchers at IDC forecast to be worth over $7 trillion.

However, many of those devices will be based on previously unconnected product designs (home appliances, building automation equipment, etc.). This will present a challenge for the engineering teams designing them as connected devices, as they’ll be utilizing a variety of technologies (wired and wireless connectivity, security, cloud, etc.) that will increase the overall complexity of the design. What’s more, many of the embedded developers building IoT devices don’t have experience with these technologies. Adding the necessary expertise via additions to the team’s headcount or spending the time necessary to train existing engineering resources is not an option available to most design teams. And yet these new products must be developed quickly and cost effectively if they are to be successful in the market.

To shorten time to market, embedded hardware vendors that supply microcontrollers, sensors, analog acquisition, and low-power wireless solutions have created new development kits for their customers. These kits usually bundle the target hardware along with software (RTOS, stacks, and middleware), often sourced from multiple vendors. These kits have become instrumental tools to aid in the development of embedded solutions (Figure 1).

Figure 1: Development kits with ample hardware support for connectivity and user interfaces to enable the use and development of a complete software bundle bring significant value as a tool for embedded design work. (Source: Renesas Electronics America Inc.)
(Click graphic to zoom)



Three software setbacks of the traditional dev kit

How essential are development kits and design examples to the electronics design and production process? According to a recent worldwide survey of electrical engineers by element14 Pty Ltd, four out of five respondents believe that development kits have become a crucial tool to take designs to the end product stage. Of those, most use all or part of their kits in their final production design. Moreover, three out of four survey respondents believe that kits play a critical role in driving innovation. Yet, the traditional development kit model is not a good fit for the IoT market for several reasons.

First, the software bundled with most development kits is usually packaged as a free or low-cost extra. And while this may save cost initially, in the long run it can actually cost more in terms of lost design time and reduced reliability. Bundled software included in a development kit is likely to have gone through minimal compatibility testing and is often not eligible for access to ongoing upgrades or bug fixes. This could lead to trouble during development if bugs or conflicts occur. Furthermore, support capabilities can vary greatly between different software vendors, and inconsistencies in quality of products and documentation can cause unacceptable delays in product development. In the event of compatibility issues between various software components and/or hardware, oftentimes it is unclear who is responsible for fixing the bugs – vendor A or vendor B – and precious time is wasted trying to determine who has the responsibility of fixing the problem. Additionally, many bugs don’t appear until a new product is in the field, oftentimes months or years after its deployment. If that happens, will the vendor responsible still be in business and capable of providing a fix? What if a bug affects multiple customers and the vendor’s support resources become overwhelmed?

Second is the issue of product differentiation. Many embedded software platforms offer a variety of features (connectivity, user interface, graphics, etc.) and support various software protocol stacks and middleware. These features are available to every other design team using the platform, so by themselves they don’t provide any unique value add that a design team can leverage to differentiate their product from the competition.

Licensing is a third consideration. Software bundled with a development kit is typically licensing free when building a prototype, but when that prototype goes into production, software licensing fees become necessary and often add up to a substantial amount of investment both upfront and over the product lifetime. Some developers may argue that the answer to this problem is to avoid licensing fees altogether and explore open source software alternatives. This is a solution, but open source software often has hidden costs. For example, bugs or compatibility issues with open source software still require fixes, and most vendors won’t be able to wait for the open source community to solve the problem. They’ll either need to purchase support from a third party or develop a fix on their own. In the long run, paying up front for a software license (and access to technical support from an established vendor) may be the less costly alternative.

The path to productization

Looking at the design challenges described above, it becomes clear that much of the work around software and hardware configuration, debugging, and testing will need to be done up front by vendors. This will allow IoT product designers to focus less time on simply getting a device to function (to send that first Ethernet packet or display that first animated widget on a color display) and more time on end-product differentiation, which is ultimately what will make their product successful in the market. The way to do this is through the use of development kits that fully integrate the IoT platform’s software and hardware, have been fully tested and qualified to written specifications for operation and compatibility, provide ongoing access to software updates and bug fixes, and offer detailed but easy-to-navigate technical documentation (Figure 2). Perhaps most importantly, the kit’s vendor should serve as the sole point of contact for customers when it comes to technical support, software updates, and software licenses.

Figure 2: Leveraging kits and a platform-based approach like Renesas Synergy allows designers to focus their resources on their own end-product differentiators with confidence that the underlying essential system code is solid. (Source: Renesas Electronics America Inc.)
(Click graphic to zoom)



Mark Rootz is Marketing Director, IoT Business Unit at Renesas Electronics.

Mark Rootz, Renesas Electronics Corporation
Previous Article
Flexible framework architecture and IoT

Traditional networked embedded systems architectures are being challenged as they begin to be used within I...

Next Article
Open source hardware and software key to unlocking IoT development

It's so simple, really. What we all want is to build something that solves a problem in the best way we can...


Stay updated on Developer Tools & Operating Systems with the Dev Tools and OS edition of our Embedded Daily newsletter

Subscribed! Look for 1st copy soon.
Error - something went wrong!