Ваши познания в CAN впечатляют, говорю совершенно без иронии!

Про возможности контроллера:

Примем ПО контроллера состоящим двух частей: системное ПО (СПО) и пользовательская диаграмма (ПД). Контроллер работает в бесконечном цикле, исполняя на каждом проходе по одному разу СПО и ПД. Предсказать продолжительность такого цикла невозможно, но его можно измерить, и получить измеренное значение из соответствующего регистра.
Почему невозможно предсказать:
Время работы СПО зависит от числа задействованных драйверов периферии (UART CAN Dallas I2C ВЧШИМ...) контроллера и нагрузки на них, от числа и характера обращений ПД к периферии и системным ресурсам контроллера и т.п. Время работы пользовательской диаграммы так же недетерминировано: один тот-же функциональный блок может исполнятся за разное время в зависимости от текущего контекста диаграммы. Колебания продолжительности цикла могут составить от единиц до десятков процентов.

Теперь немного упростим: возьмем CANNY 7, пусть наша диаграмма для него не занимается ничем другим кроме арифметики и передачи в CAN, никакая другая периферия не задействована. Пусть фильтры CAN настроены таким образом, что через них на прием не проходит никаких сообщений, то есть нагрузки нет даже на принимающую часть драйвера CAN.

Что получится в цифрах:
Текущая (но не единственно возможная) реализация драйвера CAN CANNY7 позволяет отправить максимум одно CAN-сообщение за один цикл диаграммы. Продолжительность цикла, в зависимости от объема арифметики в нашей диаграмме, составит от 1-2 мс при минимуме блоков, до ~30 мс при 4-5 сотнях блоков в диаграмме. Соответственно, если "затыков" по вине других узлов сети на шине не возникнет, то CANNY 7 сможет передать от ~30 до до ~1000 сообщений в секунду.

Что касается трафика CAN в автомобиле, то его генерирует как правило (если не в вообще всегда) несколько узлов сети, а не один и при необходимости генерации массированного трафика, можно использовать несколько контроллеров CANNY. То же и с приемом. Как правило, ни один узел в автомобиле, кроме узлов-маршрутизаторов и, возможно ЭБУ в в системах с высокой степенью централизации, не принимает весь трафик, все фильтруют. И для "переваривания" массированного трафика CANNY так же можно включать параллельно.

Жесткие ограничения на время отклика в CAN могут оказаться технически несостоятельны: во первых, шина может быть забита более высокоприоритетными сообщениями и отправитель будет долго и непрерывно проигрывать арбитраж, во вторых, CAN не гарантирует прием сообщения всеми адресатами, сообщение будет считаться успешно отправленными, если его примет хотя бы один узел, и если в сети есть маршрутизатор (gateway) то остальные узлы могут запросто "прозевать" посылку адресованную им.
Я использовал слова "жесткие" и "могут оказаться" потому, что теоретически возможно построить CAN-сеть и протокол верхнего уровня таким образом, чтобы минимизировать влияние перечисленных выше факторов.

Да, мы позиционируем свои контроллеры как универсальные и простые в освоении, но у любой универсальности есть рамки, хоть мы и попытались их максимально раздвинуть. Да, наш контроллер, если он в сети один - не лучший выбор для построения на нем ЭБУ ДВС, но есть масса уже решенных и потенциально решаемых единственным контроллером задач. Ну и разумеется, последствия неграмотного применения подобного нашему оборудования могут быть непредсказуемы, согласен с вами полностью.

Правильно ли я понял, что цель испытаний, методику которых вы изложили - определение производительности контроллера по отправке CAN-сообщений при различном составе и размере пользовательской диаграммы записанной в контроллер?

Если огрубленно, - то да, можно и так упростить (без потери общности, так сказать)...

С вашего позволения, я всё же уточню:

Правильно ли я понял, что цель испытаний, методику которых вы изложили - определение производительности контроллера по отправке CAN-сообщений при различном составе и размере пользовательской диаграммы записанной в контроллер?

По поводу "предельного трафика" - тут как раз все понятно, - все зависит от приоритетности пользовательских сообщений (на то и шинный рабитраж, в конце концов). Да и разработчики протокола советуют не напрягать шину больше чем 70% (правда, у них тоже, по-ходу эта цифра с потолка взялась..)