DSS Front End Software Review A ‘quick’ look at the PLC code

Introduction (disclaimer) Nothing like a formal review, but rather a personal ‘look at the code’ The reviewer is not a great PLC programming expert, but has basic knowledge on Step7 and its concepts and some ‘hands on’ experience in the past Will limit to general observations here DSS Advisory Board 1 March 2004

Some facts The review was done Dec 2003/Jan 2004 Reviewed a version of the PLC code as it was 10 December 2003 ‘Paper review’, it did not involve any real life tests Only reviewed the PLC Siemens Step7 project DSS Advisory Board 1 March 2004

How it was done 1 afternoon introductory explanation by Stefan Detailed study of the code 1 afternoon discussion of my questions and findings with Stefan Write-up of the review (soon ) DSS Advisory Board 1 March 2004

General impressions Very good ! Project (code and data blocks) is very well structured Relatively easy to understand the code (structure, comments) Well defined interface with backend (through data in data blocks) DSS Advisory Board 1 March 2004

Observations Extensive self-checking of the whole DSS system (interrupt and timed) Every cycle well structured reading of inputs, calculation of alarm-action matrix and setting of outputs (coherent structure of all sub-routines) Had to make assumptions for complexity of alarm relations (relation between input parameters) Support DSS-team request for ‘most complex examples’ DSS Advisory Board 1 March 2004

Observations Currently implemented: Compare two analog values Two levels of ‘m out of n’ functions to construct complex logical functions Will cater for most common relations Specific functions could relatively easily be implemented, but PLCs are not designed for complicated mathematics DSS design paradigm is ‘simplicity’ DSS Advisory Board 1 March 2004

Observations Internal logging (locally on PLC): Masking All alarms, actions, etc. All DSS errors and status changes 8000 time stamped messages Masking Mechanism implemented at several points (coherency) e.g. input, calculation, output Its use is governed by the backend DSS Advisory Board 1 March 2004

Observations Only limited implementation of ‘consistency checking’. Impossible to implement all possible checks Responsibility delegated to Back-End DSS Advisory Board 1 March 2004

Findings Very minor inconsistencies in numbering of functions and datablocks Error in checking Analog input This part of code has been rewritten (more clearly) since Some ‘copy-paste’ errors DSS Advisory Board 1 March 2004

Findings Found a case where action could be triggered during 1 cycle when alarm disappears (under specific circumstances) Some room for improving performance has been identified But not exploited to preserve coherence and ease understanding of the code DSS Advisory Board 1 March 2004

Documentation Sufficient comments, and self-documenting to understand the project (with some introductory explanation) However, clearly additional documentation is essential Identified some aspects that would be desirable to document DSS Advisory Board 1 March 2004

Documentation Could see two levels of documentation: For users/configurators of DSS system To document what is implemented For developers (maintenance) of DSS system To document how and where it’s implemented Define procedures on how to change the system Hardware (new sensors/modules etc.) Software (configuration, code) DSS Advisory Board 1 March 2004

Conclusions Good overall impression Well structured Flexible enough and room for expansion Identified some minor points that are (or are being) corrected or looked at Code is generic enough to suit needs of the four experiments Some further tuning is possible/needed as more details are defined by the experiments Documentation need to be provided DSS Advisory Board 1 March 2004

Recommendations Urge experiments to provide examples of complex Alarm-Action relations And refine number of I/O’s and AA relations Review interaction FE  BE Produce two levels of documentation For users and for developers Define procedures for all type of modifications Keep original developer at least up to initial commissioning of all systems In any case, allow for ample overlap to transfer expertise DSS Advisory Board 1 March 2004