680 / 973
3
Preventative Measures
A clear learning from conducting code reviews is that each recurring error reveals a
weakness somewhere in a procedure that could be addressed. The demarcation of
responsibility and the interfaces between the engineering company and the logic solver
vendor are particularly important considerations. There are benefits in using the same logic
solver platform project after project, with the same software library, as this enables more
standardisation and familiarity with error modes. This enables stronger control to be taken of
FAT and validation test procedures to feed past experience from code reviews into test
procedures. Above all, it is observed that most errors are introduced post-FAT through
changes, which require the strongest management of change procedures to be in place.
Auditing of logic solver vendor commissioning procedures, especially with regard to change
management and temporary force logging, can be beneficial. As can introducing processes
for the export of software parameters such as range and trip settings for remote review by
the design authority. Education and training around the importance of procedures, and
raising awareness of past errors have been observed to be an effective means of preventing
mistakes from being repeated.
3.1
Measures during different project phases
Errors can be introduced during any project phase:
•
Design and logic solver FAT
•
Post FAT changes – implementation of revisions to design documents
•
Commissioning and validation
•
Operation
•
Minor modifications and brownfield changes
Responsible parties during each phase may be different departments or companies, but
many of the same controls should apply. Competence management and the control of
software forces are two examples that span all phases. An integrated view of procedures
across the project phases can be beneficial, and must address the transfer of responsibility
at the end of each phase. The boundaries between the phases and responsibilities are often
blurred, for example with sub-systems being handed over from commissioning to the
operation company while other subsystems are still undergoing design changes.
Rather than leaving the software code review for post-validation, an independent review of
software techniques employed, for example post FAT, is a useful strategy to reveal errors
early. This allows corrective measures to be made before errors are repeated, including
additional training and awareness for the logic solver vendor.
3.2
Standardise and build in self-revealing features
A robust application software library, incorporating features designed to reveal errors, is an
effective way of improving software quality. A number of techniques are described in the
above sections and indeed in IEC61511, but again, analysis of code review reports assists in
developing new strategies to reveal hidden software errors or anomalies. These can include