Minimize the risk of downtime through Defensive Programming

'Can happen'. In earlier days, it sometimes sounded as if it was acceptable when an installation was down for a minute or more. Nowadays, however, downtime can count on a lot less mercy, and everything is done to reduce stoppage times to zero. Defensive Programming is becoming one of the main focuses within this continuous pursuit of efficiency. But what exactly does this complex concept stand for?

Reducing downtime

It should go without saying that the duration of a jam has an exponential impact on the profitability of a manufacturing company, especially when there are few buffers. If there is a breakdown in the supply of raw materials, then not only is the assembly or mixing of those same raw materials disrupted, but the logistical follow-up will also be severely impacted. Therefore, not only the machines, but certainly the software on which all processes run, should preferably be free of errors. But how can you achieve this?

‘What’ vs ‘How’

Today, companies' expectations of software are mainly functional: 'Can this software control this process?' However, seldom does the way the code is written enjoy the same attention. ‘Have the right safety nets been provided to anticipate expected or unexpected failures?’ In short: the present-day focus is mainly on the goal, while little attention is paid to the way in which you should achieve that goal.

"Too often, companies focus on the functional aspect of software, without giving that same attention to the way that software code is written. The result: repeated downtime and limited insight."

Moreover, the 'How' (the way in which the code is written) all too often turns out to be linked to the individual (person-specific). This is because every programmer sooner or later will run into certain problems and, based on that experience, will gain knowledge on how to solve these bugs or come up with tricks to prevent them from happening in the first place. However, if this programmer leaves the company that provides you with your software, or simply makes a mistake, this can lead to errors being repeated time and time again. With all the consequences this will have.

However, we should not be too pessimistic: after all, companies will already be unwittingly protecting themselves against some problems. Just think of a calculation protection, for example, to catch a division by 0, a common software bug in PLC programs that causes the PLC (and therefore the controlled installation) to crash. Such division by 0 has nothing to do with the functionality of a process, but when it occurs, it will cause the whole installation to stop. In most cases, this potential deadlock can only be resolved by the intervention of a software programmer. It is therefore logical that many companies already protect themselves against such a zero crossing.

But there is still room for improvement...

More deliberate and less person-specific coding

In order to program a code as deliberately and person-independently as possible, an digitizing expert such as Yitch uses Defensive Programming as a directive to ensure that as few software bugs as possible can occur on-site on a running application. Defensive Programming has nothing to do with security or protecting against cyber attacks, but purely refers to the anticipation of machine downtime by incorporating certain safety measures into the software code.

"With Defensive Programming, a relatively unknown concept originating from IT that is increasingly finding its way into Factory Automation, we at Yitch are committed to making the understanding of software safety nets in the code commonplace, and to ensuring that they are used with awareness in order to reduce downtime," says Sander Verbruggen, Team Lead Automation at Yitch. "The guidelines and best practices for this are carefully stored within our company and continuously updated, so that our Junior profiles can benefit from Senior experience, so to speak. In this way, we succeed in anticipating any bugs right from the start.”

"With Defensive Programming Yitch shows its commitment in making the understanding of software safety nets in the code commonplace, in order to reduce downtime."

When a bug is first found, it is reported immediately by the Yitchies and then converted into guidelines. At this point, most bugs are accurately described in the guidelines, so there can be no discussion whatsoever concerning a lack of knowledge.

Screening of existing systems through the Yitch-Quickscan

Besides the set-up of new software systems, compliant with the Defensive Programming philosophy, Yitch also focuses on examining existing systems. As many companies have their software written by third parties, who ensure that it meets functional requirements, these clients often have no idea or grip of/on how software is written. 'Was it written according to best practices? Are there sufficient safety nets built in, so that the installation is not risking a shutdown because of a bug?' Yitch reaches out to these companies, so that they can avoid downtime caused by software bugs.

"Was our code written in according to best practices? Are there sufficient safety nets built in, so that we don't risk a shutdown because of a bug?"

"Through an audit of existing systems, we can find out where optimization is possible by integrating software safety nets. Through such an audit, we can provide companies with an insightful status of their software (including non-compliances and possible improvement actions) through a report.”

Iterative testing focused on quality

Yitch firmly insists on quality control through the so-called ‘4 eyes principle’, which means that the code is checked each time by a different programmer. This quality control is done in an iterative way, which implies that the check is not done once, but frequently throughout the entire digitization and automation project of a company. Only by doing so will it be possible to intervene in time, to adjust certain philosophical concepts, and thus to apply Defensive Programming properly.

A few real-life examples

1. A classic example of bugs that can creep into software is one in which the standard failure of an analog card of a mixer is mistakenly considered to be a hardware failure in the code. As a result, all the inputs immediately fail, including the signals coming from a tank's level measurement, causing the tank to start overflowing. By starting to interpret this in a different way, taking this hardware failure into account in the software as well, and stopping the filling process when the card failure occurred, further product loss can be avoided.
    
2. Another example is when a PLC goes into shutdown when the cycle time is exceeded because of a glitch somewhere in the software. However, this implies that everything will stop and the entire installation will come to a standstill. Defensive Programming can also be helpful here.
    
3. A third example concerns processes that use tables. If the pointers/references or sequences are not restricted, and can exceed the range of the table (e.g. get a value of 101 when the range was only supposed to go from 0 to 100), then the PLC will stop as well, with the same consequences as the above situation. In accordance with the logic of Defensive Programming, Yitch can both make sure that no action will be taken when a certain, erroneous value is entered, but also prevent that value from being entered at all.

In conclusion

When it comes to writing code, most companies require it to be done according to best practices. Yitch not only uses Object Oriented Programming for this, but also a number of standards that must be applied, such as the ISA-88 or -95 models. The Defensive Programming ideology, as neatly listed in the Yitch guidelines, assumes that something can still occur in an impossible way, as cited by Murphy's Law. Apart from all the different ways in which that error can occur - hardware-based, software-based or human - Defensive Programming's main goal is to be able to prevent bad consequences, such as increasing downtime.

Eager to learn more about our services