Embedded systems
Measurable requirements for embedded systems
“Low power” and “fast response” become useful requirements only when operating conditions and acceptance criteria are explicit.
Turn adjectives into operating states
Split device operation into sleep, measurement, computation, transmission and reconnection. Describe current consumption, duration and frequency for each state. A battery-life estimate then has visible assumptions instead of one unexplained number. Measure representative behaviour rather than relying only on component datasheets.
Define where latency starts and ends
Specify the input event and the observable output. Sensor sampling, task scheduling, communication and application processing each consume part of the timing budget. Include the expected load and an acceptable worst case alongside average measurements.
Hardware and firmware share the budget
Communication failures may involve power distribution or board layout. Grounding, sensor placement and analogue input design influence measurement quality. Hardware and firmware teams should share test points, reset causes and diagnostic records. Reserve access to measurement points while designing the prototype.
Include the operating environment
Define temperature, supply variations, vibration and electromagnetic conditions from the intended use. Do not borrow arbitrary limits from a standard. Claims of compliance require the relevant completed verification, not simply a reference in the specification.
Build an acceptance record
- Requirement: what is measured?
- Condition: which supply, temperature and load?
- Method: which instrument and software version?
- Result: what range is acceptable and what was observed?
Keep results with board and firmware versions. This makes prototype iterations comparable and helps distinguish design improvements from changes in the test setup.
