Date: August 15, 2018
This article discusses firmware development in embedded systems, specifically common design patterns implemented today. The article defines what a design pattern is, why it should be used in firmware development, and outlines one of the more popular patterns used in embedded systems today. However, this will not go in depth into any one specific pattern and rather touches on some popular ones. To be able to do this we have to first define what the terms "firmware" and "embedded systems" mean.
An embedded system is a "computerised system dedicated to performing a specific set of real world functions, rather than to providing a generalised computing environment" [1]. It consists of a combination of (electronics related) hardware and software (known as firmware). In fact, most of the products we at Beta Solutions design are considered embedded systems. These systems might be a standalone device or form part of a larger system. Embedded systems can be found in a broad range of places:
Figure 1: Examples of Embedded Systems
So you can see embedded systems make up a large part of everyday life. It is likely that the average person interacts with over 30 embedded systems every day.
Simply put, firmware is a type of software specifically written for embedded devices.
The vast majority of electronic devices today include some form of programmable componentry - usually in the form of a micro-controller. The firmware is the brains of system - telling the hardware what to do and when to do it. eg: "Read" the value from that sensor at exactly 08:15:00 and "if" the value of the sensor is 0, "then" turn on the error light. It is the firmware that communicates directly with the physical world via the electronics hardware.
When it comes to designing an embedded system there are inevitably a considerable number of design considerations and constraints. For example, hardware considerations include: size, computing power, thermal distribution and EMC - to name just a few. What about considerations for firmware?
Well, unlike computer/smart phone software, which are regularly popping up with “software update” messages, it is much more difficult (or impossible) to update the firmware in embedded systems. Ultimately this means that the developer has to get the firmware code ‘right’ before the device enters production. In short - design considerations for firmware are immensely important.
Performance constraints, for instance, are heavily considered and different systems will have different performance requirements. For example, the ABS braking system in your car - for obvious safety reasons - is critically required to be a highly responsive system. Other systems may value accuracy over responsiveness. Accuracy is an example of a quality of service constraint. Other examples of quality of service properties include:
A design pattern is a term used in the software development community that means "a generalised solution to a commonly occurring problem". A design pattern's purpose is to be a template for a firmware programmer when developing a system. Any one design pattern can be used in any programming language and is not restricted by the field in which the system is being designed for. (Note: If the pattern was specific to a certain field this would be considered an analysis pattern. An analysis pattern is problem specific, where as a design pattern is driven by the quality in which the system performs its requirements.) One system may have multiple design patterns implemented and often do.
A developer’s goal is to use a design pattern to optimise one, or a few, of the important systems quality of service properties at the expense of others. A good developer will pick a set of design patterns that optimises the important properties while keeping the properties of others to an acceptable level.
Popular design patterns used in embedded systems are listed below:
The observer pattern is a popular pattern in event handling systems. That is a system which monitors multiple inputs and may display these for the user in some way and/or respond by initiating some actuators. It's called the observer pattern because a subject (data object from input sensors) has a number of dependents which observe the subject for changes and react accordingly. In reality the subject will notify the observers when it has changed.
The observer pattern optimises the execution efficiency and flexibility of a system. It is flexible as it makes it easy to add more subjects and more observers to those subjects. The pattern is execution efficient, as all relevant observers are only notified when needed so not to waste processing time.
A nice example which demonstrates an observe pattern is in a car alarm. Car alarms can consist of a range of sensors, but let's look at a typical example. A car alarm that has three sensors to detect thieves, a control panel so the owner can arm and disarm the alarm, and three actuators that act as alerts. The actuators are observers to the sensor data. Using an observer pattern here makes it easy to add more observers without having to change the subject’s code.
Figure 2: Possible firmware architecture of a car alarm.
In summary, a design pattern is used by a software developer as a template to build part of an overall system. Most embedded systems will use more than one of these design patterns in practice and these should be chosen to fit the quality of service requirements of the overall system.
Figure 3: Beta Solutions Engineer writing signal processing firmware.
At Beta Solutions, our experienced embedded electronics engineers have the skill and proven track record to use the best suited firmware design pattern for our clients' products.
You can get in touch with us to discuss any idea you have in mind via our contact page or give us a call.