адаптивный AUTOSAR - разница между функциональной группой и приложением?

Question

В последнем документе с требованиями к диспетчеру выполнения адаптивного Autosar,

я запутался в отношении группы функций и приложения.

в документе говорится о группе функций и приложение , как показано ниже (из https://www.autosar.org/fileadmin/user_upload/standards/adaptive/19-11/AUTOSAR_SWS_ExecutionManagement.pdf)

Функциональная группа

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

,

Приложение

Реализация это решает ряд согласованных функциональных требований и является результатом функционального развития. Приложение - это единица доставки для конфигурации и интеграции, определяемой машиной c.

Эти концепции меня действительно смущают.

исходя из моего понимания, я классифицировал приложения таким образом.

1. системные приложения
2. пользовательские приложения - несколько приложений в функциональных группах
3. пользовательские приложения - другие приложения

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

Answer 1

В конце концов, это все о функциях в транспортном средстве, которые распределены по нескольким ЭБУ, включая поддерживающие функции и ЭБУ между ними.

Для экономии заряда батареи не все ЭБУ должны быть работает все время. Но может случиться так, что некоторые ECU реализуют несколько функций.

например:

• SRR (радар ближнего радиуса действия, а в настоящее время также дальность действия более 150 м!) ЭБУ в тылу делают BSD (BlindSpotDetection), LCA (LaneChangeAssist), RCTA (RearCrossTrafficAssist Alert / Brake), обнаружение свободного пространства, предотвращение столкновений, OccupantSafeExit, выход обнаружения объекта для обзора 360 ° и слияния, например, для AutomatedDriving ...

• CentralECU, как 360 ° Vision / Fusion ECU для автоматического вождения, который имеет несколько сенсорных c ECU, таких как передний LRR (Long Range Radar), передние камеры и передний и задний SRR. Если этот ECU также является шлюзом для сенсорных c ECU, а задние SRR используются для OSE, то передние ECU могут быть отключены, а CentralECU может по крайней мере отключить несколько высокопроизводительных ядер / процессоров, кроме тех, которые необходим для маршрутизации между автомобилем и задними SRR. После того, как водитель / пассажир покинет автомобиль, он может вскоре отключиться.

Для вышеупомянутого сценария ios могут также использоваться другие шлюзы. А также SRR и CentralECU должны знать, что другие ECU отключены и не предоставляют такие данные, как скорость автомобиля, скорость рыскания, угол поворота руля и т. Д. c. и, следовательно, сообщения больше не передаются в сети. Мониторинг крайнего срока приема / передачи должен быть отключен для функций, которые отключены. Функции, которые также отключаются в этих SRR или CentralECU, должны также останавливать передачу их функциональных сообщений.

Именно поэтому в одном приложении может быть несколько функций, сгруппированных в одну или несколько функциональных групп, потому что ЭБУ может участвовать в нескольких из них. По крайней мере, AUTOSAR Adaptive предназначен для CentralECU, ECU SRR обычно представляют собой недорогие ECU, которые просто запускают AUTOSAR Classi c. Но есть аналогичная обработка через PartialNetworking, VirtualFunctionCLusters и NetworkManagement.