Getting a handle on embedded software development costs

The Synergy Platform from Renesas, with its warrantied Synergy Software Package, removes a large portion of this typically underestimated and unforeseen cost of product development.

By Kim Dinsmore, Senior Engineer, MCU/MPU Solution Marketing, Industrial & Communications Business Group, Renesas Electronics Europe.

The most dangerous word in embedded firmware development is 'just'. Today’s new embedded systems requirements are full of 'just': just make it go faster; just replace the LCD with a colour graphics display; just replace the switches with touch sensitive buttons; just add USB connectivity. Sometimes 'just' can be motivating. It can encourage out-of-the-box thinking and not knowing what is considered to be impossible can challenge accepted limitations. But all too often, it indicates that someone does not really understand the task, nor what it actually entails. And that 'someone' is often a manager who has already committed to the concept, much to the frustration of the engineers who are going to have to make it happen. Sometimes, tasks that appear to be difficult are actually relatively simple to implement. But that is an unusual case. Typically, it is exactly the opposite. Simple concepts like capacitive touch are very application specific and difficult to quantify. Concepts such as 'internet connectivity' roll off the tongue easily, but the reality of implementing it is quite different. Plus, the fundamental integration of multiple, sophisticated technologies is a challenge in itself, ensuring that each task has the bandwidth and resources it requires without interfering with other system requirements. Today’s sophisticated MCUs enable the creation of embedded systems with capabilities that far exceeded those of their predecessors. But gone are the days where the development costs of the firmware were reflected by the cost of the MCU. Technologies today are evolving and expanding, growing in both number and in complexity. How can companies today rein in the escalating cost of software development and still hit critical market windows with unique, differentiated products?

Let’s say we need to update a control panel. The basic control requirements have not really changed much, but these days it is all about user interface and connectivity. The old control panel had an LCD display and push button switches, but the new one will have a touch sensitive colour graphics display. Cloud connectivity and firmware upgrade over WiFi was considered, but have been deferred for the moment, though the hardware is going to be designed for that potential. Instead, configuration and upgrade will be done via a USB flash drive, so security can be handled via physical access to the unit. With graphics, touch, USB and primary control algorithms all needing to run simultaneously, this is going to get complicated very quickly. So we will need some sort of scheduler, to ensure that all of the processes execute with the correct relative priority without interfering with each other.

Figure 1 – basic software architecture block diagram

Our final architecture is going to look something like what is shown in Figure 1. Note that out of all the required pieces, the only component that is truly unique to our product is the 'application block'. The other pieces are simply the foundation that is required before we can start building our product! We could even completely change the product and not alter the required foundation. There is nothing here that will truly differentiate our product in the market. Yet, the foundation is still required. There are three ways we can go about creating this foundation:

1. Implement all of the pieces ourselves;
2. Use components from various sources; or
3. Start with a commercially available platform.

Creating the technically challenging components of a scheduler, a USB stack and a graphics library from scratch is an intriguing option and offers some compelling advantages, at least to the engineer. All of the development expertise will be in-house, so if any problems arise, they should be able to be addressed quickly. And keeping development centralised can help create a more optimal, targeted solution. And if we are honest, most engineers prefer to develop these things themselves. But if the developers have no previous experience with the technologies, they will run headlong into problems that have long since been identified and solved by experts in the field. How to identify and handle conflicting processing priorities in the scheduler? How to control the interaction between touch and graphics? What do you mean, this USB flash drive works fine but that one does not; are they not all the same? All these questions and many more will cause implementation and test time to increase exponentially. So while most engineers would thoroughly enjoy the challenge, it is simply not practical in today’s business environment.

The next option is to gather components from various sources. MCU vendors often offer hardware drivers for their devices and internet searches can reveal a wide range of available stacks and libraries. But there are various problems that can arise here, also. The first is licensing. A library from one vendor may be licensed for use only with a particular manufacturer’s products, but you may want to use a different MCU. Some licensing schemes may require you to contribute any changes back to the community, thus eliminating any advantage you might have over competing solutions. Other licensing schemes require that the code cannot be used for commercial applications. Due to the wide variety and complicated legal ramifications of various licensing schemes, many large companies who develop embedded products simply have a firm policy that no open source code can be utilised. So it is highly probable that you will have to source various solutions from multiple vendors. The advantage here is that you can obtain the best technical solutions. There are disadvantages, however. It can take quite some time to identify these solutions, which again can jeopardise time-to-market. Licensing and payment schemes will be different for every vendor. Some have an up-front charge, some charge royalties based on the number of products produced. Managing the licensing of multiple components can be a time consuming task. Finally, the various components must be integrated, so they can all be used together in the same application. While this may sound like an issue that can be resolved by simply sourcing all of the same components from the same vendor, this often is not the case. For one, software vendors often specialise only in certain areas and offer only specific stacks or libraries, such as an RTOS. But also, frustratingly, it is not uncommon that stacks and libraries from the same vendor are incompatible, requiring rework or additional interface code to enable them to function together. This all-important integration phase is typically the most overlooked and under-budgeted phase of project development.

In either case, whether home grown or purchased, the final integrated platform must be extensively tested, to ensure a solid foundation upon which to build the application. This stage is critical, as issues here can often be difficult to detect, identify and isolate once application code is added. It can be tedious and time consuming, requiring dedicated test drivers to be created to stress test the platform. Yet it cannot be omitted without significant risk to the final product, with borderline and corner cases often not appearing until months in the field, usually requiring expensive and embarrassing repairs.

If we look at a reasonable estimate of how many man-hours are required, it is a bit staggering. The calendar time can, of course, be reduced by having a software development team, but only up to a certain point. Forgotten tasks, under resourced tasks, unexpected integration issues… These are the primary root causes of software induced schedule slips. Often, only 6 months is scheduled for platform creation, sometimes less. But it can easily take a year. And that is simply a platform, the foundation upon which to build the actual application. When this phase is complete, there is not yet anything to differentiate your product in the market. In today’s market, this basic functionality is expected. But if you do not have it from the beginning of product development, you are already a year behind.

Table 1 – time to create a software platform from scratch

Table 2 – time to create a software platform from off-the-shelf components (Additional time needed for touch support)

But, suppose you could start with a software platform that was already implemented, integrated and tested? One that was targeted for a set of MCU’s that allowed you to easily scale not only your software, but your hardware as well. Instead of starting out 6 months behind and slipping an additional 6 months, you gain 6 months and minimise or even eliminate the risk of schedule slip. What could you do with that extra time? You could beat your customers to market by weeks or even months. Plus, you could add features that truly differentiate your product. For example, the WiFi connectivity that you deferred could be added, especially if the platform already contained an Ethernet stack and WiFi drivers. If the MCU’s are scalable and pin compatible as well, then the additional programme memory and RAM requirements of such a memory intensive capability are not a critical concern; just substitute a larger processor or maybe even a more powerful one. The platform can account for them automatically, and the schematic needs only a label change for the MCU.

The Renesas Synergy™ Platform is one such option. From a hardware perspective, it offers four series of MCU’s based on the ARM Cortex M0+ and M4 cores. With complete functional and pin compatibility across both the series and the packages, they are the perfect foundation upon which to build a complete embedded platform. Time-proven stacks from Express Logic form the backbone of the software platform, with drivers and frameworks that abstract the lower levels and allow developers to focus on what they want to create, rather than developing the building blocks to support their creation. Targeted application examples can accelerate development even more, by giving users a jump-start on their application. Plus third party stacks and libraries, verified by Renesas to be compatible with the Synergy Platform, enhance and expand the capabilities of the platform, in areas including security and Cloud connectivity.

Figure 2 – the Renesas Synergy Platform

Looking ahead, the world is getting connected. Devices are connected not only to each other, but also to a central system, allowing remote monitoring and control. Embedded applications are evolving in ways that ten years ago were barely even imagined. Smart energy meters that can track usage and apply cost profiles, allowing consumers to monitor and optimise their energy usage. Street lighting that can report outages, provide varying degrees of illumination for weather conditions based on single point of control rather than requiring multiple expensive photocells. Parking systems that can locate and guide users to available parking places within a car park. It is an exciting time for embedded development. But with all of these new technologies, embedded product development companies can no longer afford to give firmware developers the time and resources required to become expert in all areas. The investment in time is simply too great, and in today’s fast paced economy, time to market is critical. Instead, developers must leverage existing tools, and focus on what they do best - innovate.