Static Resource Allocation

2025-08-31

Static Resource Allocation

What is it?

Static resource allocation is a software design technique in which all memory and resources are reserved at compile-time. No dynamic variables or objects are created while the program runs. Because the memory layout is fixed, the compiler and static analysis tools can verify sizes and addresses, and the system avoids run-time effects such as fragmentation or allocation failure.

When to use

  • Safety functions must meet strict real-time deadlines and worst-case execution time analysis.
  • The standard or safety case restricts dynamic allocation (e.g., IEC 61508-3 Tables A.2/B.1; Annex C.2.6.3).
  • Independent verification needs a static, auditable memory map and bounded resource usage.

Inputs & Outputs

Inputs

  • Hardware memory map (RAM/flash, stack limits, MMU/MPU configuration)
  • Worst-case resource demands (buffers, task stacks, queues, tables)

Outputs

  • Fixed allocation plan (symbols, sections, linker script)
  • Evidence: compiler maps, static-analysis reports, and allocation ban checks

Procedure

  1. Inventory memory needs: enumerate all buffers, task stacks, message queues, and persistent objects; define credible worst-case sizes.
  2. Design the layout: assign static storage (globals, static locals, fixed-size pools); define sections in the linker script (e.g., .bss, .data, dedicated IO buffers).
  3. Ban dynamic allocation: remove/forbid malloc/calloc/realloc/free, new/delete; configure build rules/LINT to fail on use (including in third-party libraries).
  4. Prove bounds: add compile-time asserts and run-time guards; generate and review the map file; verify each buffer has explicit bounds checks at interfaces.
  5. Validate timing: measure worst-case execution time with the static layout; confirm no allocation hotspots exist in task paths.
  6. Document & test: record assumptions, margins, and SAFE REACTIONS for overflow conditions; include unit/integration tests that exercise near-capacity cases.

Worked Example

High-level

A safety PLC regulates a reactor feed valve. Loss or corruption of control data due to heap exhaustion could leave the valve command undefined. By allocating fixed-size input/output buffers and prohibiting dynamic allocation, the control loop always has memory, and any oversize frame is detected and handled safely.

Code-level

// Example: static buffers and bounds checks (C-like) 

#define RX_FRAME_MAX 64 
#define TX_FRAME_MAX 64 
static uint8_t rx_frame[RX_FRAME_MAX]; 
static uint8_t tx_frame[TX_FRAME_MAX];

bool handle_rx(const uint8_t* data, size_t len) {
if (len > RX_FRAME_MAX) {
// SAFE REACTION: discard frame, raise diagnostic, hold last known safe output
raise_diagnostic(DIAG_RX_OVERSIZE);
return false;
}
memcpy(rx_frame, data, len);
return true;
}

void control_step(void) {
// No dynamic allocation anywhere in the control path
size_t out_len = build_command(tx_frame, TX_FRAME_MAX);
if (out_len == 0) {
// SAFE REACTION: enter safe state (close valve)
command_valve(CLOSE_VALVE);
} else {
send_command(tx_frame, out_len);
}
}

Quality criteria

  • Determinism: No run-time allocation in safety-related paths; timing shown for worst-case conditions.
  • Completeness: Every buffer, stack, and queue has a justified size and documented headroom margin.
  • Verification: Automated checks (lint/build rules) enforce allocator ban; map file and static-analysis reports reviewed.
  • Protection: Bounds checks at all interfaces; SAFE REACTIONS specified, implemented, and tested.

Common pitfalls

  • Hidden allocators in libraries. Mitigation: audit dependencies; link with stubs that fail build on allocation calls.
  • Underestimated worst case leading to overflow. Mitigation: derive sizes from credible worst-case scenarios; add assertions and tests at capacity limits.
  • Excessive over-allocation wastes RAM. Mitigation: iterate sizing with measurements; separate safety-critical from non-critical buffers.
  • Assuming “static” implies “safe.” Mitigation: still implement bounds checks, diagnostics, and SAFE REACTIONS.

References

FAQ

Does IEC 61508 always forbid dynamic memory?

No. It requires restrictions where dynamic behavior cannot be accurately predicted by static analysis. Many safety cases choose a full ban in safety-related paths to simplify assurance.

How do I deal with variable-length payloads without malloc?

Use fixed-size buffers with length fields, ring buffers, or statically sized memory pools; validate lengths and apply SAFE REACTIONS on overflow.

Can I mix static allocation in safety code with dynamic allocation elsewhere?

Yes, if freedom-from-interference is demonstrated (e.g., MPU/partitioning) so non-safety allocation cannot impact safety resources.

What evidence should I keep for audits?

Allocator ban rules, dependency audits, linker map files, static-analysis reports, worst-case sizing rationale, and tests showing correct SAFE REACTIONS at capacity.

This article explains Static Resource Allocation in general functional-safety practice. Always consult applicable standards for normative requirements.


Back to all news

We use cookies
Cookie preferences
Below you may find information about the purposes for which we and our partners use cookies and process data. You can exercise your preferences for processing, and/or see details on our partners' websites.
Analytical cookies Disable all
Functional cookies
Other cookies
We use cookies to personalize content and ads, to provide social media features and to analyze our traffic. Learn more about our cookie policy.
Accept all Decline all Change preferences
Cookies