Functional safety development: The real resource commitment behind embedded development

Experts often discuss functional safety using standards, audits, and certification milestones. What is much less discussed is the very real, long-term resource commitment that developing and maintaining a safety-certifiable TCP/IP stack or a file system requires.

When we look at the actual resource breakdown required for functional safety development, one thing becomes immediately clear: this is not a small extension of standard software development; it is a fundamentally different operating model.

What functional safety development really requires

Many industries, such as automotive, medical, industrial, railway, aerospace, and defense, manage and handle devices considered mission-critical.

These devices need to have a safe mode of operation, and in case of a functional error, there needs to be a way to stop the function safely. For example, industrial robotics prevents the robot from starting if an error or fault occurs.

From a software development perspective, we could look at one example. Consider a safety-certifiable TCP/IP stack (with basic components of IPv4, ICMPv4, IGMPv2, TCP, UDP, DHCPv4, and BSD Sockets) that must be developed according to strict standards such as ISO 26262, IEC61508, or any other functional safety standard, ensuring vertical and horizontal traceability from system and software safety requirements, down to architecture and unit design, implementation and up to verification and validation results.

To achieve this, organizations typically need to allocate resources across several distinct roles:

1. Dedicated functional safety development team
Handling functional safety as a side task is not an option. In the example project of a TCP/IP, the effort for the basic functionality is 4-5 full-time engineers for at least 2 years focused exclusively on safety-related development activities. In this example, we consider the basic functionality (modules listed earlier) of the TCP/IP, not more advanced features.

The development team must handle the following:

• Planning, documentation, configuration management, and change management
• Establishing and maintaining a controlled software development environment
• Managing safety requirements, including assumed system safety requirements
• HSI requirements, and derived software safety requirements
• Software architecture aligned with safety constraints and supported by appropriate safety analysis
• Design and implementation of software units in accordance with defined coding standards like MISRA C
• Verification, including verification of work products, static analysis, code coverage, unit testing, integration testing, and embedded software testing
• Confirmation measures, including confirmation reviews
• Ensuring consistency and horizontal and vertical traceability from system safety requirements down to source code and verification results
• Ensuring that appropriately qualified tools are being used

These engineers must gain experience in functional safety or undergo extensive training before they can make any meaningful progress.

2. Independent safety and quality team
Besides the development team, functional safety standards require independence in assessment and oversight. This usually translates to 1-2 full-time specialists in this example project where we are developing a basic TCP/IP stack for functional safety dedicated to:

• Process definition and enforcement
• Safety coaching and internal training
• Planning and executing of independent functional safety audits and assessments

This team operates independently from development, adding another permanent layer of resourcing.

3. Long-term maintenance commitment
Functional safety does not end at certification. In the example project, throughout the product’s lifetime, the TCP/IP stack is to be maintained in a safety-compliant manner. Although rare, the potential need for bug fixes or other changes means that the overall impact of the change should be assessed throughout the whole V-model. This assessment includes requirements, design, implementation, verification and validation, and FMEA. Adjustments need to be applied if necessary. This requires attention and diligence throughout the product’s lifecycle in case changes are necessary.

Why these numbers matter

Taken together, the resource requirements show why functional safety projects often experience:

• Higher-than-expected development costs
• Longer time-to-market
• Increased organizational complexity
• Sustained operational costs long after release

This is particularly challenging for teams attempting to adapt open-source networking stacks or build an in-house solution. In practice, achieving safety compliance often means redeveloping large portions of the stack while still carrying the full burden of safety processes, audits, and lifetime maintenance.

Reducing risk and resource load with TCP/IP CERT and EdgeFS CERT

Tuxera TCP/IP CERT and EdgeFS CERT specifically address this challenge.

By providing a pre-developed, safety-focused TCP/IP stack or a file system with certification-ready artifacts, Tuxera removes much of the resource burden described above by:

• Significantly reducing development effort and time-to-market
• Allowing the in-house development team and safety professionals to focus on the core functionality of the device
• Enabling the team to work on the system and functional level of safety without the need to establish a team to work on the low-level software safety processes or invest in more people in the functional safety development team

In the example project of the TCP/IP, this results in:

• Savings of 4-5 FTEs in development for a minimum of 2 years
• Savings of 1-2 FTEs in quality and safety oversight over the product’s lifetime
• Reduced long-term maintenance effort over the product’s lifetime

What the numbers tell us

The resource requirements summarized below tell an important story: functional safety is not just a technical challenge — it is a strategic resourcing decision.

In the table above, the lower percentage represents a best-case scenario with a team that is already experienced in functional safety development, the maximum effort increase is with a team that has not been working with functional safety before. The information source is Kugler Maag and the Tuxera in-house team. We always compare the effort increase to the previous step.

Organizations that account for this early enough can avoid surprises, delays, and cost overruns. With Tuxera TCP/IP CERT or EdgeFS CERT, teams gain predictability: predictable effort, predictable timelines, and predictable long-term costs, without compromising on safety.