Embedded System Design: Challenges of Hardware and Software Development

What are Embedded Systems?

Embedded systems consist of computer hardware and software; but unlike personal computers or smartphones, they are designed for a specific function or a set of closely related functions. They typically perform only one task, while a PC can perform various tasks – programming, calculating, drawing, gaming, etc.

A typical embedded system has the following structure:

Embedded system developers face fundamental issues in hardware-software co-design. Both parts must be created together so that the product works properly and meets performance, reliability, security, and cost requirements. It is important to consider the entire system during the design process to achieve optimal performance and reliability. Software cannot be developed without taking into consideration available hardware resources, while hardware components cannot be selected without regard to software functions that must be implemented. 

Overcoming various hardware-software co-design challenges requires deep knowledge of both electronics engineering and programming. Such projects require the following specialists: 

1. Project managers participate in the pre-sale phase. If you contact Integra Sources, you can discuss your idea with them as they have the necessary skills to make a rough estimation of the project. They also organize and supervise the work of the team on a particular project. For customers, PMs are the main contact person in the development team.

2. A system analyst and a tech lead are responsible for collecting and analyzing the requirements for the future system and thorough project estimation. The tech lead also designs the architecture of the future solution.

3. Embedded developers are front-line layout engineers and software engineers responsible for designing printed circuit boards and coding programs. 

4. QA specialists are responsible for testing solutions under development. 

To make embedded system development faster, the team usually works on hardware and software simultaneously. Nevertheless, for convenience, let’s consider hardware development and embedded software design as separate parts. 

Embedded System Design: Hardware Development Cycle

1. Requirements gathering and project development specification

Since Integra specializes in outsource embedded electronics development, the ideas of new products usually belong to our customers. When the team joins a project, our first task is to gather the requirements for the future device:

• Functional requirements (what the system must do);
• Non-functional requirements: performance, scalability, security, size, weight, and other important features, as well as ensuring the system meets all necessary industry standards and compliance requirements.

Еhe key challenge here is to interview the client thoroughly to gather requirements and formulate project specification. 

One of the most common problems at this stage is that decision-makers with no technical background find it difficult to formulate requirements for their products. They tend to pay more attention to marketing and functional features but lack an understanding of the technical side. 

In this case, the team listens carefully to understand what functions and features the client wants, then analyzes possible implementations and tells the customer what can and what cannot be done, what risks these options carry, and so on. The idea is to explain the whole picture so that the customer fully understands the pros and cons of each option. 

Another typical scenario is when the client requests too many features (some of which may even be redundant). While it is not necessarily impossible to implement all of them, the number of functions and their complexity affect the cost and duration of the project. In this case, our job is to make sure the customer realizes these drawbacks or to convince them that giving up on some features will not harm the product. 

Sometimes what customers ask is either unrealistic or is not economically feasible. Since Integra Sources takes responsibility for the project, we never promise more than we can do, so in such situations, we tell the customer why the project cannot be fulfilled and offer feasible alternatives if possible. 

When certification is required, we ensure compliance with relevant industry standards such as EU Radio Equipment Directive, IEC 60065, or IEC 61508, and incorporate compliance testing early in the design process to facilitate certification and meet industry-specific safety and quality requirements.

Gathering requirements, understanding the key project goals, and explaining the pros and cons of each option to the customer helps us reveal potential obstacles before the development starts. In our experience, when done properly, this step can save the client an average of 15-30% of the project cost.

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

2. Technical proposal

At this stage, the team creates a document that describes the architecture of the future system and the solutions we are going to implement. 

It may also include the list of key electronic components to be used in the project because intelligent choice of components can make a difference between success and failure. Components differ in terms of performance, size, compatibility, durability, regulatory compliance, and cost, defining the performance of the future device, its reliability and software capabilities. Since embedded electronics have limited resources, components must be adequate to the minimum requirements for the device. For example, when selecting components, choosing options with more memory can provide greater flexibility for optimization, reduce system complexity, and improve overall performance.

The team must take into account different criteria:

• Technical characteristics: power consumption, memory capacity, MCU performance, size, weight, etc. Selecting low power components and implementing power management strategies are crucial for reducing energy consumption and extending battery life.
• Operating environment: extreme temperatures, humidity, vibration stress, etc.
• The cost and quality of the components. Attention to cost savings and minimizing production costs is important, especially for high-volume manufacturing.
• The availability of the components (if the device is supposed to be mass-produced).
• Developers must find a balance between the cost of the future embedded system solution and its performance.

The key to successful hardware and software integration is to find a balance between the cost of the future embedded system and its performance.

3. Schematics and PCB design and layout

The device under development must not only perform its key functions but also be safe and reliable. During embedded hardware design, the team takes into account the following issues:

• The design of the board must fully comply with the PCB design rules so that the device can serve as long as possible with no issues.
• Due attention must be paid to heat dissipation, especially when designing a powerful device. It can be achieved with proper component placement, or by extending the copper area, adding vias, using a cooling radiator, or by other means. 
• The components we have never used before must be tested to make sure they function as their data sheets indicate.
• PCBs must be protected from EOS and ESD events, EM interference, environmental hazards, and other factors that could impact reliability. To further enhance system reliability and safety, fault tolerance techniques such as redundancy and error detection should be considered during the design process.
• If the embedded system is to be mass-produced, we must follow the Design for Manufacturing (DFM) principles.
• The board must be designed with certification requirements  and relevant industry standards in mind (if the client wants the product to be certified).

Data sheets may contain errors and inaccuracies. And since embedded product development is a costly service, such problems must be revealed before we spend the customer’s money. Besides, if the job requires a non-standard approach, we must make sure it’ll work for a given project. In such cases, the team may want to build a proof-of-concept prototype first. Electronics prototyping allows us to prove an idea, check the work of components, and reveal various issues at an early stage of embedded development. Rigorous testing procedures, including hardware-in-the-loop simulations and validation under different conditions, are essential to ensure system robustness and compliance.

Prototyping may require creating not only PCBs but other elements of a system. During one of our projects, we were developing a computer vision algorithm that was supposed to control a robotic manipulator. The model we ordered was too short compared to the measurements provided by the customer, so the team had to make a longer arm, using a shaped metal tube and support elements printed on a 3D printer. This way, we could test the algorithm.

4. Testing

Our team tests PCBs under development at each phase of the process. Rigorous testing is essential to ensure that the board functions correctly and can withstand various conditions. Tests can show if the board functions correctly and complies with various certification requirements. Tests are conducted both after and during development so that we can reveal and eliminate all kinds of defects and issues before moving on to mass production, resulting in significant benefits such as improved system performance, safety, and reliability. Read our article on PCB and electronics testing to learn more. 

Often, the team needs to create custom testing firmware that checks 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 part of custom embedded system development. Unlike applications that run on PCs or smartphones, embedded software is created for specific hardware, i.e., can only run on the microcontrollers of special-purpose, non-computer devices. A program that controls a smart watch, a digital camera, a multimeter, or a washing machine is embedded software.

Such programs are built into devices or machines to control them and/or perform a limited range of functions. When designing embedded systems, it is important to consider both hardware and software components to ensure optimal performance and compatibility.Often embedded software is installed in devices permanently – although nowadays it can be updated through wireless connection (over-the-air (OTA) update). It is stored in non-volatile memory – ROM, EEPROM, or flash memory. Without it, the device won’t work and turn into a piece of metal and plastic. 

Most embedded programs (except for embedded apps) don’t 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. Communication protocols also play an important role in this process, ensuring seamless data exchange and interoperability between hardware components and external devices.

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. Security is a key concern at this level, and secure boot processes are often implemented to ensure system integrity and prevent unauthorized access.

Embedded operating system

Embedded OSs are specialized software that controls 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. Real-time operating systems are commonly used in embedded systems to manage task scheduling and prioritize time-critical operations, ensuring timely responses and system reliability.

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 that contain 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.
• Validation tools are used to ensure that embedded systems meet industry standards and function correctly under various conditions. These tools support rigorous testing such as hardware-in-the-loop simulations to guarantee system robustness and compliance.

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 see what hardware resources they can expect and how they can solve typical embedded system scalability issues.. 

Of course, the team prefers more powerful MCUs with larger memory capacity. Choosing components with more memory can enable better optimization, reduce system complexity, and improve overall performance, especially in demanding projects. When considering power consumption, selecting low-power components and implementing effective power management strategies are essential for reducing heat generation or conserving battery life in portable devices. But if it’s not an option and we have to use less powerful alternatives, we need to analyze the project thoroughly to be sure 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.

To achieve optimal performance, efficient resource management is crucial. This includes code optimization, selecting energy-efficient components, and leveraging hardware features to handle constraints such as limited memory and processing capabilities.

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. Real-time operating systems are also commonly used to manage task scheduling and ensure timely responses in time-critical embedded systems. 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. When designing for performance, it is crucial to minimize latency to meet strict timing requirements and ensure optimal system responsiveness.

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

When everything is settled, the team gets to 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 lots of frameworks with ready-made solutions and tons 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 the firmware development process includes studying data sheets and/or testing the hardware manually.

Within 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

A lot of embedded systems store, manipulate, or transmit sensitive data, especially the solutions designed for critical applications: medical equipment, automobile controllers, industrial modules, etc. Unauthorized access to such equipment can lead to private information theft, financial losses, and even physical injuries. That’s why secure embedded system design has become a key task for engineers nowadays. 

Developers face a number of challenges here. The resources required for security processing can overwhelm the capabilities of the hardware used, as embedded systems have limited processing power, memory size, battery capacity, etc. Additionally, since security protocols have to evolve constantly, it is preferable to make the architecture flexible and adaptable to changing requirements. At the same time, secure embedded system design comes at a price, making product development more expensive and requiring costlier hardware.

Common security requirements for embedded systems include the following:

• User validation before granting them access to the device;
• Secure network access, which is granted only if the device is authorized;
• Secure communications, i.e., protecting the confidentiality of transactions and identities of participants;
• Secure storage, which implies restricting access to confidential information;
• Content security, which implies restricting access to digital content to certain users;
• Availability requires that the work of embedded devices not be disrupted by denial-of-service attacks.

To address growing security threats in interconnected embedded systems, engineers implement multi-layered security measures such as secure boot processes, encrypted communication, and regular firmware updates to protect system integrity and prevent unauthorized access. They use symmetric (e.g., DES, 3DES, and AES) and asymmetric ciphers (RSA and Diffie–Hellman) for encrypting or decrypting information, as well as hashing algorithms for checking data integrity such as MD5 or SHA. Sometimes these cryptographic primitives are combined. Commonly used security technologies and mechanisms include security protocols, digital certificates, and various secure storage and execution techniques.

You can see an example of how our team implements cybersecurity methods in our software for an EEG system project. The solution consists of a headband with electrodes and a processing module which transmits gathered data over Bluetooth to an SDK installed on a tablet. To protect the system from unauthorized access, we used authentication based on the HMAC-SHA256 hashing algorithm. When connection is being established, the processing module sends a unique challenge message to the tablet. If the latter does not return the correct response in one second, the access is denied. Thus, the equipment cannot be used if the tablet doesn’t have the SDK.

• Memory and performance shortage

Resource constraints in embedded software development remain a key challenge. Hardware is becoming more efficient, but 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 debugging embedded software

Thorough functionality testing ensures that both individual modules and the system as a whole work correctly. Load and stress tests can reveal potential failures under extreme operating conditions and show the need to increase reliability in real-life scenarios. In certain cases, a comprehensive and well-planned testing strategy can reduce failures occurring during system operation by up to 30-50%.

A typical application can be tested on a computer, but testing and validating embedded systems requires 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

In conclusion, embedded system design is a complicated process consisting of many steps and requiring professionals specializing in electronics engineering and embedded programming. The team has to deal with many issues at each phase from requirements gathering to testing. Moreover, to speed up the process, hardware and software must be developed in parallel. Integra Sources is a well-knit team with rich experience in embedded electronics development. We know what embedded system design challenges to expect at each step and how to deal with them. In this matter, expert partnerships are essential due to the complexity of the process, ensuring reliable and secure solutions. Don’t hesitate to contact us if you need help with your project idea.