Можно ли определить один AUTOSAR Runnable для многих компонентов на задачу?

Question

Вот сценарий...

Мне нужно для каждой задачи 2 разных runnables...

- First : to receive data at specific times at the beginning of the task.

- Second: to send data at specific times at the end of the task.

каждый из этих исполняемых модулей должен предоставлять данные для различных процессов компонентов в начале задачи (такой же, как неявный режим приема для интерфейса получателя отправителя, но с некоторой фильтрацией, которая не может быть достигнута с использованием атрибута фильтра), или отправлять данные только в определенное время в конце задач.

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

Я новичок в AUTOSAR, поэтому, пожалуйста, дайте мне знать, что может быть лучшим решением для этого.

Answer 1

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

Вот что я вижу много за последние годы. Многие разработчики, работающие с коммуникационными стеками, не понимают функций и фактически реализуют что-то в SWC, которое фактически доступно и выполняется с годами в ComStacks ... даже в стеке Vectors CANbedded (в IL (Interaction Layer)). Это делает SWC настолько зависимыми от связи, что вероятность изменений очень высока.

Обработка тайм-аута обрабатывается IL и AUTOSAR Com в соответствии с PduTiming SystemDescription/EcuExtract (и старыми файлами DBC), режимом передачи IPDU и свойствами передачи сигнала.

Режимы передачи IPDU: * NONE -> запускается не Com, а вручную Com_TriggerIPDUSend() * PERIODIC -> циклически запускается Com в соответствии с заданным периодом времени * DIRECT -> срабатывает при "событии" настроенных сигналов (TRIGGERED *)
* MIXED (PERIODIC + DIRECT) -> "EventPeriodic" .. это также включает в себя возможную MDT (минимальная задержка по времени)

Просто чтобы назвать некоторые значения свойств сигнала: * PENDING - в и IPDU TxMode MIXED это не вызывает событие, поэтому ожидает до следующего события передачи (или только со следующим циклом сообщения) * TRIGGERED - как бывший DBC "OnWrite" * TRIGGERED_ON_CHANGE - как бывший DBC "OnChange", поэтому только если значение изменилось по сравнению с последним значением

AUTOSAR Com также может контролировать получение IPDU в соответствии с настроенным периодом времени.

IpduGroups можно использовать для включения / выключения передачи IPDU и мониторинга IPDU RxDeadline (обработка тайм-аута).

Итак, в конце концов, большинству SWC на ​​самом деле не нужно заботиться о времени приема / передачи... они просто пишут / читают в / из своих портов, и все.

Еще одна полезная функция - обработка SignalGroup, которая снимает бремя поддержания синхронизации сложных данных (структур). Раньше кто-то, вероятно, блокировал прерывания до тех пор, пока все данные не будут обновлены в сообщении.

Защита E2E теперь может обрабатываться трансформаторами E2E.

Таким образом, SWC могут быть смоделированы на уровне VFB (виртуальной функциональной шины), а затем сопоставлены с ECU. Их соединения остаются прежними, но если SWC обмениваются данными только через Intra-ECU через RTE в том же ECU или через Inter-ECU через границы ECU через ComStack, это совершенно не имеет значения для SWC. SWC могут использовать dataReceivedEvents или dataReceiveErrorEvents для получения информации об ошибках приема или приема (например, Timeout) и dataSendCompletedEvent о завершении передачи. Или же они могут просто "опросить", проверив код возврата RTE вызовов Rte_Read/Write.

Вместе с возможностями RTE DataTransformations, Data/PortMapping и преобразований, будет гораздо проще иметь реконфигурируемое ПО без постоянной замены SWC.

Также будет легче перемещать SWC, независимо от того, перемещаете ли они их на другое ядро ​​на многоядерном процессоре (с MultiCore OS и MultiCore RTE) или перемещаете функции с датчиков на высокопроизводительный центральный ECU.

Отношения маршрутизации шлюза на уровне PDU даже не нуждаются в каких-либо SWC, это можно сделать путем настройки отношений маршрутизации PduR и обмена здесь конфигурацией POSTBUILD. Даже маршрутизация на основе сигналов в Com может быть выполнена следующим образом.