Requirements for Embedded and Real-Time Systems

Key ideas#

What is different about this kind of project#

• Changing hardware after design and manufacture costs far more than changing software, so architecture trade-offs are settled early.
• System requirements are allocated to software, hardware and people, which multiplies the number of requirements, especially for interfaces.
• Timing is a requirement in its own right.
• Quality attributes include physical properties.

Wiegers and Beatty distinguish hard real-time systems, where a missed deadline is catastrophic (air traffic control failing to detect an obstacle in time), from soft real-time systems, where it is not (a cash machine simply retries).

Requirements and architecture together#

A system requirements specification (SyRS, as described in an ISO/IEC/IEEE standard) states what the whole system must do, whether software, hardware or a person provides it. It can stand alone or include the software requirements specification. The architecture (components, their visible properties and connections) is developed iteratively from the top down, usually led by a systems engineer or architect with broad technical knowledge. Poor allocation leads to software doing what hardware would do more cheaply (or the reverse), people doing what automation would do more cheaply, poor performance, and components that are hard to upgrade. Software’s flexibility should not become an excuse for skimping on hardware design.

Models that help#

• Context diagram: the system and the external entities it deals with, such as users, sensors and other systems.
• State-transition diagram: the states and the events that move the system between them.
• Event-response table: for each event and current state, the required response. The same event can call for different responses in different states.
• Architecture diagram: subsystems and the data and control flows between them. Drawing it early reveals missing functional and interface requirements.
• Periodic functions: work repeated while the system is in a state, such as reading a sensor every second, not only on transitions.

The authors describe drawing a state diagram from a specification that existed only as a text table and finding two missing requirements: different views of the same requirements expose different defects.

Interface specifications#

For complex systems, interfaces often get a separate document. A typical outline covers an introduction, interface diagrams, data interfaces (types, file formats, protocols), software interfaces (calls, synchronization, protocols), hardware interfaces (connections, data and control flows) and user interfaces. Requirements analysis focuses on external interfaces; internal ones are a design matter.

Timing requirements#

There are three dimensions: execution time (from the start to the end of a task), latency (from an event to the response) and predictability (how repeatable the timing is, as with a steady audio sampling rate). For each task, elicit: - period and deadline, each with its tolerance; - typical and worst-case execution time; - consequences of a missed deadline; - minimum, average and maximum data arrival times in each state; - timeouts and what happens when they expire; - required task order, and which tasks may interrupt which; - state-dependent behavior, such as an elevator in normal mode versus fire mode.

Citing Koopman, the authors stress that real-time means fast enough at the lowest total cost, not as fast as possible. Unnecessarily tight timing requirements drive up hardware cost.

Quality attributes, including physical ones#

Performance, efficiency, reliability, robustness, safety, security and usability all matter. So do physical attributes that software-only systems lack: size, shape, weight, materials, flammability, connectors, durability, noise and strength. There may also be non-technical constraints, such as political or environmental reasons to avoid certain materials. Prioritize and resolve trade-offs before hardware design starts; afterwards, changes are expensive or impossible.