This is a presentation by Thierry Coq (Principal Consultant of DNV) and Denis Chalon (Technical Director of Itris Automation Square). It was presented during the Club Automation debates day, on November 22nd 2011 : "Quality Model for Industrial Automation - Safe design of control applications" Find us at http://www.itris-automation.com/ Contact us at commercial@itris-automation.com for more information.

1. Quality Model for Industrial Automation
Safe design of control applications
Tuesday, November 22nd, 2011
Thierry COQ Denis CHALON
thierry.coq@dnv.com
System and Software Reliability
denis.chalon@automationsquare.com 1
Principal Consultant Technical Director

2. Content
 Software - apprehension or apprehension
 Software quality in traditional computing
 Application to automation
 Real Case study – DNV Audit
 Quality model’s thresholds for automation
 Conclusions
2
All rights reserved

3. Software is everywhere
 Increasingly complex applications
- More variables, more I/Os, more treatments
- Applications distributed over several PLCs
 Replacing hardware functions by software features (more flexible, cheaper)
 The development is mostly subcontracted
 Re-use of already developed libraries
3
All rights reserved

4. Apprehension of software
 Where is software? How is its integrity managed over its life span?
What is the quality delivered by our suppliers? How to ensure that suppliers are
qualified?
 What are the causes of software errors? How can we trust software corrections
later in the project? And during the operation?
 How to prevent delays?
4
All rights reserved

5. Stakeholders around software
Client Methods Project Manager Automation Engineer
 Different jobs
 Very different environments and tools
 Knowledge hardly shared
 Software is more difficult to grasp than mechanical and electrical controls
Different levels of focus required:
14mm 120mm 400mm
5
All rights reserved

6. How is software perceived ?
Client
PLC 1 PLC 2 PLC 3 Methods
PLC 4 PLC 5 PLC 6
? PLC 7Always down,
PLC 8 PLC 9
maintenance complains,
poor performance
Unreadable,
no test,
late
?
? Unfinished,
complicated,
important
Quick, quick,
Done before,
copy/paste 400mm fix
Projet Manager Automation Engineer
6
All rights reserved

7. Need to make software visible
Client Always down,
maintenance complains, Quick, quick,
average performance Done before,
copy/paste...
Methods
Unreadable,
Software must be measurable: no test,
Projet Manager - objectively late
- repeatedly
This measure must be shared
by all stakeholders
Automation Engineer Unfinished,
complicated,
Important…
7
All rights reserved

8. Software quality in traditional computing
What do computer specialists do to make
software more visible?
How to define software quality?
How can we measure it?
Does measuring really make sense?
8
All rights reserved

9. A brief history of software quality
 1970's - Theory formalized by Mac Cabe
 1980's - Available tools (eg. Logiscope)
 1990's - Tools are mainly used for critical software
 2000's - Democratization of the monitoring methods:
 Automating data generation from source code
 Simplifying the use of quality measurement tools (no need for specialist anymore)
 Ergonomic user interfaces, tailored to different stakeholders
 Standardization of concepts (ISO9126)
"If you can not measure it,
you can not improve it."
(Lord Kelvin) 9
All rights reserved

10. Principle of a quality model
ergonomics operational reliability
maintenance cost features
bug detection rate performance
EXTERNAL
CMMI exceptions handling
ISO9126
coupling reusability
architecture
INTERNAL
reliability
testability
scalability
fault tolerance
efficiency
maintainability readability
comprehensibility code complexity
10
All rights reserved

11. Quality monitoring cycle
Dashboards
Client Methods
Decides Follows
4 3
Automatic operation
Analysis model
Analysis tool
Automatic operation
Controls
2'
Source
Analysis results code
Projet manager
2 Corrects
Automation engineer
1 11
Develops Development
workshop

12. Quality model
Client
Methods
Comment ratio
No GOTO
Reusability
Project Manager Comprehensibility …
Maintainability
Readability
Effectiveness
Scalability
Automation Engineer Reliability
Testability
Sub-attributes Measure and
Attributes of the program
verification points
12
All rights reserved

13. Analysis model
The “fctn_vannes” Measure 1
function has 67
lines of code The program has
Measure 2 Analysis Attribute 1
a good testability
model
Measure 3 Attribute 2
...
Attribute 3
Measure N
The “cbfe_34” Attribute 4
variable has Verification 1
no comment Attribute 5
Verification 2 ...
... Attribute N
Verification N
13
All rights reserved

14. Characteristics of the SQALE method
 The SQALE method takes into account the entire life cycle of the software, including maintenance,
renovation and reuse.
 The program features are hierarchical:
 Who wants to reuse a non reliable program?
 Who can demonstrate the reliability of a non testable program?
 The result is a measurement of a technical debt:
 How much does it cost to have a quality program from the
current situation?
 The problems to be solved are counted once on the attribute
with the highest priority
- The quality properties are regarded as independent
 The methods tells you where to start
 SQALE is independent from a language and from a specific technology
- The results are directly comparable from one program to another
 Contrary to ISO9126, SQALE applies directly, does not require to be interpreted
 SQALE is automated and economical to implement. It is standardized.
14
http://www.sqale.org/ All rights reserved

15. Application to industrial automation
What software analysis should be used?
- cross-PLC brands
- 5 languages of IEC-61131
Which quality model should be implemented?
- transposition of the quality models of traditional
computing
- specificities of industrial automation
Which tools for stakeholders?
- how to cope with the diversity of stakeholders?
- how to manage outsourcing?
15
All rights reserved

16. One solution
Dashboard
Quality model
The black box is open to
all stakeholders…
Software analysis tool
Workshops
5 IEC languages
16
All rights reserved

17. Control engineer and software
Client
Solved problems:
Make objective the non-functional evaluation
of the program
Methods Positive feedback on the programming
practices
Higher level view than just the application
under development
Project Manager
Automation Engineer
17
All rights reserved

18. Project Manager and software
Client
Solved problems:
 Quality monitoring
 Monitoring the progress of the project The dashboard allows
Methods navigation from overall
 Benchmarking vision to detail
Project Manager
80-400mm
Automation Engineer It also allows a temporal
monitoring of the project’s
progress
18
All rights reserved

19. Methods and software
Client
Solved problems:
 Taking into account existing data
 Verify that specifications and code match
Methods
Formalization and sharing of development
methods
 Transversal software indicators 24-120mm
Project Manager
Automation Engineer
19
All rights reserved

20. The end client and software
Client
Solved problems:
 Simplify decision making on the means
to assign, according to an objective view
Methods Possible correlation with other sources
of information available in the plant
Project Manager PLC 1 PLC 2 PLC 3
PLC 4 PLC 5 PLC 6
Automation Engineer
10-24mm
PLC 7 PLC 8 PLC 9
20
All rights reserved

21. Real case study – The DNV Audit
Is it usable in real life?
How to implement it?
How much time is saved?
21
All rights reserved

22. PLC program audit
 Need: risk management
 Client: DNV, Malmö, Sweden
 Function: PLC in charge of controlling the lay tower on a boat
 PLC: Rockwell RSLogix 5000
 Analysis tool: PLC Checker
 Method: SQALE
Unrepresentative image of the boat in question
22
All rights reserved

23. Code audit : the need
 Objectives:
- Identification of key risks associated with software
 Scope:
- Software for control systems of the lay tower
- Reliability, maintainability and dependability of the tower
 Actions: manual and automated code review
- Functional analysis of the software application
- Analysis of the development process
- Specifications, design, coding, unit testing, integration testing and acceptance testing
- Analysis of the internal quality of the software application: SQALE
23
All rights reserved

24. Code Audit : SQALE analysis
 LADDER code, about 7000 code locations
 Normalized index figures
 Most common problems:
- Testability: variables written in several places, dead code, important complexity,
code in comments
- Reliability: variables are read before being written
- Maintainability: uncommented code
24
All rights reserved

25. Code Audit : the results
 Consistent with other SQALE results for other languages (traditional computing)
 The results are better than what is usually observed
 Consistent with manual code reviews and “top ten” verifications
 Some persistent difficulties with the tools have to be solved
- Interaction between the program and the HMI may not be identified automatically
- Copy / paste of code not yet detected
 Final comment of the Swedish client:
« The SQALE analysis provided a very valuable complement to the manual part of the
software review »
« While the manual review focused on thoroughly checking selects parts of the code,
the SQALE analysis measured defined quality characteristics of the complete code »
25
All rights reserved

26. How to validate that the thresholds of the quality model
are suitable for automation?
Why would a traditional computing quality model
suit the IEC languages?
How to tune the model to ensure a good match
between the ratings and the actual quality?
26
All rights reserved

27. A study based on real life programs
 Step 1: Formalization of measurements to be made on the programs
 Step 2: Creation of a client program database
- No test program
- Multi-PLC (Schneider Electric PL7 Pro and Unity Pro, Siemens Step7, Rockwell
RSLogix5000)
Step 3: Running the analyzer (PLC Checker) on each program with formalized
measures
 Step 4: Analysis of results
- Results per PLC
- Results of all PLCs combined
- Definition of thresholds
27
All rights reserved

28. A few figures
 ~25 measures
 ~300 PLC codes Step7, Unity Pro, PL7 Pro and RSLogix5000
 ~180 000 Program Organisation Units (POUs)
 ~2 500 000 instructions
 ~2 000 000 variables
 55 hours of calculation
 Results: 112MB of raw data to analyse
28
All rights reserved

29. Definition of thresholds
The quality model is not elitist, it must correspond to the actual use:
 50%: A
 75%: A or B
 90%: A, B or C
Acceptance criterion
 95%: A, B, C or D
 97,5%: A, B, C, D or E
 99%: A, B, C, D, E or F
29
All rights reserved

30. Number of lines of code
APPLICATIONS PROGRAM ORGANIZATION UNITS
No quality criteria on the size of the Ensure that each POU has a reasonable
application, just an information size
 Analysed applications are up to 60,000  90% of POUs have less than 100 lines
lines of code of code
 50% <10 000 lines  The threshold is comparable to what is
recommended in traditional computing
30
All rights reserved

31. Complexity of the codes
 Are programs easy to understand?
 Two different complexities:
- cyclomatic complexity, essential complexity
- in both cases, the thresholds are in line
with the levels seen in traditional computing:
 eV(G) < 5
Acceptance criterion
 V(G) < 15
 Most automation engineers already
program correctly
Beware! The cyclomatic complexity is
not available as such on all languages
​(limitations on graphical languages​​ :
SFC, FBD and LD).
Acceptance criterion
31
All rights reserved

32. Level of comments of codes
 Are applications well commented?
 Elements within the program:
50% of all applications have a comment ratio
greater than 85%
 75% have a ratio greater than 70%
 90% have a ratio greater than 60%
 Check on size of comments
 Density of comments in the code:
50% of all applications have a density of
comments greater than 67%
Acceptance criterion  75% have a density greater than 57%
 90% have a density greater than 52%
32
All rights reserved

33. Conclusion
 Low dispersion on very general measurements
 PLC programs are comparable with one another regardless of their functionality
 The quality model used in the experiment is sound
The complexity thresholds used in traditional computing can also be used in
automation, with the following restrictions:
- have to be tuned for graphical languages ​(SFC, FBD and LD)
- detection limits on copy/pasted codes
- has to take into account typical malpractices
33
All rights reserved

34. Conclusion
How to participate?
How to use?
I have a use case, what to do?
Can I adapt all of this to my needs?
For more information
34
All rights reserved

35. Key Takeaways
The late discovery of bugs and low quality is costly. The monitoring of quality
during the life cycle prevents it:
Thanks to the democratization of quality control, with the following parts…
- Dashboards that allow navigation between high and low level view
- Analysis tools automatically generating data
- Quality models implementing ISO 9126
…That are applicable and suitable for automation:
- Cross-PLC brands support
- Support of all languages of the IEC-61131​
Calling all end users and
integrators
Invitation to participate in
To go further, we are looking for: motivated industrial end the development of a
users and system integrators, willing to participate in the Quality Model adapted to PLCs
improvement of a quality model suitable for automation Please contact DNV or IAS
35
All rights reserved

36. Want to know more?
Software quality on Wikipédia -
http://en.wikipedia.org/wiki/Software_quality
SQALE website - http://www.sqale.org/
Der Norske Veritas - http://www.dnv.com/
Itris Automation Square –
http://www.automationsquare.com/plc-checker.html
SQUORING - http://www.squoring.com/en
Inspearit - http://www.inspearit.com/en/
Denis CHALON Thierry COQ
denis.chalon@automationsquare.com 36
thierry.coq@dnv.com
All rights reserved
Technical Director Principal consultant