Copyright © 2024 | All Rights Reserved
The FlexRay Controllers State/Action tab is where the two FlexRay coldstart nodes within ICS hardware can be controlled and monitored. The tab is divided into Options, actions, and a node status table as shown in Figure 1.
Remember to select the correct Network above the tab before using any of the features.
Page navigation aids are included here to help with the long page length:
Options **** Actions **** Status Table **** States
The Options area (Figure 1:
) includes some startup and synchronization settings. Additional options for synchronizing to a database are located at the bottom of the Configuration tab.
Table 1: State/Action Options
| State/Action Option | Description |
|---|---|
Startup upon going online | On - ICS hardware will be the "leading coldstart node", so it will coldstart the FlexRay cluster after going online with VSpy. Off - ICS hardware will be a "following coldstart node", so it will begin in a listen state after going online with VSpy. A startup from an external FlexRay node is needed before frames will appear. |
Wakeup before startup | Startup upon going online must be ON before this feature will work. On - Each node within ICS hardware will transmit a FlexRay wakeup pattern on its wakeup channel after going online with VSpy, but before it does a coldstart. The wakeup pattern and channel are defined on the Configuration tab. A wakeup pattern must have at least two wakeup symbols to be successful. Off - ICS hardware will not send a FlexRay wakeup before doing a coldstart. |
Sync node frames to database upon change | This setting can synchronize Messages Editor Transmit frames to the Database frames. On - After selecting an ECU in the Node Name list, all transmit frames assigned to that node are deleted and replaced with all database frames from the ECU. The ECUs and their database frames come from FIBEX or ARMXL files loaded in Network Databases. Off - Node transmit frames are not forced to be synchronized to a database. |
FlexRay wakeup and coldstart can be confusing, so they are explained further here.
A FlexRay cluster is a collection of at least two coldstart nodes and usually some non-coldstart nodes too. Coldstart nodes can start or join FlexRay cycling, but non-coldstart nodes can only join cycling.
FlexRay cycling begins if at least two coldstart nodes are awake and then one of them does a coldstart A node wakeup can come from an external trigger OR from a FlexRay wakeup sent by a coldstart node. A FlexRay wakeup is a pattern of at least two wakeup symbols sent on only one channel at a time. The entire cluster of nodes will wake up after detecting a FlexRay wakeup pattern on their wakeup channel, assuming the nodes were not already awake from their external triggers.
ICS FlexRay hardware comes with two built-in nodes that can act as a simple cluster by itself or can be connected to a larger cluster of nodes. The cluster inside ICS hardware can be controlled on the State/Action tab by executing a Cluster Action (Figure 1:
) while Vehicle Spy is online.
Table 2: Cluster Actions
| Cluster Action | Description |
|---|---|
Start | Forces the ICS hardware cluster to coldstart, which can also get an external cluster to begin cycling if the external cluster is already awake. |
Stop | Forces the ICS hardware cluster to stop cycling, but this will not stop an external cluster that is already cycling. |
Restart | Stops the cluster first before doing a Start. |
Reconfigure and Restart | Reconfigures the ICS hardware cluster to the Configuration tab cluster settings, then forces the ICS hardware cluster to coldstart. |
There are many choices for a Node Action as described in Table 3 and most of them refer to specific controller states. Actions at this lower level are not usually needed unless trying to troubleshoot specific issues.
To perform a Node Action, select a node by highlighting its row in the status table, select a Node Action (Figure 1:), then click Execute to perform the selected action on the highlighted node.
It is strongly recommended to refer to state transition diagrams in the FlexRay Protocol 2.1A specification when using these node actions.
Table 3: Node Actions
| Node Action | Description |
|---|---|
Start | Forces node to coldstart. |
Stop | Forces node to stop cycling. If POC state is NORMAL_ACTIVE then forces node to stop after the current cycle is done. (i.e. Halt) If POC state is not NORMAL_ACTIVE then forces node to immediately stop even if the current cycle is not done yet. (i.e. Freeze) |
Restart | Stops the node first before doing a Start. |
Reconfigure and Restart | Stops the node, then reconfigures it to Configuration tab node settings, then forces node to coldstart. |
Set POC to Config | (POC means Protocol Operation Control, which is the FlexRay state control logic within the node.) Forces node state to DEFAULT_CONFIG or CONFIG depending upon when this action is attempted. Values are NOT configured until Node Action Perform Config of CHI and Msg Bufs is done. |
Set POC to Ready | Forces node to be ready to send a wakeup, begin a coldstart, or jump into a cycling cluster. |
Set POC to Wakeup | Forces node to send a wakeup pattern as defined on the Configuration tab. |
Set POC to Monitor | Forces node to monitor for wakeups and cycling, but not send any frames itself. |
Set POC to Halt | Forces node to stop cycling after the current cycle is done. |
Set POC to Startup | Forces node to coldstart an inactive cluster or jump into a cycling cluster. |
Set POC to Run | Forces a ready node to startup, otherwise does nothing. |
Set POC to Freeze | Forces node to immediately stop cycling even if the current cycle is not done yet. |
Set POC to Send MTS | Forces node to send a Media Access Test Symbol. The MTS is sent within a Symbol Window which is a cycle segment defined on the Configuration tab. Note: An MTS pulse is the same as a Collision Avoidance Symbol (CAS), but MTS is sent within a cycle and CAS is sent outside of a cycle. |
Set POC to All Slots | Forces node from single slot mode to all slots mode. Single slot mode is an optional feature to limit frame transmission during startup. |
Set POC to Reset Status Indicators | Resets node status flags that track coldstart and wakeup events. This action works only if the POC state is READY or STARTUP. |
Set POC to Clear RAMs | Clears all POC related RAM in the node to zero. This action works only if the POC state is DEFAULT_CONFIG or CONFIG. |
Perform Config of CHI and Msg Bufs | Forces node to configure its Controller Host Interface and message buffers. This action works only if the POC state is DEFAULT_CONFIG or CONFIG. If POC state is DEFAULT_CONFIG then settings come from "hardcoded" values stored within ICS hardware. If POC state is CONFIG then settings come from Configuration tab, Nodes branch settings. |
Each row in the status table (Figure 1:
) represents one node in the ICS FlexRay hardware. A Vehicle Spy Cluster Action affects both nodes, but a Node Action only affects the selected node in the table.
For each node, the status table shows the current logic state and timing location within the overall FlexRay cycle schedule. The status table also allows an ECU from a FlexRay database to be assigned to a node.
Table 4: State/Action Table
| State/Action Status Column | Description |
|---|---|
Key | Unused at this time. |
Node Name | Name of the node as defined on the Configuration tab, Node Settings, ECU Short Name. Also, an ECU can be assigned to the node here if an ECU database from a FIBEX or ARMXL file is already loaded in Network Databases. This quickly allows ICS hardware to simulate a FlexRay ECU. WARNING: If the option Sync node frames to database upon change is ON then making an ECU selection here will replace all transmit frames assigned to the node with database frames from the selected ECU. |
POC State | Current state of the FlexRay logic in the node. The many Protocol Operation Control states are described further in a table following this one. The node state can change due to external cluster connections or be changed directly by executing a Cluster or Node Action. |
Slot Counter A | Current slot of channel A. Counter resets to 1 at the beginning of each cycle then counts slots across the static and dynamic segments until the end of the dynamic segment is reached. |
Slot Counter B | Same counting logic as channel A, but this tracks channel B. |
Macroticks | Current macrotick within the current cycle. Counter resets to 0 at the beginning of each cycle. |
Cycle Cnt | Current cycle number that loops from 0 to 63. |
Rate Fix | Current Rate Correction Value calculated by the node to adjust its macrotick frequency. Allows the node to compensate for internal clock drift and stay synchronized to a cycling cluster. |
Offset Fix | Current Offset Correction Value calculated by the node to adjust its macrotick phase. Allows the node to compensate for internal clock drift and stay synchronized to a cycling cluster. |
There are many Protocol Operation Control states that define FlexRay logic in a node. It is strongly recommended to refer to state transition diagrams in the FlexRay Protocol 2.1A specification when trying to understand the flow of these states.
A lookup table is included here for convenience, but this does not replace requirements from specifications. Most of this information is copied directly from the FlexRay 2.1A specification then edited for brevity. The states are listed alphabetically.
Table 5: POC States
| POC State Name | Description |
|---|---|
ABORT_STARTUP | Exit cluster startup process for various reasons then get ready to try again by going to STARTUP_PREPARE. |
COLDSTART_COLLISION_RESOLUTION | Detect and resolve collisions between multiple simultaneous coldstart attempts of several coldstart nodes. |
COLDSTART_CONSISTENCY_CHECK | Leading coldstart node checks whether frames transmitted by other following coldstart nodes fit into its schedule. |
COLDSTART_GAP | Leading coldstart node stops transmitting its startup frame. All nodes integrating on leading coldstart node will stop their integration attempt. |
COLDSTART_JOIN | Only following coldstart nodes enter this state. Upon entry they begin transmitting startup frames and continue to do so in subsequent cycles. |
COLDSTART_LISTEN | Coldstart node tries to detect ongoing frame transmissions and coldstart attempts. A coldstart node still allowed to initiate a coldstart enters this state before actually performing a coldstart. |
CONFIG | Frame communication is stopped, all node configuration memory is accessible, and physical layer pins are set to their inactive state. Settings from the Configuration tab are applied. |
DEFAULT_CONFIG | Frame communication is stopped, all node configuration memory is accessible, and physical layer pins are set to their inactive state. Default settings "hardcoded" in the firmware are applied. |
HALT | Halts the node in preparation for reinitialization. |
INITIALIZE_SCHEDULE | This state is entered as soon as a valid startup frame has been received in one of the listen states. |
INTEGRATION_COLDSTART_CHECK | Only integrating coldstart nodes pass through this state. Verify clock can be corrected and leading coldstart node is still available. |
INTEGRATION_CONSISTENCY_CHECK | Only integrating non-coldstart nodes pass through this state. Verify clock can be corrected and enough coldstart nodes are sending startup frames that agree with the node's own schedule. |
INTEGRATION_LISTEN | Node waits for a valid startup frame or for a coldstart to be allowed. |
MONITOR_MODE | Node receives wakeups and frames, but does not send any frames itself. |
NORMAL_ACTIVE | Normal operation state following a successful startup. Node is synchronized to the cluster allowing continued frame transmission without disrupting other nodes. If synchronization problems occur, POC can transition to NORMAL_PASSIVE. |
NORMAL_PASSIVE | Node can receive frames, but not transmit frames due to synchronization problems to the cluster. If synchronization improves, POC can transition back to NORMAL_ACTIVE. If synchronization problems persist, POC transitions to HALT. |
READY | Node is ready to send a wakeup, coldstart a cluster, integrate into an ongoing cluster, or be configured again. |
STARTUP_PREPARE | Node prepares to listen for cluster activity. |
STARTUP_SUCCESS | This seems to not really be a POC state, but is actually a critical flag that must be true to enter the NORMAL_ACTIVE state. |
WAKEUP_DETECT | Node attempts to identify reason for wakeup collision detected in WAKEUP_SEND state then returns to WAKEUP_STANDBY. |
WAKEUP_LISTEN | Node prepares to quickly send a wakeup in a noise free scenario or waits a bit longer in a noisy environment. |
WAKEUP_SEND | Node sends wakeup pattern on wakeup channel defined on the Configuration tab. Node transitions to WAKEUP_DETECT if collisions are detected. |
WAKEUP_STANDB | Node is waiting to send a wakeup pattern. |
Page navigation aids are included here to help with the long page length:
Options **** Actions **** Status Table **** States **** Top of Page****
