Designing an embedded system can be complex, with many factors to consider when selecting the right software and hardware components. In fact, embedded systems tend to be more complicated and expensive than most programmers think.
In this article, we focus on one critical aspect of this complex process: choosing the right networking stack. While it’s just one piece of the puzzle, the networking stack plays a vital role in the overall design and can significantly impact your project’s success.
Drawing on over three decades of experience in embedded systems, we’ll guide you through the essential considerations for selecting the right networking stack. We’ll cover key questions you need to ask—from hardware and software specifications to how your intended use case and data workload influence your choices.
Let’s dive in.
What to consider when choosing a network stack for embedded devices
These are the key aspects to take into account when selecting a network stack for embedded devices.
Your desired outcome
When selecting your networking stack, start by defining your desired outcome. Every aspect of the system design affects the others, so different standard compliances, security, encryption requirements, and performance expectations might influence your choice of microcontroller unit (MCU).
In some cases, you might need to replace or add an existing stack without the freedom to choose new hardware. Cost constraints can also limit your networking stack options. In these situations, it’s important to select a supplier that can deliver high performance in resource-constrained environments.
Applications and protocols
Identify the necessary protocols for your system based on the type of data being transferred. Determine which protocols are allowed, including whether proprietary protocols are an option.
When introducing or replacing a network stack due to performance, security, or reliability issues, consider any existing applications that rely on the current network stack. You have three options:
1. Tailor the existing application to the new networking stack
2. Use the application provided by the new network stack, if there is one
3. Develop a new application from scratch (you want to avoid this option)
For example, if you have a custom protocol (let’s call it my_protocol_app) and need to replace the network stack, it’s crucial to assess the effort required to migrate my_protocol_app to the new stack. Ideally, this migration should require minimal effort.
Ensuring cyber resilience
Cyber attacks are on the rise, targeting IoT devices and systems like industrial water pumping stations. From a system design perspective, you need to consider the type of data being transferred and the network’s vulnerability to cyber attacks.
If the data needs encryption, use security protocols like MACsec, IPsec, and D/TLS to protect against man-in-the-middle attacks. Your stack supplier should guide you through the Threat Analysis and Risk Assessment (TARA) process to ensure robust security solutions.
Compliance with industry-specific standards
Different industries require adherence to specific quality standards. There’s ISO 26262 ASIL-x for automotive, DO178 DAL-x for avionics, and IEC61508 SIL-x for industrial applications, to name a few.
Off-the-shelf solutions often fall short of meeting industry standards because vendors can’t anticipate your unique use cases and quality expectations. However, achieving certification requires a collaborative effort. At Tuxera, for example, we start with established requirements in our safety solutions and perform a gap analysis to ensure all your needs are addressed. Additionally, we adhere to robust development practices and maintain a strong safety culture.
Regional compliance requirements
You also need to navigate regional compliance requirements to ensure the legality and security of embedded systems.
For example, in the US, security-based products using cryptographic algorithms typically need Federal Information Processing Standards (FIPS) certification. In the EU, the recently introduced Cyber Resilience Act will be enforced starting in 2027.
Additionally, the UN Regulation R155, a cybersecurity standard for all E/E systems in road vehicles, is mandatory in some countries. Japan was the first to adopt R155 into national regulations, requiring it for new vehicle types.
Connectivity and power management
Choosing between wireless or wired connectivity and mobile data networks like 4G and 5G not only affects the hardware, operating system, and protocol requirements—it also affects power consumption.
To maximize battery life for battery-powered devices, you need to carefully plan workload distribution and data transfer methods.
Ongoing support
For critical applications, continuous support is a must. Your support team should be readily available and able to quickly resolve issues.
Having support hubs from suppliers spread across the globe also ensures consistent availability of support, facilitating the smooth continuation of operations.
Related content: Watch our interview with Sandor Filippinyi at Embedded World
Networking stack evaluation checklist
Now that we’ve covered the general topics to consider when choosing a network stack for embedded devices, we’ll get into more granular details.
Here are some specific questions you should ask when selecting the network stack and other system components.
Hardware compatibility
Target CPU: Does the networking stack support the CPU architecture of our devices?
Ethernet driver: Is there an available Ethernet driver compatible with our hardware?
Cryptographic engine: Does the CPU include a cryptographic engine, and is it supported by the supplier?
● If there is no crypto engine, can the supplier provide a software solution meeting our performance needs?
● If there is a crypto engine, then:
● If the driver is available, can it be tailored in a straightforward manner to the networking stack?
● If the driver is not available, can the supplier develop it?
External components
External chips (Wi-Fi, modem, Ethernet PHY): Are these components supported by the networking stack?
Operating system compatibility
Target operating system (OS): Is our OS supported by the networking stack?
● Can the network stack be integrated to a time/memory partitioned OS?
OS flexibility: Can the supplier work with any operating system or bare metal?
Target protocol support
Communication and security protocols: Does the stack support all necessary communication and security protocols?
● Can the supplier help in designing, implementing, and verifying potentially missing protocols?
Implementation
Language: What is the implementation language of the networking stack? Is it C?
Compiler independence: How independent is the stack from the target compiler?
● How easy is it to compile the network stack with the target compiler?
Memory management
Memory requirements: Can the networking stack meet our target RAM/ROM requirements?
Dynamic memory: Is dynamic memory required, and how does its use impact system behavior? Using dynamic memory may introduce non-deterministic behavior.
Compliance and security
Standards compliance: Is the stack compliant with MISRA?
Cybersecurity: Is the stack monitored for common vulnerabilities and exposures (CVEs)?
Safety standards: Is the stack developed according to the V-model? Can it address our quality and/or safety requirements?
Flexibility and customization
Configurability: Is the networking stack configurable to our needs?
Feature exclusion: Can unnecessary features be excluded, especially for functional safety certification?
Supplier support: Can the supplier assist in fine-tuning the system or developing missing components (protocols, drivers, etc.)?
Final thoughts
To sum it up, designing your embedded system architecture with your desired outcome in mind is crucial. And when that’s not possible, you’ll want to work with suppliers who are experts in the specific functionalities you need.
Your networking stack must meet security, performance, memory, and compliance requirements. So choose a supplier that has optimized their code over the years, ensuring efficient memory use and strong cybersecurity features.
At Tuxera, we specialize in not only in embedded systems but in helping people and businesses store and move data reliably, while making data transfers fast and content easily accessible. From the edge all the way to the cloud, we have a comprehensive portfolio of file systems, flash management software, network stacks, and storage testing services.
To learn more, check out our networking stack page.
Sandor Filippinyi
Sandor Filippinyi is Head of Global Software Engineering at Tuxera. Over a span of more than two decades in the embedded industry he has taken part in architecting and implementing fault-tolerant file systems (interoperable/proprietary), flash translation layers (raw NAND/NOR), TCP/IP stack, related security protocols, USB host- and device stacks, and bootloaders for various CPU-s, microcontrollers, and operating systems. He has learned extensively about safety-critical development and related processes. Sandor continues to actively help engineering with his expertise.