Firmware Design Patterns in Embedded Systems
Date: Aug 15, 2018
Introduction
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:
- At home, embedded systems can be found in toasters, kettles, washing machines, dishwashers, food processors, televisions and more.
- In the telecommunications field, examples of embedded systems include network routers and modems, low power wide area network enabled sensors, cell towers and of course the mobile phone.
- The medical field has x-ray generators, ECG monitors, MRI scanners, even the hospital beds have embedded systems.
- Embedded systems can be found in the science technology field with electronic microscopes, oscilloscopes.
- Your car is also made up of dozens of embedded systems, ranging from electronic speedometer, ABS, power steering, car alarm, air conditioning and just the general heads up display.
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.
Embedded Firmware
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:
- Throughput
- Reliability
- Cost
- Availability
- Maintainability
- Flexibility
- Responsiveness
Design Patterns
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:
- Observer pattern: Also known as the publish-subscribe method. It is a method which allows data to be shared to multiple elements and makes it easy to add more elements to share the data. Thus the system becomes more flexible.
- Hardware proxy pattern: Elements specifically responsible for accessing certain hardware. These make it easy to update firmware when changes in the hardware design are made. Again, this increases the flexibility of the design.
- Interrupt pattern: Used to pause what its currently processing and handle events as soon as they happen. This in turn increases the Responsiveness.
- Queuing pattern: Uses queued messages to share information among multiple processes.
- Rendezvous pattern: Synchronises 2 or more separate processes.
- State pattern: Implements a state machine inside firmware.
- CRC pattern: Verifies data which makes the system more reliable.
Observer Pattern
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.
Summary
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.
References:
- Retrieved from https://pdfs.semanticscholar.org/a312/430dc5a54a1cae78e19f06c3ffa8509015a7.pdf
- Photographic images retrieved from https://www.pexels.com
- Photo by Mikes Photos from Pexels - https://www.pexels.com/photo/audi-vehicle-interior-1009871/
- Photo by Torsten Dettlaff from Pexels - https://www.pexels.com/photo/space-gray-iphone-6-193004/