This article introduces the differences between automotive embedded development and consumer electronics embedded development, and demonstrates the differences between the two development methods through the “traditional embedded development and AUTOSAR development of the car door module”.
The methods of automotive embedded software development and consumer electronics embedded software development are completely different, and this difference is summarized by two aspects: first, the differences in environmental and regulatory factors caused by product characteristics; second, the differences in research and development models. If the following content feels abstract, you can distinguish these concepts through the last “car door example”.
● First, the differences in product characteristics:
In embedded development, environment-oriented product design is an important consideration. Clearly, the operating environments of automotive electronic products and consumer electronic products are different, and their working environmental conditions, temperature, humidity, external environmental impacts, etc., differ greatly. For example, an automotive radio must withstand high temperatures of +85 degrees Celsius and extreme cold working conditions of -40 degrees Celsius.
In addition to explaining the differences from the perspective of the working environment of automotive electronic products compared to consumer electronic products, another obvious difference is that automotive electronic products are also subject to local or industry-specific regulations and standards. These industry-specific or local regulations and standards are generally stricter and more stringent than those of consumer electronic products, as automobiles are a means of transportation, with more consideration given to safety and reliability factors.
The first consideration is the decoupling of hardware and software. Software-defined vehicles (SDV) are a key trend in the automotive industry’s digital transformation, achieving diversification and personalization of automotive functions through software, and enabling software updates via over-the-air technology (OTA).The traditional consumer embedded development model is a linear process, tightly coupling hardware and software development, which in automotive applications leads to long development cycles and poor flexibility. In the software-defined vehicle era, software development adopts agile, spiral development models, combined with the vehicle’s V-model development approach, achieving decoupling and collaboration of hardware and software development, supporting rapid iteration and personalized customization. Through effective decoupling of software and hardware development and continuous collaboration, software development, verification, and delivery do not depend on the progress of the vehicle hardware development, allowing for immediate release of software products at all stages of development.
The second is ensuring software safety: The complexity and safety requirements of automotive software are extremely high, and ensuring software quality and safety is a major challenge. In traditional embedded software development, defining data types, drivers, and other handwritten code can lead to non-standard practices. In complex automotive application scenarios, bugs caused by incomplete code testing can easily occur. For example, handwritten CAN communication definitions can lead to communication bugs in certain scenarios. Automotive software development pursues layered and modular software modules; for instance, in CAN communication, you only need to call the interface to achieve communication functionality, while the specific transmission process is encapsulated through AUTOSAR specifications, preventing faults caused by manually defined code.
The third is more convenient division of labor: For example, the OEM and suppliers define the RTE interface, and the OEM also participates in software development, as the OEM understands the vehicle’s usage scenarios or is closer to the user, thus better understanding customer needs. The OEM can be responsible for developing the vehicle control strategy layer, while the supplier’s strengths lie in lower-level software development and BOM costs, thus responsible for hardware and lower-level software development.
● Why use AUTOSAR?
In summary AUTOSAR can be summarized in one sentence:AUTOSAR is a code configuration specification, and configuration tools are derived from this specification. In other words, the method of automotive software development is tool configuration, while traditional embedded development is handwritten code.
AUTOSAR and traditional embedded development have several key differences in core methodology and tool usage:
Standardization and Modularity:
-
AUTOSAR: Emphasizes standardization and modularity, defining standards for software components, interfaces, and communication protocols, making it easier to integrate and interchange different software modules.
-
Traditional embedded development: Typically focuses more on direct programming for specific hardware platforms, with lower levels of modularity and standardization.
Hardware Abstraction:
-
AUTOSAR: Provides a hardware abstraction layer (EcuAbstraction, Rte, BswM, etc.), allowing software to be decoupled from hardware details, increasing software portability.
-
Traditional embedded development: Usually interacts directly with hardware interfaces, with high hardware dependency.
Configuration and Code Generation:
-
AUTOSAR: Uses configuration files to define system behavior, then generates code through tools, reducing the workload of manual coding.
-
Traditional embedded development: Mainly relies on manual coding, with relatively little role for configuration.
Development Process:
-
AUTOSAR: Follows a more rigorous development process, including requirements analysis, system design, component configuration, code generation, integration, and testing.
-
Traditional embedded development: The development process may be more flexible and simplified but may lack strict standardization.
Maintainability and Upgrades:
-
AUTOSAR: Due to modularity and standardization, the software is easier to maintain and upgrade.
-
Traditional embedded development: Maintenance and upgrades may require more manual intervention, with higher risks.。
AUTOSAR Tools:
-
Configuration tools: Such as Vector CANoe, EB Tresos, Mentor Graphics Volcano, etc., used to create and edit AUTOSAR configuration files.
-
Code generation tools: These tools generate C code and header files based on configuration files.
-
Testing and simulation tools: Such as Vector CAST, dSPACE, etc., used for simulation and testing in the early stages of software development.
Traditional Embedded Development Tools:
-
Integrated Development Environment (IDE): Such as IAR Embedded Workbench, Keil MDK, Atmel Studio, etc., providing compilers, debuggers, and project management tools.
-
Version control systems: Such as Git, Subversion, etc., for code version management and collaboration.
-
Hardware debuggers: Such as JTAG, SWD, etc., for hardware-level debugging.
In summary,AUTOSAR development focuses on using configuration-driven tools and methods to improve production efficiency and software quality, while traditional embedded development relies more on direct programming and hardware-specific tools. The AUTOSAR toolchain is usually more complex but offers a higher level of abstraction and a stricter development process, which is especially important in developing large, complex automotive electronic systems.
● Requirements
Suppose we need to develop a car door control module that needs to implement the following functions:
-
Automatically lock when the door is closed.
-
Automatically unlock when receiving an unlock signal.
-
Automatically unlock all doors when a collision occurs.
In traditional embedded development:
Hardware Dependency: The developer first needs to understand the specific ECU hardware specifications, including the microcontroller model, I/O ports, memory size, etc.
Direct Programming: The developer writes code directly on the microcontroller, handling all hardware interfaces such as door sensors, lock control solenoids, and collision sensors.
Function Implementation:
-
Locking Function: Write code to monitor the door status and activate the lock control solenoid when the door is detected to be closed.
-
Unlocking Function: Write code to listen for the unlock signal (possibly from a wireless signal from the car key or other control units), and activate the lock control solenoid to unlock when the signal is received.
-
Collision Unlock: Write code to monitor the collision sensor and activate all lock control solenoids to unlock when a collision is detected.
-
Integration and Testing: The developer needs to conduct integration testing on the actual hardware to ensure all functions work properly.
-
Maintenance and Upgrades: If new functions need to be added or bugs fixed, the developer may need to modify the lower-level code directly, which may require a lot of retesting.
In the AUTOSAR framework, the software development process for the door control module differs:
Hardware Abstraction:AUTOSAR provides a hardware abstraction layer (MCAL), meaning developers do not need to deal directly with hardware but can communicate with hardware through standardized interfaces.
Modular Design: Developers break down functions into independent software components (SW-C), such as “LockControl”, “UnlockSignalHandler”, and “CrashDetector”.
Configuration: Using AUTOSAR configuration tools, developers can configure parameters for each component, such as sensor thresholds and the activation logic for the lock control solenoid.
Function Implementation:
Locking Function:Create a “LockControl” component that communicates with the door sensor through standard AUTOSAR interfaces and sends lock commands at appropriate times.
Unlocking Function:Create an “UnlockSignalHandler” component that listens for unlock signals and controls the lock control solenoid through standard interfaces.
Collision Unlock:Create a “CrashDetector” component that notifies the “LockControl” component to unlock all doors when a collision is detected through standard interfaces.
Integration and Testing: Since the components are standardized, they can be integrated and tested in a simulation environment before being deployed to the actual ECU hardware.
Maintenance and Upgrades: As the components are modular, adding new functions or fixing bugs typically only requires updating or replacing the corresponding components, rather than modifying the entire system, greatly simplifying maintenance and upgrade processes.
This example illustrates how the AUTOSAR development approach, compared to traditional embedded development, offers higher modularity, standardization, and configurability, which helps improve software reusability, maintainability, and development efficiency. At the same time, the AUTOSAR development process is also more suitable for the development of complex systems, better meeting the high performance and safety requirements of modern automotive electronic systems.