I am just venturing into the CAN Bus communication, I know that the identifier might have 11 or 29 bits, which is a good amount.
However, a doubt just came into my mind, in a robust system that has many peripherals on it, is there some approach to remediate and/or avoid in case two or more peripherals have exactly the same ID?
AFAIK, CAN-based systems are usually not designed to be plug-and-play, so the ID collusion does not happen in real world. The systems are static, all the nodes are known in advance, in the design phase, with all the frames needed to achieve the wanted functions.
In Automotive world, the OEM will create a document with the list of all the frames and the list of all the signals. The frame's ID will be different by design. Usually, the frames with very important information will use low ID, which have a high priority, the frames with less important information will use higher ID, which have a lower priority.
The suppliers of ECU will just use the frames ID described in the OEM specifications.
Take a look at this post https://os.mbed.com/forum/electronics/topic/28241/?page=1#comment-59250 maybe could answer your question.
you have likely learned that a CAN message has an identifier, and up to 8-bytes of data (ignoring some of the other bits in the stream). It is essential that no two nodes send the exact same identifier, or they can't tell one from the other and it is about the only way in which nodes "collide" and the data is lost. The data is quite limited to help minimize the "blocking time" that would prevent a higher priority message from being sent.
CAN arbitrates non-destructively - so while it is a party-line, the arbitration ensures that the highest priority packet is delivered successfully, and the lesser priority messages automatically pause until the network is idle and then they try again. With a true party-line, the rate of collisions increases so rapidly that some argue you cannot load the channel more than about 30%. With the arbitration of CAN, you can achieve throughput at about 100% bus load (the lowest priority messages may never be sent in such a situation).
If you need to send more than 8-bytes, you can either define new messages for fragments of the data, or you could "serialize" a big blob using a single identifier, typically by embedding a sequence number in each packet (and the remaining bytes in the packet have the data).
