Professional Engineers

Ontario

Professional Engineers Using

G u i d E l i n e
Software-Based Engineering
Tools

Contributors: Eric Brown, P.Eng. / Colin Cantlie, P.Eng., / Norm Fisher, P.Eng., /
Jeremy Jackson, P.Eng. / Tibor Palinko, P.Eng. / Daniel Tung, P.Eng. (Chair)

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 professional engineers engaged in

this area of practice. Users of this guideline who have questions, comments or suggestions for future amend-

ments and revisions are invited to submit these to PEO using the form provided in Appendix 2.

April 2011
Contents
1. PEO Mandate and Criteria for Guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3. Purpose and Scope of Guideline. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

4. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

5. Using Software-Based Engineering Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

5.1 Choosing the right software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2 Understanding the software in an engineering context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.3 Training and support for the software user. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.4 User’s responsibility for quality assurance of software output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.5 Configuration management for software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.6 Traceability for data and results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.7 Quality control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

6. Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

7. Issues Related to Software-Derived Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Appendix 1. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Appendix 2. Amendment and Revision Submission Form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Appendix 3. PEO Professional Practice Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1. PEO Mandate and Criteria for Guidelines
Professional Engineers Ontario produces guidelines 4. Guidelines add value to the professional engineer
for the purpose of educating both licensees and the licence for practitioners and for the public by outlin-
public about standards of practice. This is done to ing criteria for standards of best practice.
fulfill PEO’s legislated objectives. Section 2(4)2 of the 5. Guidelines help the public to understand what it
Professional Engineers Act states: “For the purpose of can expect of engineers in relation to a particular
carrying out its principal object”, PEO shall “estab- task within the practice of professional engineering.
lish, maintain and develop standards of qualification By demonstrating that the task requires specialized
and standards of practice for the practice of profes- knowledge, higher standards of care, and responsibil-
sional engineering”. The association’s Professional ity for life and property, guidelines help reinforce the
Standards Committee is responsible for developing public perception of engineers as professionals.
practice standards and preparing guidelines. This guideline is not intended to establish a “one
method of practice for all” approach to the practice
Professional Engineers Ontario produces guidelines
of professional engineering, or replace a practitioner’s
to meet the following objectives, which were used to
professional judgment when providing professional
develop the content of this document.
engineering services. Subject to provisions in the
1. Guidelines are intended to aid engineers in perform- guideline that incorporate professional conduct
ing their engineering role in accordance with the requirements or legal requirements, a decision by a
Professional Engineers Act and Regulations 941/90 practitioner not to follow the guideline will not, in
and 260/08. and of itself, indicate that a member has failed to
2. Guidelines are intended to describe processes maintain an acceptable standard of work. On the
required by regulatory, administrative or ethical other hand, following the guideline may not ensure
considerations associated with specific professional that a member has provided services conforming to
services provided by engineers. They do not aim to an acceptable standard. Determining whether a prac-
be short courses in an engineering subject. titioner’s service is acceptable will depend upon the
3. Guidelines provide criteria for expected practice by circumstances of each case.
describing the required outcome of the process, identi-
See Appendix 3 for a list of PEO professional practice
fying the engineer’s duty to the public in the particular
guidelines.
area of practice, and describing the relationships and
interactions between the various stakeholders (i.e.
government, architects, other engineers, clients).

2. Preface
The Professional Standards Committee formed a engineers depending on software as an aid in providing
subcommittee of practitioners from a variety of prac- engineering services.
tice areas who had experience providing professional
The subcommittee met for the first time on May
engineering services with the assistance of software.
26, 2006, and submitted a completed draft of this
This group was asked to address questions regarding
guideline to the Professional Standards Committee for
the proper role for and responsibilities incurred by
approval on May 14, 2009.
professional engineers using commercial, free source
and software developed by other practitioners. The Following practitioner consultations and review by
subcommittee was also instructed to prepare a guide- PEO legal counsel, the final draft was approved by
line providing recommendations to all professional the Professional Standards Committee on March 15,
2011 and by Council at its meeting on April 8, 2011.

P r o f e ssi o n a l E n g i n e e r s O nt ar i o 3
3. Purpose and Scope of Guideline
Most professional engineers rely on software to undertake procedures and controls presented here must be tailored
such tasks as calculations, modeling, and optimization to each project’s specific requirements. They are strongly
analysis as part of their engineering services or to provide recommended, but are not considered mandatory by the
information used as the basis for their decisions, judg- association.
ments and opinions.
This guideline does not deal with development of soft-
This guideline suggests considerations for the use of ware by the practitioner. Situations involving software as
computer programs in engineering work that are rea- the output of an engineering design process are the sub-
sonably necessary to protect the public. The practices, ject of a separate guideline.

4. Introduction
The practice of professional engineering has become Due diligence is the effort expected to be made by an
increasingly reliant on computers and engineers use ordinarily prudent or reasonable party to avoid harm to
many computer programs that incorporate engineering another party. A practitioner’s due diligence is best dem-
principles as aids in carrying out their assignments. This onstrated by taking an organized approach to ensuring all
software generally provides numerical or graphical output potential sources of error and omission are assessed and,
that the engineer uses as the basis of decisions. In many if necessary, corrected before any action is taken. The
cases, software provides complete design information, procedures and processes described in this guideline are
such as pipe or wire sizing, truss layouts or equipment an example of best practices for due diligence in situa-
selection, that engineers can use directly in their work. tions where practitioners rely on software tools.
Parametric design software, such as that available for
All practitioners must have an acceptable knowledge of
ductwork and piping design, can produce complete
and experience in the engineering principles involved in
drawings with no operator interaction beyond inputting
all the work they undertake. Article 72(2)(h), O. Reg.
initial conditions.
941 under the Professional Engineers Act identifies one
Professional engineers are responsible for all aspects of criterion of professional misconduct as “undertaking
the design or analysis they incorporate into their work, work the practitioner is not competent to perform by vir-
whether it is done by an engineering intern, a technolo- tue of the practitioner’s training and experience”. Using
gist or a computer program. Therefore, practitioners are software to automate part of the work does not relieve
advised always to use the data obtained from engineering practitioners of the obligation to provide services only in
software judiciously and only after submitting results to a their areas of competence.
vigorous checking process. This guideline explains at least
Note: References in this guideline to professional
some of the steps needed to fulfill the practitioner’s due
engineers apply equally to temporary licence holders,
diligence obligations.
provisional licence holders and limited licence holders.

4 Us ing So ftw a re - Ba s e d E ngine e r ing Tools

5. Using Software-Based Engineering Tools
This guideline deals with situations where software is competent to evaluate the software) should be able to
used to assist professional engineers in performing the justify the selection of each software tool.
engineering activities included in the definition of the
The first step in assessing whether a certain software
“practice of professional engineering” given in section
tool is right for the task is to document requirements
1 of the Professional Engineers Act. The listed activities
for the software tool and then validate that the cho-
are planning, designing, composing, evaluating, advis-
sen tool actually meets these requirements. Some of
ing, reporting, directing or supervising. This guideline
the questions to consider include: Can all input data
refers to the use of engineering software as a contribu-
be seen on the page? Or do you see data only as it is
tor to any of these activities.
entered? Does the software provide data entry check-
ing to ensure the data entered is within reasonable
5.1 Choosing the right software bounds? Does the software provide a copy of the
As part of their due diligence obligations, practitioners input data in the output display or printout? Engi-
have a responsibility to accept or reject software based neers should avoid software that does not provide a
on their own assessment of the compatibility and via- means for verifying and recording input data.
bility of the software to the task at hand. Engineering
Does the software have defaults for data the user does
practitioners must understand the limitations of the
not supply? Are the defaults reasonable? Does the soft-
software tools proposed to be used for an engineering
ware allow the practitioner to modify all relevant data
project and carefully consider whether the software is
or does it appear that certain constants are fixed by
appropriate for the purpose intended. A practitioner
the developer? In other words, does the software offer
should decide to use a software-based engineering tool
the practitioner sufficient control or is the practitioner
only if he or she has a high degree of confidence that
held hostage to decisions made by the developer?
it is an appropriate technical means for accomplishing
the task. Does the software accommodate the initial conditions
and all the physical states of the equipment, processes
Even the best software will provide incorrect results
and/or systems that are the subject of the calculations?
if the engineer is either using it incorrectly or is using
software that is inappropriate for the engineer’s needs.
Every practitioner should consider, prior to use, 5.2 Understanding the software in
whether the software to be used is the right product an engineering context
for the purpose and can perform this work reliably. If Knowing how to use the software properly is cru-
the software used is not appropriate, the practitioner cial for getting correct answers. Practitioners should
may be relying on faulty data. For example, software become familiar with all aspects of the software prior
provided by an equipment supplier might rely on to using it for design or analysis purposes.
technical information specific to that equipment and
Engineering programs are based upon or include
for that reason the data that results might not be gen-
assumptions, limitations, interpretations and judg-
erally applicable. Using this data might result in an
ments on engineering matters that were made by
ill-conceived and problematic design.
or on behalf of the user when the program was first
Before purchasing or using software, practitioners developed. It is often difficult to determine just by
should assure themselves that it will do what they using a program or by being given a description of its
need. By reading user reviews and software manuals function how the software deals with the engineering
and talking to other users, practitioners should be able principles and technical information it incorporates.
to determine the software’s capabilities and whether it Engineers should become familiar with the engineer-
is dependable for their work. However, practitioners ing principles, equations, models, algorithms and
(or, where appropriate, someone in their organizations assumptions used in the software. Some developers

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
 provide manuals, or white papers, containing detailed The practitioner should test all problematic situations
explanations of the software’s underlying structure. Prac- that arose in the past. This will require the keeping of
titioners should acquire and review these documents. logs reporting software performance and user observa-
tions of problems experienced and limitations.

5.3 Training and support for the In larger organizations, software choice, testing and
software user verification might be undertaken by other qualified
Practitioners should also consider taking courses avail- people rather than by every practitioner. In these orga-
able through the supplier or a third party trainer. nizations, a practitioner need only assure themselves
When the developer does not supply a user manual or that such corporate practices exist and are responsibly
the manual is not comprehensive the engineer should executed and documented. The practitioner need
obtain third-party texts, if these are available. only review that record rather than be individually
responsible for each of the QA tasks described in this
Make use of informal sources of expert advice. For
section.
example, users of many common software applications
have established support networks, such as forums
and user groups, that share experiences and informa- 5.5 Configuration management for
tion regarding the software. These groups, while not software
a substitute for the exercise of professional judgment, Configuration management is record-keeping related to
can provide warnings about software bugs, help with the maintenance, upgrading, alteration and problems
resolving application problems, and offer suggestions experienced with the hardware and software used by an
for improving the software and its use. organization. Configuration management comprises four
tasks.

5.4 User’s responsibility for quality • Identification–this is the selecting, specifying and
assurance of software output identifying of all components and their inter-relation-
Quality assurance is a process meant to ensure that (a) ships and making provision to record and retain this
software is installed and configured correctly; and (b) information.
that all users are using the software correctly. The pro- • Control–this is the management of each identified
cess will involve checking configuration management configuration item, specifying who is authorized to
records and testing based on standardized input. “change” it, and ensuring only authorized and iden-
tifiable configuration items are accepted.
The quality assurance procedure should be performed
• Status–this task is the recording of the status of all
every time software or relevant hardware is updated
configuration items in the database, and the mainte-
or reconfigured. This is done by qualifying each new
nance of this information.
version of the software against the standard set of data
• Verification–this task involves reviews and audits to
and observing any deviations from output generated
ensure the recorded configuration information is
by previous versions. To substantiate results, practi-
accurate.
tioners should keep records of input data, preferably a
record supplied by the software either as an electronic Keeping these records will ensure the practitioner
data file or as a printout, and check output from knows the version currently being used and whether
newer software versions with that obtained from ear- everyone in the organization or project team is using
lier, verified versions. the same version. The records will confirm whether
this version has been verified for use.
When verifying updated versions of previously used
software, testing may concentrate on those features
changed or added in the new version. However, prac-
titioners should not assume that previously existing
features continue to function correctly.

6 Us ing So ftw a re - Ba s e d E ngine e r ing Tools

5.6 Traceability for data and results correct. This includes designs and opinions based on
Even if the software has some form of input check- software-derived data. Output data should be checked
ing, it cannot determine if the information provided thoroughly enough that the engineer is reasonably
is the correct information for the project. Practitioners assured the data is correct. This may involve manual
should know which version of input data was used calculation of a random selection of the output data
to generate every set of output. It is also important or comparison with data obtained for past projects of
to know which version of the software produced the a similar nature. Defective output discovered while
output data. using software-based tools should be examined closely
to determine the implications on the tools’ suitability
for use. Practitioners who are not directly responsible
5.7 Quality control
for a firm’s QA/QC or management/configuration
Quality control procedures should be implemented
processes should, after discovering “defective” output
each time software is used to carry out engineering
where the nature of the defect is not obviously user
activities. Engineers are responsible for ensuring their
error, notify the responsible individuals
designs or the opinions they provide in reports are

6. Verification
Professional engineers are responsible for the accuracy, a specific run is reliable and can be used for design
completeness and acceptability of all aspects of the purposes. This process assumes the software operates
services they provide, including information obtained correctly and, therefore, problematic output is caused
using software. Given the increasing reliance on by incorrect use, faulty input data, or a design that
computer software, engineers should ensure a compre- falls outside the bounds of the software’s reliability.
hensive verification of the software’s performance exists.
Verification, on the other hand, is an evaluation, con-
Widely used, industry standard software undergoes ducted outside the process of design and analysis for
ongoing verification by regular users, who routinely specific projects, to determine, prior to use, whether
apply results obtained from the software to their engi- the software, when used within its stated limitations,
neering work. Each completed project based on the consistently provides correct output. Software is veri-
software is a testament to its applicability. In all cases, fied by comparing the output, for well defined input
engineers should establish and conduct suitable tests conditions, against data known to be correct, based
to determine whether the software performs as it is on either actual results from real-life situations or
required to do. thoroughly checked manual calculations.

Software verification is not the same as checking the The verification process can also be used to ensure
output of a run to see if it is reasonable. Checking of that every person using the software does so correctly
output after each run is necessary to ensure the data or to compare various software products to determine
was entered correctly for the particular engineering which is the most reliable.
project underway. The checking process is a quality
assurance measure employed to ensure the output of

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
7. Issues Related to Software-Derived Information
Output from computer programs, like all working notes ner, the data should be distributed either as hard copies
and calculations, are usually the property of the engineer or electronic files bearing the seal and signature of the
(or his or her employer) and generally do not need to be professional engineers who prepared or supervised the
provided to the client or submitted as part of regulatory preparation of the input data and checked the output
approval processes unless required by law or contract. data. See the PEO guideline Use of the Professional Engi-
neer’s Seal for further information regarding the proper
In those cases where output data must be supplied to
use of the seal.
people outside the organization employing the practitio-

Appendix 1. Definitions
For the purposes of this guideline: Quality assurance
Configuration Item A managerial function involving all the planned and sys-
A computer element treated as a self-contained unit for tematic activities within the quality management system
the purposes of identification and change control. All to provide confidence the project will satisfy the relevant
configuration items (CIs) should be uniquely identified quality standards.
by codes and version numbers. CIs might be a single
Quality control
software or hardware module, such as a compiler, sub-
An inspection function using quality control tools,
routine, monitor or tape drive, or more complex items,
involving monitoring specific project results to determine
such as a complete system.
if they comply with relevant quality standards and iden-
Configuration management tifying ways to eliminate causes of unsatisfactory results.
Process and procedures for maintaining a database con- It is focused on the deliverables and involves procedures
taining details of the computer elements that are used in that determine if specified quality is attained.
providing an organization’s services. More than just an
Validation
“asset register”, it will contain information that relates to
The process of determining the correctness of a deliver-
the maintenance, movement, and problems experienced
able with respect to the user’s needs.
with the elements in the database.
Verification
Engineering activities
The process of reviewing, inspecting and testing a soft-
Activities included in the definition of the practice of
ware tool under standardized conditions to determine
professional engineering given in Section 1 of the Profes-
whether there is adequate assurance the output of the
sional Engineers Act. The listed activities are planning,
tool will conform to the specified requirements.
designing, composing, evaluating, advising, reporting,
directing or supervising.

8 Us ing So ftw a re - Ba s e d E ngine e r ing Tools

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

Appendix 3. PEO Professional Practice Guidelines
1. Acting as Contract Employees (2001)
2. Acting as Independent Contractors (2001)
3. Acting Under the Drainage Act (1988)
4. Acoustical Engineering Services in Land-Use Planning (1998)
5. Building Projects Using Manufacturer-Designed Systems & Components (1999)
6. Commissioning Work in Buildings (1992)
7. Communications Services (1993)
8. Engineering Services to Municipalities (1986)
9. Environmental Site Assessment, Remediation and Management (1996)
10. General Review of Construction as Required by the Ontario Building Code (2008)
11. Geotechnical Engineering Services (1993)
12. Guideline to Professional Practice (1998)
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 (1997)
17. Professional Engineer’s Duty to Report (1991)
18. Project Management Services (1991)
19. Reports for Pre-Start Health and Safety Reviews (2001)
20. Reports on Mineral Properties (2002)
21. Roads, Bridges and Associated Facilities (1995)
22. Selection of Engineering Services (1998)
23. Services for Demolition of Buildings and other Structures (2011)
24. Solid Waste Management (1993)
25. Structural Engineering Services in Buildings (1995)
26. Temporary Works (1993)
27. Transportation and Traffic Engineering (1994)
28. Use of Agreements between Client and Engineer for Professional Engineering Services (including sample agreement)
(2000)
29. Use of Computer Software Tools Affecting Public Safety or Welfare (1993)
30. Use of the Professional Engineer’s Seal (2008)
31. Using Software-Based Engineering Tools (2011)

10 Us ing So ftw a re - Ba s e d E ngine e r ing Tools

Published by the Association of Professional Engineers of Ontario