Applications of Formal Methods in Engineering Innovation

One of the ways formal methods can find bugs tests do not: invariant checking. Say you're making a banking program, and have a rule that no account can ever go below zero dollars. You might write a test like this: test {a = Account(balance=5); a.withdraw(10); assert a.balance >= 0} If the test passes, you can't go below zero dollars. Or more specifically, THIS account with THIS setup with THIS exact sequence of steps doesn't have a negative balance AFTERWARDS. But "accounts can't be negative" is an *invariant*: it should hold for all system states, regardless of what the system does or when you check the invariant. Withdrawing 10 dollars from a 5 dollar account might not break the invariant, but what about withdrawing 11 dollars from a 10 dollar account? Doing two withdrawals at once? Sending someone money? Can you test every possible thing? In a formal specification, rather, we define all the ways the system could be set up and all of the actions the system *could* take. Then we tell it to check the invariant: always (forall a in Accounts: balance[a] >= 0) Then the checker will check the invariant for every possible state in every possible behavior from every possible setup, eventually getting back something like > If A sends B two transfers, then B sends C one transaction, and then one of the A->B transfers bounces, then depending on how the remaining A->B transfer and the B->C transfer race each other, it's possible for B to end with negative dollars. I have seen much, much weirder errors crop up in the process of formally specifying. Weirder errors that actually were latent in the real system, and could have cost a LOT of money in damages. There's a lot of other cool tricks in the formal methods toolset— liveness properties, reachability, refinement, etc— but invariant checking is one of the most accessible and most powerful perks of writing a formal spec.

Defense Software for a Contested Future At the request of the DARPA, the National Academies conducted a study to explore how to enhance the assurance and agility of large-scale, integrated software-based systems. This report recommends ways the Department of Defense can engineer and manage its software systems to reduce cyber risk and enable more rapid system evolution to meet changing mission needs. Report is here: https://lnkd.in/eDrUdrUu Neat section on use and rapid maturing of formal methods to help with software assurance. Examples given: - CompCert: formally verified compiler for the C. An automated test tool that found hundreds of bugs in mainstream compilers like gcc and clang/LLVM found no bugs in CompCert's verified components after years of testing. - seL4: A high-assurance, open-source microkernel that serves as a trustworthy foundation for security-critical systems. It was successfully used in a Defense Advanced Research Projects Agency (DARPA) program to build a quadcopter drone that could resist red-team attacks. - NATS iFACTS: A large-scale air traffic control system in the United Kingdom, comprising 250,000 lines of code, that was formally proven to be free of runtime exceptions and to have functional correctness. It is written in SPARK, a subset of the Ada programming language designed for high-assurance systems. - Project Everest: A collaboration that produced formally verified, high-performance implementations of components of the HTTPS ecosystem, such as the TLS protocol and cryptographic algorithms. This verified code is now widely deployed in Mozilla Firefox, the Linux kernel, and Microsoft's Hyper-V hypervisor, among others.

Applying formal verification in network security: Insights from a Caliptra project engineer As a formal verification engineer at LUBIS EDA, I've had the privilege of working on the Caliptra project, ensuring the reliability of cryptographic algorithms like SHA-256, SHA-512, DOE, ECC, and HMAC. 🛡️ Formal verification in network security uses mathematical methods to exhaustively prove that a system behaves as intended under all possible conditions. This is crucial for cryptographic systems, where minor errors can lead to serious security issues. Here's what we did: - Property Generation: Using LUBIS tools, we defined the expected behavior and security characteristics of each algorithm. - Abstraction Techniques: We used black-boxing, signal cutting, and constraints to manage complexity and improve proof convergence. - Divide-and-Conquer Strategy: We split the design into smaller blocks, verifying each independently to handle state space explosion effectively. Challenges included modeling complex cryptographic algorithms and managing state space explosion. Yet, formal verification provided high assurance of security and comprehensive coverage, catching bugs that traditional testing might miss. 🔍 The result?  A mathematically guaranteed security for the Root of Trust (RoT) in data center SoCs, enhancing overall system reliability. Want to discuss more about formal verification in cryptographic systems? Drop your thoughts below! 👇 #SemiconductorIndustry #Semiconductors #FormalVerification

What is Formal Verification? Formal verification is the process of mathematically proving whether a design satisfies its intended specifications. Unlike simulation (which checks behavior for specific input vectors), formal methods explore all possible states and inputs exhaustively (within defined constraints). It’s widely used in semiconductor design, safety-critical software, protocols, and security. Core Techniques in Formal Verification 1. Model Checking • Definition: Automatically explores the state space of a system model against a given specification (e.g., expressed in temporal logic). • How it works: The system is represented as a finite-state machine; properties are checked using temporal logics like LTL (Linear Temporal Logic) or CTL (Computation Tree Logic). • Types: • Explicit-state model checking: Traverses states one by one (state explosion risk). • Symbolic model checking: Uses BDDs (Binary Decision Diagrams) or SAT/SMT solvers to compactly represent large state spaces. 2. Equivalence Checking • Definition: Proves that two designs are functionally identical. • Use cases: • RTL vs. synthesized netlist • Pre-layout vs. post-layout design • Types: • Combinational equivalence checking (CEC): For purely combinational logic. • Sequential equivalence checking (SEC): Accounts for state machines, pipelines, clock gating. 3. Theorem Proving • Definition: Uses mathematical logic to prove properties interactively (human + tool assistance). • Tools: HOL, Coq, Isabelle. • Strength: Extremely flexible—can prove very abstract properties (algorithms, protocols, security). • Weakness: Requires high manual effort and expertise 4. SAT/SMT Solving • SAT (Boolean Satisfiability): Checks if a Boolean formula can be satisfied. • SMT (Satisfiability Modulo Theories): Extends SAT with arithmetic, arrays, bit-vectors, etc. • Used heavily in bounded model checking and property verification. 5. Property Checking / Assertion-Based Verification • Definition: Formal tool checks whether design meets assertions (properties written in PSL, SVA). • Example properties: • Safety: “X never happens” (deadlock freedom, no overflow). • Liveness: “Y eventually happens” (request gets response). • Widely used in IP verification (bus protocols, cache coherence). Advantages of Formal Verification • Exhaustive: No need for test vectors. • Early bug detection (before simulation testbenches are ready). • Catches corner-case bugs missed in simulation. • Proves absence of bugs (not just finds them). Limitations • Scalability: State space explosion in large SoCs. • Abstraction needed: Often needs environment constraints to converge. • Complex setup: Requires expertise in properties, constraints, and tool usage. Typical Applications • Hardware: Equivalence checking (RTL vs. netlist), protocol compliance (AMBA, PCIe), deadlock freedom. • Software: Verifying algorithms, security properties, absence of runtime errors.

Sweden Electrical and control system engineering. The project involves distributed task planning and control for multi-agent systems. Multi-agent tasks will be given in the form of formal verification languages such as temporal logic and its variants. The control of each agent will need to take into account information from other agents as well as changes in the environment. The doctoral student will develop novel algorithms for distributed multi-agent planning and control under complex tasks that account for these features using tools from multi-agent planning and control, hybrid control systems, formal methods and game theory. Supervision: Professor Dimos Dimarogonas https://lnkd.in/dpExfi3E