Ten strategies to minimize cross-platform design complexity in an IoT world
The potential growth in applications related to the Internet of Things (IoT) is providing new opportunities for vendors and their design teams, but it is also adding to their already long list of hardware and software engineering challenges. The hardware and software are intimately related, and together create a platform that will require strategies for minimizing cross-platform design complexity. Some of these strategies include:
1. Limiting sensor and transducer I/O
Decide up-front if your I/O needs will have a fixed or limited number and type, or if they need to be expandable in count and flexible in type. The decision affects your options in MCU and peripheral selection. It’s especially critical when the I/O consists of more than just simple, low-voltage digital points, but instead may include temperature sensors, motors, and even the communications lines, with both serial and parallel formats.
2. Using an external, certified RF module
A module which is separate from the core application processor makes the most sense in many cases. While a single-chip, highly integrated solution may seem attractive in terms of board space, power, and cost, it means that changes or extensions in wireless protocol, required range, and even regulatory requirements will mandate a major redesign, or perhaps a new MCU and RF link-related firmware. Even if the coding part is straightforward (unlikely), the MCU may be inadequate for the new requirements and need to be upgraded as well, which adds to development time and risk.
3. Trading power for performance
Understand clearly where your proposed MCU selection fits in the power versus performance matrix. As you move up along the curve of required performance, there will be points where you cross thresholds and have to step up to larger MCUs that consume more power. There’s a complementary issue as well: as you slide down the curve and need fewer resources, you will be able to consider smaller, cheaper MCUs which needs less power. Just be sure the specific MCU you choose supports a sophisticated range of speed versus functionality and power modes, so you can optimize operational sequences for lowest overall energy consumption, yet handle the required, power-intensive operational spurts.
4. Simplify your security
Some processors have dedicated, hardware embedded features that will make some aspects of security automatic and independent of any application software or even the chosen RTOS; these may accelerate and simplify your security challenges. Even better, if that same embedded security function is available on all MCUs on your shortlist, this significant part of the IoT challenge can be taken off the “to do” list regardless of the specific processor selected.
5. Standardize your system
Standardizing on a low-power 8/16-bit MCU and then implementing different memory sizes (on-chip or external) as requirements move both up and down the size/performance scale; OR go with a single, larger 32-bit MCU and accept that there will be unused capacity in lower-end applications, but with the benefit of code and driver consistency, plus simplified BOM and test procedures.
6. Operating system selection
In some cases, a simple, low-cost single-thread OS will be sufficient, but for many projects, you’ll need a real-time OS (RTOS). For either choice, you need to assess the OS scalability and availability of small-, medium-, and large-footprint versions. Be realistic about the size of that smallest version, and its corresponding capabilities – you don’t want to “hit a wall” on OS capability as your project is at the 80% completion point.
7. Upgrading hardware versus software
At key points along the curve of software resources required to complete added tasks (development time, processor resources), you will have to decide between adding a peripheral IC to offload the fully committed MCU, or choosing a faster MCU. Be prepared for this decision point, by analyzing when a more-powerful MCU lets you pull a hardware task back into software, thus saving component cost, footprint, and power (in principle) but with a likely penalty of longer development and debug time.
8. Choosting your connectivity protocol carefully
Look at a “lighter” IoT-optimized protocol rather than the client/server HTTP-based Internet browser model. This will reduce stack and processing requirements by a factor of two or more, yet allow you to handle a variety of IoT devices and their peripherals. At the same time, consider what will happen when the connectivity requirements (protocol, speed, integrity) increase, as the market becomes more demanding.
9. Doing the test plan early in the design stage
It is both essential and complex, especially where wireless is part of the design. How you informally and then formally verify that the end product meets the market, technical, industry standards, and regulatory requirements affects your “fix” cycle and thus time to market. If you have to change either prototype test procedures or production test set-up as you scale your product up and add features to handle different applications, that’s a lot more work, uncertainty, and risk. Using pre-certified hardware and software modules that you license that will assure conformance and compliance for many of the aspects of the final design, but not all. Be very cognizant of any high-level regulatory guidelines on design and verification (such as for reliability of medical products) that impact your software – and to which of your products they apply, if not all.
10. Again, security, security, security
Adopt software techniques and tactics that can scale across products and match the application requirements and IoT user interface (if any), such as firewalls, authentication, and even passwords. Identify the security resources you need from the hierarchical list – secure boot, authentication, secure communication, firewall, tamper detection, event reporting, remote command audit and policy management – and ensure that each one’s actual implementation is appropriate and feasible, given the software resources you have. Assess if the “burden” of adding security to various products push you to a larger or faster MCU than otherwise, and have a plan verify the robustness of the security steps you implement.
Conclusion
As new or additional products are developed, the “sweet spot” will undoubtedly move to meet the changing requirements while avoiding excessive compromises. Designers can help ensure that these changes do not impact their costs, schedule or workload more than absolutely necessary by looking across the range of immediate and future products, then making platform decisions that can be scaled with a minimum of rework and maximum of re-use.
About the author:
Stefan Ingenhaag is Senior Engineer MCU/MPU Solution Marketing ICBG, Renesas Electronics Europe.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
