Overview of Component Types
Figure 1: Overview of SWC
Software Component
In Autosar, Application software functionality implemented as software components. for example vehicle speed, chime, Gauges, vehicle Power modes, driver notification or any applications.
Software component using ports for communicating with outside world and using internal behavior for implementing the functions.
✅✅[TPS_SWCT_01002] SwComponentTypes may only interact by means of their
PortPrototypes
Graphical representation of software component
In general we have three types of SW-Cs are available. it is defined by attribute "SwComponentType".
- Atomic Software Component: An Atomic software cannot be split into further software components. This is used as general term for below components
- Application SW Component
- EcuAbstraction SW Component
- Sensor-Actuator SW Component
- ComplexDeviceDriver SW Component
- NvBlock SW Component
- Service SW Component
- ServiceProxy SW Component
- Parameter Software Component : This component provides the calibration parameter values to other software components.
- Composition Software Component: The purpose of an AUTOSAR CompositionSwComponentType is to allow the encapsulation of specific functionality by aggregating existing software-components. In simple words composition means logical grouping of software components.
Better way to differentiate the software components is understand the ARXML tags called as "attribute"
Application SW Component
The ApplicationSwComponentType is a specialization of AtomicSwComponent-Type for representing hardware-independent application software. in general words it is hardware-independent.
it implements a software applications and use all AUTOSAR communication mechanisms and services. these components are communicating with other SWC like NV component, sensor-actuator and communicating with BSW using AUTOSAR services.
- ApplicationSwComponentType uses BSW services using service ports.
EcuAbstraction SW Component
it contains references to the corresponding "Hardware element" and provides the ECU specific IO capabilities.
IO hardware abstraction is part of ECU abstraction.
Reference from SWC template spec:
✅✅[constr_1144] SensorActuatorSwComponentType, EcuAbstractionSwComponentType, and ComplexDeviceDriverSwComponentType may only reference a HwType The attribute sensorActuator of SensorActuatorSwComponentType,
the attribute hardwareElement of EcuAbstractionSwComponentType, and the attribute hardwareElement of ComplexDeviceDriverSwComponentType may only reference a HwType
Sensor-Actuator SW Component
SensorActuatorSwComponentType is a special type of an AtomicSwComponentType as it depends on specific hardware. SensorActuatorSwComponentType may use the I/O hardware abstraction directly.
Sensor-Actuator component is located above RTE hence it is communicating with other application SWC and ECU abstraction layer.
✅✅A SwComponentPrototype typed by a SensorActuatorSwComponentType needs to be mapped and run on exactly that ECU that contains the HwElement corresponding to the HwType that its SensorActuatorSwComponentType refers to in case it accesses the hardware via the I/O hardware abstraction layer. this requirement saying this component not relocatable to over different ECU so it is using in the VFB level.
ComplexDeviceDriver SW Component
The ComplexDeviceDriverSwComponentType is a special AtomicSwComponentType that has direct access to hardware on an ECU and which is therefore linked to a specific ECU or specific hardware.✅✅[TPS_SWCT_01393] Complex Driver A Complex Driver implements complex sensor evaluation and actuator control with direct access to the Microcontroller using specific interrupts and/or complex Microcontroller peripherals to fulfill the special functional and timing requirements.
NvBlock SW Component
The NvBlockSwComponentType defines non volatile data which data can be shared
between SwComponentPrototypes. The non volatile data of the
NvBlockSwComponentType are accessible via provided and required ports.
Note 1: A non volatile data interface declares a number of VariableDataPrototypes to be
exchanged between non volatile block components and atomic software components.
Note 2: The AUTOSAR Architecture defines two alternatives how a software component can access non volatile memory.
- The first option is that the software component defines in its InternalBehavior a PerInstanceMemory and a NvBlockNeeds referring to the PerInstanceMemory via a RoleBasedDataAssignment. In this case the nv block is exclusively accessed by this software component and the NvM . Therefore the nv data is encapsulated inside the software component and can not be accessed directly by other software component.
- The second option is that the software component uses port based communication to access nv data provided by a NvBlockSwComponentType. In this case it is possible that nv data used by different AtomicSwComponentTypes is packed in one larger nv block to reduce the nv block management overhead or that the same nv data used by several software components with a reduced RAM overhead. The nv data of a NvBlockSwComponentType is typed with AutosarDataTypes.
- NvBlockSwComponentType provides two main advantages:
- It allows modelling of NV data at the VFB level.
- it can be used to reduced the number of NvBlocks. the same "DataElement" can be used by different SwComponentPrototypes.
[NVM requirement Accessing NV Data using NvBlockSwComponent ]: In case of NvM being used via a NvBlockSwComponent, the NvM uses standard callback API’s provided by RTE for each NvBlockDescriptor having RoleBasedPortAssignment for a ClientServerPort (r-port) with a NvMNotifyJobFinished or NvMNotifyInitBlock Rte_NvMNotifyInitBlock() and Rte_NvMNotifyJobFinished().
- NvMService interface is used to send commands to the NvM. Some of the basic operations supported are:
- EraseBlock
- GetDataIndex
- GetErrorStatus
- InvalidateNvBlock
- ReadBlock
- RestoreBlockDefaults
- SetDataIndex
- SetRamBlockStatus
- WriteBlock
- NvMAdmin interface is used to order some administrative operations to the NVM.
- Following operation is supported. SetBlockProtection
- NvM_NotifyInitBlock interface is used by the NVM to request users to provide the default values.
- Following operation is supported. InitBlock
- NvM_NotifyJobFinished interface is used by the NVM to notify the end of job.
- Following operation is supported. JobFinished
Service SW Component
Service Software Component (ServiceSwComponentType) provides the AUTOSAR services to the application through standardized Interfaces. ServiceSwComponentType shall have service ports only.
ServiceProxy SW Component
Service Proxy software component (ServiceProxySwComponentType) is a component that acts as a proxy to provide access to internal services for one or more Remote ECUs
the main use case of ServiceProxySwComponentType is the distribution of vehicle mode throughout the system. modes are provided by Basic software. it is used in the Multi-core or Multi-partition system.
- Difference between a ServiceProxySwComponentType and an ApplicationSwComponentType d The main difference between a ServiceProxySwComponentType and an ApplicationSwComponentType is on system level:
- A prototype of a ServiceProxySwComponentType can be mapped to several ECUs even if it appears only once in the VFB system, because such a prototype is required on each ECU, where it has to address a local ServiceSwComponentType
- Apart from the semantics, a ServiceProxySwComponentType has these specific properties:
- A prototype of it can be mapped to more than one ECUs in the system description.
- Exactly one additional instance of it will be created in the ECU-Extract per ECU to which the prototype has been mapped.
- For remote communication, it can have only R-Ports with sender-receiver interfaces and 1:n semantics.
- There shall be no connectors between two prototypes of any ServiceProxySwComponentType.
Parameter Software Component
A ParameterSwComponentType
shall never aggregate a SwcInternalBehavior and also owns exclusively PPortPrototypes of type ParameterInterface.
ParameterSwComponentType having only provider port does not have receiver port.
Composition Software Component
The purpose of an
AUTOSAR CompositionSwComponentType is to allow the encapsulation of specific functionality by aggregating existing software-components. They simply group existing software-components and thereby take away complexity
when viewing or designing logical software architecture.
CompositionSwComponentType not defining any Runnable.
Connectors
- AssemblySwConnectors interconnect PortPrototypes of SwComponentPrototypes that are part of the CompositionSwComponentType.
- An AssemblySwConnector can only connect PortPrototypes of SwComponentPrototypes that are owned by the same CompositionSwComponentType
- DelegationSwConnectors connect from "inner" PortPrototypes to delegated "outer" PortPrototypes.
- A DelegationSwConnector can only connect PortPrototypes of the same kind, i.e. PPortPrototype to PPortPrototype and RPortPrototype to RPortPrototype.
General topic:
- ComSpecs attached to a PortPrototype owned by an AtomicSwComponentType have a direct impact on the generation of the RTE. The RTE Generator, on the other hand, does not consider the existence of CompositionSwComponentTypes.
- The SwcInternalBehavior of an AtomicSwComponentType describes the relevant aspects of the software-component with respect to the RTE, i.e. the RunnableEntities and the RTEEvents they respond to.
========================================================================================================
References:
========================================================================================================
Thanks for visiting the post..!!
========================================================================================================
No comments:
Post a Comment