This document discusses quality initiatives for industrial software and firmware at Schneider Electric. It outlines the company's focus on reliability, architecture, maintainability, and evolvability through practices like increasing automated unit testing, using UML models, reducing complexity, and ensuring modularity. Quality is managed through processes for escalating issues, releasing new versions and service packs, and using tools for static analysis, code coverage, complexity metrics, and coding rule checks. The goal is continuous quality improvement to meet rising customer expectations.

1. 1
Quality in Industrial Software
Schneider Electric
Automation
Speaker : Jerôme Firmin
General Manager for PLC Software

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. Division - Name - Date - Language 3
From Enterprise to Plant floor
 Information
 Control
(PLC: Programming
Logical Controller)
 Device

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. 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. Division - Name - Date - Language 6
Our Software locations
North Andover
(BOSTON)
Seligenstadt
(Frankfurt)
Sophia-Antipolis
(Nice)
Bangalore
(India)
Shanghaï
(China)

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. 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. 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. 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. 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. 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. 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. 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. Division - Name - Date - Language 15
Unit Tests managed in a home-made repository
 Unit Tests database for tracking scenarios plans & reports

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