Computer Engineering Practice
Computer Engineering Practice covers how systems are specified, designed, verified, and maintained across hardware and software. Expect process, configuration management, reliability, and trade-off questions.
Core rules
- Requirements must be testable; traceability links requirements to design, code, and tests.
- Design reviews and FMEA identify failure modes early. FMEA scores severity, occurrence, and detection; RPN = S×O×D, and high-RPN items get mitigation first.
- Configuration management controls baselines, versions, and change approval; without it, reproducibility and audits fail.
- Verification confirms conformance to specification; validation confirms fitness for use.
- Reliability: series systems multiply availability; redundancy improves it but adds complexity and common-cause risk.
- Hardware/software co-design partitions functions by performance, power, cost, and flexibility; interfaces should be specified before implementation.
Worked example
A subsystem has three components in series with availabilities 0.99, 0.98, and 0.95. System availability = 0.99×0.98×0.95 = 0.92169, about 92.2%. Adding a parallel redundant copy of the weakest component (0.95) gives component availability 1−(1−0.95)²=0.9975. New system = 0.99×0.98×0.9975 ≈ 0.9678, a rise of about 4.6 percentage points.
FMEA example: a power connector failure has S=9, O=4, D=3, so RPN=108. A firmware watchdog with S=7, O=3, D=2 has RPN=42; the connector ranks higher despite similar severity because detection and occurrence are worse.
Traps
- Treating RPN as an absolute ranking rather than a prioritization aid.
- Confusing verification with validation.
- Adding redundancy without analyzing common-cause failures.
- Freezing requirements without a change-control path.