How do I efficiently build a CAN Gateway?
With the recent introduction of the new Raptor GCM48-5605B-1906, containing 6 separate CAN channels, we have been receiving significantly more interest lately in building gateway software within Raptor. Gateway applications function by bridging the messaging between communication link(s) in a system, where the gateway module may or may not perform modifications on the messages depending on its function / requirements.
Gateways are useful for solving many system issues such as vehicle architecture challenges, backwards compatibility concerns, or even creating isolation for security reasons. In this user tip we provide tips for assuring rapid development and recommendations for ensuring efficient implementation and operation.
Limit Message Gating to Specific Messages If Possible
Many times the limiting factor for a gateway is simply the number of messages it can pass between the different communication links (CAN buses). This issue is highlighted especially in the case where there is processing done on messages. Limiting the processing to specific messages if possible is desired. If you have a limited number of messages you need to pass through, limiting your implementation to those will significantly reduce the workload for the ECU. You can use ID masks to filter the message received by a CAN block. In this example only message ID 0x4D1 will be received by this CAN RX Raw block.
If you need to gateway several messages (or an entire bus of data) leave the mask open (0x0) and use CAN Rx/Tx Raw blocks.
Typically, to assure that messages are being transferred as they arrive you will want to use CAN Mailbox Triggers, placing the blocks above inside a triggered subsystem connected to the Mailbox Trigger.
Use a Beacon Message to Confirm Configuration and Wiring
When setting up a system with many CAN channels, such as the GCM48 with six, it can be useful to be able to verify, when looking at the traffic on the bus, what CAN channel is connected where on each ECU. For this reason, we often add a calibratible ‘beacon’. This can be turned on and when showing the CAN traffic, in Raptor-CAN or CAN King, with ASCII display mode you will see ‘__CAN1__’ for instance. Allocating the difference beacon CAN Identifiers among your modules can allow you to confirm your configuration and wiring.
Gateway Application Example
In this section, a gateway example with a model sample that can be downloaded here so you can follow along, with the overall gateway structure detailed alongside useful tips.
In many applications several messages (or an entire bus) need to be gatewayed, and specific messages need to be intercepted so specific signals can be measured or modified before being transmitted. The example below shows one method to implement this type of gateway.
First, use a CAN trigger block to trigger a subsystem with a CAN Rx Raw block with an open mask.
Tip: To help with troubleshooting, add counters in Rx/Tx Triggered subsystems to verify the code is executing during runtime.
In this architecture all message IDs are received and logic in the ‘Intercept Certain IDs’ subsystem determines if each ID received will be intercepted or transmitted on the outgoing bus unchanged.
The CAN2_CAN3_InterceptMsgID corresponds to a predefined message ID that is to be intercepted. When this ID is received the unchanged message subsystem above is not enabled and instead the Modify Msg subsystem is enabled. In this example there is only one predefined ID each incoming ID is compared to, but this approach could be replicated with as many message IDs as needed. This logic also has a CustomID feature which allows the user to select specific IDs at runtime to block or input custom values; this will be explained more in depth in a later section.
The ‘Modify Msg’ subsystem contains the logic below. This is the next level of determining if the intercepted message is a hard coded message or a custom ID selected by the user at runtime. For now we will focus on the hard coded message.
In the ‘Hardcoded Message Intercepts’ subsystem is the logic to actually intercept the values. An efficient approach is to use CAN Rx/Tx Raw blocks with DBC Unpack/Pack blocks. Alternatively the CAN Tx/Tx Message blocks can be used, but they require more ECU overhead.
Details to note here are the _InterceptEnbl Adjustment, and _numberTimesTriggered measurement. In this case the adjustment is used to intercept existing data for each signal and replace it with a control value. The _numberTimesTriggered measurement is especially helpful for troubleshooting if this subsystem is running since it only runs when the calibrated ID is received.
- If the ECU supports receive (RX) and transmit (TX) queues, in the CAN Definition block, take care to size these to worst case conditions. If these are sized too low, you will see CAN queue overruns (in System->CAN in Raptor-Cal) that will result in dropped messages. If they are sized too high then excess RAM will be consumed which can be a limiting factor elsewhere in your software.
- Because the DBC message-based CAN transmit and receive blocks automatically parse the data fields based on the DBC format, they use more CPU processing power than the raw CAN transmit and receive blocks. For most pass-thru gateway situations, the raw blocks provide the most efficient implementation because they don’t pack or unpack the data.
- If you are using the raw transmit and receive blocks for gating your messages, but you need to receive-modify-transmit some messages, you can use the DBC pack and unpack blocks to handle the modification. An example of this can be seen in the gateway example model from this tip.
- GCM48 and GCM80 may have issues gating heavy bus loading due to the limited processing power of the microprocessor inside. It will be especially important to minimize the messages that are gated.