CANopen NMT State Machine
How to use Hierarchy Beneficially
From the CANopen [1] homepage: “CANopen is a CAN-based higher layer protocol. It was developed as a standardized embedded network with highly flexible configuration capabilities. CANopen was designed for motion-oriented machine control networks, such as handling systems.”
Because many small micro-controllers often have a CAN controller on-board the implementation of the CANopen communication interface is possible without high cost. On the other hand the implementation has to be optimal regarding required CPU performance and code/ram size.
The application layer profile is defined in the CiA Draft Standard 301. One page 75 of the standard the NMT state machine of a device is shown. All CANopen devices must support the CANopen network management (NMT) slave state machine. The NMT state machine defines the communication behavior of the CANopen device. The CANopen NMT state machine consists of an Initialization state, a Pre-operational state, an Operational state and a Stopped state. After power-on or reset the device enters the Initialization state.
The original state diagram is not hierarchical. If you implement the machine following the standard it will be correct, but you will notice sooner or later that the transitions ResetNodeInd and ResetComInd have to be considered in several states. If you want to change your design after the implementation started it is probably too late. You might have to re-write and re-test many lines of code.
The diagram below is not directly modelled after the standard. It is different in two places:
-
-the design is hierarchical. The additional parent state AfterInitialization was added.
-
-the transitions marked in red were modelled only once leaving the new parent state. This makes the model simpler to understand and also the implementation better to understand. The two transitions needs to be handled only in state AfterInitialization.
The following code fragment shows the structure of the generated code. The hierarchical structure is visible in the lower part of the code. If an event was not consumed from the inner states of AfterInitialization it is handled from the parent.
The generated code is clear and easy to understand which makes validation and verification much simpler in comparison to other state machine generators which rely on complex frameworks.
...
case ResetCommunication:
...
case AfterInitialization:
switch(instanceVar->stateVarAfterInitialization){
/*
Code for transitions starting from inner states
*/
case Stopped:
....
case Operational:
...
case PreOperational:
...
}
if(evConsumed == 0U){
/*Event not consumed by inner states, handover to parent */
if(msg==(CANOPEN_EVENT_T)ResetNodeInd){
...
elseif(msg==(CANOPEN_EVENT_T)ResetComInd){
...
}
Download the free demo version and try out the codegenerator using your own designs!
[1] CANopen is registered Community Trademarks of CAN in Automation e.V. See www.can-cia.org
