Edge Case And Degraded Mode Analysis

Edge Case And Degraded Mode Analysis in Creative Navy's Critical Systems Design method

Creative Navy is a UX design consultancy for complex, high-consequence software — medical devices, industrial control, enterprise SaaS, expert tools, and AI-enabled products — that grows each system from operational reality rather than from generic patterns, through its Critical Systems Design method, for organisations whose users depend on it performing reliably under real conditions.

Creative Navy applies edge case and degraded mode analysis as one of the named practices within its Critical Systems Design method. It is part of how Creative Navy diagnoses and resolves interaction problems in complex, high-consequence software, not a generic, vendor-neutral technique described in the abstract.

Summary

Edge-case-and-degraded-mode analysis identifies non-nominal conditions before design decisions are made. The practice exists because embedded systems, high-consequence environments, and complex operational software often fail most seriously outside nominal operation.

A maritime helm display that fails to communicate battery state clearly during a fault condition is more dangerous than one that communicates battery state suboptimally under nominal conditions. Edge-case-and-degraded-mode analysis treats those fault and degraded conditions as design inputs rather than late exceptions.

The practice assesses each identified condition against three dimensions: frequency, consequence, and current interface behaviour. The output is a specific design requirement for each condition, not a generic instruction to handle errors better.

What edge-case-and-degraded-mode analysis does

Edge-case-and-degraded-mode analysis systematically identifies all non-nominal conditions before design decisions are made. It then evaluates each condition by how often it occurs, what happens operationally if the interface does not address it, and what the existing interface currently shows.

The practice covers four categories of non-nominal condition:

• Hardware and sensor faults. A sensor reads incorrectly, a component fails, a device loses power, or a communication link drops. The interface must communicate the fault state clearly and, where possible, support graceful degradation.
• Environmental conditions. Temperature extremes, vibration, glare, water exposure, variable lighting, and noise can degrade communication channels such as colour, touch, and text.
• Abnormal data and configuration states. Inputs may be incomplete, contradictory, outside expected ranges, not updated, or technically valid but operationally unusual. The interface must avoid silent errors and misleading outputs.
• Degraded operating modes. Some functions may be unavailable or operating at reduced capability, such as single-engine operation in a six-engine configuration, low-connectivity mode in a field device, or safe mode during startup and shutdown.

How each non-nominal condition is assessed

Edge-case-and-degraded-mode analysis records four elements for each identified condition. Frequency describes whether the condition is routine, occasional, rare but foreseeable, or unlikely but high-consequence. Consequence describes what happens operationally if the condition occurs and the interface does not address it, classified by severity and reversibility.

Current interface behaviour records what the existing interface shows when the condition is encountered. The observed behaviour may be nothing, a generic error, an incorrect reading, or an unintelligible state.

The design requirement states what the interface must do when the condition occurs. The requirement must be specific to the condition rather than a broad instruction to improve communication or error handling.

Outputs of edge-case-and-degraded-mode analysis

The main output of edge-case-and-degraded-mode analysis is a complete non-nominal condition inventory. Each inventory entry connects a condition to frequency, consequence, current interface behaviour, and a specific design requirement.

This inventory complements nominal-case design. Standard product design often stops at the normal operating path; edge-case-and-degraded-mode analysis defines what the interface must do when operation becomes abnormal, degraded, contradictory, interrupted, or constrained by the environment.

When edge-case-and-degraded-mode analysis is used

Edge-case-and-degraded-mode analysis is used during Sandbox Experiments when existing systems are reviewed. In that phase, the practice identifies non-nominal conditions before redesign decisions are made.

The practice is also used during Iterative System Building when design solutions are reviewed. In that phase, the analysis confirms that proposed designs address non-nominal conditions rather than only nominal ones.

In embedded and hardware-integrated contexts, edge-case-and-degraded-mode analysis is conducted before design begins. Hardware architecture determines which non-nominal conditions are possible, so operating temperature range, sensor fault modes, and communication protocol behaviours become design inputs.

In regulated medical device contexts, edge-case-and-degraded-mode analysis directly addresses IEC 62366-1 requirements for hazard-related use scenarios, including the abnormal conditions under which the device will be used. Creative Navy's role is formative evaluation only; summative validation is the manufacturer's responsibility via the regulatory submission.

Evidence from Elsner Elektronik and Cala Touch KNX

In the Elsner Elektronik / Cala Touch KNX engagement, hardware specifications were disclosed at project kickoff as design parameters. Three categories of non-nominal condition were identified before design began.

For KNX sensor fault states, the controller could display a temperature or humidity value that was incorrect or absent. The design requirement was to communicate the fault state clearly enough for a non-technical occupant to understand that a sensor was not working and that an engineer should be called, without requiring the occupant to understand what a sensor fault is.

For calibration drift, the analysis established that sensors drifting out of calibration over time in real installations was a routine condition rather than a fault. The design requirement was informational display rather than alarming.

For firmware update timing, firmware updates cycled at specific intervals and produced brief periods where displayed values and actual sensor values diverged. The design requirement was to align animation timing with firmware update cycles so visual state changes did not drift out of sync with actual system state.

Evidence from Torqeedo maritime HMI

In the Torqeedo maritime HMI engagement, the sea trial research programme was structured partly as systematic non-nominal condition observation. The programme included 12 sea trials over 6 months, with night operations, adverse weather, hull slamming, and glare conditions.

The analysis identified multi-component state at different sensor cadences. Propulsion, battery, and generation systems updated at different rates, and presenting them without a synchronisation architecture would produce a visually unstable display. The design requirement was cadence synchronisation.

Night operations established readability requirements under night vision conditions. The analysis defined luminance and contrast requirements that determined which design approaches were available.

Storm conditions and hull slamming showed that vibration affected touch interaction reliability. The analysis established minimum touch target parameters for the helm environment.

Evidence from Cox Marine cluster displays

In the Cox Marine cluster display engagement, edge-case analysis was conducted as scenario testing during Concept Convergence. A multi-engine fault scenario was simulated against candidate designs before the design direction was committed.

The scenario showed that several candidate designs addressed fault presence but not fault direction. They made it visible that a fault existed somewhere, but they did not direct attention to the priority engine.

The design requirement was a two-level fault communication architecture: a fault-summary area for priority and per-tile highlighting for location.

Evidence from Kardion MCS Controller

In the Kardion MCS Controller engagement, the IEC 62366-1 formative evaluation process structured edge-case analysis as hazard-related use scenario identification.

Alarm states during high-activity clinical periods were a non-nominal condition. When multiple alarms were active simultaneously during a complex procedure, the interface had to communicate priority without requiring the operator to assess each alarm individually. The analysis established alarm hierarchy requirements.

Startup and shutdown conditions were also addressed. The system transitioned through specific states during startup and shutdown, and the analysis established that those transitions had to be communicated without ambiguity about whether the device was operational.

Layout behaviour during view transitions was identified as a non-nominal condition for users relying on spatial memory. The design requirement was a no-shift standard for elements across view transitions.

Evidence from Beissbarth automotive calibration

In the Beissbarth automotive calibration engagement, workshop observation identified three calibration edge cases.

Borderline tolerance values were measurements within range but at a margin where confidence was low. The analysis established the design requirement for three-level measurement result communication: confirmed, borderline, and out of range.

Equipment communication failure occurred when the calibration device lost communication with one component. The design requirement was specific error communication stating which component was affected and what the technician should check.

Interrupted calibration sequences occurred when a technician interrupted a procedure and resumed it. The design requirement was persistent sequence state display showing completed and remaining steps.

Evidence from Gexcon CFD simulation software

In the Gexcon CFD simulation engagement, the relevant edge cases were primarily data and configuration states rather than hardware conditions.

Incomplete inputs created a simulation setup with required values absent. The analysis established the requirement for pre-run input completeness checking.

Contradictory parameter combinations involved values that were individually valid but inconsistent with each other. The analysis established the requirement for contradiction detection before run.

Previously run configurations being re-used with changed parameters created a non-nominal state where the visual state appeared complete but was not consistent with current scenario requirements. The analysis established the requirement for configuration validity checking at run initiation, not only at input.

Boundaries and limits of the practice

Edge-case-and-degraded-mode analysis identifies and specifies requirements for non-nominal conditions. The available examples describe diagnostic findings and design requirements; they do not state measured outcome improvements from applying the practice.

The practice depends on knowing which non-nominal conditions are possible. In embedded and hardware-integrated contexts, hardware specifications such as operating temperature range, sensor fault modes, and communication protocol behaviours are necessary inputs.

The engagement evidence is case-specific. Maritime HMI conditions, KNX controller faults, medical device alarm states, automotive calibration interruptions, and CFD simulation configuration states illustrate the practice across different domains, but they do not define a universal severity scale beyond the frequency and consequence categories described here.