That’s not what I am saying, it was rather the opposite. Your trim controller is likely part of a real-time system interfaced over a network with predictable temporal properties where a highly stateful protocol like TCP is unlikely to be beneficial. If you are defining the interface yourself, which I understood is the case, then it certainly doesn’t make sense.
You mentioned Python, so maybe it’s best to start with a simple demo that runs on your desktop first, and then apply the experience to your embedded system: https://pyuavcan.readthedocs.io/en/latest/pages/usage.html
Roughly speaking, yes. This can be seen as a manifestation of Publish–subscribe pattern - Wikipedia
Correct. But observe that UAVCAN strongly advocates in favor of higher-level interfaces. Do not send some 16-bit values; send the information that they represent. For example, instead of a raw 16-bit ADC reading, communicate the quantity that it relates to; say, it is some angle, which is represented in radians, so in your case the 16-bit value becomes, say, a 32-bit floating point. The guide speaks about this at length.
When you define a message type, you add something like @extent 1024 * 8
at the end. The number is the maximum possible size of a serialized message (1024 bytes in this example). You multiply the maximum size by frequency by the number of publishers, you get the network load. Divide that by the maximum throughput of your transport, you get network utilization. While working on the DS-015 standard, we put together a spreadsheet for assessing the feasibility of our design for Classic CAN networks; you may find it useful:
https://docs.google.com/spreadsheets/d/1xSBcnnqbHBEZfFg4cqiS1weXHwX3X0MFWpW1WcEBIds/edit
You can easily adapt the spreadsheet for your transport.
You mentioned that messages have “addresses”, right? You were very close. These things are called not “addresses” but “subjects”, or actually “subject-IDs”. Your first trim controller would take a subject-ID, say, 6000, and the other one would be 6001. You choose the numbers arbitrarily but every component of your vehicular network needs to be configured correctly such that it is aware of which subject-IDs to use for which data.