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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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