• <xmp id="om0om">
    •
    • <table id="om0om"><noscript id="om0om"></noscript></table>
  • Compute Graph Framework SDK Reference  5.8
    •All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Macros Modules Pages
    SSM Samples

    The NVIDIA Driveworks SDK includes sample SSM applications you can use as a starting point for developing, porting, and optimizing your applications. These samples are provided as binaries you can run and source code that you can modify to meet specific use cases.

    Precompiled samples can be found under 

    /usr/local/driveworks/bin

    The source code can be found under 

    /usr/local/driveworks/samples/src/ssm

    Prerequisites

    To ensure that the sample source code is in directory with read/write permissions, run the following command to copy the sample source code to a desired directory 

    /usr/local/driveworks/samples/src/ssm/setup_demos.sh ${HOME}

    The SSM sample sources include five applications to demonstrate SSM’s features. Scripts to build the applications are also included.

    Building the Demo Applications

    Use the build.sh script to build the samples 

    cd ${HOME}/ssm/samples
./build.sh

    Makefiles are also included with the samples to ease the process of calling the parser and building the applications.

    To run parser after modifying ssm JSON files 

    cd ${HOME}/ssm/samples/demo1
make parser

    To build a specific demo 

    cd ${HOME}/ssm/samples demo1
make parser
make

    Running the Demo Applications

    To run a specific demo after building the application 

    cd ${HOME}/ssm/samples/demo1
./bin/demo1

    Samples

    Demo 1

    This demo demonstrates how state transitions can be executed over a simple state machine. 

    cd ${HOME}/ssm/samples/demo1
    • The hierarchy structure for the demo is defined in sm1.json.
    • Notice that the demo has one state machine called the “ssm”.
    • It has four states “Degrade, NormalOperation, Standby, UrgentOperation”.
    • The state transitions are defined against the transition key.
    • As part of the build process the SSM parser converts JSON file into C++ autogenerated code (see src/sm1 and include/sm1 directories).
    • The class defined in SSMClass.hpp derives from the autogenerated code.
    • The framework starts a tcp socket server listening to port SSM 6072
    • The framework initializes the state machine with five initialization phases: PRE_INIT, INIT, POST_INIT, PRE_READY, READY
    • All the initialization phases have associated virtual function handlers; developers can overload these handlers with their own
    • SSM framework instructs the system to enter the state machine at which point ssm state machine enters its first state as defined in the JSON file.
    • SSM enters standby first and proceeds to the subsequent states.

    Demo 2

    This demo demonstrates how a parent's state change can impact the execution of its child state machines. The demo also demonstrates how a reset functionality can be executed on the parent state machine. 

    cd ${HOME}/ssm/samples/demo2
    • The hierarchy structure for the demo is defined in sm2.json.
    • This demo contains three stateful state machines (SESMs): SSM, SM1, SM2
    • SSM is the head state machine with SM1 are SM2 are the child state machines
    • Notice the structure of the parent child relationship defined as part of the hierarchy key
    • SM1 gets active when SSM is either in the Standby or in Degraded state
    • SM2 gets active when SSM is either in the NormalOperation or in UrgentOperation
    • SSM enters standby state and when SM1 enters its stat state
    • As the iterations proceed, SM1 enters its subsequent states
    • SSM the enters the NormalOperation state and SM2 enters its start state.
    • SM2 sends a reset message to SSM; SSM should display “###### INIT RESET ######”
    • SSM resets its init state and enters to its start state; Standby at which point SM1 activates while SM2 deactivates
    • SSM should continue going from Standby to urgent operations

    Demo 3

    The sample demonstrates the performance of state machine framework. 

    cd ${HOME}/ssm/samples/demo3
    • The hierarchy structure for the demo is defined in sm3.json.
    • This demo contains three stateful state machines (SESMs): SSM, SM1, SM2
    • SSM is the head state machine with SM1 and SM2 are its children
    • SM1 actives when SSM runs in either Standby or Degraded states
    • SM2 actives when SSM runs in either NormalOperation or UrgentOperation
    • SSM should enter standby state and continue to urgent operations
    • Check the logs

    Demo 4

    The purpose of the demo is to show how state machine initialization can be deferred as per the need 

    cd ${HOME}/ssm/samples/demo4
    • The hierarchy structure for the demo is defined in sm4.json.
    • This demo contains four stateful state machines (SESMs): SSM, SM1, SM2 and SM22 and five stateless state machines (SSMClone objects)
    • SSM is the head state machine with SM1 & SM2 as its children
    • SM1 actives when SSM is either in Standby or Degraded state
    • SM2 actives when SSM is either in NormalOperation or UrgentOperation
    • SM2 has a child SM22
    • SM22 actives when SM2 gets the control
    • This demo runs in two steps:
    • Step 1
      • The primaryInitList should contain the following SM22, SM2, SM1, 1, 2, 3, 4, 5
      • State machines SM22, 3 and 4 are removed from the primary list; their initialization is deferred.
    • Step 2
      • System startups up
      • SM1, SM2, 1, 2, 5 initialize first
      • The deferred state machines (SM22, 3 and 4) are initialized when SSM is in standby
      • Once initialized all the state machines run as expected

    Demo 5

    The purpose of the demo is to show how SSM framework allows state machines to transmit data amongst each other. 

    cd ${HOME}/ssm/samples/demo5
    • The hierarchy structure for the demo is defined in sm5.json
    • You should notice three state machines: SSM, SM1, SM2
    • SSM is the head state machine with SM1 and SM2 as its children
    • SM1 actives when SSM is either in Standby or in Degraded state
    • SM2 actives when SSM is either in NormalOperation or in UrgentOperation
    • After Init, SSM enters Standby state while SM1 activates
    • SSM should continue going from Standby to urgent operations
    • This demo demonstrates how state machines send data to each other
      • #### Received Data SM1 #####
      • #### Received Data SM2 #####
      • #### Received Data SSM #####
    • SM1 sends data to SSM
    • SSM sends data to SM1
    • SM1 sends data to SM2

    Demo 6

    This demo shows how users can use the SSM framework's state change event mechanism to trigger state changes at the appropriate time 

    cd ${HOME}/ssm/samples/demo6
    • The hierarchy structure for the demo is defined in sm6.json
    • The head state machine has a single child: 'genericClone'
    • The child state machine is a special clone interface; it can connect to any head state machine
    • SSM is the head state machine; it orchestrates the initialization
    • Notice that the genericClone object is set with a safety module.
    • Genericclone executes the safety module handler whenever a state change event is triggered
    • GenericClone interface calls the safety module and passes the relevant information
    • SSM locks the framework from executing other state changes until GenericClone acknowledges a state change complete
    • Notice 'bool GenericClone::globalStateChangeComplete()'; this is the API that informs SSM that a state change is complete
    人人超碰97caoporen国产