Systems Engineering, Architecture and Interfaces

Think in systems, not collections of components

A medical device is rarely just its enclosure, electronics or software. The system may include hardware, software, data, users, accessories, consumables, networks, cloud services, operating procedures, training, production processes and service activities. Safety and performance often emerge from their interactions.

Establish the boundary and operating context

The system boundary determines which elements and interactions the manufacturer designs, controls, verifies and supports. A useful context description should show what is inside the product, what it depends on and who or what interacts with it.

• Intended patients, users, administrators, service personnel and other actors.
• Clinical workflow, use environments, transport, storage, cleaning and maintenance contexts.
• Hardware, software, accessories, consumables, packaging, labelling and training.
• Mobile applications, cloud services, hospital systems, networks and third-party platforms.
• Power, data, mechanical, fluidic, environmental and human interfaces.
• Product variants, compatible configurations and excluded combinations.
• Production, calibration, installation, service, update and disposal activities.
• External assumptions, responsibilities and conditions required for safe operation.

Context diagrams are valuable because they make external interactions visible, but the accompanying text must define each actor, system, flow and assumption. A line on a diagram is not yet an interface specification.

See MTL-102 — Intended Purpose, Users and Use Environments for the product definition that constrains the system context.

Architecture makes important decisions visible

Architecture describes the fundamental organisation of the system: its elements, responsibilities, relationships, governing principles and rationale. It should help a competent reviewer understand how the system is expected to meet its requirements and control risk.

Architecture is not a single block diagram. Different questions need different views: context, functional flow, physical decomposition, data flow, deployment, state behaviour, safety controls, security zones, power, communications and production or service configuration.

Allocate, then confirm

Allocate requirements, functions and risk controls to system elements with rationale. Check that the set of allocated requirements is complete, compatible and feasible. Allocation also identifies who must produce the design output and evidence—and where integration will be needed to demonstrate complete-system behaviour.

Treat every interface as a controlled agreement

Many system failures occur at boundaries between teams, components or organisations. An interface-control specification should define more than connector pins or an API name.

For every interface, identify an owner on both sides, the authoritative specification, version compatibility, normal and abnormal behaviour, acceptance criteria and verification responsibility. Interface assumptions should be testable and controlled—not left in meeting notes.

Define states, modes and behaviour

Static architecture views do not show what happens over time. State and sequence models expose transitions, permissions, timing, concurrency, interruptions and recovery behaviour that prose requirements often miss.

• Power-off, start-up, self-test, idle, ready, active, paused, completed and shutdown states.
• Normal, degraded, fault, safe, maintenance, service, calibration, update and recovery modes.
• Permitted triggers, guards, timeouts and actions for every important transition.
• Behaviour following power interruption, communication loss, sensor failure or invalid data.
• Which functions remain available, inhibited or latched after a detected fault.
• How users are informed and what action is expected or prevented.
• How concurrent activities interact and which function has priority.
• What information must persist across restart, update, servicing or component replacement.

A “safe state” is context dependent. Stopping immediately may be unsafe during fluid delivery, active therapy, sample handling or a controlled mechanical movement. Define the safe response from the hazardous situation and clinical context, not from an assumed engineering convention.

Use architecture to control risk

Risk management and systems engineering should develop together. Hazard analysis reveals safety-relevant functions, interfaces and failure responses; architecture determines where and how controls can be implemented.

Systematic failures may cross several elements: a shared clock, power source, data definition, software library, calibration value, update mechanism or misunderstood workflow. Architecture reviews should therefore examine common cause, independence, external dependencies and assumptions—not only single-component failure modes.

See MTL-105 — Medical-device Risk Management for the complete risk-management process.

Systems engineering across the lifecycle

Systems engineering begins with the problem and continues as the product, evidence and external environment change.

Integration, verification and traceability

Integration should follow an explicit strategy that builds confidence progressively. Verify interfaces and subsystem behaviour before relying on complete-system testing to diagnose basic incompatibilities.

• Define integration order, prerequisites, configurations, environments and responsibilities.
• Confirm interface compatibility before combining dependent system elements.
• Test normal, boundary, timing, degraded, fault, recovery and foreseeable misuse conditions.
• Verify risk controls at the level where implementation and effectiveness can be observed.
• Retain versions of hardware, software, data, accessories, fixtures and external services used.
• Investigate unexpected behaviour and update requirements, architecture, risk or evidence where needed.
• Maintain traceability from needs and hazards through requirements, allocation, outputs and verification.
• Use system validation to confirm the integrated product meets user needs and intended use.

Traceability is a reasoning network, not merely a matrix. It should allow a reviewer to move in both directions: from a user need or hazard to the implemented solution and evidence, and from a design element or test back to the reason it exists.

See MTL-104 — Design Controls and Technical Documentation for organising the connected evidence chain.

Common misconceptions