Our website uses cookies to enhance your browsing experience.
We’ll send a trial key to .
If you do not see the email in your inbox, please check if it is filtered to one of the following folders:
Webinar: Evaluation - 05.12
The PVS‑Studio static analyzer detects errors in code of programs written in C, C++, C#, and Java. The analyzer is highly effective in finding issues in embedded systems and other engineering projects.
The earlier an error is found, the cheaper it is to fix it. Static analysis detects errors at the code writing stage — or, at least, during night tests on the server. As a result, finding and fixing errors becomes way cheaper.
Static analysis may be especially helpful in debugging embedded systems.
In such projects, developers may face errors in software and device, or poor quality of the layout design (bad contacts, etc.).
Therefore, the process of searching for errors may take a long time, since it's not always clear where to search for one.
If a developer thinks that the code is correct, this may make circuit designers and other colleagues spend time searching for error in the hardware.
The more unpleasant it will be later to return to the program code and finally find a typo.
Inefficient use of the team's time and energy. It's great if a static analyzer finds such an error.
Here's how a developer described a similar case to us:
When I was a master's graduate, I started working for a company engaged in production of various custom devices. For example, automating greenhouses or collecting information from sensors at the enterprise that nothing has leaked or overheated anywhere.
I was assigned another typical task, which I finished in just a couple of hours and gave it to my colleagues to firmware into the device. They were surprised how quickly I did that, so I replied with "I'm a professional, writing such things is easy as one-two-three". They took the flash drive with a binary file for the firmware and went away.
I forgot about it right away. There were bigger and more interesting tasks to do. Moreover, since they did not return, everything was fine.
They did return. But only a week after that. They said: "We're confused. We don't understand anything. Our device isn't working. Or, rather, it's working but not quite as it should. We have already re-soldered it and replaced the executive electromechanical parts. It won't work... Would you take a look? Maybe there's something wrong with the program..." I looked at the code and see the following error:
uchar A[3]; .... for (uchar i = 0; i != 4; i++) average += A[i]; average /= 3;I took another my project as a basis and just copy-pasted most of the code. In one place I forgot to replace the number of sensors: 4 with 3. I was so ashamed that I made two people waste two weeks to search for my error.
Errors in embedded systems are extremely unpleasant. It's almost impossible to fix them, if the devices are already in the mass production. What if hundreds of thousands of washing machines have already been sold and used, but they don't work correctly in a certain mode? The question is rhetorical — there are only two options:
Moreover, regardless of whether the circulation of devices is large or small, error correction can be problematic or delayed:
The rocket crashed, the error was detected, but too late;
Patients died, the error was detected, but it won't bring people back;
The cars' brakes were broken, the error was detected, but victims had no benefit from it.
The conclusion is simple. The code of embedded systems should be tested as thoroughly as possible. Especially if errors may lead to casualties or serious material losses.
Static code analysis doesn't guarantee that there are no errors in code. However, developers need to use any means to additionally check code for bugs. Static analyzers can point out a variety of errors that manage to hide in code even after several code reviews.
If static analysis helps eliminate some errors in code, that will be great. Perhaps, thanks to the detection of these errors, human lives can be saved and a company won't lose the money and reputation.
Errors in software can be divided into two types. Developers know about the errors of the first type — they appear in code accidently or after a rush coding. The errors of the second type appear when developers don't know that writing code this way is wrong. In other words, they can review such code as many times as they want, but they still won't find the error.
To detect issues in code, static analyzers use a large knowledge base with patterns that under certain conditions lead to an error. That's why analyzers can warn developers about errors, the existence of which may not be discovered due to lack of knowledge. For example, using the 32-bit time_t type that can lead to a device malfunction after 2038.
Another example is undefined behavior due to an incorrect use of the <</>> shift operators. These operators are widely used in the microcontrollers' code. Unfortunately, developers often use these operators carelessly, thus making software unreliable and dependent on the compiler version and settings. The program may still work quite well — although, out of pure luck and not the corectness of code.
Using a static analyzer, developers can prevent such situation from happening. Besides, the analyzer can be used as a code quality control tool, which is important when the team grows or changes. In other words, static analysis helps check whether a new developer started writing bad code.
Development of embedded systems often involves the use of such standards as MISRA C, MISRA C++, AUTOSAR C++. Static analyzers help check code for compliance with these standards.
The standards are related and serve one purpose — enhance security, portability, and reliability of embedded software.
