How to optimise interconnected HMI system designs

There are billions of intelligent interconnected devices nowadays populating what has become known as the Internet of Things (IoT). Since these IoT devices are all embedded systems, they need to be developed with the same rigor, design considerations, and device selection criteria as any other embedded application. Product requirements vary dramatically and can quickly become complex, demanding the real-time responsiveness, scheduling, and interrupt support of a Real-Time Operating System (RTOS). Some specifications call for the flexibility and usability of consumer-friendly user interfaces (UI) on products in industrial, automotive, and even medical segments. To successfully bring a system with these capabilities to market, it behooves the designer to use a software design ecosystem and microcontroller (MCU) or microprocessor (MPU) that are highly integrated and optimised for human-machine interface (HMI) functionality.

Choosing a software design framework
Quite often, the first question the software team faces when approaching a new project is whether to use an operating system or not. There are pros and cons to each approach. The cons include: a somewhat larger software footprint; having to learn a new event control mechanism and API; the cost of the RTOS; and, depending on the use-case; more CPU overhead (although an RTOS may actually reduce footprint and/or overhead in cases where a complicated polling loop is required). For systems with even moderately complex graphical interfaces, however, the pros generally far outweigh the cons. RTOSs provide a completely validated and integrated code base with hooks to all kinds of middleware for communication and storage plus graphics libraries. This reduces design risk considerably. Using an RTOS can also make it easier to achieve compliance with regulations for functional safety, among others, because the vendor takes care of certifying large parts of the code base.

Programs with RTOSs also scale well with complexity; whereas programs that use a "polling loop" do not. Put another way, as you add or remove code within the polling (i.e. "while {}") loop, the round-trip time of the main program changes, and this alters the entire system's performance profile. RTOS-based systems, by contrast, are partitioned around multiple tasks (or "threads")—each of which provides event-driven responsiveness, pre-emptive capability, and deterministic latency—and are scalable by design. If you want to add or remove functionality, simply add or remove another task from the program; the program timing should remain the same. Thus, an RTOS actually has the potential to reduce CPU overhead.

RTOSs are also well suited to implementing the model-view-controller (MVC) HMI design pattern. The MVC approach separates the display logic from the application logic, which improves collaboration within teams. Non-HMI sections of code, like complex communications streams—TCP/IP, USB, file systems, etc., can be encapsulated away from the main application in separate program threads. This keeps the code clean and organised. The interfaces between the threads can be formally defined using standard RTOS constructs such as messaging, event flags, and semaphores. Not only does this enable a highly systematic design flow, which allows the designer to quickly converge to working software on his or her own block, but it makes it easy to prioritise events and to manage shared resources.