Archive for April, 2015

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