A common sense approach to avoiding MCU software losses - Embedded.com

A common sense approach to avoiding MCU software losses


Many MCU software engineers unknowingly create large product and software losses for their employers. They are trying to do a great job but have not been educated in the economics of software engineering and product management.

On larger projects, program managers and senior software engineering managers fill this gap, but for smaller MCU based projects this high level expertise is not assigned. The net result is inefficient and suboptimal engineering decisions in many organizations.

To understand this phenomenon in more depth, first we will examine the shift in the MCU market from a solution space that was 80% hardware and 20% software to the current environment of 80% software and 20% hardware. Given a fundamental shift in the problems that developers face, how can these developers ensure that their solutions are optimal for their company?

Second, we will examine the cost structure of MCU software development. What are effective ways to minimize costs during development? What minimizes maintenance costs? What minimizes total costs for a prototype; for a product; for a product line? Armed with this knowledge and understanding, you will be much better equipped to make correct choices.

Third, we will examine the effectiveness of the business case for different software approaches. The most effective approach during software development may not be the minimization of up front costs.

It depends on the goal. In some instances up front cost minimization may be the correct approach, but in other instances it is completely the wrong approach. What is the best approach to maximize profits for a prototype; for a product and for a product line?

Finally these principles will be applied to software offerings for MCU development. A comparison of the various approaches versus system complexity, licensing, and standardization can be used to find the most effective approaches for your development.

MCU Market Shifts
The concept of the market shifting from hardware to software creates an opportunity to reduce the overall hardware costs with fewer parts, and increase reliability at the same time. Now the bigger memories and faster processing along with demand for new features create a big software problem.

How can this be overcome? Generally, experienced hardware designers must re-educate themselves in software engineering techniques. Engineers that fail to do this and use their old approaches will create suboptimal designs which will trigger significant financial and market share losses.

Figure 1. Cost of ownership of different software architectures

The total cost of ownership is estimated for four different software architectural approaches in Figure 1 above . This illustrates how the choices of a scheduler or timing loops work for trivial systems.

It also illustrates how a real-time kernel offers some assistance but shows that POSIX standards based, complete RTOS is the best approach as system complexity increases. Most often, a lack of software engineering and business understanding leads developers to choose much poorer schedulers and standalone kernels which are suitable for simple systems, but uneconomic in today's environment.

MCU Software Engineering Costs
Table 1 below shows a variety of factors which have varying levels of importance for prototypes, single products and a line of products. This table identifies how the various factors which affect overall cost impact the implementation of these different types of systems.

Table 1. Factors which affect overall cost impact on product design

If you look at the choices that users make in the field, it is apparent that many designers start with a prototype mentality and then it becomes the product or product line.

Because they have committed to software solutions that are free for prototyping, but inferior in TCO for products or product lines, engineers don't throw out the prototype and re-analyze, rather they continue to refine based on the free prototype architecture.

The product will work, given enough time and effort; however, the approach becomes institutionalized. Software is the big investment here and 80% of the investment was just made using poor software architecture. Developers are left with a suboptimal approach, but are locked in by their initial approach.

The single most common and expensive mistake in MCU software development is choosing a free prototype oriented environment and letting it become the environment for the final product without re-analysis.

The solution to this dilemma is to choose prototype solutions that evolve into optimal product and product line approaches in an incremental fashion. By doing so, developers completely eliminate the need for any rework.

Key to a product line approach today is the following set of Lean Product Development concepts:

1) Research in parallel with development
2) Technology Insertion to upgrade the line
3) Standard platforms
4) Component or modular systems
5) Industry software standards

Choosing a lean product development approach coupled with good management will immediately lead to minimized TCO and maximized profits and market share. A prototype is really the start of research on a new product.

By choosing a prototype or research environment that is suitable to move from a prototype to a product and on to a product line, you can minimize or totally eliminate software rework, minimize time to market and minimize total cost of ownership (TCO). It will immediately let you develop your lean product development strategy without risk or additional costs

Time To Market – The Business Case
Time to Market is an absolutely key parameter for all OEM products. The reason for this is linked to product life cycle and market penetration. If you delay your product, you are giving up market share. The diagram in Figure 2 below illustrates what you are giving up as you delay entry of your product into the marketplace.

Market share is very important in terms of profitability. We have known for decades that profitability has the strongest correlation with market share and from this we know that we should strive for market share in our defined niche. The actual addressable market is the area under the curve.

As delays are introduced, the benefits from a longer sales life are lost along with the benefits from a larger market. As a result, a small delay can create a large loss in market share and a huge loss in profits. It is also true that the later you are, the worse the time to market share losses are.

Figure 2. Tradeoffs between market penetration and product time to market

Numerically, how important is time to market? To understand this, think about the effects of losing market share or sales volume on your product. A 10% delay in product launch can easily create a loss of 20-30% of the market share you estimated for the product. This can take you from a profit position to a substantial loss on the product. The costs can be summarized as:

1) Variable Costs Affecting Gross Margin:
Bill of Materials
Manufacturing Costs
Selling Costs

2) Fixed Costs:
R&D Costs
Marketing Costs
General and Administrative Costs
Plant and Equipment Costs

The variable costs are affected by the smaller market by increasing the costs on a per unit basis, particularly bill of material costs, and over time, through experience effect, the manufacturing costs. The loss of units of sales along with higher costs per unit erodes the gross margin or the fundamental business of the company.

The Fixed Costs are not affected by time to market delays. We must be prepared to manufacture to meet the projected volume and the R&D, Marketing and G&A costs are unchanged.

Overall, we have much smaller net sales, which cost us more per unit, and a fixed set of costs that does not change. A fairly small change in the number of units or a small market share reduction leads to a substantial profit reduction. All of this is brought about by time to market delays.

The number one rule of OEM product development is time to market is the most important factor of new product development and launch .

Software Engineering Choices: The Business Case
If we know that minimizing time to market is the best way to maximize profits overall, how does this relate to our software engineering costs? Actually, the same set of factors that determine minimum single product and product line costs, are best choices to minimize time to market (Table 2 below ).

Table 2. Software engineering features and related time & cost savings.

Given that we make smart software engineering decisions, we minimize time to market and development costs which minimizes total cost of ownership or TCO. A standards based software platform such as POSIX is the key to achieving all of these savings and minimizing risk.

Time To Market and Software Engineering In Practice
The discussion in this article can be reduced to a simple cookbook set of rules:

Rule #1. Understand what your goals are, particularly if you are successful. Always be prepared for a manager to declare that a prototype will become a product and choose a suitable environment for product and product line development even when prototyping.

Rule #2. Always apply sound software engineering principles – use modular standards based designs and keep your options open for changing requirements and low cost product upgrades.

Rule #3. Understand that using open standards will minimize training, maximize productivity and maximize software reuse. It is the best strategy to contain costs and development time.

Rule #4. Always go for quality systems and integrated testing. You have only one reputation to loose.

Rule #5. Standardized platforms which are performance optimized eliminate rework and optimization. This is critical as the costs of optimization are significant and can quickly delay and bloat system costs. Free prototyping environments often offer abysmal performance and if kept for a product development can increase both time and costs substantially. A more thoughtful choice eliminates this issue without risk or costs.

Rule #6. MCU vendor provided software provides necessary low level drivers for unequaled system support (i.e. CMSIS). In the past this has not been the case for board support packages, however it is true today for chip support packages.

Rule #7. Maintenance costs are minimized through modular standards based architectures and high quality tested components.

Rule #8. Safety features are critical for real world products – make sure you have the options to use them if required.

By following these simple rules, you will minimize your Total Cost of Ownership and make everyone in the company happy as you deliver very high quality products much faster. You will be able to transition to a full line of products without effort or extensive rework and create greater value.

As POSIX is the most broadly accepted industry standard, available from all major RTOS and OS vendors, getting a POSIX prototyping environment which can transform into a commercial development environment for your product and product line is the best move you can make as you implement your new software engineering based approach.

Kim Rowe has more than 30 years of experience in business management and systems engineering and holds both an MBA and an MEng. He has been instrumental in the startup of several companies and several business units in the computer systems and services areas. Rowe has published approximately 35 papers and articles in various journals and magazines.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.