Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

20070925 03 - La qualimétrie en environnement industriel (Schneider automation)

50 views

Published on

Quality in industrial software

Published in: Software
  • Be the first to comment

  • Be the first to like this

20070925 03 - La qualimétrie en environnement industriel (Schneider automation)

  1. 1. 1 Quality in Industrial Software Schneider Electric Automation Speaker : Jerôme Firmin General Manager for PLC Software
  2. 2. Division - Name - Date - Language 2 Table of Content  “Automation World” : what are we doing in Software & Firmware ?  “Customer Attitude” : how do we manage Quality issues ?  “Quality Focus” : what are our priorities for implementing Quality in our development ?  Highlights
  3. 3. Division - Name - Date - Language 3 From Enterprise to Plant floor  Information  Control (PLC: Programming Logical Controller)  Device
  4. 4. Division - Name - Date - Language 4 Software on PC & Embedded Firmware in PLC IT integration Maintenance User Interface Standardization Connectivity User Configuration & Programming SAFETY
  5. 5. Division - Name - Date - Language 5 Some numbers for our Software & Firmware A single Software on PC 2,7 Millions of C++ lines of code 65 000 files under source control 350 software components 5100 classes 70.000 methods 11 OS Firmware in PLC 325 000 C and C++ lines of code 1 400 files under source control 30 software components
  6. 6. Division - Name - Date - Language 6 Our Software locations North Andover (BOSTON) Seligenstadt (Frankfurt) Sophia-Antipolis (Nice) Bangalore (India) Shanghaï (China)
  7. 7. Division - Name - Date - Language 7 Table of Content  “Automation World” : what are we doing in Software & Firmware ?  “Customer Attitude” : how do we manage Quality issues ?  “Quality Focus” : what are our priorities for implementing Quality in our development ?  Highlights
  8. 8. Division - Name - Date - Language 8 Software Quality cases escalation  Escalation from Country to Centralized Support – Daily Basis  Raised when a technical question or issue cannot be answered locally Daily basis Processes managed under Rational ClearQuest Rational http://www.ibm.com/developerworks/rational  Critical Issue : raised due to risk of losing a Customer when the normal process has failed – Interruption process  Managed by a sponsor with priority n°1 for all contributors  Customer regularly updated on the status until case is closed  Product Safety Alert : raised when bodily injury and/or property damage has occurred/can occur  Any employee can raise a PSA  Early containment and communication made to users
  9. 9. Division - Name - Date - Language 9 How do we deliver Quality to our customers ?  New version of the software & firmware – Unity Pro V3.0, V3.1 …  Added features  A set of bug fixing  Service Pack between versions – Unity Pro V3.0 SP1  A set of bug fixing  Delivered on public web site  Hot fix  A targeted fix for a dedicated customer – No public distribution With strong rules for Traceability and Compatibility Managed by intensive use of Rational ClearCase & ClearQuest http://www.ibm.com/developerworks/rational
  10. 10. Division - Name - Date - Language 10 Table of Content  “Automation World” : what are we doing in Software & Firmware ?  “Customer Attitude” : how do we manage Quality issues ?  “Quality Focus” : what are our priorities for implementing Quality in our development ?  Highlights
  11. 11. Division - Name - Date - Language 11 From market needs to validated solutions Customer requirement (More & More System view) Customer usability (System, Interoperability) Schneider product & system requirement (Technical invariants...) System Validation (Limits , Robustness, Performances Compatibilities) Product specification Product verification & certification Incremental design Customer Customer Incremental verification Unit Test Use of Rational Robot
  12. 12. Division - Name - Date - Language 12 What Quality factors did we choose as priorities ?  Reliability  Increase quality of code “at the source”  Extend / Automate Unit Tests coverage and smart non regression  Improve customer orientation for Verification & Validation scenarios  Architecture  Use UML models for use case description and evolution  Always updated Hands book for developers / architects  Maintainability  Check and reduce complexity  Push for code documentation and do & “just enough” in specification  Define and check coding rules  Evolutivity  Ensure / solidify modularity of components  Enable maximum openness (API, XML source format)
  13. 13. Division - Name - Date - Language 13  Easy to setup  Easy to use for developers  Personalized pages  Reports are clear  Good customization  Web based architecture  Support for COM  Very little false positive rate  Deep analysis  Excellent support Coverity Prevent for Software static code analysis http://www.coverity.com/
  14. 14. Division - Name - Date - Language 14  Widely used for embedded systems  Full data ranges of variables are analyzed  Clear testimonial : Analyzed software is free of bugs  MISRA checks embedded Polyspace for Firmware static code analysis http://www.polyspace.com/ (now MathWorks)
  15. 15. Division - Name - Date - Language 15 Unit Tests managed in a home-made repository  Unit Tests database for tracking scenarios plans & reports
  16. 16. Division - Name - Date - Language 16 Unit Tests based on CppUnit and internal GUIs  Strong push for automating Unit tests at development time, specially for the very sensitive area of code generation for PLC http://sourceforge.net/projects/cppunit
  17. 17. Division - Name - Date - Language 17 What Quality factors did we choose as priorities ?  Reliability  Increase quality of code “at the source”  Extend / Automate Unit Tests coverage and smart non regression  Improve customer orientation for Verification & Validation scenarios  Architecture  Use UML models for use case description and evolution  Always updated Hands book for developers / architects  Maintainability  Check and reduce complexity  Push for code documentation and do & “just enough” in specification  Define and check coding rules  Evolutivity  Ensure / solidify modularity of components  Enable maximum openness (API, XML source format)
  18. 18. Division - Name - Date - Language 18  Code execution coverage  Good results achieved with PureCoverage  Cantata++ under evaluation  TrueCoverage (DevPartnerStudio) under evaluation Code coverage http://www-306.ibm.com/software/awdtools/purecoverage/support/index.html http://www.ipl.com/products/tools/pt400.uk.php http://www.compuware.com/products/devpartner/default.htm
  19. 19. Division - Name - Date - Language 19 What Quality factors did we choose as priorities ?  Reliability  Increase quality of code “at the source”  Extend / Automate Unit Tests coverage and smart non regression  Improve customer orientation for Verification & Validation scenarios  Architecture  Use UML models for use case description and evolution  Always updated Hands book for developers / architects  Maintainability  Check and reduce complexity  Push for code documentation and do & “just enough” in specification  Define and check coding rules  Evolutivity  Ensure / solidify modularity of components  Enable maximum openness (API, XML source format)
  20. 20. Division - Name - Date - Language 20  Internal Metrics platform  We have a historical base from V1 to current version – Base indicators & derived Maintainability Index (using standard formula from SEI) – Our Unity software has a good maintainability in average  External Metrics platform on going evaluation  CAST http://www.castsoftware.com/  SQUALE- open source http://www.qualixo.com/  Coding rules checking  Good results achieved with C++Test – For use on new projects Complexity metrics, Coding Rules  http://www.parasoft.com/jsp/products/home.jsp?product=CppTest
  21. 21. Division - Name - Date - Language 21 Typical process for Firmware INTEGRATION phase Investigation and CODING UNIT TESTS CODE REVIEW Automated tests (Rational Tests) Coding rules review (RSM) Fault insertion tests Code instrumentation Source code Test report (Instrumentation + Fault insertion) Code Review report Automatic Test report Qualimetry report IS3 Developpement process [CODING] Test SCRIPT (RTRT) Reworking if error ClearCase Versionned files Excel sheet per activity Html RTRT report RSM excel report Peer review by other developper Report review Report review Report review Report review Functional tests and Automatic tests are launched again during integration Notations Reworking loop Added for IS3 (In Red) Process phase Standard Dev. process
  22. 22. Division - Name - Date - Language 22 Quality : No conclusion but a permanent improvement  Our customers expect us to deal professionally with issues  A problem permanently solved is a loyalty booster

×