Status Manager Client/Server#

Introduction#

The Status Manager Client/Server component coordinates state transitions between DriveOS and registered applications. It manages system and application states such as:

  • Initializing

  • Entering and exiting SC7

  • Entering and exiting Sentry Mode

  • Resume

  • Reinit

  • Deinit Prepare

  • Deinit

It provides interfaces to register applications and to control or synchronize their transitions through these states.

Architecture and Behavior#

image1

Status Manager uses a socket interface to transfer state change and acknowledgment (ACK) messages between the server and client processes.

Status Manager Server#

  1. On QNX, the server uses NvDVMS APIs to get and set DriveOS states.

  2. On Linux, the server creates a separate thread to set and get notice for enter/exit SC7.

  3. The server manages state transitions for all registered applications through socket communication.

  4. State transitions follow the DriveOS state machine shown below:

image2

Status Manager Client#

  1. Each client uses the provided Status Manager Client interface to change app states according to messages from Status Manager server.

  2. Status Manager Client sends messages to notify the server when their state changes are complete.

  3. The Status Manager server sends acknowledgments to confirm that state changes were received and processed.

Usage#

  1. In a terminal window, start status_manager as the status manager server and set the parameter for the number of clients to be registered. As listed below, -n set to 2 means two processes of nvsipl_multicast will be launched(inter-process case)

    ./status_manager -n 2

    This example expects two instances of nvsipl_multicast to register (inter-process scenario).

  2. In another terminal window, start each nvsipl_multicast instance with the -7 option to register it as a client.

    ./nvsipl_multicast -t F008A120RM0AV2_CPHY_x4 -p "sipl_ipc" -7 &
./nvsipl_multicast -t F008A120RM0AV2_CPHY_x4 -p "ipc_enc" -7

  3. The nvsipl_multicast clients will remain running until they reach the Init_Done state, then send confirmation to the Status Manager. Once all registered clients report Init_Done, the Status Manager will prompt for the next state:

    All registered clients at InitDone state, Input for next state:
'dp': switch to deinit prepare state.
's': switch to suspend state.
'r': switch to operational state.
'lp': switch to low power state.

  4. The state could be switched by sending the corresponding command. For example, currently, all clients are in Init_Done state, and you could choose one command from “dp”, “s” , “t” or “lp” to type on terminal, so that the DriveOS/clients state will be switched to DeinitPare/Suspend/Operational/Low Power Mode state.

  5. Once status_manager gets the info that all clients are in a specific state, status_manager will wait for input to switch DriveOS/clients to the next state. After inputting the next state on the terminal, the DriveOS/clients state will be switched if the input state is valid according to the DriveOS state machine.

Constraints#

  • On QNX Safety systems, the socket path must be included in the allow_attached list of io_pkt_v6_hc_eqos_0_t. This configuration is found in the policy_debug_orin_gos_vm_safety.txt file.

  • The ReInit state is supported only in DriveOS versions 6.5.0.0 and 6.0.9.3 or later.

On this page