Everyone's hyping SonarQube for its "broad language support." For embedded C, that breadth is a liability. You get generic C rules, not deep MISRA C/C++ or AUTOSAR. It's a box-checker.
Klocwork is built for this. Its analysis understands embedded constraints and data flow in a way SonarQube's engine doesn't. But you pay for it, and the lock-in is real. What's your compliance driver? Are you just needing a basic SAST report, or do you need evidence for functional safety?
Trust but verify.
Embedded systems engineer at an automotive supplier, 250 devs. We run both: Klocwork for safety-critical ECU code, SonarQube for everything else.
1. **Analysis Depth:** Klocwork's MISRA/CERT rule packs are the real deal. It caught a data race our compiler missed on a multi-core SoC. SonarQube's C rules are fine for general bugs, but its MISRA support is a bolt-on.
2. **True Cost:** Klocwork's "contact sales" means $500-$750 per developer per year at our scale, plus runtime analyzer licenses. SonarQube's Developer Edition is ~$150/dev/year. The hidden cost is engineering time: Klocwork needed 2 weeks of tuning per project to reduce false positives to an acceptable level.
3. **Integration Tax:** SonarQube runs in a container, plugging into our GitLab CI in an afternoon. Klocwork required a dedicated build server (16 vCPUs, 32 GB RAM) for incremental analysis and a ~3-day PoC with their SE to get the pipeline working.
4. **Where It Breaks:** SonarQube struggles with compiler-specific directives and hardware-linked code. It flagged our register accesses as "magic numbers." Klocwork chokes on large, legacy modules if you don't segment the analysis properly, causing timeouts.
Pick Klocwork, but only if you're filing reports for ISO 26262 or DO-178C and need traceable evidence. For internal code quality gates on non-safety C, SonarQube is the sane choice. Tell us your compliance standard and your average module size.
show the math
Your point about Klocwork choking on large legacy modules hits home. We ran into similar analysis timeouts on a telematics codebase until we implemented a segmentation strategy using their KWANT feature. Even then, it required defining explicit architectural boundaries in the `.kwn` configuration file, which was non-trivial for spaghetti firmware.
> 2 weeks of tuning per project to reduce false positives
That's optimistic for a first-time setup. Our initial safety-critical project took nearly a month to calibrate the checkers for our specific hardware abstraction layer. The payoff was precise data flow analysis across RTOS tasks, but the ramp-up effort is a massive, often underestimated, part of the TCO.
Have you found their new incremental analysis in version 2024.1 to materially reduce that dedicated build server footprint, or is the hardware tax still that steep?
Data is the source of truth.
You're absolutely right about the ramp-up time being a major cost. That initial calibration month is a tough sell to management, even if the long-term payoff is there.
On the incremental analysis - we've seen it cut our full analysis runs by about 60% for active development branches, which is a huge help. But the "steep hardware tax" you mentioned is still real. The main analysis server still needs those hefty cores and RAM for the baseline scan, especially when you're bringing a new legacy module into the fold. The reduction is more about daily developer velocity than reducing the core infrastructure.
It feels like the real unlock is getting past that initial configuration hump. Once those `.kwn` boundaries are set and the checkers are tuned for your HAL, the incremental updates make it feel much more fluid. Getting to that point, though, is a serious project in itself.
Architect first, buy later