I am new to CAN communication and one of my tasks is to use a CANalyzer to learn what message IDs are being used for a product and what data is being sent/received.
The product has multiple nodes that can send/receive CAN messages. I know CAN messages are broadcasted to all the nodes, but the part I'm having a hard time determining is which node transmitted the message and which nodes received it.
So, for example, if I have 3 CAN nodes, is there a way I can determine that Node 1 sent the message and Node 2/3 are receiving the message?
Thank you in advance.
Generally, you can't know this by listening to the CAN bus alone. The same old story whenever someone asks about data on "CAN bus" is: what application layer protocol is it using? "CAN bus" doesn't tell you jack, it's just the specification physical and data link layers. The concept of identifying individual nodes does not exist on the data link layer, only on the application layer.
There's two possible ways for you to tell:
If you know the application layer used on top of the physical CAN bus and know that it uses node id, then you can tell which node that is sending what data by decoding the application-layer protocol.
On each node, you can sniff the Tx signal between the MCU and CAN transceiver with an oscilloscope. That one only goes active when a node is sending or ACK:ing. Most modern scopes has a CAN frame decoder feature, saving you the head ache of decoding the frames manually.
Related
I need to build a system that consist of:
Nodes, each mode can accept one input.
The node that received the input shares it with all nodes in the network.
Each node do a computation on the input (same computation but each node has a different database so the results are different for each node).
The node that received the input consolidate each node result and apply a logic to determine the overall result.
This result is returned to the caller.
It's very similar to a map-reduce use case. Just there will be a few nodes (maybe 10~20), and solutions like hadoop seems an overkill.
Do you know of any simple framework/sdk to build:
Network (discovery, maybe gossip protocol)
Distribute a task/data to each node
Aggregate the results
Can be in any language.
Thanks very much
Regads;
fernando
Ok to begin with, there are many ways to do this. I would suggest the following if you are just starting to tackle this architecture:
Pub/Sub with Broker
Programs like RabbitMQ are meant to easily allow for variable amounts of nodes to connect and speak to one another. Most importantly, they allow for transparency and observability. You can easily ask the Broker which nodes are connected and even view messages in transit. Basically they are a 'batteries included' means of delaying with a large amount of clients.
Brokerless (Update)
I was looking for a more 'symmetric' architecture where each node is the same and do not have a centralized broker/queue manager.
You can use a brokerless Pub/Subs, but I personally avoid them. While they have tooling, it is hard to understand their registration protocols if something odd happens. I generally just use Multicast as it is very straight forward, especially if each node has just one network interface, and you can extend/modify behavior just with routing infra.
Here is how you scheme would work with Multicast:
All nodes join a known multicast address (IE: 239.1.2.3:8000)
All nodes would need to respond to a 'who's here' message
All nodes would either need to have a 'do work' api either via multicast or from consumer to node (node address grabbed from 'who's here message)
You would need to make these messages yourself, but given how short i expect them to be it should be pretty simple.
The 'who's here' message from the consumer could just be a message with a binary zero.
The 'who's here' response could just be a 1 followed by the nodes information (making it a TLV would probably be best though)
Not sure if each node has unique arguments or not so i don't know how to make your 'do work' message or responce
I am looking to test a scenario, how my software will respond to disconnection of a particular CAN message coming from an external device. This external device will send many CAN messages in the bus, so I cannot control it to stop just a particular message.
Therefore, I am looking for a way in CANoe just to stop one particular CAN message coming into the bus.
Please need your suggestions here.
I tried to provide as much information here, if more is require kindly put in the comment. Thanks.
You would have to split the bus into two and configure CANoe to act as a gateway:
You need a network interface with two CAN channels.
You connect your DUT to one channel (say CAN2) and the remaining bus to the other channel (CAN1).
You then configure both busses in CANoe and add a node to both busses in the simulation setup.
This node should listen to all messages received on CAN1 and output them to CAN2 and vice versa.
If you want certain messages not to reach CAN2, you have to adapt the logic of this node.
Refer to this article in the Vector knowlegde base on how to setup a gateway between two CAN busses and how to control the message flow between those busses.
How does the sender on the CAN bus know that a node has not properly received the data?
I am currently learning the functioning of the CAN bus. Based on what I have seen so far a receiver drives the bus to a dominant state when it successfully obtains a packet and one receiving node is enough to accomplish this. However, in the event where the intended receiver does not successfully obtain the packet while others do, how is the sender made aware of the situation so that it can retransmit the packet?
Any help in providing some clarity on this topic is much appreciated. Thank you.
The sender can't know this unless you implement a higher layer protocol. The ACK slot in raw CAN frame allows sender to detect if it (not the receiver) has a bus problem. If the sender doesn't sample an ACK, it can conclude that "No one is hearing me in the bus. Maybe I'm physically disconnected or something is completely wrong."
For example in CANopen, it's generally receivers job to complain if an expected PDO packet doesn't arrive on time. Although it's not correct to talk about masters and slaves in CAN bus, a device you assign a master role can be programmed to expect periodic PDO report packets from its slaves, and can rise an error flag if they don't arrive in expected time window.
I have a virtual socketCAN network. How do I block a particular ID from being sent on the network?
If a node is connected to a CAN bus, at the lowest level it cannot be prevented from sending any message externally.
However, there are 3 things that can be done:
Add a gateway - a device that separates the bus into multiple small buses and passes messages from each sub-buses to the others, it does not prevent any node from sending a message, but it will not pass it to the others. This solution have a few clear drawbacks - it requires a separate device with multiple CAN interfaces (up to the number of nodes on the bus), it adds a delay for each message, and it renders the ACK bit unusable.
Apply filters for the received messages in each node. Again, this will not prevent sending the message, but will drop the load on the nodes. Most CAN controllers have hardware support for filtering by ID or a bit mask of ID.
There are some CAN controllers that can block the sending of messages, again, this will require adding such controller and setting it up for each node in the CAN bus.
I would like to hear your insights about an IoT data ingesting case. In AWS IoT hub, thing shadows are virtual representation of physical ones. What i understood from the figure below is whenever a thing sends a data to platform via a message broker, thing shadows and rule engine portions get the same sensor data concurrently and process it.
Are my conclusions correct ?
Things shadow system is subscribed to message broker and gets sensor data, updates their shadow actors. Shadow side is also responsible for storing sensor data such an event sourcing mechanism.
The thing shadow system does not perform any rules, it is just for performing event sourcing and keeping last known state in virtual thing actors.
The same sensor data also is an inbound data to rules engine. Rules engine is just and ECA (event condition action) type system that handle streaming data and decides what it will do with them. This means every incoming data eventually will be processed in rules engine portion.
Below are my comments to your conclusions.
What i understood from the figure below is whenever a thing sends a
data to platform via a message broker, thing shadows and rule engine
portions get the same sensor data concurrently and process it.
Changes in the thing shadow can trigger an action registered in the rule engine. There are specific topics associated with a thing shadow that you can subscribe the rule engine to, in order to perform one or many action(s) in response.
Things shadow system is subscribed to message broker and gets sensor
data, updates their shadow actors. Shadow side is also responsible for
storing sensor data such an event sourcing mechanism.
You can update the device shadow by using the REST API, or dedicated MQTT topics to publish on specific shadow topics. The shadow does not constitute an event-sourcing system by itself, but a representation of the data model associated with a physical device, as you said.
You can however create a rule that listens for changes on one or more shadow instances, and register the changes into DynamoDB for instance, in a time-series manner. You'll then have an event-sourcing system allowing you to store the previous states, or changes, sent by a device during an arbitrary amount of time.
The thing shadow system does not perform any rules, it is just for
performing event sourcing and keeping last known state in virtual
thing actors.
The thing shadow keeps the desired and reported state of a physical device in the cloud. It does not execute rules, but emits messages on MQTT topics when events happen within the shadow. These messages can then be captured by the rules engine to execute actions.
The same sensor data also is an inbound data to rules engine. Rules
engine is just and ECA (event condition action) type system that
handle streaming data and decides what it will do with them. This
means every incoming data eventually will be processed in rules engine
portion.
The rules engine does not listen by default on an MQTT topic, and hence, on data sent by devices to the Device Gateway. You must register in the rules engine the topics you'd like to listen to along with their associated actions.
Other than that, the rules engine allows you to describe your rules in ANSI SQL, meaning that you are able to specify the origin of your data (the FROM in your SQL statement), the specific fields in a JSON payload you are interested in capturing (SELECT), and an optional condition specifying on what condition the rule should be triggered (WHERE).
An example of a rule listening on the fictive topic device/+/telemetry and interested in capturing all the fields in the received payload would be :
SELECT * FROM device/+/telemetry
Note how the + can be used as a placeholder for any device identifier for instance.