Static analysis for safety-critical code is software that reads the code of a car, an aircraft, a train or a medical device without running it, and flags every line that breaks the coding rules that the industry's safety standards require. These tools are called static analysers. "Static" means that the code is examined as text, and not run.
Why are special coding rules needed? C and C++, the languages most embedded software is written in, allow many things that work on one day and fail on another. A variable may be used before it is given a value. A number may grow too large for the space set aside for it, and turn into a wrong value. A calculation may divide by a sensor reading that can be zero. In a phone app, such a bug causes a crash. In a braking unit, it can cause an accident. So the industry uses strict rule sets for these languages. The best known is MISRA C, for the C language. These rules forbid the risky features. Safety standards, such as ISO 26262 for cars and DO-178C for aircraft software, expect a team to follow such rules and to prove it. The page on safety certification explains these standards.
Here is a typical case. An avionics software team in Bengaluru is writing the software for a flight-control computer. The code has 1,20,000 lines. The static analyser checks every line against about 150 rules. Its first report lists 312 rule violations. Most are small, such as a number written without its type. But the report also finds 4 places where the code could divide by zero, if a sensor fails and reports 0. The engineers fix these by adding a check before each division. For 9 other violations, the team decides that the rule cannot sensibly be followed in that line. For each one, an engineer writes a deviation: a signed record of why the rule is broken there, and why the code is still safe. The certification authority later reads these records.
After that, the analyser runs on every change. The CI/CD pipeline, the system that builds and tests each change, runs it automatically. If a change adds a new violation, the change is rejected before it joins the main code. Moving checks this early, into the developer's daily work, is called shifting left.
The checked code ends up in avionics, in automotive safety electronics such as airbags and brakes, and in other devices that run a real-time operating system. Code that a model-based design tool generates is checked in the same way.
How is this different from static application security testing (SAST)? Both read code without running it. A SAST tool looks for security holes, such as a password written into the code. A safety analyser looks for anything that could make the machine behave wrongly, and for every break of a safety rule set. Neither one replaces testing the software on the device.