When Should You Allocate Requirements to Hardware Versus Software?
A systems architect at an automotive Tier 1 recently put the question plainly: “We have an ASIL D safety function. The hardware team says put it in a dedicated safety IC. The software team says their ASIL D certified processor can handle it. Both teams think they’re right. How do we actually decide?”
This is one of the most consequential decisions in a safety-critical system design, and it gets made badly more often than it should — not because engineers lack competence, but because the decision framework is informal. The allocation lands wherever organizational gravity pulls it: the team with more schedule margin, the platform that already exists, the manager who spoke last in the architecture review.
That is not systems engineering. It is project management masquerading as systems engineering, and ISO 26262 Part 4 will surface the difference during a safety audit.
Here is how to make the decision correctly.
What Allocation Actually Means
Requirements allocation is the engineering act of assigning a system-level requirement to a specific architectural element — hardware, software, a hardware-software combination, or a human operator — along with the rationale that justifies that assignment.
The key word is rationale. Allocation is not a label you attach to a requirement after the architecture is set. It is a decision with inputs, a logic chain, and a documented conclusion. Under ISO 26262, that logic chain must be traceable from the safety goal through the functional safety concept, through the technical safety concept, and into the hardware and software safety requirements.
If you cannot reconstruct that chain from your documentation, you have an allocation artifact — a record that something was allocated — but not an allocation decision.
The Five Inputs That Should Drive Allocation
1. Reliability Analysis
Start here. What is the target probability of dangerous failure per hour (PMHF) for the safety function in question? For ASIL D, ISO 26262 targets a residual risk below 10⁻⁸ failures per hour for random hardware failures.
Hardware components have quantifiable random failure rates from standards like IEC 62380 or SN 29500. A dedicated safety IC designed for a specific function — current monitoring, redundant switching, voltage supervision — can be sized precisely for that target.
Software does not have an equivalent random failure rate model in the same sense. Software failures are systematic. You cannot put a field failure rate on a software defect the same way you can on a capacitor. This asymmetry matters: if your safety analysis depends on a quantified random hardware failure metric, hardware allocation gives you a tractable path. Software allocation shifts the argument to systematic capability and diagnostic coverage, which are real but structurally different claims.
2. Safety Integrity Requirements
ASIL decomposition and allocation are tightly coupled. A single ASIL D requirement can be allocated to two independent ASIL B elements (ASIL D = ASIL B + ASIL B under ISO 26262’s decomposition rules), provided the independence requirements are met.
Hardware independence is often easier to demonstrate than software independence. Two separate microcontrollers running different software on different execution paths provide a structural independence argument. Two software modules on the same processor require a more elaborate argument about freedom from interference — which is achievable but adds certification effort.
When the ASIL D requirement cannot be cleanly decomposed, or when the decomposition would require a software architecture you cannot currently certify, hardware allocation for part or all of the function is frequently the cleaner path.
3. Latency Constraints
Some safety reactions must occur faster than software can reliably guarantee in a complex real-time operating environment.
Overcurrent protection in a battery management system is a canonical example. A dedicated protection IC can respond in microseconds, unconditionally. A software-based protection function running on a microcontroller with an RTOS has interrupt latency, task scheduling jitter, and context switching overhead. The worst-case execution time is bounded but rarely below the tens of microseconds range — and that bound must be verified and maintained across software updates.
If the requirement is “disconnect within 10 μs of overcurrent detection,” hardware allocation is not a preference. It is the only allocation that can satisfy the requirement without requiring heroic software architecture.
For functions with latency requirements in the milliseconds range, software becomes viable. For functions requiring subsystem coordination across multiple frames, software is often preferable because the logic is too complex for a cost-effective hardware implementation.
4. Testability
Both hardware and software safety requirements must be verified. The allocation decision affects what your test strategy looks like and whether it is achievable.
Hardware faults are typically tested through fault injection at the hardware level — a well-understood methodology with established tooling. A dedicated safety IC with defined fault detection mechanisms has a testability argument baked into its specification.
Software safety functions must be tested for functional correctness, but also for their response to hardware faults (via the hardware diagnostic layer). If the software is responsible for detecting hardware faults, you need to demonstrate that the diagnostic coverage claimed in your FMEA is actually achieved in testing. This is often the underestimated work item in software-dominant architectures.
Allocate to the element where the required test coverage is achievable within your program constraints. If your test infrastructure cannot inject the hardware faults needed to verify a software diagnostic, your allocation is aspirational, not engineered.
5. Cost
Cost is a valid engineering input, not an embarrassing one. Total cost of ownership for a dedicated safety IC includes component cost, qualification cost, PCB area, and supply chain management. For software, the equivalent includes platform certification cost, integration testing, ongoing maintenance, and the cost of regression testing every safety function when any software changes.
In high-volume automotive programs, software allocation frequently wins on per-unit cost once the platform certification is amortized. In lower-volume or higher-criticality applications, hardware allocation can win because the platform certification cost is prohibitive and the hardware solution is more auditable.
Model both cases. Do not let either team tell you cost is not their problem.
Common Allocation Patterns in Automotive Safety Systems
Dedicated hardware for: Power stage protection (overcurrent, overvoltage, thermal shutdown), watchdog supervision of the main processor, voltage monitoring for safety-relevant power rails, redundant position sensing (resolver ICs, magnetic encoder ASICs), and physical isolation enforcement (gate driver fault response).
Software for: Safety state machine management, plausibility monitoring across multiple sensor inputs, degraded-mode logic, driver communication (torque limiting, speed limiting), and AUTOSAR-compliant safety mechanisms where the platform is pre-certified.
Hardware-software co-allocation for: ASIL D brake control functions (hardware handles sub-millisecond fault latch, software handles degraded operation and fault logging), battery management (hardware monitors cell voltages and enforces hard limits, software manages charge algorithms and state estimation), and camera-based ADAS (hardware accelerators handle image processing pipelines, software handles object classification and path planning).
The pattern is consistent: hardware owns the response to well-characterized, time-critical faults where the failure mode is bounded. Software owns the logic that requires context, history, or communication with other systems.
What ISO 26262 Actually Requires for Allocation Documentation
ISO 26262 Part 4 (product development at the system level) requires that the technical safety concept document the allocation of technical safety requirements to system elements. Specifically:
- Each technical safety requirement must be allocated to a hardware element, software element, or the hardware-software interface.
- The allocation must be consistent with the ASIL assigned to the requirement.
- If a requirement is allocated to multiple elements (e.g., for ASIL decomposition), the independence requirements must be documented.
- The rationale for allocation must be available for review — typically as part of the safety case.
What auditors look for in practice: Can you show the requirement? Can you show what it is allocated to? Can you show why? The “why” is where most programs are deficient. The allocation exists as a column in a spreadsheet or a tag in a requirements tool, but the rationale is in a PowerPoint from an architecture review eighteen months ago that three of the four authors have since left the company.
That is not a documentation style preference. It is an audit finding under Clause 6.4 of ISO 26262 Part 4.
How Flow Engineering Handles Allocation as a First-Class Decision
Most requirements tools treat allocation as a field — a tag, a label, a dropdown. The requirement exists. The allocation exists. The connection between them is implicit in the data model but the reasoning is unstructured, usually buried in a comment field that nobody reads.
Flow Engineering takes a different approach by treating allocation decisions as structured, bidirectionally traceable engineering choices. An allocation in Flow Engineering is not just “Requirement X → Hardware Element Y.” It is a node in a connected graph that carries the requirement, the allocated element, the rationale that connects them, and the verification method that will confirm the allocation was realized correctly.
This matters for two reasons.
First, it survives program changes. When the hardware team revises the safety IC specification, Flow Engineering’s graph immediately surfaces which allocated requirements are affected — not because someone ran a manual impact analysis, but because the connection is structural. Engineers see the impact before the change is finalized, not after it is released.
Second, it produces auditable evidence automatically. The ISO 26262 audit question “show me the rationale for this allocation” has a direct answer: open the allocation node, read the structured rationale, trace backward to the technical safety requirement, trace forward to the verification activity. The safety case does not need to be reconstructed from meeting notes. It is the model.
Flow Engineering is intentionally focused on hardware and systems engineering workflows rather than general-purpose requirements management — which means it does not try to be a document management system or a project management tool. Teams that need deep integration with legacy document workflows will need to evaluate whether that trade-off works for their program. For teams building new products on modern architectures where the goal is connected, AI-assisted traceability rather than a better spreadsheet, the focus is the point.
A Practical Starting Framework
When you face an allocation decision, work through these questions in order:
- What is the PMHF target, and can software diagnostic coverage plausibly meet it? If not, hardware allocation is required.
- What is the worst-case latency requirement? If it is below ~1 ms, software allocation requires a rigorous timing analysis. If it is below ~100 μs, you are almost certainly looking at hardware.
- What ASIL is assigned, and does the current platform carry that ASIL? If not, can you decompose? What is the independence argument?
- What test infrastructure exists? Can you verify the allocation you are proposing?
- What is the total cost model over the program lifetime? Include certification, not just BOM.
Document the answers to these questions as part of the allocation rationale — not in the minutes of the meeting where you discussed them, but in the requirements record itself, traceable to the requirement being allocated.
The answer to your systems architect’s question is not “hardware wins” or “software wins.” The answer is: work through the analysis, document the logic, and let the allocation follow the evidence. If both teams can meet the requirement with acceptable risk at acceptable cost, choose the one with better testability. If they cannot both meet it, the analysis will tell you which one can.
That is systems engineering.