“You can’t control what you can’t measure ”
Tom DeMarco

Building Quality into Safety Critical Applications
組み込みソフトウェアの性能、品質の向上 − セーフティクリティカル産業から学んだ事例、教訓Nat Hillary
Field Applications Engineer
nath@metrowerks.com+1 (425) 487 -5985
2004年5月 30日

2General Business Use

Agenda• Introduction• Building Safety Critical Software– A focus on the Avionics approach• Conclusion

Introduction3

2004年5月 30日

General Business Use

Safety Critical Systems – a definition

Implementing a Safety critical system• A system is ‘safe’ when it does not endanger human life orthe environment• A safety critical system is one whose action, or inaction,
may cause death, dismemberment or injury• Examples:• Safety critical computer systems have both hardware andsoftware components• Overall system must be reliable and fail safe
• Reliability:– Measure of how long system must operate correctly without failur e– Brake-by- wire system– Cardiac Defibrillator– Fly-by-wire system

5

General Business Use• Fail safe:– Does NOT mean that system is safe from failure!
– Means that should a failure occur, the system design ensures thatthe failure does not affect safety, i.e. system should FAIL SAFE LY

6General Business Use

1

Designing Reliable Hardware & Software

Industry Response to proliferation of computer systems• Hardware• Growing number of guidelines addressing safety criticalsoftware development, e.g.:– Techniques and criteria for building reliable hardware wellunderstood (e.g. use of redundancy)– Common for industry regulations to define specific design,
implementation and test criteria for hardware– RTCA DO-178B “Software Considerations in Airborne System andEquipment Certification”; Aerospace– MISRA “Development Guidelines for Vehicle Based Software”,
Automotive– FDA “General Principles of Software Validation; Final Guidance forIndustry and FDA Staff”, Medical• Software– Similar criteria for software rarely exist– As our dependency on computers increase, so does our sensitivityto Computer Error

7

General Business Use• Common themes in approach used by most safety criticalindustries

8

General Business Use

General Approach Shared by Safety Critical Industries• Producing high quality software requires high quality
processes• Have a quality management system (e.g. ISO 9000)• Perform hazard analysis to determine safety integrity level• Define development process appropriate for safety level,e.g.:– H/W & S/W Architectural Design (level & type of redundancy, etc.)– Choice of implementation language– V & V activities– Choice of tools

Building Safety Critical Software• Make product measurements
A focus on the Avionics approach

2004年5月 30日

1110

General Business Use

Unique aspects of Avionics approachLesson One• Approach to V&V identified to FAA prior to development• Process documented throughout• Software lifecycle data submitted to authorities to obtaincertification ‘credit’• Software verification activities are described independently
from software verification tools• Intent is that focus is on verification process first, andprocess automation second• Three lessons to learn from this approach• Execute functional tests as normal• Repeat, making CodeTEST coverage measurements• Analyze coverage results, and for functions wherecoverage < 100%, determine cause:

General Business Use– Missing requirements?
– Missing test cases?
– Dead or unreachable code?

• Improve test effectiveness by updating requirements, testcases or code
• Repeat

12General Business Use

2

The state of industry …

Lesson Two• In summarizing his findings from working withmany companies, Richard Bender revealed thefollowing figures:– Current best practice in industry• There is no “one size fits all” coverage analysis metric –choice of coverage is based on how safety critical softwareis• Code Coverage > 70%, with 95% of bugs being found before
shipment– Average test results before shipping• Code Coverage < 35%, with > 25% of bugs being found in thefield

S/W Level

Ref: Development Dilemmas and the SEI Model – case studies in Software Process Development,
presented by Chuck House to the 9th IEEE International Software Quality Week, San Francisco May 23rd, 1996
13

General Business Use

14

Lesson Three

Failure causes system to fail, resulting in …

Coverage Req’d

A catastrophic failure for aircraft

MCDC, DC & SC

B hazardous/severe failure condition for aircraft

DC & SCC Major failure condition for aircraftSC

D Minor failure condition for aircraft

N/A

E No effect on aircraft

N/A

General Business Use

Golden Rule

• To have high quality code, you need high quality tools• Tool qualification process used in Avionics to ensure thata tool provides confidence at least equivalent to processes
eliminated, reduced or automated• "Automation is a great idea. To make it a goodinvestment, as well, the secret is to think about
testing first and automation second."
Bach, James: Testing Automation Snake Oil,www.satisfice.com/articles/test_automation_snake_oil.pdf

15

General Business Use

16

General Business Use

Building quality into safety critical systems• Safety critical industries publish software development
guidelines seeking to ensure systems meet specificreliability objectives, and they are fail safe
• Challenge is to build-in software reliability by reducing oreliminating defects using advanced testing and analysis
techniques• Much can be learned from Software V&V Techniques usedby avionics industry• Use of Coverage Analysis early and often in development
process has demonstrated significant impact on reducing
defects• Coverage Analysis does not replace other good processes
and practices, but is added and integrated with themConclusion

2004年5月 30日

18

General Business Use3

Not Just Aerospace …

Questions?

• A large system vendor on east coast of US
introduced Coverage Analysis early and often in
their development, resulting in:– 50% reduction in bugs found service– 95% reduction in system test time!
– 23% reduction in total development time

www.metrowerks.com
or please stop by our booth!
Ref: Development Dilemmas and the SEI Model – case studies in Software Process Development,
presented by Chuck House to the 9th IEEE International Software Quality Week, San Francisco May 23rd, 1996
General Business Use

1920General Business UseReferences
••

•
•

•
•
•
•

21

RTCA/D0 -178B “Software Considerations in Airborne System andEquipment Certification”, RTCA Inc., Washington D.C., December 1992
RTCA/D0 -248B “Final Report for Clarification of DO -178B ‘Software
Considerations in Airborne Systems and Equipment Certification’”,
RTCA Inc., Washington D.C., October 2001
FAA Order 8110.49 “Software Approval Guidelines”, Federal Aviation
Administration, June 2003
Draft IEC 1508 “Functional safety: safety related systems”, Geneva:
International Electrotechnical Commission (IEC ref 65A Secretariat 123),
June 1995“An Investigation of the Therac-25 Accidents”, Nancy Leveson, Clark S.
Turner, IEEE Computer, Vol. 26, No. 7, July 1993, pp. 18-41“Testing Computer Software”, Cem Kaner, et al, International Thomson
Computer Press, 1993
“Testing Automation Snake Oil”, Bach, James,
www.satisfice.com/articles/test_automation_snake_oil.pdf“Emerging Software Best Practices and how to be Compliant”, Rivett,
Roger S., Rover Group Ltd., www.misra.org.uk/papers/EAEC97.PDF

General Business Use4