This document discusses the importance of risk management and software quality control for system integrators. It provides examples of costly failures from bugs in software that controlled spacecraft, medical devices, and networks. These examples demonstrate the need for coding standards, static analysis tools, and defensive programming techniques to detect and prevent bugs. The document advises system integrators to implement standards, verify code quality, educate customers on standards, and use static analysis tools to protect themselves from potential liability issues from software defects.

1. Risk management and business
protection with Coding
Standardization & Static Analyzer

2. SI Revenue & Specialties
The key of SI success is software development and IT management

3. Mars Polar Lander Crash
• Cost
– $125,000,000
• Disaster
– After a 286-day journey from
Earth, the Mars Climate Orbiter
fell too far into Mars’
atmosphere, causing it to crash
• Cause
– The software that controlled the
Orbiter thrusters used imperial
units (pounds of force), rather
than metric units (Newtons) as
specified by NASA

4. Ariane 5 Explosion
• Cost
– $500,000,000
• Disaster
– ESA’s Ariane 5 unmanned rocket
was intentionally destroyed
seconds after launch on its maiden
flight
– Also destroyed was its cargo of four
scientific satellites
• Cause
– When the guidance system tried to
convert the sideways rocket
velocity from 64-bits to 16-bits
format, an overflow error resulted
– When the system shut down,
control passed to an identical
redundant unit…

5. AT&T Lines Go Dead
• Cost
– 75,000,000 phone calls missed
– 200,000 airline reservations lost
• Disaster
– A single switch at one of AT&T’s 114
switching centers suffered a minor
mechanical problem and shut down the
center
– When the center came back up, it sent a
message to other switching centers, which
in turn caused them to shut down
– This brought down the entire AT&T network
for 9 hours
• Cause
– A single line of buggy code in a complex
software upgrade implemented to speed up
calling caused a ripple effect that shut down
the network

6. Medical Machine Kills (1985)
• Cost
– 3 people dead
– 3 people critically injured
• Disaster
– Therac-25 radiation
therapy machine delivered
lethal radiation doses to
patients
• Cause
– A subtle bug called a race
condition

7. World War III… Almost
• Cost
– Almost all of humanity
• Disaster
– Soviet early warning system
indicated the U.S. had
launched 5 ICBMs
– The human operator
thankfully interpreted this as
an error
• Cause
– A bug in the software failed to
filter out false missile
detections caused by sunlight
reflecting off cloud-tops

8. Your software?
How do you assess the quality of your software?

9. How do you protect yourself?
Why should system integrator care?
System Integrator Client
Service delivered
Law suit

10. Product Liability Legal Theories
• NEGLIGENCE
– Did you fail to act as a reasonably prudent person/plant
operator/manufacturer/installer/repairer would have acted under the
same or similar circumstances
• STRICT LIABILITY
– Whether a person has been injured by a product that was defective in
design or manufacture
– Unreasonably dangerous when it left the manufacturer’s control. You
may have been eminently reasonable, yet liable for a defect.
• BREACH OF WARRANTY
– This is a lesser applied theory but still available to an injured party. The
focus is on whether the product conformed to representations made by
the seller in writing, verbally, or implied by law.
Source: Legal Considerations for Safety - Rockwell Automation Safety Automation Forum - November 2011

11. Defective Condition
• Consumer Expectation Test:
– Whether the product failed to perform as safely as an
ordinary consumer would expect.
• Risk Utility Test:
– Whether the harm could have been avoided by
adopting a reasonable alternative design and on
balance the benefit of that design outweighs the risk.
– This test usually applies in cases involving more
complex products.
Source: Legal Considerations for Safety - Rockwell Automation Safety Automation Forum - November 2011

12. What is safer alternative design?
• A way that plaintiffs can demonstrate a defective product
is to show that a safer alternative design was available
• A design which satisfies ALL of the below
– Prevents or significantly reduces the risk of injury
– Does not substantially impair the product’s utility
– Is not too expensive (economically feasible)
– Is technologically feasible at the time the product left the
manufacturer’s control
Source: Legal Considerations for Safety - Rockwell Automation Safety Automation Forum - November 2011

13. Software quality
usability
performance
operation reliability
functionality
bug detection rate
maintenance cost
code complexity
reusability
testability
reliability
changeabilityefficiency
maintainability
coupling
exception handling
fault tolerance
understandability
readability
architecture
Source: PSaQC (~“Psychic”) PLC Software automated Quality Contro, DNVl

14. Quality and safe design
• Applicable standards and guidelines governing your
product are a key part of every product liability
• ISO, 14121.199E:
– Documentation on risk assessment shall demonstrate the
procedure which has been followed and the results which have
been achieved
• FDA, General Principles of Software Validation
– Software validation is a critical tool used to assure the quality of
device software and software automated operations. Software
validation can …reduced liability to device manufacturers
• ISO, IEC, IAEA, EWICS, etc.

15. Common developer issues
• Secure and defensive programming
• Many malware exploiting vulnerability because of the lack of defensive
programming
• Defensive programming is not educated widely
• Input inconsistency check, surveillance mechanism, etc.
• Developers ignore the standards because it is cumbersome, they have not had
experiences, or sometime just they don’t like it
• Mistakes leftover in the code unknowingly
• Reuse of code is very common
• Reuse of code causes confusion and mistakes
• Complete manual verification on all test variables and instructions (AFI, etc.) is
virtually impossible
• Lack of verification
• There is no standard to objectively evaluate the quality of programmers
• There are many standards but very little systemic verification (especially for PLC)
• Outsourced development makes it harder to verify the quality

16. What to do to protect yourself?
• Implement code standardization
– Multiple standards and refer to your industry standard
– Recommend code standardization to your customers
• Encourage and educate to use
– Old habits are hard to kick
– Educate the importance and encourage the developers
• Verify and reinforce with static analyzer
– Manual verification is not enough and can be faulty
– Static anlyzers are priced reasonably
– Don’t forget your PLC/PAC programs

17. November 17, 2015 17
Your contact person
Valerie Fontaine
Director of International Business Development
valerie.fontaine@itris-automation.com
Mobile: +33 6 52 69 97 52
• Corporate website: www.itris-automation.com
• Presentations: www.slideshare.net/ItrisAutomationSquare/
For more information