Engineering System Design
For any engineering task, frame it through this sequence:
- System boundaries — what subsystems exist, how do they interact (mechanical, electrical, thermal, software, economic)?
- Constraints — standards (GOST, ISO, IEC), budget, timeline, materials availability
- Model — parametric CAD model or calculation script capturing key variables
- Validate — prototype, simulate, or analyze; identify failure modes early
- Document — specs, reports, risk register, BOM with cost estimates
Example prompt pattern: "Design a [component/system] that satisfies [functional requirement] under [constraints], considering interactions with [adjacent subsystems]."
Progress checklist for a typical engineering task:
- Define system scope and identify all interacting subsystems
- Gather applicable standards/norms (safety, quality, environmental)
- Build or update parametric model (CAD/calculation)
- Run engineering analysis (stress, thermal, economic, etc.)
- Select materials/components with tradeoff justification
- Identify top technical risks and mitigation plan
- Build/test prototype or simulation to validate hypothesis
- Estimate cost and payback/ROI
- Write technical documentation (spec, drawing notes, report)
- Review with cross-functional stakeholders (align interfaces, requirements)
Step details
1. Systems thinking first. Before diving into a component, map how it affects neighboring subsystems. Ask: "If I change X, what breaks downstream?" Use a simple interaction matrix (subsystem rows/cols, mark coupling strength) for anything non-trivial.
2. CAD & parametric modeling. Favor parameter-driven models over static geometry — expose key dimensions/properties as variables so design iterations don't require rebuilding from scratch. Run engineering analysis (FEA, thermal, kinematic) on the model before committing to manufacture.
3. Project/resource planning. Break work into milestones with dependencies. Flag long-lead items (procurement, certification) early — they're often the critical path, not the engineering itself.
4. Data/automation. Any repeated calculation (load cases, tolerance stacks, BOM costing) should become a script/spreadsheet, not manual rework. Vectorize where possible; keep units explicit.
5. Standards compliance. Identify applicable GOST/ISO/IEC/environmental codes at project start, not at review. Build a compliance checklist and map each requirement to a design feature or test.
6. Economic evaluation. For every major design choice, estimate cost delta and payback. Don't over-engineer past the point of diminishing economic return.
7. Material selection. Choose based on explicit tradeoff: mechanical/thermal properties vs. cost vs. availability vs. manufacturability. State the rejected alternatives and why.
8. Risk management. Maintain a risk register: failure mode → likelihood → impact → mitigation → owner. Update at each major design review.
9. Prototyping. Build the cheapest artifact (physical or digital) that tests the riskiest assumption first — don't prototype the easy parts.
10. Troubleshooting. When diagnosing failures: isolate variables, reproduce reliably, check interfaces between subsystems first (most failures happen at boundaries, not within components).
11. Documentation & communication. Write specs assuming the reader is a competent engineer from a different discipline — define domain-specific terms, state units, state tolerances explicitly. Summarize decisions and rationale, not just final values.
Example 1: Input: "Нужно спроектировать кронштейн крепления сенсора на дроне, вес минимален, вибронагрузка известна." Output: Define load case (vibration spectrum + static weight) → parametric CAD model of bracket with wall-thickness as variable → run modal/FEA to avoid resonance with rotor frequency → material tradeoff (Al 7075 vs. PETG-CF: weight, cost, fatigue life) → prototype via 3D print for fit-check → finalize drawing with tolerances per ISO 2768 → document mass budget impact on flight time.
Example 2: Input: "Производственная линия даёт рост брака на 8% за последний месяц, причина неясна." Output: Troubleshooting flow — pull process data (if none, set up logging first), check subsystem interfaces (handoffs between stations) before individual machines, correlate defect timestamps with maintenance/material-batch logs, isolate variable via controlled test run, identify root cause, document corrective action + update risk register to prevent recurrence.
Example 3: Input: "Сравнить два варианта материала корпуса: сталь vs. композит." Output: Build decision table — mechanical properties (strength/weight), cost per unit at target volume, manufacturability (tooling, lead time), environmental impact (recyclability, production footprint), compliance with relevant standard. Recommend based on weighted criteria matching project priorities (e.g., weight-critical aerospace vs. cost-critical consumer product), with explicit payback/ROI calculation.
- Always express designs parametrically — hardcoded dimensions create rework
- Quantify risk (probability × impact), don't just list concerns qualitatively
- Check standards compliance at design start, not at final review
- Validate the riskiest assumption first via the cheapest possible test
- When writing specs, state units, tolerances, and rationale explicitly
- Treat economic feasibility as a design constraint, equal to physics constraints
- In cross-functional settings, confirm interface requirements in writing before subsystems diverge
- Optimizing one subsystem in isolation, causing unseen conflicts elsewhere (classic systems-thinking failure)
- Skipping parametric modeling for "quick" one-off designs that later need revision
- Treating standards/certification as a final checkbox rather than an early constraint
- Prototyping the easy, low-risk parts of a design while deferring the actual unknowns
- Under-documenting rationale, leaving future engineers to re-derive "why" from "what"
- Ignoring long-lead procurement/certification items in project timelines
- Choosing materials on a single criterion (e.g., strength) while ignoring cost/manufacturability/environmental tradeoffs