To Run or Not to Run? The Case for Automated Static Analysis in Embedded Systems

Testing and other forms of dynamic analysis are essential for understanding program behavior, yet they remain inherently incomplete due to the infinite nature of possible inputs. Static program analysis offers a complementary approach, gathering comprehensive knowledge without execution. While manual code reviews are a valuable form of static analysis, they are labor-intensive and difficult to scale.

This presentation explores the vast spectrum of automated static analysis, ranging from simple code metrics (such as the seemingly straightforward lines of code) to advanced semantic techniques such as abstract interpretation to detect potential defects. We will compare these automated methods against dynamic analysis and manual reviews, with a specific focus on their added value in embedded software.

Although the discussion remains primarily conceptual and methodological, we will mention some exemplary tools to ground the theory. Finally, we will discuss how to effectively integrate these analyses into a Continuous Integration (CI) pipeline to ensure lasting code and process quality.

What this presentation is about and why it matters

How do you decide when embedded software is better examined by running it, and when it is better studied without execution? Rainer Koschke walks through that tension with a broad, practical tour of automated static analysis, using embedded software as the anchor and moving from simple metrics to semantic defect detection, architecture checks, and CI integration. The talk is especially useful if you have tools in place already but are unsure how to interpret their output, combine them with testing, or fit them into an engineering workflow. It is a good watch for anyone trying to turn static analysis from a checkbox into a useful part of development.

Who will benefit the most from this presentation

• Embedded software engineer, if your team already runs tests but rarely uses static analysis beyond the compiler.
• Software architect, if you need to verify layered or component dependency rules automatically.
• QA or verification engineer, if you want a clearer distinction between testing, bug finding, and conservative analysis.
• Engineering manager, if you are trying to reduce review burden with CI-based quality checks.
• Developer working in regulated domains, if you need support for coding-rule compliance and auditability.

What you need to know

A general understanding of embedded software development and basic programming terms will help. The talk assumes familiarity with the idea of compiling, testing, and reading code, but it does not require prior expertise in static analysis.

Glossary (terms used in this talk)

• Reachability analysis: A method for checking whether a known issue in a dependency can actually affect a released artifact, based on how code and symbols are used in the build. It helps separate actionable findings from unrelated noise.
• Delta analysis: A workflow that separates newly introduced findings from existing ones so attention can focus on recent changes. It is often used to make recurring static-analysis results more actionable in CI pipelines.
• Control flow graph: A graph representation of program execution paths, where nodes represent statements or blocks and edges represent possible transfers of control. It is a common intermediate form for analysis of reachability, branches, and path conditions.
• Path condition: A conjunction of constraints that must hold for execution to reach a specific program path. It is commonly used in symbolic and concolic execution to reason about feasible paths.
• SMT solver (Satisfiability Modulo Theories solver): A solver that determines whether logical constraints are satisfiable under theories such as integers, arrays, and bit-vectors. These solvers are widely used in symbolic execution, concolic testing, and other automated reasoning tasks.
• COCOMO: A cost estimation model used in software engineering to estimate development effort. It is often paired with size measurements such as lines of code.
• Abstract interpretation: A conservative static analysis technique that computes over-approximations of program behaviors in a compact form to infer properties and detect whole classes of errors. It can prove absence of certain runtime errors for an error category but may over-approximate and report false positives.
• Concolic testing: A test-generation approach that combines concrete execution with symbolic execution: it runs the program concretely to obtain a trace and then symbolically replays that trace to produce path constraints, using an SMT solver to generate new inputs to maximize coverage.

Final thoughts

Practical and methodical, this talk gives a useful way to think about what static analysis can actually tell you, and where its results need context. The value is less about memorizing tool categories than about gaining a sharper lens for choosing, interpreting, and integrating analyses into real workflows. It will especially help embedded developers, architects, and verification teams who want fewer surprises from code review, testing, and compliance work. The overall feeling is one of disciplined optimism about automation.

This overview is AI-generated from the session transcript. Spot an issue? Let us know.