Casey Business Awards Finalist

Casey Business Awards

The City Of Casey are holding their inaugural Casey Business Awards and at the Casey Business Breakfast this morning Successful Endeavours were nominated as finalists in two categories.

 

Casey Business Awards

The two Casey Business Awards categories are:

  • Manufacturer Of The Year
  • Business and Professional Services

We fall into the Business And Professional Services category with our Electronics and Embedded Software development services where we design products for Australian Electronics Manufacturers so they can achieve Low Cost Electronics Manufacture in Australia at a good profit margin.

The Manufacturer Of The Year award category recognises that for some of our clients, we also manufacture the product the product and delivered to them programmed, tested and calibrated; ready to sell. This includes products like a DNP3 enabled power controller product for the US Smart Grid market which is made right here in Berwick as well as the Award Winning Borgtech CPL2 Corrosion Protection Data Logger with Wireless Data Logging.

It was an honour to be recognised by our city council together with other small business owners in the City Of Casey, a municipality in the outer south-eastern suburbs of Melbourne. We will find out who the winners are on Friday 27th August at the Casey Business Awards gala dinner.

 

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.

Green Electronics Strategies – Reducing Power Consumption

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 its 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.

 

 

Electronics Design and Embedded Software Capability

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:

 

Continue reading

Electronics Manufacture Shines in Melbourne

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 Narre Warren which is administered by the City of Casey.

 

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 life cycle. 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

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 sounds 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.

________________________________________________

Reducing Electronics and Embedded Software Product Development Costs

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

  • Software typically consumes 80% of the development budget. Digital Avionics Handbook and Embedded.com
  • 80% of software projects are unsuccessful IBM

 

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 budgeted 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 inspection 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 walk through 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.

 

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! 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 subsystem 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.