The safety framework implemented within the Uli SDK is engineered to ensure the proactive detection and decisive handling of emergency conditions, thereby safeguarding operational integrity. This system is designed to trigger an emergency state automatically upon the detection of critical faults—such as a safety critical application entering an error state or a complete loss of contact—as well as through direct command by an operator, e-stop pressed. The foundational pillars of this framework are reliability and redundancy. To guarantee uninterrupted monitoring and communication, the architecture mandates redundant entities for assessing safety conditions and redundant routes for propagating health status and operator-initiated emergencies. This safety layer is intrinsically tied to subsystem operations, enabling immediate, appropriate responses while ensuring the operator is kept continuously informed through a consistent feedback loop.
To execute this comprehensive safety strategy, the Uli SDK relies on its architecture of interconnected services working in concert. This ecosystem comprises the Health Reporter, the Health Monitor, the Management (Life Cycle) service, the Subsystem State service, the core Safety Service, and the Safety Client Service. Together, these components form a resilient and responsive system responsible for monitoring, reporting, and acting upon all safety-critical events.
Overview
The graph below shows the interactions (indicated by arrows) among the participating services:
The arrows are explained below:
1 e-stop state routed to Safety Client
2 emergency decision commanded to Subsystem State Client
3 e-stop state reported to Safety
4 Safety triggers emergency to Subsystem State
5 Subsystem State Client triggers emergency to Subsystem State
6 health summary reported to Safety Client
7 health summary reported to Safety
8 Health Reporter sends application health status to Health Monitor
9 Subsystem State requests state transition to Management
10 application error status reported to Health Reporter
The distribution of responsibilities between the Safety Client, Safety Service, and Subsystem State Client is intentional, establishing critical redundancies within the safety framework. This layered approach guarantees redundant reporting of the e-stop state, redundant determination of an emergency condition, and redundant pathways for commanding the subsystem into an emergency state, thereby ensuring that a single point of failure will not compromise the system's ability to enter a safe state.
The following sections will provide a detailed examination of the specific roles and responsibilities of each of these services.
Lifecycle Management
At the heart of each safety-critical application is a dedicated state machine, inherited from the Management Service, that provides robust lifecycle management. This state machine dictates the application's operational mode through four distinct states: INITIALIZE, READY, FAULT, and EMERGENCY. While the INITIALIZE state handles startup procedures and the READY state executes normal commands and operations, the safety framework is primarily concerned with the latter two states.
Below are the actions in each of the state:
| State | Actions |
| INITIALIZE | Perform initialize procedures and tests |
| READY | Execute commands and operations |
| FAULT | Report error through the Health Reporter |
| EMERGENCY | Perform emergency procedures |
Within this lifecycle, the FAULT and EMERGENCY states are integral to safety enforcement. An application enters the FAULT state when it encounters an unrecoverable internal error. Its sole action in this state is to report an ERROR status through its Health Reporter service, ensuring the subsystem-wide Health Monitor service is immediately aware of the anomaly.
Conversely, the EMERGENCY state is entered in response to a subsystem-level directive from the Subsystem State service. In this mode, the application ceases normal operations and executes a predefined set of emergency procedures designed to mitigate the critical condition and bring its domain to a safe state.
The following table is the state transitions and their triggers:
| Transition | Trigger |
| 1 | Initialization procedures are performed and tests are successful. |
| 2 | Unrecoverable faults occur while performing the initialization procedures and tests. |
| 3 | Receive the INITIALIZE state transition request. |
| 4 | Unrecoverable faults occur while executing commands and operations. |
| 5 | Receive the SET EMERGENCY state transition request. |
| 6 | Receive the CLEAR EMERGENCY state transition request. |
The transitions between these states are governed by specific triggers, with all state transition requests being issued by the Subsystem State service. An application moves from INITIALIZE to READY upon successful startup, but will enter the FAULT state if initialization fails or an unrecoverable error occurs during normal operation. A RESET request is required to move an application out of the FAULT state, forcing a re-initialization.
Critically, a SET EMERGENCY request will transition a healthy application from READY to EMERGENCY, while a CLEAR EMERGENCY request will return it to the INITIALIZE state, to perform initialization procedures and tests before allowing normal operations to resume.
Health Status Reporting and Monitoring
The foundation of the safety framework's health monitoring capability lies within its safety-critical applications, each of which integrates a Health Reporter service. The primary function of this service is to continuously report its operational status to the subsystem's central Health Monitor service. This reporting mechanism is pivotal in the detection of fault conditions. When entering FAULT state, the Life Cycle Management service immediately signals a health status error to the Health Monitor. In response, the Health Monitor escalates the issue by setting the subsystem's overall Health Summary to an ERROR state. This ERROR status is then propagated to the core Safety Service during its routine query of the Subsystem Summary, triggering the system-wide emergency handling procedures.
Subsystem State
Operating at the subsystem level, the Subsystem State service functions as the central orchestrator for the lifecycle of all safety-critical applications. It is responsible for monitoring, commanding, and synchronizing the state transitions of the individual Management services within its domain. By centralizing this authority, the service ensures that all applications respond cohesively to system-wide operational changes, providing a unified and predictable state across the entire subsystem.
The Subsystem State service acts as the primary interface for both operator-initiated, via the Subsystem State Client, and commands from the Safety service. For instance, when an operator issues a RESET request, the service translates this into a command that directs all managed applications to re-enter their INITIALIZE state. Critically, the command to enter the EMERGENCY state can be triggered by two sources: manually by an operator via a SET EMERGENCY request, or automatically by the Safety service upon detection of a critical system-wide fault. In either scenario, the Subsystem State service ensures that all safety-critical applications are immediately commanded to transition into their EMERGENCY state. Recovery from this state is a deliberate action; an operator must issue a CLEAR EMERGENCY request after the underlying condition has been resolved, allowing the system to return to a normal operational state.
Safety and Safety Client
Positioned on the operator side of the architecture, the Safety Client service acts as a primary interface for monitoring and initiating safety actions. It is responsible for two key inputs: it directly receives the status of the operator's e-stop control, and it actively queries the Health Monitor service to obtain the Subsystem Health Summary. Upon detecting a fault within this summary or receiving an e-stop signal, the Safety Client service initiates a critical response by triggering the Subsystem State Client to issue a SET EMERGENCY command to the Subsystem State service.
In parallel with this action, the Safety Client also reports the e-stop state directly to the central Safety Service, providing it with crucial, operator-initiated data for its own assessment of the system's safety condition.