Embedded Software IP & Technology Transfer in Power Electronics Applications

Embedded software: sourcing specialized interfaces

When designing an electrical equipement product, you typically have the following sub-systems to design and integrate together:

  1. mechanical (a box)
  2. electrical (the wires to inteface with grid + load and power electronics)
  3. the electronics (driving the power electronics + human-machine interface + communication interface)
  4. and the software that runs on the electronics.

For (1,2,3), there are a lot of standard/COTS products available so that you can quickly have a prototype ready using those components (while there is still innovation going on in each of these areas). However, for (4), this is less obvious and knowing that embedded software costs amount for a large part of electronic product design (>50% according to PwC), it has to be carefully planned.

Splitting software into components

Software inside an electronic product can be split into 3 important components: (1) commodity interfaces, (2) specialized interfaces and (3) application software (that may or may not run over an OS) – see image below (taken from my ebook on custom electric motor drive design).

Commodity interfaces are typically packaged with your chip bundle of tools or available at a very low price, unless you are using something that’s not standard. Applications software is the software that is specific to your product (a robot, a drone, a medical device, etc.), i.e. “your sauce”. Then you have the “specialized interfaces”: middleware/drivers meant to work with a “complex” peripheral like a power stage or a camera. Those drivers typically contains very “domain-specific” functions that need advanced knowledge and expertise to be developped.

This is where it becomes tricky because you need to source those interfaces from somewhere: i.e. (1) develop them ‘in-house’ or (2) get them from a third party IP provider. The sourcing of the specialized interface is influenced by available time, budget, talent and also the type of product you are developping:

  • In house development of specialized interfaces can be an option when you have the expertise and when the product value is highly defined by this interface, e.g. a standard industrial motor drive.
  • Third party IP sourcing of specialized interfaced can be an option when your firm do not have this specific expertise in house and when the product is not highly defined by this interface, e.g. a medical device equipment.

Either option may also be influenced by the pressure on anticipated costs/profits and time of development of your product: the higher the pressure is on costs and time of development, the higher the benefits of leveraging third-party IP sourcing (if available and making financial sense against in-house development).

However, the lines get blurred when ones uses a “reference design”. Those reference designs typically come from a third-party (chip vendor) and are a great start for a project. However, it is important to know that a reference design is not an IP: you need domain expertise to use them otherwise you may get troubles, especially in power electronics applications. This topic is so important that I will make it stand as a future blog post shortly. Stay tuned!

Speak Your Mind

*