Skip over menu

Software Safety Home Page
Guidelines
Last Modified on: Fri Sep 26 20:15:09 2008
Navigation Menu Left:

Books to read
Compliers with safety in mind
Esterel.org Reactive Programing Language
Guidelines for better software
Hardware Design Tips
ISO9000, the correct meaning
Internationalization (I18N & L10)
Jobs

Do you really want to "push the reset button" on your pacemaker?

Navigation Menu Right:

Metrics Gone Bad
Metrics
Past Visitors
Photosensitive Epilepsy
Quality
Software Patents Gone Bad
Tools
Translate the Software Safety web site




If you think that I could be of some assistance to you or your organization let me know,
American Society for Quality  Certified Software Quality Engineer.

Software Safety now has a blog! Check it out.

This site has been listed as the EG3 Editor's Choice in the Embedded Safety category for February 2004.

eCLIPS gives this site four of five stars in the September 7th 2004 SAFETY CRITICAL - DESIGN GUIDE.


PicoSearch
  Help
Site Search by PicoSearch 
Text Search


Somewhere in the first few pages of every semiconductor data book, you'll find a paragraph like this:

"Don't even think of using our products in a life support application without first getting our explicit, written permission. Should our product fail, we don't want to hear from you, your lawyer, or your late customer's lawyer. Believe this!"

It's usually wrapped up in somewhat more formal language, but you get the notion. - Life Support Dr. Dobb's Journal November 2001 by Ed Nisley.

If you ever do hear from your late customer's lawyer your best defense is to have your software development process well documented, using recognized guidelines.

Officials, such as the FDA quoted here, stress that "... guidance documents, including this guidance, do not establish legally enforceable responsibilities. Instead, guidances describe the Agency's current thinking on a topic and should be viewed only as recommendations, unless specific regulatory or statutory requirements are cited. The use of the word should in Agency guidances means that something is suggested or recommended, but not required."

The problem with not considering "guidance documents" as requirements, rather than recommendations can be seen in this scenario:

Scene: Courtroom. You are on the witness stand, a defendant in a product liability case.

Prosecutor: "Did you follow the 'Best Practice Guidelines' as recommended by [Fill in your favorite acronym]?"

{There are two possible realities that can be created from this point:}

Reality One: "No. The law did not require us to do so, so we saved time and money by not following those. We saw it as a unfunded goverment mandated paper work burden."

Reality Two: "Yes we followed the Guidelines, as well as several other Industries Best Practices. We wish to submit our documentation as evidence that we did the best possible job that could be done by anyone. We found that our costs where lower and the quality of our software is higher by following the recommended guidelines."

When you think of what the Judge and/or Jury might decide, which reality would you like to continue? Did you really save time and money?


How To Write Unmaintainable Code 

shows what NOT to do. 

I once inherited code of a complex multi-processor industrial control system that looked like these where the guide lines used to develop the system.

It is down right scary to think that there is code out there in embedded systems that has been written like this. That is one of my motivations in creating this site.  I want to point out the techniques that should be use to develop mission critical code.

Some thing else you do not want to do is the:

Big Ball of Mud

by
Brian Foote and Joseph Yoder

Abstract

"While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture.

These patterns explore the forces that encourage the emergence of a BIG BALL OF MUD, and the undeniable effectiveness of this approach to software architecture. What are the people who build them doing right? If more high-minded architectural approaches are to compete, we must understand what the forces that lead to a BIG BALL OF MUD are, and examine alternative ways to resolve them.

A number of additional patterns emerge out of the BIG BALL OF MUD. We discuss them in turn. Two principal questions underlie these patterns: Why are so many existing systems architecturally undistinguished, and what can we do to improve them?"


The International Obfuscated C Code Contest shows just how bad code can get.  Keep in mind that you can write bad code in any language, C just makes it easy to do it.


Added Jan/27/2007:

Joint Strike Fighter Air Vehicle C++ Coding Standards.


Added July/09/2005:

SOFTWARE 2015: A National Software Strategy to Ensure U.S. Security and Competitiveness  http://www.cnsoftware.org/nss2report/NSS2FinalReport04-29-05PDF.pdf.


Added APR/30/2005:

SHIP - Assessment of the Safety of Hazardous Industrial Processes in the Presence of Design Faults.

The overall objective of SHIP was to devise a means of assessing, ideally numerically, the achieved reliability or safety of a system in the presence of design faults.


Workshop on Assurance Cases: Best Practices, Possible Obstacles, and Future Opportunities.


Military Standard on System Safety MIL-STD-882D.


Added Feb/25/2006:

Those working on medical device software should be very interested in a new standard currently undergoing approval, ISO 62304: Medical Device Software Software Life Cycle Processes. This standard was developed in a cooperative effort between FDA and industry, coordinated through the Association for the Advancement of Medical Instrumentation (AAMI) Software Standards Committee.


Added Nov/21/2004:

Department of the Army Pamphlet 73-7 "Test and Evaluation Software Test and Evaluation Guidelines" 1997.
Appendix Q of DA PAM 73-1 has updated, 2003, information.

Added Sep/11/2004:

A scrapbook of illustrated examples of things that are hard to use because they
do not follow human factors principles.
By Michael J. Darnell

Added Sep/11/2004:

Software Safety Standards

Software Engineering Process Technology has posted the twenty most popular software safety standards.


Added Aug/01/2004:

European Commission accepts proposal to develop reliable systems By Colin Holland, Embedded.com.

DECOS, a joint initiative to generate a proposal for an integrated project within the EU's Framework Programme 6, has been accepted by the European Commission. Its aim is to identify and alleviate the barriers that hinder the development of highly reliable embedded systems.

DECOS : Dependable Embedded Components and Systems, was among the most successful project proposals that were submitted to the EC in the field of embedded systems. Its industrial and academic partners will jointly develop a set of generic hardware and software components within the framework of the Time-Triggered Architecture (TTA).

TTA's dependable approach for high-reliability systems has seen it attract attention in a range of industries, including aerospace, automotive, special vehicles, railway, and industrial control.


Navy Handbook for the Computer Security Certification of Trusted Systems is part of the web for the Center for High Assurance Computing Systems.


DOE-STD-1172-2003; Safety Software Quality Assurance Functional Area Qualification Standard; DOE Defense Nuclear Facilities Technical Personnel documents what it takes to get DOE Software Quality Assurance position.


Industry and Federal Standards and Guides.
Regulatory Guide 1.173 - Developing Software Life Cycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Power Plants.

US Army Software System Safety Requirements. Other Army Software Web Sites.


Previous additions:


NASA C Programming Style Guide
 - From Goddard Space Flight Center.


NASA Software Requirements Specification (SRS); DI-IPSC-81433

The Software Requirements Specification (SRS) specifies the requirements for a Computer Software Configuration Item (CSCI) and the methods to be used to ensure that each requirement has been met. Requirements pertaining to the CSCI's external interfaces may be presented in the SRS or in one or more Interface Requirements Specifications (IRSs) (DI-IPSC-81434) referenced from the SRS.

Software Safety NASA Technical Standard.

This standard provides a methodology for software safety in NASA programs. It describes the activities necess ary to ensure that safety is designed into software that is acquired or developed by NASA. All Program/Project M anagers are to assess the inherent safety risk of the software in their individual programs and are encouraged t o tailor their software safety activity accordingly within the framework of this standard.

The Software Working Group (SWG) is an Agency-wide software advocate and coordinating body that is responsible for addressing software related issues throughout NASA.

The SWG site contains many of the NASA Guidebooks and Standards related to software development.


http://www.misra.org.uk/
MISRA Mission Statement
To provide assistance to the automotive industry in the application and creation
within vehicle systems of safe and reliable software.

Guidelines for the Use of the C Language in Vehicle Based Software

The Motor Industry Software Reliability Association (MISRA) has developed a set of guidelines for C programming of safety-related embedded automotive systems.

MISRA C front cover
WHY were they produced?

The MISRA software guidelines, "Development Guidelines for Vehicle Based Software", published in 1994 and now widely used within the industry, recommend the use of a restricted subset of a high-level language for programming safety-related systems. The C programming language is being increasingly used for automotive applications, due largely to the inherent language flexibility, the extent of support and its potential for portability across a wide range of hardware. However the nature of the C language is such that there are many areas of concern which potentially jeopardize the high level of integrity required from the final executable code.

Having carried out extensive consultation within the automotive industry, the MISRA consortium has now completed the development of guidelines specifically aimed at the use of the C language. These guidelines primarily identify those aspects of the C language which should be avoided in safety-related systems, along with other recommendations on how other features of the language should be used. It is anticipated that the guidelines will be adopted for embedded C programming throughout the automotive industry.

A recently launched website, http://www.misra-c.com/, dedicated to MISRA C. This website includes details of the new version of MISRA C, MISRA-C:2004, and answers to common questions. There is a web discussion forum on this site which has replaced the existing email discussion list. If you have any questions about interpretation of MISRA C rules, then here is the place to ask. Official responses to questions will be published as appropriate at this forum by the MISRA C team.

How do the MISRA Guidelines relate to IEC 61508?: IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems is a generic standard. At the time of writing Development Guidelines for Vehicle Based Software IEC 61508 had not been published, although the authors did consider earlier drafts of the standard. Many of the principles of the standard are embodied in the Guidelines with an automotive focus where appropriate. It is planned to address the "mapping" between IEC 61508 and the MISRA Guidelines more formally in the future.

You can find a list of the MISRA rules here, as part of Abraxas Software's, CodeCheck package.   Gimpel's Lint offers simular MISRA functionality.

It is still necessary to buy the MISRA guide lines to learn the rational behind each rule.


Functional Safety in High-Volatile Applications: With IEC 61508, manufacturers can ensure the functional safety of all aspects of a product's life cycle, by Kristina L. Balobeck, explains the "reset mentality".

Do you really want to "push the reset button" on your pacemaker?
Let's get it right the first time before the lawyers and politicians get involved and tell us how to do our jobs...

[Alas it is to late. It is now illegal to be a "Software Engineer" in the state of Texas, without passing a state licensing exam. There is a fine of $3,000 per day. - Dr. Dobb's Journal, June 2003 page 8. Last I knew, no one knew how to write the required exam. See also To be an engineer by Jack Ganssle.]


Conformity Assessment of Safety-Related Systems (CASS) is some thing that you'll bump into from time to time.

CASS is a certification scheme set up and managed by all those sectors of industry with an interest in accredited certification to IEC 61508, the international standard for functional safety of electrical/electronic/programmable electronic safety systems.

The CASS Scheme provides a rigorous and internationally acceptable structure under which consistent certification of safety related systems can take place. The scheme is operated through independent third-party certification bodies, that are accredited to the European and International accreditation standards.


International Electrotechnical Commission

Functional safety and IEC 61508

The document Functional safety and IEC 61508 provides an introduction to functional safety and gives an overview of IEC 61508. You will find it useful if you are:

IEC 61508, Functional safety of electrical/electronic/programmable electronic safety-related systems

IEC 61508 covers all safety-related systems that are electro-technical in nature (i.e. electromechanical systems, solid-state electronic systems and computer-based systems). The standard is in seven parts whose titles are:

Part 1: General requirements
Part 2: Requirements for E/E/PE safety-related systems
Part 3: Software requirements
Part 4: Definitions and abbreviations
Part 5: Examples of methods for the determination of safety integrity levels
Part 6: Guidelines on the application of IEC 61508-2 and IEC 61508-3
Part 7: Overview of techniques and measures

The standard is generic and can be used directly by industry (as a 'standalone' standard) and also by international standards organizations as a basis for the development of sector standards (e.g. for the machinery sector, for the process sector or for the nuclear sector). The standard will therefore influence the development of electrical, electronic and programmable electronic (E/E/PE) safety-related systems across all sectors.

For more details on the standard see Frequently asked questions.

IEC has published an introductory brochure on IEC 61508.



Besides IEC 61508 and UL 1998, ISO9000-3, and ISO/IEC12207 are worth studying.

ISO/IEC12207 defines 17 processes, 74 activities, and 232 engineering tasks required to create safe software.  To ease the burden, you can purchase checklists for eight of the major software engineering and software related standards.  Templates are also available that will help a software engineer, without extensive knowledge of a software engineering process to prepare a plan or record that meets high professional expectations.

Praxiom Research Group has prepared "ISO 9000-3 1997 Guidelines in Plain English Guidelines for Applying ISO 9001 1994 to Computer Software".


"30 Pitfalls for Real-Time Software Developers" and "25 Most Common Mistakes with Real-Time Software Development" (PowerPoint Presentation) by David B. Stewart should be on your reading list.


MBASE is a set of guidelines that describe software engineering techniques for the creation and integration of development models for a software project. The models to be integrated extend beyond Product (development) models such as object oriented analysis and design models and traditional requirements models, to include Process models such as life-cycle and risk models, Property models such as cost and schedule, and most notably Success models such as business-case analysis and stakeholder win-win.

Similar programs can be found at  the Center for Software Engineering Home Page.


http://hissa.nist.gov/http://hissa.nist.gov/

High Integrity Software Systems Assurance


The Software Quality Group develops tools and techniques to help industry improve the quality of information technology products.  Products include static analysis tools, verification and validation techniques, formal methods, and data on software failures.  The Software Quality Group collaborates with industry, academia, and other Government agencies to develop technology for high integrity software systems.
http://www.itl.nist.gov/div897/sqg/sqg.htm

A major focus within the Software Quality Group, is to provide technology to produce high integrity, affordable software in high integrity software systems.  High integrity software is software that can and must be trusted to work dependable in these and other critical functions (e.g. communications (computers, telephony), software in safety systems of nuclear power plants, medical devices, electronic banking, air traffic control, automated manufacturing, and some business systems).

Publications

Software Diagnostics and Conformance Testing Division

"The mission of the Software Diagnostics and Conformance Testing Division is to develop software testing tools and methods that improve quality, conformance to standards and correctness. The division also participates with industry in the development of forward-looking standards."

- Mark Skall, Division Chief

The Dictionary of Algorithms, Data Structures, and Problems

Software Engineering Body of Knowledge (SWEBOK)


Guide to the Software Engineering Body of Knowledge

http://www.unusualresearch.com/hacker/cud112.htm

 In many engineering disciplines, the accreditation of university curricula and the licensing and certification of practicing professionals are taken very seriously. These activities are seen as critical to the constant upgrading of professionals and, hence, the improvement of the level of professional practice. Recognition of a core body of knowledge is pivotal to the development and accreditation of university curricula and the licensing and certification of professionals. Because software engineering has not yet achieved this recognition, the ACM and the IEEE Computer Society are actively promoting the recognition of software engineering, through developing a software engineering body of knowledge (SWEBOK) for university curricula and licensing of software engineering professionals.


Capability Maturity Model® for Software (SW-CMM®).

The Capability Maturity Model for Software (CMM or SW-CMM) is a model for judging the maturity of the software processes of an organization and for identifying the key practices that are required to increase the maturity of these processes.

The Capability Maturity Model is a comparative rating scale at the organization level. The CMM scale has five levels.:

If you have no idea what that means, you area at the Initial-Level-1.

The word 'chaotic' sums the development process at Level-1. It would not stand up to a simple audit by the FDA, MSHA, or other simular organization.

CMM is being phased out in favor of CMMI.

The CMMI models improve upon the best practices of previous models in many important ways. CMMI best practices enable organizations to do the following:

Common approaches for process improvement include heavily documenting all processes and marching toward the achievement of a SEI CMMI level. The result is often a stack of paper that is either ignored or seen as a unnecessary burden on developers.

An alternative approach is to start with the business goals and problems of the organization then tie all improvement activities directly to the organization's current project work.


FDA Guidance Documents, Federal Register Notices and Other Documents may be found at DeviceLink's web site.


Medical Device Tracking: Guidance for Industry and FDA Staff

Tracking is intended to facilitate notification to users and product recall in the event a device presents a serious risk that requires prompt attention. Just in case you find that you must recall one of your products.


Formal Methods, useful for mathematically describing and reasoning about computer-based systems. Formal methods are a fault avoidance technique that help in the reduction of errors introduced into a system, particularly at the earlier stages of design. They complement fault removal techniques like testing.


MIT Software System Safety Working Group

Mil-Std-882B
Mil-Std-882C
Mil-Std-882D
U.S. Nuclear Regulatory Commission. Do a search for the word 'Software' to find items like Guidance for Software Reviews for Digital Computer-Based Instrumentation and Control Systems

DO-178B: DO-178B is not available for download. For information on obtaining a copy of DO-178B visit the Radio Technical Commission for Aeronautics (RTCA) web-site at http://www.rtca.org.



Select from the menu other areas of Software Safety that you would like to explore.


If you think that I could be of some assistance to you or your organization let me know,
American Society for Quality  Certified Software Quality Engineer.




Go Back To The  Software Safety Home Page