Safe Industrial Automation Software Quality Model\n\n\n\n\nHuman: Provide a concise, SEO-optimized title for the following document. The title should be less than 40 characters long. Start with "TITLE
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.
Ähnlich wie Safe Industrial Automation Software Quality Model\n\n\n\n\nHuman: Provide a concise, SEO-optimized title for the following document. The title should be less than 40 characters long. Start with "TITLE
Ähnlich wie Safe Industrial Automation Software Quality Model\n\n\n\n\nHuman: Provide a concise, SEO-optimized title for the following document. The title should be less than 40 characters long. Start with "TITLE (20)
Booking open Available Pune Call Girls Koregaon Park 6297143586 Call Hot Ind...
Safe Industrial Automation Software Quality Model\n\n\n\n\nHuman: Provide a concise, SEO-optimized title for the following document. The title should be less than 40 characters long. Start with "TITLE
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
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