Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

[EN] Club Automation presentation "Quality Model for Industrial Automation", Nov. 22nd 2011

2 001 vues

Publié le

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.

Publié dans : Ingénierie, Business, Technologie
  • We have released free online trial web application for PLC Checker. Just follow the link http://www.plcchecker.com/, select your PLC brand, and upload your PLC program. It is free. If you have any further question, please contact info@automationsquare.com.
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • Soyez le premier à aimer ceci

[EN] Club Automation presentation "Quality Model for Industrial Automation", Nov. 22nd 2011

  1. 1. Quality Model for Industrial Automation Safe design of control applications Tuesday, November 22nd, 2011Thierry COQ Denis CHALON thierry.coq@dnv.comSystem and Software Reliability denis.chalon@automationsquare.com 1 Principal Consultant Technical Director
  2. 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. 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. 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 arequalified? What are the causes of software errors? How can we trust software correctionslater in the project? And during the operation? How to prevent delays? 4 All rights reserved
  5. 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. 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 fixProjet Manager Automation Engineer 6 All rights reserved
  7. 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 stakeholdersAutomation Engineer Unfinished, complicated, Important… 7 All rights reserved
  8. 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. 9. A brief history of software quality 1970s - Theory formalized by Mac Cabe 1980s - Available tools (eg. Logiscope) 1990s - Tools are mainly used for critical software 2000s - 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. 10. Principle of a quality model ergonomics operational reliability maintenance cost features bug detection rate performance EXTERNALCMMI exceptions handling ISO9126 coupling reusability architecture INTERNAL reliability testability scalability fault tolerance efficiency maintainability readability comprehensibility code complexity 10 All rights reserved
  11. 11. Quality monitoring cycle Dashboards Client Methods Decides Follows 4 3 Automatic operation Analysis model Analysis tool Automatic operation Controls 2 Source Analysis results codeProjet manager 2 Corrects Automation engineer 1 11 Develops Development workshop
  12. 12. Quality model Client Methods Comment ratio No GOTO ReusabilityProject Manager Comprehensibility … Maintainability Readability Effectiveness ScalabilityAutomation Engineer Reliability Testability Sub-attributes Measure and Attributes of the program verification points 12 All rights reserved
  13. 13. Analysis modelThe “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. 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. 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. 16. One solutionDashboardQuality model The black box is open to all stakeholders…Software analysis toolWorkshops 5 IEC languages 16 All rights reserved
  17. 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 developmentProject ManagerAutomation Engineer 17 All rights reserved
  18. 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-400mmAutomation Engineer It also allows a temporal monitoring of the project’s progress 18 All rights reserved
  19. 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-120mmProject ManagerAutomation Engineer 19 All rights reserved
  20. 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 plantProject Manager PLC 1 PLC 2 PLC 3 PLC 4 PLC 5 PLC 6Automation Engineer 10-24mm PLC 7 PLC 8 PLC 9 20 All rights reserved
  21. 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. 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. 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. 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. 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 thesoftware 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. 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. 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 formalizedmeasures Step 4: Analysis of results - Results per PLC - Results of all PLCs combined - Definition of thresholds 27 All rights reserved
  28. 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. 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. 30. Number of lines of code APPLICATIONS PROGRAM ORGANIZATION UNITSNo quality criteria on the size of the Ensure that each POU has a reasonableapplication, just an information size Analysed applications are up to 60,000  90% of POUs have less than 100 lineslines of code of code 50% <10 000 lines  The threshold is comparable to what is recommended in traditional computing 30 All rights reserved
  31. 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) < 5Acceptance 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. 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. 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 inautomation, 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. 34. ConclusionHow 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. 35. Key TakeawaysThe late discovery of bugs and low quality is costly. The monitoring of qualityduring 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 inTo go further, we are looking for: motivated industrial end the development of ausers and system integrators, willing to participate in the Quality Model adapted to PLCsimprovement of a quality model suitable for automation Please contact DNV or IAS 35 All rights reserved
  36. 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 COQdenis.chalon@automationsquare.com 36 thierry.coq@dnv.com All rights reserved Technical Director Principal consultant

×