Sources and References

Primary textbook — Gordon C. Andrews, J. Dwight Aplevich, Roydon A. Fraser & Carolyn G. MacGregor, Introduction to Professional Engineering in Canada, 5th ed., Pearson, 2019.

Supplementary design references — Clive L. Dym, Patrick Little & Elizabeth J. Orwin, Engineering Design: A Project-Based Introduction, 4th ed., Wiley, 2014; Susan McCahan, Philip Anderson, Mark Kortschot, Peter E. Weiss & Kimberly A. Woodhouse, Designing Engineers: An Introductory Text, Wiley, 2015.

Professional and regulatory sources — Engineers Canada, National Guideline on Sustainable Development and Environmental Stewardship for Professional Engineers, 2016; Engineers Canada, Code of Ethics (public document, engineerscanada.ca); Canadian Engineering Accreditation Board (CEAB), Accreditation Criteria and Procedures, current edition; Professional Engineers Ontario (PEO), Professional Engineers Act, R.S.O. 1990; Government of Canada, Patent Act, R.S.C. 1985; Government of Canada, Copyright Act, R.S.C. 1985.

Open-access resources — National Academy of Engineering, Educating the Engineer of 2020, National Academies Press, 2005; IEEE, IEEE Code of Ethics (public document, ieee.org); Mike W. Martin & Roland Schinzinger, Ethics in Engineering, 4th ed., McGraw-Hill, 2005.

Chapter 1: The Engineering Profession in Canada

1.1 What Is Engineering?

Engineering is the application of scientific principles, mathematical reasoning, and practical judgment to design, construct, and operate systems, structures, and processes that meet human needs while managing risks and using resources responsibly. This definition sounds simple, but it conceals a great deal. Unlike pure science — where the goal is to discover how nature works — engineering is inherently normative: it asks not merely “what is possible?” but “what should be built, and for whom, and at what cost and risk?” That normative dimension is why the profession is regulated, why there is a code of ethics, and why courses like ECE 190 exist at all.

In Canada the word “engineer” applied to professional practice is a protected title. You may have heard it used informally — “software engineer,” “locomotive engineer,” “sanitation engineer” — but in the legal sense applicable to regulated professional practice, an engineer is someone who holds a licence granted by a provincial or territorial engineering association. That licence carries obligations to the public that no amount of technical skill alone can substitute for.

The scope of electrical and computer engineering within this landscape is broad and growing. It spans power systems, control and automation, communications networks, embedded systems, signal processing, computer architecture, and the software that binds all of these together. ECE practitioners design the microcontrollers inside pacemakers and the algorithms that route internet traffic. The breadth of the domain means that an ECE graduate will spend a career exercising judgment under uncertainty — precisely the kind of judgment that professional preparation addresses.

1.2 The Regulatory Framework in Canada

Canada’s regulatory structure for engineering is provincial. Each province and territory has its own engineering association and its own legislation, typically called the Engineering Act or the Professional Engineers Act. In Ontario the governing statute is the Professional Engineers Act, R.S.O. 1990, which establishes Professional Engineers Ontario (PEO) as the licensing body. Similar bodies exist across the country: APEGA in Alberta, EGBC in British Columbia, OIQ in Quebec, Engineers Nova Scotia, and so on.

To obtain a P.Eng. licence in a typical province an applicant must: (1) hold an accredited engineering degree, (2) complete at least four years of engineering experience — at least one year of which must be in Canada — under the supervision of a licensed professional engineer, (3) demonstrate good character, and (4) pass, in most jurisdictions, a Professional Practice Examination (PPE) covering law, ethics, and professional practice. The experience requirement is not merely a formality; it reflects the profession’s recognition that textbook knowledge becomes engineering competence only through supervised practice.

Engineers Canada is the national body that coordinates the provincial and territorial associations. It does not license engineers itself — licensing remains provincial — but it performs two critical national functions: it operates the Canadian Engineering Accreditation Board (CEAB), which accredits undergraduate engineering programs, and it produces national guidelines on ethics, equity, sustainability, and other matters of shared professional concern.

CEAB accreditation matters enormously for students. A degree from a CEAB-accredited program satisfies the academic requirement for licensure in any Canadian province without further examination of academic credentials. If a program loses accreditation, graduates may face additional scrutiny or examinations before being licensed. The CEAB evaluates programs against twelve graduate attributes — clusters of competency that every accredited engineering graduate must demonstrate. ECE 190 itself is designed to develop several of these attributes, including professionalism, ethics and equity, and impact of engineering on society and the environment.

1.3 The Iron Ring and Engineering Identity

First-year engineering students at Canadian universities encounter the Iron Ring ceremony early in their academic career. The ring — made of stainless steel, despite the traditional name — is presented at the Ritual of the Calling of an Engineer to students who have completed their engineering degree. The ring is worn on the little finger of the working hand as a reminder of the engineer’s obligations to society and of the role that professional failures can play when ethical and technical vigilance lapses.

The ceremony itself is private and its text is not published, but the underlying idea is public knowledge: engineering work affects real people and real environments, and the engineer who forgets that fact risks becoming the agent of preventable harm. The introductory Iron Pin ceremony that first-year ECE students attend — before they have completed a full degree — is a symbolic foreshadowing of that future commitment.

Chapter 2: Working in Teams

2.1 Why Teams Matter in Engineering

Virtually all significant engineering projects are team efforts. The scale and interdisciplinary complexity of modern systems — a 5G base station, an autonomous vehicle, a smart-grid controller — far exceed what any individual engineer could design, analyse, and implement alone. Teams distribute cognitive load, bring diverse perspectives to design problems, and provide error-checking through peer review. But teams also introduce coordination costs, communication overhead, and interpersonal dynamics that can undermine performance if left unmanaged.

For first-year students the challenge is two-fold: you are learning engineering content at the same time as you are learning how to work productively with people you may not have chosen as collaborators. Both skills are genuine engineering skills, not peripheral soft skills, and both require deliberate practice.

2.2 The Group Agreement

A useful early step for any project team is establishing explicit norms before disagreements arise. A Group Agreement (sometimes called a team charter) records: how the group will communicate, how decisions will be made, how work will be divided, what standards of quality are expected, what happens when a member misses a deadline, and how conflicts will be resolved. Writing these norms down when the group is in a cooperative mood makes it far easier to address problems later without those problems feeling like personal attacks.

A well-designed group agreement does not eliminate conflict — it provides a pre-agreed framework for managing it. This is analogous to a professional engineering contract: it does not prevent disputes, but it establishes the terms under which disputes are adjudicated.

2.3 The Three Design-Team Traps

Research on student and professional design teams identifies three recurring failure modes that Dan Davison’s course labels the “design-team traps.” Understanding them is the first step toward avoiding them.

Ignorance occurs when team members lack shared awareness of the project’s current state, their teammates’ progress, or the technical constraints bearing on the work. A team can fall into ignorance gradually — as a sprint deadline approaches, individuals stop sharing updates and start heads-down coding or prototyping — and suddenly discover, the day before submission, that two sub-components are incompatible. Regular standups, shared documentation, and explicit handoff protocols are the antidote.

Staleness is a subtler trap. It occurs when the team’s collective understanding of the design problem has grown outdated relative to the actual state of the project or the external requirements. Imagine a team that finalised its design concept in week two of a six-week project and then dutifully implemented it — only to learn in week five that a key constraint had changed, or that a competitor had released a far simpler solution, or that the initial concept violated a safety standard the team had not researched. Staleness is overcome by building regular design reviews and deliberate reflection checkpoints into the project schedule, not merely barrelling toward implementation.

Social loafing is the phenomenon, well-documented in social psychology, whereby individuals exert less effort in a group than they would working alone. It arises because effort within a group is less individually identifiable and because each member can reason that others will compensate for their reduced contribution. The remedy is individual accountability: each team member should have clearly assigned deliverables, and the team should review individual contributions openly enough that coasting is visible.

2.4 Keys to Academic Success in Engineering

The transition from secondary school to university engineering is significant. The workload is heavier, the pace is faster, assessment is less forgiving, and the curriculum makes cumulative demands — material from week two reappears as a prerequisite for week eight. Several habits of mind are consistently associated with success:

• Active engagement rather than passive attendance. Sitting in a lecture is not the same as learning; genuine comprehension requires working problems, testing understanding, seeking help when confused.
• Consistent effort distributed across the term rather than concentrated before deadlines. The engineering brain is better at consolidating material that is revisited repeatedly than material crammed in a single session.
• Use of resources — office hours, tutors, peer study groups, and course forums. Students who seek help early rarely fall catastrophically behind; students who wait until a week before the exam frequently do.
• Metacognitive awareness: periodically asking yourself not just “do I understand this material?” but “how do I know I understand it, and how would I demonstrate that understanding on an exam?”

Chapter 3: The Engineering Design Process

3.1 Design as a Discipline

Engineering design is the structured intellectual process by which engineers move from a statement of need to a realised solution. It is not the same as invention or creativity in the general sense, though it draws on both; it is a disciplined, iterative, and risk-conscious activity that must satisfy multiple simultaneous constraints — functional performance, safety, cost, manufacturability, regulatory compliance, environmental impact, and human factors.

The design process can be described at different levels of abstraction. At the broadest level it has a recurring structure: understand the problem, generate candidate solutions, evaluate and select among them, implement the chosen solution, and test and refine it. At a finer grain, different models — the waterfall model, Dym and Little’s design spiral, McCahan et al.’s iterative model — add intermediate stages, explicit feedback loops, and structured decision-making tools. ECE 190 introduces students to the high-level structure; subsequent design courses in the ECE curriculum build on it with increasing technical sophistication.

3.2 Stages of the Design Process

Clarifying requirements is where design begins. The customer, client, or user presents a need — often vaguely stated. The engineer’s first job is to convert that vague need into a set of engineering requirements: measurable, verifiable criteria that a solution must meet. This conversion involves asking clarifying questions, researching the domain, identifying constraints, and distinguishing must-have requirements from nice-to-have preferences. Omitting this step and rushing to solution generation is one of the most common and consequential design errors.

Generating concepts follows from a clear requirements statement. Effective concept generation is divergent: the goal is to produce a wide range of candidate solutions before converging on any of them. Techniques such as brainstorming, morphological charts, biomimicry, and SCAMPER (Substitute, Combine, Adapt, Modify, Put to other uses, Eliminate, Reverse) help teams escape the trap of anchoring on the first plausible idea.

Evaluating and selecting narrows the candidate set using structured methods. A Pugh matrix (decision matrix) allows a team to score each concept against each requirement, using weights if some requirements are more critical than others. The output is not a mechanical “winner” but rather a basis for informed engineering judgment, including the possibility of combining the best features of several concepts.

Prototyping and testing turns the chosen concept into a physical or computational artefact. In ECE, a prototype might be a breadboard circuit, a software simulation, a 3D-printed housing, or a combination of all three. Testing checks whether the prototype meets the requirements established at the outset — not the requirements the engineer wishes they had written, but the requirements they actually wrote. Discrepancies between prototype performance and requirements either indicate a problem with the design (go back and redesign) or a problem with the requirements (go back to the client and negotiate).

Iteration is not a separate stage but a meta-level property of the whole process. Real engineering design cycles back repeatedly — a prototype reveals a misunderstood requirement, a simulation exposes a critical failure mode, a user test reveals a usability problem. The willingness to iterate, even when it feels like regression, is a hallmark of professional engineering practice.

3.3 Design for Safety

Safety is not a feature to be added to a design after the core functionality is established — it is a constraint that should shape every stage of the design process. Engineers in Canada are legally obligated to practise in a manner that protects public safety; the licensing regime exists precisely because engineering decisions can kill people when made incompetently or negligently.

Designing for safety involves: identifying the ways a system can fail (failure mode analysis), estimating the probability and consequence of each failure (risk assessment), and then modifying the design to eliminate or mitigate unacceptable risks. A circuit that might electrocute a user under a foreseeable fault condition is not a “good enough” circuit that needs a safety sticker — it is a design that requires redesign.

Chapter 4: Engineering Ethics

4.1 Why Ethics and Engineering Are Inseparable

The idea that engineering is a purely technical discipline and that ethics is a separate concern — something belonging to philosophy departments or corporate social-responsibility teams — is fundamentally mistaken. Every engineering decision involves a value judgment: how much risk is acceptable, who bears the cost if something goes wrong, whose needs the system is designed to serve. Treating these as purely technical optimisation problems conceals, rather than resolves, the underlying ethical questions.

The bridge between technical practice and ethical obligation is institutionalised in Canada through codes of ethics maintained by the provincial engineering associations and by Engineers Canada. These codes are not aspirational suggestions; violation of a code of ethics can result in disciplinary action by the provincial association up to and including revocation of the licence to practise.

4.2 The Engineers Canada Code of Ethics

Engineers Canada’s Code of Ethics articulates the fundamental duties of professional engineers. While the precise wording varies slightly across provincial codes (which are enacted under provincial legislation), the substance is consistent. The following are the core duties common to virtually all Canadian engineering codes of ethics:

The ordering of the first duty — the public interest comes before the client’s interest, the employer’s interest, and the engineer’s personal interest — is not accidental. It reflects the foundational rationale for the licensing system: society grants engineers a degree of professional autonomy because engineers promise to use that autonomy in service of the public good. When the two come into conflict, the public interest prevails.

4.3 Ethical Frameworks for Engineering Decisions

Three major ethical frameworks from philosophy provide engineers with structured ways of thinking through difficult decisions. Each captures something important; none provides a complete algorithm.

Consequentialism (and its most common variant, utilitarianism) evaluates actions by their outcomes. The right action is the one that produces the greatest good for the greatest number. In engineering, consequentialist reasoning is familiar: cost-benefit analysis and risk-benefit analysis are applied consequentialism. The framework is powerful for comparing options with different outcome profiles, but it faces well-known challenges — how do you quantify human suffering? whose welfare counts? how far into the future do you project consequences?

Deontological ethics (associated most prominently with Kant) holds that certain actions are intrinsically right or wrong, independent of consequences. A deontological engineer says: “I must not deceive my client even if the deception would, on balance, produce better outcomes.” This approach maps naturally onto professional codes of ethics, which articulate duties — to be honest, to protect the public, to practise within competence — rather than outcome targets. The challenge is adjudicating conflicts between duties.

Virtue ethics shifts the focus from actions to character. Rather than asking “what rule applies?” or “what outcome does this produce?”, virtue ethics asks “what would a person of good character — courageous, honest, fair, careful — do in this situation?” For the engineering profession, the relevant virtues include technical conscientiousness, intellectual honesty, courage (the willingness to report a safety concern even when doing so is professionally costly), and humility about the limits of one’s own knowledge.

In practice, experienced engineers draw on all three frameworks, and a decision that seems clearly wrong from multiple frameworks simultaneously deserves serious scrutiny.

4.4 Resolving Ethical Dilemmas: A Structured Approach

An ethical dilemma is a situation in which two or more ethical obligations conflict, or in which every available option involves some moral cost. Students sometimes think dilemmas are rare — they are not. An engineer who discovers a potential safety defect in a product about to be shipped faces a conflict between the duty to protect the public and the institutional pressure to meet a deadline. An engineer asked to sign off on a design that falls outside her area of expertise faces a conflict between her professional obligations and the expectation of her employer.

A useful structured approach to ethical dilemmas:

1. Identify the facts. Separate what is known from what is uncertain. Many apparent dilemmas dissolve when the facts are clarified.
2. Identify the stakeholders. Who will be affected by each possible decision, and how?
3. Identify the relevant ethical obligations. Which professional duties, legal requirements, and ethical principles bear on the situation?
4. Generate options. There are almost always more than two options; search for creative alternatives that reduce the conflict.
5. Evaluate each option using multiple ethical frameworks. If one option looks bad from consequentialist, deontological, and virtue-ethics perspectives, that convergence is significant.
6. Make a decision and be prepared to justify it. A professional engineer must be able to articulate the reasoning behind an ethical choice, not merely assert a preference.
7. Reflect on the outcome. Did the decision achieve what was intended? What would you do differently?

4.5 Whistleblowing and Dissent

Perhaps the most personally difficult ethical situation an engineer can face is the discovery that an employer or client is engaged in, or about to engage in, conduct that poses a risk to public safety or that is clearly unethical or illegal. The engineer who speaks up — internally or externally — is a whistleblower, and the act of whistleblowing carries genuine professional and personal risks.

Canadian engineering codes of ethics recognise this tension. They impose an obligation to report: PEO’s code, for example, holds that a professional engineer “shall, where possible, report to their association or other appropriate authority any situation of unethical, illegal or unprofessional conduct by another engineer.” The phrase “where possible” acknowledges the real costs of speaking up. But the public-interest primacy of the first duty makes clear that when safety is genuinely at stake, the obligation to act overrides the personal cost of acting.

Legitimate internal channels — speaking to a supervisor, raising the issue with a compliance office, consulting the company’s legal counsel — should generally be exhausted before external disclosure. But when internal channels fail or are unavailable, external reporting to a regulator or public health authority may be the only way to fulfil the professional duty to protect the public.

Chapter 5: Sustainability and Environmental Responsibility

5.1 Sustainable Development Defined

The most widely cited definition of sustainable development comes from the 1987 Brundtland Commission report, Our Common Future, published by the United Nations World Commission on Environment and Development:

This formulation contains a temporal dimension — the interests of people not yet born — that conventional economic analysis, focused on discounted present value, tends to underweight. For engineers it implies an obligation that extends beyond satisfying the client who is paying today toward considering the environmental and social legacy of the artefacts and systems being built.

The Brundtland definition has been unpacked into three interacting pillars: environmental sustainability (maintaining ecosystem integrity and natural capital), economic sustainability (supporting viable livelihoods and growth), and social sustainability (ensuring equity, health, and community well-being). Engineers who design systems that devastate local ecosystems while generating short-term profit are failing on the environmental pillar; engineers who design efficient systems accessible only to wealthy nations are failing on the social pillar.

5.2 The Engineering Dimension of Sustainability

Engineers are among the most consequential actors in the sustainability transition because the physical infrastructure of modern life — energy systems, transportation networks, buildings, water treatment, electronics — was designed by engineers and can only be fundamentally transformed by engineers. The scale of this challenge is enormous: global energy demand continues to grow, the electrical grid in most countries still depends substantially on fossil fuels, and the embedded carbon in manufactured goods represents a significant and often-invisible fraction of lifecycle emissions.

Engineers Canada’s national guideline on sustainable development places the responsibility squarely on professional engineers to consider the environmental impact of their work. This means, at minimum: considering energy and material efficiency in design, selecting materials with lower environmental burden where technically feasible, designing systems for longevity and repairability rather than planned obsolescence, and conducting lifecycle analysis when significant environmental impacts are foreseeable.

Lifecycle analysis (LCA) is a formal method for quantifying the environmental impacts of a product or system from raw material extraction through manufacturing, use, and end-of-life disposal — sometimes called “cradle to grave” analysis. For an ECE product like a smartphone, an LCA reveals that a substantial fraction of its lifetime carbon footprint is embedded in the device at the point of manufacture, not consumed during use. This finding has design implications: extending device lifetime through repairability and software support reduces lifetime environmental impact even if individual components are less efficient.

5.3 The Circular Economy and Design for Sustainability

The circular economy concept proposes an alternative to the dominant “take-make-dispose” model of industrial production. In a circular economy, products are designed to be reused, repaired, remanufactured, or recycled, with the goal of keeping materials in productive use indefinitely. For electronics engineers this implies: modular designs that allow component replacement, standardised connectors and protocols that enable interoperability across manufacturers, materials choices that avoid hard-to-separate composites, and avoidance of hazardous substances that complicate recycling.

The European Union’s Ecodesign Regulation, the Canadian government’s Right to Repair discussions, and numerous provincial extended producer responsibility (EPR) programs are regulatory frameworks that push in this direction. Engineers who understand the sustainability landscape are better positioned to design compliant and future-proof products.

Chapter 6: Risk Management

6.1 Risk as a Core Engineering Concept

Engineering cannot eliminate risk; it can only manage it. Every structure, circuit, software system, and process has some nonzero probability of failing, and every failure has some consequence — ranging from negligible inconvenience to catastrophic loss of life. The engineer’s job is to understand the risks embedded in a design, communicate those risks honestly to clients and the public, and take reasonable steps to reduce the risks that are unacceptable.

In practice, both probability and consequence are often uncertain, and the multiplication model is a simplification. Nonetheless the framework is enormously useful for organising thinking about risk and for communicating with clients, regulators, and the public.

6.2 Identifying Hazards

Before risks can be managed, hazards must be identified. A hazard is a potential source of harm — a high-voltage bus bar, a software bug that could cause a system to enter an unsafe state, a chemical whose vapours are toxic at elevated temperatures. Identifying all relevant hazards is genuinely difficult; engineers must draw on domain knowledge, historical failure data, systematic analysis methods, and sometimes imagination.

Common hazard identification methods include:

• Failure Mode and Effects Analysis (FMEA): A systematic, component-by-component analysis that asks, for each component, “how could this fail, and what would be the effect?” FMEA produces a table of failure modes, their causes, their effects on the system, and their associated risk levels.
• Fault Tree Analysis (FTA): A top-down, deductive method that starts with an undesired event (a “top event”) and works backward to identify the combinations of component failures and external events that could cause it. The result is a tree structure in which AND gates and OR gates represent logical combinations of causal factors.
• Hazard and Operability Study (HAZOP): A structured, team-based method developed in the chemical process industry that systematically applies guide words (No, More, Less, As Well As, Reverse, Other Than) to process parameters to generate potential deviations and their consequences.

6.3 Risk Control Strategies

Once hazards have been identified and risks assessed, engineers choose among several strategies for reducing risk to acceptable levels. The preferred hierarchy, articulated in occupational health and safety frameworks and reflected in engineering design standards, is:

1. Eliminate the hazard. Design the hazard out of the system entirely. If a chemical process can be redesigned to avoid using a toxic solvent, that is safer than any amount of protective equipment.
2. Substitute. Replace a higher-hazard element with a lower-hazard alternative.
3. Isolate or enclose. Physically separate the hazard from people or other vulnerable elements.
4. Engineering controls. Design features that reduce exposure even when the hazard cannot be eliminated — pressure relief valves, circuit breakers, interlocks.
5. Administrative controls. Procedures, training, and warnings that reduce risk through human behaviour.
6. Personal protective equipment (PPE). The last resort, because it depends entirely on correct human behaviour and can fail.

This hierarchy matters in engineering design because it tells engineers where to focus effort. Putting a warning label on a product to address a hazard that could have been designed out is ethically inferior — and, increasingly, legally insufficient — to eliminating the hazard in the first place.

6.4 Workplace Safety and the Engineer’s Role

Engineers work in environments — laboratories, construction sites, manufacturing plants, utilities infrastructure — where workplace hazards are real and sometimes severe. In Canada, occupational health and safety is governed by a combination of federal legislation (for federally regulated workplaces) and provincial acts (for all others, which constitute the majority). Ontario’s Occupational Health and Safety Act (OHSA) establishes the rights and duties of workers, supervisors, and employers.

A key principle in Canadian workplace safety law is the right to refuse unsafe work. A worker in Ontario has the legal right to refuse to perform work that they believe is likely to endanger themselves or another worker, and this right cannot be used as grounds for dismissal or reprisal. For engineering students and new graduates, understanding this right — and the complementary obligation on engineers who supervise work to ensure safe conditions — is part of professional preparation.

The Internal Responsibility System (IRS), a concept developed in Canadian occupational health and safety policy, holds that safety is the shared responsibility of all workplace parties — workers, supervisors, managers, and employers — rather than the exclusive domain of a safety officer or regulator. Engineers embedded in workplace systems are part of the IRS whether they think of themselves that way or not.

Chapter 7: Intellectual Property

7.1 What Is Intellectual Property?

Intellectual property (IP) refers to intangible creations of the mind — inventions, creative works, brand identities, confidential business information — that legal systems treat as a form of property, granting their owners certain exclusive rights. For engineers, IP is a practically important domain: the products you design may be patentable, the code you write is copyrighted, the business methods your employer uses may be trade secrets, and the systems you build may depend on licensed IP from third parties.

Understanding IP is not merely a legal obligation. It is a professional competency that allows engineers to participate meaningfully in commercialisation discussions, to avoid inadvertently infringing third-party rights, and to protect the innovations they create.

7.2 Patents

A patent is a time-limited government-granted right that allows the patent holder to exclude others from making, using, or selling a patented invention. In Canada, patents are governed by the Patent Act, R.S.C. 1985, and administered by the Canadian Intellectual Property Office (CIPO). A utility patent in Canada has a term of 20 years from the date of filing.

For a patent to be granted in Canada, the invention must meet three criteria:

Not everything is patentable. Scientific discoveries and abstract mathematical theorems are not patentable (though software implementations of algorithms may be, in some jurisdictions, if they produce a tangible result). Business methods, which may be patent-eligible in the United States, occupy a more restricted space in Canadian law.

The patent system embodies a social contract: in exchange for a public disclosure of the invention that allows others to learn from it and to build on it after the patent expires, society grants the inventor a temporary monopoly. This is why patents are published — the disclosure requirement is fundamental to the bargain.

Employee inventors face particular considerations. In most employment contracts in technology-intensive industries, inventions made by an employee using company resources, in the scope of employment, are assigned to the employer. Engineers should read and understand their employment contracts before assuming they retain personal ownership of work-related inventions.

7.3 Copyright

Copyright protects original creative works — including literary works, artistic works, musical works, and, critically for engineers, software source code and database compilations — against unauthorised copying, distribution, adaptation, and public performance. In Canada, copyright is governed by the Copyright Act, R.S.C. 1985.

Unlike patents, copyright arises automatically upon the creation of an original work fixed in a tangible form — no registration is required. The term of copyright in Canada is generally the life of the author plus 70 years (as of recent amendments aligning with international norms), after which the work enters the public domain.

Copyright does not protect ideas, only the particular expression of those ideas. Two engineers can independently write code that achieves the same algorithmic result; if neither copied the other’s code, there is no copyright infringement. This idea-expression dichotomy is important: you can be inspired by a competitor’s product design, but you cannot copy their code or technical drawings.

Open-source software licenses (GPL, MIT, Apache, Creative Commons) are copyright instruments — they use copyright law to grant users rights that copyright would normally reserve. Engineers who use open-source components in commercial products must understand the terms of the applicable license; some (like the GPL) require that derivative works also be distributed under the same terms (the “copyleft” requirement), which may conflict with a company’s interest in keeping its product source code proprietary.

7.4 Trade Secrets

A trade secret is confidential business information that provides a competitive advantage precisely because it is not publicly known. Unlike patents, trade secrets involve no registration and no public disclosure — the protection lasts as long as the information remains secret and the owner takes reasonable steps to maintain its secrecy.

Trade secrets are protected in Canada primarily through contract (non-disclosure agreements, confidentiality clauses in employment contracts) and through common-law and statutory causes of action for breach of confidence and misappropriation. Ontario’s Uniform Trade Secrets Act (adopted in modified form) provides a civil remedy against misappropriation.

For engineers, trade secrets most commonly arise as: proprietary manufacturing processes, formulations or device specifications, customer lists and pricing strategies, and internally developed algorithms or software not released externally. The obligation to protect an employer’s trade secrets typically survives employment — a former employee who joins a competitor and reveals confidential formulas or customer pricing data is liable for misappropriation even if no non-disclosure agreement was signed.

7.5 Other Forms of Intellectual Property

Trademarks protect brand identifiers — words, logos, sounds, or distinguishing trade dress — that allow consumers to identify the source of goods or services. For engineers designing consumer products, trademark considerations arise in branding, product naming, and interface design.

Industrial designs (called “design patents” in the United States) protect the ornamental or aesthetic features of a functional object. The shape of a uniquely designed product housing, the ornamental pattern on a device surface, or the distinctive appearance of an interface icon may be protectable as industrial design.

Integrated circuit topographies have their own protection scheme in Canada under the Integrated Circuit Topography Act, recognising the distinct character of IC layout design as a form of creative work.

Chapter 8: Project Management

8.1 The Project Management Triangle

Project management is the discipline of planning, organising, and controlling resources to achieve defined project objectives within specified constraints. For engineers, project management skills are essential: virtually all significant engineering work occurs in a project context, with defined deliverables, budgets, and deadlines.

The classic project management triangle (or iron triangle) identifies three fundamental constraints that govern every project:

8.2 Work Breakdown and Scheduling

Before a project can be scheduled, its work must be decomposed into manageable units. A Work Breakdown Structure (WBS) is a hierarchical decomposition of the project scope into work packages — discrete units of work that can be assigned, estimated, and tracked. The WBS does not specify how tasks are related in time; it only identifies what must be done.

Scheduling assigns tasks to time and identifies dependencies among them. A Gantt chart is a horizontal bar chart in which each task is represented by a bar spanning its start and finish dates, allowing the project team to visualise the schedule and identify periods of high resource demand.

More analytically powerful is the PERT/CPM framework — Program Evaluation and Review Technique / Critical Path Method — which models the project as a network of tasks connected by dependency relationships.

To construct a PERT chart and find the critical path:

1. List all project tasks and estimate the duration of each.
2. Identify the dependencies — which tasks must be completed before each task can begin.
3. Draw the network diagram (either activity-on-arrow or activity-on-node format).
4. Compute Early Start (ES) and Early Finish (EF) for each task by working forward through the network.
5. Compute Late Start (LS) and Late Finish (LF) by working backward from the project end.
6. Calculate float: Float = LS − ES = LF − EF.
7. The critical path consists of all tasks with Float = 0.

8.3 Managing Project Risk and Changes

Real projects deviate from their plans. Equipment arrives late, technical problems take longer to solve than estimated, requirements change. Effective project management includes a proactive risk register — a living document that identifies potential risks, estimates their probability and impact, and specifies mitigation strategies. Risks should be reviewed regularly during the project lifecycle, not just at the outset.

Scope creep — the gradual, often unacknowledged expansion of project scope without corresponding adjustment to schedule or budget — is one of the most common causes of project failure. Preventing scope creep requires a formal change management process: all requests for scope changes are documented, assessed for impact on schedule and cost, and approved or rejected by appropriate stakeholders before work begins.

Chapter 9: Measurement and Measurement Error

9.1 Why Measurement Matters in Engineering

Engineering decisions — about whether a product is within specification, whether a structure is safe, whether a signal has been correctly decoded — ultimately rest on measurements. But measurements are never perfect. Every measurement is accompanied by some degree of uncertainty, and an engineer who does not understand and account for that uncertainty may reach confidently wrong conclusions.

This is not a minor technical footnote. In 1999 NASA lost the Mars Climate Orbiter — a $125 million spacecraft — because one team used metric units and another used imperial units in trajectory calculations. In medical device design, an uncalibrated glucose meter that reads 10% high could cause a diabetic patient to take too little insulin and enter hyperglycaemic crisis. Measurement literacy is a genuine engineering safety issue.

9.2 Types of Measurement Error

These two types of error are related to two important measurement quality concepts:

• Accuracy refers to how close a measurement is to the true value. A measurement system with large systematic error is inaccurate, even if it is very consistent.
• Precision refers to how closely repeated measurements cluster together. A precise instrument gives reproducible results; an imprecise one shows large scatter. A system can be highly precise (low random error) while being highly inaccurate (large systematic error) — for example, a miscalibrated micrometer that reads every measurement 0.1 mm too high.

The classic target analogy captures this: tight clusters near the bullseye are both accurate and precise; tight clusters away from the bullseye are precise but inaccurate; scattered shots centred on the bullseye are accurate (on average) but imprecise; scattered shots away from the bullseye are neither accurate nor precise.

9.3 Calculations with Uncertain Numbers

When uncertain measurements are combined mathematically, the uncertainties propagate. A simple and widely used approach is absolute and relative uncertainty propagation:

For a measured quantity x with uncertainty δx, the relative uncertainty is δx/x (often expressed as a percentage). When combining quantities:

• Addition or subtraction: The absolute uncertainties add. If z = x + y, then δz = δx + δy.
• Multiplication or division: The relative uncertainties add. If z = x · y, then δz/z = δx/x + δy/y.

These rules give an upper bound (the “worst case”) on the combined uncertainty. More sophisticated statistical methods (combining in quadrature, Monte Carlo simulation) give more realistic — often smaller — combined uncertainty estimates, but the simple rules are adequate for introductory purposes and conservative in the safe direction.

Chapter 10: Professional Development and Entrepreneurship

10.1 Professional Development as a Lifelong Obligation

The Professional Engineers Act and its counterparts across Canada impose an explicit obligation of continuing professional development (CPD). This is not a bureaucratic formality — it reflects a genuine reality. Engineering knowledge evolves rapidly: materials science, power electronics, machine learning, cybersecurity, and environmental regulations are all domains where a practitioner who stopped learning in 2010 would be dangerously out of date by 2025.

Professional development encompasses a wide range of activities: formal education (graduate courses, professional development courses), participation in technical conferences and workshops, reading current literature, learning new software tools, mentoring junior engineers, and contributing to standards development. The University of Waterloo’s Centre for Extended Learning (CEL) and the Professional Development program (often referenced as PD courses in the co-op context) are examples of structured continuing development programs.

For student engineers, the PD component of the co-op program introduces systematic professional skills development alongside technical work experience. The underlying message is that technical competence and professional competence develop together, not sequentially.

10.2 The P.Eng. Journey for New Graduates

Upon completing an accredited ECE degree, a new graduate becomes an Engineer-in-Training (EIT) or Engineer-in-Training (EIT) — the terminology varies by province — eligible to begin accumulating the required years of professional experience under the supervision of a licensed P.Eng. The experience must be progressive — increasing in responsibility over time — and must include a significant component of engineering decision-making rather than merely technical execution.

The practice of maintaining a professional development log — recording the nature, scope, and duration of engineering activities — is strongly encouraged from the outset of professional practice, because the license application will require a detailed account of experience. Engineering students who treat their co-op work terms as opportunities to gain meaningfully engineered experience, and who document that experience carefully, are setting themselves up for a smoother licensing process.

10.3 Entrepreneurship in Engineering

The transition from technical innovator to engineering entrepreneur involves a set of challenges distinct from, though related to, the challenges of professional engineering practice. An engineer who founds a startup must simultaneously be the technical expert, the customer-development lead, the fundraiser, and often the first salesperson — roles that require a very different skill set from designing circuits or writing code.

The University of Waterloo has developed an internationally recognised entrepreneurship ecosystem that ECE students can access even in their first year. Key components include:

• Velocity: Waterloo’s flagship startup incubator, based in the East Campus Hall and in the Davis Centre, providing workspace, mentorship, and seed funding to student-founded companies.
• Conrad School of Entrepreneurship and Business: Offers entrepreneurship courses, the BMath/MAcc program, and a range of certificate and professional development options.
• Waterloo Commercialization Office (WatCo): Assists students and faculty with IP management, licensing, and commercialisation of research.
• Engineering capstone projects with industry: Many fourth-year design projects have direct commercialisation potential, and some result in IP assignments or spin-out companies.

The engineering graduate who understands the basics of IP — patents, trade secrets, licensing — is better positioned to participate in commercialisation discussions. The question of who owns IP created during a Waterloo-affiliated project, for example, depends on the specific agreements in place, and understanding the relevant frameworks before a dispute arises is strongly preferable to understanding them after.

Chapter 11: Equity, Diversity, and Inclusion in Engineering

11.1 The Representation Gap

Engineering in Canada, like engineering in most countries, does not look like Canadian society. Women make up approximately 50% of the general population but, as of recent data from Engineers Canada, approximately 14% of licensed professional engineers. Indigenous peoples, racialised communities, and people with disabilities are also underrepresented relative to their share of the general population. This representation gap has persisted for decades despite sustained awareness of the problem.

The gap matters for several interconnected reasons. From an equity standpoint, a profession that systematically excludes groups of people is failing to fulfil its social license — the public interest rationale that justifies the profession’s privileged status. From an engineering quality standpoint, diverse teams consistently outperform homogeneous teams on complex design problems: they bring more varied perspectives, are more likely to consider a wider range of user needs, and are more likely to identify assumptions that a homogeneous team might treat as universal truths. And from a workforce standpoint, Canada faces growing demand for engineering talent; drawing only from a narrow demographic pool is economically inefficient.

11.2 Systemic Barriers and Structural Solutions

The representation gap is not primarily a pipeline problem — the result of too few women or underrepresented groups choosing to study engineering. Research consistently shows that women and racialised students who enter engineering programs graduate at rates comparable to or higher than their majority-group peers, but face higher attrition in their early careers. The barriers that produce the gap are structural and cultural: workplace cultures that marginalise contributions from non-majority engineers, informal networks from which minority engineers are excluded, and implicit biases in hiring and performance evaluation.

Addressing structural barriers requires structural solutions:

• Inclusive recruitment and hiring practices: Structured interviews with standardised rubrics, diverse hiring panels, blind-screening of resumes to remove name-based bias.
• Mentorship and sponsorship programs: Connecting junior engineers from underrepresented groups with senior advocates who can facilitate career advancement.
• Inclusive workplace culture: Codes of conduct, zero-tolerance policies for harassment, and active management of team dynamics to ensure that all voices are heard in technical discussions.
• Flexible work policies: Accommodating caregiving responsibilities — which disproportionately fall on women — without career penalty.

11.3 Engineers Canada’s 30 by 30 Initiative

Engineers Canada’s 30 by 30 initiative set a target of 30% women among newly licensed engineers by the year 2030. The initiative involves data collection, awareness-raising, and support for member associations’ diversity programs. While 30% is itself not parity, the initiative represents a concrete, measurable goal — a useful model for applying engineering thinking (define the objective, measure progress, iterate) to a social problem.

For ECE 190 students, the message is practical: the profession you are entering has significant equity work still to do, and you will be part of the generation that either continues the status quo or changes it. Treating colleagues with respect, speaking up when you observe exclusionary behaviour, and designing products for the full range of users — including users who differ from you in gender, age, disability status, and cultural background — are all within your sphere of influence as an emerging engineer.

11.4 Inclusive Design

Inclusive design (sometimes called universal design) is the practice of designing products and systems that are usable by the broadest possible range of people without requiring adaptation or specialised design. In practice it means: considering users at the extremes of the capability spectrum (users with limited mobility, low vision, limited English literacy, older users) during the design process rather than after the fact.

The business case for inclusive design is strong: design choices that serve users at the extremes of the capability spectrum typically improve usability for everyone. Curb cuts — the sloped ramps that allow wheelchair users to cross intersections — also benefit parents with strollers, delivery workers with hand trucks, and cyclists. Captioned video — designed for deaf and hard-of-hearing users — benefits viewers in noisy environments and those watching in a second language. For ECE practitioners, inclusive design considerations apply to: interface design (colour contrast, font sizes, alternative input methods), physical product ergonomics, and the accessibility of software applications.

Chapter 12: Technical Communication

12.1 Communication as an Engineering Competency

The stereotype of the engineer who would rather write code than write prose is not merely an unflattering caricature — it points to a genuine professional liability. An engineer who cannot communicate clearly and persuasively cannot effectively advocate for a safety concern, cannot convince a client to accept a necessary design change, and cannot collaborate effectively with colleagues from different technical backgrounds. The CEAB recognises communication skills as one of the twelve graduate attributes required for accredited engineering programs, specifically citing “the ability to communicate complex engineering concepts within the profession and with society at large.”

Engineering communication takes several forms, each with its own conventions and demands:

Technical reports document the design, analysis, or investigation of an engineering problem. A well-structured technical report begins with an executive summary that allows a busy reader to grasp the key findings without reading the full document; proceeds through a clear statement of the problem and the methods used; presents results clearly, with appropriately labelled figures and tables; and concludes with a clear statement of conclusions and recommendations. Reports that bury the key finding on page 14 fail their readers.

Technical presentations require adapting the same content for an oral audience. The pacing is different, the visual aids serve a different function (they should not be the speaker’s notes), and the interaction with the audience — fielding questions, reading non-verbal feedback — demands skills that written communication does not.

Short videos — increasingly a professional communication medium, particularly in engineering product contexts and customer-facing technical communication — require yet another set of skills: scripting, visual composition, pacing, and audio quality, all in service of clear communication.

12.2 Figures, Tables, and Technical Graphics

In engineering reports, figures and tables are not decorative — they are primary vehicles for communicating quantitative results and relationships. Each figure or table should: have a descriptive caption, have labelled axes with units, be referenced explicitly in the body text (a figure that is not discussed in the text might as well not exist), and be numbered sequentially.

Common pitfalls: plotting too many variables on a single graph until it becomes unreadable; using default software formatting with no thought for readability (pale grey gridlines, unlabelled axes, data series distinguishable only by colour on a greyscale printer); and including tables of raw data that belong in an appendix rather than the main body.

12.3 Plagiarism and Academic Integrity in Engineering

Academic integrity is a prerequisite for professional integrity. Engineers who learn to present others’ work as their own in university do not magically become honest when they enter the profession; the habits cultivated in school persist. More immediately, academic dishonesty is a serious breach of University of Waterloo policy with genuine consequences — and in engineering, where professional judgments about safety rest on trust, the character damage from a sustained pattern of academic dishonesty is professionally significant.

Plagiarism in technical contexts most often takes the form of: presenting a published analysis or design as one’s own original work, recycling one’s own previous submissions without disclosure, and — with increasing frequency — passing off AI-generated text as personal work. The ECE 190 course policies on generative AI address this last concern explicitly, recognising that the tools are real but that the professional skill being developed is the student’s own judgment and communication capacity, which is not substitutable.

Synthesis: The Engineer as Professional

The themes of ECE 190 — profession and licensing, ethics, design, sustainability, risk, intellectual property, project management, measurement, professional development, diversity, and communication — are not independent modules to be memorised and forgotten. They are facets of a single coherent picture: what it means to practise engineering professionally.

A professional engineer is a person who has the technical knowledge to solve real problems, the ethical grounding to solve them in ways that protect rather than harm the public, the communication skills to collaborate and to be accountable, the project management skills to deliver work within realistic constraints, and the intellectual honesty to acknowledge the limits of their knowledge and the uncertainties in their measurements.

The transition from engineering student to engineering professional is not completed at convocation. It begins at convocation and continues for an entire career. The licence that a P.Eng. receives — and that an engineering graduate is working toward — is a trust granted by the public, renewed daily through ethical conduct and sustained competence. That trust is the foundation on which everything else in this course rests.