Squash Lessons for Engineering

The picture in today’s post comes courtesy of Dr Marc Dussault, The Exponential Growth Strategist. At his recent Exponential Business Building Bootcamp, he demonstrated how a Squash Racquet gets broken from repeated use.

Broken Squash Racquet

So what does this have to do with Engineering? Glad you asked.

First, I have to explain the demonstration. Marc showed that it takes a very large amount of force to break the Squash Racquet.  He really applied himself to the destructive task and it took a few minutes of escalating Squash Racquet abuse before it finally succumbed and broke.  Some of us in the front of the room could tell just how much it required to break the Squash Racquet. However the Squash Racket already had a crack, so Marc knew where to apply the force in order to break it.  The picture above is the final outcome.  Without the crack being obvious, it would have been almost impossible to have broken the Squash Racquet using just randomly applied force.

Marc then explained that way the Squash Racquet became cracked in the first place, was by it being consistently scraped along the wall as he retrieved the ball from shots along the wall.  Marc is an outstanding competitive squash player and currently ranks  as World # 18! So he knows his stuff when it comes to squash.  You can read more about this at his Mindset Of A Champion blog.

So if you know what to look for, you can monitor the thinning of the racquet and get an idea of when and where it might fail.  If you don’t know what to look for, then the failure will be unexpected.

Software Testing and Software Engineering

A lot of Software Testing can suffer from the same problem.  If you already know where the weakness will be and how to spot it, then finding a bug is easy.  You can set up the scenario, monitor for the symptom and confirm the failure.  Or, if you have enough resources you can go the brute force approach and just break it through the persistent use of randomly directed and escalated force of testing.  However very products are simple enough and very few companies are large enough to have that level of resource and to solve the problem this way.  So for the rest of us, the other 99.995%, a more intelligent approach is needed.

Since you don’t know where and when it will fail, it is best to remove failure causes from the beginning. This is where Software Engineering come is. Software Engineering is not just coding.  Coding is the production end of the Software Engineering process.  Software Engineering is about designing the system so you have defined the components so they are each fully testable in their own right. Then you can apply processes like Unit Testing to ensure they are fully functional as stand alone pieces of software. You can then perform Integration Testing to ensure that software added to the system correctly handles both the Execution Flow, also known as Control Flow, and Data Flow required including error and Exception Handling. The result is that you build up a fully working and correctly executing system quickly and with great confidence. It isn’t a magic bullet but it is close to it.

As was famously quipped by Edsger Dijkstra, “If Debugging is the process of removing bugs, then programming must be the process of putting them in”.

So if you put less bugs in, you have less debugging to do. And that saves time and removes future time bombs.  Because the chance that you find them all is zero percent. And you can’t create a system that is 100% testable by brute force means. So you have to go about it smarter.  It will save time, money and improve the business outcome now and into 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 © 2010  Successful Endeavours Pty Ltd.

Software Testing

I recently met with an Australian Software Development company, PepperStack, and we got onto the subject of Software Testing. As someone who began their career as an Electronics Hardware Engineer, one of the things I learnt was that you have to test thoroughly to be sure everything is working as it should be. With Electronics, if you make a mistake with an Engineering Calculation you can easily destroy things. This is sometimes referred to as “letting the smoke out”. So it was good to meet with others who believe in the same level of rigorous software unit, module and system testing that we do.

Some Engineering Humour

Which reminds me of a joke I once heard:

There are 3 Engineers in a car going for a drive. The first is a Mechanical Engineer, the second an Electronics Engineer and the third is a Software Engineer. Fortunately the Mechanical Engineer is driving because the brakes fail and they are going downhill.  The Mechanical Engineer eventually brings the car safely to a halt and gets out to examine the hydraulic systems.  The Electronics Engineer gets out and checks and body computer, ABS system and the power train CAN bus.  The Software Engineer stays in the car and when queried about it says that they should all just get back in the car and see if it happens again!

Now don’t get me wrong, I’m not having a go at Software Engineers. The process of finding and eliminating faults is a very important part of the development cycle and is something that needs up front thinking and not just responding to symptoms.  And the more complex or sophisticated a system is, that harder it is to fully test every possible response to every possible stimuli and after a certain point it becomes impractical to have 100% Test Coverage (every line of code has been executed through all of the possible states).  The reason this is a bigger problem with Software Development is that the flexibility of software means that it is inherently complex and it takes skill and planning to manage that complexity so it is testable.

So here is the issue. More than any other discipline, faults can be experienced by an end user of a product under a situation or scenario you could not have proactively tested against before release.  There are many potential reasons for this including:

• change of hardware or operating system environment
• new standards or protocols
• the sheer number of potential combinations of drivers, peripherals, software and users
• the product being used for a purpose it wasn’t originally designed for
• gamma ray corruption of a memory location – I am getting esoteric now but in some areas like avionics and space this is a big threat

So how do you reduce the likelihood of these problems occurring?

Improving Software Quality

With many new products having Electronics and Embedded Software and the Software Development requiring 80% of the effort, it is important to delivery it as quickly and fault free as you can. The main weapons in your Software Quality arsenal have been known about for a long time but are, in our experience, just not used.  These are:

• Architectural Design – work out how the data and execution flow will happen and how you will manage the constraints
• Functional Decomposition – divide and conquer but with an emphasis on how each module fits into the system and how the interfaces work in detail
• Error handling - who will decide what to do with response codes – again this is data and execution flow and part of the architecture. In many cases exception management is at least 50% of the project.
• Have an Integration Test Plan – some thing that proves the data and execution flow matches the architectural design.  Too often “it builds” seems to be good enough here.
• Unit Test modules – so you remove all the issues before adding them to the integration
• Do the Integration Tests before you try system testing
• Design modules so you can integrate them as shells then add functionality down the track
• Have NVM and configuration data available at the beginning of the project and not as an after thought at the end
• Have a System Test Plan and use it
• Use some of the good practices of Test Driven Development – run the tests every time you change the code
• Have a rationale for what level of Code Coverage you can accept
• Have a rationale for what level of Churn you can accept – Churn is the percentage of the lines of code that have changed in the past time period.  Usually either a week or month depending on the size of the project.
• Use automated software quality tools. For instance we use both PC-Lint and RSM to automated many software quality metrics which saves a lot of time in Code Reviews
• Use Code Reviews, also known as Software Peer Review.  It really does save time.

Next I plan to look at what you can learn about software testing from a Squash Racquet.

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 © 2010  Successful Endeavours Pty Ltd.

Safety in High Voltage Power Distribution

My thanks to Tim Heemskerk of ABB High Voltage Division in Lilydale for this clip.  It shows how dangerous High Voltage power can be in Electric Power Transmission Systems and why ABB take so much care in how they handle High Voltage Switching, Power Factor Correction and Fault Isolation and Reclosers in systems operating at these Elevated Voltages.  Be sure to wait for the slow motion replay at the end.  I think these guys might have seen an episode or two of Myth Busters.

For those who don’t recognise them, the rectangular boxes with terminals sticking out the top are High Voltage capacitors used for Power Factor Correction in Power Distribution systems.  They have been charged to 13.8KV and hold 9675J of energy.  The pull cord is used to close the electrical circuit and the capacitor voltage is applied to the watermelon which conducts the current and the energy released causes it to explode rather spectacularly.  Not what you want happening in a real Power Distribution scenario which is why you want Engineers who know what they are doing working on both the Engineering Design and the implementation of these High Voltage Distribution systems.

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 © 2010  Successful Endeavours Pty Ltd.

This week I was the recipient of an Exponential Entrepreneur of the Year award.  Last year we were received 2 awards for technical excellence when we won 2 of the 15 EDN Innovation awards handed out in Australia in 2009. 

So I was very pleased to be receiving an award recognising the business side of Successful Endeavours.  The award was presented by Dr Marc Dussault of Exponential Programs and recognises entrepreneurs and business people who have demonstrated excellence deploying exponential strategies in their business by profitably creating exceptional value for their clients in a manner that is both measurable and sustainable. The award received was in the category of Engineering Consultant and was one of only 6 handed out in 2010 and the only one in that category. 

Exponential Entrepreneur of the Year 2010 Ray Keefe receives his award from Dr Marc Dussault.

You can read more about the awards at Exponential Programs Entrepreneur of the Year Awards page. 

The main reason for this post is to touch on the most significant aspect of this award for me. I once said that as a Business Owner I made a pretty good Engineer.  The past 18 months has a seen a transition away from that to the point now where I can say that I am an Entrepreneur who is also an Engineer.  Engineering is a Profession and so it isn’t something that suddenly stops being relevant.  Our education and mindset is all based on practical problem solving through the use of technology while balancing performance, risk and cost.  And we apply this skillset and mindset to most aspects of our lives, even when it isn’t the only way to go about it.  So I am very pleased to be making this transition.  Not only is our business better for it but our clients are as well. 

And I also thank our clients for the trust they have placed in us to deliver Electronics Design and Embedded Software Development for their next generation of market leading products, the vast majority of which are still made in Australia at a profit. 

Here is a picture of the Exponential Entrepreneur of the Year award certificate. 

Exponential Entrepreneur of the Year Certificate

 The initial nomination was published on PRWeb at 2010 Exponential Entrepreneur Award Winners Announced. 

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 © 2010  Successful Endeavours Pty Ltd.

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 for Green Manufacture

This is not as straight forward a topic as it might at first seem to be.  And this is because there isn’t yet a unified agreement on exactly what Green Manufacture means.  And like most Design Issues, you cannot do Electronics Design without clear requirements.  So what are the requirements?

Here are some Green Manufacture requirements or targets:

• reduce product Power Consumption
• reduce manufacturing Power Consumption
• add Renewable Energy options to the product
• add Renewable Energy options to the manufacture process
• reduce pollution or waste in the manufacture process
• reduce energy involved in upstream or downstream processes
• reduce pollution or waste in the upstream or downstream processes
• increase product life
• increase product utility
• increase manufacturing plant utilisation

I guess you can see the dilemma.  It can be hard to know which target to aim for.  Am I doing the Electronics Design with the product, process, life cycle or ecosystem issues as the primary concern?  And how do I balance these concerns?

Here is one excellent article that also discusses this topic Green Supply Line.

Electronics Design can be Green

One major thing we can do is reduce the product Power Consumption.  We are coming out of a phase where a mains plug pack power supply was considered an ideal way to avoid compliance costs when designing new products.  This has led to a proliferation of low efficiency always on powered devices.  A recent look under my desk reveals the problem we have as Product Developers where every device I use is either USB Powered or mains plug pack powered.

So a first step is to review this whole approach to supplying power to devices.  We have made steady gains in the area of Power Consumption reduction for the devices themselves.  Now it is time to do a similar thing on the Power Supply side.

Energy Harvesting

This is a new area that hasn’t yet reached mainstream development.  The idea is that you can utilise the ambient environment to get power for free.  Or at least you aren’t directly requiring extra Power Generation.  Hence the name, Energy Harvesting.

How you do it and the Electronics Design and Electronics Technology required to make it work are still being defined but there has been some interesting new progress.  Some key players are:

Linear Technology – new Energy Harvesting Integrated Circuit

Enocean – are front runners in bringing Self Powered Wireless devices to the market

What is Energy Harvesting?

This is where we use Electronics Design and Electronics Devices to generate power from the Ambient Environment.  The result is a product that doesn’t need to be plugged in and recharges itself automatically. Some of the Energy Sources that are used are:

• Light
• Thermal differentials
• Vibration
• Chemistry
• Pressure differentials
• Air Flow

One example of a product that does this is the Enocean Light Switch where you can just put it where you want it.  And if you change your mind, just move it. Now wiring required.

Right now the technology is still more expensive and so take up is slow.  But as it develops and the price comes down that will change.

We are in for some interesting times.

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…)

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.

So what is Niche Electronics Manufacture about?

Well, Niche implies it is aimed at a small and specific market segment rather than a large and universal segment.  Some examples might help here:

• specialist medical devices or patient sample handling equipment – see Vision Biosystems
• Very Early Smoke Detecting Apparatus = VESDA
• in wall cable tracing equipment – Aegis Trace All
• active RFID with long battery life, distance and unique ID – Protrac iD
• ultra low power mesh networking transeivers intended for battery operated telemetry – GreenPeak
• corrosion protection data logger – Borgtech CPL2
• cyclist indicator lights worn on your wrists – Safeturn
• medical training simulators – Medisius Epidural Simulator

I have been involved in all these areas and some of these are for projects I worked on or even ran.

So having looked at some examples, why do I think we should be excited about Niche Electronics Manufacture in Australia?

I touched on this briefly in an earlier post that addressed the question of Low Cost Electronics Manufacture in Australia Can We Compete?

I believe the answer is YES!  But we must be smart in how we go about it and we have to play to our strengths.  I see these as:

• highly skilled technical workforce
• world class software developers and embedded systems engineers
• good levels of capability and automation in PCB assemblers
• we like winning and overcoming challenges
• we don’t immediately do things the same as everyone else
• we have been doing this for a fair while now in spite of there being little government support or industry assistance
• a smaller Low Cost Electronics Manufacturer can be agile and tightly connected to their customers

So the challenge is actually a marketing one and not specifically a Product Development issue.  But once you have the opportunity identified, then there is no reason we can’t do it here.

Low Cost Electronics Manufacture in Australia makes good sense if you approach it the right way.

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.

________________________________________________