Archive for the ‘ELMG Redux Series’ Category

Partitioning Digital Power Development – key to success in digital power

Wednesday, April 8th, 2015







Partitioning is critical to product development.   And even more critical is partitioning digital power development where the team’s skills required do not fit into the traditional hardware software split.  This post was originally published in 2010.  It is re-run here as part of the ELMG Redux series.

Developments run smoothly

Ever been in a company or on a project where things just seemed to go right? Where the software fitted with the hardware easily and the code was manageable? Or worked with some one who seemed to have fixed your problem before you realised you had it? Or met a marketing or product management person who always specified product that sold really well?

What you saw was probably the result of accurate, timely and suitable partitioning. It is entirely possible that you did not even notice that partitioning was being done as not all companies have realized the value of formal or semi-formal partitioning.

Partitions and interface specifications

So what is partitioning? It’s dividing up the problem or project into smaller parts that can be individually specified and that fit into the organizations strengths and available resources. It is also managing the interfaces between the partitions.

Should I partition?

All product developments can (and should) be partitioned. If you consider an embedded system project a suitable partition may be into separately specified hardware and application software. An interface specification that is common to both the hardware and the software then allows the hardware and the software to be developed concurrently. Each of the hardware and software partitions may then be further partitioned by function, complexity or, and this is an important point to realise, by the development team members’ individual competence.

The hardware/software partition – classical appraoch

In the case of an embedded system the hardware drivers or hardware abstraction layers are effectively the bridge between the hardware and the application. These drivers and hardware abstractions are often badly specified and often not given the development resources needed. The people who create the drivers are critical to the success of the project. Having management that knows the drivers are critical is the key to getting the project out on time. Managers also need to know that it is possible to design hardware that makes developing the driver very difficult or impossible.

Partitioning digital power developments – do it with the team in mind

As another example consider a digitally controlled power electronic converter (DCPEC) in which case the partition may not be as clear cut as with an embedded system. Consider partitioning digital power developments into hardware and software and then allocating the hardware to an electronics engineer and the software to a software engineer without considering whether the hardware or software engineer actually has the skills to perform the underlying task. At this point I can hear people saying that when they work on projects they cannot tell how they should partition the project and so don’t. This is an extremely risky approach as without some sort of partition it is not possible to assess and therefore manage the development risk. Any attempt at a partition or reduction of the problem complexity will provide insight to the risk and best project path. It is the process of partitioning the project that generates this insight.

Digital Power Partitions

But back to the DCPEC – the typical partition for the project by function may be

1) Power converter hardware
2) Digital controller hardware
3) Software
4) Interface specifications.

The partition by competence in the team may well go along these lines.

Team member 1 – Power converter software control algorithms, EMC, and power converter hardware design.

Team member 2 – Digital controller hardware.

Team member 3 – Software coding.

This is a partition along functional and team member competence lines and best way for the partition to be organized is by the development team itself. Perhaps one of the easiest errors to make as a manager or team leader is to force the partition onto the team rather than let the team partition the project.

If you or your organisation are undertaking a power electronics project, contact us to find out how ELMG can help.

Contact Us

One simple step to improve software engineer productivity 200 percent

Friday, January 30th, 2015

This article was originally published in 2009.  It is part of the ELMG redux series of articles that will be republished over the summer.  Some additional material has been added.   These articles cover subjects in and around digital control of power electronics.

“A room without a book is like a body without a soul.”

Gilbert Keith Chesterton

“A software engineer with a notebook used to be hardware engineer”

R and D Manager (anonymous)

Engineering documentation made easy.

How many of your company’s software and firmware engineers use notebooks to record their work? Does your company require that they have one? Is there a company wide recording system for engineering decisions?  Are all issues tracked and resolved?   Does the company require that they use the notebook as part of reviews and walk throughs?

Follow the ELMG DigitalPower Blog >>

Ever noticed that hardware engineers have note books but software engineers don’t?  One software engineer told me that he did not need a notebook because his code was in subversion.  When I asked him about how he documented the design of the code he just shrugged and said “The code speaks for itself”.  Unfortunately for him and many software engineers poor code quality speaks louder.

A simple solution

We use Jira for issue and task tracking, Confluence for documentation and also have project notebooks.  The first two of these systems are software as a service.  The third is a red hardcover book.

Recently we have started to use OneNote from Microsoft and it is really effective.

Typically software engineering teams are more productive if some sort of personal recording of work progress is encouraged and enforced. Jack Ganssle’s recent article On Engineering Notebooks (seriously that is what the article is called) at is a timely reminder.

Jack’s article describes the usefulness of notebooks as a record to be looked back at.  When we write in our notebooks we are writing to our future selves.  All to often we repeat mistakes and cannot remember what we did six months or five years ago.

Follow the ELMG DigitalPower Blog >>

Only you can prevent power converter fires.


Digital power more often than not has software in direct control of the gate drive signal of the power converter.  This means that a software coding error can cause the destruction of the power converter.  The same software coding error causes a blue screen of death on a PC or a scrolling glitch on your smart phone.  In the case of a power converter the explosion may well cause a fire.

This explains why software for digital power is absolutely mission critical.  Often the software for digital power is also safety critical.  And so we take any opportunity to improve the quality of software.

Follow the ELMG DigitalPower Blog >>

Steps to improve software engineer productivity 200 percent

  • Traceable requirements as per IEC61508 or UL 1998
  • Enforce coding standards
  • Jira for issues tracking
  • Code walk throughs
  • Code reviews
  • Automated tools such as Lint
  • and writing in a hard cover notebook.

Adding process improves productivity?

So how does this addition of all these overheads improve productivity?  The short answer is that debugging is reduced to a tiny amount of time.  Jack Ganssle has collected lots of information on what improves embedded software.  One of the most effective first steps to improve software engineer productivity 200 percent is writing stuff down in a notebook.

Get 200 percent increase in software engineer productivity.  Contact us here.

Safety Critical Digital Control – Planes in Fog

Wednesday, December 24th, 2014

Safety critical digital control for airplanes in fog

This article was originally published in 2010.  It is part of the ELMG redux series of articles that will be republished over the summer.  These articles cover subjects in and around digital control of power electronics.

Redux – Safety Critical Digital Control – Planes in Fog

Just before Christmas 2006 I spent sometime (24 hours) in Copenhagen Airport as I waited for my plane after doing a week of meetings in Southern Sweden. I very nearly had a forced stopover in London at Heathrow as London fog shut that airport.  This stranded almost eighty thousand people who could not go on their holidays.

My connecting flight into Heathrow was cancelled due to that very fog in London. As a result I did not ever get to London and so I missed my connection out of London. Luckily for me I was re-routed the next day directly through Hong Kong missing the crowds of delayed passengers at Heathrow.  Thanks to all those that helped me.

Copenhagen Airport

As I waited at Copenhagen I thought about a number of things

  1. The large numbers of people at Heathrow and how their holidays would go? My sympathy to all the people who were delayed in Europe at or around Christmas time.
  2. Why, if an airliner can land itself at LAX in perfectly good weather, can an airliner not land itself in London in the fog? The pilot on my last flight to LA informed the passengers that the plane we were on would land itself at LAX. I cannot verify whether the plane did or did not land itself but we did get down safely.
  3.  What would my pre-school age daughter say if I did not get home for Christmas?

So if the plane can land on a sunny day in LAX why can it not land in the fog at London?

The guidance system on an airliner is an safety critical digital control system. It takes inputs from various guidance sensors (like GPS and inertial guidance) and produces outputs for the control surfaces like the elevators and ailerons. As such it will be a mixture of hardware and firmware  software. The program code is most probably written in a safety critical digital control useful language (not C) such as ADA. The method to write the software is (hopefully) well defined and the code is well inspected and walked through. The guidance system is then certified along with the aircraft by the FAA and other suitable safety authorities.

A Sunny Day in LA.

So let me say that again – on a good sunny day in LA my pilot can let the machine land itself but in London my plane cannot land because of the fog. I thought about why this was and even asked a friend. He said that it was “All because of the labour unions” which I hadn’t even considered. I decided that it may well be something else. Labour unions may have something to do with it but I don’t have time to write about that.

Critical Failure Modes Analysis

Consider the failure mode of the plane landing in Heathrow in the fog. If something goes wrong with the part of the guidance/landing system that takes care of height, then the airliner hits hard into the runway and makes a mess. Consider the same failure mode in the good weather at LAX. The plane is at the wrong height and would dive into the runway. Instead the over riding backup system looks out the window and takes control of the plane.

Safety Critical Digital Control on a plane needs a Pilot

So here is the skinny – it is OK for the plane to land itself so long as the backup override system is working. This backup is the pilot and so long as she isn’t struck down by food poisoning and she can see the runway she will not let the plane crash.

I am glad my flight to London was cancelled.

There have been incidents where the pilot has attempted to stop the plane crashing but the embedded systems in the plane have refused to help out. That, though, is something for another time.

Since this article was written safety of airliners and their safety critical digital control systems has come into sharp focus. Apologies and condolences to all and everyone who have been touched by the failings of digital control systems in the airline industry.