Search code examples
autosar

adaptive AUTOSAR - difference between function group and application?


In the latest requirement document of Execution Manager of adaptive Autosar,

I am confused about function group and application.

in the document it says about function group and application like below (from https://www.autosar.org/fileadmin/user_upload/standards/adaptive/19-11/AUTOSAR_SWS_ExecutionManagement.pdf)

Function Group

A Function Group is a set of coherent Processes, which need to be controlled consistently. Depending on the state of the Function Group, Processes are started or terminated. Processes can belong to more than one Function Group State (but at exactly one Function Group). "MachineState" is a Function Group with a predefined name, which is mainly used to control Machine lifecycle and Processes of platform level Applications. Other Function Groups are sort of general purpose tools used (for example) to control Processes of user level Applications.

,

Application

An implementation that resolves a set of coherent functional requirements and is the result of functional development. An Application is the unit of delivery for Machine specific configuration and integration.

These concepts are really confusing to me.

based on my understanding I categorized applications in this way.

  1. system applications
  2. user applications - multiple applications in function groups
  3. user applications - other applications

but I'm not sure this is right or not. help me to get fully understand about function group and application so that I can categorize applications in a right way.


Solution

  • In the end, it is all about functions in the vehicle, which are distributed over multiple ECUs, including supporting functions and ECUs in between.

    In order to save battery power, not all ECUs need to be running all the time. But it could be, that some ECUs implement multiple functions.

    e.g.:

    • SRR (Short Range Radar, well nowadays also more than 150m range!) ECUs in the rear do BSD (BlindSpotDetection), LCA (LaneChangeAssist), RCTA (RearCrossTrafficAssist Alert/Brake), Freespace Detection, Collision Avoidance, OccupantSafeExit, Object Detection Output for 360° Vision and Fusion e.g. for AutomatedDriving ...

    • CentralECU, like a 360° Vision/Fusion ECU for Automated Driving, which has several sensoric ECUs like front LRR (Long Range Radar), front Cameras and front and rear SRRs connected. If this ECU is also the gateway of for the sensoric ECUs, and the rear SRRs are used for OSE, then the front ECUs can be shutdown, and the CentralECU can at least shutdown several high performance cores/processors, except the ones needed for routing between vehicle and the rear SRRs. After the driver/passenger leave the car, they can then shutdown shortly after too.

    For the above scenarios, other gateways might also be involved. And also the SRRs and CentralECU need to be aware of, that other ECUs are off and not providing data like vehicle speed, yawrate, steering angle etc. and therefore, the messages are not transmitted on the networks anymore. Rx/Tx deadline monitoring should be disabled for functions which are turned off. Functions that are shutdown also in these SRRs or CentralECUs should also stop their functional messages to be transmitted.

    That is, why you could have in one application multiple functions grouped into one or more function groups, because the ECU could be involved in several of them. At least the AUTOSAR Adaptive is for the CentralECU, the SRR ECUs usually are low-price ECUs, which just run AUTOSAR Classic. But there is similar handling through PartialNetworking, VirtualFunctionCLusters and NetworkManagement.