22-Mec-B5 Product Design and Development · May 2016
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams, May 2016 — 07-Mec-B5 Product Design and Development. Three hours. Open book; no calculator is permitted. Question 1 must be completed and is worth 40 marks; four of the six remaining questions are chosen, each worth 15 marks, for 100 marks in total. Only the first five questions as they appear in the answer book are marked. The paper states that most questions require an answer in essay format or the use of tables, figures and charts, and that clarity and organisation of the answer are important.
The paper prints 40 + 6 × 15 = 130 marks and a candidate attempts 40 + 4 × 15 = 100 of them. All seven questions are answered below, because this set is a study resource rather than an examination script. The marking scheme printed on the last source page splits Question 1 as 9 / 9 / 4 / 9 / 9 and gives the part weights for every 15-mark question; the answers here are proportioned to that split. Because no calculator is permitted, every calculation is arranged so that it can be carried out on paper in one or two lines — ratios of round numbers, never a logarithm that has to be evaluated.
Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.
The product selected is the household thermostat, because it is the clearest case of a product whose mechanical and electrical content barely changed for fifty years and whose value proposition was then completely rewritten by sensing and connectivity.
The baseline thermostat is a wall-mounted controller with a bimetallic or electronic sensor and a setpoint dial. The customer’s entire interaction is: stand in front of it, and command a temperature. Everything else — whether anyone is home, what the house is doing, what it costs — is the customer’s problem, held in their head. Interconnection and integrated sensing change that interaction along four axes.
From command to intent. With occupancy sensing, geofencing from the household’s phones, and a learning schedule, the customer stops issuing setpoints and starts expressing goals — “comfortable when we are home, cheap when we are not” — and the device infers the schedule. The interaction shifts from an operation performed many times a day to a preference stated once, and the number of deliberate interactions per year collapses. This is the largest change and it is a change in the kind of interaction, not its convenience.
From co-located to remote and multi-modal. The control surface leaves the wall. A phone application, a web page or a voice assistant becomes the primary interface, so the customer can raise the heat from the car on the way home from the cottage, and the wall unit degrades to a display and a manual override. That decoupling also means the interface can be updated after the sale, and that different household members can hold different, negotiated permissions — which introduces a genuinely new interaction, the multi-user conflict, that the dial never had.
From silent to informative. The device now tells the customer things: monthly energy reports, comparisons with similar homes, the cost consequence of a setpoint change, an alert that the furnace filter is loaded or that the house is cooling faster than it should, a freeze warning while they are away. The relationship becomes two-way, and the customer’s mental model of their own house improves — which is where most of the reported energy savings actually come from.
From isolated to networked with third parties. The thermostat now interacts with parties the customer never used to deal with through it: the utility, through demand-response programmes that pre-cool the house before a peak in exchange for a credit; the HVAC contractor, who receives a fault code and arrives with the right part; the insurer, through freeze and water alerts; and other devices in the home. The customer’s interaction becomes partly an interaction with a service, with all that implies for expectations, subscriptions and trust.
“Opening the design space” means that variables which were previously fixed become free, and new objectives become reachable. For the thermostat this happens in five ways.
Control laws that were previously impossible. A single wall sensor measuring the temperature of one hallway forced a simple hysteresis controller. With cheap remote room sensors, an outdoor temperature feed and a weather forecast over the network, the controller can do model-predictive control — learn the house’s thermal time constant and solar gain, and start the heat at the time that just meets the comfort target — and it can control on a weighted average of occupied rooms rather than on the hallway. The physics is not new; the sensing that makes it identifiable is.
Function migrates from hardware to software, and can be delivered after the sale. Once there is a processor and a link, features are firmware. That decouples the product roadmap from the tooling cycle, allows a capability to be added to units already on walls, and permits A/B evaluation of a control strategy across a fleet. It also changes what the product is: the design space now includes the phone application and the cloud service, which are part of the delivered product and must be designed, validated and maintained as such.
The architecture can be repartitioned. Sensing can move off the wall entirely into battery-powered room pucks, the user interface can move to a phone, and the computation can move to a server. Each of these is an architectural degree of freedom the sealed wall unit did not have, and each brings its own trade — battery life, latency, dependency.
Field data closes a loop back into design. A connected fleet reports how the product is actually used, which failures occur and under what conditions, and how effective a change was. That converts the next generation’s requirements from opinion into measurement, supports fault detection and diagnosis as a feature, and permits genuine reliability growth from field data rather than from laboratory extrapolation alone.
New value propositions and business models become available. Aggregated across thousands of homes, controllable load is a grid asset, so the manufacturer can be paid by a utility for demand-response capacity — revenue that has nothing to do with selling a thermostat. Subscription services, contractor-facing diagnostics and insurance partnerships all become possible. The design space expands from “what should this box do” to “what should this system do, and who pays for it”.
1. Security and privacy. Connecting a product to the internet gives it an attack surface it never had, and a thermostat is a particularly sensitive case: its occupancy record is a precise log of when a house is empty, which is valuable to a burglar and is personal information under PIPEDA and the provincial privacy statutes. The engineering burden is substantial and is often underestimated by an organisation coming from mechanical products — secure boot and signed firmware, no default or shared credentials, encrypted transport, key management across a fleet of hundreds of thousands of units, penetration testing, a vulnerability-disclosure process, and a committed programme of security updates that must run for the ten- to fifteen-year life of the hardware, long past the warranty and long past the point where the product generates revenue. A connected product with no update path is a liability, because a vulnerability found in year four cannot be closed. The privacy side adds its own requirements: data minimisation, meaningful consent, a defined retention period, disclosure of what is shared with utilities and partners, and an answer to what happens to the data when the house is sold.
2. Lifecycle dependency, obsolescence and the organisational change it forces. A connected product is no longer a product; it is a system with a hardware element the manufacturer sold once and a cloud element the manufacturer must keep running. That creates a dependency the customer did not agree to: if the service is discontinued, the company is acquired, or the account server fails, a working thermostat can become an inert plastic disc — an outcome that has happened repeatedly in this industry and which regulators are increasingly unwilling to accept. It also imports the churn of the connectivity ecosystem, where protocols and standards turn over far faster than an appliance’s service life. The direct engineering response is a graceful degradation requirement, and for a heating control it is close to a safety requirement: the device must maintain a sensible schedule and keep the house above freezing with no network, no server and no phone, and every connected feature must be an enhancement over a functioning local product rather than a dependency of it. Behind that sits an organisational challenge that is often the real obstacle — a company whose competence is mechanical and electrical must acquire embedded software, cloud operations, security and data-protection capability, and must move from a design freeze followed by silence to a continuous-release model with monitoring and on-call support, all while satisfying certification bodies (CSA and UL for the appliance, ISED for the radio) whose approvals were built around products that do not change after they ship.
