This is a 6-part series.
To Read Part 1 – Vaporware Wars – Go here.
To Read Part 2 – How Products are Chosen for Development – Go here.
To Read Part 3 – Product Development – Investigation – Go here.
To Read Part 4 – Product Design, Part 1 – Go here.
Almost every electronics product being built today requires some sort of software. Software is the most complex part of the product, because it is so open-ended and subject to feature-creep during the development process. That is why tightly defining the feature set is critical during the product definition stage.
While the software team is involved from the beginning of a new product design, their workload increases once the electrical design is finalized. It’s challenging for them to write and test code without having final hardware. Yes, they will use simulations, but I cannot tell you how many times the real hardware has acted differently from the simulation – or what was promised when the code writing began. As an integrator, you experience this with every control system you install. There is a certain amount of programming you can do in the office, but the final code gets written at the customer’s site once the hardware is installed. There always seems to be some variable that doesn’t appear until then.
A detailed description of software development is far beyond the scope of this article. Suffice it to say, that the critical decisions start early, and run late into the project, and early software decisions can profoundly affect the hardware design. For example, if the software team wants to use an I2C bus (https://en.wikipedia.org/wiki/I%C2%B2C) for internal communications, all the selected components must be able to support that bus. Additionally, that bus type requires shielding and balanced lines (the paths for the different parts of the signal must be the same exact length).
There are two basic types of software – system level or embedded software (also called firmware) and application layer or user interface software. Now, before the code jockeys go all nuts and start sending me nasty e-mails, I know that is a big simplification. But it works for this purpose.
Embedded software controls internal functions, and is not directly accessible by the user. It usually operates in an environment specific to the hardware and is stored in persistent memory (memory that stays intact even when the device is powered off).
Application layer software is the operating system of the product and manages its overall operation. This is the software level that accepts inputs from user actions, makes decisions about what actions to take, and outputs information to the user.
The User Interface, in today’s world, is typically a graphic display with a dashboard of information for the user, but can be as simple as a single LED. Every aspect of that LED is scrutinized – Where will it be located? What color? How bright? Does it flash? How fast?
Graphical User Interfaces (GUI) are even more complex. Every aspect of every object in the GUI must be defined in detail, including location, size, shape, color and function. That’s a lot of decisions to make and there must be a consensus of engineering, software, marketing and most importantly, customer feedback.
For products that require a mobile device interface (phone or tablet) those applications must be developed. And the GUI must be designed for each size and shape of device – phone, tablet, PC, etc. The finished applications must then go through approvals for the device and be uploaded to the relevant sites for customers to download.
With today’s complex products, software is both the biggest challenge and the biggest opportunity. Features can be added or adjusted at lower cost and faster than making hardware changes. That leads many to increase features and increase complexity. It’s sometimes difficult to make the decision to ship now and add a feature in the next update.