An introduction to autosar
AUTOSAR, AUTomotive Open System Architecture (AUTomotive Open System Architecture) is an alliance dedicated to the development of automotive electronic software standards. AUTOSAR is jointly established by global automobile manufacturers, component suppliers and other electronics, semiconductor and software system companies, and each member maintains a development partnership.
Before autosar, car companies usually used the osek architecture, and there was a serious coupling between the software and hardware levels.
Therefore, various car companies jointly launched the autosar layered architecture model: application layer, RTE, system service layer, and hardware layer. The development cycle is short and reusable. In addition, there is a graphical configuration tool called davinci from vector company, which can generate high-quality code without handwriting code.
1 cp
runnable: the function in swc, when autosar is generated by davinci software, runnable is an empty function, and you need to manually add code to implement it. runnable can be triggered.
RTE: Isolate the upper layer and the lower layer, intermediary role.
BSW: Basic Software
2 ap
AP mainly provides high-performance computing and communication mechanisms, and provides flexible software configuration, such as OTA online upgrade.
basic concept
- Software Component (SW-C): software component
- Virtual Functional Bus (VFB): Virtual Function Bus
- Runtime Environment (RTE): operating environment (real-time environment)
- Basic Software (BSW): basic software
- Methodology principle: Methodology principle
- Mode Management: mode management
- Memory Abstraction: storage abstraction
- Runnables: runnable entities
Document Naming Rules
- EXP: That is, "Explaination", which introduces the topic in detail
- MMOD: the Meta Model "meta-model", introducing the AUTOSAR meta-model
- MOD: Model "Modeling", introduces the principle of modeling
- RS: Requirement Specification "Requirement Specification", which introduces the requirements in detail
- SRS: Software Requirement Specification "Software Requirement Specification", which describes the specification of all software modules
- SWS: Software Specification "Software Specification", which introduces the specification of software module design and implementation
- TPS: Template Specification "Template Specification", which introduces the metamodel in detail
- TR: Technical Specification "Technical Specification", which introduces technical specifications in detail
Application：swc，ports，runnables
swc: automatic swc, composition swc, special swc
ports: use ports communication between swc and swc
2 ARXML
ARXML stands for AUTOSAR xml, which is a human-machine-readable text format that describes the AUTOSAR model in xml language (Extensible Markup Language). This standard introduces how to serialize the AUTOSAR model into the rules described by AUTOSAR XML to provide support for the interoperability between AUTOSAR tools; more standardized format expression can also reduce the workload of tool implementation. A sample is as follows:
1）ARPackage(AR-PACKAGE)
AUTOSAR Package (ARPackage) is some kind of "package" used to group software components, data types and other elements of AUTOSAR. It creates a corresponding "namespace" for this package. ARPackage is not classified, but its sub-packages are.
| ARPackage |
Category |
| PhysicalDimensions |
STANDARD |
| Units |
STANDARD |
| LifeCycleInfoSets |
STANDARD |
| DataConstrs_Blueprint |
BLUEPRINT |
| ApplicationDataTypes_Blueprint |
BLUEPRINT |
| CompuMethods_Blueprint |
BLUEPRINT |
| PortInterfaces_Blueprint |
BLUEPRINT |
| PortPrototypeBlueprints_Blueprint |
BLUEPRINT |
| KeywordSets_Blueprint |
BLUEPRINT |
| Collections_Blueprint |
BLUEPRINT |
| ApplicationDataTypes_Example |
EXAMPLE |
| BlueprintMappingSets_Example |
EXAMPLE |
| CompuMethods_Example |
EXAMPLE |
| PortInterfaces_Example |
EXAMPLE |
| SwComponentTypes_Example |
EXAMPLE |
| DataConstrs_Example |
EXAMPLE |
| Systems |
EXAMPLE |
STANDARD : Elements standardized by the committer of the relevant top-level package, which can be used as-is for processing (e.g. ECU parameter definitions).
BLUEPRINT : Elements in such packages are like toolboxes, a kind of "recipe" from which definitions can be copied into real projects.
EXAMPLE : Example how to apply the element in the STANDARD or BLUEPRINT package.
2） Interface
SenderReceiverInterface(SENDER-RECEIVER-INTERFACE)
SenderReceiverInterface defines the data elements that PPort can provide and RPort requires for data exchange between software components (SWcomponent). This interface is composed of variable data prototypes and specified transfer data.
ClientServerInterface(CLIENT-SERVER-INTERFACE)
ClientServerInterface defines the operations that PPort can provide and RPort can use, and allows the client (Client) to call the operation on the server (Server), thereby providing the result to the client (Client). The parameter data prototype of an interface operation can be the server's client input (IN) or server result (OUT) or both (INOUT).
Interface type in Basic Software
AUTOSAR Interface
AUTOSAR Interface defines the information exchanged between software components, between BSW modules, and between software components and BSW modules.
Standardized AUTOSAR Interface
Standardized AUTOSAR Interface is a standardized AUTOSAR Interface used to define AUTOSAR Service. AUTOSAR Service is a standardized service provided by AUTOSAR Basic Software to applications (ApplicationSoftware Component).
Standardized Interface
The Standardized Interface interacts between BSW modules without using the AUTOSAR interface technology and is a standardized API. Usually defined by a specific language (such as C language). When the software modules communicate through the Standardized Interface, the communication between the software modules cannot be routed through the network.
RTE and Interface interface, as shown in the following figure:
3） VariableDataPrototype(VARIABLE-DATA-PROTOTYPE)
VariableDataPrototype is the element used to contain values in the ECU application. can be used as:
1) Data elements in SenderReceiverInterface;
2) Runnable variables in the internal behavior of software components;
3) per-entity memory in the internal behavior of software components;
4) Static memory in the internal behavior of software components.
4） ApplicationDataType
ApplicationPrimitiveDataType(APPLICATION-PRIMITIVE-DATA-TYPE)
Including: Primitive (simple type), STRING, BOOLEAN, ARRAY, CURVE, MAP, RES_AXIS, COM_AXIS, STRUCTURE, etc.
ApplicationRecordDataType(APPLICATION-RECORD-DATA-TYPE)
Is the compilation of ApplicationRecordElements, the category must be STRUCTURE.
ApplicationArrayDataType(APPLICATION-ARRAY-DATA-TYPE)
Is composed of one or more ApplicationArrayElements
5) ARXML serialization rules
An AUTOSAR model can be extracted from multiple XML description files; for example, some files contain data types while others contain interfaces, etc.; the file
suffix is ".arxml";
the maximum length of the file name is 255 bytes;
ARXML conforms to the standard XML file format;
ARXML encoding format requires UTF-8 character encoding, cannot start with BOM, and the
ARXML header must be in XML encoding format to declare that
BOM is a Unicode character that can be used in byte streams; UTF-8 does not support different the end of
ARXML is implemented based on the XML V1.0 standard;
The ARXML header needs to declare the XML version, as shown in the figure below
Three vector davinci toolchain
In-depth analysis of AUTOSAR architecture from entry to abandonment – Source Code Bus
Recommend a good tool for learning Autosar ecu configuration_autosar tool_SilenceMCU's blog-CSDN blog
https://blog.csdn.net/weixin_60362661/category_11989790.html
vector davinci configuration classic Download the core tools for configuration, verification, and generation of BSW and RTE
Network disk extraction code 3g62
1) Design software architecture based on requirements and form software architecture documents;
2) Develop ARXML through DavinciDeveloper according to software architecture;
3) Create a configuration project in Davinci Configurator, define the properties of the project, including the path of code generation, and the referenced configuration SIP Wait, this part of the content will be provided by the supplier when purchasing the configuration package. The supplier will provide the corresponding technical manual or configuration instructions;
4) According to the software architecture and software requirements, configure the underlying OS, COM, DEM, DCM and other codes, and purchase the configuration package from the supplier Provide corresponding technical manuals and technical support, and configure according to requirements to obtain corresponding function codes;
5) Import ARXML into Davinci Configurator, configure RTE codes according to the software architecture document, and map SWC Runnable Mapping to specific Tasks in RTE;
6) According to the software architecture and software requirements, import ARXML into MATLAB/Simulink to develop the application layer model/code;
7) The bottom layer, RTE, application layer, and MCAL code are integrated, compiled, debugged, compiled, and debugged.