# Engineering Design Challenge: Bridge Lab

An offline Grade 10 engineering studio focused on iterative design under constraints.

## Open the app

Open **index.html** in a current browser. Keep `index.html`, `styles.css`, `config.js`, `model.js`, and `app.js` in the same folder. On a Chromebook, extract the ZIP in Files, then open `index.html` with Chrome.

No backend, installation, account, API key, external fonts, libraries, or internet connection is needed. The optional local preview used during development is not required. Distribute the entire folder or ZIP, not just the HTML file.

The app saves settings, designs, test history, and reflections in this browser's local storage when available. File-URL storage policies vary by browser; a visible message warns if saving is unavailable. Use **Export notebook** to save a readable JSON record for submission or archiving. Exports contain the full designs, test conditions, predictions, vulnerability notes, results, and reflections; there is no import feature. Nothing is uploaded. Avoid sharing the same browser profile between student teams without clearing the app's local storage first. Moving the folder may change where the browser stores its notebook.

## 1. Learning objectives

Students will:

- Define a design using geometry, material, member thickness, section count, reinforcement, and deck choice.
- Make a prediction before testing, including an optional proposed weak point.
- Distinguish carrying a load from meeting a required safety margin.
- Use test evidence to explain failure, identify a limiting component, and revise a design.
- Compare cost, mass, material usage, safety, and environmental impact without assuming that the strongest design is the best.
- Respond to a changed constraint and defend tradeoffs using evidence.

The learning goal is engineering reasoning, not finding a hidden single answer. The estimates are visible deliberately: students can use them as evidence for their predictions. The test is deterministic, not an independent real-world validation of those estimates.

## 2. Suggested 40-minute lesson

| Time | Activity |
| --- | --- |
| 0–5 min | Read the brief. Identify the fixed constraints and the variables students can change. Ask why merely carrying the load might not be enough. |
| 5–10 min | Teams define their first design, predict its behavior, identify a possible weak point, and run a baseline test. |
| 10–18 min | Read **What happened? / Why? / What could you change?** Change one variable at a time, predict, and retest. Aim for at least three attempts. |
| 18–25 min | Compare two attempts in the notebook. Assign minimum cost, lightweight, or sustainability. Ask teams to preserve safety while improving the chosen objective. |
| 25–32 min | Switch to Surprise event, test a qualifying design, and reveal the change. Students must alter a design variable and retest. Discuss why a previously acceptable design may need revision. |
| 32–38 min | Complete the five required reflections with actual measurements. At least two different designs and a test of the current design under the current conditions are required to finish. |
| 38–40 min | Share defensible tradeoffs and export the notebook. Assess the reasoning and evidence, not just whether the final bridge passes. |

Prompts: “What did this change buy you?” “Which requirement is limiting you now?” “Why did the cheapest member not create the cheapest safe bridge?” “What would you test in a physical prototype?”

## 3. Simplified engineering assumptions

**This model must not be used for real structural engineering.** All material strengths, prices, deck limits, and impact indices are deliberately selected classroom parameters, not engineering reference data or current market prices.

The bridge is represented as an equivalent frame and deck spanning between two supports. Frame self-weight and deck self-weight reduce its traffic capacity. Frame resistance and deck capacity form two independent limits. The animation's truck symbolizes the total traffic load, not an individual truck of that weight.

### Design ranges

- Geometry: Warren, Pratt, or Howe, with fixed educational efficiency and material-use multipliers.
- Sections: 4–12. Benefits to resistance diminish; material and joint costs continue to increase.
- Thickness: 0.60–2.20 in increments of 0.05, a relative member-size index, **not centimeters**.
- Reinforcement: 0–3. More braces increase resistance, volume, cost, mass, and impact.
- Deck: timber, composite, or concrete, each with its own traffic-capacity ceiling.
- Truss height: 4–9 m in Advanced, fixed at 6 m otherwise.

### Equations implemented in model.js

Let `L` be span in meters, `n` sections, `t` thickness index, `r` reinforcement level, `h` truss height, `g` geometry, and `m` material. Default constants below can be edited in `config.js`.

```text
sectionFactor = 0.65 + 0.4 × (1 − exp(−(n − 3) / 3))
V = 12 × (L/40) × g.usage × (0.78 + 0.045n) × t
    × (1 + 0.13r) × (0.85 + 0.15h/6)                    [model m³]
mass = V × m.density + L × deck.mass                    [tonnes]
selfWeight = mass × 9.81                                [kN]
resistance = 6200 × m.strength × t^1.6 × g.efficiency
    × sectionFactor × sqrt(h/6) × (1 + 0.14r)
    × (40/L)^0.65                                      [kN]
frameTrafficCapacity = max(0, resistance − selfWeight)
deckTrafficCapacity = deck.capacity × (40/L)^0.35
trafficCapacity = min(frameTrafficCapacity, deckTrafficCapacity)
safetyFactor = trafficCapacity / requiredTrafficLoad
cost = 240000 × L/40 + V × m.cost + L × deck.cost + n × 22000
impact = V × m.impact + L × deck.impact
```

“Material usage” measures frame material only; mass, cost, and impact include the deck. Environmental points are **not kilograms of CO₂** or lifecycle-analysis results. Foundation/joint terms represent classroom fixed costs rather than a detailed bill of materials.

The distinction between geometries is heuristic. This app does not solve node equilibrium, individual member forces, connections, buckling, fatigue, wind, earthquakes, soil behavior, bending moments, or dynamic vehicle loads. Deflection is visually exaggerated. Member colors scale with approximate utilization and position. The central failure marker identifies the model's limiting frame or deck schematically; it is not a predicted physical fracture location. Reinforcement drawings show representative braces rather than an exact quantity takeoff.

The traffic load ramps up over the first 65% of a crossing and remains at full load for the remainder. If load exceeds capacity, the test stops and marks the weak system. Otherwise it completes and reports the reserve above required traffic load. Reduced-motion settings shorten the animation.

Prediction feedback uses explicit classroom categories:

| Prediction | Model outcome |
| --- | --- |
| Fail immediately | Capacity is less than 75% of required traffic load. “Immediately” means early in the load ramp, not time zero. |
| Bend significantly | Capacity is 75% to less than 100% of the traffic load; the bridge bends and then fails. |
| Barely pass | Capacity carries the traffic load, but safety factor is below the required minimum. This still fails the project safety constraint. |
| Comfortably pass | Safety factor meets the required minimum. Budget and environmental constraints are checked separately. |

History **Pass/Fail** means meeting all constraints for that challenge, not only avoiding structural failure. Every challenge requires safety and budget compliance; Sustainability additionally requires impact at or below the configured limit.

### Multidimensional scores

All scores are clamped to 0–100, reported separately, and never summed:

```text
Safety = 100 × safetyFactor / minimumSafetyFactor
Cost efficiency = 100 × (1 − cost / (1.4 × budget))
Material efficiency = 100 × (1 − V / (5 × baseVolume × L/40))
Environmental impact score = 100 × (1 − impact / (1.5 × impactLimit))
```

A higher environmental score means a lower impact. These are reference-normalized classroom indicators, not grades or universal engineering efficiencies. Safety earns no extra score above the required margin, which discourages “strongest at any cost.” Minimum-cost, lightweight, and sustainability modes identify a student's best qualifying tested attempt for their objective; they never reveal the global optimum. The impact limit is enforced only in Sustainability.

Surprise events are chosen deterministically from the number of passing surprise-mode tests: budget −15%, traffic load +20%, structural material prices +25%, or impact limit −25%. The environmental event activates Sustainability if necessary. A reveal begins a new constraint round and requires at least one design variable to change. Only one event is revealed per teacher-settings round. Apply teacher settings to begin another round. Old results keep their original conditions.

## 4. Exactly how teachers can customize the challenge

### In the application

1. Click **Teacher settings** in the header, or expand the panel at the bottom.
2. Choose a difficulty preset first. It fills budget, load, safety factor, and mathematics visibility; you may then override those fields.
3. Edit the title and scenario. Use `{span}` anywhere in the scenario to display the configured span automatically. Literal distances in a custom scenario must be updated manually.
4. Set span (15–80 m), budget ($100,000–$10,000,000), traffic load (500–20,000 kN), minimum safety factor (1–3), and environmental limit (20–2,000 points).
5. Check the permitted challenge modes. Keep at least one enabled.
6. Check available materials. Keep at least one enabled. Edit each material's price, density, relative strength, and impact index. Field labels state the units; disabled materials also retain editable properties for later use.
7. Choose whether to allow **Show the Math**.
8. Click **Apply teacher settings**. The current design is normalized to available choices, its old prediction is cleared, and a new constraint round begins. Tests already in the notebook retain their previous conditions.

Presets:

| Preset | Budget | Required load | Minimum SF | Experience |
| --- | ---: | ---: | ---: | --- |
| Introductory | $2,400,000 | 3,000 kN | 1.25 | Conceptual prompts, mathematics hidden by default, fixed height |
| Standard | $2,000,000 | 4,000 kN | 1.50 | Calculations and tradeoffs available, fixed height |
| Advanced | $1,600,000 | 4,500 kN | 1.60 | Tighter constraints, mathematics available, adjustable truss height |

**Fill default settings** fills the form; **Apply teacher settings** commits those defaults. Neither deletes the notebook. Teacher settings are an instructional panel, not a password-protected access control.

### In the files

Open **config.js** in a text editor and edit `window.BRIDGE_CONFIG`. The top section contains the brief, constraints, difficulty, math visibility, active mode IDs, and material properties. The `model` section contains geometry/deck parameters and the base resistance, volume, gravity, foundation cost, joint cost, and reinforcement coefficients. Retain valid JavaScript syntax, positive finite values, and at least one enabled material and mode. UI numeric limits protect classroom edits; arbitrary malformed source edits cannot be validated before JavaScript loads.

For fresh defaults to take effect in a browser with an existing notebook, export its work first, then clear the `bridge-lab-v1` local-storage entry using browser developer tools and reload. To change existing work without clearing it, use Teacher Settings. School-managed browser policies may disable file storage; export remains available.

Custom constraints may deliberately make the problem impossible. Try the settings before class. If no team finds a feasible design, consider whether revising the brief should itself be part of the engineering discussion. Do not treat the default solution counts as a guarantee for arbitrary teacher choices.

## 5. Adapting the architecture to other engineering problems

The app separates three responsibilities:

- **config.js:** teacher-editable brief, constraints, material data, and model coefficients.
- **model.js:** pure `evaluate(design, config)` function returning measurements, feasibility, limiting system, and scores.
- **app.js + index.html + styles.css:** controls, visualization, prediction gate, test narrative, history, comparison, and reflection.

To adapt it, replace the model and diagram while preserving the predict–test–explain–revise cycle and immutable attempt snapshots. Examples:

- **Wind turbine:** blade length, blade count, and tower height; trade energy against cost, noise, material use, and gust failure.
- **Water filter:** filter layers, particle size, and flow rate; trade cleaning performance against throughput and cost.
- **Insulated shelter:** materials, wall thickness, windows, and ventilation; trade temperature retention against cost, light, and embodied impact.
- **Bottle rocket:** water fill, pressure, fin geometry, and mass; trade altitude, stability, resource use, and safety constraints.

Use a domain-appropriate simplified model with stated limitations. Preserve the difference between carrying out a test and interpreting evidence. Store a full configuration snapshot with every attempt so changing assumptions does not rewrite earlier results.

## Verification

The delivered app was tested directly from a `file://` URL in Chrome without external requests. Browser checks covered every design control, all four prediction outcomes, all five modes, all four surprise events, all three presets, teacher property edits, rejected empty mode/material selections, comparison, design reload, reflection completion gates, JSON export, persistence, blocked-storage fallback, and layouts from 390 to 1440 CSS pixels. The narrower 720-pixel layout also exercised the reflow expected at 200% desktop zoom.

Model checks enumerated 32,076 standard designs: 8,079 met the default safety and budget requirements, including designs in each of the three materials. The cheapest feasible design differed from the lightest/lowest-impact design. Checks verified finite nonnegative outputs, increasing cost and mass with thickness, nondecreasing traffic capacity with thickness across that grid, and 128 extreme parameter combinations. These checks validate software behavior and classroom tradeoffs, not structural accuracy. No finite test suite can cover arbitrary edits to source configuration.