Developing Software for

G u i d E l i n e
Safety Critical Engineering
Applications
Contributors: Roger Yiu Ming Cheung, P.Eng. / Jeffrey Coulson, P.Eng. /
Eugen Malea, P.Eng. / Corneliu Muntean, P.Eng. / Nick Pfeiffer, P.Eng., Ph.D. (Chair) /
Anton Pop, P.Eng. / Paul Spagnolo, P.Eng. / Pak Tse, P.Eng.

Notice:The Professional Standards Committee has a policy of reviewing guidelines every five years to deter-

mine if the guideline is still viable and adequate. However, practice bulletins may be issued from time to

time to clarify statements made herein or to add information useful to those engineers engaged in this area

of practice. Users of this guideline who have questions, comments or suggestions for future amendments and

revisions are invited to submit these to PEO using the standard form included in the

G u i d e l i n e De v e l o p m e n t an d Ma i n t e n a n c e Pr o c e s s e s do c u m e n t

November 2013
Contents
1. PEO PURPOSE FOR GUIDELINES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. PREFACE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3. PURPOSE AND SCOPE OF GUIDELINE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

4. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

5. PROFESSIONAL RESPONSIBILITY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1 Public Interest. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2 Risk Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.3 Human Factors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.4 Code of Ethics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.5 Legal Obligations and Confidential Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.6 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.7 Multi-practitioner Projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

6. INTELLECTUAL PROPERTY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

7. SEALING. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1 Safety Critical Software Package. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2 Professional Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.3 Revisions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

8. SOFTWARE DEVELOPMENT METHODS AND PROCEDURES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

8.1 Software Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.2 Software Design and Development. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.3 Software Process Engineering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.4 Software Quality.
8.5 Software Assets Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.6 Management of Software Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.7 Software Packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

9. SUMMARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

10. DEFINITIONS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

APPENDIX 1–SOFTWARE ENGINEERING REFERENCES OF INTEREST TO ENGINEERS . . . . . . . . . . . . . . . . . . . 12

APPENDIX 2–CASE STUDIES OF SOFTWARE SYSTEM FAILURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

APPENDIX 3–AMENDMENT AND REVISION SUBMISSION FORM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

APPENDIX 4–PEO PROFESSIONAL PRACTICE GUIDELINES AND STANDARDS . . . . . . . . . . . . . . . . . . . . . . . . 15

 For the purposes of this guideline, the term the public interest
1. PEO Purpose for Guidelines refers to the safeguarding of life, health, property, economic
Professional Engineers Ontario (PEO) produces guidelines interests, the public welfare and the environment.
for the purpose of educating both licensees and the public
about best practices.
3. Purpose and Scope of
For more information on PEO’s guideline and development
process, which includes PEO’s standard form for proposing
Guideline
revisions to guidelines, please read our Guideline Software may pose a risk to the public interest, either directly
Development and Maintenance Processes document. or indirectly. The purpose of this document is to outline the
ethical and professional responsibilities of engineers to ensure
For a complete list of PEO’s guidelines, please visit Appendix 4.
that the public interest is protected. This document also
provides guidance for others interfacing with engineers who
To view other PEO guidelines, please visit the Practice
are developing software, such as clients and owners who are
Advice Resources and Guidelines section of the PEO
acquiring ready-made software or specifying requirements for
website.
new software. This guideline should be regarded as an addi-
tion to but not a substitute for specialized software training.
2. Preface The guideline is written with the expectation that the reader
is familiar with software development.
The Professional Standards Committee formed a subcom-
mittee of engineers from a variety of practice areas who had The development of certain categories of software is consid-
experience developing software in their professional ered to fall within the scope of professional engineering in
engineering practice. The group was asked to investigate the Ontario when the software is used in a manner that affects
legal, ethical and technical aspects of software design and the public interest. In June 2008, PEO council approved
development that could have an impact on the public the following definition of Software Engineering:
interest. Furthermore, the subcommittee was instructed to
Software engineering is deemed to fall within the practice of
prepare a guideline to deal with the development of software
professional engineering as defined by the Professional Engi-
when it is considered to fall within the scope of professional
neers Act:
engineering.
• Where the software is used in a product that already falls
The subcommittee met for the first time on July 21, 2010,
within the practice of engineering (e.g. elevator controls,
and submitted a completed draft of this document to the
nuclear reactor controls, medical equipment such as gam-
Professional Standards Committee for approval on January
ma-ray cameras, etc.); and
15, 2013.
• Where the use of the software poses a risk to life, health,
Following consultations with engineers and other stakehold- property or the public welfare; and
ers, the final draft was approved by Council at its meeting • Where the design or analysis requires the application of
on November 22, 2013. engineering principles within the software (e.g. does engi-
neering calculations), meets a requirement of engineering
Note: References in this guideline to engineers apply equally
practice (e.g. a fail-safe system), or requires the application
to professional engineers, temporary licence holders, provi-
of the principles of engineering in its development.
sional licence holders and limited licence holders.
For the purpose of this guideline, software that meets all
Practitioners as defined in the Professional Engineers Act
three criteria of the above definition is considered to be
(Act) refers to engineers and firms holding a Certificate of
safety critical software and falls within the practice of pro-
Authorization to offer and provide engineering services to
fessional engineering, even though the term “safety critical
the public.
software” may be defined differently by other organizations.

4 Develop ing S of t w a r e f or S a f e t y Cr it ic a l E n g i n e e r i n g A p p l i ca t i o n s
This guideline recommends considerations for developing responsible for their work, including the design and devel-
safety critical software and for incorporating such software opment of safety critical software.
as part of larger systems. It addresses factors that are reason-
Engineers play a key role in designing and developing safety
ably necessary for the protection of the public interest, such
critical software. The intent of this guideline is to provide
as: software requirements, software design and construction,
best practices for engineers developing such software, to set
software process engineering, software quality, software assets
expectations with respect to engineering practices in the
management, and management of software projects. It is
domain of safety critical software processes, to provide guid-
important to note that the recommendations presented here
ance within the realm of safety critical software to meet the
must be tailored to the specific requirements of each project.
intent of the Act, and to help improve trust in the use of
This guideline does not deal with the role and responsibili- safety critical software. Engineers need to be aware of poten-
ties of engineers who apply engineering software to perform tial risks and of their ethical and professional responsibilities
calculations, modeling and optimization analysis as part to protect the public interest.
of professional engineering services or to provide informa-
Safety critical software can have many applications, includ-
tion used as the basis for professional engineering decisions,
ing but not limited to:
judgments and opinions. The application or use of such
software is the subject of a separate guideline, entitled Pro- • control and data acquisition;
fessional Engineers Using Software-Based Engineering Tools. • sensing and interpretation software, and modeling and
design software that is used to make or automate criti-
For the remainder of this document, software and software
cal decisions and actions that impact the public interest,
development activities are assumed to refer solely to safety
such as utility (telecommunications, water, electricity,
critical software unless explicitly noted otherwise.
gas, traffic) control and protection;
Since the development of safety critical software falls within • public transportation control systems and industrial safety;
the practice of professional engineering, only engineers or • protection and control systems software; and
those supervised by an engineer can develop safety critical • medical and diagnostic equipment.
software. Furthermore, practitioners who develop safety crit-
It is the responsibility of the sealing engineer using third-
ical software as part of a service to the public are required to
party software to validate results obtained from the software
have a Certificate of Authorization.
before implementing them into the system.
This guideline does not cover software that falls outside the
There is a need to provide proactive means to prevent
practice of professional engineering, even if engineers often
software system failure that may affect the public interest.
develop software that is not related to professional engineer-
This guideline focuses on the professional responsibilities of
ing (e.g. business, financial, or tax software; e-commerce soft-
engineers developing safety critical software or incorporating
ware; database analysis software; and gaming software).
such software as part of a larger system or product. It clari-
fies the role of engineers, as well as their duty to protect the
4. Introduction public interest in this area.

Modern machines are becoming increasing sophisticated and Many other organizations have developed best practices,
complex as a means of decreasing costs, removing variability, guidelines and applicable standards, some of which are listed
reducing resources and increasing production. By definition, in Appendix 1. Engineers are advised to direct themselves to
many of these devices contain safety critical software. Poor these other references, as required. It should be noted that
design, failure to check functionality, improper use and fail- this guideline is neither a standard nor a body of knowledge,
ure to properly maintain this software can potentially lead but rather a collection of best practices. It provides recom-
to physical injury or death, economic damages, environmen- mendations–not prescriptive rules–and does not explain
tal impact or the loss of public trust. Within this context, it theoretical or practical knowledge.
is important to note that engineers are always professionally

P r o f e ssi o n a l E n g i n e e r s O nt ar i o 5
It is recognized that engineers are most often part of a
product or software development team that includes others,
5. Professional Responsibility
such as information systems professionals (ISPs), computer
5.1 Public Interest
scientists and technologists. This document reviews the
Developing safety critical software is a complex undertaking,
responsibilities of engineers to ensure the public interest is
comprising different processes, including specifying require-
protected by:
ments, design, implementation, testing, verification and
• recognizing professional and ethical responsibilities with soft- validation. Furthermore, interpreting the needs of clients
ware development, especially public interest considerations; and consumers, balancing budget and schedule constraints,
• accepting professional responsibilities in product deliv- and ensuring the efficiency, effectiveness, integrity, security,
ery (i.e. final review and sealing); privacy, safety, and quality of the software are all activities
• delineating responsibilities for multi-disciplinary proj- that involve a degree of risk. These facts should remind
ects (i.e. hardware and software interfaces); and engineers of their responsibility for performing due diligence
• recognizing the professional responsibilities of engineers and protecting the public interest, since, ultimately, engi-
in different software development roles and during vari- neers contribute to the success of software projects.
ous stages of software development.
5.2 Risk Management
The development of safety critical software requires the
To perform due diligence, project risks need to be identi-
same degree of review and validation as the development
fied early, analyzed, treated according to the likelihood
of any safety system, structure or device that falls within
and impact of the risk, and managed. Risk treatment may
the practice of professional engineering. There is a mis-
include avoiding a risk entirely; transferring (or sharing) the
conception that software does not carry the same level of
risk with another party; mitigating the risk, either its likeli-
importance as drawings, hardware or systems. This mistaken
hood and/or its impact; or accepting the risk. In choosing
belief is rather perilous, when one considers that software
appropriate risk treatments, particular attention needs to be
can be easily modified, unlike a structure or device. Because
paid to the public interest. Engineers are reminded of the
of this fact, safety critical software requires an enhanced
importance of adopting well-recognized software engineer-
level of attention to functionality, documentation and ver-
ing processes to manage any risk to the public interest (for
sion control (see 5.6 Support). This guideline identifies the
some examples of these processes, refer to Appendix 1).
responsibilities of engineers in this area, so safety critical
Furthermore, engineers should be aware of relevant software
software development is undertaken with the level of care
system failures in the past, and be cognizant of their obliga-
and diligence that is required of all engineering activities
tions when working with systems of a similar nature (refer
covered by the Act.
to Appendix 2 for case studies of software system failures).
All engineers are professionally responsible for the engineer- Finally, engineers should design safety critical software so
ing work they produce. Article 72(2)(b) of O. Reg. 941/90 that it can handle the threat of malicious software.
under the Act identifies one criterion of professional mis-
Safety critical software shall be sealed to provide assurance
conduct as “failure to make reasonable provision for the
that engineers responsible for developing the software have
safeguarding of life, health or property of a person who may
fulfilled their obligations under the Act. The seal provides
be affected by the work for which the practitioner is respon-
traceability in case the engineer responsible for developing
sible”. Engineers must be aware that the concept of “reason-
the software needs to be contacted.
able provision” applies to the development of safety critical
software, since it falls under the practice of engineering.
5.3 Human Factors
Human error has played a significant role in several
catastrophic system failures throughout the world. Con-
sequently, engineers need to be aware that human error
prevention is of paramount importance in designing and
deploying safety critical software. Design of human inter-

6 Develop ing S of t w a r e f or S a f e t y Cr it ic a l E n g i n e e r i n g A p p l i ca t i o n s
faces required to operate or maintain the system should • It is generally considered that engineers may apply any gen-
account for human capabilities and limitations, in addition eral knowledge or expertise, as long as it falls into a “state of
to meeting the necessary obligatory requirements of perti- the art” category.
nent regulations.
5.6 Support
5.4 Code of Ethics Software risk is further managed when the software
Engineers are reminded of PEO’s Code of Ethics, which is adequately supported throughout its lifecycle, from
states that: “A Practitioner shall…regard the Practitioner’s requirements definition to production, maintenance and
duty to public welfare as paramount”. Hence, practitioners deployment. Such support may include:
should minimize risk to the public interest through use of a
• Documentation, such as requirements and specifica-
well-recognized software development process, with system
tions, verification and validation reports, manuals, criti-
safety considerations as the foremost element in the design.
cal function/alarm restoration/preservation processes,
The Code of Ethics also states: “It is the duty of a Practi- safety assessment reports, software version control pro-
tioner…to act at all times with knowledge of developments cess, software defect tracking process;
in the area of professional engineering relevant to any ser- • statements of conformance to applicable standards and
vices that are undertaken”. This provides an obligation for of any limitations or restrictions;
engineers to have knowledge of well-recognized software • training, where required by agreement, on installation,
engineering processes, as well as similar safety critical software maintenance, and operation;
systems, including potential modes of failure (Appendix 2 • access to source code under suitable contractual terms; and
contains case studies of software system failures). • expressed warranty, liability limitations (e.g. connecting
to third-party middleware).
For more information on the Code of Ethics, please refer to
the Professional Engineering Practice guideline.
5.7 Multi-practitioner Projects
Final documents related to safety critical software provided
5.5 Legal Obligations and Confidential
as a service to the public shall be sealed by the engineer
Information
responsible for developing the software. In cases where the
As this is an area where conflict can arise, it is important
software is developed by multiple engineers, for example
to document intellectual property rights and owner-
in a large or multi-disciplinary project, each engineer may
ship, as well as client relationships, properly and get
seal the portion of the documentation for which he or she
legal advice when needed. Intellectual property rights
is responsible. Such sealing shall provide assurance to the
and ownership includes copyright, patents, industrial
engineer responsible for the overall development of the soft-
design rights, “trade secrets” and trademarks. In addition
ware that the sealed portion of the safety critical software
to legal obligations, engineers also have important ethi-
has been developed in accordance with the Act. It is not suf-
cal and professional obligations relating to confidential
ficient that each portion of safety critical software is sealed;
information. Following are excerpts from the Professional
the overall software should be sealed by the engineer taking
Engineering Practice guideline, which discusses confiden-
professional responsibility for the work.
tial information in detail:
Engineers who seal safety critical software shall ensure that
• Engineers should not divulge any information sensitive to
their obligations under the Act are fulfilled, including tak-
their clients’ or employers’ business to third parties, unless
ing responsibility for portions of the software that have been
expressly or implicitly authorized by their clients or employ-
developed by others under their supervision. The guideline
ers or required by law to do so.
Use of the Professional Engineer’s Seal elaborates on seal-
• Engineers are also expected to avoid using (confidential)
ing multiple-discipline projects as follows: “For a project
information for the benefit of themselves or third parties, or
covering work within several engineering disciplines, all doc-
to their clients’ or other practitioners’ disadvantage. Engi-
uments within a particular engineering discipline must be
neers are expected to decline employment or a commission
sealed by the engineer taking responsibility for work within
that would require disclosure of such information.

P r o f e ssi o n a l E n g i n e e r s O nt ar i o 7
that discipline, with an indication or qualification of which important when the IP relates to safety critical software. Engi-
discipline is implied by the seal. The supervisory or coordi- neers should evaluate the potential IP generated by software
nating engineer (if there is one) should also apply his or her development and identify technical limitations in relation
seal to indicate that the work of the various disciplines has to the IP. For example, IP could cover technically strategic
been coordinated. If only one signature and seal is used, it algorithms, specialized calculations, data constants obtained
should be that of the engineer taking responsibility for the through extensive empirical research, or the actual source code.
work, generally the coordinating engineer.”
Engineers should seek legal advice on IP matters when
Engineers who use safety critical software as part of a larger needed. Due to the complexity of IP rights, engineers,
project or system shall ensure that the software is fit for use either as users or as authors/owners of IP, should initiate a
in the particular application, and operating and physical dialogue with trained professionals in IP laws. Some of the
environment. Such fitness for use may include an under- legal clarifications may cover, but are not limited to: the
standing of functionality, reliability, usability, security, limi- rights granted or limited by copyright, licence, warranty,
tations, underlying principles, design constraints, and valid- redistribution statements and disclaimers, in order to limit
ity/reliability of results. liabilities and avoid creating a risk to the public interest.

More general legal aspects of engineering work in regard to

6. Intellectual Property safety critical software is presented in section 5.5 Legal.

Intellectual property (IP) refers to a variety of intangible

assets, such as copyrights, trademarks, patents, and trade 7. Sealing
secrets. Owners of these assets may grant legal rights restrict-
The Use of the Professional Engineer’s Seal guideline states:
ing use. When the asset is software-related, such as the source
“Engineers must seal all final documents that are within the
code for a program or the details of an algorithm, the granted
practice of professional engineering, provided as a service to
rights may limit the conditions under which the software can
the public.” This requirement is contained in the Act. Con-
be used, maintained, or included with other software.
sequently, all final safety critical software packages provided
Modern software development is often accomplished by as a service to the public, including code and professional
combining original software modules with pre-existing/re- documents, shall be sealed in accordance with this guideline.
usable software modules. The end result is a new software
The basic purpose of sealing hardcopy or softcopy profes-
product with unique characteristics and functionality. In
sional documents (refer to section 7.2 for more information
the process of software development, engineers might act as
on professional documents), or a software package, is to
either users of IP, or authors of IP, or even both users and
identify the work has been performed by or under the
authors within the same project.
supervision of an engineer. The product of engineering work
When using third-party software or development tools, engi- is sealed to indicate that other people can rely on it to be
neers should acknowledge and respect the IP rights granted or suitable for its intended purpose.
limited by licences, warranties, redistribution statements, and
disclaimers. The IP rights and their implications regarding 7.1 Safety Critical Software Package
safety, maintenance, upgrades and use by customers or other 7.1.1 Originally developed safety critical software
parties should be an important consideration for any engineer. package
In particular, too restrictive third-party IP rights might limit The original version or modifications of a safety critical soft-
the possibility of comprehensive evaluation of safety-related ware package, including code and documents, shall be sealed.
features for a software module intended to be included into The safety critical software package may be sealed on the equiv-
a newly developed software product (e.g. restricted access to alent of the “cover page” or introduction to that software.
data constants covered by third-party IP limitations).
7.1.2 Review of third-party software
Engineers as authors and/or owners of IP should take neces- Often, software is developed for one purpose, but may be
sary actions to protect their rights. These rights are extremely used for another. For example, a commercially available

8 Develop ing S of t w a r e f or S a f e t y Cr it ic a l E n g i n e e r i n g A p p l i ca t i o n s
graphical user interface developed for a non-critical infor- The appearance of an engineer’s seal on a professional docu-
mation kiosk application may be used in a critical control ment is taken as an indication of the engineer’s acceptance
application. If such software becomes safety critical software of professional responsibility for design, development and
by its incorporation into a different purpose, engineers testing. These principles apply to both paper documents and
responsible for the system, process, equipment or machine electronic documents. Refer to the guideline Use of the Pro-
shall ensure that their obligations under the Act are fulfilled. fessional Engineers Seal for more detailed information.
For instance, developers of safety critical software should
ensure that re-use or integration of such software with other 7.3 Revisions
products is properly documented, including any limitations When a safety critical software package undergoes a revision,
or constraints. Where this is not the case, engineers must the engineer responsible for the revision shall label and seal
review and verify that the software functions as anticipated the software code and professional documents that are part of
for the intended application. that safety critical software package release. The seal indicates
the engineer’s acceptance of responsibility for the revised
An engineer’s obligations, including his or her duty to the pub-
package and associated engineering work. Care should be
lic welfare and providing proper credit for engineering work,
taken in documenting the revisions to clearly identify the
can be fulfilled by a thorough review that includes sufficient
boundary of professional responsibility between the original
research, calculations and other professional engineering work,
and revised software code and documents.
so that the engineer is satisfied that the work meets appropri-
ate codes and standards and that due diligence is exercised. A
review does not necessarily imply a complete rework. The test 8. Software Development
that should be applied is: “Does the work meet the acceptable
professional and regulatory standards?” not “Is this the way that
Methods and Procedures
I would have performed the work?”. Engineers should create There is no best single process for developing software.
documents detailing the review process and seal them. However, many methodologies and standards have been cre-
ated relating to software development to control the process
7.2 Professional Documents and reduce the variability. Appendix 1 contains a list of
Professional documents associated with but separate from well-recognized processes for software development.
software code for safety critical software, either in electronic
Regardless of the particular methodology used, the develop-
or hard copy form, shall be sealed. This may include, but
ment of safety critical software is a project that comprises
is not limited to, the following design, testing and commis-
many steps and can be managed by established techniques.
sioning documents:
Engineers should choose a software development meth-
• design documents, requirements, specifications, includ-
odology that is appropriate for the type of software to be
ing documentation of operating environment (compiler,
developed. Whatever development methodology is chosen,
software versions, etc.);
there should be a clear documentation of why it was chosen
• physical models of monitoring and control systems (i.e.
and the benefits and risks of choosing it.
process drawings and mechanical drawings);
• artifacts produced during the course of design and This guideline does not specify a particular development
development (i.e. tradeoff analysis, prototypes, analysis methodology. However, engineers should choose a reliable
elements, software defect tracking, and verification and methodology and put controls/processes in place that mini-
validation test reports); mize any inherent risks.
• documentation on the purpose and appropriate use of
In general, software development projects can be divided
software, including limitations and constraints and re-
into the following major tasks:
use or integration with other products, development and
maintenance documents, tools, and aids; and • requirements;
• review documents for third-party software, as described • design and development;
in section 7.1.2. • process engineering;

P r o f e ssi o n a l E n g i n e e r s O nt ar i o 9
• software quality; fication, validation, measurement, reviews and audits. Testing
• assets management; can be used to verify proper operation and validate whether the
• project management; and software fulfills its intended purpose. This testing can be per-
• software packaging. formed at different stages of the development process, including
Engineers are often significantly involved in all these differ- unit or component testing, integration testing between compo-
ent tasks. nents, system testing, and system integration testing for systems
of two or more different systems. However, in general, testing
8.1 Software Requirements can never completely identify all the defects within software. In
Software requirements are drawn out using processes and tools addition, validation is subjective and contextualized based on
for identification of the scope and specifications, the end users’ the reviewer. Therefore, review and participation by the client
needs, the re-use or integration of existing products, the code or and/or end-user testing may be required for acceptance of the
applications, and the constraints. These requirements are then final product. This can include software safety assessments, sim-
used to describe and document the functional and non func- ulation, review of sample input and output data, performance
tional aspects of the software. The requirements are validated testing, acceptance testing, qualification and certification.
through prototyping, review and modeling. Finally, engineers
need to identify potential failure modes in safety critical soft- 8.5 Software Assets Management
ware as part of their duty to make reasonable provision for the Software must be managed through its life cycle. Software
safeguarding of life, health or property of any person who may asset management is used to control and safeguard the soft-
be affected by the work for which they are responsible. ware product versions, as well as the software development
artifacts. Software asset management requires identification of
8.2 Software Design and Development all software elements, their version and history, their relation-
Software design uses various techniques and tools to make ships, and archival data. Change control is implemented for
and capture decisions as to how the software will be built. It identification and tracking of changes to software elements,
covers architecture, design, notations, user interface, security including problem reports, contract changes and source code
and safety, data engineering, and performance engineering. changes. Release management and delivery is the preparation
of software for release, distribution, installation and deploy-
Once a design has been defined, the software is developed
ment into operation. Deployment represents the activities
through programming and integration of software com-
that make the software available for use and is affected by the
ponents. This stage would also include the creation of
target physical environment, architectural and design con-
development documentation, user documentation and train-
straints, and security and performance concerns.
ing materials.

8.6 Management of Software Projects

8.3 Software Process Engineering
Software development needs to be effectively managed, just
Proven methodologies to develop software include the
like any other engineering project, to measure and con-
definition, measurement, and improvement of a software
trol the progress of the software project. Software project
engineering process to create a repeatable, predictable devel-
management uses planning and scheduling to define the
opment method or life cycle. There are a number of process
types of process lifecycles, work breakdown structure, and
models that formalize the task of developing software or use
estimations of workload. The management includes but is
project management techniques to better control the devel-
not limited to project tracking and metrics of progress, qual-
opment process.
ity, and expenditure. In addition to its initial development,
software needs to be maintained over its life cycle and one
8.4 Software Quality
important aspect is having a process for defects management
During development, it is necessary to ensure that the soft-
and tracking.
ware product adheres to applicable standards, conforms to its
requirements, and meets its end-user needs. Software quality
can be assessed through a number of techniques, including veri-

10 Develop ing S of t w a r e f or S a f e t y Cr it ic a l En g i n e e r i n g A p p l i ca t i o n s
8.7 Software Packaging ponents of software interfaces; interpretation of test results;
Delivery of the software will require its packaging or applica- implementation procedures/guides; user guides; and reports
tion in an electronic format that allows the user, whether a or other documents that express engineering work as contem-
client or another project group or team, to install, under- plated in the Professional Engineers Act (sections 1 and 12) or
stand or use the software. In addition to the software instruc- Regulation 941/90 (section 53), or reproductions of same
tion and training materials, the applicable professional
Software safety assessment
documents should be transmitted to the user. This docu-
Assessment providing an objective independent safety evalu-
mentation and information can be transmitted electronically
ation of the software in the overall system; a software safety
or through traditional means. In either case, all engineering
assessment ensures that software engineers/designers have
documents and safety critical software must be sealed.
considered safety aspects in their designs (for example fault
tree analysis, operational health and safety analysis, etc.)
9. Summary Software risks
Throughout their careers engineers may be involved in devel- Risks to the public interest caused by software system failure
oping safety critical software. The failure of safety critical
State of the art
software systems may pose risks to the public interest. Engi-
Highest level of development achieved at a particular time
neers must be aware of these risks and of their ethical and
professional responsibilities to protect the public. Appendix 2 Trade secret
contains some case studies of software system failures. Information including, but not limited to, a formula, pat-
tern, compilation, program, method, technique or process,
Several other organizations have created well-recognized
or information contained or embodied in a product, device
methodologies relating to the development of safety critical
or mechanism that:
software, some of which are listed in Appendix 1. Engineers
are advised to direct themselves to these references and other (i) is or may be used in trade or business;
well-recognized methodologies, as required. (ii) is not generally known in that trade or business;
(iii) has economic value from not being generally known; and
(iv) is the subject of efforts that are reasonable under the cir-
10. Definitions cumstances to maintain its secrecy
For the purposes of this guideline the following terms and
Verification
definitions apply.
The process of evaluating software to determine whether the
Fail-safe system products of a given development phase satisfy the conditions
In the event of a predictable system failure, the system is imposed at the start of that phase [taken from IEEE-
returned to a safe condition that minimizes risk to the pub- STD-610]. Verification ensures that the product was built
lic interest. according to the design requirements and specifications.
Verification ensures that “you built it right”.
Reasonable provision
Requirement that practitioners maintain the standards that Validation
a reasonable and prudent practitioner would maintain under The process of evaluating software during or at the end of
the circumstances the development process to determine whether it satisfies
specified requirements [taken from IEEE-STD-610]. Valida-
Safety critical software documentation
tion ensures that the product actually meets the user’s needs
Documents that express a professional opinion, judgment or
and fulfills intended use and goals. Validation ensures that
direction that someone else may rely upon; both hard copies
“you built the right thing”.
and electronic copies of design documents, professional docu-
ments, requirements, specifications, including documentation
of an operating environment (compiler, software versions,
etc.); testing specifications; test procedures for critical com-

P r o f e ssi o n a l E n g i n e e r s O n t a r i o 11
Appendix 1.–Software Engineering References of Interest to
Engineers
This list does not in any way limit the responsibility of an engineer or the scope of this guideline.

Reference Website
Associations
Association for Computing Machinery (ACM) http://www.acm.org/
Control Systems Integrators Association (CSIA) http://csia.connectedcommunity.org
IEEE Computer Society http://www.computer.org/portal/web/guest/home
Information Systems Audit and Control Association https://www.isaca.org/Pages/default.aspx
(ISACA)
Books
Software Engineering by Ian Sommerville http://www.softwareengineering-9.com/
Code of Ethics
Software Engineering Code of Ethics (IEEE Computer http://www.computer.org/portal/web/certification/
Society and ACM) resources/code_of_ethics
Guidelines
Guide to the Software Engineering Body of Knowledge http://www.swebok.org
(IEEE Computer Society)
Papers
Comparison between five models of Software Engineering http://www.ijcsi.org/papers/7-5-94-101.pdf
(IJCSI)
Software Process Engineering
Capability Maturity Model Integration (Carnegie Mel- http://cmmiinstitute.com/
lon–Software Engineering Institute)
Standards
ANSI UL 1998, Standard for Software in Programmable http://www.ul.com/global/eng/pages/solutions/standards/
Components (ANSI/UL) accessstandards/catalogofstandards/standard/?id=1998_2
C22.2 NO. 0.8-12–Safety functions incorporating electronic http://shop.csa.ca/en/canada/canadian-electrical-
technology (CSA) code-part-ii-general-requirements/c222-no-08-12/
invt/27007812012
N286.7.1-09–Guideline for the application of N286.7-99, http://shop.csa.ca/en/canada/nuclear/n28671-09/
Quality assurance of analytical, scientific, and design invt/27030082009
computer programs for nuclear power plants (CSA)
N290.14-07–Qualification of Pre-Developed Software http://shop.csa.ca/en/canada/nuclear/n29014-07-r2012/
for Use in Safety-Related Instrumentation and Control invt/27026862007
Applications in Nuclear Power Plants (CSA)
N290.4-11–Requirements for reactor control systems of http://shop.csa.ca/en/canada/nuclear/n2904-11/
nuclear power plants (CSA) invt/27009402011
Protecting against Common Cause Failures in Digital I&C http://www-pub.iaea.org/MTCD/publications/PDF/
Systems of Nuclear Power Plants (IAEA) Pub1410_web.pdf
Software for Computer Based Systems Important to http://www-pub.iaea.org/mtcd/publications/pdf/
Safety in Nuclear Power Plants (IAEA) pub1095_scr.pdf
Nuclear power plants–Instrumentation and control http://webstore.iec.ch/webstore/webstore.nsf/Artnum_
systems important to safety IEC 60880 (IEC) PK/36058

12 Develop ing S of t w a r e f or S a f e t y Cr it ic a l En g i n e e r i n g A p p l i ca t i o n s
Functional Safety and IEC 61508 (IEC) http://www.iec.ch/functionalsafety/
Software and Systems Engineering Standards (IEEE) http://standards.ieee.org/findstds/standard/software_
and_systems_engineering.html
Software and Systems Engineering Standards (ISO/IEC http://www.iso.org/iso/home/store/catalogue_tc/cata-
JTC1/SC7) logue_tc_browse.htm?commid=45086&published=on
Software Assurance Standards (NASA) http://www.hq.nasa.gov/office/codeq/software/docs.htm
Military Standard 498. Software Development and Docu- http://www.abelia.com/498pdf/498-STD.PDF
mentation (Mil Std)
Military Standard 1629A. Procedures for Performing a http://sre.org/pubs/Mil-Std-1629A.pdf
Failure Mode, Effects and Criticality Analysis (Mil Std)
Software Considerations in Airborne Systems and http://www.rtca.org/store_product.asp?prodid=581
Equipment Certification DO-178B (RTCA)

Appendix 2. Case Studies of Northeast power blackout in 2003

Engineers should ensure that safety critical software is ade-
Software System Failures quately monitored.
Several high-profile failures illustrate the requirement for
The electrical blackout affected an estimated 10 million
formal software engineering. These case studies do not in
people in Ontario and 45 million people in eight U.S.
any way limit the responsibility of an engineer or the scope
states. While this event was due to a combination of factors,
of this guideline.
one of the systems that failed was a computerized system
Therac-25 that should have raised an alarm when loads on many of
Engineers should design safety critical software that either one company’s lines started to be exceeded. Instead, the
adapts to changes in hardware or flags changes in hardware. alarm stayed silent and the operators remained unaware of
the problems. On older systems, each line would have had
In its original configuration, the Therac medical radiation
its own control and alarm systems.
treatment machine would not function unless a protec-
tive shield was in the correct position. The machine had a
flawless treatment record despite the danger posed by the
large dose of ionizing radiation it was capable of producing.
However, the software on the new machine was supposed
to incorporate this safeguard, but instead a combination of
faulty sensors on the shield, a slow response time to opera-
tor inputs and inadequate feedback to the operator led to at
least six accidental overexposures, three of which were fatal.

P r o f e ssi o n a l E n g i n e e r s O n t a r i o 13
Appendix 3. Amendment and Revision Submission Form
Guideline:

Statement of proposed amendment or revision:

Reason:

Submitted by: __________________________________________________ Date: _______________________________

Mail: Professional Engineers Ontario

101-40 Sheppard Avenue West
Toronto ON M2N 6K9

Attention: Standards and Guidelines Coordinator

Fax: (416) 224-1579 or (800) 268-0496

Email: practice-standards@ peo.on.ca

14 Develop ing S of t w a r e f or S a f e t y Cr it ic a l En g i n e e r i n g A p p l i ca t i o n s
Appendix 4. PEO Professional Practice Guidelines and Standards
Practice Guidelines
1. Acoustical Engineering Services in Land-Use Planning (1998)
2. Acting as Contract Employees (2001)
3. Acting as Independent Contractors (2001)
4. Acting under the Drainage Act (1988)
5. Building Projects Using Manufacturer-Designed Systems & Components (1999)
6. Commissioning Work in Buildings (1992)
7. Communications Services (1993)
8. Developing Software for Safety Critical Engineering Applications (2013)
9. Engineering Services to Municipalities (1986)
10. Environmental Site Assessment, Remediation and Management (1996)
11. General Review of Construction as Required by the Ontario Building Code (2008)
12. Geotechnical Engineering Services (1993)
13. Human Rights in Professional Practice (2009)
14. Land Development/Redevelopment Engineering Services (1994)
15. Mechanical and Electrical Engineering Services in Buildings (1997)
16. Professional Engineer as an Expert Witness (2011)
17. Professional Engineering Practice (2012)
18. Professional Engineer’s Duty to Report (1991)
19. Project Management Services (1991)
20. Reports for Pre-Start Health and Safety Reviews (2001)
21. Reports on Mineral Properties (2002)
22. Reviewing Work Prepared by Another Professional Engineer (2011)
23. Roads, Bridges and Associated Facilities (1995)
24. Selection of Engineering Services (1998)
25. Services for Demolition of Buildings and Other Structures (2011)
26. Solid Waste Management (1993)
27. Structural Engineering Services in Buildings (1995)
28. Temporary Works (1993)
29. Transportation and Traffic Engineering (1994)
30. Use of Agreements between Client and Engineer for Professional Engineering Services (including sample agreement) (2000)
31. Use of the Professional Engineer’s Seal (2008)
32. Using Software-Based Engineering Tools (2011)

Performance Standards
1. General Review of Construction of a Building (2008)
2. General Review of Demolition and Demolition Plans (2008)

P r o f e ssi o n a l E n g i n e e r s O n t a r i o 15
 Professional Engineers
Ontario
40 Sheppard Avenue West, Suite 101
Toronto, ON M2N 6K9

Tel: 416 224-1100 or 1 800 339-3716

Fax: 416 224-1579 or 1 800 268-0496

Enforcement Hotline: 416 224-9528 Ext. 1444

Website: www.peo.on.ca

Published by the Association of Professional Engineers of Ontario