Embedded System Design: Challenges of Hardware and Software Development

What Are Embedded Systems?

Embedded systems are composed of both hardware and software, yet unlike personal computers or smartphones, they are tailored for specific functions or closely related tasks. These systems typically perform just one task, whereas a PC can handle multiple functions—programming, gaming, drawing, and more.

A typical embedded system consists of the following structure:

Therefore, designing embedded systems requires deep expertise in both electronics engineering and programming. Such projects necessitate the involvement of the following specialists:

1. Project Managers are involved in the pre-sales phase. If you reach out to Integra Sources, you can discuss your concept with them, as they possess the skills to provide a rough estimate of the project. They also oversee the work of the team on a specific project. For clients, PMs act as the primary point of contact within the development team.

2. System Analysts and Tech Leads are responsible for collecting and analyzing the requirements for the future system and conducting thorough project estimations. The tech lead also designs the architecture of the upcoming solution.

3. Embedded Developers are the frontline engineers who focus on designing printed circuit boards and writing software code.

4. Quality Assurance Specialists are tasked with testing the solutions under development.

To accelerate embedded system development, the team often works on hardware and software simultaneously. Nonetheless, for clarity, let's consider hardware development and embedded software design as separate entities.

Embedded System Design: Hardware Development

1. Requirements Gathering and Project Specification

Since Integra specializes in outsourced embedded electronics development, the ideas for new products usually come from our clients. Once our team joins a project, our initial task is to gather requirements for the future device:

• Functional requirements (what the system must do);
• Non-functional requirements: performance, scalability, security, size, weight, and other crucial features.

Customers without a technical background often find it challenging to outline the requirements for their products. They tend to emphasize marketing and functional aspects but lack an understanding of the technical feasibility of the project. Thus, the main challenge here is to conduct thorough interviews with the client.

It's also essential to avoid overpromising. If what the customer desires is barely feasible, our responsibility is to communicate the truth, explain why, and suggest viable alternatives.

Based on this information, the Integra team creates a project development specification—a document detailing the purpose, functions, behavior, and other requirements for the future device.

2. Technical Proposal

At this stage, the team drafts a document outlining the architecture of the future system and the solutions we plan to implement.

We also select components for the future device. The selection is constrained by the product requirements:

• Technical characteristics: power consumption, memory capacity, MCU performance, size, weight, etc.
• Operating environment: extreme temperatures, humidity, vibration stress, etc.
• Cost and quality of the components.
• Availability of the components (especially if the device is meant for mass production).
• Developers must strike a balance between the cost of the future embedded system solution and its performance.

3. Schematics and PCB Design and Layout

The device under development must not only fulfill its primary functions but also ensure safety and reliability. During embedded hardware design, the team addresses the following issues:

• The board design must strictly adhere to PCB design rules to ensure the device operates smoothly without issues for as long as possible.
• Proper attention must be given to heat dissipation, especially when designing a powerful device. This can be achieved through proper component placement, expanding the copper area, adding vias, using a cooling radiator, or other methods.
• Components we’ve never used before must be tested to verify they function as described in their data sheets.
• PCBs must be protected from EOS and ESD events, electromagnetic interference, environmental hazards, and other factors.
• If the embedded system is intended for mass production, we must follow Design for Manufacturing (DFM) principles.
• The board must be designed with certification requirements in mind (if the client wants the product to be certified).

Data sheets may contain errors and inaccuracies. Given the high cost of embedded product development, such problems must be identified before we spend the customer’s money. Furthermore, if the job requires a non-standard approach, we must ensure it will work for the given project. In such cases, the team might opt to build a proof-of-concept prototype first. Electronics prototyping allows us to validate an idea, check the functionality of components, and uncover various issues at an early stage of embedded development.

Prototyping may involve creating not only PCBs but also other system elements. During one of our projects, we were developing a computer vision algorithm meant to control a robotic manipulator. The model we ordered turned out to be shorter than the measurements provided by the customer, so the team had to fabricate a longer arm using a shaped metal tube and support elements printed on a 3D printer. This allowed us to test the algorithm.

4. Testing

Our team tests PCBs at every stage of the process. These tests verify if the board functions correctly and meets various certification requirements. Tests are carried out both during and after development to identify and eliminate all kinds of defects and issues before moving on to mass production. For more details, read our article on PCB and electronics testing.

Oftentimes, the team needs to create custom testing firmware to verify if the PCB works as expected. When the product is ready for mass production, we also develop factory testing firmware.

What Is Embedded Software?

Creating software is the other half of embedded system design. Unlike applications that run on PCs or smartphones, embedded software is tailored for specific hardware, meaning it can only run on the microcontrollers of special-purpose, non-computer devices. Programs controlling smartwatches, digital cameras, multimeters, or washing machines are examples of embedded software.

These programs are integrated into devices or machines to control them and/or perform a limited range of functions. Often, embedded software is permanently installed in devices—although nowadays it can be updated wirelessly (over-the-air, or OTA updates). It is stored in non-volatile memory such as ROM, EEPROM, or flash memory. Without it, the device would be rendered useless, becoming nothing more than a piece of metal and plastic.

Most embedded programs (except for embedded apps) do not have a graphical user interface (GUI). They are designed to interact with other software through external interfaces rather than with users through a GUI. If a program does have a GUI, it is typically used for configuring the program and outputting limited data (for example, the information about the device’s state).

The purpose of embedded software is to control a device by transmitting data between the hardware and higher-level programs.

Embedded software retrieves signals and data from the hardware. The program interprets them as commands and data sequences, used for creating various objects, and transmits them to higher-level software.

When embedded software receives commands and objects from higher-level software, it translates them into signals and data arrays and transmits them to the hardware.

An embedded system solution can have up to four levels of embedded software:

Firmware

Firmware is a type of computer program that boots a piece of hardware and provides it with low-level instructions. Operating systems and applications run on top of firmware. It is written in low-level languages (typically in C/C++). To let the device read it and execute the instructions, the program is then converted into machine code.

Embedded Operating System

Embedded operating systems are specialized software that control system resources. With drivers and APIs, an OS provides application-level software with access to the device’s hardware. Applications run on top of embedded operating systems.

MiddleWare

Some embedded software designs can include middleware. It’s a software layer between the OS and the application. Virtual machines are typical examples of middleware. A VM emulates a platform and executes a computer-independent code, thus making it compatible with different operating systems. For instance, programs written in Kotlin are converted to a Java code (application level) that, in turn, is executed in a virtual machine (middleware level) running on an operating system (OS level).

Embedded Application

Just like typical apps for computers, this type of software performs the functions of the embedded system and directly interacts with users. It processes data, interacts with other devices, and performs high-level functions. Embedded applications are written in high-level languages such as C++, Python, and Java.

An embedded system can incorporate firmware only or more levels of embedded software. Additionally, a solution may require desktop or smartphone applications to function properly. Our team can create all these types of programs for your solution, so give us a call to discuss the project in detail.

Sometimes, embedded applications, embedded OSs, and middleware are referred to as firmware, while the term embedded software is extended to include firmware and embedded software development tools. There is no uniform terminology for these concepts.

Embedded Software Development Tools

Developers use the following tools to create embedded software:

• Integrated Development Environments (IDE) are toolsets containing various programming instruments such as editors, compilers, debuggers, and more.
• Compilers and cross-compilers translate the code written in a high-level language into a low-level machine code.
• Debuggers help developers find and eliminate bugs.
• Linkers can combine different pieces of code and modules into a single executable program. Modern compilers have built-in linkers.
• Simulators and emulators provide simulated environments close to real-life conditions for testing programs.
• System configuration and code generation tools automatically generate code for configuring the hardware components of a device. They minimize manual coding and, therefore, error rates.
• Code suggestion tools are AI-based instruments that analyze the code written by a programmer and autocomplete it with contextually relevant snippets. They considerably speed up embedded system software development.

Disassemblers are used to reveal errors made by compilers. Sometimes, it is easier to eliminate errors at the assembler level.

Challenges of Embedded Software Development

1. Hardware Platform Selection

The future embedded software design can be roughly estimated when the team creates the technical proposal, as experienced developers can anticipate the hardware resources they can expect.

Of course, the team prefers more powerful MCUs with larger memory capacity. But if it’s not an option and we have to use a less powerful alternative, we need to analyze the project thoroughly to ensure we can implement all the features and optimize the code for this particular hardware.

Since embedded software systems interact with hardware (microcontrollers, sensors, buzzers, etc.), developers need to study the equipment before they start coding. The problem is that certain models may lack the necessary documentation or the data sheets may contain mistakes, inaccuracies, and outdated information.

One of our projects required a module that could simultaneously receive GPS coordinates and transmit data using GSM. The data sheet claimed the module was capable of both, but the device didn’t function properly during tests. The team contacted the manufacturer, and the company admitted that the module couldn’t perform both functions simultaneously. To switch between GSM and GPS modes, it needed to be rebooted. This fact was not mentioned in the data sheet.

This situation is not uncommon for cheap components. Contacting the developer of the hardware usually helps. Sometimes, the developer doesn’t respond, and the team has to analyze the hardware by itself. But these are usually simple components designed by small companies, so studying them is not too difficult.

The manufacturers of expensive hardware typically provide full information in their data sheets, but using them makes the final product more expensive.

2. Selecting a Programming Language and Operating System

The choice of programming language is determined by hardware and the type of software we want to create. For example, programs for Android-based devices are created in Java, while software for single board computers is written in C or C++. C is suitable for low-level programming, i.e., for programs that interact directly with the hardware. C++, Python, Java, Rust, and other languages are suitable for high-level programming.

Our team specializes in C/C++ development because a programmer experienced in C++ can use the Qt framework to create both embedded software and application-level programs. Although there are safer alternatives to C/C++ (e.g., Rust), our team is highly qualified and knows how to avoid typical mistakes of this sort. So, by entrusting your project to us, you save money because we don’t need to hire more developers specializing in other languages.

Devices that perform simple actions can function with the so-called bare-metal firmware that doesn’t require an operating system. However, electronics with complicated functions do need an OS.

Here developers have many options: Embedded Linux, Android, Windows IoT, RTEMS, and more. The choice is determined by several factors:

- project goal;

- available hardware resources; and

- development cost.

Powerful hardware can hold resource-demanding operating systems. For instance, writing software for Ubuntu won’t take much time but will require powerful and expensive hardware as Ubuntu has many services, drivers, and packages. Weaker hardware makes developers spend more time optimizing and customizing the code, so embedded software programming grows more expensive.

Our team prefers free operating systems because creating software for them is easier and cheaper. But we can also create programs for proprietary OSs if the customer insists.

3. Software Architecture Design

Before writing the code, developers think through the architecture (structure) of the future solution. The architecture includes software elements, the relations among them, and their properties.

Since we deal with different hardware platforms and are limited in resources, we can’t use a single architecture template for all projects. Embedded system design requires optimal solutions, so a universal architecture won’t work here. We have to pick from a number of architecture templates and customize them for each particular project.

Often embedded products under development are only a part of a bigger system. A project may also require developing application-level software that will interact with the device somehow. In theory, the team can design embedded software first and move on to other tasks after that. But to make the process faster, our embedded team creates a document that describes external interfaces and protocols for interacting with the programs so that the other teams can start their work as soon as possible. It’s a common practice that speeds up the process.

Sometimes, we create a mock service that emulates the work of the embedded program and generates synthetic data for the application-level software under development.

4. Coding

Once everything is settled, the team starts coding. The key difference between embedded software and application software development is that embedded programs don't have complicated logic. The true challenge is to make the software interact with the hardware and control it correctly.

• Lack of Information

Application software developers have access to numerous frameworks with ready-made solutions and vast amounts of information on the web. But embedded software developers create code for non-standard, heavily customized equipment. They need to understand how this particular hardware works, so they spend a lot of time studying data sheets and/or testing the hardware manually.

During one of our projects, the solution under development was supposed to send commands to MacBook computers via a USB port. The commands are represented by sets of bits, but Apple doesn't provide any information on this matter in official documents. So, the team had to search different forums to find the information.

• Data Security

Many embedded devices have access to the Internet. If they transmit sensitive data, the communication must be secure. Here we have a range of standard encryption methods. For instance, right now the Integra team is working on a medical device that transmits biometrics via the Internet. This kind of data must be protected. However, encryption raises the hardware requirements, so developers don’t use it when data carries no sensitive information.

• Memory and Performance Shortage

Embedded devices are getting smaller, while the performance requirements for them are increasing. Although memory shortage isn’t as critical today as it used to be, it is still a problem for embedded software development.

Power limitation is another typical problem for battery-powered devices. The work of its software must be programmed in such a way as to minimize electricity consumption. To do so, developers can reduce the number of instructions for the processor core. Another way is to put the processor core to sleep mode until an outside event (such as timer interruption) occurs. We mentioned both these techniques in our article devoted to firmware development practices.

• Stability

Although software can’t “break” like hardware components do, it can still crash. Most of such problems are caused by incorrect memory access.

Here is a typical example. Process 1 calculates a variable and puts the value into a memory cell. This value is required by Process 2. Since the two processes run in parallel, Process 2 may access the memory cell before Process 1 calculates the value, which causes a crash.

When coding, developers must foresee such situations and give processes proper instructions—for instance, instruct Process 2 to make sure Process 1 has calculated the value before using it.

• New Requirements

Sometimes this phase becomes challenging because the customer decides to extend the functionality of the device or wants to change the requirements for the project. The hardware platform chosen at the preparation phase may not be sufficient for the new features, and the team may even be forced to start over.

• Optimization

Software optimization plays a huge role in embedded system design as we are always limited in resources. Programmers can make software fast but memory-intensive or vice versa—memory-friendly but slow. Modern compilers offer many types of optimizations so that developers can find a balance between these extremes.

5. Testing and Debugging

A typical application can be tested on a computer, but embedded software is designed for devices and equipment. So, developers need a fully featured test station or even field trials. QA specialists have to be very resourceful.

For example, when working on the aircraft towing system, the team had to test the distance-measuring module somehow. Our QA specialist designed and created a special stand with a 3D printer. The module was fixed on the stand, while the stand was attached to the hood of a car with a magnet.

Sometimes we need to develop software for a device that we don’t have—for example, if it’s too heavy to transport or when we design a PCB for a larger system. This makes testing even more difficult.

In that case, the customer can install TeamViewer or a similar solution on a computer and connect the PC to a camera and the device under test. This way the team can connect to the PC to give commands to the device and see what’s happening through the camera.

Applications are usually standalone products, while embedded programs always interact with hardware. When an error occurs, it’s difficult to tell whether the problem was caused by hardware or software—especially during field trials when the testers are limited in diagnostic tools. The only way to see if the software is working properly is to upload logs to a connected laptop in real time.

As for hardware, QA specialists use oscilloscopes, voltmeters, multimeters, and other tools to check if the PCB and its components are working properly.

Our team designed a device consisting of a single-board computer and two PCBs. The SBC was supposed to send a heartbeat package to one of the boards to confirm it’s still working. If the PCB did not receive the package, it was supposed to reboot the computer automatically, which the board did all the time during tests.

The team checked the bus with a logic analyzer and confirmed the SBC sent the correct signal, which proved the problem was caused by the firmware of the PCB that didn’t process the package correctly.

If the device fails due to an equipment defect, the team can fix it “manually” instead of manufacturing a new PCB, which would raise the development cost.

Conclusion

Embedded system design is a complex process involving numerous steps and requiring professionals skilled in both electronics engineering and embedded programming. The team faces many challenges at each phase, from requirements gathering to testing. Moreover, to speed up the process, hardware design and embedded software development must be done in parallel.

Integra Sources is a cohesive team with extensive experience in embedded electronics development. We know what challenges to expect at each step and how to address them. Don’t hesitate to contact us if you need help with your project idea.