Embedded Software Engineering — Ch.09: Safety Critical Embedded Software [EN]

STATERA Library · Series 08 · Volume 02 · Chapter 09 · EN
Source: https://github.com/Statera-Library/08_Vol_02_Embedded_Software_Engineering/blob/main/02_09_Safety_Critical_Embedded_Software/02_09_Safety_Critical_Embedded_Software_EN.md

Volume 02 Embedded Software Engineering

09. Safety-Critical Embedded Software

09.01 Safety-Critical SW Standards: IEC 61508, ISO 26262, EN 50128

Safety-critical software is software whose failure can contribute to unacceptable harm to people, equipment, infrastructure, or the environment. In embedded robotics, this category includes functions such as emergency stopping, actuator supervision, braking, steering, power isolation, collision prevention, and fault containment. The attached structure places these concerns within the Safety Critical Embedded Software chapter, followed by integrity-level determination, V-model development, defensive programming, runtime monitoring, safety analysis, redundancy, static analysis, coverage, and safe-state transition.

IEC 61508 provides a general framework for functional safety of electrical, electronic, and programmable electronic safety-related systems. Rather than prescribing one particular machine architecture, it establishes lifecycle-oriented principles for identifying hazards, evaluating risk, assigning safety integrity requirements, implementing safety functions, and demonstrating that residual risk has been sufficiently reduced. Its generic nature makes it an important conceptual foundation for safety-critical embedded software used in industrial automation, machinery, robotics, and related control systems.

A central idea of IEC 61508 is that safety cannot be established merely by testing the completed executable. Safety must be engineered throughout the lifecycle, beginning with hazard and risk analysis and continuing through safety requirements, architecture, detailed implementation, verification, validation, operation, modification, and eventual decommissioning. Software development therefore requires traceability between hazards, safety requirements, design elements, source code, verification activities, and evidence showing that the implemented safety mechanisms behave as intended.

IEC 61508 expresses required risk reduction through Safety Integrity Levels, commonly identified as SIL 1 through SIL 4, with progressively stronger integrity expectations. The SIL concept influences the rigor of development methods, verification independence, architectural constraints, diagnostic measures, configuration management, and documentation. A higher SIL should not simply be interpreted as "better software"; it represents a safety function whose required integrity demands stronger assurance that dangerous systematic and random failures are adequately controlled.

ISO 26262 specializes functional-safety engineering for electrical and electronic systems in road vehicles. It adapts lifecycle concepts to automotive development and introduces Automotive Safety Integrity Levels, ranging from ASIL A through ASIL D, alongside quality-management cases that do not require an ASIL assignment. Hazard analysis considers factors such as severity, exposure, and controllability, allowing safety goals to be derived from hazardous vehicle situations and subsequently refined into functional and technical safety requirements.

For embedded software, ISO 26262 emphasizes disciplined requirements engineering, architectural decomposition, interface definition, implementation rules, verification, integration testing, and safety validation. Software components involved in braking, steering, propulsion, vehicle motion control, or automated-driving functions may therefore require considerably stronger engineering evidence than ordinary application software. Freedom from interference is especially important when functions with different criticality levels share processors, memory, communication resources, operating systems, or execution environments.

EN 50128 historically addressed software for railway control and protection applications, defining processes and techniques intended to achieve dependable software in safety-related railway systems. Railway software commonly operates for long service periods under demanding availability and assurance requirements, so disciplined specification, architectural design, verification, validation, configuration management, and change control are essential. In modern projects, engineers must also check the currently applicable railway software standards and contractual requirements rather than assuming that a historical standard designation alone defines the certification baseline.

Although IEC 61508, ISO 26262, and railway standards use different terminology and domain-specific mechanisms, their engineering philosophy has substantial overlap. Each treats safety as a system property derived from hazards rather than as an attribute that can simply be assigned to source code. Requirements must be traceable, architecture must address failures explicitly, implementation must follow controlled practices, and verification must produce objective evidence. Certification-oriented development therefore connects system safety analysis and software engineering instead of treating them as independent activities.

This distinction is especially important in robotics because a robot combines sensing, computation, communication, actuation, stored energy, and physical motion. A perception or planning function may operate on a powerful Linux or GPU computer, while an independent MCU or safety controller supervises velocity, actuator enable signals, protective devices, watchdogs, and emergency-stop circuits. The appropriate safety standard depends on the application domain, but the architectural principle remains similar: hazardous behavior must not depend entirely on unrestricted application software remaining correct.

Safety requirements should therefore describe measurable behavior under both normal and abnormal conditions. Instead of stating that software must "operate safely," requirements should specify detection thresholds, response times, permitted operating states, degraded modes, fault reactions, diagnostic coverage, communication timeouts, and the conditions that force transition to a defined safe state. These requirements then become inputs to architecture, implementation, unit verification, integration testing, fault injection, hardware-in-the-loop testing, and system-level safety validation.

Software architecture provides one of the strongest mechanisms for satisfying such requirements. Safety-related functions can be isolated from non-safety functions, communication interfaces can be bounded and monitored, and critical state transitions can be implemented using deterministic state machines. Watchdogs, memory protection, redundant measurements, plausibility checks, sequence counters, CRC mechanisms, timeout supervision, range checks, and independent shutdown paths can prevent a single software defect or communication failure from silently propagating into hazardous physical behavior.

Implementation discipline complements architectural protection. Safety-critical embedded code generally favors explicit control flow, bounded execution, deterministic resource usage, controlled dynamic memory, well-defined integer behavior, defensive interface validation, and restricted language constructs. Coding standards and static analysis help detect defects before execution, while compiler configuration, build reproducibility, version control, change review, and configuration management ensure that the binary being validated corresponds to the source and configuration that were actually reviewed.

Verification must demonstrate more than functional success on nominal test cases. Reviews and static analysis examine requirements, architecture, design, and code without executing the software, while dynamic testing examines behavior under normal, boundary, erroneous, and fault-injected conditions. Unit, integration, hardware-in-the-loop, and system testing progressively establish confidence. Structural coverage measurements can reveal portions of implementation that have not been exercised and can support more rigorous verification objectives for higher-criticality software.

Traceability ties these activities together into an auditable safety case. An assessor should be able to start from a hazardous condition, identify the associated safety goal or requirement, follow its allocation into software architecture and detailed requirements, locate the implementation, and inspect the verification evidence demonstrating compliance. Conversely, safety-related source code should have a justified requirement rather than existing as unexplained functionality. This bidirectional traceability is particularly valuable when embedded robot software evolves through firmware updates and product variants.

The three standards should consequently be understood as domain-specific safety frameworks rather than interchangeable checklists. IEC 61508 supplies broad functional-safety principles, ISO 26262 applies a specialized automotive lifecycle and ASIL framework, and railway standards adapt assurance practices to railway signaling and control environments. A robotics project may inherit ideas from several domains, but compliance claims must be based on the standard actually applicable to the product, operating environment, safety functions, and certification regime.

Within the attached book structure, this standards overview naturally establishes the foundation for the remaining safety-critical software topics. The subsequent subjects---SIL and ASIL determination, V-model development, defensive programming, runtime monitoring, FMEA and FTA, redundant safety channels, static analysis, MC/DC-oriented coverage, and emergency-stop safe-state transitions---represent practical mechanisms through which safety requirements become engineering evidence. Together they transform functional safety from an abstract requirement into a disciplined embedded-software lifecycle.

09.02 SIL/ASIL Determination Methods

Safety Integrity Level (SIL) and Automotive Safety Integrity Level (ASIL) are classification mechanisms used to translate risk analysis into concrete functional-safety requirements. They do not describe software quality in isolation; instead, they express the level of risk reduction and development assurance required for a safety-related function. In embedded robotics, understanding these classifications helps engineers determine how rigorously sensing, control, supervision, shutdown, and fault-handling functions must be designed and verified.

SIL is primarily associated with IEC 61508 and related functional-safety standards. Four levels, SIL 1 through SIL 4, represent increasing requirements for safety integrity, with SIL 4 demanding the greatest risk reduction. The appropriate level is determined from the hazardous consequences of failure and the amount of risk reduction required from the safety function. The classification therefore begins with system hazards rather than with software modules or individual source-code components.

A typical SIL determination process starts by identifying hazardous events and estimating their consequences and likelihood. Engineers examine operating conditions, initiating events, exposure, existing protection measures, and possible failure sequences. The initial or unmitigated risk is compared with the tolerable risk established for the system. The difference between these risk levels defines the necessary risk reduction, from which an appropriate integrity requirement can be allocated to one or more safety functions.

IEC 61508 distinguishes between safety functions operating in different demand modes. Low-demand functions are activated relatively infrequently, whereas high-demand or continuous functions may operate frequently or continuously. Quantitative integrity targets are therefore expressed using measures appropriate to the operating mode, such as probability of dangerous failure on demand or dangerous failure frequency. These numerical targets complement qualitative engineering requirements rather than replacing systematic safety analysis and disciplined development.

Several methods can support SIL assignment. A risk graph uses parameters representing consequences, exposure frequency, possibility of avoiding the hazard, and probability of the unwanted occurrence to derive an integrity requirement. A risk matrix combines severity and likelihood categories, while layers-of-protection analysis evaluates how independent protection layers reduce risk. Quantitative risk assessment can provide more numerical estimates when sufficient failure and operational data are available.

ASIL determination follows a different domain-specific method defined for automotive functional safety by ISO 26262. Hazard Analysis and Risk Assessment, commonly called HARA, identifies hazardous events created by malfunctioning behavior in relevant operational situations. Each hazardous event is evaluated using three principal parameters: Severity, Exposure, and Controllability. Their combination determines whether the event is treated through normal quality management or assigned ASIL A, B, C, or D.

Severity represents the potential magnitude of harm resulting from a hazardous event. The evaluation focuses primarily on possible injuries to people rather than damage to the vehicle itself. Increasing severity classifications represent increasingly serious consequences. Engineers must consider realistic accident scenarios, vehicle behavior, operating speed, surrounding road users, and the physical consequences that could occur when the malfunction and operational situation appear together.

Exposure describes how frequently or for how long the operational situation associated with the hazard is expected to occur. A malfunction may be technically possible but relevant only under a rare operating condition, while another malfunction may become hazardous during ordinary driving. Exposure classification therefore concerns the probability of encountering the operational situation rather than simply the probability that the electronic component or software function will fail.

Controllability estimates the extent to which the driver or other persons involved can reasonably avoid the resulting harm after the hazardous event begins. Factors include available reaction time, vehicle dynamics, warning information, environmental conditions, and the behavior expected from typical road users. A situation that can normally be controlled may receive a lower classification than one in which avoiding injury is extremely difficult or practically impossible.

The combination of Severity, Exposure, and Controllability produces the ASIL classification. ASIL A represents the lowest safety-integrity category within the ASIL range, while ASIL D represents the most demanding. Some combinations are classified as Quality Management, meaning that ISO 26262 does not assign an ASIL-specific safety requirement to that hazardous event. ASIL D consequently implies significantly stronger development, verification, independence, architectural, and evidence expectations than lower classifications.

After an ASIL has been assigned to a hazardous event, a safety goal is derived to prevent or mitigate the associated unreasonable risk. Functional safety requirements refine the safety goal into system behavior, and technical safety requirements further allocate responsibilities to hardware and software elements. The ASIL is therefore propagated through the safety lifecycle, influencing architecture, implementation, verification, validation, configuration management, and the degree of independence required for particular activities.

ASIL decomposition can sometimes distribute a safety requirement across sufficiently independent architectural elements. Instead of relying on one element carrying the complete integrity requirement, independent elements can contribute complementary safety mechanisms under defined decomposition rules. This technique is not simply redundancy. Independence, freedom from common-cause failures, interface assumptions, and compliance with the applicable decomposition constraints must be demonstrated before the architecture can claim the intended safety integrity.

SIL and ASIL should not be converted directly into one another. SIL belongs to the IEC 61508 functional-safety framework, whereas ASIL belongs to the automotive-specific ISO 26262 framework and is derived using a different risk-classification methodology. Although both represent increasing safety assurance, statements such as "ASIL D equals SIL 3" oversimplify the standards. The applicable domain, lifecycle, operating mode, risk model, quantitative targets, and certification requirements must be considered separately.

For robotics, the determination process begins by defining hazardous robot behavior rather than assigning an integrity level to the entire robot. Examples include unintended motion, excessive velocity, loss of braking, unexpected actuator torque, failure to detect a protective stop request, or failure to enter a safe state. Each safety function can then be analyzed according to the applicable industrial, automotive, railway, machinery, or robot-specific safety framework.

A mobile robot, for example, may use perception and navigation software to generate normal motion commands while an independent safety function supervises permitted velocity, protective sensors, emergency-stop signals, communication health, and actuator enable conditions. Risk analysis determines the required integrity of these safety functions. Higher integrity requirements can lead to stronger diagnostic coverage, redundancy, independence, deterministic execution, fault detection, verification depth, and safe-state mechanisms.

The integrity classification also affects software engineering activities. Higher-criticality software generally requires stronger requirements traceability, architecture review, coding restrictions, static analysis, unit verification, integration testing, structural coverage analysis, fault injection, configuration control, and independent assessment. The objective is not to create paperwork proportional to the integrity level, but to accumulate convincing evidence that systematic software faults have been prevented, detected, or controlled throughout development.

SIL or ASIL determination must therefore remain connected to the complete safety lifecycle. Hazard identification establishes what can go wrong; risk assessment determines how serious the resulting situation can become; integrity classification establishes the required assurance; safety requirements define the necessary behavior; architecture and implementation realize those requirements; and verification and validation demonstrate that the resulting system achieves the intended risk reduction.

Within the attached structure, SIL and ASIL determination forms the analytical bridge between the introductory safety standards and the engineering practices that follow. The subsequent topics---V-model development, defensive programming, runtime monitoring, software FMEA and FTA, redundant safety channels, static analysis, MC/DC-based coverage, and emergency-stop safe-state transitions---provide mechanisms for implementing and demonstrating the integrity established by the risk classification process.

09.03 Safety-Critical SW Development Process: V-Model

The V-Model is a structured development framework widely associated with safety-critical software engineering because it creates an explicit relationship between specification, implementation, integration, verification, and validation. Rather than treating testing as an activity performed after coding, the model defines corresponding verification activities while requirements and designs are being created. This supports systematic evidence generation throughout the safety lifecycle.

The characteristic V shape represents decomposition on the left side and integration on the right side. Development progresses from system and safety requirements toward increasingly detailed software architecture, component design, and implementation. After implementation, software is progressively integrated and tested in the opposite direction. Each development level therefore has a corresponding verification or validation level that demonstrates whether its intended requirements have been satisfied.

Safety-critical development begins before software requirements are written. Hazard analysis and risk assessment identify potentially dangerous system behaviors and establish safety goals, integrity requirements, and necessary risk-reduction measures. These system-level safety decisions provide the foundation from which software responsibilities are allocated. The V-Model therefore connects software engineering to the broader functional-safety lifecycle rather than allowing software development to operate independently from system safety analysis.

At the upper left side of the V-Model, system requirements describe what the complete embedded system must accomplish, including safety behavior, operating modes, environmental assumptions, interfaces, timing constraints, and fault responses. Safety requirements derived from hazards must be identifiable and traceable. Requirements should be precise, testable, internally consistent, and sufficiently detailed to permit objective verification rather than depending on subjective interpretation during final testing.

System architecture then allocates requirements among hardware, software, communication, sensors, actuators, and independent safety mechanisms. For a robot, normal motion planning may execute on a high-performance computer while emergency stopping, velocity supervision, actuator enable control, or watchdog functions reside in more isolated safety-related components. Architectural separation reduces interference and establishes clear responsibility for detecting faults and transitioning the machine toward a defined safe state.

Software requirements refine allocated system behavior into implementable functions. They may define input validity conditions, state transitions, diagnostic reactions, timeout limits, communication supervision, actuator commands, initialization sequences, degraded operating modes, and safe-state behavior. Every safety-related software requirement should maintain traceability to its higher-level requirement, while planned verification activities should establish how compliance will eventually be demonstrated.

Software architecture organizes these requirements into components, tasks, interfaces, data flows, execution contexts, and safety mechanisms. Designers consider independence, partitioning, memory protection, scheduling, communication integrity, resource limits, fault containment, and diagnostic coverage. Safety-critical architecture should make abnormal behavior explicit. Watchdogs, redundant measurements, plausibility checks, CRC protection, sequence monitoring, and independent shutdown mechanisms can therefore become architectural elements rather than late additions.

Detailed design translates architectural components into algorithms, state machines, data structures, interfaces, timing behavior, and implementation-level logic. Ambiguity should decrease as development moves downward through the V. For embedded control software, designers may specify exact transition conditions, range limits, execution periods, timeout values, numerical behavior, initialization rules, and error responses. Detailed design provides the direct engineering bridge between software requirements and source-code implementation.

Implementation occupies the bottom of the V-Model, where detailed designs become executable software. Safety-critical coding typically emphasizes deterministic behavior, bounded execution, explicit control flow, defensive input handling, predictable memory usage, and controlled language features. Coding standards, compiler rules, static analysis, peer review, configuration management, and reproducible builds help ensure that implementation does not introduce uncontrolled behavior or undocumented deviations from approved designs.

The right side begins with unit verification. Individual software units are checked against detailed design and software requirements using reviews, static analysis, unit tests, boundary-value tests, robustness tests, and structural coverage measurements where required. Fault conditions should be exercised deliberately rather than testing only expected inputs. The objective is not merely to demonstrate successful execution but to provide evidence that each unit satisfies its specified behavior and handles relevant failures correctly.

Software integration testing verifies interactions among previously tested units. Interfaces, data exchanges, scheduling dependencies, shared resources, initialization order, communication failures, and error propagation become major concerns. Incremental integration helps engineers identify failures close to the stage where they are introduced. Fault injection can be especially useful for demonstrating timeout handling, corrupted communication detection, watchdog behavior, redundant-channel disagreement, and transitions into degraded or safe operating modes.

System integration testing evaluates the embedded software together with processors, sensors, actuators, communication networks, operating systems, and other hardware. Hardware-in-the-Loop testing can reproduce difficult operating conditions while maintaining a controlled environment. Engineers can inject sensor faults, communication delays, actuator anomalies, processor overload, power-related events, or timing disturbances and determine whether the integrated safety mechanisms respond within specified limits.

Validation occurs near the upper right side of the V and asks whether the completed system fulfills its intended safety goals and operational needs. Verification primarily asks whether each development artifact was built according to its specification, whereas validation evaluates whether the resulting system is suitable for its intended use. Safety validation therefore considers realistic operating scenarios, environmental conditions, foreseeable misuse, hazardous events, and the effectiveness of implemented risk-control measures.

Traceability connects both sides of the V-Model. A safety goal should lead to system requirements, software requirements, architecture, detailed design, implementation, and corresponding verification evidence. The relationship must also work in reverse so that a test result or source-code element can be traced back to the requirement that justifies its existence. Bidirectional traceability makes missing requirements, untested functionality, unintended implementation, and incomplete verification considerably easier to detect.

Configuration and change management operate across the entire V rather than at a single development stage. Requirements, architecture documents, source code, test specifications, tool configurations, calibration data, compiler versions, generated binaries, and verification results must remain under controlled configuration. When a requirement or implementation changes, impact analysis determines which downstream and upstream artifacts require modification, review, regression testing, or renewed safety assessment.

Independence is another important characteristic of higher-integrity development. Depending on the applicable standard and integrity level, certain reviews, verification activities, or safety assessments may need personnel sufficiently independent from the original developer. Independence reduces the possibility that the same assumptions or misunderstandings influence both implementation and verification. The required degree of independence should therefore be determined by the applicable safety process rather than applied uniformly to every activity.

The V-Model should not be interpreted as requiring a rigid one-pass waterfall process. Iteration can occur when testing reveals incorrect assumptions, incomplete requirements, architectural weaknesses, or previously unidentified hazards. The important principle is that changes return through controlled requirements, design, implementation, and verification activities while preserving traceability and safety evidence. Iterative development remains compatible with the V-Model when lifecycle discipline is maintained.

For embedded robotics, the V-Model provides a practical structure for separating normal functionality from safety assurance while keeping them traceably connected. A motion-control feature can be decomposed into requirements and implementation while corresponding tests demonstrate timing, limits, fault reactions, and safe-state behavior. This becomes particularly important because software ultimately controls physical energy, movement, braking, steering, manipulation, or other actions capable of producing real-world hazards.

Within the attached structure, the V-Model development process follows the overview of safety standards and SIL/ASIL determination and establishes the lifecycle foundation for the implementation-oriented topics that follow. Defensive programming, runtime monitoring, software FMEA and FTA, redundant safety channels, static analysis, MC/DC-oriented coverage, and emergency-stop safe-state transitions can all be positioned within its development and verification activities.

09.04 Defensive Programming Techniques: Error Detection / Recovery [w/Code]

Defensive programming is a software engineering discipline that assumes faults, invalid inputs, corrupted data, unexpected states, timing violations, and hardware anomalies can occur during operation. In safety-critical embedded systems, the objective is not merely to prevent coding defects but to detect abnormal conditions early, contain their effects, and guide the system toward a predictable recovery or safe state before hazardous physical behavior develops.

The approach is particularly important in robotics because software directly influences motors, brakes, steering mechanisms, manipulators, batteries, and other energy-producing devices. A corrupted sensor value or incorrect command may therefore become a physical hazard within milliseconds. Defensive software places explicit checks around critical information and actions so that failures are detected near their origin rather than propagating silently through perception, planning, communication, and control layers.

Input validation is one of the most fundamental defensive techniques. Every external value should be treated according to an explicitly defined validity contract before it influences safety-related logic. Sensor measurements can be checked against physical ranges, command values against permitted operating limits, message fields against expected formats, and configuration parameters against allowable combinations. Invalid information should trigger a defined response rather than being accepted implicitly.

Range checking becomes especially important when physical limits are known. Robot velocity, acceleration, steering angle, motor current, actuator torque, temperature, battery voltage, and joint position normally have meaningful operating boundaries. Software can reject impossible values, clamp commands when permitted by the safety concept, or initiate a controlled transition when limits are exceeded. These checks should reflect system requirements rather than arbitrary constants hidden inside implementation code.

Plausibility checking evaluates whether a value is logically consistent with other available information. A wheel encoder may report high velocity while an independent inertial sensor indicates no corresponding motion, or two redundant position sensors may disagree beyond an allowed tolerance. Such values may individually appear valid but become suspicious when compared. Cross-checking independent information therefore provides stronger error detection than simple range validation alone.

Temporal validation adds time as another dimension of correctness. Sensor data may become unsafe even when its numerical value is valid if the information is stale, delayed, duplicated, or received in an incorrect sequence. Timestamps, sequence counters, heartbeat messages, deadline supervision, and communication timeouts can identify these conditions. A controller should distinguish between fresh trustworthy information and old data that merely remains stored in memory.

Communication interfaces require similar protection because embedded robots often distribute functions across MCUs, safety controllers, motor drives, sensors, and high-level computers. Message length, identifier, sequence, timing, and integrity can be checked before data is consumed. Checksums or cyclic redundancy checks can detect corruption, while counters and timeouts can reveal loss, repetition, or reordering. The receiving component should define explicitly how communication faults affect system operation.

Internal state must also be protected. State machines should permit only explicitly defined transitions and reject impossible combinations of operating states. For example, an actuator should not simultaneously be represented as disabled and commanded to produce torque. Initialization should establish known states before control outputs become active, and unexpected state values should lead to deterministic fault handling. This prevents memory corruption or logic defects from creating uncontrolled execution paths.

Defensive arithmetic is necessary because numerical errors can propagate rapidly through control algorithms. Integer overflow, underflow, division by zero, invalid shifts, floating-point NaN values, infinity, loss of precision, and unsafe type conversions should be considered explicitly. Calculations involving actuator commands or safety limits should define valid domains and boundary behavior. Saturation, checked arithmetic, or explicit error paths may be preferable to allowing implementation-defined or uncontrolled results.

Memory-related defensive techniques reduce failures caused by invalid pointers, buffer overruns, uninitialized data, stack exhaustion, and corrupted memory. Static allocation and bounded data structures are often preferred where predictable resource behavior is required. Memory protection units, stack guards, initialization patterns, ownership rules, and runtime consistency checks can provide additional containment. The appropriate mechanisms depend on the processor, operating system, criticality, and architecture.

Error detection becomes useful only when the software defines what happens afterward. A detected fault can be classified according to its severity, persistence, affected function, and impact on safety. Some faults permit continued normal operation after correction, others require degraded operation, and critical faults may require immediate transition to a safe state. The response should therefore be determined by the safety requirements instead of being improvised inside individual error handlers.

Recovery strategies can include retrying an operation, reinitializing a peripheral, switching to redundant information, restarting a software component, disabling a failed function, or entering a degraded mode. Recovery should be bounded because unlimited retries can create unpredictable timing or conceal persistent faults. A recovery mechanism must also avoid repeatedly returning the system to an unsafe condition. Successful recovery should restore a known and verified operational state.

Graceful degradation allows the system to preserve limited functionality when full performance can no longer be guaranteed. A mobile robot may reduce speed after losing a nonessential sensor, restrict its operating region when localization confidence decreases, or terminate an autonomous mission while retaining controlled braking and communication. Degradation policies must be explicitly designed so that reduced functionality does not violate assumptions used by other safety mechanisms.

When continued operation cannot be justified, the software must initiate a defined safe-state transition. Depending on the robot, this may involve commanding zero torque, applying brakes, disabling motor power, stopping mission execution, maintaining stabilization, or isolating an energy source. A safe state is application-dependent and may not always mean simply removing power. The transition itself must be controlled because abrupt shutdown can sometimes introduce additional hazards.

Watchdogs provide an independent mechanism for detecting software that stops executing correctly. A watchdog should not be refreshed merely because a task remains alive; stronger designs refresh it only after required execution checkpoints and health conditions have been satisfied. Windowed watchdogs can detect execution that is both too slow and unexpectedly fast. Watchdog expiration should initiate a defined reaction such as controlled reset, subsystem isolation, or transition to a safer operating condition.

Error handling should avoid creating additional failures. Logging routines, diagnostic communication, and recovery code must not consume unbounded time or resources inside critical execution paths. Error handlers should remain deterministic and should avoid recursion, uncontrolled dynamic allocation, or complex dependencies when possible. Safety-related fault information should be retained sufficiently to support diagnosis while ensuring that diagnostic activity never takes priority over immediate hazard mitigation.

Assertions can detect violated assumptions during development and, when appropriately designed, during operation. They are useful for identifying impossible states, invalid parameters, broken invariants, and incorrect API usage. In safety-critical software, however, assertion behavior must be deliberately defined. An assertion that simply terminates a process may itself be hazardous, so production handling should connect detected invariant violations to the system\'s established fault-management and safe-state strategy.

Redundancy and diversity strengthen defensive programming when a single information source or algorithm cannot provide sufficient confidence. Independent sensors, separate monitoring channels, replicated calculations, or differently implemented checks can detect disagreement before hazardous commands reach actuators. However, redundant elements should not be assumed independent automatically. Common inputs, shared power, shared memory, identical software defects, or common communication paths can defeat apparent redundancy.

Diagnostic information should support both immediate fault handling and later engineering analysis. Fault identifiers, timestamps, operating states, relevant sensor values, command history, reset causes, and diagnostic counters can help reconstruct events. Persistent storage must be managed carefully to avoid excessive write cycles or timing interference. Diagnostic records are particularly valuable during verification, fault injection, field investigation, and safety assessment.

Defensive programming should be verified deliberately rather than assumed effective because checks exist in the source code. Unit tests can exercise invalid values and boundary conditions, while integration tests can introduce corrupted messages, missing sensors, delayed communication, inconsistent measurements, and component resets. Fault injection extends this process by forcing abnormal conditions and observing whether detection latency, containment, recovery, degradation, and safe-state transitions satisfy specified requirements.

Within the attached structure, defensive programming follows the safety standards, SIL/ASIL determination, and V-Model development process and provides the implementation-level foundation for subsequent safety mechanisms. Runtime monitoring, watchdogs, checksums, memory protection, software FMEA and FTA, redundant safety channels, static analysis, structural coverage, and emergency-stop safe-state transitions build upon the same principle: detect faults early, prevent propagation, recover when justified, and move predictably toward safety when recovery cannot be guaranteed.

09.05 Runtime Monitoring: Watchdog, Checksum, Memory Protection [w/Code]

Runtime monitoring is a continuous safety mechanism that observes software execution, system health, communication, memory, and critical data while an embedded system is operating. Unlike development-time verification, runtime monitoring addresses faults that emerge during real operation. In safety-critical robotics, it provides an additional defensive layer capable of detecting abnormal behavior before software failures propagate into unsafe actuator commands or uncontrolled physical motion.

A runtime monitor should observe properties that are directly connected to safety requirements rather than collecting arbitrary diagnostic information. Typical targets include task execution frequency, deadline compliance, processor load, communication freshness, sensor validity, actuator status, memory integrity, power conditions, and internal state consistency. Monitoring rules define acceptable operating envelopes and determine what response is required when the observed system moves outside those boundaries.

Health monitoring combines multiple indicators to determine whether a software component or subsystem remains trustworthy. A task may still be executing while producing stale outputs, consuming excessive execution time, or remaining trapped in an incorrect internal state. Effective health monitoring therefore considers progress, timing, data validity, and functional state together. Heartbeat messages and health counters can provide compact evidence that distributed components remain responsive and synchronized.

A watchdog timer is one of the most widely used mechanisms for supervising software execution. The software must periodically service the watchdog within a defined timing interval; otherwise, the watchdog assumes that execution has failed and initiates a predefined response. Typical detected failures include deadlocks, infinite loops, scheduler failures, blocked tasks, severe timing overruns, and corrupted control flow. Hardware watchdogs can remain effective even when the supervised software itself becomes unresponsive.

Simple watchdog designs can create false confidence when software refreshes the timer without proving that important functions have completed correctly. A stronger approach permits refresh only after required tasks reach defined execution checkpoints and report valid health conditions. A centralized watchdog manager can collect these confirmations and service the hardware watchdog only when the complete safety-relevant execution chain is healthy. This converts watchdog servicing from an activity indicator into evidence of controlled progress.

Windowed watchdogs further strengthen supervision by defining both minimum and maximum refresh times. A refresh that arrives too late can indicate stalled execution, while one that arrives unexpectedly early may reveal corrupted control flow, incorrect scheduling, or an unintended loop. The permitted watchdog window should be derived from timing analysis and worst-case execution behavior. Recovery after expiration must also be deterministic and consistent with the system safety concept.

Watchdog response does not necessarily mean immediately resetting the entire robot. Depending on the detected fault and architecture, the system may disable actuator commands, transfer control to an independent safety controller, enter degraded operation, isolate a failed processor, or initiate a controlled restart. Resetting a processor while actuators remain energized can itself create hazards. Watchdog design must therefore consider both fault detection and the physical consequences of the recovery action.

Checksums provide data-integrity monitoring by calculating a compact value from a block of information and comparing it with an expected or transmitted value. They can detect accidental modification of configuration data, stored parameters, firmware regions, communication messages, and other safety-relevant information. A mismatch indicates that the data should not be trusted, allowing the receiving or supervising component to reject it and initiate an appropriate diagnostic or recovery response.

Cyclic Redundancy Checks, commonly called CRCs, provide stronger detection of common communication and storage corruption patterns than simple additive checksums. Embedded communication protocols frequently combine CRCs with message identifiers, sequence counters, length checks, and timing supervision. These mechanisms address different failure modes: CRC protects content integrity, counters detect repetition or loss, identifiers confirm message identity, and timeout supervision determines whether information remains sufficiently fresh for use.

Stored software and configuration can also require integrity checking. Boot-time verification may calculate a checksum or CRC over program memory, calibration data, or safety-related configuration before enabling operation. Runtime checks may periodically verify selected memory regions when timing constraints permit. If corruption is detected, the software can prevent activation, load a validated fallback configuration, isolate the affected function, or request maintenance rather than continuing with uncertain parameters.

Memory protection addresses another major class of runtime failures by restricting which software components can access particular memory regions. A Memory Protection Unit, or MPU, can separate code, data, stacks, peripherals, and safety-related resources according to configured permissions. Unauthorized reads, writes, or execution attempts generate protection faults. This prevents one defective task from freely corrupting another component\'s memory and provides architectural containment for software failures.

Systems using processors with virtual memory may employ a Memory Management Unit, or MMU, to provide stronger address-space isolation. Processes can execute in separate virtual address spaces, while operating-system mechanisms restrict access to kernel memory, device registers, and other processes. In mixed-criticality embedded Linux systems, such isolation can help separate high-level perception or planning applications from more critical supervisory components, although the complete safety argument must consider the operating system and platform architecture.

Stack protection is particularly important because stack overflow can corrupt control data and produce unpredictable execution. Guard regions, stack canaries, MPU boundaries, high-water monitoring, and static stack-usage analysis can detect or prevent excessive stack growth. Runtime systems may periodically measure remaining stack margin and report approaching limits before corruption occurs. Safety-related tasks should have stack sizes justified by analysis and verified under worst-case execution conditions.

Memory integrity can also be strengthened through Error Correcting Code memory, commonly called ECC memory, where supported by the hardware. ECC can detect and correct certain memory bit errors and report more severe corruption to system software. Runtime monitoring can observe ECC events and identify increasing error rates that may indicate deteriorating hardware. Corrected errors should not automatically be ignored because repeated corrections can provide valuable evidence of an emerging physical failure.

Runtime resource monitoring extends beyond memory. CPU utilization, execution time, queue depth, communication bandwidth, file-system capacity, temperature, voltage, and other resources may influence safety when exhaustion causes critical tasks to miss deadlines. Monitoring should establish thresholds before resources become completely unavailable. A controlled degradation or load-shedding strategy can then disable nonessential functions while preserving computational capacity for safety supervision and essential control.

Fault detection mechanisms must themselves be supervised where practical. A frozen monitor, corrupted watchdog manager, disabled MPU configuration, or malfunctioning diagnostic channel can remove the protection that the architecture assumes is available. Independent hardware, cross-monitoring, periodic self-tests, startup tests, and configuration verification can increase confidence in these mechanisms. Safety analysis should identify monitoring functions whose failure could remain latent until another fault occurs.

Runtime monitoring should feed a structured fault-management mechanism rather than generate disconnected alarms. Detected events can be classified by severity, persistence, affected subsystem, and required response. Transient faults may permit retry or continued operation, persistent faults may require degraded mode, and safety-critical violations may demand immediate safe-state transition. Diagnostic status should therefore connect detection mechanisms directly to deterministic state transitions defined by safety requirements.

For a mobile robot, this architecture may combine a high-performance computer running perception and planning with an independent MCU or safety controller supervising motion-critical conditions. The monitor can check command freshness, maximum velocity, emergency-stop status, sensor heartbeat, communication integrity, actuator feedback, and controller health. If the high-level computer freezes or transmits invalid commands, the safety path can prevent those commands from producing uncontrolled motion.

Verification of runtime protection requires deliberate fault injection. Engineers can stop tasks, corrupt messages, modify memory, delay communication, exceed stack limits, violate watchdog windows, or simulate sensor and processor failures. Tests should measure detection latency, fault containment, recovery time, and resulting actuator behavior. The objective is to demonstrate not merely that an alarm appears, but that the system reaches the required controlled or safe condition within its specified timing constraints.

Within the attached structure, runtime monitoring follows defensive programming and extends its principles into continuous operational supervision. Watchdogs detect execution failures, checksums and CRCs protect information integrity, memory protection contains unauthorized access, and health monitoring evaluates whether critical components remain trustworthy. Together with later FMEA, FTA, redundant safety channels, static analysis, coverage, and safe-state mechanisms, these techniques establish layered runtime assurance for safety-critical embedded software.

09.06 SW FMEA and FTA Methodology

Software Failure Mode and Effects Analysis (SW FMEA) and Fault Tree Analysis (FTA) are complementary safety-analysis methods used to understand how software faults can contribute to hazardous system behavior. SW FMEA primarily examines failures from the perspective of individual software functions and components, while FTA begins with an undesirable system-level event and reasons backward toward possible causes. Together, they provide both bottom-up and top-down views of software-related risk.

SW FMEA adapts the general Failure Mode and Effects Analysis approach to software behavior. Because software does not normally wear out like mechanical hardware, the analysis focuses on systematic faults, incorrect logic, corrupted information, timing violations, interface failures, unintended state transitions, and inadequate fault handling. The objective is to determine how deviations in software behavior can propagate through an embedded system and influence safety-related functions.

The analysis begins by defining the scope and decomposition of the software. Functions, components, tasks, interfaces, state machines, communication paths, and safety mechanisms can serve as analysis elements. The decomposition should correspond to the software architecture closely enough that identified failure modes can be traced to requirements and implementation. Excessively coarse analysis may hide important propagation paths, while excessive detail can make the analysis difficult to maintain.

For each analyzed element, engineers identify credible failure modes. Typical examples include missing output, incorrect output, unintended output, delayed output, output generated too early, stale data, corrupted data, incorrect sequence, failure to execute, excessive execution time, invalid state transition, and failure to detect another fault. These categories encourage systematic examination without assuming that every software failure appears simply as a complete loss of functionality.

The local effect describes what happens immediately within the affected component, while higher-level effects describe how the failure propagates through software, hardware, and physical behavior. An incorrect velocity command may first affect a communication interface, then a motor controller, and ultimately robot motion. The analysis should continue far enough to determine whether the failure can contribute to a hazardous event, violate a safety goal, or reduce an assumed safety mechanism.

SW FMEA also identifies existing prevention and detection controls. Input validation, range checks, watchdogs, sequence counters, CRC protection, redundant sensing, memory protection, state supervision, timeout monitoring, and independent safety controllers may prevent or detect particular failure modes. Analysts evaluate whether these mechanisms detect the failure early enough and whether their reaction prevents propagation into unsafe behavior. Detection without an adequate response is not sufficient safety protection.

Severity, occurrence-related considerations, and detectability may be used to prioritize findings, depending on the applicable organizational process and standard. Traditional FMEA sometimes combines rankings into a Risk Priority Number, but safety-critical analysis should not rely on a single numerical score as proof of acceptability. A severe safety consequence can require explicit mitigation even when estimated occurrence is low. Safety requirements and applicable integrity targets remain the governing criteria.

Recommended actions are generated when existing controls are inadequate. Actions may include strengthening validation, introducing independent monitoring, redesigning an interface, improving timing supervision, separating safety-related functions, adding redundancy, modifying state-machine behavior, or defining a safer fault response. Each action should have an owner and verification method so that the FMEA becomes a living engineering artifact rather than a static worksheet produced only for documentation.

FTA approaches the problem from the opposite direction. It begins with a clearly defined top event representing an undesirable condition, such as "robot fails to stop when required," "uncommanded motion occurs," or "unsafe actuator torque is produced." Analysts then decompose the top event into combinations of lower-level events that could cause it. This top-down reasoning is particularly effective for understanding interactions among multiple faults and protection mechanisms.

Fault trees use logical relationships to describe how contributing events combine. An OR relationship means that any one of several events can produce the higher-level event, whereas an AND relationship means that multiple events must occur together. More specialized logic may be used when required, but the tree should remain understandable and traceable. The purpose is not visual complexity; it is to expose the causal structure that allows a hazardous condition to occur.

Consider a robot that must stop when an obstacle enters a protective region. A top event could be failure to achieve the required stop. Possible branches might include failure to detect the obstacle, failure to transmit the stop request, failure of safety logic, failure of actuator shutdown, or insufficient braking capability. Each branch can then be decomposed further into sensor, communication, software, hardware, timing, power, and common-cause contributors.

Software events in an FTA should be described in terms of observable failure behavior rather than vague statements such as "software error." Examples include "stop request not generated," "invalid command accepted," "watchdog fails to detect stalled task," "stale sensor data treated as valid," or "safe-state transition not executed." Precise descriptions make the tree more useful for deriving requirements, identifying verification activities, and connecting the analysis to actual software architecture.

Minimal cut sets are combinations of basic events sufficient to cause the top event. Identifying them helps engineers discover single points of failure and combinations that defeat otherwise effective safety mechanisms. If one software failure alone can create the hazardous event, additional independence or protection may be necessary. If two supposedly independent channels appear in the same cut set, analysts should examine whether common resources or common-cause failures undermine that independence.

Common-cause and dependent failures are especially important when redundancy is used. Two monitoring channels may share the same sensor, clock, power supply, communication bus, memory, operating system, or software algorithm. A single underlying defect can therefore defeat both channels simultaneously. SW FMEA and FTA should challenge assumptions of independence rather than treating duplicated components as automatically providing sufficient safety integrity.

The two methods complement each other through their different directions of reasoning. SW FMEA asks what can go wrong within each software element and what effects follow from that failure, while FTA asks what combinations of failures could produce a specified hazardous outcome. Findings from one analysis can expose missing scenarios in the other. A failure mode discovered by SW FMEA may become a basic FTA event, while an unexplained FTA branch may reveal a software failure mode that requires further FMEA analysis.

Both analyses should remain connected to requirements and architecture throughout development. Hazard analysis provides safety goals and hazardous events, architecture identifies safety-related elements and interfaces, SW FMEA evaluates component-level failure behavior, and FTA evaluates causal paths toward system hazards. Resulting mitigations should become traceable safety requirements. Verification activities then demonstrate that the implemented detection, containment, recovery, redundancy, and safe-state mechanisms actually satisfy those requirements.

The analyses should also evolve when the system changes. New software functions, communication interfaces, sensors, operating modes, recovery strategies, or architectural partitions can introduce failure paths that did not exist in an earlier design. Change-impact analysis should therefore determine whether affected FMEA entries and fault-tree branches require revision. Maintaining consistency among safety analysis, requirements, implementation, and test evidence is essential for configuration-controlled safety development.

Fault injection provides an important bridge from analytical reasoning to experimental verification. Failure modes identified through SW FMEA and basic events identified through FTA can be deliberately introduced into unit, integration, HIL, or system tests. Engineers can corrupt messages, delay tasks, freeze processors, remove sensor updates, violate state transitions, or disable communication. Measured responses demonstrate whether assumed safety mechanisms actually detect and control the modeled faults.

For safety-critical robotics, combining SW FMEA and FTA creates a structured understanding of how software defects can become physical hazards. The analysis follows failure propagation from sensors and software through communication, control, and actuators while also tracing hazardous outcomes backward toward their possible causes. This bidirectional perspective supports stronger architecture, clearer safety requirements, targeted fault injection, and more convincing evidence that dangerous failure paths have been controlled.

Within the attached structure, SW FMEA and FTA follow runtime monitoring, watchdog, checksum, and memory-protection mechanisms and precede redundant safety-channel architecture. This placement reflects their role in identifying failure propagation, single points of failure, common-cause vulnerabilities, and inadequate detection mechanisms before stronger architectural mitigations are selected. Subsequent redundancy, static analysis, coverage, and safe-state topics provide additional means for controlling and verifying the risks exposed by these analyses.

09.07 Redundant Safety Channel Software Design

Redundant safety-channel software design uses multiple safety-related paths so that a single fault does not immediately eliminate the system's ability to detect a hazard or enforce a safe response. In safety-critical embedded robotics, redundancy can involve sensors, processors, communication paths, monitoring software, control logic, or actuator shutdown mechanisms. The objective is fault tolerance with sufficient independence, not simply duplication of identical software.

A safety channel is a functional path that participates in detecting a hazardous condition, making a safety decision, or executing a protective action. It may contain sensor inputs, signal validation, safety logic, communication, output drivers, and diagnostics. Two-channel architectures commonly provide Channel A and Channel B, with each channel processing safety-relevant information and contributing to a final decision such as allowing motion, reducing speed, or commanding a stop.

The simplest redundant structure is duplicated processing in which two channels evaluate the same safety condition. Their outputs can be compared before an actuator command is accepted. Agreement permits the requested operation, while disagreement indicates that at least one channel may be faulty. The system must then follow a predetermined policy, normally favoring the safer response rather than arbitrarily selecting one result and continuing normal operation.

Redundancy alone does not guarantee safety because duplicated channels may fail for the same reason. Two processors running identical software can share the same requirements defect, algorithmic error, compiler issue, power disturbance, clock failure, sensor corruption, or communication fault. Safety architecture must therefore examine common-cause failure and dependent failure explicitly. Apparent duplication without sufficient independence can provide far less risk reduction than expected.

Independence can be strengthened through physical and logical separation. Channels may use separate processors, memory regions, power domains, communication interfaces, execution schedules, or I/O paths. Memory protection and partitioning can prevent one software fault from corrupting another channel. Separate watchdogs and independent supervision can further reduce coupling. The required degree of separation should follow the safety requirements and assumptions established by the system safety analysis.

Diversity provides another defense against common systematic faults. Diverse channels may use different algorithms, software implementations, sensors, processors, compilers, or development approaches. One channel might determine robot velocity from wheel encoders while another verifies motion using an independent inertial or safety-rated sensing source. Diversity is valuable only when the differences address credible common failure mechanisms rather than introducing complexity without a clear safety purpose.

Cross-monitoring allows redundant channels to supervise one another. Each channel can exchange heartbeat, state, timing, diagnostic, and computed safety information with its peer. A channel can detect disagreement, missing updates, invalid sequence counters, stale data, or inconsistent state. Cross-monitoring protocols must themselves be protected because corrupted or delayed comparison information can otherwise create incorrect conclusions about which channel remains trustworthy.

A comparator or voter determines how redundant outputs are interpreted. In a two-channel architecture, disagreement cannot necessarily reveal which channel is correct, so the safest policy may be to inhibit hazardous operation. Architectures with three or more channels can sometimes use majority voting, but voting should not conceal common-cause faults. The voter itself becomes safety-relevant and must be designed, monitored, and verified according to the required integrity.

Safety architectures often distinguish between fail-safe redundancy and fault-tolerant redundancy. Fail-safe designs prioritize transition to a safe condition after a detected failure, even if normal operation must stop. Fault-tolerant designs attempt to continue operation using remaining healthy channels while maintaining required safety integrity. Robotics may require both approaches: some faults permit reduced-speed operation, whereas failures affecting motion authority may require an immediate protective or emergency stop.

A redundant channel must therefore include fault-detection and isolation logic. Detection identifies abnormal behavior through watchdogs, plausibility checks, consistency comparisons, communication supervision, memory protection, or self-tests. Isolation prevents a failed channel from continuing to influence safety-critical outputs. Once isolated, the system may switch to a backup, reduce functionality, prohibit particular commands, or transition to a minimum-risk state depending on the remaining safety capability.

Authority over actuators is a crucial architectural consideration. A high-level computer may generate navigation or manipulation commands, but an independent safety channel can enforce velocity, position, force, workspace, or energy limits before those commands reach actuators. If the primary software freezes or generates unsafe commands, the safety channel should retain sufficient authority to inhibit motion, disable drive enable signals, command a controlled stop, or activate independent hardware protection.

Communication between redundant channels requires explicit integrity mechanisms. Messages can contain identifiers, sequence counters, timestamps, checksums or CRCs, and status information. Receivers verify content, freshness, order, and timing before accepting safety information. Communication loss should have a defined interpretation rather than leaving the last command active indefinitely. Where independence is essential, designers should also consider whether sharing one communication bus creates a common failure point.

Startup behavior is as important as runtime operation. Redundant channels should perform initialization and self-tests before safety-related outputs become enabled. Software versions, configuration data, memory integrity, I/O states, watchdogs, communication links, and channel identities can be checked. A channel that fails initialization should not silently participate in voting or comparison. The system should enter operation only when the required safety architecture has been established and verified.

Latent faults require special attention because a redundant architecture may appear healthy while one channel has already failed. The dangerous condition emerges later when the remaining channel also fails or a demand occurs. Periodic self-tests, cross-checks, proof tests, diagnostic coverage, and health monitoring reduce the time that such faults remain hidden. Safety analysis should determine which failures can remain latent and how they will be revealed before redundancy is needed.

Degraded operation must be explicitly defined when redundancy is lost. A robot designed with two independent safety channels may be allowed to continue only at reduced speed, complete a controlled stop, return to a service area, or prohibit autonomous motion after one channel fails. Continuing unrestricted operation simply because one channel still functions may violate the assumptions used to establish the required safety integrity.

SW FMEA and FTA provide important inputs to redundant architecture design. SW FMEA can identify failure modes within each channel and determine whether faults propagate into its peer, while FTA can reveal combinations of channel failures that produce hazardous top events. Minimal cut sets help expose single points of failure, and common-cause analysis challenges independence assumptions. Redundancy should therefore be derived from safety analysis rather than added as an intuitive reliability feature.

Verification must demonstrate both correct operation and effective independence. Tests should inject processor failures, frozen tasks, corrupted memory, communication loss, stale data, sensor disagreement, watchdog expiration, and invalid outputs into individual channels. Engineers then observe whether faults are detected, isolated, and prevented from propagating. Tests should also verify that channel disagreement causes the required degraded or safe response within the specified timing limits.

Timing behavior becomes critical because redundant decisions must be completed before a hazardous physical condition develops. Channel execution periods, synchronization, comparison delays, communication latency, fault-detection time, isolation time, and actuator response all contribute to the total safety reaction time. Worst-case timing analysis should confirm that the complete path from fault occurrence to enforced protective action remains within the safety requirement.

Configuration management must preserve channel integrity throughout the product lifecycle. Software versions, calibration parameters, safety thresholds, compiler settings, hardware revisions, and communication configurations can affect independence and diagnostic behavior. Updating one or both channels therefore requires impact analysis and regression verification. An uncontrolled configuration mismatch may create disagreement, disable cross-monitoring, or invalidate assumptions made during the original safety analysis.

In robotic systems, a practical layered architecture can combine complex perception and planning software with simpler independent safety channels. The high-level system determines what the robot should do, while the safety path continuously determines whether the requested action remains permitted. This separation limits the amount of complex software that must directly carry final safety authority and provides a defensive boundary between intelligent decision making and physical actuation.

Within the attached structure, redundant safety-channel software design follows SW FMEA and FTA and precedes static analysis, MC/DC-oriented coverage, and emergency-stop safe-state design. This sequence reflects the role of safety analysis in discovering where redundancy and independence are needed, followed by verification techniques that provide evidence for the implemented software. The chapter structure explicitly positions redundancy and diversity as enabling safety techniques within the broader functional-safety lifecycle.

09.08 Static Analysis Tools: Polyspace, LDRA, PC-lint

Static analysis examines software without requiring the program to execute, allowing many defects and rule violations to be identified before dynamic testing begins. In safety-critical embedded development, it provides systematic evidence about source-code quality, language usage, data flow, control flow, and potential runtime failures. The attached structure places Polyspace, LDRA, and PC-lint analysis after redundant safety-channel design and before coverage-based verification.

The central advantage of static analysis is that it can explore conditions that conventional testing may rarely or never exercise. Tests demonstrate behavior for selected inputs and execution paths, whereas static analysis reasons directly about program structure and possible operations. It can therefore expose defects such as uninitialized variables, invalid pointer operations, arithmetic errors, unreachable code, suspicious conversions, and inconsistent control logic before software is deployed to embedded hardware.

Static analysis should not be treated as a single technique. Basic tools inspect syntax patterns and coding-rule compliance, while more advanced analyzers construct control-flow graphs, data-flow relationships, call graphs, and abstract representations of program states. Some tools apply abstract interpretation or related formal reasoning to determine whether particular runtime errors are possible. The depth of analysis therefore varies significantly depending on the tool, configuration, and verification objective.

Coding-standard enforcement is particularly important in safety-critical C and C++ because these languages contain constructs whose behavior may be implementation-dependent, difficult to review, or vulnerable to misuse. Static analyzers can check source code against project rules and standards such as MISRA C or MISRA C++. The purpose is not stylistic uniformity alone; restricting problematic language constructs reduces ambiguity and makes program behavior easier to analyze, review, test, and maintain.

Typical findings include unused variables, unreachable statements, missing initialization, inconsistent declarations, suspicious Boolean expressions, implicit conversions, signed and unsigned mismatches, questionable pointer arithmetic, array-bound risks, and inappropriate control structures. More advanced analysis can investigate division by zero, integer overflow, buffer access, invalid dereferences, and other runtime faults. Findings should be interpreted in the context of the target compiler, hardware architecture, and project safety requirements.

Polyspace is commonly associated with mathematically based static analysis for C and C++ software. Its analysis can reason about possible program states without executing every concrete test case and classify potential runtime problems according to whether operations are proven safe, proven erroneous, unreachable, or require further investigation. This approach is especially valuable when safety-related embedded code contains combinations of inputs and execution paths that are impractical to cover exhaustively through conventional testing.

A major concept behind Polyspace analysis is the attempt to prove the absence of selected runtime errors rather than merely discovering examples of failures. For a given analysis configuration and modeled assumptions, the tool can reason about operations such as array access, pointer dereference, arithmetic behavior, and division. However, the strength of the result depends on accurate environmental assumptions, compiler configuration, data ranges, stubs, and interpretation of external interfaces.

LDRA provides a broader software verification environment in which static analysis can be integrated with coding-standard compliance, structural analysis, requirements traceability, dynamic testing, and coverage activities. This makes it suitable for development processes where evidence must be connected across lifecycle artifacts. Static findings can therefore participate in a larger verification workflow rather than remaining isolated warnings generated by a standalone source-code checker.

Within an LDRA-oriented workflow, developers can analyze code structure, complexity, data and control flow, coding-rule compliance, and potentially problematic constructs. The same environment can support later verification activities such as test execution and structural coverage measurement. This connection is useful in a V-Model process because source-code verification, requirements evidence, and test results can be organized as related assurance artifacts rather than independent engineering outputs.

PC-lint is traditionally used as a lightweight but detailed static-analysis and linting tool for C and C++ source code. It is particularly useful for detecting suspicious constructs, portability problems, type inconsistencies, questionable expressions, unused objects, and violations of configured coding rules. Its large set of diagnostic messages can provide rapid feedback during implementation, making static checking practical as a routine part of individual developer workflows.

The effectiveness of PC-lint depends strongly on configuration. Compiler characteristics, language options, library definitions, project macros, warning policies, and coding-standard rules should reflect the actual build environment. An incorrectly configured analyzer can generate excessive false positives or overlook relevant conditions. For safety-related projects, the static-analysis configuration itself should therefore be controlled, reviewed, versioned, and treated as part of the verification environment.

Polyspace, LDRA, and PC-lint should not necessarily be viewed as interchangeable products. They can occupy different positions in a verification strategy. A lightweight linting tool may provide immediate developer feedback, a comprehensive lifecycle-oriented environment may manage broader verification evidence, and a formal or abstract-interpretation-based analyzer may investigate difficult runtime properties. Tool selection should follow safety objectives, software complexity, language, workflow, and required assurance evidence.

False positives are an unavoidable practical concern in many static-analysis workflows. A tool may report a condition that cannot occur because it lacks knowledge about hardware behavior, external protocols, scheduling constraints, or validated input assumptions. The correct response is not simply to suppress inconvenient warnings. Each relevant finding should be reviewed, classified, corrected when necessary, or justified through a documented deviation supported by technical reasoning.

Warning suppression must therefore be controlled carefully. Broadly disabling a diagnostic category can hide future defects that resemble previously accepted exceptions. More disciplined processes use narrowly scoped suppressions, documented justifications, review approval, and traceability to project rules. The objective is to establish a clean and explainable analysis baseline in which remaining deviations are understood rather than allowing thousands of unresolved warnings to become accepted background noise.

Static analysis also supports architectural quality by revealing excessive complexity, deep nesting, high coupling, recursion, large functions, or difficult dependency structures. Although complexity metrics do not prove that software is unsafe, they identify areas that are harder to understand and verify. Safety-related code should generally favor simple and deterministic structures because verification confidence decreases when control flow and data dependencies become unnecessarily complicated.

Integration into continuous integration pipelines allows analysis to occur whenever software changes. A developer commit can trigger compilation, coding-rule checks, static analysis, unit tests, and other quality gates automatically. Newly introduced violations can be distinguished from an approved baseline, preventing technical debt from accumulating unnoticed. This shifts static analysis from a late certification activity toward a continuous engineering control applied throughout implementation and maintenance.

Tool qualification and confidence become important when automated analysis results are used as part of safety evidence. The required treatment depends on the applicable safety standard, tool usage, and whether an undetected or incorrectly reported tool error could compromise verification. Teams should therefore document the tool version, configuration, intended use, assumptions, known limitations, and validation or qualification evidence required by their development process.

Static analysis results should maintain traceability to source-code versions and corrective actions. When a defect is found, engineers should identify the affected component, evaluate its safety relevance, correct or justify the condition, rerun analysis, and retain evidence of closure. Configuration management ensures that reports correspond to the same source code, compiler assumptions, coding rules, and tool settings used for the safety-related software baseline.

Static analysis complements rather than replaces peer review and dynamic testing. A tool may detect an invalid pointer but fail to recognize that a perfectly valid command violates a system-level safety requirement. Human reviewers understand design intent and architectural assumptions, while execution-based testing observes actual behavior on representative platforms. Combining static analysis, review, unit testing, integration testing, fault injection, and coverage provides stronger evidence than relying on any one method alone.

For embedded robotics, static analysis is particularly valuable in motor-control, communication, safety-monitoring, and actuator-interface software where a small implementation defect can propagate rapidly into physical behavior. Detecting an overflow, stale-state dependency, incorrect condition, or memory-access error before deployment reduces the probability that such faults reach real hardware. Analysis should therefore concentrate especially on software that participates directly in motion authority and safe-state enforcement.

Within the attached chapter structure, static analysis follows safety standards, SIL/ASIL determination, the V-Model, defensive programming, runtime protection, SW FMEA/FTA, and redundant safety-channel design. It then leads naturally into code-coverage-based safety verification and emergency-stop safe-state transition design. This progression moves from defining safety obligations and architecture toward implementation evidence showing that critical software has been systematically examined before final behavioral verification.

09.09 Code Coverage-Based Safety Verification: MC/DC

Code coverage is a structural verification technique used to measure which parts of software have actually been exercised by a test suite. In safety-critical embedded software, coverage is not merely a numerical quality score. It provides evidence about the completeness of verification and exposes implementation structures that have not been challenged by tests. Within the attached structure, coverage and MC/DC follow static analysis and support unit-level verification before safe-state design.

Coverage analysis begins by instrumenting the software or collecting execution information from the target environment. As tests execute, the verification tool records which statements, branches, decisions, and logical conditions are reached. The resulting measurements are compared with the required coverage objectives. Uncovered structures then become subjects for investigation, additional testing, requirements review, or justification rather than being accepted simply because the existing tests have passed.

Statement coverage measures whether each executable statement has been executed at least once. It provides a basic indication that implementation code has been reached by testing, but it does not demonstrate that all outcomes of decision logic have been exercised. A test suite can therefore achieve complete statement coverage while leaving important control-flow behavior unexplored. Safety-critical verification normally requires deeper structural evidence when complex decisions can influence hazardous physical behavior.

Branch or decision coverage examines whether each possible outcome of a decision has been exercised. For an if statement, both the true and false outcomes should be observed. Similar reasoning applies to loops, switch structures, and other control-flow constructs. Decision coverage is stronger than statement coverage because it confirms that tests have traversed alternative control paths, but it may still fail to reveal whether individual Boolean conditions independently affect a compound decision.

Condition coverage examines the Boolean conditions contained within a decision. Consider a decision composed of conditions A, B, and C. Condition coverage requires each condition to take both true and false values during testing. However, achieving this does not necessarily prove that each condition can independently influence the final decision result. Correlations among conditions can allow apparently complete condition coverage while important logical behavior remains insufficiently demonstrated.

Modified Condition/Decision Coverage, commonly abbreviated MC/DC, addresses this limitation by requiring evidence that each condition within a decision can independently affect the decision outcome. Each condition must take both true and false values, the decision must take both outcomes, and suitable test pairs must demonstrate the independent influence of individual conditions while the effect of other conditions is appropriately controlled. This makes MC/DC especially valuable for complex safety-related logic.

For a simple decision such as (A && B)\, testing only the combinations where both conditions change simultaneously does not demonstrate independent influence. To show the effect of A, tests can hold B true while changing A and observe the decision change. To show the effect of B, A can remain true while B changes. The purpose of MC/DC is therefore not exhaustive testing of every Boolean combination, but carefully selected evidence that every condition meaningfully controls the decision.

This distinction becomes increasingly important as expressions become more complex. Exhaustive testing of a decision containing many independent Boolean conditions can require an exponentially increasing number of combinations. MC/DC seeks stronger logical evidence than ordinary decision or condition coverage while avoiding the full cost of exhaustive truth-table testing. It therefore provides a practical compromise between verification rigor and test-set size for high-integrity software.

MC/DC should be understood as a test adequacy criterion rather than a proof that the software is correct. A function can achieve complete structural coverage while implementing the wrong requirement, using an incorrect algorithm, or omitting necessary behavior entirely. Coverage indicates what implementation structure was exercised; requirements-based testing determines whether intended behavior was correctly implemented. Both perspectives are required to build credible safety evidence.

Requirements-based testing should therefore drive the test design before coverage results are examined. Tests are derived from software requirements, including nominal behavior, boundaries, invalid inputs, timing conditions, fault responses, and safe-state transitions. Structural coverage is then measured to determine whether those tests sufficiently exercised the implementation. Creating tests solely to increase a percentage without understanding the associated requirement can produce impressive metrics without meaningful verification.

Coverage gaps provide valuable diagnostic information. Uncovered code may indicate missing test cases, incomplete requirements, defensive logic that is difficult to activate, obsolete implementation, or genuinely unreachable code. Each gap should be analyzed rather than automatically solved by adding artificial tests. If code has no justified requirement or cannot legitimately execute, removing it may be more appropriate than creating a test merely to satisfy a numerical coverage objective.

Unreachable or deactivated code requires particular attention in safety-critical software. Code that cannot execute under the verified configuration may represent obsolete functionality, compile-time variants, defensive behavior, or an incorrect assumption in the analysis environment. Engineers should distinguish structurally unreachable code from code that is merely difficult to stimulate. Any exclusion from coverage should be supported by documented reasoning, configuration evidence, and the applicable verification process.

Defensive code can create challenging coverage cases because it may exist specifically to handle conditions that normal system operation should prevent. Examples include impossible state detection, corrupted input handling, memory-protection reactions, or communication integrity failures. Fault injection can help exercise such paths by deliberately introducing abnormal conditions. This connects defensive programming and runtime monitoring directly to structural verification rather than leaving their error paths untested.

Instrumentation can affect embedded software behavior, particularly in systems with tight timing, memory, or processor constraints. Added probes may change execution time, task scheduling, memory layout, cache behavior, or communication timing. Coverage strategies must therefore consider whether measurements are collected on the target hardware, through a simulator, using trace capabilities, or through instrumented builds. Differences between the verification environment and released software should be understood and controlled.

Target-based coverage is especially valuable when compiler optimization or hardware-specific behavior can influence executable structure. Source-level coverage shows which source constructs were exercised, while object-code or assembly-level analysis may reveal structures introduced or transformed by compilation. The required level of analysis depends on the applicable safety process, compiler behavior, criticality, and whether source-to-object traceability leaves unresolved executable structures.

Coverage tools themselves form part of the verification environment. Their version, instrumentation configuration, compiler integration, report generation, and interpretation rules should remain under configuration control. When coverage results contribute significantly to safety evidence, tool confidence or qualification considerations may apply according to the relevant standard and development process. Repeatability is essential so that the same software and test baseline can reproduce the reported results.

Independence and review strengthen coverage-based verification. Engineers should examine whether tests genuinely demonstrate the intended condition independence rather than relying solely on a tool reporting "100% MC/DC." Complex expressions, short-circuit evaluation, masking, repeated conditions, and compiler transformations can complicate interpretation. Human review of critical decisions helps ensure that measured coverage corresponds to meaningful logical verification rather than only satisfying a tool-specific metric.

Coverage should also be maintained as software evolves. A requirement change, bug fix, compiler update, or architectural modification can introduce new statements and decisions or invalidate previously demonstrated coverage. Regression testing should therefore rerun the relevant test suites and regenerate coverage evidence against the controlled software baseline. A previously achieved coverage target does not automatically remain valid after implementation or configuration changes.

In embedded robotics, MC/DC is particularly relevant to compact but safety-significant decision logic such as motion permission, brake release, actuator enable, speed supervision, collision protection, and safe-state transitions. A decision combining emergency-stop status, sensor validity, communication health, localization confidence, and actuator readiness may directly determine whether physical motion is permitted. Independent verification of each condition therefore strengthens confidence that no single logical factor is unintentionally masked.

Coverage results also provide feedback to software design. Extremely complicated decisions may require large and difficult MC/DC test sets, indicating that the logic itself is difficult to understand and verify. Refactoring complex expressions into simpler named decisions can improve readability, traceability, and testability. Safety-oriented design therefore seeks not merely to measure complex code successfully, but to create implementation structures whose safety behavior can be demonstrated clearly and efficiently.

Static analysis and coverage analysis provide complementary evidence. Static analysis reasons about source code without requiring execution and can identify possible defects, prohibited constructs, unreachable structures, and data-flow problems. Coverage analysis observes what the test suite actually executed. The attached lifecycle places static analysis immediately before coverage and identifies MC/DC as part of unit verification, reinforcing this complementary relationship between implementation analysis and execution-based evidence.

The final objective is not maximum coverage as an isolated metric but justified confidence that safety-related software has been systematically verified. Requirements establish what behavior must be tested, structural coverage reveals what implementation was exercised, MC/DC demonstrates the independent effect of conditions in critical decisions, and gap analysis exposes incomplete evidence. Together with reviews, static analysis, fault injection, traceability, and configuration control, coverage becomes part of the broader safety case.

Within the attached chapter structure, code-coverage-based safety verification is positioned after redundant safety-channel design and static analysis and immediately before emergency-stop software design and safe-state transition. This progression moves from architectural fault tolerance and implementation analysis toward execution-based verification of critical logic, followed by the final protective behavior that must place the physical system into a controlled condition when continued operation is unsafe.

09.10 E-Stop Software Design and Safe State Transition [w/Code]

Emergency-stop software design is the final software-facing protection used when continued robot operation can no longer be considered acceptably safe. Its purpose is not merely to detect that an emergency-stop device has been activated, but to ensure that the complete system follows a deterministic transition from operating motion toward a predefined safe condition. In the attached structure, this topic closes the safety-critical embedded software chapter after analysis, redundancy, static verification, and code coverage.

An Emergency Stop, commonly abbreviated E-Stop, should be treated as part of a safety function rather than as an ordinary application command. Normal software may request motion, navigation, manipulation, or mission execution, but an E-Stop must override those activities according to the safety architecture. The software therefore participates in detecting the safety input, propagating its state, suppressing conflicting commands, supervising the transition, and reporting whether the required safe condition has actually been achieved.

The safe state must be defined from the physical hazard analysis rather than assumed to mean simply turning the computer or robot off. For a mobile robot, the required condition may include controlled deceleration, drive torque removal, brake application, and prevention of subsequent motion. For a manipulator, immediately removing power may allow a suspended payload to fall. The correct safe state therefore depends on stored energy, gravity, mechanical brakes, actuator characteristics, payload, environment, and identified hazards.

A useful design separates the emergency-stop path from ordinary mission and autonomy logic. Navigation software, AI inference, perception, fleet communication, or a high-level Linux application should not possess the authority to defeat an active safety stop. An independent safety controller, safety I/O path, or equivalent safety-rated architecture can maintain protective authority even if the main computing platform freezes, crashes, produces invalid commands, or loses communication.

The software representation of the E-Stop state should be explicit and deterministic. Typical states can distinguish normal operation, stop requested, stopping in progress, safe state reached, reset requested, and restart permitted. Transitions should occur only when their required conditions are satisfied. Modeling the behavior as a safety state machine prevents ambiguous combinations such as reporting normal operation while drive-enable outputs remain inhibited or accepting motion while an emergency condition remains active.

When an E-Stop request is detected, the first software responsibility is to prevent new hazardous commands from entering the actuation path. Queued trajectories, velocity references, manipulation commands, autonomous goals, and mission requests may need to be cancelled, invalidated, or ignored. Merely sending a single zero-velocity command is insufficient if another task can overwrite it during the next control cycle. Safety authority must dominate ordinary command generation until the stop condition is cleared through the defined process.

The transition itself should be bounded in time. Detection latency, software processing time, communication delay, drive reaction, mechanical braking, and physical stopping time all contribute to the total safety response. The safety requirement should therefore address the complete path from activation of the protective input to achievement of the required physical condition. Software timing is only one part of this chain, but uncontrolled scheduling or communication delay can compromise the overall stopping behavior.

A safe-state transition may involve several coordinated actions rather than one instantaneous event. The controller can first inhibit new motion references, request controlled deceleration, verify decreasing velocity, engage braking where required, remove torque or drive enable, and confirm actuator feedback. The exact sequence depends on the machine architecture. The important principle is that each transition step has defined entry conditions, expected completion criteria, timeout supervision, and a fallback if the expected response does not occur.

Feedback is essential because issuing a stop command does not prove that the robot has stopped. Software should observe relevant evidence such as wheel speed, joint velocity, brake status, drive state, torque status, contactor feedback, or other available safety signals. A commanded safe state and an achieved safe state are different concepts. The safety state machine should declare completion only when the required physical or controller-level conditions have been confirmed according to the safety design.

Timeout supervision protects the transition against actuators or communication that fail to respond. If controlled deceleration is requested but velocity does not decrease as expected, the system should not remain indefinitely in a "stopping" state. A timeout or progress monitor can escalate the response to a stronger protective action defined by the architecture. This creates a deterministic path from normal stopping behavior toward more restrictive fault handling when the preferred transition cannot be completed.

Communication loss must also produce defined behavior. In distributed robots, the E-Stop state may pass between safety sensors, controllers, motor drives, and supervisory computers. Messages should be protected by appropriate integrity, freshness, and timing mechanisms. Loss of communication must not be interpreted as permission to continue motion. Safety-related receivers should have a predetermined response when valid safety information is no longer available within the required interval.

Reset behavior requires as much care as stop behavior. Releasing the physical E-Stop device should not automatically restart the robot. The release normally removes one reason for remaining stopped, but software should continue to inhibit hazardous motion until reset conditions are satisfied. The system may need to confirm that safety inputs are healthy, faults are cleared, actuators are in acceptable states, communication is restored, and the operating environment permits controlled reactivation.

Restart should be deliberately separated from reset. A reset acknowledges or clears the safety condition, whereas restart authorizes operational activity to begin again. Combining them can create unexpected motion immediately after an operator releases an E-Stop. A safer software architecture requires an explicit transition through a ready or restart-permitted state, after which the normal control system can receive a new command. Previously queued motion should generally not resume silently.

Unexpected startup is another hazard that safe-state software must prevent. After power restoration, watchdog reset, processor reboot, software restart, or communication recovery, actuator outputs should default to a nonhazardous condition until initialization and safety checks are complete. The system should not assume that the state stored before reset remains valid. Safety inputs, controller health, drive status, configuration, communication, and relevant physical conditions should be re-established before motion authority is restored.

Fault handling and E-Stop handling should interact through a common safety-state concept even when their initiating causes differ. An operator pressing an emergency button, a watchdog detecting failed execution, a redundant channel reporting disagreement, or a critical sensor monitor detecting an unsafe condition may all require transition toward restricted or safe operation. Centralizing the resulting safety states helps ensure that different detection mechanisms do not produce contradictory actuator behavior.

Not every abnormal condition necessarily requires the same emergency response. The system safety analysis may distinguish controlled stop, protective stop, degraded operation, torque removal, brake application, or other minimum-risk behavior. Software should preserve these distinctions instead of routing every fault through one generic shutdown function. A carefully defined hierarchy enables the system to select the least disruptive response that still satisfies the corresponding safety requirement.

Diagnostic information should remain available without interfering with the protective response. The system can record the initiating source, timestamp, active operating mode, relevant fault codes, command state, actuator feedback, and progression through the safe-state transition. Such information supports later analysis and validation. Logging, however, must never delay safety action; critical outputs and state transitions take priority over diagnostic storage or communication.

Verification should exercise the complete E-Stop path rather than testing only the input variable. Tests should activate the stop during acceleration, steady motion, turning, manipulation, communication activity, and other relevant operating states. Engineers should observe command inhibition, transition timing, actuator response, final safe condition, reset behavior, and prevention of unintended restart. Repeated activation and release can also expose race conditions and state-machine defects.

Fault injection extends this verification by combining E-Stop operation with failures such as communication loss, frozen tasks, delayed control cycles, invalid actuator feedback, processor restart, or disagreement between redundant channels. The objective is to confirm that no credible single failure defeats the required protective behavior. These tests connect the safe-state implementation directly with the SW FMEA, FTA, runtime monitoring, watchdog, and redundant-channel mechanisms developed earlier in the safety lifecycle.

Structural verification is also relevant because safety-state decisions frequently contain multiple Boolean conditions. Conditions such as E-Stop status, drive readiness, brake feedback, communication health, reset request, and motion state may determine whether transition or restart is permitted. MC/DC-oriented testing can demonstrate that individual conditions independently influence critical decisions, while static analysis can identify unreachable states, suspicious control flow, invalid data usage, and implementation defects.

For robotic systems, the resulting architecture forms a clear authority hierarchy. Intelligent software determines desired behavior, normal controllers generate executable motion, safety supervision determines whether that motion remains permissible, and the emergency path retains authority to interrupt or disable physical actuation. This separation is particularly important when complex perception, planning, or AI software cannot provide the same deterministic assurance as the dedicated safety mechanisms surrounding the actuator path.

The safe-state mechanism should therefore be designed as a lifecycle function rather than a final emergency routine added near deployment. Hazard analysis defines what must become safe, safety requirements define response and timing, architecture establishes independent authority, implementation creates deterministic transitions, and verification demonstrates actual physical behavior. Changes to drives, brakes, payload, control software, communication, or operating modes should trigger review of the assumptions behind the safe-state design.

Within the attached structure, E-Stop software design and safe-state transition complete Chapter 09 after safety standards, SIL/ASIL determination, V-Model development, defensive programming, runtime protection, SW FMEA and FTA, redundant safety channels, static analysis, and MC/DC-based verification. This sequence expresses the central principle of safety-critical embedded software: hazards are analyzed first, defenses are layered throughout the architecture, and the final system must retain a deterministic means of bringing physical behavior under control when normal operation can no longer be trusted.

---

Author: Richard Minsoo Go

LinkedIn: Richard Minsoo Go