EMBEDDED SOFTWARE CHALLENGES Challenges of Embedded Software Engineering
Embedded software development has always been challenging, because it requires knowledge of the software’s target hardware. This challenge has grown as engineers must increasingly include connectivity, security and now, artificial intelligence capabilities. Here, we look at the issues and possible solutions.
While a PC’s applications software is insulated from the details of the hardware design by the operating system, the situation is not so straightforward for embedded software implementations.
Embedded software is so-called because it is embedded into a host product - camera, laser printer, robot or, increasingly, any other electronic or electromechanical item – and is dedicated entirely to controlling its host. It monitors input devices like motion sensors or cameras, and responds with outputs to actuators such as motors or lights in real time. It is constrained by a set of key characteristicsi :
- Requires real time performance
- It should have high availability, reliability, and stability.
- Usually, diskless operation, ROM-based
- Designed for one specific task
- It must be connected to input and output devices
- In the IoT age, usually has connectivity as an IoT device
- Minimal user interface: humans do not directly control all embedded software functionality
- Limited memory and space, low cost, lower power consumption – to maximize battery life and/or minimize cooling load.
Within these constraints, a device’s embedded software must include components to deal with low level tasks like driving a display, converting analog sensor signals to digital data, and managing communications protocols. Above these are the applications modules, which together allow the device to perform its role, such as printing a document or operating as a delivery robot.
While various approaches are available, writing embedded software that meets the above criteria calls for engineering skills, particularly knowledge of the low-level hardware, not needed when writing applications code for a PC operating system environment. Below, we look at the challenges involved, and some possible solutions.
Firmware or RTOS?
The first challenge is how to implement the low-level software components. You could code these directly in-house; such software is called firmware. Alternatively, you could use a commercial real time operating system (RTOS). The choice depends on several factors, particularly the device’s complexity and the number of devices you intend to manufacture during full-scale production.
Firmware can be very time-consuming to write, test and maintain, and can stretch your available software resource in terms of time, cost, and expertise availability. However, the code is efficient, focused, compact, and does not require a per-unit license fee. By contrast, an RTOS usually carries license costs, and is more general-purpose and memory-consuming. However, it will allow you to focus far more quickly on the higher-level applications coding that will give your product its distinct and competitive edge.
Therefore, a low-volume, complex product would almost certainly benefit from an RTOS, while a high-volume, simpler device may well justify the upfront cost of firmware development.
Whichever route you choose, however, you will find that modern users’ expectations will place further challenges on your development resource. System complexity is sharply increasing, while IoT connectivity is increasingly mandatory.
Connectivity and security
Providing connectivity adds to the design workload, because there are so many choices to be made. You could connect through WiFi, Ethernet, cellular, LoRa, a Bluetooth bridge, and many other sourcesii . Each has its own advantages and disadvantages along with different software stacks that you need to learn and understand to ensure that the hardware works. Then there is the question of which protocol to use, or whether to use multiple protocols. Even if you bring in a software stack or an RTOS, you still need enough understanding to make modifications or solve any problems arising.
If the device is connected, then users will probably also expect over-the-air updating as part of its functionality; this performs remote firmware or software updates automatically. However, for this to happen, you need to generate a firmware update job, and determine when it is appropriate to update a device. Then you must secure your updates, validate that they are coming from a trusted source, and be able to roll back an update if an issue arises.
Unfortunately, connectivity makes your devices visible to bad players on the internet as well as the intended recipients of any communication – and security threats are ever evolving and becoming more sophisticated. This calls for careful thought about how the system is partitioned and isolated, and what information needs to be protected. Appropriate security levels depend on the type of device and its application.
Debugging and complexity issues
As connected devices proliferate, complexity increases. This means that the amount of time spent debugging will most likely increase as well, especially if the various systems and software packages used have not been designed to work together in the first place. Embedded surveys have shown that developers on average already spend 40 % of their time debugging iii. Therefore, it is important that you understand all the debugging techniques available to you, and how to prevent bugs in the first place.
The above challenges are also exacerbated by the rate of technology change. Hardware continues to evolve, while whole new functionalities open up – not just IoT connectivity and security, but also artificial intelligence and machine learning applications. This calls for a pool of knowledge and great expertise which continuously develops, in an environment where good embedded software developers are relatively scarceiv . For any technology business, losing complex engineering expertise can be costly as, more often than not, the knowledge will leave with the engineer.
One way of alleviating the pressure on embedded software developers can be to use an RTOS; however, as we have seen, an RTOS does not provide the most technically efficient or cost-effective solution for all projects.
Another approach is to partner with a software company that can work with you to identify where extra effort or skills are needed, and supplying engineers when required. Such a partnership can be successful if the company can demonstrate expertise in developing and testing software, experience in working with and to customers’ requirements and timescales, and the resources to carry out projects successfully.
iEmbedded systems tutorial