CAN Node ID

Where did you get your ISO-15765 and ISO-14229 solution/software?
Your questions are supposed to be answered by your vendor.

-> Service ID 10 is sent on CAN Message ID Field
Very strange to me.

Where did you get your ISO-15765 and ISO-14229 solution/software?
Your questions are supposed to be answered by your vendor.

-> Service ID 10 is sent on CAN Message ID Field
Very strange to me.

Would like to learn more from our experts. Though I am no longer working on CAN products.

I want to know how CAN controller is able to differentiate CAN Message ID & UDS Services? Also, Does CAN Node ID Concept i.e., Does CAN Controller have Node ID, if yes, how it is useful and how and where we can assign node ID?

The CAN controller doesn't give a hoot about any protocol used. It just performs whatever ID filtering it supports based on whatever standard it supports. Then it hands over accepted frames and leaves it 100% to the source code to decide what to do next.

Some protocols and some CAN controllers makes it easy to set up the required filtering in hardware. Some protocols/CAN controllers means you have to let the controller accept lots of frames and let the software do further filtering.

What CAN controller are you using?
Does it's documentation mention UDS?

The CAN controller likely just filters on CAN message ID, and expects YOUR software/stack to do the other work.

( I am not a native English speaker. )

There are several CAN devices on a CAN-Bus.
Device-A, Device-B, Device-C.

Device-A is configured to only receive CAN-Messages with CAN-IDs 0xA10, 0xA50;
Device-B is configured to only receive CAN-Messages with CAN-IDs 0xB10, 0xB50, 0xB70;
Device-C is configured to only receive CAN-Messages with CAN-IDs 0xC10, 0xC50, 0xC90;

So there are CAN-Nodes:
A-0xA10, A-0xA50,
B-0xB10, B-0xB50, B-0xB70,
C-0xC10, C-0xC50, C-0xC90.

TP Layer (ISO-15765) is responsible to deliver UDS (ISO-14229) Data from one device to another, even the UDS data is more than 8 bytes.

DS Layer is on the top of TP Layer.

Device-A:
A-0xA10 for receiving Runtime data.
A-0xA50 for receiving UDS data. (Runtime Diagnostic is possible)

When Device-C wants to send UDS data to Device-A, it sends the UDS data (100 Bytes) with CAN-ID 0xA50 via TP Layer (more than 100 Bytes). Once Device-A's TP Layer receives the UDS data (more than 100 Bytes), TP Layer passes the UDS data (100 Bytes) to it's DS Layer. Device-A's DS Layer then analyzes the UDS data, fetches the Service-ID......

For automotive, in the real world, the UDS solution is decided by Car manufacturers, and controlled by very less solution providers. Since you have CANoe, I believe you should have a better way to learn UDS and ISO 15765-2.

Is it possible that one ECU will request another ECU for diagnostic data using Services? I think it is not possible. Tester needs to send Diag services for diagnosing the ECU. One ECU can't diagnose other ECU.

Please let me know does CAN ID '0' is valid or not?

I want to know how CAN controller is able to differentiate CAN Message ID & UDS Services?
It isn't, because there is nothing to differentiate. Some CAN frames are used to transport UDS via ISO TP, others are used for other data. A CAN frame is a CAN frame is a CAN frame.

Also, Does CAN Node ID Concept i.e., Does CAN Controller have Node ID,
How often do I have to tell you it doesn't before you start believing it?

Some CAN frames are used to transport UDS via ISO TP, others are used for other data.
This answer helps me a lot. Because, In ISO-14229-1 document I found 00-FF CAN Frames are reserved for various SERVICES.

Rest of the CAN Messages starts from 0x100 are used by application. I never saw a CAN message with an ID below 0xFF in my Project.

Just let me know CAN ID '0' is valid or not?

Because, In ISO-14229-1 document I found 00-FF CAN Frames are reserved for various SERVICES.
I'm pretty sure you're misunderstanding the document there. UDS has nothing to say about CAN frame IDs. It can't have, because it doesn't talk about CAN in the first place.