Regardless of industry, any company writing code understands the need for standardization and proof-checking, and the medical device sector is no different. What is different is the emphasis on safety, quality, performance, and security. While a lot of businesses have a standard practice they follow, Velentium is here to shine a light on how static analysis, dynamic analysis, and more specifically, unit testing, can be developed and best applied to the development lifecycle for secure medical device software.
One of Velentium’s Principal System Architect & Engineers, Satyajit Ketkar (Sat), will explain how companies can adopt these best practices, as well as show in detailed steps the way Velentium accomplishes specific tasks internally using the software Parasoft. Sat has nineteen (19) years of engineering experience with seven (7) of those years within medical device design. A majority of his career has revolved around electrical, firmware, software and systems engineering but recently he spent over eighteen (18) months working for a European Union notified body. This experience allowed him to see product development in a different way, teaching him how to review and audit products for safety and, quality, performance, and security.
We’ll finish out the series with a how-to guide aimed at configuring Parasoft for testing in medical device development, which is the tool we’ve identified as providing all the functionality we require at the best price point. With that final post, we’ll release a free download of our configuration guide; and, as always, if you’d rather not wait for each blog post to come out, you can click here to download our free Static & Dynamic Analysis White Paper.
What is Static Analysis?
Static analysis, also called static code analysis, is a method of computer program review and debugging that is done by examining the code without executing the program. The process provides an understanding of the code structure and helps to ensure that the code adheres to industry standards. By running the source code through a set of predetermined criteria, called checkers, static analysis tools expose various types of flaws in the code. Static analysis tools function independently of compilers, linkers, and hardware, and can analyze the most commonly utilized languages, C and C++.
Limitations of Static Analysis
Current Static analysis tools do not replace traditional code review entirely, but they make the code review process more efficient and productive. The next generation of static analysis tools do show promise of improved automation of the code review process, and with further development, this could become possible in the future.
Static analysis also cannot look for correctness based on the intent of the developer. For example, if you have a function that is called multiply(A, B), but when executed, it returns A plus B, the analyzer cannot determine whether the developer’s intent was to multiply or add A and B. Since this method of analysis does not execute the code or compare results with purpose, the possible bug would not be considered a violation or caught.
Another limitation with this method is that it cannot detect and enforce a developer’s specific coding style unless the parameters of that style are manually defined and input before running the analysis. Even then, results may vary.
Static analysis occasionally reports false positives (saying there is a problem when there isn’t one) and false negatives (assuming there isn’t a problem when there is one). Fortunately, each generation of static analysis technology is continuing to decrease the occurrences of these flaws. In the 1970s, the false negative and positive rates were 25-40%. By the 1990s, these rates were in the 10% range; today, false positive and negative rates have improved to less than 1%.
Historical Overview
The concept of static analysis was first introduced by Alan Turing in 1936 as he attempted to address the halting problem during his team’s work on the Enigma machine.
Not much additional development occurred after Turing until the 1970s, when safety-critical firmware and software needed to be interpreted and checked for programming errors, suspicious constructs, bugs, and stylistic errors before they were executed. Tools designed for this purpose were called Linters, and the most popular one was Lint (now PC-lint).
Static analysis tools have continuously evolved, and some, like PC-lint, are still being put to good use today. However, most of the activities that first-generation “linters” performed have since been incorporated into today’s compilers.
The 1990s brought several changes to static analysis. Accommodating code standards such as the then-new C89, beginning to address code quality and metrics, and decreasing the rates of false positives and negatives. One of the standard tools at the time was Coverity, which is less popular today, but was a pioneer in code quality analysis, checking issues like explicit casting and variable consistency.
In the early 2000s, the automotive, oil and gas, aerospace, medical, and other high-risk industries came together to establish standards for safe and secure code development. The third generation of static analysis began to emphasize safety, security, and higher standards for code quality. At the same time, static analysis concepts were adopted by large corporations. Microsoft, for example, incorporated some into their Intellisense IDs. Meanwhile, Lint, Coverity, and others released plug-ins for large-scale configuration management systems.
Static analysis tools have incorporated new standards based on C99 and further improved the false positive and false negative report rate to below 1%. One of the more popular tools currently is Parasoft, which not only conforms to industry standards but goes beyond those standards with a host of additional configurable checks available as well (which we’ll discuss in-depth later).
Next time, we’ll address some of the philosophy behind static analysis and software standards, as encoded in regulatory guidances and industry standards applicable to medical device software. If you’d rather not wait, click here to download our free white paper!