Giving the best UX by design

Getting something right at the start, or ‘by design’, is much more cost effective than trying to change something after the fact. That’s particularly true for embedded development; it’s why requirements and specifications are so important.                                           

From System thinking to Design Thinking: when embedded devices focus on user experience
Specifying something based on expectations can be a costly mistake. Take embedded software, for example. The sheer number of lines of code needed for a typical embedded application today means that most OEMs will start from a platform, such as an operating system and associated middleware. This is, of course, an excellent way of cutting development time and costs. But it doesn’t guarantee an optimal result.

One of the most obvious symptoms of a sub-optimised design is in the user experience, or UX. This can often manifest itself as slow, unresponsive menus, of a noticeable delay between a user action (pushing a button, swiping a screen and the expected result. An unresponsive user interface can be caused by any number of design issues but whatever the cause, the effect is the same; an unsatisfied customer.

Performance is an intrinsic product of how the hardware and software are integrated. When using an open source operating system such as Linux, or a commercially licensed OS like QNX it may be inferred that the software is already optimised for the target architecture. In general, this would be the first mistake.

Optimisation starts with understanding fully the features present in the target hardware; many SoCs, even those based on the same CPU (such as ARM Cortex-Ax) will feature different hardware features. Making the most of those hardware features will require a solid requirements specification and a firm understanding of the performance trade-offs between hardware- and software-based features.

Partitioning functions in this way will also depend on the number of cores present in the target SoC. Many devices, even those designed for embedded applications, feature multiple processing cores. It may be possible to virtualise multiple operating systems across those cores, but at the very least it is necessary to include some level of multicore task scheduling.

More complex the applications will also have a greater potential of demonstrating performance issues. Interpreted languages can present a bottleneck in terms of throughput, as can excessive read/write operations to a database. These are just some of the design considerations that can impact performance.

Ensuring a responsive system is potentially much simpler today thanks to virtualisation technologies and the availability of higher performance single-core and multicore SoCs. For single-core solutions, optimising the kernel at a very low level can help deliver the highest possible performance. By adding virtualisation, two versions of the kernel can run on the same core, allowing those functions that must deliver high response levels to run separate from other less critical tasks. With multicore solutions virtualisation steps up a gear, allowing multiple instances of the kernel to run on their own CPU. This clearly delivers higher responsiveness and can even be extended to running different operating systems or software frameworks on separate cores.

But even at this level of separation performance bottlenecks can occur, not least due to the interprocess communications that may need to take place between cores. Using performance analysis tools can help identify these bottlenecks, allowing them to be resolved.

One step beyond: Market specific design thinking
Performance and responsiveness will mean different things depending on the end application and the platform; an industrial robot will have different priorities compared to a set-top box, but both may be based on Linux. Identifying the exact requirements and then taking measures to ensure those requirements are met is fundamental to delivering the right user experience.