An Engineering Problem in Disguise

A funny thing happened to me the other day during the Christmas shopping rush at our local shopping centre in Endeavour Hills.  Our daughter had purchased some clothes for her nieces for Christmas and used the self serve checkout. When she got home she discovered she had not had one of the security tags removed so she asked for my help.

OK, I might be an Electronics Hardware and Embedded Software Engineer but I did do a year of Physics and Chemistry at Deakin University before switching to Engineering and I have had a role in the design of Multidisciplinary Systems with Electromechanical Actuators and Variable Frequency Motor Drives including Multi-Axis Robotic Handlers.  So I thought, “How hard can this be?”

The first step was to review the problem and identify the information.  Those familiar with Edward De Bono’s Six Thinking Hats will recognise this as the White Hat stage.

I had:

• circular plastic sealed tag with an alignment  feature – a hole through it to accept a tapered pin
• a metal pin with a large head inserted into the centre of the plastic disk
• no other visible connection points

So assuming the tag was made at a minimum price, needed to be aligned correctly to be released and could be disconnected without an external power source; I concluded that the release mechanism was probably magnetic.  So I got a magnet and did some experiments and I could hear something click inside the security tag as I moved the external magnet around.  Now I am very confident that it is a Magnetic Latching Mechanism.  But no orientation of a single magnet released the pin.

I got 2 magnets and worked around the unit until the pin released and the problem was solved.

Having released the tag I gave the garment to my daughter to wrap in Christmas paper and put the tag with pin inserted back into it by the front door.  Since we were shopping the next day I thought I would return the tag.  At the very least it would get recycled.

What’s so good about being an Engineer?

At the shops, I went to the help desk and offered them the tag.  They were very confused.  I explained that it had been accidentally left on one of the items we purchased so I took it off and was returning it to them.  The stunned reply was, “You took it off yourself”?  “Yes” I said.  “I’ll have to call security” was the next reply.  So I said, “It’s all right, I’m an Engineer“.  “Oh, that’s fine then” was the reply and I wandered off to collect some final groceries for Christmas dinner.

So apparently there was a connection in the shop assistants mind that made being an Engineer something special.  They may not have know what that connection was.  And that got me wondering about Engineers and what is so special about us.  Here is a bit of a list of my initial thoughts if I ignore specific Engineering Disciplines:

• we create the future by designing and constructing the machines and systems that it requires
• we routinely solve complex problems that others do not know even exist
• we do all of this because we want a better world and are prepared to do our part to achieve it
• we have learned that covering up a symptom is not the same as solving the underlying problem

You might have some thoughts of your own so please leave a comment.

And of course, I hope you had a Merry Christmas in 2009 and that 2010 is a very good year for you all.  Happy New Year!

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years.  For more information go to his LinkedIn profile. This post is Copyright  Successful Endeavours Pty Ltd.

Electronics Design To Save Energy

We have looked at how Low Power Electronics is a green strategy because it reduces the amount of power that has to be generated.  And then we looked at a range of options for Reducing Electronics Power Consumption.

Now we are into specifics.  The last post looked at Sleep Modes For Microcontrollers and how extending the Sleep Period and reducing the Sleep Current could dramatically Reduce Electronics Power Consumption.

Saving Electronics Power When Awake

The next logical step is to ensure that Power Consumption when awake is also reduced as much as possible.  This can be a little tricky to get right as it can sometimes eliminate all the benefits you built up with you sleep strategy.  The reasons for this are:

• you can use Analogue Electronics to reduce software power requirements but it has to be turned off during Sleep Mode
• if you do turn the power off to Analogue Electronics then there is a Settling Time after it is powered up
• using Smart Electronics Chips can increase overall Quiescent Current
• unless the Startup Time and Shutdown Time are quick, these can dominate the Power Consumption

Now there are some Software Architecture issues that affect these, especially the last one, but we will look at that in another post.  For the last part of this post we will address the Electronics Design issues that have been raised here.

Electronics Design – To Save Power

Electronics Design can address these Power Consumption issues.  Here is an example of a Power Consumption curve where an RC Time Constant must be taken into account to minimise average Power Consumption.

RC Time Constant affect Power Consumption

Here is a list of general strategies to select from to reduce Power Consumption:

• using the lowest feasible Clock Rate so Clocked Devices use less power
• using shorter Settling Times particularly by controlling RC Time Constants
• select semiconductors for lowest overall Quiescent Current taking awake and sleep operation into account
• ensure streamlined Startup and Shutdown operation

The overall Quiescent Current issues often gives the most difficulty.  This can be addressed through Design Simulation either by SPICE, Software Modelling or a spreadsheet.  For simpler systems the spreadsheet is often the easiest solution to implement.  For very Software Intensive Systems the Software Modelling approach is the most reliable method.  This will allow you to construct scenarios and be able to predict the Power Consumption implications for each of them.

For our Electronics Design and System Test methodology we often create a full system Software Model and so it is easy to use this same Software Model to accumulate the power consumption as it runs.  This can also be automated and so simulate months of operation very quickly.

Next we will look at the role of Embedded Software in ensuring Power Consumption remains as low as possible.

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years.  For more information go to his LinkedIn profile. This post is Copyright © Successful Endeavours Pty Ltd.

How Does Sleep Save Energy?

For this post, we will look specifically at Embedded Software techniques to save power and energy.  This is a well known Power Saving Strategy which doesn’t always get the recognition it deserves.  It is also something you have to design into the Power Management Plan from the beggining.

For this example, we will use the MSP430 from TI which has some of the best Power Saving and Power Consumption figures in the industry.  We have used them to create devices that run from a pair of AAA batteries for 2 years and which have time based control algorithms so that they can’tbe used in a purely event driven mode.  Here is how it works:

Low Power Sleep Mode

This shows the power consumption versus time.  In Low Power Sleep Mode the consumption is close to zero.  Almost no power consumed.  Then depending on what is happening it wakes up to varying degrees.

Get the best Electronic Sleep

So this is how you take advantage of this:

• make the time between wake ups as long as possible
• make the time awake as short as possible
• only turn on the peripherals needs for a particular wake period

Now if you system only has to wake once every minute then you can get low power operation from a lot of different processors.  If it wakes many times a second then you need a processor that gives you lots of ways to reduce power during wake, reduce the time awake, and increase the interval between wakes.

MSP430 Sleep

So back to the MSP430. It has Power Conservation features that allow it to do all three better than most.  Here is the list:

• Digitally Controlled Oscillator DCO allows it to wake and run quickly
• Can run a Timer from a 32KHz crystal making interval timing very low power
• Can use the DCO to set the run speed and so shorten the wake time
• Lot’s of Power Down Modes so you can always find one that suits your application
• Peripherals can be Shut Down when not in use
• Can run down to 1.8V – more on that later but it can also help here

Low Power System Architecture

To take advantage of all this, you have to develop the System Architecture so that  takes advantage of this.  An example from a very long life application we did runs like this:

• 32Hz Oscillator runs a timer that generates a 1 second wake
• User input keys set up to wake on change of state from high to low
• Use DCO at 1MHz to quickly wake, execute & sleep again
• Use State Machines to allow modules to execute predictably with eratic timing
• Have early exit tests to prevent unnecessary Code Execution

The result is an application that runs a process with User Interaction, LED Indicators, and a 2 week cycle where the average Power Consumption is 20uA at 2.7V or 54uW.  Of this, less than half is the processor executing the software and the single biggest energy use is the intermittently flashed LED Indicators.

To learn more, check out this more comprehensive article on “Low power MCU selection criteria and sleep mode implementation” from embedded.com which provides more examples.

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years.  For more information go to his LinkedIn profile. This post is Copyright © Successful Endeavours Pty Ltd.

What is so good about Low Power Electronics?

If you read my last post, you would have noticed that this has the potential to reduce overall Power Requirements.  Up until now,  only Battery Operated Devices have really cared about Power Consumption.  If you could plug it into a wall outlet then all was OK unless you were consuming more power than a standard circuit allowed.

Today, things are different.  Climate Change is a global concern and reducing the Carbon Footprint for a product is important, regardless of what sort of power it consumes.

If we can reduce the Power Consumption of an appliance by 50%, then provided it’s Electronics Manufacture does not add that back again, we have a net Carbon Footprint gain.  In fact, if we can do this across all products then we will meet our Global Carbon Reduction target of 50% by 2050 with this strategy alone.

How to reduce Electronics Power Consumption

This is not a new topic, and much of what I present here represents the combined experience of the Electronics and Embedded Software industry.  Here is the short list:

• reduce the Supply Voltage for Microcontrollers, Microprocessors and CMOS Circuits in general
• use Sleep Modes and keep the Wake Periods as short as possible
• replace High Power Consumption Devices with Low Power Consumption Devices
• replace high utilisation Digital Filters with Analogue Electronics equivalents
• replace Polled Operating Modes with Event Driven Operating Modes
• use Low Power Smart Peripherals that Wake the rest of the System only when required
• reduce the Time To Wake and the Time To Sleep
• optimise the Software Execution Flow
• use Energy Harvesting
• Remove power from sections of Electronics Circuitry when not in use

There is overlap and interdependency between these but that is a good starting point.

Next I will start look at specific examples.

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years.  For more information go to his LinkedIn profile. This post is Copyright © Successful Endeavours Pty Ltd.

In this post we will look at the Product Development Process and how to get improved outcomes.  But first here is a fun graphic made from our logo.

Successful Endeavours - Making Electronics and Embedded Software Work

Product Development Process

The Product Development Process is intended to reliably deliver new products for manufacture or distribution.  This is a critical component of a Product Strategy where you are creating the product rather than sourcing it from a supplier.   So you would think that it should be a highly optimised, well oiled machine that reliably delivers successful products. Alas that is not always the case. With 30 years of experience in Developing Products for a wide range of industries I have seen my share of projects handled well and not so well. Here are some general principles I have gleaned from my experience in Successful Product Development Projects:

• Risks must be identified and managed.  Track them and eliminate them as soon as possible.
• Anything clever or tricky needs to be checked by someone else.
• Everything else also gets checked.  Design reviews, code walk-throughs and prototypes save time, money and heart ache later on.
• Hold the timeline.  Foster an attitude that slippage is not acceptable.
• Test and check everything.
• It’s not finished until no-one has to do another thing to it.

So six core principles.  They are inter related of cousre.  Let’s look at how these work out in practice.

Successful Product Development Principles

Lets look at how each of these priciples can be used to improve the likelihood of a Successful Product Development Project.

Risk Management

Risk Management is an old idea.  Not surprising since risks have always existed. Did you know that during the Manhattan Project it was determined that there was a chance that a fission bomb could ignite the whole atmosphere ?  Having got contradictory reports the argument was eventually settled by a report showing that although it was possible, it was unlikely.  How comfortable would you feel running that risk ? Fortunately the average Development Project is dealing with much more mundane risks such as achieving Technical Requirements such as:

• Power Consumption
• Unit Manufacturing Cost
• Performance Criteria

But the approach is still the same:

• Identify the risk
• Work out how to ameliorate the risk – reduce it – or eliminate it
• Do tests to confirm the risk has been dealt with
• Iterate until it is no longer a risk

Review the clever bits

Test Everything - Clever Design Needs Test

Where possible, any particularly clever or tricky areas of the project need to be reviewed by someone not involved in the everyday work of the project.  This is primarily to ensure that assumptions are challenged.  If you can’t get an outsider to do the review, use a process like Six Thinking Hats by Edward De Bono which can allow team members to step outside their emotional and assumptive predispositions.  Unchallenged assumptions are unmanaged risks.

Review the rest of the project

Review Everything

The astute amongst would have noticed that I am proposing everything gets reviewed.  But the tricky bits get extra review.  This section is for the regular bits. Reviews are an essential tool to find mistakes early and eliminate problems down the track.  You don’t have to solve a problem you don’t have.   Or as Jack Ganssle famously quipped “Skip Bugging To Speed Delivery“. The whole article refers to using Code Review and Design Review to find problems early and fix them so they don’t become much bigger problems later on. Imagine a scenario where a Software Bug causes an electric motor to try and spin backward every now and again and then corrected itself almost immediately.  You would get a momentary shudder or jerk followed by correct motion and it would only happen every now and again.  How would you determine that this was a software fault and where the fault lay?  It could be symptomatic of any number of issues including Mechanical Design and Electrical Design. How about this similar real world case.  I won’t mention the company, but their elevators had an Integer Overflow problem in the motor controller that caused the elevator to go in the wrong direction, about once a month, for half a floor.  Very disconcerting to the passengers if they pressed up, and promptly dropped half a floor before then going up.  Fortunately they found it and fixed it before it happened to someone at the top or bottom floor. All the Software Industry Metrics show for that for Software Development; Design Review, Code Review, Unit Tests and System Simulation save money and time.  And yet in many projects they don’t happen enough or are done after the event as a Quality Assurance box ticking activity where they add mostly cost and little in the way of value.  Lean Coding argues that you can reduce your Software Development Budget in particular by doing Code Inspections during the project as part of the Risk Management and Quality Management process. By reducing the bugging, you can reduce the debugging.

Stick to the Timeline

Project Development Timeline

An attitude that the schedule slipping is normal can be very costly.  Some examples of how to avoid this are:

• Develop and Simulate the Software before the Hardware is ready
• Prototype early and thoroughly
• buy in IP where it makes financial sense – this can also reduce risk
• get expert assistance with areas outside your competence
• review regularly and honestly

As someone who has done a lot of team leading and project management, I have learned to ask about progress in more than one way.  I find the following to be very common: Manager: “This module is estimated as 10 days of work to complete.  How complete is it”? Developer: “About 80%”. Manager: “How many more days of work are required to fully finish everything”? Developer: “To fully finish everything, I would think 6 more days would cover it all”. The discrepancy is easy to spot.  People estimate high on progress because they want to please.  They also like to finish well so they tend to estimate conservatively on required effort.  In practice the real answer lies somewhere between the 2 extremes.  If the task had already consumed 6 days of effort then it is likely to run late. If you have ever built a house you might have experienced the knock on effect it has when one trades person doesn’t turn up and everyone else misses their scheduled action time because they are now waiting on a predecessor task, the trades person who has to come back again, before they can start their task.  The same thing happens on projects. So fight hard to hold to the schedule.  It is better to over resource a task (according to the plan) and get it done than to let everything and everyone slip which usually costs a lot more. Additionally, it is quite common that the later you are in the market, the lower the overall profit.  So it is worth holding the schedule for this reason as well.

Test and Check Everything

 

Test Everything

This is another Risk Management related principle. Don’t assume it will be OK.  Even if you have done it 100 times before, test it again this time.   Make sure it really is OK.  This ensures it really is 100% complete. This also implies that you are going to design things so they can be tested.  Another principle.  Design For Testability or somestimes called Design For Test. Do it.  It will save you time, effort, money and sleep. Test Driven Development is another example of a Modern Development Methodology where you set up the test first then develop the product so it passes the test.  If the Product Requirements change, you change the tests first, show that the old Product Design fails the test, then update the Product Design until it now passes the test.

It is not finished until no-one has to do anything else to it

Many tasks are called complete but they aren’t.  The documents might be checked into the Revision Control System, also known as a Version Control System or Version Management System,  but it isn’t complete until it is 100% tested, 100% integrated, 100% reviewed and 100% signed off and no-one has to do another thing. This also means that when tasks are identified that weren’t thought of in the original Project Plan, you then add them and don’t try and fiddle them into existing tasks.  This is different to working out the fine detail of a task and realising it is under resourced or over resourced on the Project Plan. You also want the extra tasks visible on the Project Management Plan so when you do the next project you have evidence that they were required last time and can make allowances for them.

Trip Assurance for Developers

Satisfaction Guaranteed

In marketing, the term Trip Assurance refers to the client having a clear expectation of this transaction or experience being a good one, just like every other one has been.  I think we can begin to develop some of the same as developers whereby projects can be routinely good experiences and likely to be so each time.

 This post is also available as an eZine article with Expert Author classification.

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years.  For more information go to his LinkedIn profile. This post is Copyright © Successful Endeavours Pty Ltd.

Electronics Manufacturers are the people we serve

A common question we are asked is what sort of Electronics Manufacturers do we Develop Products for?

So I thought I would compile 3 lists:

• The first is a list of the Electronics and Embedded Software product types we have worked on
• The second list is a list of the industries we have Developed Products for
• And the third list is the Technologies we have worked with so far

I might have to regularly update this third list since knowledge and technology are constantly expanding.  Before I do the lists I’d like to present a video that specifically addresses this last point.  This is very much worth thinking about.  Enjoy.

Electronics and Embedded Software Products

Did you notice the section from 1:45 to 2:15?  We are being prepared for jobs that don’t yet exist, technologies that haven’t been invented, and problems we don’t even know we will have!

Here is the list of some of the Electronics and Embedded Software Products that do already exist and which we have helped to create:

(more…)

Electronics Development and Success

Hello again,

A couple of posts ago in Electronics Manufacture Shines in Melbourne I said I would explain the origins of our company name.  Many have suggested that Successful Endeavours sounds more like a personal coaching enterprise or a business that handles products by people like:

• Brian Tracy
• Tony Robbins
• Marc Dussault
• Deepak Chopra
• Zig Ziglar
• John Maxwell
• Arthur Cherrie
• …

And the list could go on for a long time.

While I do hope we motivate and encourage our clients to improve their results, we assist them by undertaking activities such as:

Electronics Development Activities

• Electronic Circuit Design
• Electronic Circuit Simulation
• Analogue Electronics
• Analogue Design
• Printed Circuit Board Design
• Printed Circuit Board Layout
• Electronic Prototyping
• Electronic Testing
• Embedded Software Design
• Embedded Software Development
• Embedded Software Coding
• Embedded C
• Embedded Software Debug

Development Statistics

The name came from some industry statistics on the success rate for Product Development.  You can read more details in Reducing Electronics and Embedded Software Product Development Costs and I will summarise here:

• 80% of embedded development projects fail in someway or another
• Embedded software is 80% of the cost of an embedded development project
• Embedded software is responsible for 80% of the delays and shortcomings

Successful Product Development

So it seemed to me that many Product Development Projects are unsuccessful endeavours.  I wanted to change that.  We have a success rate significantly better than all the industry norms. Our short USP ( Unique Selling Proposition ) is:

We Make Stuff Work

That’s it.  The details are complex but the philosophy is simple.  So for me, Electronics and Embedded Software Development should be a routinely Successful Endeavour.  And so the name Successful Endeavours was chosen.

I am passionate and committed to assisting Australian Electronics Manufacturers who want to keep making their products in Australia.  Made In Australia is what we are pursuing and we are focusing on this segment.

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years.  For more information go to his LinkedIn profile. This post is Copyright © Successful Endeavours Pty Ltd.

There are a lot of news feeds running this story.  Here are a few:

Timeline ABC News
IEEE Spectrum
National Geographic
Business Journal

And when the Internet first began, no-one knew what we would be doing with it today.

This has happened to a lot of other technologies.  Low Cost Electronics and Low Power Design that can be Battery Operated has made many thing possible such as mobile phones, portable computers including netbooks, notebooks and laptops; portable media players, MP3 players, PDAs and the list has just begun.

But where is it going?  Realistically, you need a few things to come together and the environment and carbon footprint considerations now sit alongside the more traditional requirements such as:

• Low Cost Electronics Manufacture
• Low Power Electronics Design
• Design Tool Productivity improvements
• Electronic Design Automation
• Increased Processing Power per milliwatt (mW)
• Embedded Software of immense complexity and flexibility
• Flexible circuits
• Transparent Electronics
• Compact component size
• Reduced Polluting and Increased Recyclability and reuse

Vernor Vinge looked into what might become of this in his book Rainbows End which I recommend as a good read and full of well thought out ideas about how augmented reality might operate including concepts such as  wearable computers, gesture recognition, graphic overlays, the equivalent of doing a Google search on any object in your field of view, and other ideas like that.  It is set 20 years from now.

The most interesting for me was the way work was conducted in the future and how much advantage there was in having 100,000 people as affiliates on a program.  Pay is based on royalties for contributions.  You choose what you join and contribute to.  Your income directly reflects the product of your contribution and your negotiated royalty rate.  A large company has 3 direct employees and everyone else is an affiliate on one or more programs of work.  This produces phenomenal synergies.

It will be very interesting indeed to see how much of his vision matches the future.

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years.  For more information go to his LinkedIn profile. This post is Copyright © Successful Endeavours Pty Ltd.

________________________________________________

National recognition for local Casey Business

OK, I couldn’t resist that blog title or this headline.  It isn’t often you get a chance to say something like that.  If you hadn’t heard yet, we are finalists in two categories in the EDN Innovation Awards for 2009.  Melbourne is the Electronics Manufacturing capital of Australia and we are based in Berwick which is administered by the City of Casey .  And we are also members of the Berwick Chamber Of Commerce.

Successful Endeavours in the NEWS

The Berwick & District Journal has just done an article on Successful Endeavours that also covers the EDN Innovation Awards we are finalists for.  You can check it out here Electronics Whiz Wired For Success.  And as a bonus, you get to see what we look like.

Electronics Manufacturing

Our aim is to turn Australian Electronics Manufacture into Low Cost Electronics Manufacture through improving the total cost of a product throughout its lifecycle.  This is not a quality reduction process.  Quite the opposite.  Getting the product right so it doesn’t fail and does do what it is meant to do is one of the things necessary to reducing cost.

Located on the outskirts of Melbourne we primarily serve Melbourne based Electronics Manufacturers by providing them with ELectronics and Embedded Software Development services that save them up to 70% compared to traditional linear Product Development.

So how do we do that?

Firstly, there are a few blog posts you can refer back to that will fill in some of the details.

Successful Product Development

• Performance and Cost versus Time
• Time and Cost versus Performance
• Time and Performance versus Cost
• Project Priorities Perspective
• Reducing Electronics Manufacturing Parts Cost
• Reducing Electronics and Embedded Software Product Development Costs
• Electronics Products Made In Australia – Strategies to be more Profitable

Australian Electronics Manufacturing

Low Cost Electronics Manufacture in Australia that competes favourable with China is feasible.  Ignoring the trade offs discussed in the links above, the steps to take are:

• Identify the primary priority – is it time, cost, performance?
• Reviews costs – all the costs – see the last link above if you are sure what they all are
• Reduce Cost through redesign to remove unnecessary labour and to streamline manufacture
• Implement
• Deploy
• Monitor and correct as required

Written like this it sound simple, and conceptually it is.  Where it gets lost is in the assumption that it can’t be that simple.  But there aren’t any hidden traps in this process.

We have had a few queries about how we came up with our company name, Successful Endeavours. Next post I will reveal all.

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years.  For more information go to his LinkedIn profile. This post is Copyright © Successful Endeavours Pty Ltd.

________________________________________________

First some basic statistics that made me think about this issue a bit more:

•  Software development is responsible for 80% of the delays and complications associated with designing a new product.  Source Embedded Forcast
• 80% of embedded projects are delivered late.  Source Embedded.com
• Software typically consumes 80% of the development budget.  Digital Avionics Handbook and Embedded.com
• 80% of software projects are unsuccessful  IBM

That is a lot of 80% figures associated with the software component of product development.

So working from the Pareto Principle it is clear that product development success and cost can be most improved by addressing the Software Development component.  In my recent post on Reducing Electronics Manufacturing Parts Cost I argued that increasing the software component can reduce the hardware costs.  Which is a great idea as long as it doesn’t introduce an even more expensive problem. 

I agree with Jack Ganssle in his article looking at tools where he points out that software quality tools are often not budgetted for yet will find many classes of defect quickly and at a significantly lower cost than the test and debugging  effort required to find them after integration with the rest of the project.  Or put another way, the cheapest way to get rid of bugs is not to introduce them in the first place – Lean Coding.

Since we mainly develop in C and C++, this is what we do to ensure we minimise software development cost and overruns:

Static analysis and code reviews

We use static analysis and code quality tools such as PC-Lint and RSM and integrate them into our editors and IDEs so we can run the tests are part of our build or at the very least with a single click covering either the current file or the current project.  These tools find flaws you are hard pressed to identify by visual inpection and I believe they pay for themselves within a month of purchasing them.  They can also enforce coding standards.  Another great benefit is that when you do a code walkthrough and review, you are not looking for these classes of faults explicitly because you know the toolset will find them for you.  So the first thing you do is run the tests and focus on anything found there.

Code reviews save money.  Every issue identified in a code review is an issue you don’t have to debug later on. And another person is going to look at your code without the same assumptions you would so they will see the things you miss.  It just makes sense to do it.  Software debugging is more expensive than coding so not bugging in the first place is good budget management.

Smart Bear Software have an excellent whitepaper you can download for free that covers best practices of peer code review  and if this is a new idea to you, then I strongly recommend you get the whitepaper as they have distilled a lifetimes worth of learnign in this area into a concise and easily implementable strategy to improve code quality.

Unit testing

Next, we unit test.  A huge benefit of this is that you have to think about test and it makes you think about error handling in the design phase.  Many problems in implementing embedded systems come from not handling errors consistently.  Sometimes they aren’t handled at all!  In Failure is an option this gets explored a little.  Someone else once suggested that software developers were the most optimistic people on the market – you can tell this is true by looking at how they handle exceptions!  I’m not sure who said it so if you know then post a comment and I’ll credit them and provide a link too if you have one.

Integration testing

Integration testing itself does not have to be overly complex.  You want to know that things work and it is often easier to write a cut down system to manage the test process.  This way you are proving that each susbsystem is present and correct before doing the full scale system test.  This is an area that often gets overcomplicated.  Don;t try and do more here than you have to.

Oh, and by the way, just because something builds don’t mean it passes the integration test.  Some things to cover are:

• software manifest – do I have the right version of each module?
• data flow – do the higher level calls get at the right data lower down?
• exceptions – do error returns get passed back?
• exceptions again – if you raise exceptions, do they get acted on?
• communications – does it communicate? 
• IO – are they mapped to the right pins and peripherals?

Simulation

For some systems or subsystems we write fully fledged PC mocks around the code and ensure it handles all the parameter and error cases correctly and that all the functions are correctly implemented.  This is a form of integration testing that proves the software component of the system is doing what it is meant to but goes a lot further to fully excercise part of it.  And since 80% of the problems come from software this is a very effective way of reducing bugs and difficult to track down system defects that are expensive on time and resources to cover in real time operating tests.

To do this, you have to abstract the interface so the code can run in the embedded version or the PC version without any changes.  This is easy to do if you think about it in advance.

One word of caution; the PC has a lot more resources and clock speed available compared to a smaller embedded system so this is not a substitue for testing on the real hardware to ensure execution latency is acceptable.

And for the purposes of this post, the PC could just as easily be a Linux or Mac system.  The point is to use the higher level system to efficiently and fully test the embedded software module so you save time and money later on in the project.  And let’s face it, who like to be under unnecessary pressure at the back end of an embedded software project?

System testing

If you think in advance about how to most easily implement the system testing then you can save a lot here as well.  We put effort into deciding how the do the test process at the architecture design phase so that we have the data flow required to actually do the test.  This can be as simple as having some extra parameters or calls available to be able to inspect the state of the system and the communications facilities to get at this data.  Where possible 100% parameter range testing and 100% code coverage testing is very desirable.  One thing this means is that you had better think about how you will create each error condition that must be handled!

Low Cost Software Development

Low Cost Electronics Manufacture relies on Low Cost Software Development.  So make it a priority.  The Pareto Principle says that it is the most important thing to get right.

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years.  For more information go to his LinkedIn profile. This post is Copyright © Successful Endeavours Pty Ltd.